Skip to main content

Hyper-V Performance expectations

Hyper-V Performance expectations

Before drilling deeper into the Hyper-V architecture and discussing the performance impacts of virtualization in some detail, it will help to put the performance implications of virtualization technology in perspective. Let’s begin with some very basic performance expectations.

Of the many factors that persuade IT organizations to configure Windows to run as a virtual machine guest under either VMware or Microsoft’s Hyper-V, very few pertain to performance. To be sure, many of the activities virtualization system administrators perform are associated with the scalability of an application, specifically, provisioning a clustered application tier so that a sufficient number of guest machine images are active concurrently. Of course, the Hyper-V Host machine and the shared storage and networking infrastructure that is used must be adequately provisioned to support the planned number of guests. Provisioning the Hyper-V Host machine also extends to ensuring that the guest machines configured to run on the host machine don’t overload it. Finally, virtualization administrators must ensure that guest machines are configured properly to utilize the physical resources that are available on the host machine. Under Hyper-V, this entails making sure an adequate number of virtual processors are available to the guest machine, as well as an appropriate machine memory footprint. This aspect of provisioning guest machines properly is, perhaps, more aptly characterized as capacity planning. It is certainly critical to the performance of the applications executing inside those guest machines that they are configured properly and the Hyper-V host machine where they reside is adequately provisioned.

Instead of under-provisioning, the IT organization frequently employs virtualization to utilize server hardware that is often massively over-provisioned with respect to individual guest machine workloads. Virtualization allows IT to consolidate multiple servers and workstations on a single piece of high-end hardware, with the object of making significantly more efficient and more effective use of that hardware. Data center server hardware that is provisioned with high end network adapters and connections to a high speed SAN disks (either flash memory or conventional drives) is expensive on a grand scale, so the cost benefit of packing guest machines more tightly into a physical footprint is considerable. Meanwhile, there is always the temptation to overload the VM Host, which runs the risk that the virtualization host machine could become under-provisioned. Under-provisioning has serious implications for the virtualization environment. Whenever the Hyper-V Host machine is under-provisioned for the workload presented by the guest machines it is hosting, any performance problems that result are only too likely to impact all of the guest machines that are resident on that host machine.

The best way to think about the performance of applications running under virtualization is that you have traded off some, hopefully, minimal amount of performance for the benefit of utilizing data center hardware more efficiently. Let's be crystal clear: compared to a native machine running Windows, you can count on the fact that virtualization will always have some impact on the performance of your applications running inside a Windows virtual machine (VM) guest. The impact may in fact be minor, in extreme cases, barely detectable, especially when the VM Host machine is over-provisioned with respect to the physical resources that VMs utilize from the underlying Host machine that are available to be granted to the guest VM. In other circumstances, where the guest machine does not have access to sufficient resources on the underlying Host, the performance impact of virtualization can be severe!

In the next set of blog posts, we are going to look at specific examples of this trade-off, comparing the performance of a benchmarking application

  1. on a native machine, 
  2. on an amply provisioned Hyper-V Host, and 
  3. on a Hyper-V Host machine is significantly under-provisioned, relative to the guest machine workloads it is configured to support

The key skill for performance analysts that needs cultivating is the ability to recognize an under-provisioned Hyper-V Host, or, better yet, proactively anticipate the problem and re-balance and redistribute the workload better to avoid future performance problems.
Given the capacity of today’s data center hardware, under-provisioning is often not a big concern. But when performance problems due to lack of capacity on the physical machine do occur, diagnosing and fixing them is challenging work. Typically, diagnosing this type of performance problem requires visibility into both the Hyper-V performance counters and performance measurements from the guest machines. When there is contention for storage or network resources, you may also need access to performance data from those subsystems, many of which are shared across multiple Hyper-V or VMware Hosts.

Figuring out why a guest machine does not have access to adequate resources in a virtualized environment can also be quite difficult. Some of this difficulty is due to sheer complexity: it is not unusual for the Host to be executing a dozen or more guest machines, any one of which might be contributing to overloading a shared resource, e.g., a disk array attached to the Host machine or one of its network interface cards. The guest VM might also be facing a constraint where the configuration of the virtual machine restricts its access to the physical processor and memory resources it requires. Another source of difficulty is that the virtualization environment distorts the measurements that are produced from inside the guest machine that, under normal circumstances, would be used to understand the hardware requirements of the workload.

Fortunately, the configuration flexibility that is one of the main benefits of virtualization technology also often provides the means to deal rapidly with many performance problems that arise when guest machines are configuration-constrained or otherwise severely under-provisioned. With virtualization, you have the ability to spin up a new guest machine quickly and then add it non-disruptively to an existing cluster of front-end web servers, for example. Or you might be able to use live migration to relieve a capacity constraint in the configuration by moving one or more workloads to a different Hyper-V Host machine.

Before I show some of these benchmark results, you need to know a little more about how Hyper-V works, which is the subject of the next blog post in this series.


Popular posts from this blog

“There’s a lot more to running a starship than answering a lot of fool questions.”

Continuing a series of blog posts on “expert” computer Performance rules, I am reminded of something Captain James T. Kirk, commander of the starship Enterprise, once said in an old Star Trek episode: “There’s a lot more to running a starship than answering a lot of fool questions.” Star Trek, The Original Series. Episode: The Deadly Years. Season 2, Episode 12. See For some reason, the idea that the rote application of some set of rules derived by a domain “expert” can suffice in computer performance analysis has great sway. At the risk of beating a dead horse, I want to highlight another example of a performance Rule you are likely to face, and, in the process, discuss why there is a whole lot more to applying it than might be obvious at first glance. There happens to be a lot more to computer performance analysis than the rote evaluation of some set of well-formed performance rules. It ought to be apparent by now that I …

How Windows performance counters are affected by running under VMware ESX

This post is a prequel to a recent one on correcting the Process(*)\% Processor Time counters on a Windows guest machine.

To assess the overall impact of the VMware virtualization environment on the accuracy of the performance measurements available for Windows guest machines, it is necessary to first understand how VMware affects the clocks and timers that are available on the guest machine. Basically, VMware virtualizes all calls made from the guest OS to hardware-based clock and timer services on the VMware Host. A VMware white paper entitled “Timekeeping in VMware Virtual Machines” contains an extended discussion of the clock and timer distortions that occur in Windows guest machines when there are virtual machine scheduling delays. These clock and timer services distortions, in turn, cause distortion among a considerably large set of Windows performance counters, depending on the specific type of performance counter. (The different types of performance counters are described here

Virtual memory management in VMware: memory ballooning

This is a continuation of a series of blog posts on VMware memory management. The previous post in the series is here.

Ballooning is a complicated topic, so bear with me if this post is much longer than the previous ones in this series.

As described earlier, VMware installs a balloon driver inside the guest OS and signals the driver to begin to “inflate” when it begins to encounter contention for machine memory, defined as the amount of free machine memory available for new guest machine allocation requests dropping below 6%. In the benchmark example I am discussing here, the Memory Usage counter rose to 98% allocation levels and remained there for duration of the test while all four virtual guest machines were active.

Figure 7, which shows the guest machine Memory Granted counter for each guest, with an overlay showing the value of the Memory State counter reported at the end of each one-minute measurement interval, should help to clarify the state of VMware memory-managemen…