The following recommendations will help you configure your networking environment for using live migration:

• Network adapters. For each node of the failover cluster: use more than one network adapter; configure at least one network adapter for the private virtual network. We recommend that you configure a dedicated private network with Gigabit speed for live migration traffic. This network should be separate from the network for managing the failover cluster, from the network for the virtual machine, and from the network for storage.
  
  
• It is recommended that you do not use the same network adapter for virtual machine access and management. If you are limited by the number of network adapters, you should configure a virtual local area network (VLAN) to isolate traffic. VLAN recommendations include 802.1q and 802.p.
  
  
• Hardware and system settings. It is recommended that you make the hardware and system settings of the nodes in the failover cluster as similar as possible to minimize potential problems.
  
  
• Security policies. If possible, do not apply IPSec policies on a private network for live migration because this can significantly impact the performance of live migration.
  
  
• IP subnet configuration. Ensure that the source and destination nodes (for the live migration) in the failover cluster are connected through the same IP subnet. This is so the virtual machine can retain the same IP address after live migration.
  
  
• For storage network recommendations, you should review the guidelines provided by your storage vendor.
  
  

Hyper-V provides processor compatibility settings to make it easier to perform a live migration of a virtual machine to another physical computer with a different processor version. The Migrate to a physical computer with a different processor version setting in Hyper-V Manager allows you to move a running virtual machine to a physical computer with different processor features without restarting the virtual machine. It is recommended that you enable this setting in Hyper-V Manager to ensure 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. When this setting is not used, Hyper-V provides the virtual machine with all the virtualization features offered by the physical processor. The setting is also useful for high availability and backup and recovery scenarios because it makes it easier to move a highly available virtual machine to another node in a cluster or restore the virtual machine to different hardware.

Cluster Shared Volumes are volumes in a failover cluster that multiple nodes can read from and write to at the same time. The nodes coordinate the reading and writing activity so that the disk is not corrupted. In contrast, disks (LUNs) in cluster storage that are not Cluster Shared Volumes are always owned by a single node. Cluster Shared Volumes have the same requirements as non-Cluster Shared Volumes disk resources. The storage location in the Cluster Shared Volumes is under SystemRoot/ClusterStorage. When creating the virtual machine, we recommend that you use this storage location.

It is recommended that you first validate the cluster configuration before configuring Cluster Shared Volumes. For more information about how to validate a cluster configuration, see the Failover Cluster Step-by-Step Guide: Validating Hardware for a Failover Cluster and The Microsoft Support Policy for Windows Server 2008 Failover Clusters.

Note

The network connection that is used by Cluster Shared Volumes is fault tolerant; therefore, if the network that is used by Cluster Shared Volumes experiences problems, network traffic will be moved to another network. Cluster Shared Volumes can only be enabled once per cluster. By enabling Cluster Shared Volumes for a failover cluster, all nodes in the cluster will be enabled to use shared volumes.

1. In the Failover Cluster Manager snap-in, if the cluster that you want to configure is not displayed, in the console tree, right-click Failover Cluster Manager, click Manage a Cluster, and then select or specify the cluster that you want.

2. Right-click the failover cluster, and then click Enable Cluster Shared Volumes. Or, under Configure (center pane), click Enable Cluster Shared Volumes. The Enable Cluster Shared Volumes dialog box opens. Read and accept the terms and restrictions, and click OK.

1. In the Failover Cluster Manager snap-in, if the cluster that you want to configure is not displayed, in the console tree, right-click Failover Cluster Manager, click Manage a Cluster, and then select or specify the cluster that you want.

2. If the console tree is collapsed, expand the tree under the cluster that you want to add a disk to the Cluster Shared Volumes.

3. Click Cluster Shared Volumes.

4. Under Actions (on the right), click Add storage.

5. In Add Storage, select from the list of available disks, and click OK. The disk or disks you selected appear in the Results pane for Cluster Shared Volumes.

The storage location appears as SystemRoot\ClusterStorage (which you can rename) on all nodes of the failover cluster. Under SystemRoot\ClusterStorage, a specific folder appears for each volume on the disk (or disks) that was added to the Cluster Shared Volumes. You can view the list of volumes in Failover Cluster Manager.

To set up a virtual machine for live migration, you need to do the following:

1. Create the virtual machine
   
   
2. Configure the virtual machine to use Cluster Shared Volumes
   
   
3. Reconfigure the automatic start action on the virtual machine
   
   
4. Make the virtual machine highly available
   
   

For information about how to perform these procedures, see Steps 6 and 7 in Hyper-V Step-by-Step Guide: Hyper-V and Failover Clustering.

Note
When creating the virtual machine, we recommend that you configure the storage location under SystemRoot/ClusterStorage in the Cluster Shared Volumes.

Cluster networks are automatically configured for live migration. You can use Failover Cluster Manager to perform this procedure.

1. In the Failover Cluster Manager snap-in, if the cluster that you want to configure is not displayed, in the console tree, right-click Failover Cluster Manager, click Manage a Cluster, and then select or specify the cluster that you want.

2. Expand Services and applications.

3. In the console tree (on the left), select the clustered virtual machine for which you want to configure the network for live migration.

4. Right-click the virtual machine resource displayed in the center pane (not on the left), and then click Properties.

5. Click the Network for live migration tab, and select one or more cluster networks to use for live migration. Use the buttons on the right to move the cluster networks up or down to ensure that a private cluster network is the most preferred. The default preference order is as follows: networks that have no default gateway should be located first; networks that are used by cluster shared volumes and cluster traffic should be located last.

   Live migration will be attempted in the order of the networks specified in the list of cluster networks. If the connection to the destination node using the first network is not successful, the next network in the list is used until the complete list is exhausted, or there is a successful connection to the destination node using one of the networks.

   Note
   When you configure a network for live migration for a specific virtual machine, the setting is global and therefore applies to all virtual machines. If you have more than one cluster network listed in Network for live migration, you should change the priority order to avoid having live migration and Cluster Shared Volumes use the same network.

You can use either Failover Cluster Manager or PowerShell to initiate live migration to move a virtual machine from one node to another node in a failover cluster.

Note

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. However, 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. When you use PowerShell to initiate a live migration of a virtual machine, then more than one live migration can occur at a time. If live migration fails, the virtual machine continues to operate on the source node with no disruption.

The amount of time it takes to move a virtual machine using live migration 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.
  
  

1. In the Failover Cluster Manager snap-in, if the cluster that you want to configure is not displayed, in the console tree, right-click Failover Cluster Manager, click Manage a Cluster, and then select or specify the cluster that you want.

2. Expand Nodes.

3. In the console tree (on the left), select the node under which you want to move a clustered virtual machine using live migration.

4. Right-click the virtual machine resource displayed in the center pane (not on the left), and then click Live migrate virtual machine to another node.

5. Select the node that you want to move the virtual machine to. When migration is complete, the virtual machine is running on the new node.

6. To verify that the virtual machine successfully migrated, you will see the virtual machine listed under the new node (in Current Owner).

1. Open PowerShell. Click Start, point to All Programs, click Windows Powershell 2.0, and then click Windows Powershell 2.0.

   The Failover Clustering feature must be installed on the computer on which you are starting the PowerShell session.

2. To install the Failover Clustering feature, type:

   Add-Module FailoverClusters

3. Type:

   Get-Cluster “<Cluster Name>” | Move-ClusterVirtualMachineRole -Name “<VM group name>” -Node “<Destination node name>”

   Where:

   • <Cluster Name> is the name of the cluster that the virtual machine is included in.
     
     
   • <VM group name> is the virtual machine resource group.
     
     
   • <Destination node name> is the name of the destination node to which you would like to move the virtual machine using live migration.
     
     

The following list covers some common live migration troubleshooting issues.

• If you initiate a second live migration before the clean-up of the first migration is complete, the second migration may fail. You should wait for several seconds before initiating the second migration.
  
  
• If a cluster service is restarted, or a virtual machine is moved and hosted by a new RHS.exe process, the network that is used for the migration needs time to initialize. It may take up to 30 seconds for the network to be ready. If you initiate a live migration during this time, it will fail with the error “no migration network available”.
  
  
• You should avoid taking a snapshot of a running virtual machine. If you revert back to a snapshot of a running virtual machine, the memory state is restored in addition to the disk. Before reverting a clustered virtual machine back to a snapshot, you should first shut down the virtual machine from Failover Cluster Manager, take a snapshot of the virtual machine, and restart the virtual machine.
  
  

To help diagnose troubleshooting issues, you can retrieve Hyper-V and cluster event log information.

• To enable the high availability analytic log, type the following command at a command prompt:
  
  Wevtutil sl Microsoft-Windows-Hyper-V-High-Availability-Analytic /e:true /q
  
  
• To retrieve information from the log, type the following command at a command prompt:
  
  Wevtutil epl query.txt /sq:true <logname>.evtx
  
  Query.txt code:
  
  
  Copy Code

  	<QueryList>  <Query Id="0" Path="System">    <Select Path="System">*[System[Provider[@Name='Microsoft-Windows-Hyper-V-Hypervisor']]]</Select>    <Select Path="Microsoft-Windows-Hyper-V-Config-Admin">*</Select>    <Select Path="Microsoft-Windows-Hyper-V-High-Availability-Admin">*</Select>    <Select Path="Microsoft-Windows-Hyper-V-High-Availability-Analytic">*</Select>    <Select Path="Microsoft-Windows-Hyper-V-Hypervisor-Admin">*</Select>    <Select Path="Microsoft-Windows-Hyper-V-Integration-Admin">*</Select>    <Select Path="Microsoft-Windows-Hyper-V-Network-Admin">*</Select>    <Select Path="Microsoft-Windows-Hyper-V-SynthStor-Admin">*</Select>    <Select Path="Microsoft-Windows-Hyper-V-SynthNic-Admin">*</Select>    <Select Path="Microsoft-Windows-Hyper-V-Image-Management-Service-Admin">*</Select>    <Select Path="Microsoft-Windows-Hyper-V-VMMS-Admin">*</Select>    <Select Path="Microsoft-Windows-Hyper-V-Worker-Admin">*</Select>  </Query></QueryList>
  	

• To retrieve information from cluster event logs, run the following to retrieve the logs from all nodes in the cluster:
  
  Cluster.exe log /g /copy:<logdir>
  
  

The amount of time that it takes for a live migration to complete depends on the size of the virtual machine being migrated. The migration transfers the virtual machine memory to the destination node over the network, and the amount of time needed is proportional to the size of the virtual machine. During the migration process, the virtual machine continues running. However, once all the virtual machine memory is transferred, the virtual machine is not running because it pauses, moves, and resumes on the destination node. Maintaining a TCP connection during this period of blackout is the goal of live migration. To achieve this, we recommend using Cluster Shared Volumes and a dedicated private network for live migration. If, despite using these recommendations, you still experience TCP connection drops, you can enable traces to collect performance data which will identify the feature or operation that is consuming too much time.

1. Enable the performance tracing registry key by typing the following command at a command prompt:

   reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Virtualization" /v EnablePerformanceTracing /t REG_DWORD /d 1 /f

2. Enable the high availability analytic log by typing the following command at a command prompt:

   Wevtutil sl Microsoft-Windows-Hyper-V-High-Availability-Analytic /e:true /q

3. Enable vml traces for high availability by typing the following command at a command prompt:

   vmltrace.exe /m all /f ha all /i