You are correct. Creation of Default Switch (just by enabling Hyper-V role and doing nothing) reduces performance for all NIC.
It is actually deliberate (so as to improve performance generally).
Probably that works for servers with many NIC but it certainly doesn't work for my home laptop. I don't think is it BS just I'm running it on weak hardware.
I'm glad you guys said something
also I found the dates of posts funny - Hyper-V External Switches killing Networking in Insider builds Win10.Guru
The default Switch also causes problems for Mobile Intel Dual Band 7260AC since 2015.
My work around that worked up until 1703 was to bridge all of the switches and adapters and daisy chain machines to that single bridge.
I'm in the middle of setting up a Hyper-V DC and doing a split brain DNS to join the Host-Machine via Forest Trust and DNS Tom-foolery.
The name resolution gets mismatched with Windblows Server Versions... 1603 still has Workgroups... 1703+ doesn't - and without Desktop Experience, which I'm also going to be playing around with to extract the components required and build it on to 1803+
Changing the host machine from 'WORKGROUP' to 'GSP' will not find the domain, and only when the Workgroup 'WORKGROUP' is named 'GSP.local' will it find the Name Server, IF the name server uses the host as a gateway - which means the external card takes 2nd preference, which means slower external transfer...
Internal Domain Name Resolution takes far too long because Windows is busy finding devices with NetBIOS, WSD, SSDP.
Which means there will be problems with profiles and redirection. But there were also severe issues that were just recently patched the other week that I need to test out now.
I'm adding an extra dungeon boss level by having a QNAP be an additional Domain Controller...
There's also the fritz.box 'Network Location'...
Then the fight with windows firewall and it's dual profiling because of the 'Public' network caused by the switch.
(ESET Users: Delete all known network profiles if having issues, and re-create them - windows will override the settings)
edit: i forgot to mention the most important part of windows actually messing with network settings in the reply - configuring the default switch from within the guest machine only works until reboot or lease period - then - the host machine will pick a new default IP range... and also re-enable IPv6 if you have it disabled.
Set-NetConnectionProfile also has little effect for the same reason.
For the record - that is the (Guest) DC's Network view with the Switch 'Not Connected' but not removed. Yes... it still sees a 'disconnected' machine
Here is the same with the Default Switch removed from the Hyper-V machine:
Last edited by NeoBeum; 26 Sep 2018 at 11:11.
I cannot understand what you mean with "dates of post are funny".
That being said, I am the person who wrote the article you are referring to. If you read it once more, you'll notice that I am telling that as long as you use the Default Switch, there are no issues. Problems start when you create an external switch, at which point the network transfer speeds drop to almost zero.
Default Switch = OK, External Switch = network transfer not working.
Kari
That was a deliberate decision by MS though (I can't be bothered to find the link but you know it was - something boring about sharing bandwidth).
The problem is anyone who turned on Hyper-V and made external switch got the (normally single) NIC shared between 1 host and 1 guest. So it was half.
So, that is it.
It is a terrible decision but it is in fact what they did.
EDIT - I'm talking about home users here (people with only one NIC) but the problem was not confined solely to them. For example, ME!
WRONG!
Even if you bothered, you would not find anything supporting your statement. External switch causing networking issues was not and is not a deliberate decision by MS, it is simply a bug.
Think logically: if it was deliberate, the option to create external switches in Hyper-V had been removed.
Microsoft has never said or told in any blog post, article or such anything about this being a feature (deliberate decision) rather than a bug.
I really challenge you to "bother" to find anything supporting your statement. Until that, let's agree that it is an invalid statement.
How is the situation different when using Default Switch? Host and VM are sharing the same Internet connection through one single NIC. Absolutely no difference.
Let's make this clear: Hyper-V external switches causing networking issues is a bug, not a feature. Microsoft has never even remotely hinted that it is a "deliberate decision". Absolutely not.
Kari
I agree with you. Something does not add up here. I think we are talking crossed wires with others.
They seem to be talking about the design of networking being inefficient which may or may not be true.
You and I are talking about a nasty bug that crept in with version 1803.
Prior to 1803, if I was not using a VM simultaneously with host, I would get 72Mb/s download when using setup with an external switch. I saw no suggestion of any inefficiency on host if no vms running.
I cannot say what would have happened with vm downloading simultaneously with host ie would one dominate, would they share 50:50, would sum of two be significantly lower than 72Mb/s etc.
However as I said earlier 1803 screwed up download speeds so now I only get 2Mb/s if going via an internal switch.
Bizarrely, upload speeds are not affected.
When I remove the external switch, and use the default switch, speed goes back up to 72Mb/s.
There is no way on earth, this behaviour is by design - it is clearly a bug!
Exactly.
Although saying it by myself, my article at Win10.guru which fellow member NeoBeum mentioned earlier pretty much summarizes the issue: Hyper-V External Switches killing Networking in Insider builds | Win10.Guru
It seems you are correct and you now have me doubting my sanity. I was certain I read that external switch was changed to share bandwidth between host and guest a few releases ago so neither host or guest got more than their fair share.
Having spent several hours looking I can't find this document any more. I don't like to think I dreamt it all up but as I can't back it up I must assume I was wrong.
I wasn't trying to spread false information - I did truly think it was the case.
Quote
