Hyper-V Default switch IP address range change. Ver 1809 Build 17763.1

[Bala Sundaram]

Can one confirm IP address range changed to 192.168.X.Y Subnet 255.255.255.240 from 172.X.X.X

Also changes the subnet randomly on every Hyper-V services startup. 192.168.X.Y . X can change from 51 thru 180.

Although this is working on DHCP based IP assignment on guests, It is causing issues on static IP as it keeps changing after every boot

Regards,

Bala

[#2]

When you do a route print, you will see that the default vSwitch is not creating a persistent route but rather a temporary one. it's not a bug, it's intentional and the way Microsoft made it.
you can request a feature change through Feedback hub app.
the norm is that when people are running professional servers in their Hyper-V, they set external vSwitch as the network adapter for their VMs, it provides more functionality.

there is also another case when the host is connected to a VPN, if the guest VM use default vSwitch, it will have access to the same VPN as the host. but if the guest VM uses an external vSwitch, it will continue using the Direct Internet connection Even though the host is connected to the VPN. now if the default vSwitch was to get a static IP address forever, it would cause conflicts with host VPN and other scenarios where the subnet of the default gateway on the host changed.
with non-persistent routes like this, default gateway first examines and evaluates the network topology and then based on the available networks and subnets, chooses an IP address.

so again this is Not a bug, it's just how it's made.

I have a normal home router, my Windows 10 is connected wirelessly to it. in my Hyper-V I created an external virtual network adapter and connected all my VMs to that same external vSwitch. I run 3 Windows server 2019 and one of them is a VDI host (yes Nested Virtualization). all of these with a 20$ wireless network adapter and a simple normal home router. it can't be any simpler and easier than that.
I've worked with VirtualBox and VMware Workstation 15 as well, but still Hyper-V is the best.

[#3]

@HotCakeX NAT is not about routes, it's about network address translation. And that switch is for NAT isn't it? But it's black-boxed and the only configuration parameter opened (static IP address) is simply broken, changing randomly every time you boot your computer. Why? No clues, nobody does this except MS. And documentation either not complete or it's just a bug. 
Again, switch is not allowed to change it's own address randomly if configured statically. If MS made it intentionally, they should fire their developers and hire professionals.
This scenario is a dead horse. It's usable only in few cases. Again, all other virtualization software do things right in few clicks but not MS. Why? No clues.
Windows costs money. And the thing you have to buy yet another software to make it works is just bad. Because it's working pretty weird out of the box and workarounds are broken too. 

[#4]

I didn't talk about NAT, not even a word in my comment.
why? i told you why in my previous comment but you seem to ignore the reasoning behind it and keep on saying how bad Windows is. i can also write a book about how bad Linux is. but it's not about that. whether or not Windows costs money is off topic and not related to this thread.
i told you the solution for your problem, it's to use External Switch. I don't see why you don't want to use it. you don't need another software for it. Hyper-V doesn't need another license to use, it comes built-in by Windows 10.
again I provided real life facts and reasoning for why Windows does what it does and how it is helpful in what situations.

[#5]

@sn00p The recreation of the Default Switch with a new subnet on every host reboot is definitely a bug. I'm migrating from VMware, where I use a virtual NAT network for all my VM's. I knew going in to the migration that Hyper-V has limited capabilities compared to VMware, but I didn't expect the networking to be so limited. Here's the issues I've run in to:

* - Default switch reconfigures on every host restart and there is no way to prevent it.

* - Default switch is the only way to have VM's on a virtual NAT...it's not possible to create a Internal Switch with NAT (correct?) that doesn't get reconfigured on every host restart

* - External switch must bridge to a specific host NIC. My host is a laptop that is sometimes docked and connected via ethernet and sometimes connected via wifi.

I'm new to Hyper-V (but not new to working with VMs and networking), so please correct me if I've overlooked solutions to any of the above.

[#6]

P.S. I'm running on build 1903

[#7]

I'm not sure about that part where you mentioned Hyper-V has limited functionality compared to VMware. I have worked VMware workstation 15 and its previous versions for years, each has it's own set of features.

Hyper-V default virtual switch is exactly made for the type of the environment you work at.
sometimes you connect to WIFI network and sometimes you connect using Ethernet cable.
each of those networks can have different set of IP addresses and subnets.
now if the default virtual switch were to create persistent routes instead of temporary ones (as it does now), it would have created problems for you because you'd have to jump in CMD each time the networks changed and set the correct routing table.

right now default Hyper-v virtual switch takes care of it automatically and it's for quick VM set up, casual VM works.
but if you want to set up servers in Hyper-V like i do, you should use external Hyper-v virtual switch. it has more functions and it gives the guest VM a static IP because it bounds it to a Real physical network adapter. that's exactly what server admins Need. usually servers use more than 1 physical network adapter. so using the external virtual switch, they can properly and separately assign each of them to a specific external virtual switch and utilize them perfectly in the guest OSes (servers). servers do need static IP addresses.
but if you just want to install a Windows 10 pro or home and do casual works then the default switch should suffice.

[#8]

@HotCakeX 

With VMware, I could configure my virtual NAT network subnet...I had it set to 192.168.5.X and the host and guest IP addresses on the subnet where static. So no matter where I happened to be working, my VM's were isolated on a NAT network with static IP addresses (which is important for the type of work I do)

With the Hyper-V Default Switch changing the subnet on every reboot, I'm having to log in the to my main VM (Windows Server 2016) and tell it that the "new network" that it is now connected to is a private network.

[#9]

Well normally those who virtualize servers for real life uses have at least one gigabit Ethernet port, that's the least i can say. the norm is 10 GBit Ethernet(s). not WIFI. and they are always-on connections. that's why we don't see server admins complain about this Hyper-V feature because the proper way would be to create 1-on-1 links between Physical and Virtual network adapters using External virtual network adapter.
I totally understand your situation, sometimes you have to switch between WiFi and Ethernet because it's a laptop, portable and so on.
you can still create persistent routes in the Window's routing table and make the default virtual network adapter's IP address stick even after reboots.

Btw, you Don't have to change anything in the Guest OS if you change your active network adapter from WiFi to Ethernet. all you need to do is to go to Hyper-V's virtual switch manager, go to the external adapter and change the external network from the drop down list. the guest OS shouldn't need any further changes if it has already given a static IP address from the same subnet.

[#10]

Thanks for tips, I've sorted this out )
But in general, why is that so hard to achieve compared to other solutions?
It's far easier in Linux world

[#11]

You're welcome, glad you got it solved ^^
Well i don't know how it can be easier in Linux where most of the things must be done from Terminal and manually typing codes

[#12]

I figured out how to create a new NAT internal switch with a static IP. It can be done via Powershell: Using a NAT Virtual Switch with Hyper-V

These are the commands I used to re-create the 192.168.5.X NAT network like I had in VMware Workstation:

New-VMSwitch -SwitchName “NATSwitch” -SwitchType Internal

New-NetIPAddress -IPAddress 192.168.5.1 -PrefixLength 24 -InterfaceAlias “vEthernet (NATSwitch)”

New-NetNAT -Name “NATNetwork” -InternalIPInterfaceAddressPrefix 192.168.5.0/24

I knew there must be a way since my scenario is very common in software development. There's just no way to do it in the Hyper-V Switch Manager GUI.

I have no use for the Default Switch now, but it doesn't appear to be remove-able...at least not without some registry hacking.

[#13]

@mlmathews 

In that same article:

"the end result is that (to begin with) that virtual machines on the internal virtual switch can talk to the host, but they cannot talk to the network that the host is connected to."

That's totally useless for me.

I want my Virtual machine to be able to talk to the host network and be accessible from the Internet or in case of a server, it host websites on ISS, provide VPN server connections to outside clients over the Internet.

my host is already behind a phyiscal router, putting my VMs on yet another NAT with different subnets makes things worse and impossible.

with External Virtual Swtich in Hyper-V, i can give an IP address (v6 or v4) to my VM and then put that VM's IP address in my physical router's DMZ so it can be accessible from the Internet.

that's how servers operate. Hyper-V does a great job by letting VMs directly be involved with the real network.

[#14]

@HotCakeX The VM can connect to the network using an internal switch if it's set up with a virtual NAT firewall. My local server VM can connect to Microsoft Update (and the rest of the local network + internet). However, only the host (my laptop) can initiate connections to the VM...which is perfect for a development testing scenario. There are other servers (vSphere VMs) that the code is pushed to when it's time to make it available to other people for testing and production.

[#15]

Exactly what i said. the External Virtual Network switch is used for Real-Life scenarios. i wasn't talking about test purposes.
test purposes can have whatever strange settings they want.
Servers such ca CA, VPN, IIS, VDI etc are needed to connect to the outside world in order to do their job and serve. the Internet network would be already behind a NAT which belongs to the physical router.
there is no point in putting it behind yet another NAT.
the external IP address is 1 and when users from Internet want to connect to the Virtual Servers, they have limited possibilities, the best one would be to use VPN and then access the local network of the Servers/Clients but that also does Not need double NATs.

[#16]

@HotCakeX I'm not intending to argue with you and what I'm about to say is not directly related to the original topic of this thread, but you might be surprised at what's being done in "real-life" networking scenarios these days. The reason I switched from VMware to Hyper-V on my dev machine is because I need to work with Window Containers and Docker Desktop, which requires Hyper-V. Currently Hyper-V and VMware cannot coexist, but that is about to change. In the container world, VM's are just hosts for containers and usually many containers. For example IIS would not run directly on a server VM, but in a container. In larger scale systems like I work with, everything is redundant and disposable. For example, the web application I work on has many instances in production all sitting behind a reverse proxy (which itself is in a container). If one instance dies for some reason, no big deal, another is spun up to replace it. The containers are all behind a Hyper-V internal switch with NAT. Anyway, it you want to learn more about containers in the Windows world, here's a good place to start: About Windows containers

[#17]

Yeah as you said it's off topic so i have no interest in discussing containers.
but as i said, using double NATs won't let servers be accessible from the Internet. specially if it's a nested virtualization that I use mostly.

[#18]

@HotCakeX That is incorrect.

[#19]

It's not.

[#20]

You are my hero! I have been fighting this since I setup hyper v on windows 10 a couple of days ago. I was dropping packets left and right once I started my virtual machine. Thank you!!

[#21]

@mlmathews It sounds as though our respective use-cases may be similar.

(Edit to add: I had missed your most recent reply, as I failed to notice page 2; I will look into the PowerShell-based solution! Thank you!)

I'm a web developer who works primarily with VMs running GNU/Linux. I work in a Windows-driven, corporate ecosystem, though, so my primary development machine runs Windows 10 with Hyper-V.

I have many different VMs that I spin-up on a regular basis, oftentimes freshly-provisioned (that is, built dynamically and booted for the first time on each use). The provisioning process is 100% automated, which I mention only to make clear that there is no room for "manual tweaking" nor GUI configuration in my workflow; any networking configuration has to be automated during provisioning.

Further, I have many VM configurations in which one VM needs to communicate with one or more other VMs on the same subnet, which requires that each source VM knows any potential destination VM's IP address (a hostname could work, too, if hostname resolution was configured correctly, which I haven't yet attempted with Hyper-V).

More importantly, I need this subnet to be completely isolated from my physical NIC so that there is zero possibility of another machine on my LAN communicating with any of the VMs running in Hyper-V.

But I also need for the VMs to be able to connect to the Internet.

So, here's where I'm stuck:

1.) Default Switch: IP address assigned to VMs changes at random on host system reboot, so without hostname resolution across multiple VMs on VLAN, this configuration is untenable.

2.) External Network: This makes my VMs visible on our corporate LAN, which is a no-go.

3.) Internal Network: My VMs cannot obtain IPv4 addresses for some reason; only IPv6. No idea why this is.

4.) Private Network: Doesn't allow VMs access to internet, so not viable.

@HotCakeXDo you have a clever solution that will meet my requirements?