search

hashicorp / packer-plugin-vmware

Packer plugin for VMware Builder
https://www.packer.io/docs/builders/vmware
Mozilla Public License 2.0
46 stars 41 forks source link

Packer understands relative ISO paths, VMware doesn't #25

Closed stephenreay closed 6 days ago

stephenreay commented 3 years ago

Overview of the Issue

A previously working Packer config suddenly failed to boot VMWare (using Fusion 12) machines properly - the ISO was set, but never "Connected", and the VM shows "No Operating System found".

Some comparison with a manually-created VM shows that the path for the ISO was absolute.

The only change I've made in the Packer config, was to define the iso_target_path property (I'd previously used an external step to download the ISOs for repeated use). It seems that when this path is relative, Packer understands it fine, but VMWare does not.

The work-around for now is to supply the path as absolute, but ideally Packer would handle this.

Reproduction Steps

Have a packer config with iso_target_path specified as a relative path.

Plugin and Packer version

1.712

Operating system and Environment details

macOS 11.4 on Intel.

VMWare Fusion Professional 12.1.2

puetzk commented 2 years ago

I think the problem is https://github.com/hashicorp/packer-plugin-vmware/blob/274f4049159f7ada33bd0742c72c0ef27fee59d7/builder/vmware/iso/step_create_vmx.go#L77-L80

Which simply does nothing on err.

Thus, if the path cannot be made relative to config.VMXTemplatePath, it's just left unchanged. And so path that packer treated as relative to the working path, VMware treats as relative to the .vmx, and (unles output_directory happens to be the same place) the .iso is not there.

And https://pkg.go.dev/path/filepath#Rel says

An error is returned if targpath can't be made relative to basepath or if knowing the current working directory would be necessary to compute it

So I think packer should just make this Abs (using its own working dir) before it makes it Rel to the VMXTemplatePath. Though VirtualBox goes further and uses EvalSymlinks, not just Abs. I don't really see why that that would be desirable.

puetzk commented 2 years ago

Actually, it's a worse than that - config.VMXTemplatePath is https://www.packer.io/docs/builders/vmware/iso#vmx_template_path - it's an input template file, not the .vmx we're going to write, which is https://github.com/hashicorp/packer-plugin-vmware/blob/274f4049159f7ada33bd0742c72c0ef27fee59d7/builder/vmware/iso/step_create_vmx.go#L335 much later in the function. So in addition to everything being invalid relative paths, it's completely the wrong thing.

TigerC10 commented 2 years ago

I am eagerly awaiting a fix...

In the meantime, I got around it by specifying a variable absolute path like so:

source "vmware-iso" "ubuntu_2204" {
  iso_url = "https://releases.ubuntu.com/22.04/ubuntu-22.04-desktop-amd64.iso"
  iso_checksum = "sha256:b85286d9855f549ed9895763519f6a295a7698fb9c5c5345811b3eefadfb6f07"
  iso_target_path = "${path.cwd}/assets/iso/"
  #...
}
tenthirtyam commented 1 week ago

Addressed in #247.

Ryan Johnson Distinguished Engineer, VMware by Broadcom