Ever since its debut in Windows Server 2008, Hyper-V has included a feature called processor compatibility mode. The idea behind this feature is that because host servers are not necessarily created equally, Hyper-V processor compatibility mode provides a way to live migrate virtual machines between host servers with dissimilar CPUs. It does this by limiting the virtual machine, so that it only uses the most basic CPU features, rather than being able to take advantage of the more modern processor capabilities.
Conventional wisdom has long held that Hyper-V processor compatibility mode should not be used unless there is a need to live migrate VMs (or migrate VMs that are in a saved state) between servers with dissimilar processors. Otherwise, it’s best to avoid using processor compatibility mode, because the inability of the VM to access advanced CPU features presumably impacts the virtual machine’s performance.
I have always been curious about how much of a difference in performance Hyper-V processor compatibility mode really makes. Over the years, I have read (and even written) various blog posts stating that processor compatibility mode should not be used unless it is really needed. Even so, I can’t seem to recall Microsoft ever warning its customers that enabling processor compatibility mode would cause huge performance problems. Maybe Microsoft did release such a statement at some point, but I can’t recall ever having seen it if they did. As such, I decided to do some informal benchmark testing to determine how much of a difference Hyper-V processor compatibility mode really makes to a virtual machine’s performance.
Before I get started, I need to point out that my test results should not be treated as definitive. Some workloads make heavy use of advanced CPU features, while others do not. As such, my test results are only valid for my particular workload. Even so, the tests should give at least a ballpark idea of the impact that processor compatibility mode has on a generic workload.
For the purposes of this test, I installed a fully patched copy of Windows 10 into a Hyper-V virtual machine. The VM is running on a Windows Server 2012 R2 host. For the test, I have shut down all of the other virtual machines, so that my test VM was the only thing running on the host.
I then installed Cinebench onto the VM, and ran a CPU benchmark test. I opted to use this particular tool because it assigns a simple, numerical score to the CPU based on its performance. I thought that approach might be better than using a collection of metrics that only those who have advanced hardware knowledge would be familiar with.
So with the VM in an idle state, Cinebench gave the VM’s CPU a score of 353. If you look at the figure below, you can see that Cinebench also shows how this CPU compares to other commonly used CPUs. In this case, the VM finished near the bottom of the rankings. However, this isn’t so much a reflection of Hyper-V’s capabilities as it is of my hardware. My Hyper-V host is running on older, lab hardware, so I would expect a low score.
Enabling Hyper-V processor compatibility mode
With a benchmark result in hand, I shut down the VM and enabled processor compatibility mode. For those who might not have ever used processor compatibility mode, you can enable it within the Hyper-V manager by right clicking on the VM, and choosing the Settings command from the shortcut menu. When the Settings dialog box opens, expand the Processor node, and click on Compatibility. Now, select the Migrate to a Physical Computer With a Different Processor Version checkbox as shown below, and click OK.
With processor compatibility mode enabled, I booted the VM, logged in, and then waited for the VM’s CPU load to stabilize. After several minutes of waiting, I ran Cinebench again so that I could see what kind of difference processor compatibility mode had made to the VM’s performance. This time, Cinebench reported a score of 346, as shown below. The score was seven points lower than before, but given Cinebench’s rating scale I do not consider this to be a huge difference.
One of the things that I have learned about benchmarking over the years is that unless you perform the benchmark testing under very carefully controlled conditions, the results cannot be considered to be scientific. You can end up with different results for each test, even though nothing in the testing environment has changed. These differences can be attributed to things such as OS overhead and background processes. As such, I ran the benchmark test five more times, both with and without CPU compatibility mode enabled, and then averaged the results together. Here are the testing results:
As you look at the scores shown above, you can begin to get a sense of why it is important to take multiple data points when benchmarking a system’s performance. The values yielded by the tests are anything but consistent. In fact, the tests yielded some really interesting numbers. The lowest score that was reported when processor compatibility mode was not enabled was 345, and that number came up more than once. The highest score that was achieved while running with processor compatibility mode enabled was 346 — one point higher than the lowest score that I got with processor compatibility mode enabled. Had these been the only two data points, it would have given the illusion that the system actually performed better with Hyper-V processor compatibility mode enabled. In reality however, the VM scored an average of eight points higher when it was not using Processor Compatibility Mode.
Conclusions — with caveats
As I mentioned early on in this article, my tests were anything but scientific. But they do give a hint as to the way that processor compatibility mode impacts some workloads. Even so, it is important to remember that the impact of enabling processor compatibility mode is highly dependent upon the workload that is being run. Even Microsoft says that “it is difficult to quantify the overall performance effects of processor compatibility mode. The performance loss is primarily dependent on the workload running in the virtual machine. Some workloads will be completely unaffected, while others will show a noticeable difference. Software that heavily relies on hardware optimizations (such as encryption, compression, or intensive floating-point calculations) will be impacted the most.”
Photo credit: Pixabay