SSH timeout because IP address changes

[matthew-hickok]

• Packer version: v1.1.2
• Host platform: Hyper-V on Windows Server 2016
• Guest: CoreOS

I'm getting stuck creating a Hyper-V image for CoreOS. I've get everything working on VMware Workstation, but with Hyper-V I get stuck waiting for SSH to become available. I noticed that when Packer initially creates the VM, it boots to disc, has one IP address, and then when it reboots after the install to hard disk, the IP address is different. So it makes sense that SSH times out.

How do people typically get around this? And how does Packer normally detect the IP address of the guest?

[SwampDragons]

Have you gotten this to work before, or are you trying to figure out Packer for the first time? Normally for "question" issues we refer people to the mailing list: https://groups.google.com/forum/#!forum/packer-tool

[matthew-hickok]

@SwampDragons I'm pretty familiar with Packer, but less familiar with the details of its implementation of the hyper-v builder.

My builds work with CoreOS+VMware and anything+Hyper-V, but specifically Hyper-V+CoreOS seem to have an issue with IP address detection.

So I guess this is just a question, but I can't find any information on how exactly packer detects a guest's IP address on Hyper-V. It may be related to an issue with the fact that CoreOS doesn't support Hyper-V integration services, but then again I don't know if that's how Packer obtains the IP.

[rickard-von-essen]

Packer first uses this powershell script find the mac of the VM, and then the following script to get the IP associated with the mac.

Check and what you get if you run those manually.

[matthew-hickok]

@rickard-von-essen

I ran the scripts and it pretty much confirmed what I was thinking -- Packer queries the network adapter with Get-VMNetworkAdapter, which will only work if integration services are working properly on the guest. So I can get the MAC but not the IP.

So it does not return the IP address because CoreOS does not implement all of the Hyper-V Integration Services (coreos/bugs#2161).

I was able to validate this by spinning up a Ubuntu container on my CoreOS host, and copying the missing Hyper-V integration service binaries (primarily hv_kvp_daemon) back to the CoreOS host. After doing that, the Packer script was able to detect the IP address without issue.

I really don't like the idea of relying on integration services for this. I made another suggestion here: #4404

Might be a terrible idea, but it would be great to have a more stable requirement than a proper implementation of these integration services.

[stuartluscombe]

I too am experiencing this issue.

OS: Windows 10 Enterprise x64 1709
Packer: 1.2.1

I am using the "Default Switch" that was automatically installed by Windows as part of the 1709 update.

When packer starts up a build it is pulling the IP of the VMSwitch rather than the VM. If I query 'Get-VMNetworkAdapter *' throughout the OS installation there are no IP addresses listed. It is only when the install completes and the VM reboots with the integration services installed that an IP shows up.

If I switch to using an 'External' VMSwitch then the IP of the network adapter is the one that is picked up.

It would make sense if possible for packer to re-query the network adapter for any changes and update if necessary. That, or perform the query later on in the process?

[ghost]

This issue has been automatically migrated to hashicorp/packer-plugin-hyperv#17 because it looks like an issue with that plugin. If you believe this is not an issue with the plugin, please reply to hashicorp/packer-plugin-hyperv#17.

[ghost]

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.