Guest OS Live Migration Using Fake I/O for Pending Requests
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing live migration technologies for virtual machines (VMs) face significant downtime due to unpredictable and lengthy completion times for uncompleted I/O requests, which cannot be canceled, leading to increased migration duration and reduced predictability.
Innovation Solution
The method involves interrupting the guest OS execution on the source server, transferring its state to the target server, creating fake I/O requests for pending requests, and resuming execution without waiting for their completion, allowing the target server to generate new I/O requests while the source completes them, with the target server completing fake requests upon notification from the source.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If the guest OS execution is stopped on the source server and I/O requests are waited for completion before migration, then data consistency is ensured, but downtime increases significantly and becomes unpredictable
Solution Approach 1:
The system performs preliminary actions by capturing the state of pending I/O requests before migration and transferring this state information to the target server. This allows the target server to prepare and manage I/O requests in advance, eliminating the need to wait for source server completion while maintaining data consistency through state tracking.
Solution Approach 2:
The patent introduces an intermediary mechanism where the hypervisor captures and tracks the state of pending I/O requests as a mediator between the source and target servers. This state information acts as a bridge, allowing the target server to resume I/O operations without waiting for source completion, thus reducing downtime while ensuring consistency.
2Reliability
If the hypervisor waits for completion of all pending I/O requests before transferring guest OS state, then data integrity is maintained, but migration time increases and predictability decreases
Solution Approach 1:
The patent segments the I/O request handling into two independent parts: capturing the state of pending requests before migration and managing their completion separately at the target server. This segmentation allows the migration process to proceed independently from I/O completion, improving both speed and predictability while maintaining integrity through state tracking.
Solution Approach 2:
The hypervisor performs preliminary capture of pending I/O request states before the actual migration transfer. This preliminary action enables the target server to receive and manage I/O requests independently, decoupling migration time from I/O completion time, thereby increasing migration speed and predictability without sacrificing data integrity.
3Loss of time
If the guest OS is restarted on the target server before pending I/O requests are completed, then migration downtime is reduced, but I/O request completion coordination becomes complex
Solution Approach 1:
The patent implements a feedback mechanism where the hypervisor tracks the completion status of I/O requests and provides feedback to the target server. This feedback loop allows the target server to coordinate I/O request completion with the restarted guest OS, managing complexity through structured communication while minimizing migration downtime.
Solution Approach 2:
The hypervisor acts as an intermediary that manages the complexity of I/O coordination by capturing request states and facilitating their completion at the target server. This intermediary role simplifies the coordination process while enabling rapid restart of the guest OS, thereby reducing downtime without excessive complexity.
Data Source
AI summary
Disclosed herein are systems and method for live migration of a guest OS from a source computing device to a target computing device, the method comprising: interrupting execution of the guest OS in a hypervisor on the source computing device, transferring a state of the guest OS to a hypervisor on the target computing device, creating fake I/O requests corresponding to pending I/O requests, resuming execution of the guest OS in the hypervisor on the target computing device without waiting for completion of the pending I/O requests on the source computing device, for each of the pending I/O requests, sending, by the source computing device, a notification about completion of the pending I/O request, and for each pending I/O request for which the notification about completion is received, completing, by the hypervisor on the target computing device, a fake I/O request corresponding to the pending I/O request.