After getting your Hyper-V server up and running, via whichever platform you choose to utilize, the next logical step will be to build a virtual machine, right? So why are we talking about networking? Because setting up the networks that your VMs are going to plug into is an important baseline and it is worth spending some time thinking about this before you start spinning up new VMs. Every virtual machine will have a network interface, sometimes more than one, and those NICs need to be plugged into a switch; just like with a physical server. Except that, in the virtual world, we don't use physical switches, we must tell the VMs which virtual switch to tap into. That means we must build these virtual switches in the first place, before we can start making any network connections possible to our VMs.
Planning the right number of physical NICs to be inside your Hyper-V host server is also important. Each physical NIC can only be plugged into one physical switch, obviously, and so if you plan to host virtual machines on this host server that need to tap into different physical networks, you will need multiple NICs to support that scenario. Each NIC on the physical host server can be plugged into a different switch, flowing traffic to a different area of your network. Then inside the Virtual Switch Manager, we can build virtual switches that correspond to these physical NICs, so that our VMs can be plugged into any piece of the physical network that we choose. As a simple example, think about a DirectAccess server that needs to be connected to both the internal corporate network and into a DMZ. You would need at least three NICs on that physical Hyper-V host server because one gets plugged into the internal network, one into the DMZ network, and also the host operating system on the Hyper-V server itself prefers to have an NIC dedicated to its own communications.
We are using Windows Server 2016 running Hyper-V, which has been hosting the virtual machines throughout this book. This server has just two NICs; unfortunately this is a limitation of the chassis on my test box. It would be much more common for a full-blown Hyper-V server to have more than two physical network interfaces.
Here are the steps you will need to take in order to create and manage the virtual networks on your Hyper-V server:
- Launch Hyper-V Manager from inside the Tools menu of Server Manager.
- You are presented with a list of virtual machines that are installed on this system, and over to the right side of the screen there is an Actions pane. Go ahead and click on the link for Virtual Switch Manager….
- This is the screen where you will define any switches that need to be available for the VM NICs to plug into. As you can see in the following screenshot, a switch is linked to my physical NIC on my Hyper-V host is connected to the corporate network, and this virtual switch was given the name Physical NIC when I initially installed the Hyper-V role. I can easily change that name from inside this screen to reflect whatever description I want.
- There are also two Private virtual switches that are currently configured on this server. These are switches I created in order to accomplish the server builds and testing that we have been doing throughout these chapters. As you can see, one is labeled Corp LAN, and the other is one I called Internet. Neither of these switches is connected to a physical NIC, so they aren't able to communicate outside this host server at all. These kinds of switch are useful for building out segregated test lab environments when you want to test new technologies.
- If you click on New virtual network switch, you see that you have the option of creating three different kinds of virtual switches.
- Let's take a minute to describe the differences between the three:
- External: This kind of virtual switch binds itself to a physical network adapter on the Hyper-V host server. When you connect VMs to an external virtual switch, they have the ability to flow traffic back and forth with that physical network.
- Internal: This kind of virtual switch does not bind to a physical NIC, and so the traffic generated in this switch cannot communicate outside the host system. However, the VMs that you connect to these switches are able to communicate with each other, and with the Hyper-V host system itself.
- Private: This kind of virtual switch is what I used for the test lab. It is a segregated switch, unable to talk to any of the physical NICs and also unable to communicate back with the Hyper-V host. Any VMs that you plug into a private switch will be able to communicate with each other, such as in the case of my Corp LAN switch, but they will be isolated to each other and nothing else.
- While I am using a brand new Windows Server 2016 for this recipe and the three standard types of switch are the only ones visible to me in the graphical interface, I would like to point out that there are now two additional types of Hyper-V switch, brand new in Server 2016 and available for us to use. Why are they not visible in the previous screenshot? Because if you want to use the new switch types, you will need to deploy them via PowerShell. Here is the summary information on the two new types of switch available to us on Windows Server 2016 Hyper-V servers that are running the Software Defined Networking (SDN) stack:
- External switch with Switch Embedded Teaming (SET) - SET is brand new in 2016 and allows us to create NIC teams right in a Hyper-V switch, a feature never available in prior versions of Hyper-V. You can group between one and eight physical NICs into virtual network adapters which will provide fault tolerance in the event of a single NIC failure. When using SET, it is important to know that all of the NIC adapters must be installed in the same physical Hyper-V host server, and the NICs must all be identical. You utilize the New-VMSwitch cmdlet combined with the EnableEmbeddedTeaming parameter in order to create a new SET virtual switch.
- NAT: Windows Server 2016 also includes a new Hyper-V switch type called NAT. You would establish this type of virtual switch when you need virtual machines to have a shared internal network, and connect to the external interfaces by using a NAT'd address instead of binding them directly to an external NIC and its own physical IP addressing. NAT is also not available from the graphical console when setting up a new Hyper-V switch; you use the
New-VMSwitchcmdlet combined with the-SwitchType NATparameter to build one. This new type of switch is particularly useful in a container scenario.
From the Hyper-V Virtual Switch Manager, you are able to very quickly create as many different virtual switches as you need to support the different kinds of virtual machines you are planning to create. In most testing environments, it makes the most sense to utilize internal or private switches, to make sure that traffic remains segregated on the host. However, when working with production servers and virtual machines, you will be working mostly with external switches that are bound to physical network cards in your Hyper-V host server. This enables you to assign IP addresses on your VMs and gives them the ability to communicate with your physical network and with places like the real Internet. It is important to have at least some of your virtual switches configured before you start creating a lot of VMs, because, as you will see in our next recipe, one of the options you can configure during the VM creation process is which virtual switch it should be connected to.