How to Enable Hyper-V Virtual Machine Processor Compatibility Mode

Windows Server 2008 R2 (W2008 R2) introduced live migration to Hyper-V. Live migration allows running virtual machines to move from one host to another with no perceivable downtime. There are some boundaries that are enforced by hardware on this type of virtual machine movement. In this article, I will show you how to enable processor compatibility mode in Hyper-V to allow a virtual machine to move between different generations of the same processor family.

How Processors Restrict Virtual Machine Movement

A hypervisor will reveal the capabilities of the physical processor to a virtual machine when that virtual machine boots up. The virtual machine will then use those features to run services. Over the years, AMD and Intel have added features, especially for virtualization, that enhance the performance and security of those virtual machines. Obviously neither Intel nor AMD can back-port their hardware enhancements to already deployed processors, so there is a potential issue. Let’s get something clear first: You cannot live migrate or restore saved virtual machines across different families of processor. This means, for example, that you cannot do the following:

  • live migrate from a host with Intel processor to a host with AMD processors
  • restore a virtual machine on an Intel host from a saved state created on a host with an AMD processor

The reason is quite simple: The processors are in different families and have completely different instructions and features. There is no way around this. So the advice is simple: Go all-Intel or all-AMD within your expected migration boundaries. Imagine you have a virtual machine running on Host1. Host1 has a “Generation 1” processor from manufacturer X. You want to live migrate that virtual machine to Host2 that has “Generation 3” processors. The newer processors have a superset of features; in other words, all of the features on the older processor exist or are compatible on the newer processor. The live migration will work because the virtual machine is using features that will still work on the newer host. The newer processor has many more features that cannot be found on the older processor. Say you start another virtual machine on Host2. It will find all those lovely new features of the newer processor that do not exist on Host1. You will not be able to live migrate this second virtual machine to Host1 because the newer processor enhancements are not there to be used by the already running virtual machine. This incapability of features between different generations of a processor family also impacts restoring virtual machines.

Processor Compatibility Mode

We have had the ability since W2008 R2 to enable processor compatibility mode in the processor settings of a virtual machine. This setting will allow you to live migrate or restore a virtual machine across different generations of processor within the same family (Intel to Intel, or AMD to AMD). Enabling processor compatibility is easy. Simply open the settings of the required virtual machine and check the box.

processor compatibility mode setting in a Hyper-V virtual machine
Enabling processor compatibility mode in a virtual machine.

There is a significant price to enabling this feature. The hypervisor will hide all of the advanced processor virtualization enhancements from the virtual machine when it boots up. This will reduce the performance of your services. My suggestion is that this feature should be used as a last resort. Instead, you should always try to keep your processors in the same generation. This is hard to do when you are adding servers over time and manufacturers keep adding new stock. So here are my ideas:

  • When you start a new cloud or host farm, buy the newest processor and server spec that you can afford. This will give you a longer window for buying more of the same spec later on.
  • When you need to add more host capacity, go back to that spec and get more of the same.

This won’t be a complete solution if you’re adding host capacity over multi-year periods because hardware does change. But it will increase the size of your live migration boundaries.