Windows Server 2019 – Using virtual switches

How to install web server (IIS) on Windows Server 2019

Upon completion of the Hyper-V role installation, your first inclination may be to jump right in and start creating VMs, but you should really take a minute to make sure that the networking capabilities of your Hyper-V Server are adequate to meet your needs. During the role-installation process, we selected the physical NICs that are to be passed through into Hyper-V, and that screen told us it was going to establish a virtual switch for each of these NICs. But what does that look like inside the console? And what options do we have for establishing networking between our virtual machines?

In order to answer these questions, we need to open up the management interface for Hyper-V. As with any administrative tool of a Windows role, check inside the Tools menu of Server Manager, and now that the role has been installed, you will see a new listing for Hyper-V Manager. Launch that and we are now looking at the primary platform from which you will be managing and manipulating every aspect of your Hyper-V environment:

We currently have a lot of blank space in this console, because we don’t have any VMs running yet. Over on the right side of Hyper-V Manager, you can see a link that says Virtual Switch Manager…. Go ahead and click on that link to be taken into the settings for our virtual switches and networking:

Toward the left, you see a list of current  Virtual Switches. On my server, there is only one switch listed there at the moment, which is named after the physical NIC to which it is connected. This is the virtual switch that the role-installation process created for us when we selected the NIC to be included with Hyper-V. If you selected multiple NICs during the role installation, you will have multiple virtual switches available here, each corresponding to a single physical NIC. Every VM that you create will have one or more virtual NICs, and you will see shortly that you have the ability to choose where each of those virtual NICs gets connected. If there are five different physical networks that your VMs might need to contact, you can use five physical NICs in the Hyper-V Server, plug each one into a different network, and then have five virtual switches here in the console that your VM NICs can be plugged into.

As you can see in the previous screenshot, we have a button named Create Virtual Switch, which is self-explanatory. Obviously, this is where we go to create new switches, but there are three different types of switches that you can create. Let’s take just a minute to discuss the differences between them.

The external virtual switch

The external virtual switch is the most common type to use for any VMs that need to contact a production network. Each external virtual switch binds to a physical NIC that is installed onto the Hyper-V Server. If you click on an external virtual switch, you can see that you have some options for configuring this switch, and that you can even change a switch type. In the following screenshot, I have renamed my external virtual switch so that it is easier to identify when I decide to add additional NICs to this server in the future:

The internal virtual switch

Internal virtual switches are not bound to a physical NIC, and so if you create an internal virtual switch and connect a VM to it, that virtual machine will not be able to contact a physical network outside the Hyper-V Server itself. It’s sort of a middleman between the other two types of switch; using an internal virtual switch is useful when you want the VM traffic to remain within the Hyper-V environment, but still provide network connectivity between the VMs and the Hyper-V host itself. In other words, VMs connected to an internal virtual switch will be able to talk to each other, and talk to the Hyper-V Server, but not beyond.

The private virtual switch

The private virtual switch is just what the name implies: private. VMs plugged into the same private virtual switch can communicate with each other, but not beyond. Even the Hyper-V host server does not have network connectivity to a private virtual switch. Test labs are a great example of a use case for private virtual switches, which we will discuss immediately following this text, when we create a new virtual switch of our own.

Comments are closed.