This post has been updated to include a link to our Strategies and Best Practices for Virtualizing SQL Server guide.
(This is a branch off of my overall v9.0 announcement post.) For Hyper-V, enabling guest virtualization information works a bit differently that with VMware. This functionality works in conjunction with Performance Advisor for Windows. All you need to do is monitor the Hyper-V host with Performance Advisor for Windows, and we'll handle the rest. I should note also that this functionality only works for Hyper-V running on Windows Server 2012 (or Windows 8) or higher.
Virtual Machine Enhancements
Some of the information we'll provide is a bit different for guests running in Hyper-V. First, you'll be able to see the hierarchy for the host including the Windows cluster, virtual machines, and any instances being monitored in the navigator pane:
Note a few details here. We can see the Windows cluster (WSFC), the WSFC nodes in the cluster, several virtual machines, and some basic information about OS type and version.
As we move to the Performance Advisor Dashboard, we'll see something new in the information area.
We have the hypervisor platform and host name here, just like with VMware, but you can see that the host name is a link. Since SQL Sentry will be monitoring the Hyper-V host, we're providing a quick way to launch into Performance Advisor for the host. Simply click on that host name link, and it will open in a new Performance Advisor tab. For the CPU Usage charts, we wanted to provide a similar metric to what we get from VMware for Ready Time. There is not a direct counterpart available for this in Hyper-V, but there is enough information available to calculate something close. The result is a metric we call "vCPU Wait Time."
vCPU Wait Time is a measurement of the percentage of time over that the sample period the virtual CPU(s) were waiting to be able to do their work. Ultimately it is very similar to what Ready Time is on VMware; we’re just doing all the math for you. In Hyper-V you will likely find this value to be much lower than you will see in VMware due to the difference in how CPU scheduling works between the two hypervisor platforms. The thresholds you’re looking for are going to be the same, but it’s going to take more to get there in Hyper-V. For memory, we display ballooning for Hyper-V as well. This is only going to show when the virtual machine has dynamic memory available, and when memory is actually being ballooned.
One difference to keep in mind is that ballooning in Hyper-V means something slightly different than VMware. Instead of ballooning memory to give back to a host that is under stress, Hyper-V will balloon memory in order to reclaim memory that is not being used by a guest. From our testing, it is typical to be able to see something similar to the above image on a Hyper-V VM that has a much higher maximum dynamic memory setting than it normally uses. As demand for memory goes up on the VM, the ballooned memory is returned to the VM.
Just like in VMware, you can have these measurements in reports and in custom conditions.
Here I'm testing to see whether overall read or write IOps for the virtual storage subsystem are less than 90% of the Windows storage subsystem on a host.
Until next time,