In this post we will show you how to deploy bandwidth management via Quality of Service (QoS) Packet Scheduler in Windows Server 2012 (WS2012). This type of QoS can be used when converging the networks of a Hyper-V host’s management OS or a non-Hyper-V WS2012 or later operating system.
This method of QoS can be used when you are deal with networking that is not passing through a Hyper-V virtual switch in the configured operating system. This means that you can use this type of bandwidth management to guarantee minimum levels of bandwidth for protocols (not NICs) in:
As noted, this form of QoS works by assigning a weight or absolute bits per second rate to a protocol, such as live migration or cluster communications. This ensures that the protocol in question will get a minimum level of bandwidth on a contended NIC. The protocol can burst beyond that guarantee when there is both demand and idle capacity.
QoS rules that are enforced by the Packet Scheduler have two traits that you should be aware of:
If you need every cycle of processor capacity (which is normally underutilized) for your guests’ services and you want to use converged RDMA then you should use Datacenter Bridging (DCB) to implement QoS at the hardware layer instead. This will require DCB capable NICs and switches.
In this design we will be converging several networks on WS2012, as shown below.
A possible WS2012 converged networks design.
Two physical NICs are being used for the host networking. Try not to overthink this – that’s a common mistake for novices to this networking. The design is quite simple:
This configuration is a requirement for SMB Multichannel communications to a cluster such as a SOFS. Each NIC has a single IP address. Critical services such as cluster heartbeat, live migration, and SMB Multichannel will failover the non-teamed NICs automatically if you configured correctly. For example, enable both NICs for Live Migration in your host/cluster settings.
Just as with QoS that is enforced by the virtual switch, your total assigned weight should not exceed 100. This makes the algorithm work more effectively and makes your design easier to understand; weights can then be viewed as percentages. We will assign weights as follows on this host with 10 GbE networking:
PowerShell will be used to create the QoS rules. The cmdlet used is New-NetQoSPolicy.
New-NetQosPolicy “Live Migration” –LiveMigration –MinBandwidthWeight 30
The above example uses the built in filter called LiveMigration to create a rule called “live migration.” Also, a minimum weight of 30 is assigned to Live Migration traffic. This will be applies all NICs that the OS Packet Scheduler is responsible for which are the physical NICs that are not connected to the virtual switch.
You can extend this cmdlet to assign an IEEE P802.1p priority that can be leveraged by your physical network admins.
New-NetQosPolicy “Live Migration” –LiveMigration –MinBandwidthWeight 30 –Priority 5
Note that some switches with out of date software have had trouble with packets that are tagged with the priority flag.
After that you can implement QoS for SMB traffic:
New-NetQosPolicy “SMB” –SMB –MinBandwidthWeight 40
Other protocols won’t have a built-in filter. In those cases we can use the configuration of the protocol to define the traffic that is being managed. This first example will implement QoS for cluster communications by defining the destination IP port of the protocol in question:
New-NetQosPolicy “Cluster”-IPDstPort 3343 –MinBandwidthWeight 10
We can use this example to make a rule for our TCP 10000 backup protocol:
New-NetQosPolicy “Backup”-IPDstPort 10000 –MinBandwidthWeight 20
There are lots more mays to identify the traffic that is being managed by the OS Packet Scheduler, and you can find more information about these on TechNet.
And that’s it! Four lines of PowerShell have configured QoS for four protocols that are used by the host’s management OS.