Posey's Tips & Tricks
Hyper-V Architecture: Some Clarifications
Recently, someone who is relatively new to Hyper-V e-mailed me to ask two thought-provoking questions.
The first was whether or not it is true that Hyper-V virtual machines (VMs) have direct hardware access. The second was how it is possible to manage VM resource contention if the VMs bypass the host operating system and communicate directly with the underlying hardware. The person's theory was that if the VMs directly access the underlying hardware, then the host operating system should be unaware of the resources that the VMs are using, thereby making it impossible to accurately measure the load that the VMs are placing on the host.
In actuality, Hyper-V VMs do not bypass the host partition and communicate directly with the bare-metal hardware. However, there are at least a couple of reasons why there is sometimes a perception that VMs have direct hardware access.
The first of these reasons has to do with the evolution of Microsoft's virtualization products. Early on, Microsoft created virtualization products that were based on the use of hardware emulation. Whenever a VM needed to make a hardware call, the parent operating system would intercept the call and act as a proxy, thereby making the call on behalf of the VM. The process worked (at least most of the time), but VMs were painfully slow.
When Microsoft eventually created Hyper-V, which does not depend on the architecture that I just described, it became possible to squeeze far more performance out of a VM. Bloggers sometimes described the VMs as having native hardware performance, or used similar terms. That's probably one of the things that contributed to the idea that Hyper-V VMs communicate directly with the hardware.
Another contributing factor is probably Hyper-V's support for hardware pass-through. Hyper-V VMs can be configured to take ownership of physical hard disks through the hypervisor's storage pass-through feature. Similarly, Hyper-V supports discrete device assignments, which allow a VM to take control of a PCIe device.
As previously mentioned, Hyper-V VMs do not make direct hardware calls. A granular discussion of the Hyper-V architecture is beyond the scope of this column, but VMs reside inside of child partitions. Microsoft's Hyper-V architecture documentation states, "Partitions do not have access to the physical processor, nor do they handle the processor interrupts." The documentation goes on to explain, "The hypervisor handles the interrupts to the processor, and redirects them to the respective partition."
Calls to other types of hardware may be handled by the hypervisor or the VMBus. In any case, VMs do not directly interact with the underlying hardware.
So what about the question of keeping tabs on resource utilization at the host level? The host actually can see how much of a load VMs are placing on the system. If you have ever used the Hyper-V Manager, you have probably noticed that even though it runs in the parent partition, it is able to report on the VM CPU and memory utilization.
This brings up an important point. A VM is only assigned a fraction of the system's total resources. For example, a VM is allocated a specific number of virtual processors and a certain amount of memory. This means that when you run a performance monitoring tool inside of a VM, it is reporting the percentage of the VM's resources that are being used, not a percentage of the host resources used. A performance monitoring tool that is running inside of a VM has no knowledge of the parent partition's resources or of resources that are being consumed by other VMs.
Conversely, if you run a performance monitoring tool at the host level, that tool will show you the impact that all running VMs are having on the host. Let me show you an example.
If you look at Figure 1, you can see a VM running on a Hyper-V host. I am running a tool called Heavy Load inside of the VM. This tool is configured to stress the VM's CPU. I let the tool run for a while, then I clicked the Stop button. The Task Manager shows that the VM's CPU was running at 100 percent, and then utilization decreased sharply when I hit the Stop button.
[Click on image for larger view.] Figure 1: I used the Heavy Load tool to stress the VM's CPU.
If you look to the right of the VM's desktop, you can see part of the Task Manager window running in the parent partition. This host has two physical processors. One processor shows almost no activity. The other processor shows a CPU usage pattern that closely mimics that of the VM. But whereas 100 percent of the VM's CPU resources were being consumed, only about 30 percent of the physical CPU resources were being consumed.
This is because the VM only receives a fraction of the available CPU resources. The Heavy Load tool is consuming 100 percent of the VM's CPU resources, but the VM has far fewer CPU resources than the physical host because of the way that the VM is configured.
In other words, the parent partition runs the hypervisor and is therefore aware of VM hardware resource usage. That is why it is possible to monitor VM resource consumption from the host operating system.
About the Author
Brien Posey is a 22-time Microsoft MVP with decades of IT experience. As a freelance writer, Posey has written thousands of articles and contributed to several dozen books on a wide variety of IT topics. Prior to going freelance, Posey was a CIO for a national chain of hospitals and health care facilities. He has also served as a network administrator for some of the country's largest insurance companies and for the Department of Defense at Fort Knox. In addition to his continued work in IT, Posey has spent the last several years actively training as a commercial scientist-astronaut candidate in preparation to fly on a mission to study polar mesospheric clouds from space. You can follow his spaceflight training on his Web site.