Hypervisor Shadow Relocation via Cache Controller Interception
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
In systems utilizing a hypervisor for hardware virtualization, removing a node hosting the hypervisor from the pool is challenging due to the dependency of guest operating systems on the hypervisor, making it difficult to manage failures and maintain system continuity.
Innovation Solution
Implementing a method and system where a shadow hypervisor is hosted on a different node, allowing interception and modification of hypervisor access requests to redirect them to the shadow hypervisor upon failure, enabling seamless transition and maintaining system operation without altering the source code or pointers.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Ease of repair
If a node hosting the hypervisor is removed from the system, then system maintenance and failure management become possible, but guest operating systems cannot continue to access the hypervisor and system continuity is disrupted
Solution Approach 1:
A shadow hypervisor is created in advance as a backup copy of the primary hypervisor. This shadow hypervisor is maintained ready on a different node, so when the primary hypervisor node needs to be removed for maintenance or has failed, the shadow hypervisor is already prepared and can immediately take over, ensuring continuous operation of guest operating systems without interruption.
Solution Approach 2:
The cache controller acts as an intermediary between guest operating systems and the hypervisor. It intercepts hypervisor access requests (HARs) from guest OSes and automatically redirects them to the shadow hypervisor when the primary hypervisor is unavailable. This intermediary mechanism transparently handles the failover without requiring changes to guest OS code or awareness of the hypervisor relocation.
2Device complexity
If the hypervisor is hosted on a single node, then system结构简单性 is maintained, but the system lacks flexibility for node removal and failover
Solution Approach 1:
Instead of hosting the hypervisor on a single node, the system creates a copy of the hypervisor (shadow hypervisor) on a different node. This copying approach maintains the simplicity of having a single active hypervisor while providing the adaptability to remove or fail the primary node, as the shadow copy is ready to take over. The shadow hypervisor is an exact functional copy that can seamlessly replace the primary.
Solution Approach 2:
The system implements dynamic hypervisor relocation where the active hypervisor role can switch between the primary and shadow hypervisors based on node availability. The cache controller dynamically intercepts and redirects hypervisor access requests based on the current state of the system, allowing flexible node removal and failover without requiring system reconfiguration or changes to guest operating systems.
3Ease of operation
If hypervisor access requests are intercepted and node ID bits are modified to redirect to shadow hypervisor, then transparent failover is achieved, but additional processing steps are introduced
Solution Approach 1:
The cache controller automatically performs the interception and redirection of hypervisor access requests without requiring external intervention or complex coordination. When a HAR is detected, the cache controller self-service handles the node ID bit modification and redirects the request to the shadow hypervisor node. This self-service mechanism simplifies the overall system operation by embedding the failover logic directly in the cache controller, eliminating the need for separate failover management systems.
Data Source
AI summary
A method for managing multiple nodes hosting multiple memory segments, including: identifying a failure of a first node hosting a first memory segment storing a hypervisor; identifying a second memory segment storing a shadow of the hypervisor and hosted by a second node; intercepting, after the failure, a hypervisor access request (HAR) generated by a core of a third node and comprising a physical memory address comprising multiple node identification (ID) bits identifying the first node; modifying the multiple node ID bits of the physical memory address to identify the second node; and accessing a location in the shadow of the hypervisor specified by the physical address of the HAR after the multiple node ID bits are modified.