I would install an Ubuntu VM, then try and update and discover that the VM has an IPv6 address but no IPv4 IP address.
So, off into the land of tweaking Ubuntu. No go.
Next, my kids report router problems. So I assume there is a correlation and I screw around with the router. No change.
I delete and re-create virtual switches. No Change.
After a bit of frustration and some calming attention to detail, I realize that the IPv6 address that my VM is getting is actually self generated, it was not getting it from my ISP (as I originally thought - since we do IPv6).
The one pattern is that; a virtual switch on the wired NIC always works with the VMs and the wireless doesn't.
The other pattern is that Windows VMs are just fine. It is only Linux.
Now. Since this is an external virtual switch that includes a wireless NIC a Network Bridge device is added.
I decided to poke around a bit. I checked the properties of the Wi-Fi adapter (as it is common for power management to mess things up). I discover that I cannot edit the driver properties of the Wi-Fi adapter due to the Network Bridge.
If I open the properties of the Network Bridge, I can then disable Power Management on the NIC.
Come to find out tat was a waste of my time. But hey, I had to try it.
But, wait a minute. The bridge is dependent on the NIC. ... Network bindings pops into my head.
It used to be really easy to get into the bindings and totally mess things up. Needless to say, it is not so intuitive any longer.
At the Network Connections press the ALT key, this reveals the file menu - select Advanced and then Advanced Settings.
What I notice is that the binding order is: Network Bridge, Wi-Fi, Ethernet
My thinking is; if Network Bridge is dependent on Wi-Fi, shouldn't it be after Wi-Fi?
(if you cluster or have clustered or have been around Windows as a server admin for a while you have probably messed with this before)
So I decided to give it a shot and move the Network bridge after Wi-Fi.
I then reboot for the change to take effect.
I then attach a VM to the virtual switch on my wireless NIC, cross my fingers, and power it on.
The VM boots right up, no hang at networking. I logon, I type ifconfig and voila the VM has a proper network configuration. I run 'sudo apt-get update' and all is glorious and good.
Just to fun, I build a Generation1 VM and install the pfsence router into it.
That failed the auto configure test, but after reboot it came up just perfect (and it didn't prior). And the latest version has the integration Components built-in and can use synthetic virtual NICs instead of Legacy - and even reports the IP address to the networking tab in Hyper-V Manager (I love that).
So much pain and consternation, for what now feels like a binding order bug.
I will update this is anything changes, but in the mean time: It works!
Now, why might Windows VMs work just fine?
Because they keep trying to get an IP, they don't just try once at boot and then fail. So that network stack can come live at any time, in any order (and generally does late in the boot sequence).
