Creating an external virtual switch on Hyper-V causes host to experience very slow networking

Question

I've set up my Hyper-V environment (Win 10 Pro 64-bit, update 1809) to have an external virtual switch bound to my wifi adapter and shared with the host OS. I've used this virtual switch with my Debian guest VM to access the internet and the local network.

This was fine up until a couple of days ago when my host's network suddenly dropped network throughput from something like 350Mbps to 8Mbps.

Removing the external switch causes the slowdown to go away completely.

I've tried disabling VMQ, even though my wireless card driver doesn't support it (it's the built-in Qualcomm wifi chip on an Asus Strix z270e motherboard), but that didn't change anything.

Is there a way to have an external switch that shares the connection with the host without these problems, or a resource I can study to figure out how to get around these problems? I need the VM to be exposed to the local network, since I connect to it via test devices connected to my LAN.

Update 1

The answer provided here does describe my situation correctly, and I've tried the solution by making applying the following steps:

1. creating an Internal virtual switch,
2. selecting the internal virtual switch and my wifi NIC in the network control panel and selecting "create bridge" from the context menu.

This resulted in the same slowdown as before with an external virtual switch.

External links

https://win10.guru/hyper-v-external-switches-killing-networking-in-insider-builds

Answer 1

I don't know if my suggestion can satisfy what you're really asking but what I've done is instead of using external switches I create an internal one and configure it as a NAT virtual switch..that way I don't have to deal with external vSwitches.. if what you want is to provide internet access to guest VMs it works just fine. Here's a link in case you want to implement it..it's relatively easy. Hope that helps!

Answer 2

So, I've been fighting this issue myself for a few hours on my nice new laptop, and I believe I've found the combination of settings that seems to have restored most of my connectivity.

Since I have an Intel NIC I have no idea if this will help, but I'm curious and would love for you to try if you haven't gotten it sorted already.

Problem no.1: Slow download Disable coalescing on the Wifi-card. This completely restored my download speed and resolved issues I was seeing with intermittent connectivity in the host OS and on VMs.

Problem no.2: Slow upload Disable Large Send Offload on the Virtual adapter representing the external switch. In my case called vEthernet(WAN)

Answer 3

Disabling Large Send Offload Version 2 in the properties of the external vEthernet adapter helped me with this problem.

Answer 4

I have Intel Killer WiFi on an XPS 15 9570. I will give the specific configuration that restored full performance for me:

• WiFi adapter
  • Set “D0 PacketCoalescing” to “Enable” (or “Disable”—sometimes changing this setting makes things faster even though one setting used to be better—it doesn’t seem consistent).
• vEthernet adapter configured for External access pointing to the WiFi adapter
  • Set “Recv Segment Coalescing (IPv4)” to “Disabled”
  • Set “Recv Segment Coalescing (IPv6)” to “Disabled”

Together, these settings restored my host system’s connection speed from 7Mbps to 60Mbps which is the performance I would get if I didn’t have Hyper-V configured at all. I also still get just about the same performance on my guests.

Answer 5

I have a HYPER-V host (Server 2019 1809 & 1903) tested. The Windows 10 guest had fast SMB networking but extremely slow internet browsing/download speeds. My post is NOT related to WiFi may assist anyway.

My Linux guests were getting fast download speeds.

My Windows 10 were setup as Gen2 VM's. I created a Windows 10 VM as Gen1 VM, I'll call this W10G1.

W10G1 still had poor internet performance using 'Network Adapter' in the config. W10G1 had excellent internet performance using a 'Legacy Network Adapter'. No other changes were made.

It appears that there is a problem in the hosts 'Network Adapter' code, or the Windows 10 Guest's 'Network Adapter'.

I'd be happy for someone to double-check my results by doing a similar test.