Live Migration in Windows Server 2008 R2 Hyper-V

by [Published on 5 May 2009 / Last Updated on 5 May 2009]

Taking a look at the Live Migration feature included in Windows Server 2008 R2 Hyper-V.

Introduction

In this article, you will learn about the much anticipated Live Migration feature that is included in Windows Server 2008 R2 Hyper-V. The Live Migration feature allows you to move a virtual machine between two Hyper-V server failover cluster nodes without data loss and without service interruption.

Live Migration Feature in Microsoft Windows Server 2008 R2 Hyper-V

Microsoft Windows Server 2008 R2 Hyper-V is the much awaited follow-up to the Microsoft Windows Server 2008 Hyper-V release. In this latest version of the Windows Server 2008 operating system, several new features have been added to the Hyper-V technology, but the most anticipated is the Live Migration feature.

The Windows Server 2008 R2 Hyper-V Live Migration feature provides you with two main benefits. First, Live Migration allows you to implement a high-availability solution based on Failover Clustering for mission-critical applications running in virtual machines, without the requirement for either a cluster-aware guest operating system or application. In addition, Live Migration provides the ability for System Center Virtual Machine Manager 2008 R2 (a Beta version is available for download from Microsoft) to provide dynamic load balancing of virtual machines, also without data loss or service interruption.

Hyper-V Live Migration Feature Requirements

In order to use Live Migration successfully, you must ensure that your Windows Server 2008 R2 Hyper-V failover cluster meets the following requirements:

  • Hyper-V failover cluster nodes must use processors from the same manufacturer and of the same type. Therefore, you cannot use Live Migration to move a virtual machine running on an AMD-V platform to an Intel VT platform.
  • Hyper-V failover cluster nodes must be configured on the same TCP/IP subnet. Although the Windows Server 2008 and Windows Server 2008 R2 Failover Cluster feature does not require that cluster nodes are configured on the same TCP/IP subnet, this is a required configuration to use Live Migration.
  • Hyper-V failover cluster nodes must have access to shared storage. The shared storage options are the same ones that are supported in Windows Server 2008 Hyper-V, and include iSCSI-based devices as well as storage area network (SAN) devices.

A Live Migration of a virtual machine can be started from the Windows Server 2008 R2 Failover Cluster Manager or through System Center Virtual Machine Manager 2008 R2 if it is used to manage the failover cluster nodes. You can also initiate a Live Migration using a Windows Management Instrumentation (WMI) or PowerShell script.

Live Migration Process

The process that takes place during a Live Migration starts with a TCP connection from the Hyper-V failover cluster source node (where the target virtual machine is initially executing) to a selected destination node in the same Hyper-V failover cluster. The TCP connection is established to transfer the virtual machine configuration data from the source node to the destination node, and the data is used to create a new virtual machine with identical settings on the destination node. The virtual machine configuration data includes the number and type of virtual storage adapters, virtual network adapters, virtual processor and memory allocations, and other required virtual machine configuration parameters.

The next step after the virtual machine is created on the destination node is the transfer of virtual machine memory pages from the source node to the destination node. This is an iterative process since the virtual machine continues to execute on the source node as the memory data is transferred to the destination node. In order to ensure that data is not lost, Hyper-V tracks all modifications to the memory pages on the source node and continues to transfer the memory pages to the destination node until an iteration threshold is reached or all modified memory pages are copied successfully to the destination node.

Then, the virtual machine is paused on the source node, remaining modified memory pages are copied to the destination node, and the processor register and device state is transferred from the source node to the destination node. At this stage, the Live Migration process can no longer be cancelled.

During the short period of time when the virtual machine is paused, the virtual machine storage control, including virtual hard disks and pass-through disks, is also assigned to the destination node. At this point, the virtual machine is in a consistent state and resumes execution on the destination node.

The next step in the process is to force the physical network switches to update their tables with the new port to direct the network traffic for the virtual machine. The new port is the physical network switch port that connects the destination node to the physical network. Finally, the virtual machine information is removed from the source node.

Live Migration Considerations

The time frame that the virtual machine pauses during Live Migration is minimized to avoid exceeding application and TCP network connection timeout values that could result in a service interruption. Therefore, it is crucial to fully understand and test the configuration of any Hyper-V failover cluster that will support Live Migration. In particular, you should use high-speed network connection links, with a minimum of 1 Gbps Ethernet, to optimize the memory and state data transfers between the source and destination nodes. Additionally, you must be aware that a Live Migration is not an instantaneous event, and that the amount of time needed to complete the migration process is dependent on several parameters:

  • Large virtual machine memory size increases the time it takes to complete a live migration, since more active memory pages have to be transferred between the source and destination cluster nodes.
  • High virtual machine activity level increases the potential for more memory page modifications that result in additional iterations to create a consistent memory state on the destination node.
  • High utilization rates on the source and destination nodes extend the time frame required to complete the live migration process.
  • High-speed network bandwidth and throughput decrease the amount of time required to transfer the virtual machine memory page and state information between the source node and the destination node.
  • The transfer of a logical unit number (LUN) between the source and destination node also affects the migration timeline. It is possible to reduce the impact of this process by using the new Cluster Shared Volumes (CSV) feature in Windows Server 2008 R2.

Although not a requirement, if you want to optimize the shared storage configuration of a Hyper-V Failover Cluster to support Live Migration, you should implement Cluster Shared Volumes. You should also take into consideration that each Hyper-V failover cluster node can take part only as the source or destination in a single live migration at a time. Therefore, in a fully expanded, 16-node failover cluster, you can only perform a maximum of eight concurrent Live Migrations.

Cluster Shared Volumes

Up until Windows Server 2008 R2, only a single failover cluster node was allowed to have ownership of a LUN and access to the data stored on it. In contrast, the new Cluster Shared Volumes feature in Windows Server 2008 R2 allows multiple cluster nodes to concurrently access a LUN on a shared storage system while providing a consistent file namespace to all cluster nodes. Therefore, to a virtual machine, attached VHDs appear as if stored on an individual LUN. However, all virtual machine VHDs can reside on a single LUN, and every cluster node can have access to the volumes using the same fully qualified path. By default, Cluster Shared Volumes are created as directories beneath a root folder named ClusterStorage. However, you can modify the root folder name as required in your environment.

Some of the other benefits that Cluster Shared Volumes provide are: NTFS compatibility (no requirement to reformat disk media), support of SAN or iSCSI-connected storage systems, and elimination of drive letter limitations that are encountered with Windows Server 2008 Hyper-V.

Conclusion

If you are designing a virtualization infrastructure with the requirement to dynamically move virtual machines without data loss or service interruption, you should download Windows Server 2008 R2 Hyper-V, and begin to learn and test the new Live Migration feature.

Featured Links