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…

clip_image002

Today, most vendors already offer Dynamic QoS based on weight 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 traffic in the event of conflict.

This backend solution enables us to have the best of both worlds. We can provide QoS and we can also take advantage of all the Hyper-V Network optimizations like RSS and dVMQ. Of course, it is important how many Multiplexed NICs we present to Windows and the weight assigned to each of them, but remember that the same rules from the Non-Converged network configurations will apply from a Windows perspective.

There are three major points with this configuration to bear in mind.

  1. LACP is not exposed to Windows, so Link Aggregation on the Multiplexed NICs will not be possible.
  2. 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.
  3. 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 options 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 your storage connections are over FC using HBAs.