Windows 10 – How to Fix Unintended Hyper-V Virtual Switches After Upgrade

hyper-vwindows 10windows updatewindows-10-v2004

This morning I upgraded my system to Windows 10 2004, the upgrade went smooth and was through Windows Update. I am using Hyper-V as my virtualization program for virtual machines and to provide extra layer of protection to the system through core isolation.

After the upgrade, I noticed that a new Virtual Switch was created with the name "vEthernet (Ethernet)" where "Ethernet" within the parentheses is the name of my primary network adapter. Also noticed this behavior has a specific pattern of creating new vSwitches correspond to the adapters you have, e.g. if you created a new Virtual Switch and restarted the system, a new additional switch will appear with the name "vEthernet (your-new-switch-name)".

Tried to remove Hyper-V and reinstall it but no luck.

I am aware of a similar question on SuperUser but has no answers on it.

Any clues for the root of the problem?

Best Answer

This post resumes the results of the study done by one poster:
Windows Sandbox on Win10 2004 now creates vEthernet interface for every physical NIC?

His conclusion is that these new virtual switches were related to the feature of Windows Sandbox. Uninstalling the Sandbox in Control Panel > Programs and Features > Turn Windows features on or off and reboot removes these switches. If you wish to keep Windows Sandbox, you will need to also keep the switches.

I reproduce below his account:

I updated to Win10 2004 (Build 19041.208 as of this writing) and I've noticed that on my system with Hyper-V and Windows Sandbox installed, I now have an auto-created vEthernet interface for every physical Ethernet interface on my system. Each one is named "vEthernet (Physical interface name)". This is occurring despite that fact that only virtual switch I have on my host system is the Default Switch.

When I run "Get-VMNetworkAdapter -ManagementOS", I see multiple adapters named "Container NIC xxxxxx", each showing as attached to the Default Switch.

All of these vEthernet interfaces have auto-assigned 172.x.x.x IP addresses. They cannot be deleted in Network Connections (option is grayed out) and if I use Device Manager to uninstall the actual Hyper-V Virtual Ethernet adapter device associated with these interfaces, they reappear after rebooting. This behavior persisted even after I completely uninstalled Hyper-V, but when I reinstalled it and instead uninstalled Windows Sandbox, the vEthernet interfaces all disappeared, except for the one associated with the Default Switch, which I expected to remain. And at that point, running "Get-VMNetworkAdapter -ManagementOS" returned only one result.

Related Solutions

Windows 10 – Update 1511 Breaks Hyper-V Switches

Alright, so for anyone else who has this issue here is the solution.

DISCLAIMER: YOU WILL MOST LIKELY LOSE NETWORK CONNECTIVITY ON THE HOST PC/SERVER UNTIL THE FINAL STEP

Since you cannot remove/uninstall the Hyper-V switch through

Control Panel\Network and Internet\Network Connections

The only choice left is to open the device manager.

Device Manager > Your PC > Network adapters

In this list you will find the Hyper-V Switch, but it will most likely NOT have the name you gave it. Determine which network switch is the Hyper-V Switch, right click and uninstall it. This is where network connectivity will be lost.

After uninstalling the switch from the device manager, the record will still be left in your Hyper-V Manager's Virtual Switch Manager. However, rejoice, as now that the device has been manually removed you can now remove the virtual switch from the Virtual Switch Manager without error.

Now, when configuring a Hyper-V Switch, the actual physical adapter is set as a Hyper-V Extensible Switch. Since we manually removed the adapter, the Virtual Switch Manager did NOT restore the switch to its original settings. Go back to

Control Panel\Network and Internet\Network Connections

and right click on your primary network adapter, hit properties, and uncheck the "Hyper-V Extensible Virtual Switch". After doing so, you should see the other checkboxes populate automatically, if it doesn't for some reason, go through them and check what you need.

Hit OK, confirm the notice that will say you may experience network interruption, and you are back to having internet on your PC/Server and are now able to Re-create your Virtual Switch for your Hyper-V Virtual Machines.

Networking – Hyper-V virtual network switch

So you have . . .

The VM Mikrotik machine configured with two NIC's with one connected to the "internal" Hyper-V switch (inside) that has the DHCP service running on it, and the other is connected to an "external" Hyper-V switch (outside), etc.
The lUbuntu VM has one NIC and you connect that to the "internal" Hyper-V switch which has a DHCP server service listening on it from the Mikrotik machine to process requests accordingly.

Clarification Resources

1. Configuring VM Networking on a Hyper-V NAT Switch

Virtual machines that are connected to a NAT virtual switch are in an isolated broadcast domain, a different one to the LAN. The NAT switch does not have flat, 2-way routing to the LAN that the host is connected to. The virtual switch is an internal virtual switch that the host NATs to the LAN. This means that, by default, the virtual machines can connect to the LAN, but the LAN cannot connect to the virtual machines. And even if we do create NAT rules, the virtual switch remains a separate broadcast domain from the LAN.

The virtual switch is somewhat isolated from the LAN, especially from broadcast-based services such as DHCP. You can deploy your own DHCP server(s) as virtual machines that are connected to the virtual switch. The scope of these servers is limited to the virtual switch, so there is no impact on the LAN, and network administrators should not have a problem with your DHCP servers being deployed on the NAT virtual switch.

Source

2. Internal Hyper-V switch configuration

Internal: Allows communication between virtual machines on the same Hyper-V server, and between the virtual machines and the management host operating system.

Source

3. Visualization of all switch modes

Source

Potential Workarounds

The way I've handled this is to ensure the VMs connected to the internal switch have IP addresses assigned, and then from the host Hyper-V management server, I then can access those machines from the host OS that way via their IP addresses.
You could probably look over the Set up a NAT network, and be sure to have a full understanding of it and then Create a NAT virtual network and configure it accordingly to see if it'll do what you want using the "internal" Hyper-V switch functionality.
Since the VMs can talk with the Mikrotik machine, perhaps you can setup routing in it and then tell the VMs to use it's accessible internal Hyper-V switch IP address as the default gateway on all those devices, and just let it do the routing when things need accessed that's not connected to the internal Hyper-V switch.
Check your VLAN configuration and see Configure virtual local area networks for Hyper-V in the event something at this level is needed or causing trouble.
- Configure and View VLAN Settings on Hyper-V Virtual Switch Ports
Check any OS level firewall rules for the blocking of the traffic coming from the internal Hyper-V switch to the host Hyper-V or any of the connected VMs.