Go to ...

RSS Feed

August 18, 2022

Hyper-V External Switches killing Networking in Insider builds

I use Hyper-V a lot. All of my physical machines run the UK English x64 PRO edition of the latest Windows Insider build, along with other language versions of Windows 10 I regularly need (FIN, SWE & GER), with both of the latest official release and Insider builds also running on Hyper-V virtual machines.

Until Windows Insider Build 17704 everything worked perfectly. I was able to use my external switches both on host and virtual machines, with no networking issues whatsoever. File transfers operated at full speed without delays.

Build 17711 (released July 6) and now build 17713 (released a week later) have changed this. Now, if I have any external switches other than Hyper-V’s own Default switch enabled, networking is simply not impossible. Not only is the connection between the host and its virtual machines effectively lost, it also affects the host’s connection to other physical machines.

A picture is better than thousand words. Here, I have enabled a self-created external switch another PC and copying files on its share to a laptop not using external switch. File transfer from or to laptop in case the other PC is using external switch is so maddeningly slow that it in fact is useless even to try. Thus, for example, the file copy dialog shows nothing happening. Checking Task Manager, I can see that network activity is occurring, but file transfer is so slow it would take a few weeks to transfer an ISO. Ouch!

Disabling all external switches except Default, file transfer between both physical and virtual machines is as it should be:

Indeed, the default switch in Hyper-V works without issues, allowing networking at full speed. But the reason I must create and use an additional external switch is because I am using the Windows Admin Center (WAC) to administer and manage all my physical and virtual machines. It’s simple: if a VM uses default switch, I cannot connect to it from WAC:

When I switch the virtual machine’s NIC to a “normal” external switch, I can use WAC to start it and connect using WAC Remote Desktop:

Using WAC Remote Desktop to connect to a VM. Click to open enlarged in a new tab.

However, this is almost useless now because the external switch makes file transfer and other networking tasks nearly impossible. In the current 17713 build, as well as in the previous 17711 build, I find myself constantly enabling an external switch to manage my virtual machines using WAC, then disabling that switch and using the Default switch to get any serious networking done. This is quite annoying.

Here’s a shortened version of the long preceding story: Using any external switches other than the Default switch in Hyper-V on a build 17711 or 17713 host, file transfer between the host and its virtual machines or the host and other physical computers becomes impossible. I for sure hope Microsoft fixes this in its next Insider builds.


P.S. For more information about WAC and how to use it to manage your Windows 10 workgroup computers and virtual machines, see the tutorial I wrote on Ten Forums: https://www.tenforums.com/tutorials/113966-windows-admin-center-centrally-manage-all-your-windows-10-pcs.html

Author: Kari Finn

A former Windows Insider MVP, Kari started in computing in the mid 80’s writing code for VAX / VMS systems. Since then, he’s worked in a variety of IT positions. He specializes in Windows image capture, customization, repair and deployment as well as Hyper-V virtualization. Kari is a proud Team Member at number #1 Windows site TenForums.com.

10 Responses “Hyper-V External Switches killing Networking in Insider builds”

  1. staimo
    October 11, 2018 at 08:57

    I’ve noticed the same issue after updating to 1809. Can’t use any external hyper-v switch. transfer speed for network file access is below 1MBit/s. Have you found any solution yet?

  2. October 11, 2018 at 13:41

    No, I have not found any solution for this issue. However, I have now noticed that external switches in latest Windows Insider build 18252 no longer slow down networking. This might mean that whatever the underlying cause is will be fixed in version 1903.

  3. November 1, 2018 at 01:24

    I’m having the same problem. I’ve posted a question to Superuser hoping that someone might have an idea about how to fix this:


    Hopefully that doesn’t involve sitting and waiting for 1903 to roll around.

  4. November 1, 2018 at 12:57

    I just read your post on Superuser, and the solution offered. I have same experience, Internal switch does not resolve the issue. In any case, it uses NAT exactly as the default switch which then causes other networking issues.

  5. Alex
    February 5, 2019 at 12:25

    Were you able to resolve this? I’m struggling with this right now. This is incredibly poor form for Microsoft.

    • February 5, 2019 at 13:24

      This issue is resolved in recent Windows Insider builds, preview builds for upcoming version 1903. If you are using version 1809, it seems you have to wait until April and version 1903.

  6. Angus
    February 22, 2019 at 00:53

    I’m not sure if it’s related, but I had the same symptoms and issue with speed on my laptop with 1803; add external switch: downloads would slow to 1Mbps, remove external switch and everything would be fine. I ended up finding a post mentioning disabling Packet Coalescing on the NIC, in my case the Intel WiFi card and it has resolved the issue.

    • February 22, 2019 at 02:09

      Thanks for sharing, a good tip worth to remember, in case the issue returns.

  7. MIchael
    August 7, 2019 at 09:34

    If this helps, 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 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.

  8. RAffRuse
    September 5, 2019 at 16:41

    I am on 1903 and confirm i have this issue still, microsoft sucks.

More Stories From Hyper-V

Magbo Invite Codes Links: