Online Hypervisor Replacement via Resource Segmentation
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Conventional virtualized systems require shutting down all VMs and applications to install a new hypervisor, causing downtime and disrupting system operation, as they cannot support multiple instances of hypervisors sharing system hardware.
Innovation Solution
A method to transfer control of hardware resources from one hypervisor to another without interrupting the operation of the first hypervisor or virtual machines, allowing for the installation of a new hypervisor while keeping the system running, by hot-removing and hot-adding hardware resources and migrating VMs to the new hypervisor.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Adaptability or versatility
If a new hypervisor is installed to replace the original hypervisor, then the virtualization software can be updated or changed, but the system must shut down all VMs and applications causing downtime
Solution Approach 1:
The patent applies preliminary action by installing and initializing the new hypervisor (HV2) before the old hypervisor (HV1) is shut down. The new hypervisor is prepared with all necessary configurations and is ready to接管 control immediately when HV1 is replaced, eliminating downtime. This is achieved by booting the system into a special mode that allows dual hypervisor coexistence temporarily, enabling HV2 to be fully configured and validated before HV1 is deactivated.
Solution Approach 2:
The patent uses an intermediary mechanism in the form of a special boot mode or transition state that allows two hypervisors to coexist temporarily during the replacement process. This intermediary state enables seamless handover of control from HV1 to HV2 without interrupting VM operations. The intermediary mechanism manages the transition of hardware resource control and ensures continuous system availability throughout the hypervisor replacement process.
2Adaptability or versatility
If hardware resources are transferred from one hypervisor to another, then the new hypervisor can take control, but conventional systems cannot support multiple instances of hypervisors sharing system hardware
Solution Approach 1:
The patent applies segmentation by dividing hardware resource control into distinct phases and ownership states. During the transition period, hardware resources are segmented between HV1 and HV2 with clear boundaries on who controls what. The system divides the resource management space into separate control domains, allowing each hypervisor to manage specific subsets of resources without conflict. This segmentation enables safe coexistence and controlled transfer of resource ownership from HV1 to HV2.
3Ease of manufacture
If the original hypervisor is shut down to install a new one, then the replacement can be completed, but system operation is disrupted and VMs must be restarted
Solution Approach 1:
The patent implements continuity of useful action by ensuring that VM operations continue uninterrupted throughout the hypervisor replacement process. The system maintains continuous service delivery by allowing VMs to run on HV1 while HV2 is being installed and configured, then seamlessly transitions control to HV2 without requiring VM shutdown or restart. This continuous operation is achieved through the dual-hypervisor coexistence mechanism and controlled resource transfer, eliminating service disruption entirely.
Data Source
AI summary
In a virtualized system running one or more virtual machines on a first hypervisor, a second hypervisor is installed and control of the hardware resources of the physical computer supporting the virtualized system is migrated from the first hypervisor to the second hypervisor without interrupting the operation of the first hypervisor and the virtual machines. Initially a minimal set of hardware resources is hot-removed from control by the first hypervisor, and the second hypervisor is launched on the minimal set of hardware resources. Both the remaining hardware resources and the virtual machines are then migrated from the first hypervisor to the second hypervisor until all the virtual machines have been migrated over to the second hypervisor, while the virtual machines and the first hypervisor continue running largely unaffected by the migration process.