The Really Simple Guide to Hyper-V Networking

The Really Simple Guide to Hyper-V Networking

If you’re just getting started with Hyper-V and struggling with the networking configuration, you are not alone. I (and others) have written a great deal of introductory material on the subject. But, we often throw too much into it. I’m going to try a different approach. Rather than a thorough deep-dive, I’m going to show you what you’re trying to accomplish. After that, I will provide links to the detailed information so that you can turn those goals into reality.

Getting Started with Hyper-V Networking

First things first. If you have a solid handle on layer 2 and layer 3 concepts, that’s helpful. If you have experience with networking Windows machines, that’s also helpful. If you come to Hyper-V from a different hypervisor, then that knowledge won’t transfer well. If you apply ESXi networking design patterns to Hyper-V, then you will create a jumbled mess that will never function correctly or perform adequately.

Goals for Hyper-V Networking

You have two very basic goals:

  1. Ensure that the management operating system can communicate on the network
  2. Ensure that virtual machines can communicate on the network

Hyper-V Networking Configuration

Any other goals that you bring to this endeavor are secondary, at best. If you have never done this before, don’t try to jump ahead to routing or anything else until you achieve these two basic goals.

Hyper-V Networking Rules

Understand what you must, can, and cannot do with Hyper-V networking:

  • You can connect the management operating system to a physical network directly using a physical network adapter or a team of physical network adapters.
    rsn_managementos_connect
  • You cannot dedicate any physical adapter or team to a virtual machine.
    rns_vm_nopnic
  • You can connect a virtual machine to the physical network, but you must use a Hyper-V virtual switch. There is no bypass or pass-through mode.
    rsn_vm_connect
  • A Hyper-V virtual switch completely consumes a physical network adapter or team. It totally takes over that adapter or team; nothing else can use it.
    rsn_clutchedadapter
  • You can connect the management operating system to a Hyper-V virtual switch. It is not required.
    rsn_mos_via_vnic
  • It is not possible for the management operating system and the virtual switch to use a physical adapter or team at the same time. The “share” terminology that you see in all of the tools is a lie.
    rsn_mosorvs

What the Final Product Looks Like

It might help to have visualizations of correctly-configured Hyper-V virtual switches. I will only show images with a single physical adapter. The principles are identical if you use a team instead.

Networking for a Single Hyper-V Host, the Old Way

An old technique has survived from the pre-Hyper-V 2012 days. It uses a pair of physical adapters. One belongs to the management operating system. The other hosts a virtual switch that the virtual machines use. I don’t like this solution for a two-adapter host. It leaves both the host and the virtual machines with a single point of failure. However, it could be useful if you have more than two adapters and create a team for virtual machines to use. Either way, this design is perfectly viable whether I like it or not.

rsn_vswitch_split

 

Networking for a Single Hyper-V Host, the New Way

With teaming, you can join all of the physical adapters together. Let the team host a single virtual switch. Let the management operating system and all of the guests connect through that.

rsn_vswitch_unified

 

Networking for a Clustered Hyper-V Host

For a stand-alone Hyper-V host, the management operating system only requires one connection to the network. Clustered hosts benefit from multiple connections. Before teaming was directly supported, we used a lot of physical adapters to make that happen. Now we can just use one big team to handle our host and our guest traffic. That looks like this:

rns_vswitch_cluster

 

VLANs

VLANs seem to have some special power to trip people up. A few things:

  • The only purpose of a VLAN is to separate layer 2 (Ethernet) traffic.
  • VLANs are not necessary to separate layer 3 (IP) networks. Many network administrators use VLANs to create walls around specific layer 3 networks, though. If that describes your network, you will need to design your Hyper-V hosts to match. If your physical network doesn’t use VLANs, then don’t worry about them on your Hyper-V hosts.
  • Do not create one Hyper-V virtual switch per VLAN the way that you configure ESXi. Every Hyper-V virtual switch automatically supports untagged frames and VLANs 1-4096.
  • Hyper-V does not have a “default” VLAN designation.
  • Configure VLANs directly on virtual adapters, not on the virtual switch.

Other Quick Pointers

I’m going to provide you with some links so you can do some more reading and get some assistance with configuration. However, some quick things to point out:

  • The Hyper-V virtual switch does not have an IP address of its own.
  • The Hyper-V virtual switch does not appear anywhere in the regular Windows GUI. You can’t see it in the regular network connections list. You might find a logical team adapter and you might find virtual adapters that belong to the management operating system, but the switch is not there.
  • You do not manage the Hyper-V virtual switch via an IP or management VLAN. You use tools in the management or a remote operating system (Hyper-V Manager, PowerShell, and WMI/CIM). The Hyper-V virtual switch does not have an IP address of its own.
  • Network connections for storage (iSCSI/SMB): Preferably, network connections for storage will use dedicated, unteamed physical adapters. If you can’t do that, then you can create dedicated virtual NICs in the management operating system
  • Multiple virtual switches: Almost no one will ever need more than one virtual switch on a Hyper-V host. If you have VMware experience, especially do not create virtual switches just for VLANs.
  • The virtual machines’ virtual network adapters connect directly to the virtual switch. You do not need anything in the management operating system to assist them. You don’t need a virtual adapter for the management operating system that has anything to do with the virtual machines.
  • Turn off VMQ for every gigabit physical adapter that will host a virtual switch. If you team them, the logical team NIC will also have a VMQ setting that you need to disable.

For More Information

I only intend for this article to be a quick introduction to show you what you’re trying to accomplish. We have several articles to help you dive into the concepts and the necessary steps for configuration.

 

Note: this page was originally published in January 2018 and has been updated to be relevant as of December 2019.

Share this post