Hyper-V Virtual Switch Explained, Part 148
The Hyper-V virtual switch is one of the biggest sticking points for newcomers to the hypervisor. This is the first of a two-part series that will break this down and try to clear up some of the confusion. In this part, we’ll cut through some of the conceptual barriers around the Hyper-V virtual switch. In part 2, we’ll look at use cases for the virtual switch. These posts will only cover the virtual switch and the connection of the management operating system to the physical network.
There are three possible modes for the Hyper-V switch: private, internal, and public. Do not confuse these with IP addressing schemes or any other networking configuration in a different technology.
The private switch allows communications among the virtual machines on the host and nothing else. Even the management operating system is not allowed to participate. This switch is purely logical and does not use any physical adapter in any way. “Private” in this sense is not related to private IP addressing. You can mentally think of this as a switch that has no ability to uplink to other switches.
The internal switch is similar to the private switch with one exception: the management operating system can have a virtual adapter on this type of switch and communicate with any virtual machines that also have virtual adapters on the switch. This switch also does not have any matching to a physical adapter and therefore also cannot uplink to another switch.
This switch type must be connected to a physical adapter. It allows communications between the physical network and the management operating system and virtual machines. Do not confuse this switch type with public IP addressing schemes or let its name suggest that it needs to be connected to a public-facing connection. You can use the same private IP address range for the adapters on an external virtual switch that you’re using on the physical network it’s attached to.
Conceptualizing the External Virtual Switch
Part of what makes understanding the external virtual switch artificially difficult is the way that the related settings are worded. In the Hyper-V Manager GUI, it’s worded as “Allow management operating system to share this network adapter”. In the PowerShell “New-VMSwitch” command (2012 only), there’s an “-AllowManagementOS” boolean parameter which is no better, and its description — “Specifies whether the parent partition (i.e. the management operating system) is to have access to the physical NIC bound to the virtual switch to be created.” — makes it worse. What seems to happen far too often is that people read these and think of them like this:
Unfortunately, this is not at all what really happens. Once you create an external virtual switch, there is absolutely nothing connected to the physical adapter except the virtual switch. There is no exception to this. Trying to connect something else to the adapter will break the way that the virtual switch works. Instead of “sharing” the adapter, the management OS is given a virtual adapter that connects to the virtual switch just like the adapters in the virtual machines. This is a more proper visualization:
The above is the way that the external switch always works. If you don’t select the option to “share” the adapter or if you set “-AllowManagementOS” to False, then the item shown as “Management OS Virtual Adapter” is simply not created. That’s the only difference. The physical NIC is never used for any other purpose except hosting the virtual switch.
Have you ever tried to use Hyper-V Manager from a remote system to create a virtual switch on a host and set that Allow option, only to have Hyper-V Manager stop responding? This is why. The IP settings are unbound from the physical adapter, the virtual switch is activated on it, a new virtual adapter for the management operating system is created, and the IP settings are assigned to it. If you’re connected in remotely via that adapter, this doesn’t work because the process necessarily involves a disconnect.
In 2012, if you opt to create the virtual switch but don’t choose the option to “share”, there’s nothing stopping you from using PowerShell to immediately create a virtual adapter on the switch. In either version, you can immediately check the “Allow” box in Hyper-V Manager. The “allow” wording, unfortunately, doesn’t actually mean “allow”. It just means “create a virtual adapter right now and designate it for the management operating system”. In fact, if you don’t initially set “allow” but use PowerShell to attach a virtual adapter for the management operating system later, you’ll find that these options have been set to checked or True. I usually don’t use the “allow” option because I’d rather design my own virtual adapters than have to go back and modify an automatically created one.
What’s Coming Up In Part 2
Part 2 of the series will expand on this knowledge by showing you what can and can’t be done with the virtual switch beyond simply plugging in virtual adapters.
Have any questions or feedback?
Leave a comment below!