I frequently write about all sorts of Hyper-V networking topics. I was surprised to learn that we’ve never published a unified article that gives a clear and complete how-to that brings all of these related topics into one resource. We’ll fix that right now.

Understanding the Basics of Hyper-V Networking

We have produced copious amounts of material explaining the various concepts around Hyper-V networking. I want to spend as little time as possible on that here. Comprehension is very important, though, so here’s an index of expository work:

  • How the Hyper-V Virtual Switch Works: If you don’t understand the contents of that article, you will have a very difficult time administering Hyper-V. Read it, and read it again until you have absorbed it. It answers easily 90% of the questions that I receive about Hyper-V networking. If something there doesn’t make sense, ask.
  • The OSI model and Hyper-V: A quick read on the OSI model and a brief introduction to its relevance to Hyper-V. If you’ve been skimming over the terms “layer 2” and “layer 3” because you don’t have a solid understanding of them, read it.
  • Hyper-V and VLANs: That article ties closely to the OSI article. VLANs are a layer 2 technology. Due to common usage, newcomers often confuse them with layer 3 operations. I’m frequently asked about trunking multiple VLANs into a virtual machine, even though I’m fairly certain that most people don’t really want to do that. This article should help you sort out those concepts.
  • Hyper-V and IP: That article also ties closely to the OSI article and contrasts against the VLAN article. It doesn’t contain a great deal of direct Hyper-V knowledge, but it should help fill any of the most serious deficiencies in TCP/IP comprehension.
  • Hyper-V and Link Aggregation (Teaming): That article describes the concepts around NIC teaming and addresses some of the myths that I encounter. The article that you’re reading now will bring you the “how”.
  • Hyper-V and DNS: If I were to compile a list of ridiculously simple technologies that people tend to ridiculously over-complicate, I’d place DNS in the top slot. Hyper-V itself cares nothing about DNS, but its management operating systems and guests care very much. Poor DNS configurations can be blamed for nearly all of the world’s technological ills. You must learn it. It won’t take long.
  • Hyper-V and Binding Order: Lots of administrators spend lots of time wringing their hands over network binding order. Stop. Only the DNS subsystem and one other thing (that I’ve now forgotten about) pay any attention to the binding order. If you get that, then you don’t really need to read the linked article.
  • Hyper-V and Load Balancing Algorithms: The “hows” of load balancing algorithms will be on display in the article that you’re reading. If you want to understand the “what” and the “why”, then follow the link.
  • Hyper-V and MPIO and Teaming for Storage: I see lots of complaints from people that create a switch independent team on a pair of 10GbE pipes that wind back to a storage array with 5x 10,000 RPM disks. They test it with a file copy and don’t understand why they can’t move 20Gbps. Invariably, they blame Hyper-V. If you don’t want to be that guy, the linked article should help.

That should serve as a decent reference on the concepts. If you don’t understand something written below, it’s probably because you don’t understand something linked above.

Contents of this Article

I will demonstrate common PowerShell and, where available, GUI methods for working with:

  • Standard network adapter teaming
  • Hyper-V virtual switch
  • Switch Embedded Teaming
  • Hyper-V virtual adapters

PowerShell or GUI?

Use PowerShell for quick, precise, repeatable, scriptable operations. Use the GUI to do the same amount of work in twice the time following four times as many instructions. I will show all of the PowerShell methods first for the benefit of those that just want to get things done. If you prefer to plod through dozens of GUI screens, scroll to the bottom half of the article. Be aware that many things can’t be done in the GUI.

If you’re just getting started with PowerShell, remember to use tab completion! It makes all the difference!

Creating and Working with Network Adapter Teams for Hyper-V in PowerShell

If you’re interested in Switch Embedded Teaming (Server 2016 only), then look a few headings downward. This section applies to the standard Microsoft teaming methods.

First things first. You need to know which adapters to add to the team. Discover your available adapters:

Get-NetAdapter -Physical

I’ll use my system for reference. I’ve renamed all of the adapters in my system so that I can recognize them. If your hardware supports Consistent Device Naming, then you’ll likely already have actionable names (like “Slot 4 Port 1”). If not, you’ll need to find your own way to identify adapters. I use my switch’s interface to enable the ports one at a time, identifying the adapters as they switch to Connected status.

Creating and Working with Network Adapter Teams for Hyper-V

The PowerShell cmdlets for networking allow you to use names, indexes, or descriptions to manipulate adapters. The teaming cmdlets only work with names.

Create a Windows Team

Create teams with New-NetLbfoTeam.

I use my demo machines’ “P*L” adapters for Hyper-V teams. One way to create a team for them:

New-NetLbfoTeam -Name vSwitch -TeamMembers PBL, PTL -TeamingMode SwitchIndependent -LoadBalancingAlgorithm Dynamic

I usually Name my team for the virtual switch that I create on it, but choose any name that you like. The TeamMembers field accepts a comma-separated list of the names of the physical adapters to add to the team. I promised not to go into detail on the options, and I won’t. Just remember that the other parameters and their values are selectable by tab completion. SwitchIndependent is the preferred teaming mode in most cases with LACP being second. I have never seen any compelling reason to use a load balancing algorithm other than Dynamic. Most people will want to use the Dynamic load balancing algorithm as it combines the best of Hyper-V Port mode and the hash mode along with some special features that can relocate traffic dynamically. However, if you will be combining Switch Independent and Dynamic with an external third-party load balancer, I recommend that you read the comment section for helpful warnings from reader Jahn.

To save even more time and space, the cmdlet is smart enough to allow you to use wildcards for the adapter names:

New-NetLbfoTeam -Name vSwitch -TeamMembers P*L -TeamingMode SwitchIndependent -LoadBalancingAlgorithm Dynamic

If you want to avoid the prompt for scripting purposes, add the Force parameter.

A Note on the Team NIC

When you create a team, you also create a logical adapter that represents that team. A logical team NIC (often abbreviated as tNIC) works in a conceptually similar fashion to a Hyper-V virtual NIC. You treat it just like you would a physical adapter — give it an IP address, etc. The team determines what to do with your traffic. If you use the cmdlets as shown above, one team NIC will be created and it will have the same name as the team (“vSwitch”, in this case). You can override that name with the TeamNicName parameter.

You can also add more team NICs to a team. For a team that hosts a Hyper-V virtual switch, it’s neither recommended nor supported, although the system will allow it. Additional tNICs must be created in their own VLAN, which hides that VLAN from the team. Also, it’s not documented or clear how additional tNICs affect any QoS settings on a Hyper-V virtual switch.

For the rest of this article, the single automatically-created tNIC will be the only one referenced.

Examine Teams and tNICs

View all teams and their statuses with Get-NetLbfoTeam. You don’t need to supply any parameters. I get more use out of Get-NetLbfoTeamMember, also without parameters.

Remove and Add Team Members

You can easily remove team members if you have the need:

Remove-NetLbfoTeamMember -Name PBL -Team vSwitch

And add them:

Add-NetLbfoTeamMember -Name PBL -Team vSwitch

Removing an adapter obviously disrupts the traffic on that member, but the team will handle it well. You can add a team member at any time.

Delete a Team

Use Remove-NetLbfoTeam to get rid of a team. You can use the Name parameter to reverse what you’ve done. Since my hosts only ever use a single team, I can do this:

Get-NetLbfoTeam | Remove-NetLbfoTeam

Working with the Hyper-V Virtual Switch

I always use Hyper-V virtual switches and Microsoft teams together, so I have a certain technique. You may choose a different path. Just understand that external switches must be created on an adapter. I will always use the default tNIC. If you’re not teaming, then you’ll pick a single physical NIC. Use Get-NetAdapter as shown in the teaming section above to determine the name of the adapter that you wish to use.

Create a Virtual Switch

Use New-VMSwitch to create a new switch. Most commonly, you’ll want the external type (refer to the articles linked at the beginning if you need an explanation). External switches require you to specify a logical or physical (but not virtual) adapter. You can use its friendly name or its less friendly description. I use the name. In my case, I’m binding to a team’s logical adapter, so, as explained a bit ago, I’ll use the team’s name.

New-VMSwitch -Name vSwitch -NetAdapterName vSwitch -AllowManagementOS $false -MinimumBandwidthMode Weight

For internal or private, use the SwitchType parameter instead of the NetAdapterName parameter and do not use AllowManagementOS.

New-VMSwitch -Name vSwitchInternal -SwitchType Internal -MinimumBandwidthMode Weight

Several things to note about the New-VMSwitch cmdlet:

  • New-VMSwitch is not one of the better-developed cmdlets. Usually, when tabbing through available parameters, your options are presented in a sensible order. New-VMSwitch’s parameters are all over the place.
  • The documentation for every version of New-VMSwitch always says that the default MinimumBandwidthMode is Weight. I used to classify this as an error, but it’s been going on for so long I’m starting to wonder if it’s an unfunny inside joke or a deliberate lie. The default is Absolute. Most people won’t ever need QoS, so I don’t know that it has practical importance. However, you can’t change a switch’s QoS mode after it’s been created, so I’d rather tell you this up front.
  • The “AllowManagementOS” parameter’s name is nonsense. What it really means is “immediately create a virtual adapter for the management operating system”. The only reason that I don’t allow it to create one is because it uses the same name for the virtual adapter as the virtual switch. That’s confusing for people that don’t know how all of this works. You can always add virtual adapters later, so the “allow” verb makes no sense whatsoever.

Manipulate a Virtual Switch

Use Set-VMSwitch to make changes to your switch. The cmdlet has so many options that I can’t rationally explain it all. Just scan the parameter list to find what you want. A couple of notes, though:

  • You can’t change the QoS mode of an existing virtual switch.
  • You can switch between External, Internal, and Private types.
    • To go from External to either of the other types: Set-VMSwitch -Name vSwitch -SwitchType Internal. Just use Private instead of Internal if you want that switch type.
    • To from Private or Internal to External: Set-VMSwitch -Name vSwitch -NetAdapterName vSwitch. You’d also use this format to move a virtual switch from one physical/logical network adapter to another.
  • You can’t rename a virtual switch with this cmdlet. Use Rename-VMSwitch.

Remove a Virtual Switch

Appropriately enough, Remove-VMSwitch removes a virtual switch.

Remove-VMSwitch -Name vSwitch

You can remove all virtual switches in one shot:

Get-VMSwitch | Remove-VMSwitch

When a switch is removed, virtual NICs on VMs are disconnected. Virtual NICs for the management OS are destroyed.

Speaking of virtual NICs, that’s the next thing you care about if you’re using a standard virtual switch. I’ll explain them after the Switch Embedded Team section.

Working with Hyper-V Switch Embedded Teams

Server 2016 adds Switch Embedded Teaming. If you’re planning to create a team of gigabit adapters, then I recommend that you use the traditional teaming method outlined above. I wrote an article explaining why.

Create a Switch Embedded Team (SET)

Use the familiar New-VMSwitch to set it up, but add the EnableEmbeddedTeaming option. Two other options not shown in the following are EnableIov and EnablePacketDirect.

New-VMSwitch -Name SETSwitch -NetAdapterName PBL, PTL -EnableEmbeddedTeaming $true  -MinimumBandwidthMode Weight

The documentation continues to be wrong on MinimumBandwidthMode. If you don’t specify otherwise, you get Absolute. Prefer Weight.

Use EnableIov if, and only if, you have 10GbE adapters that support it. I cannot find any details on Packet Direct anywhere. Everyone just repeats that it provides a low-latency connection that bypasses the virtual switch. A few sources add that it will force Hyper-V Port load balancing mode. My hardware doesn’t support it, so I can’t test it. I assume that it only works on 10GbE and probably only with SR-IOV.

Once a SET has been created, you view it with both Get-VMSwitch and Get-VMSwitchTeam. For whatever reason, they decided that the output should include the difficult-to-read interface descriptions instead of names like Get-NetLbfoTeam. You can see the adapter names with something like this:

Get-VMSwitchTeam | select Name, @{Name='Adapter Name'; Expression= { (Get-NetAdapter -InterfaceDescription $_.NetAdapterInterfaceDescription).Name } }

The SET cmdlets have no analog for Get-NetLbfoTeamMember.

SET does not expose a logical adapter to Windows the way that LBFO does.

Manipulate a Switch Embedded Team

You can change the members and the load balancing mode for a SET using Set-VMSwitchTeam.

Set-VMSwitchTeam -Name SETSwitch -LoadBalancingAlgorithm HyperVPort -NetAdapterName PBL

Add and Remove SET Members

Instead of Set-VMSwitchTeam, you can use Add-VMSwitchTeamMember and Remove-VMSwitchTeamMember.

Remove-VMSwitchTeamMember -VMSwitchName SETSwitch -NetAdapterName PBL
Add-VMSwitchTeamMember -VMSwitchName SETSwitch -NetAdapterName PBL

Remove a SET

Use Remove-VMSwitch to remove a SET. There is no Remove-VMSwitchTeam cmdlet.

Working with Virtual Network Adapters

You can attach virtual network adapters (vNICs) to the management operating system or virtual machines. You’ll most commonly use them with virtual machines, but you’ll also usually do less work with them. Their default settings tend to be sufficient and you can work with them through their owning virtual machine’s GUI property pages.

For almost every vNIC-related cmdlet, you must indicate whether you’re working with a management OS vNIC or a VM’s vNIC. Do this with the ManagementOS switch parameter or by supplying a value for either the VM or the VMName parameters. If you have a vNIC object, such as the one output by Get-VMNetworkAdapter, then you can pipe it to most of the vNIC cmdlets or provide it as the VMNetworkAdapter parameter. You won’t need to specify any of the other identifying parameters, including those previously mentioned in this paragraph, when you provide the vNIC object.

View a Virtual Network Adapter

The simple act of creating a virtual machine or virtual switch with AllowManagementOS set, creates a vNIC. To view them all:

Get-VMNetworkAdapter -ManagementOS
Get-VMNetworkAdapter -VMName *

Ordinarily, we give descriptive names to management OS vNICs, especially when we use more than one. If you didn’t specify AllowManagementOS, then you’ll have a vNIC with the same name as your vSwitch.

Get-VMNetworkAdapter -ManagementOS -Name vSwitch

Each management OS vNIC will appear in the Network Connections applet and Get-NetAdapter with the format vEthernet (vNICName). Avoid confusion by changing the default vNIC’s name (shown in a bit). Many newcomers believe that this vNIC is the virtual switch because of that name. You cannot “see” the virtual switch anywhere except in Hyper-V-specific management tools.

Ordinarily, we leave the default name of “Network Adapter” for virtual machine vNICs. New in 2016, changes to a guest’s vNIC name will appear in the guest operating system if it supports Consistent Device Naming (CDN).

Manipulate a Virtual Network Adapter

Use Set-VMNetworkAdapter to change vNIC settings. As you can see, this cmdlet is quite busy; I could write multiple full-length articles on various parameter groups. Settings categories available with this command:

  • Quality of service (Qos)
  • Security (MAC spoofing, router guard, DHCP guard, storm)
  • Replica
  • In-guest teaming
  • Performance (VMQ, IOV, vRSS, Packet Direct)

You need a different cmdlet for VLAN manipulation, though.

Manipulate Virtual Network Adapter VLANs

Use Set-VMNetworkAdapterVlan for all things VLAN on vNICs.

To place a management OS vNIC into a VLAN:

Set-VMNetworkAdapterVlan -ManagementOS -VMNetworkAdapterName LiveMigration -Access -VlanId 25

Remember that the VlanId parameter requires the Access parameter.

Also remember that there is no such thing as “VLAN 0”. For some unknown reason, the cmdlet will accept it and assign the adapter to VLAN 0, but strange things might happen. Usually, it’s just that you can’t get traffic in or out of the adapter. If you want to clear the adapter’s VLAN, don’t use VLAN 0. Use Untagged:

Set-VMNetworkAdapterVlan -ManagementOS -VMNetworkAdapterName LiveMigration -Untagged

I’m not going to cover trunking or private VLANs. Trunking is very advanced and I don’t think more than 5 percent of the people that have asked me how to do it really wanted to do it. If you want a single virtual machine to exist in multiple VLANs, add virtual adapters and assign individual VLANs. Private VLANs require you to work with PrimaryVlanId, SecondaryVlanId, SecondaryVlanIdList, Promiscuous, Community, and Isolated as necessary. If you need to use private VLANs, then you or your networking engineer should already understand each of these terms and intuitively understand how to use the parameters.

Since we’re commonly asked, the Promiscuous parameter on Set-VMNetworkAdapterVlan does not have anything to do with accepting or participating in all passing layer 2 traffic. It is only for private VLANs.

Adding and Removing Virtual Network Adapters

Use Add-VMNetworkAdapter and Remove-VMNetworkAdapter for their respective tasks.

Add-VMNetworkAdapter -ManagementOS -Name 'Live Migration'
Add-VMNetworkAdapter -VM (Get-VM svdc02)
Add-VMNetworkAdapter -VMName svdc02 -Name 'PublicLDAPS'
Remove-VMNetworkAdapter -ManagementOS -Name 'vSwitch'
Get-VMNetworkAdapter -vm (get-vm svdc02) | where MacAddress -eq '000000000000' | Remove-VMNetworkAdapter

Connecting and Disconnecting Virtual Network Adapters to/from Virtual Switches

These cmdlets only work for virtual machine vNICs. You cannot dis/connect management OS vNICs; you can only add or remove them.

Connect always works. You do not need to disconnect an adapter from its current virtual switch to connect it to a new one. If you want to connect all of a VM’s vNICs to the same switch, specify only the virtual machine in VMName.

Connect-VMNetworkAdapter -VMName svdc02 -SwitchName vSwitch

If you provide the Name parameter, then only that vNIC will be altered:

Connect-VMNetworkAdapter -VMName svdc02 -SwitchName vPublicSwitch -Name PublicLDAPS

These two cmdlets do not provide a VM parameter. It is possible for two virtual machines to have the same name. If you need to discern between two VMs with the same name, use the pipeline and filter from other cmdlets:

Get-VMNetworkAdapter -VMName svdc02 | where MacAddress -eq 00155DD4D901 | Connect-VMNetworkAdapter -SwitchName vSwitch

Use Disconnect-VMNetworkAdapter the same way, leaving off the SwitchName parameter.

Disconnect-VMNetworkAdapter -VMName svdc02

VLAN information is preserved across dis/connects.

Other vNIC Settings

I did not touch on the entire range of possible vNIC cmdlets or their settings. You can go to the root 2016 Hyper-V PowerShell page and view all available cmdlets. Search the page for adapter, and you’ll find many hits.

Using the GUI for Hyper-V Networking

The GUI lags dramatically behind PowerShell for most things related to Hyper-V. I doubt any category shows that as strongly as networking. So, whether you (or I) like it or not, using the GUI for Hyper-V network qualifies as “beginner mode”. Most of the things that I showed you above cannot be done in the GUI at all. So, unless you’re managing a single host with a single network adapter, the GUI will probably not help you much.

The following sections show you the few things that you can do in the GUI.

Working with Windows Teams

The GUI does allow you some decent capability when working with Windows teams.

Create a Windows Team

You can use the GUI to create teams on Server 2012 and later. You can find the applet in Server Manager on the Local Server tab.

Using the GUI for Hyper-V Networking

You can also run lbfoadmin.exe from the Run window or an elevated prompt.

Once open, click the Tasks drop-down in the Teams section. Click New Team.

Tasks drop-down in the Teams section

You’ll get the NIC Teaming/New team dialog, where you’ll need to fill out most fields:

NIC Teaming/New team

Manipulate a Team

To make changes to your team later, just return to the same screens and dialogs using the same methods as you used to create the team.

Manipulate a Team

Delete a Team

To delete a team, use the Delete function in the same place on the main lbfoadmin screen where you found the New Team function. Make sure to highlight the team that you want to delete, first.

Delete a Team

Working with the Hyper-V Virtual Switch

The GUI provides very limited ability to work with Hyper-V virtual switches. You can’t configure QoS (except on vNICs) and it allows nearly nothing to be done for management OS vNICs.

Create a Hyper-V Virtual Switch

When using the Add Roles wizard to enable Hyper-V, you can create a virtual switch. I won’t cover that. If you’re looking at that screen, wondering what to do, I recommend that you skip it and follow the PowerShell directions above. If you simply must use a GUI, then wait until after the role finishes installing and create one using Hyper-V Manager.

To create a new virtual switch in Hyper-V Manager:

  1. Right-click the host in Hyper-V Manager and click Virtual Switch Manager. Alternatively, you’ll find this same menu at the far right of the main screen under Actions.
    Working with the Hyper-V Virtual Switch
  2. At the left of the dialog, highlight New virtual network switch.
    Create a Hyper-V Virtual Switch
  3. On the right, choose the type of switch that you want to create. I’m not entirely sure why it even asks because you can pick anything you want once you click Create Virtual Switch.
    Create a Hyper-V Virtual Switch Type
  4. The creation screen itself is very busy. I’ll tackle that in a moment. First, look to the left of the dialog at the blue text. It’s a new entry named New Virtual Switch. It represents what you’re working on now. If you change the name, you’ll see this list item change as well. You can use Apply to make changes and continue working without closing the dialog. You can even add another switch before you accept this one.
    New Virtual Switch

Now for the new switch screen. Look after the screenshot for an explanation of the items:

Virtual Switch properties - Hyper-V Networking

First item: name your switch.

I would skip the notes field, especially in a failover cluster.

For Connection Type, you’re decided between External, Internal, and Private. That’s why I don’t understand why it asked you on the initial dialog. If you choose External, you’ll need to pick a logical or physical adapter for binding. Unfortunately, you can only see the fairly useless adapter description fields. Look in the Network Connections applet to determine which is which. This right here is one of the primary reasons I like switch creation in PowerShell better.

Remember that the IOV setting is permanent.

I despise the item here called Allow management operating system to share this network adapter. That description has absolutely no relation to what the checkbox does. If you check it, it will automatically create a virtual NIC in the management OS for this virtual switch and give it the same name as the virtual switch. That’s all it does. There is no “sharing”, and there is no permanent allowing or disallowing going on.

The VLAN ID section ties to the nonsensical “Allow…” field. If you let the system create a management OS vNIC for you, then you can use this to give it a VLAN ID.

You can use the Remove button if you decide that you don’t want to create the virtual switch after all. Cancel would work, too.

Where’s the QoS? Oh, you can’t set the QoS mode for a virtual switch using the GUI. PowerShell only. If you use this screen to create a virtual switch, it will use the Absolute QoS mode. Forever. Another reason to choose PowerShell.

Manipulate a Virtual Switch

To make changes to a virtual switch, follow the exact steps that you did to create one, except choose the existing virtual switch at the left of the Virtual Switch Manager dialog. Of course, you can’t change much, but there it is.

Remove a Virtual Switch

Retrace your creation steps. Select the virtual switch at the left of the Virtual Switch Manager screen. Click the Remove button at the bottom right.

Working with Hyper-V Switch Embedded Teams

You can’t use the GUI to work with Hyper-V SET. PowerShell-only.

You can use the Virtual Switch Manager as described previously to remove one, though.

Working with Hyper-V Virtual Network Adapters

The GUI provides passably decent ability to work with vNICs — for guests. The only place that you can do anything with management OS vNICs is on that virtual switch creation screen. You can add or remove exactly one vNIC and you can set or remove its VLAN. You can’t use the GUI to work with two or more management OS vNICs. In fact, if you use PowerShell to add a second management OS vNIC, all related items in the dialog are grayed out and unusable.

But, for virtual machines, the GUI exposes most functionality.

Manipulate Virtual Network Adapters on Virtual Machines

In Hyper-V Manager or Failover Cluster Manager, open up the Settings dialog for the virtual machine to work with. On the left, you can find the vNIC that you want to work with. Highlight it, and the page will switch to its configuration screen. In the following screenshot, I’ve also expanded the vNIC so that you can see its subtabs, Hardware Acceleration and Advanced Features.

Manipulate Virtual Network Adapters on Virtual Machines

On this screen, you can change the virtual switch this adapter connects to, or disconnect it. You can change or remove its VLAN. You can set its QoS. The numbers here are given in Absolute since that’s the default. It doesn’t change if your switch uses Weight mode. I would use PowerShell for that. You can also Remove the vNIC here.

The Hardware Acceleration subtab:

Hardware Acceleration

Here, you can change:

  • If a VMQ can be assigned to this vNIC. The host’s adapters must support VMQ and a queue must be available for this checkbox to have any effect.
  • IPSec task offloading. If the host’s physical adapter supports IPSec task offloading and has sufficient resources, the guest can offload IPSec tasks to the hardware.
  • An SR-IOV virtual function can be assigned to this NIC. The host’s adapters and motherboard must support IOV, it must be enabled on the adapter and in BIOS, the virtual switch must either be unteamed or on a SET, and a virtual function must be available for this checkbox to have any effect.

The Advanced Features subtab:

Advanced Features

Note that this screen scrolls, and I didn’t capture it all.

Here, you can change:

  • MAC address, mode and address both
  • Whether or not the guest can spoof the MAC
  • If the guest is prevented from receiving DHCP discover/request frames
  • If the guest is prevented from receiving router discovery packets
  • If a failover cluster will move the guest if it loses network connectivity (Protected network)
  • If the vNIC’s traffic is mirrored to another vNIC. This feature seems to have troubles, FYI.
  • If teaming is allowed in the guest. The guest requires at least two vNICs and the virtual switch must be placed on a team or SET for this to function.
  • The Device naming switch allows the name of the vNIC to be propagated into the guest where an OS that supports Consistent Device Naming (CDN) can use it. Note that this is disabled by default, and the GUI doesn’t allow you to rename the vNIC. Use PowerShell for that.

Remove a Virtual Network Adapter

To remove a vNIC from a guest, find its tab in the VM’s settings dialog in Hyper-V Manager or Failover Cluster Manager. Use the Remove button at the bottom right. You’ll find a screenshot above in the Manipulate Virtual Network Adapters on Virtual Machines section.

 

Note: This guide will be periodically updated to make sure it covers all possible Hyper-V Networking problems. If you think I’ve missed anything please let me know in the comments below.

 

Is Your Office 365 Data Secure?

Did you know Microsoft does not back up Office 365 data? Most people assume their emails, contacts and calendar events are saved somewhere but they're not. Secure your Office 365 data today using Altaro Office 365 Backup - the reliable and cost-effective mailbox backup, recovery and backup storage solution for companies and MSPs

Share this post

Not a DOJO Member yet?

Join thousands of other IT pros and receive a weekly roundup email with the latest content & updates!

26 thoughts on "The Complete Guide to Hyper-V Networking"

  • Jahn says:

    Hi Eric.
    Can you please elaborate why do you prefer switch independent to LACP?

    “I have never seen any compelling reason to use a load balancing algorithm other than Dynamic.”
    The combination of Switch Independent teaming mode and dynamic load balancing mode can cause issues since the source MAC address is replaced when packages is sent on a team member other than the affinitized one. I have seen this cause issues with non-Microsoft load balancer.

    • Eric Siron says:

      I was a BIG fan of LACP and I used it on EVERYTHING. My little Netgear switch handled it great, and loved it!
      And then one day, someone reported to me that, when one leg of a LACP system failed while connected to a fancy eleventy-billion dollar Cisco switch, it took over a minute for communications to transfer to the other leg. So, we spent hours troubleshooting it with our Cisco engineers. Then we opened up a case with Microsoft that stretched over weeks. Their final conclusion: “Meh, that happens.” Seriously, that was it. I mean, I’m paraphrasing a bit, but they found nothing wrong and took no interest in pursuing it. The more I dug, the more I found out that our experience lies somewhere between semi-rare and common.
      So, I did a lot of performance testing. Even under stress, a functioning LACP system doesn’t give much more than Switch Independent. In normal operating conditions, no difference could be detected. Switch Independent has a greater success rate with a nearly identical performance profile. So, I use Switch Independent.

      I have not seen a report about the MAC causing issues before. Is it only with 3rd party load balancers or does it manifest in other uses? What mode do you use instead?

      • Jahn says:

        F5 BIG-IP has named this feature “auto last hop”. Other LB vendors might have a different name for the same feature. Citrix Netscaler also seems to the same issue.

        From https://support.f5.com/csp/article/K13876
        “Auto Last Hop is a setting that allows the BIG-IP system to track the source MAC address of incoming connections and return traffic from pools to the source MAC address, regardless of the routing table.”

        After weeks with Microsoft premiere support, upgrading firmware/drivers of the nics, testing different teaming and load balancing modes, private hotfixes, Microsoft support concluded that F5 BIG-IP did not support switch independent/dynamic mode or their implementation don’t follow Microsoft “standard”.

        We could disable auto last hop on F5 BIG-IP, but since there might be other applications that could face the same issue we decided to change LB mode on the Hyper-V hosts to Hyper-V port. Currently our clusters run either Switch independent/Hyper-V port or LACP/Dynamic.

        We had some issues with LACP about 18 months ago. The support case with Microsoft and Cisco solved nothing so we decided to replace our Cisco edge switches with switches from a different vendor. We have not had any issues with LACP since.

        You seems to be familiar with this thread regarding the source mac replacement issue, but your view on LACP have changed. 🙂
        https://social.technet.microsoft.com/Forums/office/en-US/b698bf90-153b-466b-a078-8355ce730a91/dynamic-lbfo-load-balancing-mode-causing-issues

        • Eric Siron says:

          That’s really interesting. Sorry that your problem wasn’t really resolved. What are the symptoms of the problem with the F5 and Dynamic/SI?

          • Jahn says:

            The vm will start by sending a SYN package to F5, but the source MAC is replaced by the host when packages is sent on a team member other than the affinitized one.
            F5 respond with SYN ACK, but since it contain the wrong MAC, the vm will not receive it and an ACK will not be sent back to F5.
            F5 will do a retransmission of the SYN ACK a couple of times and a timeout will occur.

          • Eric Siron says:

            Thank you for the information!

  • Victor says:

    Great guide!!!!!
    Can we download in PDF format? It would be a excellent tool!

    Many thanks!

  • Danny says:

    Hi Eric,

    great post and I think I understood the most.

    But still…

    I have a physical machine with one nick behind a firewall which is the DHCP server.
    On this physical machine, I have Hyper-V core 2016 running.

    I’ve created an external vswitch and assigned the physical nic to it. So the HyperV got a virtual nic attached to the external switch and works just fine.

    But when I connect the guest os to the external switch I’ve made, it gets an address thru DHCP but I cannot ping the firewall (Destination host unreachable). I cannot even ping the host machine which should be connected on the same vswitch. Though I can ping from the host to the guest…

    When I create an internal switch it all works but I get an IP from the internal switch. I need the machine to have an address out of the range my firewall deals out.

    I hope you can help me through this because I’m on the verge of

    • Eric Siron says:

      Hi Danny,
      To date, 100% of the time this problem has turned out to not be caused by Hyper-V. So, treat this as you would if the exact same thing happened on a physical system. You have a machine, connected to a switch, and the switch is connected to another switch, and the other switch has some path to an Internet-connected firewall. If it’s getting DHCP, then you know for a fact that it has layer two connectivity to whatever distributes IPs. Layer 2 is so simple that it must also have connectivity to everything else in that layer 2 broadcast network. So, now you’re looking for things like bad routing tables and MAC collisions and endpoint firewalls that block ICMP.

  • Ben Seroussi says:

    Hi Eric,

    Your posts are really helpful, I read everything related to this and new hyperv clust and then some more and I have a few question:

    I’m setting up a new 3 cluster environment, each 1 has 4X10 10gbe 2X1gbe(1 disabled and 1 for DMZ) and compelent SCv3020 storage. 2 new 10gbe switches (the rest are old 1gbe).

    1) All of the 10gbe ports are connected to the 10gbe switches (I wanted to be able to use the 10gbe for the VMs as well). Should I use SET with all the 4 adapters and create adapters for ISCSI and the cluster or should I use 2 with SETteam and keep the 2 ISCSI separate?

    2) Should I enable DCB? Can it work with normal cluster data on the switches?

    3) Anything else I might have overlooked?

    P.S. the 10gbe switches are connected with 2 cables each to the network backbone switch.

    • Eric Siron says:

      Sorry for the response delay.

      1. Because 10GbE is so fast, I would use SET for all adapters and then use vNICs for iSCSI
      2. If you have a use for DCB, sure. Cluster traffic is SMB so you would have to create a priority level for SMB.
      3. Don’t overthink it. 10GbE is fast. Anything beyond a basic connection is probably over-engineering.

Leave a comment or ask a question

Your email address will not be published. Required fields are marked *

Your email address will not be published. Required fields are marked *

Notify me of follow-up replies via email

Yes, I would like to receive new blog posts by email

What is the color of grass?

Please note: If you’re not already a member on the Dojo Forums you will create a new account and receive an activation email.

Related posts