Ok, so this has been something that’s been brewing for years now…

Juggler Hyper V Slot Machines
Juggler Hyper V Slot Machine Free Play

Having worked with many clients who have had Hyper-V issues related to VMQ, and spending a lot of my time debating incorrect/stale blog posts, I feel it’s time to set to story straight. So please excuse me if I come across a little too brash…

Pro 6 - Hyper Juggler V features a simulation of the slot machine of the same name for the player to play, he can try to get the good combinations and break the records. Manufacturer's description: Pachislot real machine simulation equipped with the 4th generation 'Hyper Juggler V' of the 'Juggler' series which added more notice with the start sound and flash notice added. A ‘Juggler’ Hyper V tabletop slot machine. No universal key is included. Please note that the ownership of slot machines is illegal in the states of Alabama, Arkansas, Connecticut, Hawaii, Indiana, Nebraska, South Carolina, Tennessee and Wisconsin. Bidding must be kept restricted to residents of states where ownership of slot machines is legal. Hyper Juggle V by Kitac Slot Machine. Juggler Girl by Kitac Slot Machine Juggler Girl by Kitac Slot Machine - NO Known Issues - Some coins come with it.

Yes, this is a bit of a “blowing of steam” post, but hopefully this can be helpful to those who have been misdirected or just need some assistance with VMQs on Hyper-V in scaled environments…

Ultimately, the main goal of this post is to help you succeed in your Hyper-V experience.

Target audience

Before I continue, let’s set the context of the post. This is for Hyper-V environments running at least 10GbE networks and using SUPPORTED hardware and drivers… What do I mean supported? Well… It’s on the Windows Server Catalog (WSC) and has “Virtual Machine Queue (VMQ)” listed as a certification. This is also targeted at those using legacy storage such as iSCSI or FC SANs (wow, I really do have a bee in my bonnet).

This post may also be helpful for those who are having random performance or stability issues in their new Hyper-V environment. This is often because VMQ is using core 0 and it is getting pinned to 100% starving hosts of being able to communicate with the cluster and or other critical low level operations. To be honest, those issues are often very hard to qualify and it’s just a matter of making some tweaks and seeing how things go.

Not for you…

If you’re running a single Hyper-V host with 1GbE NIC, then this post is not for you. If you are using HCI or your storage is SMB, then whilst this post would be helpful, there are considerations outside of what I will cover here.

Also, this post is not intended on teaching you what VMQ’s are or how they work (I may touch on it), this is a how to gather the information required and to set them correctly.

If you want more accurate info on what VMQ’s and other settings are, then these two blogs are your go-to’s:

Darryl van der Peijl
Altaro Hyper-V Dojo

Note: There are more, but these two blogs are from others that I know have extensive experience deploying and managing Hyper-V in scaled production environments. Not labs.

Ok, the disclaimers are out of the way and we’re all on the same page? Great 🙂

Sections of this post:

Misconceptions of VMQs
Common VMQ rules
VMQ modes
Teaming Modes
VMQ Settings

1. Misconceptions of VMQs (and some of Hyper-V in general)

Firstly, let’s address a few common misconceptions:

The out of the box settings are best – WRONG
Both VMQ and RSS need to be configured on the same interface – WRONG
Working out optimal VMQ is complicated – WRONG
disable VMQ on Team interface – WRONG
disable VMQ for any reason – WRONG
NUMA = physical Proc – WRONG
Dynamic load balancing algorithm is best – WRONG
LACP gives more network perf to VMs – WRONG
Switch Independent won’t work on my switches – WRONG

Note: I bet you’re a bit confused right now because you’ve read some blogs or support posts saying the opposite to much of the above. That’s fine, I’ll help you with that. They’re either outdated or wrong. 🙂 (no fence-sitting going on here…)

2. Common VMQ (and aligning with VMQ) rules

Some common rules for VMQ:

Never use Core 0
Do not overlap NUMA nodes
Physical cores only (ignores HT)
Max 64 physical CPUs
In VMs with more than 1 vCPU, enable vRSS

When it comes to VMQ and RSS, think of it as RSS is a physical adapter setting but when you apply a virtual switch the setting changes to VMQ. Kinda correct kinda incorrect, but if you think about it that way, you’ll increase your likelihood of getting VMQ and RSS settings correct.

You mentioned core 0, what’s this all about?

Well, I won’t go in too deep here, but essentially some primary processing functions of the OS happen on core 0. And if we have some high network IO being processed this can essentially pin core 0 to 100% utilization and cause all sorts of performance and stability issues

In older environments with 1Gb networks, the amount of processing required to compute the network IO was minimal. But with 10GbE and higher networks, the amount of throughput utilized requires more processing. This is what VMQ helps with, distributing the compute requirements of network IO across multiple cores and removing this overhead from core 0.

Image: Incorrectly configured VMQ at work…
(Original source unknown. A client sent this to me but I am totally using it…)

3. Teaming Modes

Before we configure VMQ, we need to understand our teaming modes, and more importantly which is best?

To clarify what these are:

Juggler Hyper V Slot Machines

Switch Independent

This is the default recommendation for all Hyper-V virtual switches. Each interface is it’s own trunk and the physical switch sees these as separate independent interfaces.

This is your go-to config and will give a higher likelihood of success.

Summary: Switch Independent is the way to do Hyper-V switches properly

Switch Dependent

This is LACP or Static Teaming. Quite often I have customers who’s networking teams dictate this and try to mandate LACP as the methodology for fail-over. I STRONGLY recommend this be overruled and Switch Independent be the methodology used.

Whilst technically LACP works (I ran LACP in prod for a long time) too many time have I seen incorrect, misaligned or configs that just don’t work which give organisations a poor Hyper-V experience. Additionally, with VMQ we can get more networking performance out of our environments. Ok, networking people will argue this, but they thinking physical aggregation, not virtualization.

So which is best? I think you know my answer already 🙂

The long politically correct answer – it sometimes depends on the environment but ultimately Switch Independent is typically the optimal configuration.

Simple direct answer – Switch Independent is best.

4. VMQ modes

When configuring VMQ, there are two modes that we must be aware of: Min-queue mode and Sum-of-queue mode

Sum-of-queue mode:
All NICs in the team/switch must have separate processor assignments

Min-queue mode:
All NICs in the team/switch must have identical processor assignments

A good blog from Charbel Nemnom has a little bit more info on the two modes:

But which mode when? This common table should help with the overall selection…

Teaming mode	Hyper-V Port	Dynamic	Address Hash
Switch Independent	Sum-of-Queues	Sum-of-Queues	Min-Queues
Switch Dependent	Min-Queues	Min-Queues	Min-Queues

If you’ve been reading properly though, you’ll note I stated above that you should always be using Hyper-V Port as your teaming algorithm. Following that rule, your table really should look like this:

Teaming mode	Hyper-V Port
Switch Independent	S