Hyper-V virtual switch creation woes

High-end laptop hardware does not approach enterprise-grade server quality. That’s my takeaway.

I’ve been wrangling with Hyper-V on a very nice ultrabook that has 32GB of RAM and a Core i7 processor (quad-core). Highly portable and useful for running multiple VMs, which indeed was the idea.

This ultrabook is also now sporting the 2004 release of Windows 10. Security-obsessed folks like me have taken a keen interest in the application sandbox features.

Since sandboxing is all about virtualisation, it made sense, I reasoned, to use Hyper-V rather than any other virtualisation platform. It’s native to Windows and this way there should be fewer potential conflicts between hypervisors.

And it was all going well until I attempted to create an “external” (bridged) switch. The creation process failed with the following unhelpful Virtual Switch Manager errors:

  • “Adding ports to the switch ‘[switch name]‘ failed. The operation failed because the object was not found.”
  • “Failed while adding virtual Ethernet switch connections. Ethernet port ‘{[insert long GUID here]}’ bind failed: Cannot create a file when that file already exists. (0x800700B7).”

Worse than that, whatever process had partially completed could not easily be reversed – clicking ‘cancel’ did not back out any changes. Rather, it left my laptop with networking utterly ruined.

I confirmed this by repeated attempts to create a vSwitch, following resetting the network stack and removing/reinstalling Hyper-V. Same results every time. If you find yourself in this mess, utter the incantation “netcfg -d” at an elevated command prompt and reboot. (You may also need to remove and re-add WAN miniport devices as described here, since this process can break existing L2TP VPN connections.)

Is there a way to fix this problem? I believe not, at present. It’s almost certainly connected to the attempted use of a WiFi adapter which Hyper-V can’t always support. My adapter is an Intel Wi-Fi 6 AX200, FWIW. No matter how expensive the laptop, you can’t assume that the hardware will provide across-the-board support for virtualisation. For that, you really need a decent-quality server-grade NIC.

All is not lost. Although it’s not possible to bridge the Wi-Fi adapter, the default network (which offers NAT) works fine. And internal virtual networks (which aren’t hardware bound) are also unaffected. Granted, this means you can’t route externally into your VMs, but that’s not the end of the world, particularly if you’re au fait with port forwarding (read also the comments at that link).

(Yes, you could also use an external network interface for this, though that reduces your laptop’s portability of course. Quality matters for that too – YMMV.)

If you have cracked this problem or can provide any further thoughts or guidance, please do let me know in the comments!

This article’s featured photo by Siavash Ghanbari on Unsplash

6 Replies to “Hyper-V virtual switch creation woes”

  1. I have the exact same issue. Win10 2004, with an Intel Wireless-AC 9260. No luck.

    To clean it up you have to reboot, then delete the bridge it created under Network Connections (will not show up until after the reboot) — then the vEthernet NIC will appear which you can remove from Device Manager.

  2. Finally the issue started to show up online, I have been struggling with it since May and contacting MS was of no use. Actually, it started after 2004 update, before that everything was working flawlessly. It is not clear whether it is the update the has something broken or it is Intel that is expected to update their drivers somehow. Bridging wifi is still working with many older wifi devices on other machines on 2004. Anyway, to reinstate the connection after the failure of bridging the wifi, it is just enough (most of the time) to disable the wifi and re-enable it then the buggy bridge will show up so that you can delete it.

    1. Ah, that’s interesting. Many thanks for commenting, Aena – I’m sure your suggestion will help others! I’m just in the process of writing another blog post about a related problem…

  3. I have encountered the same issue on a desktop PC that contains an “Intel(R) Wi-Fi 6 AX200 160MHz” adapter, so seems to be the same hardware as your issue.

    I have found this article from Microsoft dated 9th September 2020: https://docs.microsoft.com/en-us/troubleshoot/windows-client/virtualization/cannot-create-hyper-v-virtual-switch

    This article describes the issue and confirms it was caused by a recent Windows Update. It states that it will be fixed in the next Windows Update, but provides an easy-fix option to patch it.

    I have run this “easy-fix” and found that it completely stripped my network keys, so I had to re-enter my network key… but when trying to create the virtual switch in Hyper-V again, the same issue persists.

    Part of me hopes that it’s a more general issue than the hardware not being supported by Hyper-V, although I couldn’t help but notice that the Enternet adapter works fine… it’s just the wireless adapter that fails with this error. Unfortunately, I don’t have direct physical access to be able to plug this PC into my network via Ethernet, so wireless is king.

    VirtualBox works fine with this adapter, but I found that I was experiencing some unexpected performance hit… plus I have need to learn Hyper-V from a professional aspect.

    Here’s hoping for a relatively quick fix coming out shortly!

    1. Thanks Mike. My final solution to the problem was to create an additional VM switch that manages NAT and to pair this with a pfSense VM to handle DHCP. That’s worthy of its own blog post.

      The bottom line is that low-level MAC spoofing and other shenanigans needed to run VMs are particularly challenging over WiFi. I suspect VirtualBox ‘fixed’ this by not digging as far down into the networking stack as Microsoft does with Hyper-V. But that could be complete nonsense.

      From what I’ve read on various forums and technical boards, the Hyper-V team are aware of the issue but it’s less of a priority than other feature requests. Large enterprise customers (from whence most Hyper-V-attributed income must be derived) are not running over WiFi. All enterprise NICs, none of which are WiFi, have first-class support. Harrumph.

Leave a Reply

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

This site uses Akismet to reduce spam. Learn how your comment data is processed.