Hyper-V Networking Guide

If you’re a beginner at Hyper-V and need some help with configuring your network, or maybe you’re just interested in networking with virtualization software, then this is the article for you. Today we’ll be taking a deep dive into the world of Hyper-V networking.

Starting Out With Hyper-V Networking

Having a good understanding of layer 2 and 3 protocols is an excellent start for Hyper-V networking, as is any experience you might have setting up Windows machine networks.

What might come as a surprise is how little of your skills will transfer to Hyper-V if you’re coming from using a different hypervisor. Applying network design patterns from a different hypervisor like ESXi to a Hyper-V network will lead to you making nothing better than a pile of uncoordinated VMs that doesn’t even work properly.

Hyper-V Networking Aims & Rules

There are two main goals for you to keep in mind while configuring your Hyper-V network:

1. Make sure that the management operating system is capable of communicating within the network
2. Make sure that VMs can communicate with each other through the network

Additional goals past this are more likely to bring you trouble than anything else. If this is your first time using Hyper-V, or even just the first time you’re using it for networking, don’t start routing or doing anything else until these two goals are taken care of.

Next, it’s important for you to know what Hyper-V networking can do, what it can’t do, and what it’ll have to do:

Can Do:

• Use a physical network adapter(or a team thereof) in order to establish a connection between the management operating system and a physical network directly.
• Establish a connection between a VM and a physical network. With that being said, this has to be done through the Hyper-V virtual switch.
• Create a connection between the management operating system and a Hyper-V virtual switch.

Can’t Do:

• Dedicate a team of physical adapters or a single unit to a VM
• Make it possible for the management operating system and virtual switch to utilize the same physical team or single adapter at once. Although there is the “share” function, it does not apply to this scenario

Must-Do:

• Use the adapter or team taken up by the Hyper-V virtual switch for nothing else. It will be completely taken up by the Hyper-V virtual switch, rendering it useless for all other purposes.

The Hyper-V Networking Switch & Adapter

Operating networks in Hyper-V can be a very confusing experience for newbies. This is in part due to Hyper-V’s differences from most other hypervisors. The biggest source of confusion and difficulty stems from the Hyper-V virtual switch.

What Is A Hyper-V Virtual Switch?

The Hyper-V virtual switch is, quite literally, just a virtual switch. What this means is that the virtual switch is an entirely digital construction that works in the active memory of your Hyper-V host, performing Ethernet frame switching. The virtual switch can utilize network adapters both when they’re alone and when they’re teamed. They are used as uplinks in order to connect the virtual switch to a physical one, making communication with the physical network much simpler.

What Is A Virtual Network Adapter?

Much akin to the Hyper-V’s virtual switch, the network adapters are quite simple to explain in concept. Simply put, they are entirely digital constructions that are tasked with receiving and transmitting Ethernet frames.

Usually, a network adapter will belong to a VM. You can see this in a myriad of ways, however, the easiest two are through PowerShell and the Hyper-V Manager UI.

There, you can see the adapters within the hardware list, and you can also see what switches are connected to which adapter. These can be manipulated and switched up whenever you’d like. You can change it so that a virtual switch connects to a different adapter, or you can even disconnect them completely. With that being said, in Hyper-V, there’s no equivalent to a crossover cable, so you won’t be able to connect multiple adapters.

In a guest, you’ll find that the virtual adapter shows up everywhere that a physical adapter would.

Management operating system Virtual Adapters

It’s also possible to make virtual adapters through the management operating system. You’ll be able to take a look at these within PowerShell as well as every other place that you’d be able to find a physical adapter. You can tell them apart from physical adapters by their naming pattern which starts with vEthernet.

Now, much unlike virtual adapters for VMs, there are far fewer options when it comes to the management of the virtual adapters inside the management operating system. In case you’ve got one available, you can use the virtual network manager in order to set the VLAN up. In case you’ve got more than one, there’s no way in the GUI to do so.

So, what should you do if you’ve got multiples?

The sole way to do that is by using PowerShell. It’ll let you control the arrangement, as well as letting you change a variety of the management operating system’s settings for the visual adapters.

Modes of the Hyper-V virtual switch

There are three distinct modes that you can use with the virtual switch:

1. Private: The private virtual switch mode will only allow for communication between virtual adapters that have a connection to a VM.
2. Internal: This mode is used when you only want to allow communication between the adapters included in the private mode, as well as those maintaining a connection with the management operating system.
3. External: The final mode of operation will permit the communication of virtual adapters outlined in the internal mode, as well as using physical adapters and switches in order to enable communication with outside systems.

Understanding External Virtual Switches

The external mode of the Hyper-V virtual switch is one that causes the most issue for most users. Inside of the GUI, you can see the setting “Allow management operating system to share this network adapter.” Due to the setting’s name and PowerShell description, many people completely misunderstand how this mode is to be used.

The first thing you need to grasp is that, as you’ll see below, a physical adapter or adapter team cannot be simultaneously used by a virtual switch and something else. There is no way to share adapters with anything else. This also means that you’ll be unable to configure TCP/IP information on the adapter.

Once you’ve bound a virtual switch to a team of adapters or a single unit, it’ll appear as a “Hyper-V Extensible Virtual Switch.” After this, you shouldn’t mess with any of the protocols or services on the adapter. In the best-case scenario, this will do nothing, and in the worst case, it’ll lead to your switch breaking.

The “sharing” in this example happens in a different way. A virtual adapter is created for the management operating system, then it is attached to the same virtual switch that the VM is going to take advantage of. This lets you remove the adapter from the equation whenever you’d like without impacting the function of the virtual switch in the slightest. Take note that some wordings in the software are easy to misunderstand. Pressing “ Allow management operating system to share this network adapter” is not the only way to create a virtual adapter for the operating management system.

The only reason to tick that particular box is in case the management operating system needs the ability to communicate with the VM without an intermediary. In case you’re using a separate physical team of adapters or singular units in order to manage traffic, then there’s no need to use this option. On the other hand, if you’re planning to deal with network convergence, it’s one of the best tools at your disposal.

In case you’re uncertain of what you should do at the start, don’t worry too much about it. After you’ve created a switch, then you’ll be able to remove or add new adapters whenever you’d like. PowerShell is also a valid way to handle this if the GUI is confusing you.

Once you’ve grasped this, finding the difference between the external mode and its two counterparts becomes a walk in the park.

Single-Host Hyper-V Networking

There’s an older way of making a hyper-V network originating before the 2012 update. This method takes advantage of two physical adapters, one of which is assigned to the management operating system while the other one will host a virtual switch that the VM will use. Although the two-adapter host networking design can work, it does have the downside of leaving your host and VM with an individual point of failure. With that being said, it can be a viable strategy to take in specific circumstances, like having more than 2 adapters to make a team of VMs.

More Modern Hyper-V Networking

By teaming multiple adapters up, you can have all of them join in together. Then, once you’ve got your team set up, you can have it host a virtual switch. When you’re done with that, you can have the management operating system and guests use that to connect to the network.

Networking With A Clustered Host

Now, a standalone host makes it so that the management operating system needs just one connection to the network. Having a clustered host gives you the upside of having multiple connections. Now that teaming has direct support, there’s no longer a need to use physical adapters for this. It’s easy to simply have one large team to handle all kinds of traffic.

Incorporating VLAN

VLANs are one of the trickier networking elements to get right, there’s a couple of things to remember here:

• The main goal of using a VLAN is to have Ethernet(layer 2) traffic be separate from the rest.
• If you want to separate IP networks(layer 3), then you don’t need a VLAN for that. However, it is a relatively common practice to take advantage of VLANs in order to make walls around some layer 3 networks. With that being said, you only need to worry about this if your physical network takes advantage of VLANs, if not, don’t fret about it.
• Avoid making a Hyper-V virtual switch for every single VLAN in much the same manner you would configure ESXi. Any given Hyper-V virtual switch will support both untagged frames as well as VLANs.
• There is no default VLAN designation when using Hyper-V
• You should be configuring your VLANs right on the virtual adapters, rather than the virtual switch.

Hyper-V And DNS Issues

DNS issues are at fault for most Hyper-V problems we hear about. When you mix two commonly misunderstood technologies, you get a jumbled mess of easily preventable issues.

The first kind of issue we see pop up a lot regards guests. A lot of people will set up a VM and plug it into an internal or private virtual switch. The goal of doing this is to attain the superior speeds of the hardware instead of having an external switch.

Before we get into the DNS issues with this, there are a few things to clarify. First of all, the virtual switch already knows that it shouldn’t send local traffic out the physical uplink. Although this can get violated due to the source and destination IP not being on the same subnet. The other factor is the fact that internal and private switches generally don’t cause a significant increase in performance compared to network hardware.

There are, however, some merits to taking advantage of internal and private virtual switches. It is crucial that you have an idea of what the DNS is going to do in these cases. If you’re trying to communicate while using DNS names, then the source will just ask the DNS server for the IP, and it’ll get one. There won’t be any requests for an IP on a particular subnet or similar, due to the fact DNS doesn’t operate this way. It’ll simply give out whatever IP comes next. If you’re trying to essentially make communication happen on a particular switch, you’ll need to give it its own subnet. Afterward, it’s the simple task of using manual entries within the HOSTS file, or simply take advantage of custom A and CNAME records pointing to the IP you want.

The second issue Hyper-V can have with DNS is when you get multi-homed hosts involved. Quite often, I’ll see setups where there are dedicated management adapters, and the virtual switch adapters are then shared with the host. This kind of system is multi-homed. The issue with this is that every adapter that has a valid IP is already DNS-registered. Anything attempting to form communication with the multi-homed host by its name will wind up with a semi-random address from those provided with the DNS. The fix to this issue is just to disable the DNS registration in everything apart from the management adapter.

Some Tips

• If you were wondering what the Hyper-V virtual switch’s IP address was- know it has none.
• If you’re looking for the Hyper-V virtual switch through the usual Windows UI, then know it is a futile endeavor. It simply doesn’t show up, although some elements of the virtual network might.
• You can’t use an IP or management VLAN in order to manage the Hyper-V virtual switch. Instead of doing this, you’ll need to be using tools in the management, or a remote OS like the Hyper-V Manager.
• If you have SMB or iSCSI storage connections, then they will be using dedicated adapters. If you aren’t able to afford them dedicated physical adapters, virtual NCIs can do the trick too.
• There are pretty much no scenarios where you will need over one virtual switch per host. Seriously think about whether it’s really necessary if you ever want to add another.

Conclusion

Hyper-V networking can be a difficult beast to wrestle with. It’s so far removed from any other hypervisor that there are few to none transferable skills which make learning it easier.

The easiest way to learn more about Hyper-V networking is to follow this guide and read onward. While it’ll prepare you for the beginning, there’s an almost endless well of information on Hyper-V networks online, take advantage of it!

Did we miss something? Would you like a section explored in more detail? Let us know in the comment section below.

Hyper-V Networking Guide FAQs