It’s easy enough to monitor basic network traffic statistics for Hyper-V virtual machines (VMs), but it’s harder to perform actual packet capture due to how networking is virtualized in Hyper-V. Here are your options:
- Network Interface. This counter set describes the physical network devices used in Hyper-V. The counters in this set are useful for seeing how well traffic is going to and from Hyper-V as a whole. If you’re logging a large number of errors on your physical network interface, for instance, that might be a sign either the adapter itself is saturated or the network fabric you have Hyper-V connected to is too slow.
- Hyper-V Virtual Switch. This gives you statistics about traffic being passed between Hyper-V VMs . A similar counter set, Hyper-V Virtual Switch Port, lets you see statistics for a particular port in the switch.
- Hyper-V Legacy Network Adapter and Hyper-V Virtual Network Adapter. These two sets of performance counters provide details about the network activity of specific VMs. Subsets of each one of these groups of counters will exist with the friendly name of the VM you’re looking for, along with the name(s) of its network adapter(s), plus GUIDs for both VM and adapter in case you want to use Windows Management Instrumentation (WMI) to query them.
The main difference between these two sets of counters is whether or not the VM you’re monitoring is using Integration Services. Obviously, you want to use IS whenever possible and use the Virtual Network Adapter counters. (Windows Server 2008 and later come with IS preinstalled, so you don’t have to worry about them.) VMs that don’t have IS running need to use the Legacy Network Adapter counters, although that comes with a performance penalty.
What if you want to monitor packet-level network traffic to and from all VMs in an instance of Hyper-V -- in other words, perform packet inspection or network capture? Right now, unfortunately, there’s no direct way to do this in Hyper-V itself. The virtual network adapter does not yet have a promiscuous mode, in part for the sake of enhancing security and isolation between VMs and for protecting the hypervisor itself. (Ivan Pepelnjak has some perspective on this issue here.)
One way this can be achieved is by simply installing WireShark or a similar product on each of the VMs that need to have packet capture set up. It’s a less-than-ideal solution for a variety of reasons. For one, you have to set up the packet-capture software on each individual machine, rather than once in the hypervisor. You might be able to work around this via software deployment -- but that’s assuming the VMs you’re capturing from are all running Windows.
More on Hyper-V monitoring
Shedding light on Hyper-V 3.0 resource monitoring
Hyper-V and PerfMon: Even more useful counters
However, the picture’s already changing. One of the new features planned for Windows Server 8 is an “extensible switch” system. This allows capturing, filtering and forwarding of extensions injected into Hyper-V’s virtual switch stack, so that traffic to and from each VM can be separately inspected on the Hyper-V side. Granted, this means waiting for Hyper-V 3.0 to come along (you can download the Windows Server 8 beta here), but at least Microsoft has admitted to the need for such a feature and is doing something about it.
ABOUT THE AUTHOR
Serdar Yegulalp has been writing about computers and IT for more than 15 years for a variety of publications, including InformationWeek and Windows Magazine.
This was first published in March 2012