New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Discussion: Static IP address for Hyper-V #8384
Comments
Yeah, I've been thinking about this. My goal is to get @StefanScherer 's windows10-docker-swarm working on Hyper-V. Things that I know need to change:
Questions: Do you have any opinions on 3? It seems like the guest plugins support setting IPs for more operating systems than the Hyper-V Integration Components, but I have been struggling to find docs and examples of how to use them. If a VM was exported with multiple NICs - should those settings (including MAC & IP) be preserved when importing it, or should the network configuration in the |
I've looked into how Vagrant does things right now and from what i understand, it indeed has implementations for setting the network for the guests. I would probably look at how the implementation for VirtualBox is and use that for Hyper-V. This will keep the basic code for setting the network in the guest the same which i feel is a pro. I think there is a lot of logic there that can be reused for the Hyper-V logic. We only would need to be very carefull in what different options there are on the machines of the users. I really think we can screw up the networking of the users if we do too much. I've even had moments when i was manually setting up my network for my VM that i screwed up my network settings after enabling or disabling Hyper-V networks. We don't want that to happen to an unsuspecting user. Regarding the deletion of NIC's, i feel you should be carefull deleting nics. Perhaps make it an option because unless you make every little think configurable in the config file you might not be able to conserve a specific setup a box might need. I really think rebuilding the NIC's from scratch always will become a problem in the future, and for most people they just need the VM as close to how it was exported as possible, since that was how the software was set up for them. When i implemented support for VMCX i started of with rebuilding the VM from the settings of the old one, but that really ends up making things harder and more code. |
I have achieved this using https://sourceforge.net/projects/dhcpserver/ and some powershell scripts that manage it. I am not sure whether it's the right path to go , or whether it's fine to add it as a dependency but it works pretty well without any bugs. If you are interested, i could spend some time adding it into a fork. The advantage is that it can be used for any Win/Linux box, since they all ask for an IP address via DHCP What it does is :
|
I'm not sure adding another dependency is really the way to go. From what i understand in the new Windows 10 update there has been an update to NAT networking, this allows for multiple NAT networks to exist, which makes the whole static IP problem quite a lot easier since we can control the NAT network as we see fit.
I think if we can use this to create an easy quick internal network for Vagrant to use for the machine. It should check for overlap in NAT networks though, since that might cause problems. If a NAT already exists which would serve that IP then just use that. Otherwise create a network. Cleaning up should be a breeze if we use well defined names for the network. The only catch is you need a recent version of Windows 10. But i feel that this should not really be an issue that stops Vagrant from having this. |
I think the important part to this is ensuring graceful fallbacks (even if it's just explanatory error messages) for when the feature is not available. I'm very much in agreement with the approach though and prefer it over adding more dependencies. |
@chrisroberts ok, fair enough, i will try and find some time to get something up and running. I agree on the fallbacks ofcourse. @PatrickLang I've run through your linked commit, is there any reason why you want support for multiple networks, i haven't really seen machines that need multiple networks really. |
@bbrala multiple networks are very helpful when working with Windows Active Directory where I need to have a tightly integrated Kerberos, DNS, and DHCP setup spanning multiple VMs. I typically have 1 network that's "public" relying on DHCP & routing to the public internet such as public wifi. The other network is private just for the machines using the AD infrastructure. Here's an example of a doc I'm doing at work targeted to Azure, but I'd like to fully automate it with Packer+Vagrant so others can run it on a Win10 laptop. |
Also useful, as @bbrala pointed out, is that HyperV has support for a NAT (with port forwarding) under the hood. Here's how to use it in Windows 10: |
@PatrickLang Hmm, i'll think about how to go about doing it for multiple network interfaces, but perhaps this should be built in 2 steps. First one interface, then add the possibility for a second one. Although i could make sure we use a hash of the settings or something to identify the network interface. Not sure yet. Time is a little short at the moment, but I will have a go at this eventually :) |
Walking through the docs and code for networking i noticed multiple networks is supported in VirtualBox, think it would be weird to change the interface much for HyperV so we need multiple networks right away. Other than that i'm still a little torn in how smart we would make the code. I'm not entirely sure if for example Vagrant with virtualbox does anything to fix/find collisions in private networks. If you make 2 overlapping networks that would be created in VirtualBox for example, but i guess that isn't that hard to just test. |
I forked the NAT topic to a new issue. I think there may be a quick option to implement that first while we think about multiple nic and static ip here. |
@mwhooker; you did the implementation of HyperV for packer. Do you have any insight on this chicken/egg issue regarding static IP's? |
@bbrala regretfully, I only merged the PR. @taliesins is the brains behind the endeavor. Maybe he knows? |
Ah sorry, it has been a while, i remembered incorrectly, sorry about that :) |
@bbrala two potential approaches are:
We then need to change Packer to add an option to specify the management ip address to use instead of it always polling the hypervisor api for the ip address. |
to contribute to this discussion - i played around with vagrant and hyper-v lately. since windows server 2012 hyper-v allows to set the ip of guests from the host: i tested this script method with a linux guest on my hyper-v and it worked as proposed. there also seems to be a workaround to set the vswitch used mentioned in this discussion it is possible to create a NAT-Vswitch via Powershell: so i think all pieces to automatically create a nat-vswitch (or use a pre-created one) and apply the config to the vagrant guest would be there. so the same things which are done with virtualbox could be done with hyper-v. or am i missing any limitations on the hyper-v side? |
The script you posted doesn't work for me in Windows 10 unfortunately. We did have a look at setting ip's through hyperv but OS support is a bit limited regarding that. Perhaps we need to accept that fact for now. |
This Hyper-V post contains an interesting piece about new functionality ahead: link. In the comments they mention that this new "special" virtual switch will do DHCP. |
Good catch, that will make things a lot easier. Patience i guess |
Is there any progress in this? I already have a NAT-enabled vSwitch (via Docker) and I think that vagrant should error-out if the vSwitch IP and VM-IP is not in the same subnet (if possible). Creation of NAT-enabled vSwitches are also documented on blogs around the world. So if no NAT-enabled vSwitch can be found and used then maybe it should be created. Windows 10 does not support more than one NAT-enabled vSwitch but I think I saw something about it getting support for it in the future? (then this possibility should be checked before creation/use) |
The new Fall Creators update might help us getting this to work. There now is a Default switch available which is always present. This switch would enable us to connect to the VM regardless of current configuration on the host. This means we could actually connect and set the IP address on the selected switch without a problem. This would mean some refactoring though, since this would only work on machines with Windows 10 Fall creators update. Also i'm not entirely sure yet how we would implement using that interface as a managing interface for the VM. I would need to look into how the current VirtualBox implementation does this. From what i remember it always requires a NAT switch for exactly that reason. The update is pretty fresh, i haven't had time to look into this yet but i feel we could get this implemented using the new default switch. |
VirtualBox implementation requires two NICs. First one is host-only and the second is used for communicating with "the world". VirtualBox can also use an Internal Network that is ever more strict than host-only. Is hyperv set up the same way? Host-only sounds really like a hyper-v internal network with the infamous exception of missing DHCP. The reason "vagrant up" works at the moment seems to be that we get an ipv6-address that is used during setup. (ubuntu vms in my case) So if first nic is management only maybe create a vSwitch with Internal Network if one doesn't exists? or maybe create a vagrant internal network that is always used with or without the Default Switch? The public network is then later used to connect to whatever network that is needed. May it be internal, private och external. If Default Switch exists and no config says otherwise, then nic 2 is connected to it. If no default switch is found, nic2 is in "unconfigured" state and Vagrantfile needs be be updated with right vSwitch to use. Since we have no DHCP you Have to insert both private and public ip# in Vagrantfile. My ruby is almost non-existent but my powershell is most acceptable. Since I would like this to get better I will try to test whatever you come up with. :) |
Has any work been done on this guys? |
I haven't done anything yet. I was hoping the NAT changes in the Windows 10 & Windows Server 1709 release would make this easier but not quite yet. Here's my current proposal: I think I may be able to make this work for a second NIC. The first NIC would still use an external switch or the Windows built-in nat on "Default Switch". This would give the VM outbound connectivity. The second NIC could use a static IP on a private network. This would be good for labs where you want the VMs networked to each other with static IPs. Would that be helpful for your case? |
Yeah. This would work for me. |
The second NIC is used in the docker-swarm scenario for VMware as well. The Vagrant VMware plugin cannot handle setting a fixed IP address in Windows VM's, but my workaround to do this in a provision script https://github.com/StefanScherer/windows10-docker-swarm/blob/master/Vagrantfile#L46 scripts/fix-second-network.ps1 helps at least for Workstation and Fusion. |
Sorry to join discussion without additional tech info, but would like to kindly ask if there is any progress, or plans? As more of you noted, there is way how to make it work (and be fast) with two NICs like is in VirtualBox so curious if this is might be priority in near future. |
That is awesome to hear. |
This is amazing news, thank you! |
@chrisroberts can you drop a proposal here before starting the work. It would be interesting to see how you are going to tackle this. This might be usable in Packer HyperV and Terraform HyperV (wip). |
@taliesins Yep, I'm planning on it. |
You can assign IP to HyperV VM using the below command for both Windows and Linux. I have automated and assigned for almost 300 VMs successfully. For Windows use the below command:
$vmName = "TestVM"; For Linux use the below command:
Command as below: $VM="TestVM";
} Cheers guys.. |
Sorry to join discussion without additional tech info, but would like to kindly ask if there is any progress, or plans? |
I can still submit a PR with my working solution using the external DHCP server if there is any interest in it. |
@s0lucien If it works, I'm interested, and I suspect I'm not alone. Whether or not your PR will be merged is anybody's guess, but something that works is a lot better than nothing at all, especially given that this proverbial can has been kicked down the road into 2.2, which has no Due Date as yet. If it's not too much trouble, I, for one, would love to see your fork, and would use it until this is addressed to whatever degree of elegance Hyper-V affords. And I'm not holding my breath for Microsoft to give the Vagrant developers something to work with here, given the myriad problems that Hyper-V's switching implementation has incurred as recently as build 1809. |
I think with the new "Typed Triggers" there should be also a way to set a static IP address. As we should be able to start a script on the host that will set the guest IP. But up to now, I was not able to get them working (Typed Triggers), and yes I've added the VAGRANT_EXPERIMENTAL="typed_triggers" env variable. |
Got it working with something like that config.trigger.before :"VagrantPlugins::HyperV::Action::WaitForIPAddress", type: :action do |t| my next issue is, that it looks like that these type of triggers do not work together with config.vm.define method |
@schnyders Are you able to elaborate upon your approach at all? Specifically, what is that |
I took the time to get this "working" and posted a comprehensive how-to: https://superuser.com/a/1379582/176764 All the required networking-related Powershell is there (and it's far less verbose than what's described in #8384 (comment) ). They key is not to use Hyper-V's This odd behavior seems to rule-out the possibility to do as @taliesins suggests, with regard to using DHCP and predictable MAC addresses inside base boxes. Unfortunately, the alternative is to configure a static IP address inside the guest, which, of course, is OS (and therefore base box) specific. In other words, the only viable approach as yet seems to be for Vagrant to create a switch for its own exclusive use (see the Powershell commands in my linked post). Hopefully, a core Vagrant developer or a contributor with sufficient knowledge of the software is able to take what I describe and synthesize it into a more elegant and fully-configurable solution. |
Hello, Thanks @cbj4074 for you help on this, your posts was very valuable to make it run. For the first one, default switch, you can include in the vagrantfile, you must adapt #{vm_name} variable:
So it will only assign the default switch on the vm creation. Just what we need ! : ) Second part for the not gracefull shutdown, i did'nt use any reload plugin, but just issue a Here is the PS script, $vmName is a variable to set to the name of the vm.
With all this, you can fix an IP for your vagrant VM. I hope it helps other people struggling on this, and maybe on day we can get this feature native in Vagrant. The hard part you be to set the fixed ip inside the guest OS as iti is very depending of it. Best regards |
EDIT: after trying, it works only for CentOS/RedHat guest OS it seems... Thanks. |
@Yivan Thanks for the suggestions, and I'm glad I could help you! With regard to specifying the Regarding the second issue, again, your suggestion works!
Actually, upon further consideration, the same problem exists, regardless of how the VM is reloaded, which now that I think about it, makes sense. Even if we issue Again, this isn't a big deal; it just causes a bit of a delay (60 seconds or so) before Vagrant restarts the machine forcibly. This is evident from the following output (the second line is present only if the graceful attempt fails):
But, this change is still worthwhile because it allows me to eliminate the Fantastic! I'm pretty happy with this workaround, although, it goes without saying that proper fixed-IP support in Vagrant would be vastly superior. |
Hi @cbj4074, do you happen to know how to decrease the timeout of the halt? In my setup, it is taking about 10 mins to forcibly stop the VM. Thanks in advance |
I dont quite understand how you can do a vagrant reload command inside the script. Vagrant is locked during execution and should result in an error An action 'read_state' was attempted on the machine 'name', |
@jesperkragh Hello, in recent vagrant versions, this check is now done, and so running "vagrant reload" inside the script work no more like you said. I needed to change my script to handle the restart directly using the VM api. It makes the process faster by the way : )
Hope it helps! |
So after quite some time i got it to work. I ran into several issues. First the ssh command would not work because the file permissions on the insecure private key was wrong. After i fixed that i ran into wrong line endings in the shell command to set the static ip. I fixed that by changing the entire script from windows line endings to unix using notepad++ I also found out that setting the new switch for the vm before stopping the vm made the stop command very slow, so i changed the script so that it does this after vm shut down.
Here is my script if anyone is interrested. For information i create the Nat switch in the before up trigger and this script is run on the after up trigger.
|
I've been doing a bunch of kubernetes dev and need to build and tear down windows+linux kubernetes nodes pretty frequently on Hyper-V and have always wanted to use Vagrant for this type of thing. I'd appreciate any feedback, especially if anyone thinks this is worth pursuing further. |
I was looking into setting a static ip address for the machine's but im not entirely sure how we would go about that.
There are a few different ways to setup your network switch and would we implement different ways to set the ip address based on the network configuration?
Currently Vagrant doesnt manage the switches in any way, should we even try and start doing that.
When it is a extenal switch you basically part of the same network as the host, which usually means there is DHCP and a static IP is limited to your subnet. Also there is the possibility of collisions.
An internal switch has possiblities, but would require the user to share his internet on his adapter manually to get internet on the machine.
Another possibility is doing an internal switch and create a nat network, which would give some flexiblity, but i know that docker does this also and would probably conflict with that since windows can only handle one NAT network.
Anyways, i'm not entirely sure what the best way to go about it is.
Perhaps you have some insight @PatrickLang :)
The text was updated successfully, but these errors were encountered: