Packer: Hyperv-iso with ssh communicator ignores ssh_host, and the default can not properly determine the IP

[digitalirony]

Using packer 0.12.1
Running scripts via Jenkins on a windows slave(via cygwin to interpret bash/use ssh).
Also running it manually to debug with PACKER_LOG=1

Packer config: https://gist.github.com/anonymous/ccf2517937033699d76fc61655c1283d

I will try and get a PACKER_LOG=1 output, but it is hard to capture due to the automation we are using.

The gist(no pun intended, but certainly appreciated) of the error output is:
[DEBUG] Error getting SSH address: No ip address.

It just streams the above error message over and over until ssh timeout is reached, at which point it tears down the build and exits.

I have tested ssh into the machine manually from inside of cygwin once the machine is installed and up. Manual ssh works correctly without issue.

I am no good at all with 'go' so I am unable to debug the code myself. However the error appears to be here:
https://github.com/hashicorp/packer/blob/master/builder/hyperv/iso/builder.go#L381

The line does not in any way account for ssh_host configuration option for the ssh communicator. Not only this, but it is unable to properly determine the IP address of the VM, so, unless I am missing something that isn't obvious(at least to me), this means building a linux hyperv-iso using packer is impossible?

[mwhooker]

Thanks for the report. Can you verify that this is still an issue with the latest release of packer?

[invisibleaxm]

Hello,

I am using packer v1.0.0 on windows and I can confirm that I am experiencing the same issue while trying to build a linux (CentOS 7) vm. The VM builds fine but packer times out waiting for SSH.

I enabled the PACKER_LOG=1 and I get the same issue:
[DEBUG] Error getting SSH address: No ip address.

I confirmed that I could login (via the console) to the Centos7 VM created by packer and the VM had an internal IP with external network access, SSH was up and running and listening on port 22 with firewall down, etc and still no luck (tcpdump showed no traffic to port 22).

For what it's worth, my get-vm powershell commandlet shows a null/empty string for the IPAddress field for all of my (linux) vms. I believe this is the "normal" scenario for Linux guests unless you manually install the Linux Integration Services on the guest: https://www.microsoft.com/en-us/download/details.aspx?id=51612

PS C:\WINDOWS\system32> get-vm | select -ExpandProperty NetworkAdapters | select VMName,IPAddresses

VMName               IPAddresses
------               -----------
centos7-invisibleaxm {}
MobyLinuxVM          {}
precise64            {}

Can you confirm if somehow having the LIS is a requirement?

[invisibleaxm]

I can confirm that after manually installing the Linux Integration Services, my get-vm commandlet returned and IP address and packer was able to continue the installation

VMName               IPAddresses
------               -----------
centos7-invisibleaxm {192.168.1.95}
MobyLinuxVM          {}
precise64            {}

Here are the logs after the change:

2017/05/01 11:06:28 packer.exe: 2017/05/01 11:06:28 [DEBUG] Error getting SSH address: No ip address.
2017/05/01 11:06:38 packer.exe: 2017/05/01 11:06:38 [DEBUG] TCP connection to SSH ip/port failed: dial tcp 192.168.1.95:22: connectex: No connection could be made because the target machine actively refused it.
2017/05/01 11:06:48 packer.exe: 2017/05/01 11:06:48 [INFO] Attempting SSH connection...
2017/05/01 11:06:48 packer.exe: 2017/05/01 11:06:48 reconnecting to TCP connection for SSH
2017/05/01 11:06:48 packer.exe: 2017/05/01 11:06:48 handshaking with SSH
2017/05/01 11:06:48 packer.exe: 2017/05/01 11:06:48 handshake complete!
2017/05/01 11:06:48 packer.exe: 2017/05/01 11:06:48 [INFO] no local agent socket, will not connect agent
==> hyperv-iso: Connected to SSH!
2017/05/01 11:06:48 ui: ==> hyperv-iso: Connected to SSH!
2017/05/01 11:06:48 packer.exe: 2017/05/01 11:06:48 Running the provision hook
2017/05/01 11:06:48 ui: ==> hyperv-iso: Gracefully halting virtual machine...
==> hyperv-iso: Gracefully halting virtual machine...
2017/05/01 11:06:48 packer.exe: 2017/05/01 11:06:48 Executing shutdown command: /sbin/halt -p
2017/05/01 11:06:48 packer.exe: 2017/05/01 11:06:48 opening new ssh session
2017/05/01 11:06:48 packer.exe: 2017/05/01 11:06:48 starting remote command: /sbin/halt -p
2017/05/01 11:06:48 packer.exe: 2017/05/01 11:06:48 Waiting max 5m0s for shutdown to complete

Any suggestions ? Does this mean I will have to make sure to install the LIS driver's to get packer to work? Is there a way to specify a static IP address ?

[digitalirony]

Well, I am using the "ssh_host" : option in the build config.
Also, supposedly, since centos 6.5, LIS should be installed(not the case
for me either with 7). However, using the ssh_host option in the config,
the build doesn't read it, and still fails. So I ended up modifying the
code, and compiling manually to force it always 'require/read' the ssh_host
option, and this worked for me.

On Mon, May 1, 2017 at 9:11 AM, Alex Campos [e-mail]
wrote:

I can confirm that after manually installing the Linux Integration
Services, my get-vm commandlet returned and IP address and packer was able
to continue the installation

VMName IPAddresses
------ -----------
centos7-invisibleaxm {192.168.1.95}
MobyLinuxVM {}
precise64 {}

Here are the logs after the change:

2017/05/01 11:06:28 packer.exe: 2017/05/01 11:06:28 [DEBUG] Error getting SSH address: No ip address.
2017/05/01 11:06:38 packer.exe: 2017/05/01 11:06:38 [DEBUG] TCP connection to SSH ip/port failed: dial tcp 192.168.1.95:22: connectex: No connection could be made because the target machine actively refused it.
2017/05/01 11:06:48 packer.exe: 2017/05/01 11:06:48 [INFO] Attempting SSH connection...
2017/05/01 11:06:48 packer.exe: 2017/05/01 11:06:48 reconnecting to TCP connection for SSH
2017/05/01 11:06:48 packer.exe: 2017/05/01 11:06:48 handshaking with SSH
2017/05/01 11:06:48 packer.exe: 2017/05/01 11:06:48 handshake complete!
2017/05/01 11:06:48 packer.exe: 2017/05/01 11:06:48 [INFO] no local agent socket, will not connect agent
==> hyperv-iso: Connected to SSH!
2017/05/01 11:06:48 ui: ==> hyperv-iso: Connected to SSH!
2017/05/01 11:06:48 packer.exe: 2017/05/01 11:06:48 Running the provision hook
2017/05/01 11:06:48 ui: ==> hyperv-iso: Gracefully halting virtual machine...
==> hyperv-iso: Gracefully halting virtual machine...
2017/05/01 11:06:48 packer.exe: 2017/05/01 11:06:48 Executing shutdown command: /sbin/halt -p
2017/05/01 11:06:48 packer.exe: 2017/05/01 11:06:48 opening new ssh session
2017/05/01 11:06:48 packer.exe: 2017/05/01 11:06:48 starting remote command: /sbin/halt -p
2017/05/01 11:06:48 packer.exe: 2017/05/01 11:06:48 Waiting max 5m0s for shutdown to complete

Any suggestions ? Does this mean I will have to make sure to install the
LIS driver's to get packer to work?

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/hashicorp/packer/issues/4825#issuecomment-298363871,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AEdODNnbo8TdJvLPzJE9Cjl1GvjOTjmaks5r1gQ0gaJpZM4NGD4T
.

[wickedviking]

LIS is installed, well the drivers are anyway, what you need are the daemons. Add the following to the %post section of your ks.cfg:

#hyperv support
if [ $(virt-what) == "hyperv" ]; then
    yum -y install hyperv-daemons
    systemctl enable hypervvssd
    systemctl enable hypervkvpd
fi

[invisibleaxm]

Sweet! I'll spend some cycles testing this, i guess it makes sense that
this will be causing the hyp not talk to built-in lis (which btw i prefer
to use since they are easier to maintain)

Thanks again!!

Alex

On May 4, 2017 12:34 PM, "WickedViking" [e-mail] wrote:

LIS is installed, what you need are the daemons. Add the following to the
%post section of your ks.cfg:

hyperv support

if [ $(virt-what) == "hyperv" ]; then
yum -y install hyperv-daemons
systemctl enable hypervvssd
systemctl enable hypervkvpd
fi

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/hashicorp/packer/issues/4825#issuecomment-299255625,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABIqX8nxSFzJS4s0H3gXkWaPDN0hUkv-ks5r2gwJgaJpZM4NGD4T
.

[wickedviking]

@mwhooker I don't think this is really a bug on packer's behalf, more of a nuance for working with Hyper-V. The daemons need to be installed, enabled, and running after the kickstart reboots. This is a RHEL & derivatives specific solution. Ubuntu, for example, is slighty different. And the guest OS must have Hyper-V LIS support, so it's not a global thing as some distro's are not yet supported. If anything, this should just be an addition to the Hyper-V builder docs.

[taliesins]

This is more an issue with running OSes on hypervisors that do not have built in drivers/support for the hypervisor they are running in.

Closing for now.

[wickedviking]

That's not at all what this is about, the OSes mentioned do in fact have the drivers pre-packaged, in the case of CentOS, and I assume most RHEL derivatives, the daemons are missing and cannot be installed without network connections available to the %POST section of the kickstart.

Two things must accomplished to build RHEL derivatives on Hyper-V, 1st you must ensure the system being built has network in %post, this can be done via

network --bootproto=dhcp --onboot=on --device=eth0

Then in post you need to ensure the daemons are install, but only when using hyper-v, which is done via

#hyperv support
if [ $(virt-what) == "hyperv" ]; then
    yum -y install hyperv-daemons
    systemctl enable hypervvssd
    systemctl enable hypervkvpd
fi

With out both of these workarounds, hyperv-iso will not build RHEL systems. Before you write this off as a CentOS problem, which is debatable since they have provided the functionality required, you should consider whether this is a matter of documentation or if some hyperv specific functionality should be added to packer to allow these systems to build. CentOS is not a flavor of the month after all.

Packer is the failure point here, not CentOS or Hyper-V. Well ok, you could debate that Hyper-V is the failure point... But it is what it is. So, more specifically, packers' hyperv-iso builder is the failure point here.

I guess what I am getting at is that this shouldn't be closed until it's at least documented for the community on packer.io. Closing this issue as it, doesn't advance understanding and leaves anyone having this issue in the dark unless they happen to find this bug.

[ladar]

I found this bug, and can confirm that with 1.3.4-dev, the hyper-iso builder still ignores the value of ssh_host and thus is still incapable of building operating systems that lack Hyper-V daemon support (see #5049). Without the daemons, the Hyper-V builder IP address auto detection fails. In theory auto detection shouldn't be needed, or even used, if an ssh_host value is provided.

This report stems from having fixed the network access issue, by adding support for legacy network adapters (see #7128) and by overcoming the media ejection hurdle by changing the boot order (see #7147).

With those fixes in place I was _finally_ able to install NetBSD and DragonflyBSD on Hyper-V, and get the guest VMs to reboot properly, without manual intervention. I am also able to confirm remote access via SSH to the freshly installed guest. Unfortunately because those guest operating systems lack Hyper-V daemon support, I am trying to workaround the problem by specifying the guest MAC address, and then configuring my DHCP server to return a fixed IP to that guest. In theory, setting the ssh_host value with this predictable IP should work... but it doesn't.

I'm playing around with a possible code fix, but wanted to (re)-report the issue in case I don't fix this issue and submit a pull request.

The relevant lines of my generic-hyperv.json file are here, and here. And the debug log file is filled with a large number lines that look like:

2018/12/26 23:51:05 packer.exe: 2018/12/26 23:51:05 [DEBUG] Error getting SSH address: No ip address.
2018/12/26 23:51:13 packer.exe: 2018/12/26 23:51:13 [DEBUG] Error getting SSH address: No ip address.
2018/12/26 23:51:20 packer.exe: 2018/12/26 23:51:20 [DEBUG] Error getting SSH address: No ip address.
2018/12/26 23:51:27 packer.exe: 2018/12/26 23:51:27 [DEBUG] Error getting SSH address: No ip address.
2018/12/26 23:51:34 packer.exe: 2018/12/26 23:51:34 [DEBUG] Error getting SSH address: No ip address.
2018/12/26 23:51:42 packer.exe: 2018/12/26 23:51:42 [DEBUG] Error getting SSH address: No ip address.
2018/12/26 23:51:49 packer.exe: 2018/12/26 23:51:49 [DEBUG] Error getting SSH address: No ip address.
2018/12/26 23:51:56 packer.exe: 2018/12/26 23:51:56 [DEBUG] Error getting SSH address: No ip address.
2018/12/26 23:52:04 packer.exe: 2018/12/26 23:52:04 [DEBUG] Error getting SSH address: No ip address.
2018/12/26 23:52:11 packer.exe: 2018/12/26 23:52:11 [DEBUG] Error getting SSH address: No ip address.
2018/12/26 23:52:18 packer.exe: 2018/12/26 23:52:18 [DEBUG] Error getting SSH address: No ip address.
2018/12/26 23:52:25 packer.exe: 2018/12/26 23:52:25 [DEBUG] Error getting SSH address: No ip address.
2018/12/26 23:52:33 packer.exe: 2018/12/26 23:52:33 [DEBUG] Error getting SSH address: No ip address.
2018/12/26 23:52:40 packer.exe: 2018/12/26 23:52:40 [DEBUG] Error getting SSH address: No ip address.
2018/12/26 23:52:47 packer.exe: 2018/12/26 23:52:47 [DEBUG] Error getting SSH address: No ip address.
2018/12/26 23:52:55 packer.exe: 2018/12/26 23:52:55 [DEBUG] Error getting SSH address: No ip address.

[SwampDragons]

Thanks, Ladar! I've reopened until I get a chance to test out your patch.

[hashibot[bot]]

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.