Part 4 of this series covered the scenario where the Backend QoS had to be Static. Now let’s take a look to what is becoming more common nowadays with Dynamic QoS. Take a look to the following picture…
Today, most of the vendors already offer Dynamic QoS based on weights or minimum reservations. This allows us to use the entire bandwidth on each of the Multiplexed NICs presented to Windows. This is good because it means that each of the NICs on the Hyper-V Host will be able to reach 10GB if needed while prioritizing traffics in case of conflict.
This backend solutions enables us to have the best from both worlds. We can provide QoS and we can also take benefit from all the Hyper-V Network optimization like RSS and dVMQ. Of course is important how many Multiplexed NICs we present to Windows and the weight assigned to each them, but remember that same rules from the Non-Converged network configurations will apply from Windows perspective.
There are three major things with this configuration to have in mind.
- LACP is not exposed to Windows, so Link Aggregation on the Multiplexed NICs will not be possible.
- QoS in the Backend and QoS from SCVMM 2012R2 on the vSwitch ports may be in conflict if policies are not properly planned and configured.
- Windows does not know what these backend QoS and Multiplexed NICs are. Support and troubleshooting should be provided by the vendor.
Besides these three caveats, this architecture is one of the best option we have if your hardware supports it. MGMT, CSV and LM networks will be able to reach 10GB throughput when needed enhancing the Host performance while keeping HA and reliability.
Of course, again we are assuming that you storage connections are over FC using HBAs.