Hyper-V Virtual Switch Explained

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.

Switch Modes

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.

Private Switch

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.

Internal Switch

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.

External 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:

An incorrect visualization of the Hyper-V Switch

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:

Correct Visualization of the Hyper-V External Switch

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 switch, 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.
In the first part of this series, we looked at the Hyper-V virtual switch on a conceptual level. In this second part, we’ll look at it from a more practical angle. Use cases for the virtual switch will be examined.

Private, Internal, and External Virtual Switches

Most switches will be used in external mode, as there is no other way to directly connect a virtual machine to a physical network. However, there are uses for the other two types. The two most common uses for a non-public switch are inter-system performance and isolation.

Performance

The private and internal switches are not connected to a physical switch in any way, so they are unbound from most of the limitations imposed on physical network equipment. Specifically, a virtual adapter on a private switch can communicate with other adapters on the same switch at the speed of the physical host’s system bus. The communications aren’t without cost. These are virtual network adapters and are still governed by the need to pass network protocols. Packet processing requires the same CPU resources as a physical adapter and, without the physical path as a bottleneck, this packet processing might become a measurable burden on your system in a way that gigabit networking never could be.
The thing to keep in mind is that private and internal switch communications cannot leave the physical host. If you set up two virtual machines so that they connect over a private switch and then one of those is Live Migrated to another host, the communications link will be broken. Because the Hyper-V switch is extensible, it is possible for this limitation to be overcome by supporting software, but Hyper-V cannot do it alone.

Isolation

Since the private and internal switches aren’t connected to a physical adapter, they are naturally isolated from anything not attached to the virtual switch. You could use this for critical systems that you don’t want exposed to other networks.

External and Private Switch

Advanced Configuration

Windows Server provides a role called Remote Access Service (Routing and Remote Access Service on earlier versions). This is a very powerful role with an impressive number of possible uses. Two that it can perform that would be of relevance in the above diagram are routing and network address translation (NAT). It would be installed on the virtual machine straddling both networks. You could then assign the machines on the private network to their own IP network. The system with RAS installed could then perform routing to indirectly connect them to the physical network. If you like, you can also use the NAT feature to provide an even greater level of isolation. To add a further level of automation, you could install DHCP in the straddling VM and allow it to service that network, or use DHCP relay.
If the adapters on a private or internal switch will be Live Migrated to another host, then it is possible to have them continue using a RAS system to connect. A straddling RAS system must exist on an identically-named switch on each host. There are a few ways to approach this, but the simplest way is to have each RAS server use a different IP address on the private/internal switch. The connected machines could be programmed with each possible RAS server’s address as a gateway, but they’ll also discover gateways on their local subnets. Unlike a regular Live Migration, these types of connections are likely to drop any active communication streams when they’re moved because of the way that they are presented to the network beyond the RAS systems.

Configuring the Hyper-V Switch

There isn’t a lot to configure. If you’re using Hyper-V Manager, start with the “Virtual Switch Manager…” link on the right. Unless your Hyper-V installation is a role inside a Windows Server with a GUI, you’ll have to run this remotely. Doing so can cause issues. If you create an external switch on the adapter that the system is using for its general network connectivity, that connection will be broken while the switch is created. This will cause the overall creation of the switch to fail. So, if you aren’t running Hyper-V within a GUI, either ensure that you are creating the adapter on an otherwise unused physical adapter. Otherwise, use PowerShell on the Hyper-V console.
New-VMSwitch is the command you use to actually create a switch. It only has a few options but covering them all is beyond the scope of a post of this nature. You can review them all on TechNet.
External switches must be created on a physical adapter (or a team of physical adapters) that is not used in any other virtual switch. Use “Get-NetAdapter” to list the adapters in the system. The Name field is what you’re looking for to create an external switch. The following is a sample creation command:

New-VMSwitch -Name "vSwitch" -NetAdapterName "Ethernet 2" -AllowManagementOS 0

There are a few things to note. First, if you wanted to use a private or internal switch, you’d use the -SwitchType variable with one of those two options. That parameter is not used in the above because the inclusion of the -NetAdapterName parameter automatically makes the switch external. Also, quality of service by absolute value is automatically set (the documentation for this cmdlet indicates it is minimum weight, which is incorrect). QoS is also beyond the scope of this post. As mentioned in part one of this post, setting AllowManagementOS to 0 just means that no virtual adapter is created now. If you set it to one, you’ll have a virtual adapter in the management OS that you’ll need to set configuration on.
To create a virtual adapter in the management operating system, you must use PowerShell (with the exception of the adapter that is automatically created if you set the “Allow” option. The creation command is on TechNet. An example:

Add-VMNetworkAdapter -SwitchName "vSwitch" -ManagementOS -Name "LiveMigration"

Adapter creation is pretty straightforward. You can create as many as you need for the various purposes you have in mind for your management OS installation. Multiple adapters in the management OS for a single virtual switch is of most value when used with teaming. Configuring a management OS adapter requires one major note: the OS sees it with a name of “vEthernet (name you used)”. That is the name you need to pass into any networking command that doesn’t include “VM” in the noun portion, such as New-NetIPAddress.
The last configuration option of importance in this discussion is VLAN settings for virtual adapters. The Hyper-V virtual switch is 802.1q-compliant and adapters attached to virtual machines and the management OS can be assigned to a VLAN. The virtual switch will trunk inbound and outbound packets properly. Setting the VLAN on a VM-connected adapter can be done through the VM’s properties in Hyper-V Manager. PowerShell can be used for any virtual adapter with the Set-VMNetworkAdapterVLAN command.

Set-VMNetworkAdapterVlan –ManagementOS –VMNetWorkAdapterName "LiveMigration" -Access –VlanId 10

There are many more options available for this particular command, but most of them are for advanced purposes, such as in a multi-tenanting environment.

Cluster

While these posts weren’t really about clustering, it is important to note that for virtual adapters on a highly available virtual machine to be able to continue connecting after a migration, it must connect to a virtual switch with the same name on each host. The exception is if it is assigned to a Network Resource Pool. However, the pool name must be identical on all hosts, so there isn’t much effective difference than just using the same virtual switch name. Resource pools are intended for resource metering and there’s not much benefit to using them otherwise.