Hyper-V monitoring –

Tip 1 — Don’t Rely on Task Manager Data Within a VM

The first rule is don’t ever measure the performance of a VM from within a VM, because it can only see its little keyhole view of the world. Here’s a simple test to understand this: run one VM on a host, run an application (such as Prime95) that maxes out the virtual CPU(s).

Task Manager will report 100% CPU, but if you now start another VM and run the same application in that VM, Task Manager will still report 100%—but it’s actually running at half the speed compared to earlier. This example disregards additional processors in the host, but clearly demonstrates the Task Manager in VMs lies.

Tip 2 — Establish a Performance Baseline

The second rule for performance monitoring, whether physical or virtual, is to create baselines when things are humming along. Unless you’ve got a baseline from when performance was good and users happy, you have nothing to compare with when issues arise. Learn how to create Data Collector Sets: log for a few days, and archive the results.

Tip 3 — Use Counters That Are Specific to Hyper-V

When using Performance Monitor in the host, be aware that it might lie as well. Don’t use normal counters as they often don’t understand VMs, use Hyper-V specific counters. For processor performance use the Hyper-V Hypervisor Logical Processor% Total Run Time counter; this will let you monitor physical processors in the host. For VMs use Hyper-V Hypervisor Virtual Processor% Guest Run Time, which lets you monitor virtual CPUs for each running VM (or as a total). As a rule of thumb, less than 75% for this counter (total for all VMs) is healthy, over 75% is a warning sign, and more than 85% should definitely be investigated.

Tip 4 — Keep an Eye on Committed Memory

In today’s Hyper-V world of BDM (Before Dynamic Memory), you should monitor MemoryAvailable Mbytes on the host. Healthy is more than 10% of RAM free, at less than 10% it’s a warning that something is going on. If it’s less than 100 MB, it needs to be looked at. Veterans will know that “high pages per second” means a low memory condition, but there are cases where this isn’t true (due to memory mapping of files). Use the MemoryCommitted Bytes counter to see how much memory each VM is using when planning your VM memory allocation.

Tip 5 — Provide Adequate Memory Buffer

In the physical world, as sysadmins, we always like to have a bit extra up our sleeve. If you were designing a server that you knew would use about 1.5 GB of memory you’d install 2 GB just to be on the safe side. In the VM world, this is adjusted with the buffer, the default is 20%. For workloads that need a lot of file cache to increase this value. This screen is also where you can assign a higher or lower weight to each VM, which will allow a VM to have a higher (or lower) priority for memory as the host starts running low on available memory.

Tip 6 — Watch the Disk Latency

Monitoring disk is done via the LogicalDisk(*)Average Disk SecRead or Write which indicates your disk latency. Healthy is less than 10ms (0.010). If it goes up to 15ms or above (0.015), it’s time to check it out. At 25ms or above (0.025) the situation is critical.

Tip 7 — Network Performance

For network monitoring use the counter Network Interface (*)OutputQueue Length. Less than 1 on average is healthy, the warning is when it’s above 1 on average, and critical is when it’s 2 or more on average.