Control VM Migration for Continuous Guest Uptime
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Software upgrades of virtualization host devices often require rebooting, leading to downtime of both host devices and guest Virtual Machines (VMs), which is undesirable and can be costly due to the need for spare hosts and live migration drivers.
Innovation Solution
The solution involves connecting guest VMs to an old control VM, creating an upgraded control VM with new virtualization software, and seamlessly transitioning control to the new VM without interrupting guest VM operations, using architectural domain separation and live-migration capabilities to manage I/O operations, eliminating the need for spare hosts and live migration drivers.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If the virtualization host device is rebooted to load upgraded virtualization software, then the virtualization software is updated, but the host device and guest VMs experience downtime and cannot operate
Solution Approach 1:
The system segments the virtualization control into multiple control VMs (old control VM and new control VM) that can operate independently. The new control VM is created and configured separately while the old control VM continues to manage guest VMs, allowing incremental updates without complete system shutdown.
Solution Approach 2:
The new control VM is created and configured in advance before the old control VM is deactivated. Virtual I/O backends are pre-configured in the new control VM, and communication paths are established beforehand, so that when the transition occurs, guest VMs can immediately connect to the new control VM without interruption.
2Reliability
If live migration is used to migrate guest VMs to spare host devices, then continuous operation is maintained, but extra host devices and live migration drivers are required, increasing TCO
Solution Approach 1:
The control VM architecture provides multi-functionality where a single host device can host multiple control VMs that manage the same set of guest VMs. This eliminates the need for separate spare host devices, as the new control VM serves as both the updated version and the continuous operation guarantee.
Solution Approach 2:
Instead of migrating guest VMs to a different physical host, the system creates a copy of the control functionality in the new control VM on the same host. This copying approach maintains all necessary management capabilities without requiring additional physical infrastructure.
3Ease of manufacture
If kernel patching techniques are used to upgrade virtualization software, then small changes can be applied, but the solution is limited in scope and becomes tricky when data structures change
Solution Approach 1:
The virtualization software is segmented into control VMs that can be independently created, configured, and updated. This allows comprehensive changes to data structures and software components without the limitations of kernel patching, as each control VM is a separate executable entity that can be fully replaced.
Data Source
AI summary
Systems and methods for providing a continuous uptime of guest Virtual Machines (“VMs”) during upgrade of a virtualization host device. The methods comprising: connecting all of the guest VMs' frontends or drivers to at least one old control VM which is currently running on the virtualization host device and which contains old virtualization software; creating at least one upgraded control VM that contains new virtualization software and that is to replace the old VM in the virtualization host device; connecting the guest VMs' frontends or drivers to the upgraded VM; and uninstalling the old control VM from the virtualization host device.