Moving a Virtual Machine Between Hyper-V Hosts

A virtual machine (or VM) is an entity that is stored on one virtualization host, and that runs an instance of an operating system and uses resources that are presented to it by the virtualization software on that host. In Hyper-V, a VM uses a set of configuration files, and one or more virtual disks (in the format of VHD files).

There may come a time when there is a need to move a VM or more between virtualization hosts. I will not go into a debate of why this needs to be done, however, I will just mention that the most common reasons for this would be:

To free up a virtualization host for maintenance tasks that may require a reboot

To free up resources on the virtualization host

To re-arrange VM placement

Before moving or migrating a VM from one host to another, one should carefully consider these issues:

Is there downtime involved when moving the VM?

How long is the downtime?

How long does the actual migration take?

Is performance of other VMs and the virtualization host and/or network affected by the migration process?

While other potential issues may play a key role in the migration planning, the main rule of thumb when moving the VM is as follows. Moving the VM should be as fast as possible, with little or no downtime to the VM, and with a limited effect on the performance of other VMs on that host or on the network subsystem.

Let’s talk a bit about how you can migrate a virtual machine between 2 Hyper-V hosts.

Note that this article only deals with Hyper-V R2, and not with the RTM version of Hyper-V. Therefore, there may be changes in functionality, and if you’re using the RTM version (isn’t it time to upgrade already?), you may find that some of the options listed here are not available to you.

Basically, there are 3 possible ways to migrate a virtual machine between Hyper-V hosts:

By manually exporting and importing VMs

Manually moving VMs between Hyper-V hosts means that you need to perform a manual (or scripted) export of each VM you wish to migrate, copy the files to the target Hyper-V host, and then import the VM on that host. In order to export a virtual machine, you can simply right-click that VM within Hyper-V Manager and choose the “Export” option. On the new virtual host you want to import to, you can do the same process in reverse by choosing the “Import” option from the Action menu in Hyper-V Manager.

Performing a migration between hosts in this manner will assure all settings are copied along with the VHD file, and also ensure that network adapter settings are not lost.

However, this process takes time because it requires you to wait until the exporting process is done (unless the entire process is done by using a script), and only then copy the VHD and other files that make the VM to the target host. Once copied, you need to manually import the VM (or again, use a script to do it for you), which doesn’t take as much time as the export operation, but still requires time. In addition, the migrated VM will experience a prolonged downtime. This is due to the fact that it must be shut down on the original host, exported in the shut down state, copied across the network to the target host, and then imported and booted.

In order to use this method, you must install System Center Virtual Machine Manager 2008 (preferably R2, and this is the version I will be referring to from now on), and use it to perform the migration. You do NOT need to have a failover cluster of 2 or more Hyper-V hosts to allow Quick Migration. However, when migrating a VM, there will be some downtime for the migrated VM. The length of this downtime is related to the amount of RAM that is configured for the VM and the speed of the network subsystem. To learn more about how to migrate a VM from one Hyper-V host to another by using Quick Migration, please read my Using Quick Migration to Migrate a VM Between Hyper-V Hosts article.

By using Live Migration in SCVMM 2008

This method was introduced in Hyper-V R2. In order to use this method you must install System Center Virtual Machine Manager 2008 R2, and use it to perform the migration. Also, in order to allow for Live Migration, you must have at least 2 Hyper-V nodes configured in a failover cluster. The major benefit of Live Migration is the fact that it can be used to migrate VMs without any type of downtime to the VMs.

Microsoft Hyper-V Server 2008 R2 includes Live Migration and host clustering. Therefore, you do not need to buy the full featured Windows Server 2008 R2 operating system just to get Live Migration. However, remember that when using Hyper-V Server 2008 R2, each guest OS must have a valid license. When using the full featured Windows Server 2008 R2 operating system, you’ll have the advantage of the various licensing benefits that are given to you by Microsoft.

Live Migration is supported on up to 16 node failover clusters.

For production deployment, up to 64 VMs per node are supported. Customers must plan for adequate capacity when a failover occurs and VMs from the failed host are brought online on different nodes of the cluster.

For Live Migration to work, all cluster nodes must have processors from the same processor vendor, for example Intel or AMD.

Live Migration or Quick Migration will work when moving VMs from an older processor to a newer processor. However, to migrate a VM from a newer processor to an older processor, the VM must be turned off and restarted after moving the VM.

A new functionality is the “Processor Compatibility” option. This functionality can be enabled for VMs to allow both Live Migration and Quick Migration from newer to older processors from the same manufacturer. The setting is under VM settings > Processor > “Migrate to a physical computer with a different processor version”.

Upcoming article, “Using Live Migration to Migrate a VM Between Hyper-V Hosts” will feature in-depth coverage of migrating a VM from one Hyper-V host to another by using Live Migration.