Your Virtualization Community: Optimize the performance of your virtual environment.
Live migration provides the capability to move a virtual machine (VM) from one node in a Microsoft® Windows Server® 2008 R2 failover cluster to another node without a perceived interruption in service by applications/clients connecting to the VM.
The process for live migration is comprised of the following high-level steps: A live migration between two nodes (source and target) within the same failover cluster is requested. A new VM is created on the target server. The initial memory state is copied from the source VM to the target VM over the live migration network. Any memory pages that were changed during the copy process (dirty pages) are marked, and the pages are copied over as well. This iterative process continues until the number of pages is relatively small. The VM is paused on the source node, and the state of the VM is copied to the target node. The VM is resumed on the target node, the VM on the source is removed, and an ARP is issued to update routing tables.
A user can request a live migration by utilizing any of the following methods/interfaces: Failover Cluster Manager interface Programatically through Windows Management Instrumentation (WMI) Programatically through a PowerShell script Microsoft System Center Virtual Machine Manager 2008 R2 A user can explicitly request migration on a per-VM basis. It can automatically occur when a user requests to place a node in a Failover Cluster into Maintenance mode. It can occur based on a PRO Tip (automatically or with acceptance based on PRO Tip settings).
Live migration times can vary widely based on several factors. The primary factors that affect the migration time are the following: The amount of memory assigned to the VM The rate of change of the VM memory—the number of pages being dirtied during the initial copy process The available bandwidth of the live migration network
Yes, when migration is requested, the TCP stack on the device is pushed back into the software stack within the VM. If the target node also supports an advanced networking feature, then that capability can be utilized after the migration process is complete.
By default, live migration traffic will occur over a private network (those without a gateway defined). However, unless explicitly deselected in the Failover Cluster Manager, live migration traffic can flow over public networks.
*Dell recommends that two separate private networks are created in the cluster to provide a redundant live migration path. In addition, public networks should be removed from the list of available networks for Live Migration.
If you have more than one processor family utilized by the nodes of your cluster, then live migration may fail with the default settings. To allow live migration to succeed, each VM must have a processor migration compatibility setting enabled. This setting can only be changed when the VM is powered off.
No, CSVs are not required to support live migration; however, the capabilities provided with CSVs make it very compelling to implement them with any R2 implementation that is targeting to utilize live migration.