Hypervisor Surprise Removal Using Guest Capability Indicators

Resolve Bottlenecks,
Find Innovative SolutionsGenerate Solutions

Solution Overview

Problem

In virtualized computer systems, the removal of virtual devices from guest operating systems can be time-consuming due to the need for explicit acknowledgment from the guest OS, which may be slow or unstable, leading to potential data loss or system crashes during surprise removal.

Innovation Solution

Implementing guest-driven surprise removal by allowing the guest OS to pre-emptively notify the hypervisor of its ability to recover from device removal, enabling the hypervisor to unmap virtual devices without waiting for acknowledgment, thus reducing the time required for device removal and facilitating quick resource reallocation.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If the hypervisor waits for explicit acknowledgment from the guest OS before removing a virtual device, then data loss is prevented, but the device removal time increases significantly

Engineering Contradiction:

Improvedata loss preventionVSAvoiddevice removal time

Core Design Contradiction:

ReliabilityVSLoss of time

Solution Approach 1:

The guest OS performs preliminary actions by proactively notifying the hypervisor of its readiness for device removal before the actual removal occurs. This allows the hypervisor to proceed with removal without waiting for post-removal acknowledgments, thus reducing device removal time while maintaining data safety through pre-confirmation of guest OS readiness.

Inventive Principle:

Principle #10Preliminary action

2Reliability

If the guest OS is slow or unstable in providing acknowledgment, then system reliability decreases, but the device removal process becomes even more time-consuming

Engineering Contradiction:

Improvesystem stabilityVSAvoiddevice removal speed

Core Design Contradiction:

ReliabilityVSProductivity

Solution Approach 1:

Instead of the hypervisor waiting for the guest OS to provide acknowledgment after removal preparation, the approach is inverted: the guest OS is expected to proactively notify the hypervisor of its readiness for removal. This shifts the initiative from the hypervisor to the guest OS, allowing the process to continue even if the guest OS is slow or unstable, thereby improving both reliability and productivity.

Inventive Principle:

Principle #13The other way round (Inversion)

3Productivity

If surprise removal is implemented without acknowledgment, then device removal speed increases, but the risk of guest OS errors and data loss increases

Engineering Contradiction:

Improvedevice removal speedVSAvoidguest OS stability

Core Design Contradiction:

ProductivityVSReliability

Solution Approach 1:

The guest OS performs preliminary notification to the hypervisor indicating its readiness for device removal before the actual removal takes place. This preliminary action establishes a safety mechanism that allows fast removal while maintaining reliability, as the guest OS has already confirmed its ability to handle the removal without errors or data loss.

Inventive Principle:

Principle #10Preliminary action

Data Source

PatentUS10394586B2Using capability indicators to indicate support for guest driven surprise removal of virtual PCI devices

Publication Date: 2019.08.27 RED HAT ISRAEL

AI summary

A hypervisor receives a notification from a guest operating system of a virtual machine that includes a capability indicator of support provided by a virtual device driver for recovering from a surprise removal of a corresponding virtual device from the virtual machine. The hypervisor, upon receiving a request to remove the virtual device from the virtual machine, uses the capability indicator received from the guest operating system to identify one or more actions to be performed to remove the virtual device from the virtual machine. The hypervisor then removes the virtual device from the virtual machine using the identified actions.