Common causes of a failed Hyper-V live migration
Hyper-V live migration helps admins maintain infrastructures. But a few common configuration snafus can cause failures. Do you know what to look for?
Most organizations running Microsoft Hyper-V in production consider live migration a critical capability. A failed live migration can be devastating, and a number of configuration mistakes can cause failures. Knowing the most common factors that lead to failed Hyper-V live migrations can prevent a problem before it begins.
No Hyper-V live migration without sufficient resources
One of the most common causes of a failed live migration is also the simplest to correct. To live-migrate a virtual machine from one host server to another, the destination host must have adequate physical resources to accommodate the VM, including enough physical memory. If the destination host does not have enough free physical memory -- or other physical hardware resources -- the live migration will fail.
Fixing the problem is simple. An administrator must either live-migrate the VM to a different host with sufficient free hardware resources or shut down a lower-priority VM on the destination host to free up space and resources.
Incompatible processors will fail a migration
Microsoft Hyper-V does not require cluster nodes to use identical hardware. However, each host server in a Hyper-V cluster must use similar processors to accommodate live migrations. This means you need to ensure that all physical host processors belong to the same processor family. In other words, you could not live-migrate a virtual machine from a host with an Intel processor to a host with an AMD processor.
More resources on Hyper-V live migration
Overcoming Hyper-V Live Migration limitations
Hyper-V Live Migration terminology
Sometimes using similar CPU brands does not suffice. For example, a few weeks ago I decided to replace some aging servers running hex-core AMD processors with new ones running eight-core AMD processors. I planned to join the new servers to the existing Hyper-V cluster, live-migrate the VMs from the old servers to the new servers and then take the old servers offline. Unfortunately, the processors were too different from one another for the live migration to succeed.
By configuring VMs to use processor-compatibility mode, I successfully completed the live migration.
Processor-compatibility mode has its flaws
Processor compatibility mode may seem like a miracle fix, but it has drawbacks: It can only facilitate live migrations between processors in the same family. You cannot use it to enable a live migration between an Intel processor and an AMD processor. You can, however, use this mode to facilitate live migrations between generations of processors within a common vendor or brand.
The mode intercepts the CPUID instructions so that the actual CPU identification is obscured. This, in turn, disables a number of processor features that can affect performance. Microsoft recommends avoiding processor-compatibility mode if you use VMs for multimedia or high-performance computing, or if the VM performs a CPU-intensive encryption function.
To enable processor compatibility mode, you must power off and then restart a VM. In some cases, you can move the powered-off VM to the destination host. Such cases may, in fact, render processor compatibility mode unnecessary.
Mismatched Hyper-V versions, iSCSI incompatibility and slow network connections
Mismatched versions of Hyper-V within a failover cluster could also cause a live migration to fail. A cluster can consist of multiple Windows Server editions, as long as each copy of Windows Server belongs to the same release cycle. For example, you couldn't mix Windows Server 2008 and Windows Server 2008 R2 within a failover cluster because the Windows Server 2008 edition of Hyper-V does not support live migration.
ISCSI incompatibility can impede your ability to live-migrate a VM as well. Prior to the release of Windows Server 2012, live migration required the use of Cluster Shared Volumes (CSV). CSV could connect through either Fibre Channel or iSCSI. If you choose iSCSI, then the target must adhere to the iSCSI-3 specification, which allows for the persistent reservations required for live migrations.
Lastly, only network connections with a speed of at least 1 Gbps can support live migrations. Theoretically, it may be possible to complete a live migration on a slower network link, but Microsoft does not support it.
A number of different factors can stand in the way of live-migrating virtual machines. By learning to identify the most common problems you may encounter, you'll be better equipped to avoid them.
