Is there any way to make the Waiting for SSH to become available to be faster ?
Right now, my deployment of PhotonOS 3, using latest packer, on OS X, uses 80% of the time, just waiting for SSH, on my fusion, even thou it’s ready to accept connections.
I have played around with ssh timeout, without any luck.
Right now it’s.
“ssh_timeout”: “10m”,
Thanks.
I’m not sure what builder you’re using but if you are building an image from scratch rather than launching a cloud image that is already built, “waiting for ssh” is always going to take a long time. This is because while Packer is waiting, the VM is busy running its preseed configuration. We suggest you enable SSH as your very last step to make sure that the instance is ready for further provisioners by the time Packer is able to connect. The way to shrink the “Waiting” time is to make the preseed as small as possible, with as few package installations as needed. But you’ll be able to see what the time is being spent on if you connect to your instance via VNC – Packer should print the VNC address to the UI so you can connect.
Thanks.
I’m using the VMware-iso builder. Is that what you mean ?
And i do understand, what you mean, but in this case, the image is really small, and there is nothing for it to do, so it’s just waiting and not doing anything.
I got a feeling, that it’s a timeout or something.
Packer detects when it reboot’s, and should imho be ready to take over, as soon as it donee rebooting, but ends up waiting instead.
If you can share a config I can take a look.
I have the same concern as well. i am using the Vshpere-iso. the packer waits for SSH for almost 2-3 hours. i am also looking for any suggestion to reduces this wait time. mine is windows vms. using the en_windows_server_2016_x64_dvd.iso. is there anything we could do with the hardware vsphere which might help in reduce this time!!
You might want to check if packer identifies the new IP of the virtual machine after it’s booted again.
I have faced this issue before where Packer would eventually timed out after ssh_timout was reached (and the build was rolled back) even though the VM was reachable by SSH. Do you know how Packer identifies the VM’s IP address?
A point to note, that when I was testing this build in Hyper-V the VM did not have “cloud-tools” packages installed, hence hypervisor itself did not know about the IP address that was assigned. I am now testing with these tools installed through cloud-init user-data and see whether it makes any difference.
Given that you’re creating templates with packer, you can normally have a dedicated IP for this. I’m not sure if packer knows how to use the guest agent to read the IPs ( and even if he did, how would he know which one to connect to? That also needs to be taken into consideration), but this is what I do, I tell it that it should connect over ssh to that ip with so-and-so user and it’s ok.
Thanks for feedback. So far I have build using hyperv and virtualbox. In both cases I do not know the VM IP upfront as it gets assigned through DHCP. I would say packer builder can query the hypervisor (hyperv, virtualbox, etc) for this information since it created the VM in the first place. Also once i installed the cloud tools, hyperv would show it and packer could then connect to perform the provisioning step.
But I could imagine an approach with static address defined during bootime, however it does not work for all builders in same manner.
I think you’re actually right. Packer is supposed to connect automatically. I chose to use a certain IP for my templates anyway (provisioned through auto-install in Ubuntu), but packer doesn’t use that information, it uses the information in ssh_host - which I’ve just realised I don’t even have in my configuration! And this works because packer figures out automatically what IP it should connect to:
The address to SSH to. This usually is automatically configured by the builder.
But I also think that this probably wouldn’t work if you don’t have the proper guest tools installed on the virtual machine (qemu-guest-agent, open-vm-tools, virtualbox guest tools etc.), because, as you mentioned, the hypervisor itself wouldn’t know the IP.
In my proxmox templates I always install qemu-guest-agent through cloud-init (provided by packer through its temporary http server).
The vmware-iso and vmware-vmx builders both have issues with taking excessive time to sort out the correct IP used by the guests during builds. This time can get extremely long if your dhcp leases file used by Fusion has 20+ entries as the “fusion6” packer driver searches through the list. I often see packer attempting to use the correct IP before the guest OS is ready and then taking super long to loop back around to try the correct one.
This has to do with changes apple made with macOS 11 and greater in combination with changes on Fusion to accommodate them. The packer fusion driver was updated, but a later Fusion release reverted the functionality.
Hi,
We are trying to run packer code for kvm image, we are using the qcow2 file, while executing the code, we are getting stuck at the below point:
==> qemu: Waiting 10s for boot…
==> qemu: Connecting to VM via VNC (0.0.0.0:5922)
==> qemu: Typing the boot commands over VNC…
qemu: Not using a NetBridge – skipping StepWaitGuestAddress
==> qemu: Using SSH communicator to connect: 127.0.0.1
==> qemu: Waiting for SSH to become available…
==> qemu: Timeout waiting for SSH.
==> qemu: Deleting output directory…
Build ‘qemu’ errored after 9 minutes 448 milliseconds: Timeout waiting for SSH.
==> Wait completed after 9 minutes 448 milliseconds
==> Some builds didn’t complete successfully and had errors:
→ qemu: Timeout waiting for SSH.
==> Builds finished but no artifacts were created.
Can someone please help/guide on this.
Hi SwampDragons,
We are trying to run packer code for kvm image, we are using the qcow2 file, while executing the code, we are getting stuck at the below point:
==> qemu: Waiting 10s for boot…
==> qemu: Connecting to VM via VNC (0.0.0.0:5922)
==> qemu: Typing the boot commands over VNC…
qemu: Not using a NetBridge – skipping StepWaitGuestAddress
==> qemu: Using SSH communicator to connect: 127.0.0.1
==> qemu: Waiting for SSH to become available…
==> qemu: Timeout waiting for SSH.
==> qemu: Deleting output directory…
Build ‘qemu’ errored after 9 minutes 448 milliseconds: Timeout waiting for SSH.
==> Wait completed after 9 minutes 448 milliseconds
==> Some builds didn’t complete successfully and had errors:
→ qemu: Timeout waiting for SSH.
==> Builds finished but no artifacts were created.
Can someone please help/guide on this.