In the top area, you can change the order that Windows chooses to access adapters when it doesn’t have any other hints. In my observations, this doesn’t work reliably, which is one of the reasons I recommend you not use it for Hyper-V.
Reasons People Try to Use Binding Order for Hyper-V
The most prominent reason people attempt to manipulate the binding order in Hyper-V is when the host is joined to a cluster. This is because a cluster requires multiple adapters for the management operating system, resulting in a multi-homed system. When such a system is not configured properly, it may choose the wrong adapter for some communications, resulting in a wide variety of problems.
The other reason is a misunderstanding of the Hyper-V switch. All Hyper-V installations, cluster or not, require a management adapter for the operating system and the virtual switch for the guests. Unfortunately, too many people take this to mean that the Hyper-V switch needs some sort of network presence of its own the same way that a regular adapter does. So, they try to find ways to modify the bindings and binding order between the management adapter and the virtual switch. This should never be done.
Bindings and the Hyper-V Virtual Switch
Here’s a picture of what an adapter properly bound to the Hyper-V virtual switch looks like:
The Broadcom bit is just there because it’s a Broadcom card and I have the entire Broadcom package installed. Other than that, the only thing bound to this adapter is the Hyper-V Extensible Switch. That’s exactly as it should be. Attempting to bind anything else should be blocked by the system, but if you manage to do it, you’ll probably break something.
Beyond that, network bindings have no real purpose for Hyper-V. Adapters used for the management operating system are as dependent upon bindings as any other adapter in Windows. The same goes for the virtual adapters inside virtual machines. Configure them as you would any adapter in the respective operating systems.
The Multiplexor
Right beneath the Hyper-V virtual switch in the above screenshot, you can see the Microsoft Network Adapter Multiplexor Protocol. This is the magical component that makes native adapter teaming work in Windows Server. As with adapters bound to the Hyper-V switch, adapters bound to the multiplexor must be bound to nothing else.
What it All Means
To risk oversimplification, all these components are just software. Most of them act as intermediaries between the bound adapter and anything else that wants to use it. In almost all cases, that “anything else” will be the operating system. Most other software has no real concept of network adapters. They request communications of some sort and the operating system does most of the work. This is especially true when it comes to teaming.
One exception is the Hyper-V virtual switch. Hyper-V is well aware of this software component. It is through this particular binding that Hyper-V is able to control how traffic flows in and out of all connected virtual adapters. The fact that nothing else is bound is why the management operating system has no visibility into anything that happens on the Hyper-V virtual switch. Configuring firewalls and other such OS level tools will have absolutely no effect on or access to traffic on the Hyper-V switch unless they are specifically designed as extensions to the virtual switch.
What’s Next
At this point, we’ve covered the major aspects of generic networking in relation to Hyper-V. Now it’s time to start moving into
technologies that are more Hyper-V specific.
