Hypervisor Hot-Swap via Memory Pointer Transfers
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Upgrading hypervisors or operating systems often requires rebooting the underlying machine, which interrupts virtual machines and can be time-consuming, especially when the aggregate size of virtual machines is large, and may not be feasible without a standby machine.
Innovation Solution
The process involves partitioning the machine into source and target partitions, where the updated hypervisor is installed on the target partition, and virtual machines are migrated logically by sending memory pointers instead of physically moving data, allowing for a 'hot swap' without rebooting, using techniques like shared memory to facilitate resource transfer.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If virtual machines are physically migrated to a standby machine during hypervisor upgrade, then virtual machines can continue executing during upgrade, but migration takes an undesirably long time when collective size is large
Solution Approach 1:
Instead of physically migrating virtual machine data, the system creates a pointer copy (memory pointer) that references the original virtual machine data location. This pointer-based representation allows the virtual machines to be logically migrated without copying their actual data, dramatically reducing migration time while maintaining continuous execution capability.
Solution Approach 2:
The system replaces the mechanical data copying process with a pointer-based reference mechanism. By substituting physical data transfer with pointer assignment, the system achieves virtual machine migration without the time-consuming physical copy operations, enabling fast hot-swapping during hypervisor upgrades.
2Reliability
If virtual machines are physically migrated during hypervisor upgrade, then virtual machines can continue executing, but requires a standby machine that is not always available
Solution Approach 1:
The system uses pointer copies to represent virtual machines, eliminating the need for physical standby hardware. The pointer-based representation can be stored in memory and switched between hypervisors without requiring dedicated standby machine resources, making the solution adaptable to any host configuration.
Solution Approach 2:
The pointer-based virtual machine representation can be executed on any hypervisor instance, making the system universally applicable without requiring specialized standby hardware. The same pointer mechanism works for both hot-swapping and normal operation, providing multi-functionality that eliminates standby machine dependencies.
3Loss of time
If memory pointers are used to migrate virtual machines instead of physical data transfer, then transfer time is reduced by orders of magnitude, but requires sophisticated memory management
Solution Approach 1:
The system copies only the memory pointer (a small data structure containing address information) rather than the entire virtual machine data. This selective copying approach reduces transfer time dramatically while the memory management complexity is contained within the pointer handling mechanism, which is managed by the hypervisor's existing memory management subsystem.
Data Source
AI summary
An “old” hypervisor is upgraded to or otherwise replaced by a “new” hypervisor without migrating virtual machines to a standby computer. The old hypervisor partitions the computer that it controls between a source partition and a target partition. The hypervisor and its virtual machines initially run on the source partition, while a new hypervisor is installed on the target partition. The virtual machines are migrated to the new hypervisor without physically moving the in-memory virtual-machine data. Instead, the old hypervisor sends memory pointers, and the new hypervisor claims the respective memory locations storing the virtual-machine data. After all virtual machines are migrated, the old hypervisor bequeaths the hypervisor memory and a last processor that the old hypervisor requires to run. The new hypervisor claims the bequeathed processor and hypervisor memory after the old hypervisor terminates to complete the upgrade/exchange.