Virtual Machine Background Reboot via Cloning and Change Integration
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Virtual machines often require rebooting for updates, which interrupts user operations and results in lost productivity as users must stop working during the process.
Innovation Solution
A system and method that allow virtual machines to detect the need for a reboot, prompting users to opt for a background reboot, where the virtual machine is cloned, and the reboot is performed while the user continues to use the original machine, with changes integrated into the clone after completion.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If a virtual machine performs a reboot operation to update the operating system or application, then the system can be updated with new features and security patches, but the user operations are interrupted and productivity is lost
Solution Approach 1:
The system segments the virtual machine into two separate instances: the original VM that continues serving user operations, and a cloned VM that performs the reboot and update operations. This segmentation allows both update reliability and operational productivity to be maintained simultaneously by isolating the reboot process from the user-facing instance.
Solution Approach 2:
The system creates a copy (clone) of the virtual machine to perform the reboot operation. The cloned VM is an exact replica that can be updated without affecting the original VM's operational status. After the cloned VM completes its reboot and updates, the system can switch users to the updated clone, thereby maintaining productivity while achieving system updates.
2Reliability
If a virtual machine is rebooted to install patches and drivers, then system security and performance are improved, but the reboot process takes time and interrupts normal operations
Solution Approach 1:
The system performs preliminary actions by creating a cloned VM in advance before the user needs to switch to an updated instance. The cloning process prepares a ready-to-update replica that can undergo reboot operations without waiting for the user to be idle, thereby reducing the perceived downtime and allowing security patches to be applied in advance.
Solution Approach 2:
The system maintains continuity of useful action by ensuring the original VM remains operational and serving user requests throughout the entire reboot process of the cloned VM. This allows the update process to continue in the background without interrupting normal operations, effectively eliminating idle time while security patches are being installed.
3Reliability
If a virtual machine performs multiple reboot operations for updates, then the system remains current with latest software versions, but user productivity decreases due to repeated interruptions
Solution Approach 1:
The system segments the update process by maintaining separate original and cloned VM instances. This allows multiple update operations to be performed on cloned instances in parallel while the original instance continues to serve users without interruption. Each clone can be updated independently, enabling continuous software version updates without affecting work continuity.
Solution Approach 2:
The cloned VM acts as an intermediary that absorbs all reboot and update operations. Users interact with the original VM which remains stable and uninterrupted, while the clone serves as a buffer that undergoes all necessary software updates. This intermediary approach allows the system to remain current with latest software versions while maintaining uninterrupted user productivity.
Data Source
AI summary
A system can allow a user to continue using a virtual machine while a background reboot occurs on a clone of the virtual machine. A backup agent operating on a server can receive a request from a virtual machine operating in an active state, to complete a reboot operation without operational interruption. A hypervisor can clone the virtual machine. During and after cloning, the backup agent can cause a filter agent to capture changes to the virtual machine. The virtual machine clone can notify the backup agent that the reboot is complete. Changes made in the interim on the virtual machine can be integrated on the virtual machine clone. Then the hypervisor can transition usage from the virtual machine to the virtual machine clone.