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 · 9 comments

Comments

Projects
None yet
7 participants
@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 from become guest tools independant to become guest tools independant for networking Jan 15, 2017

@rickard-von-essen rickard-von-essen changed the title from become guest tools independant for networking to builder/hyperv: become guest tools independant for networking Jan 15, 2017

@rickard-von-essen

This comment has been minimized.

Collaborator

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

This comment has been minimized.

Collaborator

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

This comment has been minimized.

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

This comment has been minimized.

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

This comment has been minimized.

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

This comment has been minimized.

Collaborator

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

This comment has been minimized.

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

This comment has been minimized.

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

This comment has been minimized.

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment