Skip to content
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

builder/hyperv: become guest tools independant for networking #4404

Closed
w9n opened this issue Jan 15, 2017 · 10 comments
Closed

builder/hyperv: become guest tools independant for networking #4404

w9n opened this issue Jan 15, 2017 · 10 comments

Comments

@w9n
Copy link

@w9n w9n commented Jan 15, 2017

hi all,

as discussed here packer does not handle vms without guest tools in the aspect of networking well. As @taliesins mentioned there is also a demand to specify the ip and mac address of the vm independently from the vms os and the hypervisor to ensure network regulatory.

One idea is to develop a mode where the machine is not set up to a hosts network device, but to a bridge that leads to a small proxy vm that handles the connection to us the admin. The advantage could be a hypervisor and os independent place to manage networking.

But i am not sure how to pass our desired network configuration to the proxy vm.(somehow add a file to the proxy vm before deployment or use current technology which would shift guest tool dependency to the proxy vm and would not meet network regulatory requirements)

Apart from that the proxy machine would mainly need a dhcp server and forward ssh to the actual vm.

@w9n w9n changed the title become guest tools independant become guest tools independant for networking Jan 15, 2017
@rickard-von-essen rickard-von-essen changed the title become guest tools independant for networking builder/hyperv: become guest tools independant for networking Jan 15, 2017
@rickard-von-essen
Copy link
Collaborator

@rickard-von-essen rickard-von-essen commented Jan 15, 2017

IMHO I think disturbing that this isn't solved in Hyper-V. All other virtualization engine manage to handle it in a ok way. It seems like adding a lot of complexity to Packer to fix that Hyper-V is broken.

@mwhooker
Copy link
Contributor

@mwhooker mwhooker commented Feb 3, 2017

Interesting idea. I'm not sure I'm on board with something this complex. We should continue to discuss ideas about how we can achieve this with hyperv. Let's keep the discussion going in this thread, but going to close it since it's not something we're planning on working on

@mwhooker mwhooker closed this Feb 3, 2017
@w9n
Copy link
Author

@w9n w9n commented Feb 10, 2017

HyperV should have to save dhcp leases somewhere regardless of gues tools. But i completly switched to qemu so wont do any further research.

@gh2k
Copy link

@gh2k gh2k commented Mar 2, 2017

I ran into this problem making a Debian build.

This should be fixable by using a "legacy network adapter" in Hyper-V. This will report the proper IP address without the tools installed. The downside is that there's a performance penalty to them, so you may not want them to end up in the final machine.

Ideally one would want to boot and provision with the legacy adapter, and then (optionally, depending on whether you expect the tools to be there when you're done?) swap it for a non-legacy one before building the final image.

I eventually worked around the problem my end by mangling the preseed file to run a script that managed to fix the hyperv integration tools, but it wasn't straightforward.

I did however determine that if I modified the VM to use a legacy network adapter, Packer found the IP address without the tools being installed.

@gh2k
Copy link

@gh2k gh2k commented Mar 13, 2017

So, I tried to fix this in #4656 but it looks like I misunderstood what a legacy network adapter does and it doesn't actually help. There must have been some other side-effect in my tests that allowed the broken tools in my guest OS (they don't seem to work proberly in kernel 4.9) to see the adapter properly after unplug/replug, or something like that.

I concur that it's weird Hyper-V can't do this, but I couldn't find a nontrivial way of getting beyond this without the tools. Maybe Packer could open a port and the typed boot command or similar could write the IP address to it? It does seem like a lot of work to bypass a hyper-v issue.

If the tools in the mainline kernel are going to break from time to time though, maybe it's worth it? (shrug)

@taliesins
Copy link
Collaborator

@taliesins taliesins commented Mar 13, 2017

Legacy adaptor is physical network card emulated in software. OS treats network card like a physical one, so driver works in an un-optomized way.

Other network card types are para-virtualized. OS knows they are virtualized, so it the driver works in an optimized way.

The solution is dhcp and static mac reservations.

@matthew-hickok
Copy link

@matthew-hickok matthew-hickok commented Dec 16, 2017

The MAC address is known already and Powershell is already being used, so why not just change the method of getting the IP address from the adapter and query for the active IP that has that MAC address via arp?

$ip = (Get-NetNeighbor -LinkLayerAddress $mac -State Reachable -AddressFamily IPv4).IPAddress

Maybe not that command exactly -- but something along those lines. Or maybe that could just be backup method if it is unable to get the IP by querying the VM adapter directly.

I really don't like the idea of requiring integration services for Packer builds to successfully run. Plenty of smaller distros do not and likely don't have plans in the near future to add these modules.

@matthew-hickok
Copy link

@matthew-hickok matthew-hickok commented Dec 18, 2017

@taliesins

Could you expand on this:

The solution is dhcp and static mac reservations.

What do you have in mind?

@tuxillo
Copy link

@tuxillo tuxillo commented Mar 6, 2018

Hi,

I can't see any option in the documentation (https://www.packer.io/docs/builders/hyperv-iso.html) to use a legacy network driver for the builder.
Is there any way to do so?

Thanks,
Antonio Huete

@hashibot
Copy link

@hashibot hashibot bot commented Apr 2, 2020

I'm going to lock this issue because it has been closed for 30 days . This helps our maintainers find and focus on the active issues.

If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.

@hashibot hashibot bot locked and limited conversation to collaborators Apr 2, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
7 participants