Virtualized Background Task Handling Across Unavailable Partitions
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Virtualization layers can interfere with the execution of background tasks in virtualization partitions (VPs), causing guest applications to fail to perform as intended when the VP is rendered unavailable.
Innovation Solution
A virtualization layer executes a background task service that registers and manages background tasks outside the VP, ensuring the VP's availability through communication with the virtualization layer to maintain execution, even if the VP becomes unavailable.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Productivity
If the virtualization layer manipulates the VP to save resources or manage workload (pause, low-power mode, deletion), then resource utilization and system control are improved, but the guest application's expected behavior and reliability deteriorate
Solution Approach 1:
The patent introduces a background task service as an intermediary layer between the virtualization layer and guest applications. This service runs outside the VP but manages background tasks that need to execute regardless of VP availability. When a background task is triggered, the service can migrate it to another VP or maintain it in a dedicated environment, ensuring the task completes even if the original VP is paused, deleted, or placed in low-power mode. This resolves the contradiction by decoupling task execution reliability from VP availability while allowing the virtualization layer to freely manage VP resources.
2Ease of operation
If the VP is paused or rendered unavailable, then system control and resource management are improved, but background task execution and alarm firing fail
Solution Approach 1:
The patent implements preliminary action by having the background task service register and prepare background tasks before the VP becomes unavailable. The service maintains a registry of background tasks with their triggers and execution requirements. When a trigger event occurs (such as an alarm time or incoming message), the service has already prepared the task for execution and can immediately migrate or activate it in another VP without waiting for the original VP to become available. This ensures background tasks execute reliably even when the virtualization layer pauses or manages VP availability dynamically.
3Productivity
If the virtualization layer deletes or starves the VP of processor time, then resource optimization and system efficiency are improved, but the guest application cannot respond to external events
Solution Approach 1:
The background task service acts as an intermediary that receives external events (messages, notifications, alarm triggers) and manages their delivery to guest applications independently of VP availability. When an external event occurs, the service can migrate the background task to another VP or maintain it in a dedicated execution environment, ensuring the application responds to external events even when the original VP is deleted or starved of processor time. This resolves the contradiction by separating event handling from VP lifecycle management while allowing aggressive resource optimization.
Data Source
Figure 1
Figure 2
Figure 3
AI summary
A virtualization partition (VP) is executed by a virtualization layer. The VP contains guest software that executes in isolation within the VP. The guest software has a background task (BT) that needs to be performed in the future. The BT is virtualized by a BT service that executes outside of the VP. The guest software registers the BT, through the virtualization layer, with a BT virtualization service. An event occurs outside of the VP that triggers the BT. The BT virtualization service responds to the event by assuring that the VP is available (executing), and optionally triggers (possibly indirectly) the execution of code in the application.