VM Persistent Data Migration via Mirrored IOs
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing techniques for live migration of virtual machine persistent data, such as those using redo logs, face issues with increased vulnerability due to reliance on two data stores and potential for significant downtime caused by large redo logs during the migration process.
Innovation Solution
The method employs mirrored input-output operations (IOs) to migrate persistent data between data stores, selectively mirroring write IOs and prioritizing data block copying based on activity levels, allowing for an atomic switchover without downtime.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If redo logs are used to store copies of changed blocks during migration, then persistent data can be migrated between data stores with minimal disruption, but the virtual machine becomes vulnerable to failure due to relying on two different data stores simultaneously
Solution Approach 1:
The migration process is divided into distinct phases: initial copy phase where data is copied to destination, and final switch phase where the VM is briefly paused and switched to use only the destination data store. This segmentation ensures that at no point does the VM rely on two data stores simultaneously, eliminating the failure vulnerability while maintaining migration reliability.
Solution Approach 2:
The complete copy of persistent data to the destination data store is performed in advance before the VM needs to switch. By preparing the destination data store fully beforehand and using a brief pause to atomically switch pointers, the system avoids the need to maintain simultaneous access to both data stores, thus eliminating the vulnerability to dual-data-store failures.
2Manufacturing precision
If redo logs are used to track changed blocks during migration, then data consistency can be maintained, but storage capacity is consumed and migration time increases due to large redo log sizes
Solution Approach 1:
The patent extracts and eliminates the redo log mechanism entirely from the migration process. Instead of using redo logs to track and replay changed blocks, the system performs a direct copy of the persistent data to the destination data store followed by an atomic switch. This removes the time-consuming redo log generation, storage, and merging operations, significantly reducing migration time while maintaining data consistency through the atomic switch mechanism.
3Manufacturing precision
If redo logs are merged with initial copy while VM is paused, then data consistency is achieved, but VM downtime increases due to large redo log merge operations
Solution Approach 1:
The patent removes the redo log merging step entirely from the migration process. By eliminating redo logs, there is no merging operation required. The data consistency is achieved through the atomic switch of data store pointers after the destination data store has been fully copied, reducing VM downtime to only the brief pause required for the pointer switch rather than the extensive time needed for large redo log merges.
Solution Approach 2:
The complete copy operation is performed in advance before the VM needs to be paused. By the time the VM is paused for the final switch, the destination data store already contains all necessary data, and no further merging or synchronization operations are needed during or after the pause. This preliminary completion of the copy eliminates post-pause merge operations that would extend downtime.
Data Source
AI summary
Persistent data, such as disks associated with virtual machines, are migrated between and across data stores using mirrored input-output operations (IOs). The migration technique employs a data mover to copy selected regions of the virtual machine disk to a target data store while the virtual machine is executing. If the virtual machine issues a write IO, the write IO is selectively mirrored on the target data store depending on whether or not the write IO is in a region of the virtual machine disk that has already been copied.