Hypervisor Container Reboot Preserving Guest OS Memory State
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Hypervisor reboots in virtualized host platforms are disruptive to multiple guest operating systems, requiring shutdown or migration of guest operating systems, which negates the resource-sharing advantages of virtual hosts.
Innovation Solution
A method and apparatus that suspend guest operating systems, reboot containers while preserving volatile memory contents, and resume operations, allowing for a non-disruptive and non-migratory hypervisor reboot by maintaining state information at the same addresses or relocating memory with address translation.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If a hypervisor reboot is performed on a virtualized host platform, then the hypervisor can be upgraded or maintained, but multiple guest operating systems are disrupted and require shutdown or migration
Solution Approach 1:
The system segments the hypervisor functionality into multiple container instances, each managing a subset of guest operating systems. This allows selective rebooting of individual containers rather than the entire hypervisor, enabling maintenance while preserving guest OS continuity in other containers.
Solution Approach 2:
The system performs preliminary actions by creating a snapshot of the volatile memory state before rebooting a container. This snapshot is preserved and used to restore the guest operating system state after the container reboot, preventing disruption to guest OS operations.
2Reliability
If guest operating systems are shut down or migrated before hypervisor reboot, then the reboot can be performed safely, but the resource-sharing advantages of virtual hosts are lost
Solution Approach 1:
The hypervisor is divided into multiple independent container instances, each capable of being rebooted individually. This segmentation allows the system to maintain virtual host resource sharing across containers while performing targeted reboots on specific containers without affecting others.
Solution Approach 2:
The system introduces a container layer as an intermediary between the hypervisor and guest operating systems. This container acts as a mediator that can be rebooted while preserving guest OS state through snapshotting, allowing hypervisor maintenance without requiring guest OS shutdown or migration.
3Reliability
If the entire hypervisor is rebooted, then system-wide updates can be applied, but all guest operating systems experience disruption
Solution Approach 1:
The hypervisor is segmented into multiple container instances that can be rebooted independently and sequentially. This allows updates to be applied to individual containers without forcing a complete system-wide reboot, thereby minimizing guest operating system downtime through parallel operation of updated and non-updated containers.
Solution Approach 2:
The system maintains continuity of useful action by keeping other container instances operational while one container is being updated. Guest operating systems continue to run on non-updated containers during the reboot process, ensuring uninterrupted service and minimizing overall downtime.
Data Source
AI summary
A non-disruptive, non-migratory hypervisor reboot is performed by suspending execution of the guest operating system, rebooting the container, and then resuming execution of the guest operating system. Suspending execution of the guest operating system can include stopping guest OS access to processing resources. Reboot includes the container loading or reloading itself while preserving the contents of the volatile memory in place. It is also possible to relocate some or all of the contents of the volatile memory to different addresses by creating an abstraction layer.