builder/hyperv: become guest tools independant for networking

[w9n]

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.

[rickard-von-essen]

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]

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

[w9n]

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]

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]

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]

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]

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.