Hyper-V Live Migration FAQ

Updated: May 26, 2010

Applies To: Windows Server 2008 R2

This article provides answers to common questions about the live migration feature of Hyper-V™ in Windows Server® 2008 R2.

What is live migration?

What are the requirements for using live migration?

How do you initiate a live migration?

How many network adapters are required to use live migration?

Are Cluster Shared Volumes required to use live migration?

How long does it take to move a virtual machine using live migration?

Does live migration support moving a virtual machine to a physical computer with a different processor?

Does live migration support TCP Offload (Chimney)?

Can you initiate more than one live migration at a time?

Can you back up a migrating virtual machine?

When should you refresh configuration changes you made to a virtual machine?

Are all virtual switch names required to be the same to support live migration?

When using CSV with Hyper-V, do you have to boot from the same drive letter?

Live migration is a Hyper-V feature in Windows Server 2008 R2, which requires the failover clustering feature to be added and configured on the servers running Hyper-V. Live migration allows you to transparently move running virtual machines from one node of the failover cluster to another node in the same cluster without a dropped network connection or perceived downtime. In addition, failover clustering requires shared storage for the cluster nodes. This can include an iSCSI or Fiber-Channel Storage Area Network (SAN). All virtual machines are stored in the shared storage area, and the running virtual machine state is managed by one of the nodes. For a detailed overview of live migration and the benefits of using it, see Windows Server 2008 R2 & Microsoft Hyper-V Server 2008 R2 - Hyper-V Live Migration Overview & Architecture.

  • All the servers in a failover cluster must either run the x64-based version or the Itanium architecture-based version of Windows Server 2008 R2 (nodes within a single failover cluster cannot run different versions).

  • All the servers should have the same software updates (patches) and service packs.

  • Windows Server® 2008 R2 Enterprise or Windows Server® 2008 R2 Datacenter must be used for the physical computers. These servers must run the same version of Windows Server 2008 R2, including the same type of installation. That is, both servers must be either a full installation or a Server Core installation.

  • Configure all physical hosts that will use live migration with failover clustering, which supports up to 16 nodes per cluster.

  • Configure the cluster with a dedicated network for live migration traffic.

  • Configure physical hosts on the same TCP/IP subnet.

  • Provide shared storage access to all physical hosts.

You can initiate a live migration using any of the following methods:

For each node of the failover cluster, use more than one network adapter and configure at least one network adapter for the private network. We recommend that you configure separate dedicated networks with gigabit or faster speed for live migration traffic and cluster communication, and these networks should be separate from the network used by the management operating system, and from the network used by the virtual machines. For information on network settings required for live migration, see Hyper-V: Live Migration Network Configuration Guide.

Cluster Shared Volumes are not required to perform a live migration. You should be aware that using Cluster Shared Volumes simplifies the configuration and management of clustered virtual machines. With Cluster Shared Volumes, multiple clustered virtual machines can use the same LUN (disk) while still being able to fail over (or move from node to node) independently of one another.

The amount of time is dependent on the following items:

  • The network connection speed and bandwidth that is available between the source cluster node and the destination cluster node.

  • The load on the source cluster node and the destination cluster node.

  • The amount of RAM configured for the virtual machine.

If you are using different processor versions on the nodes in the cluster, live migration may fail. To perform a live migration of a virtual machine to another physical computer with a different processor, you must first select the Migrate to a physical computer with a different processor version setting in Hyper-V Manager. This setting ensures that the virtual machine uses only the features of the processor that are available on all versions of a virtualization-capable processor by the same processor manufacturer. It does not provide compatibility between different processor manufacturers. This allows you to move a running virtual machine to a physical computer with different processor features without restarting the virtual machine.

Yes, when performing a live migration, the TCP stack on the device is moved back into the software stack within the virtual machine. If the cluster node to which the virtual machine in migrating also supports TCP Offload, then this capability will be utilized once the migration is complete.

Yes, depending on the number of nodes in the failover cluster, you may be able to use live migration to move more than one virtual machine at a time. Keep in mind that a cluster node can participate as the source or destination node in only one live migration at a time. For example, if there are 4 nodes in the failover cluster, then two live migrations can occur at the same time.

You can also use Virtual Machine Manager’s maintenance mode to use live migration to evacuate all virtual machines to other hosts on the same cluster. For more information, see About Maintenance Mode.

Yes. Because live migration is a transition state, the Hyper-V VSS writer waits for the migration to complete before continuing with backup. However, once migration is complete, the virtual machine is no longer on the cluster node on which backup occurs. At this stage, backup continues and correctly backs up the files (it can still access the files on the CSV volume), but it is only a file copy. The VSS writer does not perform the steps that it usually would for an online backup. You should be aware that the VSS writer does not return a failure error code to VSS, and therefore, does not log any errors. However, it does log two warning messages that the virtual machine is not found.

When the Hyper-V VSS writer performs a backup in a failover cluster that uses CSV, and the backup fails or is canceled, CSV continues in a redirected I/O mode. This causes the I/O performance of all of the cluster nodes to suffer.

If you change the configuration of a virtual machine, we recommend that you use the Failover Cluster Manager snap-in to access the virtual machine settings. When you do this, the cluster is updated automatically with the configuration changes. However, if you make changes to the virtual machine settings from the Hyper-V Manager snap-in, you must update the cluster manually after you make the changes. If the configuration is not refreshed after networking or storage changes are made, a subsequent failover may not succeed or may succeed but result in the virtual machine being configured incorrectly.

Yes, you should make sure that all virtual switch names are the same across the entire cluster.

When using Hyper-V with Cluster Shared Volumes, in order for virtual machines to migrate or fail over properly, the operating system (%SystemDrive%) of each server in your cluster must be set so that it boots from the same drive letter as all other servers in the cluster. In other words, if one server boots from drive letter C, all servers in the cluster should boot from drive letter C.

Community Additions