Parentless Virtual Machine Forking for Live Cloning
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Current virtual machine (VM) fork operations require a parent VM to be in a permanent quiesced state, limiting its management and flexibility, as it cannot be restored or deleted while child VMs exist, and imposes code complexity and resource overhead.
Innovation Solution
The parentless VM fork operation allows for the creation of powered-on VMs from a running state, enabling efficient sharing of memory and disk state with the source VM while becoming independent, allowing both parent and child VMs to resume execution, and simplifying management by eliminating the need for a stunned source VM.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Adaptability or versatility
If a parent VM is used as source for live cloning, then cloning capability is enabled, but the parent VM becomes permanently quiesced and cannot execute instructions
Solution Approach 1:
The patent divides the VM state into two separate components: the source VM state (used for cloning) and the running VM state (continues execution). This is achieved by creating a snapshot of the source VM's memory and device state, then allowing the original VM to resume while the cloned VM is created from the snapshot. The segmentation separates the cloning function from the execution function.
Solution Approach 2:
The patent uses memory copying techniques to replicate the source VM's state to the cloned VM. Instead of requiring the source VM to remain quiesced, the system copies the necessary state (memory pages, device state) to create the clone, then allows the source VM to continue running. This copying approach enables both VMs to execute simultaneously.
2Extent of automation
If a parent VM is marked as source VM, then system manages it differently, but this increases device complexity and management restrictions
Solution Approach 1:
The patent makes the VM fork operation universal by allowing any running VM to serve as a source without requiring a special quiesced state. The fork operation works on powered-on VMs just as it would on quiesced VMs, eliminating the need for different management paths. This universal approach simplifies the system by removing special-case handling for parent VMs.
Solution Approach 2:
The patent inverts the traditional approach by not requiring the source VM to be quiesced before forking. Instead of stunning the VM first and then forking, the system performs the fork operation on the running VM and then allows it to continue execution. This inversion eliminates the complexity of managing quiesced parent VMs while maintaining the cloning capability.
3Adaptability or versatility
If parent VM consumes memory and storage resources in quiesced state, then cloning is supported, but resource overhead increases
Solution Approach 1:
The patent merges the cloning operation with the running VM state by allowing the source VM to remain powered on during the fork operation. The memory and storage resources are shared between the source VM and the cloned VM through snapshot technology, eliminating the need for duplicate resource allocation. This combining approach reduces overall resource consumption while supporting cloning.
Data Source
AI summary
Instructions to fork a source VM are received, and execution of the source VM is temporarily stunned. A destination VM is created, and a snapshot of a first virtual disk of the source VM is created. A checkpoint state of the source VM is transferred to the destination VM. The source VM has one or more virtual disks. One or more virtual disks associated with the destination VM are created and reference the one or more virtual disks of the source VM. Execution of the destination VM is restored using the transferred checkpoint state and the virtual disks of the destination VM in a way that allows the source VM to also resume execution. Forking VMs using the described operation provisions destination VMs in a manner that makes efficient use of memory and disk space, while enabling source VMs to continue execution after completion of the fork operation.