Go to ...

RSS Feed

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.

Kari

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.

4 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:

    https://superuser.com/questions/1371759/creating-an-external-virtual-switch-on-hyper-v-causes-host-to-experience-very-sl

    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.

Leave a Reply