Packer Builds Field Notes

expect_disconnect is useful, but it is not a broom. When a Packer vsphere-iso build fails with Script disconnected unexpectedly, the important question is whether the command already completed before SSH dropped. If the command was interrupted mid-package-install, telling Packer to expect the disconnect can turn a real partial install into a green build step. Symptom The build reaches a shell provisioner and fails after cloud-init finishes: Provisioning with shell script: /tmp/packer-shell123456789 Cloud-init finished... Synchronizing state of open-vm-tools.service with SysV service script... Executing: /usr/lib/systemd/systemd-sysv-install enable open-vm-tools Script disconnected unexpectedly. The template may build successfully in one vSphere environment and fail in another because network convergence and VMXNET3 behavior differ by host, port group, or timing. Do not assume the template is safe just because a sibling environment happened to tolerate the restart. ...

A Packer image pipeline produces more than a template. It produces evidence. If the only durable output is “template exists in vSphere,” operators lose the ability to answer the questions that matter during rollback or incident review: What source produced this template? Which Packer and plugin versions built it? Which variables were used, excluding secrets? Which validation gates passed? Which template was promoted to current? What changed from the previous image? Artifact storage is the operating memory of the image factory. ...

Migrating Packer templates to HCL2 is not just a syntax cleanup. It changes how operators reason about variables, plugin versions, reusable blocks, and what the pipeline can validate before a build starts. The goal is not to make the file look modern. The goal is to make image builds easier to review, safer to parameterize, and less dependent on undocumented wrapper behavior. Preserve The Operating Boundary Do not use an HCL2 migration to move runtime configuration back into the image. ...

Windows images fail differently than Linux images, but the lifecycle boundary is the same: the template should contain the reusable mechanism, not the clone’s final identity. A Windows Packer build usually has more moving parts before the first provisioner runs: unattended installation or answer-file behavior. VMware Tools installation and reboot timing. WinRM enablement and firewall access. Windows Update or baseline configuration. sysprep and shutdown before template capture. vSphere clone customization or first-boot configuration after deployment. Do not compress those into “Packer built a Windows template.” Ask which stage owns which state. ...

A Packer template can contain a bootstrap framework without owning every piece of clone behavior. The boundary is sealing. A successful packer build produces a configured machine; it does not, by itself, prove that the resulting artifact is safe to clone. Sealing is the lifecycle stage where a configured build machine is deliberately converted into a reusable artifact, and ownership of state changes hands: configured machine -> sanitized machine -> sealed template -> clone -> uniquely identified machine That makes the ownership boundaries explicit: ...

A Packer template build can fail in three different places that look similar from the outside: Packer never reaches SSH, so file and shell provisioners never run. Packer places bootstrap files into the template, but does not execute runtime bootstrap. Terraform/cloud-init clones the VM but does not start the bootstrap entrypoint correctly. Do not diagnose all three as “bootstrap did not work.” Ask which layer failed. Placement Is Packer’s Job For a reusable vSphere template, Packer should place static resources only. For the follow-on sealing pattern after the bootstrap payload is placed and validated, see Packer Template Sealing After Clone-Time Bootstrap. ...

Terraform can successfully ask vSphere to clone a VM and still fail during guest customization. In that case, the problem is usually inside the guest/template, not Terraform syntax. Symptom Terraform reports an error like: Virtual machine customization failed An error occurred while customizing VM ... For details reference the log file /var/log/vmware-imc/toolsDeployPkg.log in the guest OS. Terraform may leave the VM in place to help troubleshooting. First Checks From the VM console or SSH if available: ...

Terraform can inject cloud-init data into vSphere clones through VMware guestinfo keys. That only works if the template is built to let cloud-init run on first boot. Symptom Terraform creates or replaces the VM, but the expected userdata.yaml behavior does not happen. Bootstrap does not run, SSH is not configured, or /var/log/platform-bootstrap.log is missing. Check Guestinfo From vSphere Use govc to inspect the VM extra config: source govc.env govc vm.info -e /DC-Site-A/vm/K8s-Cluster/OpsTools/cluster-a-api-lb-01 \ | grep 'guestinfo\|disk.enableUUID' Look for keys like: ...