Hyper-V supports Hyper-V-specific and emulated network adapters in the virtual machines, but the Hyper-V-specific devices offer significantly better performance and reduced CPU overhead. Each of these adapters is connected to a virtual network switch, which can be connected to a physical network adapter if external network connectivity is needed.
For how to tune the network adapter in the root partition, including interrupt moderation, see Performance Tuning for the Networking Subsystem earlier in this guide. The TCP tunings in that section should be applied, if required, to the child partitions.
Hyper-V-specific Network Adapter
Hyper-V features a Hyper-V-specific network adapter that is designed specifically for virtual machines to achieve significantly reduced CPU overhead on network I/O when it is compared to the emulated network adapter that mimics existing hardware. The Hyper-V-specific network adapter communicates between the child and root partitions over VMBus by using shared memory for more efficient data transfer.
The emulated network adapter should be removed through the settings dialog box in the virtual machine and replaced with a Hyper-V-specific network adapter. The guest requires that the virtual machine Integration Services be installed.
Perfmon counters that represent the network statistics for the installed Hyper-V-specific network adapters are available under the following counter set: \Hyper-V Virtual Network Adapter (*) \ *.
Install Multiple Hyper-V-specific Network Adapters on Multiprocessor virtual machines
Virtual machines with more than one virtual processor might benefit from having more than one Hyper-V-specific network adaptor installed in the virtual machine. Workloads that are network intensive, such as a web server, can make use of greater parallelism in the virtual network stack if a second Hyper-V-specific network adapter is installed in a virtual machine.
As with the native scenario, offload capabilities in the physical network adapter reduce the CPU usage of network I/Os in virtual machine scenarios. Hyper-V currently supports LargeSend Offload (LSOv1, LSOv2) and TCP checksum offload (TCPv4, TCPv6). The offload capabilities must be enabled in the driver for the physical network adapter in the root partition. For details about offload capabilities in network adapters, refer to Choosing a Network Adapter.
Drivers for certain network adapters disable LSOv1, and they enable LSOv2 by default. System administrators must explicitly enable LSOv1 by using the Properties dialog box for the driver in Device Manager.
Network Switch Topology
Hyper-V supports creating multiple virtual network switches, each of which can be attached to a physical network adapter if needed. Each network adapter in a virtual machine can be connected to a virtual network switch. If the physical server has multiple network adapters, virtual machines with network-intensive loads can benefit from being connected to different virtual switches to better use the physical network adapters.
Perfmon counters that represent the network statistics for the installed Hyper-V-specific switches are available under the following counter set: \Hyper-V Virtual Switch (*) \ *.
The Hyper-V-specific network adapter supports VLAN tagging. It provides significantly better network performance if the physical network adapter supports NDIS_ENCAPSULATION_IEEE_802_3_P_AND_Q_IN_OOB encapsulation for Large Send Offload and checksum offload. Without this support, Hyper-V cannot use hardware offload for packets that require VLAN tagging, and network performance can be decreased.
Dynamic virtual machine queue (VMQ or dVMQ) is a performance optimization of VMQ in Windows Server 2012 that automatically scales the number of processors that are in use for VMQ, based on the traffic volume. This section provides guidance about how to configure the system to take full advantage of dVMQ.
The configuration of dVMQ is controlled by the same settings as RSS. It uses the following standard keywords in the registry for the base CPU number and the maximum number of CPUs to use: *RssBaseProcNumber and *MaxRssProcessors.
Some Intel multi-core processors may use Intel Hyper-Threading Technology. When Hyper-Threading Technology is enabled, the actual number of cores that are used by dVMQ should be half the total number of logical processors that are available in the system. This is because dVMQ spreads the processing across individual physical cores only, and it will not use hyperthreaded sibling cores. As an example, if the machine has an Intel processor with four physical cores, and Hyper-Threading Technology is enabled, it will show a total of eight logical processors. Only four logical processors are available to VMQ. VMQ will use cores 0, 2, 4, and 6.
There may be situations where starting with logical processor 0 (which corresponds to core 0) as the *RssBaseProcNumber is acceptable. However, general guidance is to avoid using core 0 as the base CPU because it is generally used for default network queues and workload processing in the root partition.
Based on the root virtual processor utilization, the RSS base and maximum logical processors for a physical network adapter can be configured to define the set of root virtual processors that are available for VMQ processing. Selecting the set of VMQ processors can better isolate latency-centric or cache-sensitive virtual machines or workloads from root network processing. Use the Windows PowerShell cmdlet, Set-NetAdapterVmq, to set the correct base processor number and the maximum processor number.
There are limited hardware queues available, so you can use the Hyper-V WMI API to ensure that the virtual machines using the network bandwidth are assigned a hardware queue. To disable VMQ for specific virtual network adapters, open Hyper-V Manager, and then open the settings for a virtual machine. For the virtual network adapter on which you want to disable VMQ, expand the port settings, and in the Hardware Acceleration section, clear the Enable Virtual Machine Queue check box.
When a host has multiple network adapters, each for a different virtual switch instance, and it is using dVMQ, do not configure dVMQ to use overlapping processor sets. Ensure that each network adapter that is configured for dVMQ has its own set of cores. Otherwise performance results may be impaired and unpredictable.
There are two separate dVMQ configuration recommendations, based on the type of network adapter teaming (also known as load balancing and failover or LBFO) in Windows Server 2012 with Hyper-V. If the team is configured by using switch dependent-mode or address hashing, each network adapter in the team should have identical values for *RssBaseProcNumber and *MaxRssProcessors. This mode is referred to as Min mode in the following table.
If the team is configured by using switch independent mode and Hyper-V switch port addressing, each network adapter in the team should be configured by using non-overlapped processor sets as earlier described for multiple network adapters. This is referred to as the Sum mode in the following table. For more information, see the Windows Server 2012 NIC Teaming (LBFO) Deployment and Management Guide.
Address hash (2-tuple, 4-tuple, or MAC)
Hyper-V switch port
Switch dependent mode
Switch independent mode
The following table has example comparisons of the dVMQ settings (RssBaseProcNumber, MaxRssProcNumber) for two virtual machines that use the Min and Sum configurations.
3 network adapters
4 network adapters
Min example configuration
Each NIC=2, 3
Sum example configuration
The following formula can be used to compute even distribution of cores among network adapters for a team. It is assumed that the first core is skipped; that is, RssBaseProcNumber starts at 2.
The maximum number of cores per virtual machine that dVMQ will use is 16.
Nt = total number of network adapters in the team
The general case assumes hyperthreading is in use on cores:
MaxRssProcessors = min((Ct-2)/2/Nt, 16)
In the event that hyperthreading is disabled or unavailable:
MAC Spoofing Guidance
By default each virtual machine has MAC address protection, so traffic on a MAC address (other that the one assigned in the host) is blocked. To allow a virtual machine to set its own MAC address, the Enable MAC Spoofing check box must be selected with the Windows PowerShell cmdlet Set-VMNetworkAdapter as follows:
PS C:> get-vm “MyVM” | set-vmNetworkAdapter
Note If MAC spoofing is enabled on a virtual machine that is connected to an SR-IOV mode virtual switch, traffic will still be blocked. MAC spoofing should only be enabled for a virtual machine on a non-SR-IOV mode virtual switch. If Enable MAC Spoofing is selected, the SR-IOV virtual function is removed and traffic is routed through the virtual switch.
Single Root I/O Virtualization
Windows Server 8 introduces support for single root I/O virtualization (SR-IOV), which allows the direct assignment of network resources (virtual functions) to individual virtual machines when specialized hardware is available. SR-IOV can be enabled for networking and CPU intensive workloads to reduce virtualization overhead for networking I/O.
The number of virtual functions available for assignment is defined by the network adapter, and they can be queried with the Windows Powershell cmdlet, Get-NetAdapterSriov. Other IOV operations that are exposed through Windows Powershell include:
Enable-NetAdapterSriov: Enables IOV on the physical network adapter
Disable-NetAdapterSriov: Disables IOV
New-VMSwitch: Use withthe –EnableIov flag to create an IOV switch
When networking virtual machine-to-virtual machine, the virtual function bandwidth is limited by the bandwidth of the physical adapter. In cases where the virtual function bandwidth is saturated, switching to the Hyper-V-specific network adapter for inter-virtual machine communication can improve throughput by decoupling virtual machine-to-virtual machine network I/O traffic from the physical adapter bandwidth.
Live migration enables you to transparently move running virtual machines from one node of a failover cluster to another node in the same cluster without a dropped network connection or perceived downtime. In addition, failover clustering requires shared storage for the cluster nodes.
The process of moving a running virtual machine can be divided into two major phases. The first phase is the copying the memory contents on the virtual machine from the current host to the new host. The second phase is transfering the virtual machine state from the current host to the new host. The durations of both phases is greatly determined by the speed at which data can be transferred from the current host to the new host.
Providing a dedicated network for live migration traffic helps minimize the time that is required to complete a live migration, and it ensures consistent migration times.
Figure 16. Example Hyper-V live migration configuration
In addition, increasing the number of receive and send buffers on each network adapter that is involved in the migration can improve migration performance. For more information, see Performance Tuning for the Networking Subsystem earlier in this guide.