If you would like to read the other parts in this article series please go to:
- Hyper-V Optimization Tips (Part 1)
- Hyper-V Optimization Tips (Part 2)
- Hyper-V optimization tips (Part 3): Storage queue depth
- Hyper-V Optimization Tips (Part 4)
In the previous articles in this series we’ve examined a number of different aspects of Hyper-V optimization such as how disk caching settings should be configured on both Hyper-V hosts and on the virtual machines running on these hosts; how Hyper-V performance can depend upon the underlying storage subsystem of clustered Hyper-V hosts and how to optimize and troubleshoot performance on those systems through judicious choice of storage hardware; how storage queue depth can potentially impact on the performance of virtualized workloads running on Hyper-V hosts; and how one can optimize Hyper-V performance when hosting clustered SQL Server workloads. In that last article we also mentioned that if you are using Shared VHDX for an SQL Server failover cluster, you can ensure that your failover cluster interconnects are optimized by:
- Using RDMA-compliant 10 GB NICs.
- Using Receive-Side Scaling (RSS) which means your interconnects should not be part of a virtual switch.
- Configuring RSS queues to their maximum supported values.
- Configure the power plan on your Hyper-V host to High Performance.
- Disabling NetBIOS if it is not required.
In this article we’re going to explore the fourth item in the above list in more detail. In particular, what is the impact of choosing different power plan settings for Hyper-V hosts and for virtual machines running on those hosts? And is there any difference between configuring power options on the guest as opposed to within the host operating system?
Guest power options are mostly irrelevant
As a starting point you need to understand that the guest operating system in a virtual machine running on a Hyper-V host doesn’t have any direct access to the underlying hardware of the host system. As a result, any power settings you configure in the guest operating system shouldn’t have any impact on how either the virtual machine or the host machine performs. This is because the host operating system together with its hypervisor layer work together in conjunction to manage the actual power management features of the platform. As a result, making changes to the power options in the host operating system has the ability to impact the performance of both the host system and any virtual machines running on the host.
Now there is one exception to this, namely the virtual (or synthetic) guest idle state which was introduced in Windows Server 2008 R2 as an under-the-hood feature for power management. The virtual guest idle state is utilized by the Intelligent Timer Tick Distribution (ITTD) feature which helps extend the amount of time processor cores remain in the idle state. This is accomplished by not interrupting all the cores in the system whenever the periodic timer interrupt is delivered, and on virtualized systems it can help realize reduced interrupt traffic and longer idle periods. The overall impact of utilizing the virtual guest idle state along with other features like core parking and timer coalescing resulted in greater energy efficiency for Windows Server 2008 R2 Hyper-V compared with Windows Server 2008 Hyper-V, and these features and capabilities continue to be implemented in Hyper-V in Windows Server 2012 and 2012 R2.
Now if the virtual guest idle state is disabled in the guest operating system, this will usually have an impact on the performance of the virtual machine, but typically this will result in degraded performance so disabling this state is not recommended. Making high-level changes however to guest power settings, for example by changing from the High Performance power plan to the Balanced power plan, will likely have no measurable impact on the performance of a workload hosted by the virtual machine because the guest operating system cannot control the performance states of a host processor such as the Intel SpeedStep feature.
Host power options are the same as for non-Hyper-V systems
Microsoft’s guidance for configuring power settings for Hyper-V hosts is basically the same as for Windows Server without the Hyper-V server role installed. The best source of reliable guidance on this topic can be found in the “Windows Server 2012 R2 – Server Performance Tuning Guidelines” document which is available here from the Microsoft Hardware Dev Center. I’m told by insiders at Microsoft that the kernel power manager in the host operating system on a Hyper-V system works in conjunction with the hypervisor, and that there are a couple of minor differences in how power management functions with the processor when the hypervisor is running compared to when it’s not running, but that these differences are subtle and not publicly documented.
SQL Server virtual machines are a possible exception
I’ve also been told by some Microsoft insiders that there have been some recommendations given to customers sometimes that if you have virtual machines with SQL Server installed then you should set the power options in the guest to match that of the host. So if High Performance is the recommended power plan for Hyper-V hosts that have virtualized SQL Server workloads running on them, then the virtual machines on that host should also have High Performance for their power plan. However, I’ve heard conflicting statements from insiders concerning whether doing this makes any difference for SQL Server performance. I do know from experience that SQL Server as a product is very sensitive to power settings when you have the product deployed on a dedicated physical server, so the bottom line for this scenario would be to test to see whether there is any difference when the power plan in the guest is changed from Balanced to High Performance.
Hyper-V and BIOS power plans
As a final consideration, it’s important to know that modern servers can have power plan options you can configure in the BIOS settings of the server. This is definitely the case for Dell and HP servers we’ve encountered, and Christian Edwards of Microsoft deals with this in some detail in this blog post on the PFE Virtualization Blog. Readers who aren’t familiar with the term “c-state” can learn more about it from this article on Intel’s website.
Got more questions about Hyper-V?
If you have any questions about Microsoft’s Hyper-V virtualization platform, the best place to ask them is the Hyper-V forum on Microsoft TechNet. If you don’t get help that you need from there, you can try sending your question to us at [email protected] so we can publish it in the Ask Our Readers section of our weekly newsletter WServerNews and we’ll see whether any of the almost 100,000 IT pro subscribers of our newsletter may have any suggestions for you.
If you would like to read the other parts in this article series please go to:
