Proposal: Improve default network selection for Hyper-V - Githubissues

hashicorp / vagrant

Vagrant is a tool for building and distributing development environments.

https://www.vagrantup.com

Other

26.19k stars 4.43k forks source link

Proposal: Improve default network selection for Hyper-V #8573

Open PatrickLang opened 7 years ago

PatrickLang commented 7 years ago

The discussion in #8384 forked to also talk about NAT on windows. I think this could be implemented first, without addressing static IP or multiple networks.

Current behavior:

if only one external network exists, attach the vnic to it
else prompt the user

Proposed: ~~- if an existing nat exists, use it~~

Attempt to find an external network with the interface "up" with IPv4 connectivity
else prompt user

This would work on all releases of Windows 10 since it isn't creating a new nat, just reusing what's already there.

PatrickLang commented 7 years ago

@scooley @kallie-b any feedback? We should chat about this

bbrala commented 7 years ago

We need to remember the IP has to be set on the guest so that probably has to be configured in the vagrant file. And wouldn't it be more sane to just select from all available switches and branch off from there?

PatrickLang commented 7 years ago

Hmm, I shouldn't post to GitHub before having coffee. Yeah, you're right, DHCP services aren't provided by default. I've been spending too much time with Docker which has IPAM built-in for the default nat network.

bbrala commented 7 years ago

Ok, another thing. Vagrant uses SSH to communicate with the machine. This means there needs to be a valid network configuration available otherwise it cannot communicate with the guest. In the VirtualBox provider this is worked around by requiring the first network interface in virtualbox to be a Nat network, which would probably provide DHCP. That connection is used on setup, and then IP configuration is applied. For HyperV this creates a problem, we cannot create a valid network configuration on the guest without SSH, which needs a valid network configation...

We could use the built-in support from HyperV but as you said, the support for different OS's is not ideal.

Windows machines have a pretty well defined 'i cannot find and ip adress' address, but im not sure if linux guests would do the same...

bbrala commented 7 years ago

Appearantly its a standard. That might be usefull

Quote 169.254.0.0/16 - This is the "link local" block. As described in [RFC3927], it is allocated for communication between hosts on a single link. Hosts obtain these addresses by auto-configuration, such as when a DHCP server cannot be found.

bbrala commented 7 years ago

Ok, ive been looking into how this is done in packer, and there they just use a public switch. Vagrant uses SSH to send command to the machine, so it needs connectivity. There will be no connectivity if there is no IP, so thats a bit of a chicken and an egg. You need DHCP to get the machine to get an IP automaticly, other than using the (slightly) limited guest services from Hyper-V.

bbrala commented 7 years ago

@PatrickLang did you have any chance to talk to your colleagues?

PatrickLang commented 7 years ago

I was mistaken on DHCP services. They're not built in to NAT.

What about changing it to automatically pick a switch with a network interface with public connectivity? I could find that by following associations from

Get-NetConnectionProfile | ? IPv4Connectivity -eq Internet to Get-VMNetworkAdapter -ManagementOS to find the switch name.

PatrickLang commented 6 years ago

blowing the dust off this issue

Windows 10 / Windows Server version 1709 now have a DHCP server with the NAT. This might make sense as the default and it would let you move from wired Ethernet to wifi and back. However, I don't think static IPs will be possible. Thoughts?

bbrala commented 6 years ago

Static might be possible within the range the dhcp server serves, although I'm not sure if that might result in collisions.

I've been meaning to check out the possibilities but haven't had the time yet.

kallie-b commented 6 years ago

@PatrickLang -- To translate into our HNS "lingo," are you suggesting that we make our default "nat" network on Windows use ICS NAT instead of the more Docker based NAT that it uses today?

The difference is that today's default Docker based "nat" gets DHCP from Docker's built-in DHCP server. By contrast, ICS NAT gets DHCP from Windows (from the Windows Shared Access service, from my understanding).

kallie-b commented 6 years ago

Okay upon a closer read I have more questions. Namely:

Are we talking about changing how the default NAT is configured for containers on Windows? For example, by opting for a different DHCP service to be used? Or by making things like the DHCP server more configurable?
AND/OR is this thread about changing the default network driver on Windows such that it's not NAT at all, but Transparent or some other network type that would be considered "external"?

It looks like this discussion arose from a conversation about static IP configuration--would you mind summarizing the core question/problem here?

PatrickLang commented 6 years ago

This is about Vagrant being able to use the "Default Switch" NAT, not the Docker-style nat.

For comparison, VirtualBox has an internal network that features a NAT for routing external traffic, but gives the VMs internal IPs. These can also be static IPs but routing still works.

Static IPs are great for multi-machine scripts. That way you can set a static IP like 192.168.1.1 on the first machine, then run commands like docker swarm join 192.168.1.1 on the second machine because you have the fixed IP.

Main requirements are:

Be able to create a VM with internal IP a. Bonus points if it can be a fixed IP. otherwise use dynamic
VMs can communicate to each other on internal IPs
VMs have route to internet and working DNS servers
Connections can migrate between wifi, 4g/lte, and wired Ethernet without VMs as needed without reboots or losing internet connectivity
Configure all this through PowerShell cmdlets and/or WMI. Vagrant is built on top of the powershell commandlets.

bbrala commented 6 years ago

Id like to add to that; static ip's are also quite handy if you want to do DNS resolution of an internal dev domain, since you can just use the same ip for everyone, currently you need to do nasty stuff to the hostfile on windows to get a domain to work, which is quite annoying since you cant wildcard stuff in your hostfile (eg *.machine.dev) .

kallie-b commented 6 years ago

Roger that. I'll take this to my team and see what their thoughts are 👍

Trolldemorted commented 5 years ago

Could you estimate a timeframe when decent network support in the hyperv-provider will be available?

I wouldn't even mind having to declare a public switch first and to create internal switches manually in my hyperv manager, as long as I can specify which switch a VM should use for which network, similar to the virtualbox provider's slang:

Vagrant.configure("2") do |config|
  config.vm.network "private_network", ip: "192.168.50.4",
    virtualbox__intnet: "mynetwork"
end

Based on that, hyperv could support something like

Vagrant.configure("2") do |config|
  config.vm.network "private_network", ip: "10.0.0.2",
    hyperv__switch: "myprivateswitch"
end

Assigning private networks to VMs is essential!

rgl commented 4 years ago

is there someone still looking into this?

chrisroberts commented 4 years ago

@rgl Yes! I have previous work on hyperv networking support that was dropped simply due to things not being very well documented and difficulty getting stable behavior. Much of that has changed now and the work is going to be resurrected with a goal of getting the networking functionality for hyperv on par with other providers over the next couple releases.

friesoft commented 2 years ago

Any news? :)

ShaunLawrie commented 2 years ago

I commented on the static IP issue but it's somewhat relevant to this as well https://github.com/hashicorp/vagrant/issues/8384#issuecomment-1228509296