Although it’s been around for a while, the Hyper-V Default Switch is often misused or not given the credit it actually deserves. Let’s take a quick look at what it does, how it works and when you should use it.
Starting with the Windows 10 Creators Update (build 1709), Hyper-V includes a special virtual switch – the Default Switch. It’s called this because it’s the only switch installed automatically… ummm…. by ‘Default’. This was done to bring Hyper-V more in-line with the simple NAT network sharing found in competing virtualization platforms like VirtualBox. This is not something you need to set up (you can’t, actually) or install – it’s just available and ready for you to use.
How it works (briefly)
The Default Switch leverages Internet Connection Sharing (ICS) and gives it a whole new purpose. It creates a dynamic private address space for any connected VMs, provides a rudimentary DHCP server to automatically assign addresses within that space and then NATs traffic to and from connected VMs so they can share your host’s physical network card. Pretty cool, right? In other words, it turns you host machine into a very very very simple router and allows the VMs to access the host and the internet.
Interestingly, it also carries forward a few other features from the old ICS days, namely the hosts.ics file. This file is automatically generated and maintained by the Default Switch. This means it creates a mapping between the assigned address given to your VM and it’s reported hostname with a mshome.net domain appended. So, you can access your VMs simply by hostname.mshome.net. That’s very cool. Nothing to maintain, nothing to set up. You can check this out yourself by opening
%systemroot%\system32\drivers\etc\hosts.ics. I should note though, this does not replace or act like a real DNS system – the host can use this file to resolve by name, but the guest VMs cannot use that file to look each other up by name.
Top 3 Drawbacks
Although this feature is pretty great, it does have some drawbacks.
1. Dynamic IP assignment
The built-in DHCP pseudo-server that assigns addresses definitely makes life easier in many cases, however, it cannot be disabled and cannot be customized. You have no control over the assigned address and cannot set a static IP on your VM. This is detrimental if you wanted to set up a server or something else that requires a predictable address for port forwarding.
2. Fixed domain assignment
I know, you thought mshome.net was dead… I know I certainly hoped it was. But, in this case, it’s very much alive. While it’s cool that you can fire up a VM and access it by name seconds later via this mshome.net domain name, it really sucks that you cannot change that domain name! This spells trouble for situations where you have domain-specific test-setups, providing domain services, certificates, and so many many other issues.
3. Port forwarding does not work
This is, if you think about it, a natural extension of point 1 above. If you have a dynamic address, how would you setup the networking rules to forward ports? Forward to where? It’s a moving target. This is a huge problem especially for working with Linux systems where SSH tunnels are just about the only way to work with a GUI when running within Hyper-V. In fact, no form of SSH tunnelling works properly as far as I can tell. It just cannot be done, it will fail with obscure error messages… don’t even waste your time trying. If someone has figured a way around this, by the way, PLEASE let me know in the comments!!!
When to use the Default Switch
Briefly: Use the default switch whenever the above 3 drawbacks don’t apply to your usage scenario! Seriously, the Default Switch is super simple and such a quick way to provide internet/network access to your VM. Really, anytime that the domain name doesn’t matter to you and you do not need to forward ports, the Default Switch is a great candidate for quick setup. If you need control over the network in question, the assigned IP address or the domain name, then set up a dedicated NAT network (I did an article on how to do that with just 3 PowerShell commands!) and save yourself a ton of time and head-scratching.
I could go much more in-depth into this issue, but I think this is enough to answer most questions. As long as you keep the 3 points outlined in this article in mind, you should have no problem deciding when you can save time and use the Default Switch versus when it’s worth the extra effort to set up your own NAT network in Hyper-V.
Thanks for reading my techie-thoughts on this issue. Have any comments or suggestions? Want to add your tips? Things you want me to cover in a future article? Comment below!