Packer: VMware + vmx issues

[evilezh]

Platform: Windows 10 pro
VMware: VMware workstation pro 12
Packer: 1.0

1. it works only with ide disks. In case with non-ide drive .. it reports something like: 'e:\output-vmware-vmx\auto detect' not found. I did quick lookup into code - and found out that only IDE is supported (hardcoded). Nothing in documentation.

2. created files names have non-interpolated field - timestamp: packer-vmware-vmx-{{timestamp}}.vmx

Both problems are not critical .. i can rename later files or if you can read code, you can figure out, that only IDE drive supported. I would suggest add scsi/sata support as it is kinda default always rather than IDE.

[rickard-von-essen]

Please supply the information requested in the issue template:

• Packer version (packer version)
• Host platform (uname -a etc.)
• Debug log output from PACKER_LOG=1 packer build template.json.
  Please paste this in a gist.
• The _simplest example template and scripts_ needed to reproduce the bug.
  Include these in your gist.

---

1) I don't follow this, please be a bit more precise and supply the requested information.

[evilezh]

I updated packer version ...
Windows 10 pro is quite specific - there isn't anything else to say. Latest updates, plenty of memory/cpu etc.

I provided enough information.
for 1: here is exact line of code.
https://github.com/hashicorp/packer/blob/9f992b8f809525903049fdda94a4dcdeaeb0cd8a/builder/vmware/common/step_clean_vmx.go#L56
or line 46 where IDE only regex defined. Maybe something like

devRe := regexp.MustCompile(`^(ide|scsi|sata)\d:\d\.`)

would be enough ? Not sure about scsi/sata patterns.

for 2: there is nothing to output, that is exact name of resulting file: packer-vmware-vmx-{{timestamp}}.vmx

here is last lines

==> vmware-vmx: Gracefully halting virtual machine...
    vmware-vmx: Waiting for VMware to clean up after itself...
==> vmware-vmx: Deleting unnecessary VMware files...
    vmware-vmx: Deleting: output-vmware-vmx\packer-vmware-vmx-{{timestamp}}.vmx.lck\M29079.lck
    vmware-vmx: Deleting: output-vmware-vmx\vmware.log
==> vmware-vmx: Compacting the disk image
==> vmware-vmx: Cleaning VMX prior to finishing up...
    vmware-vmx: Unmounting floppy from VMX...
    vmware-vmx: Disabling VNC server...
Build 'vmware-vmx' finished.

here is config section:

{
      "type":             "vmware-vmx",
      "source_path":      "C:\\Users\\*******\\Documents\\Virtual Machines\\ubuntu-server\\ubuntu-server.vmx",
      "ssh_username":     "ubuntu",
      "ssh_password":     "*******",
      "shutdown_command": "sudo shutdown -P 0"
    }

I used SCSI drives in vmware which are by default.

[znerd]

I've got the same issue where {{timestamp}} is literally in the file name, with Packer 1.0.0 and VMware Fusion Pro 8.5.7 (provider vmware-vmx).

Note that I'm using VirtualBox (provider virtualbox-ovf) as well, and that one works flawless.

[charlievieth]

I ran into this error as well. It comes from vmware-vdiskmanager, which packer shells out to, during the CompactDisk step. I was able to fix it by changing ide0:0.fileName = "auto detect" to ide0:0.autodetect = "TRUE" in the target vmx file. It would appear that VMware Workstation and Fusion use a mix of the two to indicate that a CD is set to Auto-detect.

Below is the error message:

1498767461,,ui,say,==> vmware-vmx: Compacting the disk image
1498767462,,ui,say,==> vmware-vmx: Deleting output directory...
1498767462,,ui,error,Build 'vmware-vmx' errored: Error compacting disk: VMware error: Failed to open the disk 'C:\foo\vm\auto detect' : A file was not found (0x4).\r\nFailed to defragment: A file was not found (0x4).
1498767462,,error-count,1
1498767462,,ui,error,\n==> Some builds didn't complete successfully and had errors:
1498767462,vmware-vmx,error,Error compacting disk: VMware error: Failed to open the disk 'C:\foo\vm\auto detect' : A file was not found (0x4).\r\nFailed to defragment: A file was not found (0x4).
1498767462,,ui,error,--> vmware-vmx: Error compacting disk: VMware error: Failed to open the disk 'C:\foo\vm\auto detect' : A file was not found (0x4).\r\nFailed to defragment: A file was not found (0x4).
1498767462,,ui,say,\n==> Builds finished but no artifacts were created.

[giovannidegani]

Same issue for me with packer 1.0.2 and Vmware fusion 7.1.3.

All files have {{timestamp}} in the name.
But I dont have any ide0:0, only sata and is set already to "TRUE".

[mwhooker]

the timestamp problem should be fixed in #5274

[goodwinb99]

I'm having the same problem with it trying to compact a non-existent file because I can't find a way to delete a key in vmx_data using packer. I need to delete, e.g., ide0:0.filename because if that value is set to anything, it'll try to compact it, regardless of the autodetect setting. Is there a way to, in packer, remove a key from the vmx file when the builder is done?

[rastating]

Also having this issue - temporarily worked around using the steps suggested by @charlievieth; i.e. to change ide0:0.fileName = "auto detect" in the source VMX to ide0:0.autodetect = "TRUE"

[Selora]

Same issue as @rastating & others. Same fix.
ide0:0.fileName = "auto detect" -> ide0:0.autodetect = "TRUE"
-Packer 1.2.0
-VMware Fusion 10 Pro

[eduncan911]

Confirmed same issue. Building an ubuntu image on Fusion using vmware-iso to generate a base vm, and then using vmware-vmx to create additional VMs from that base vmx.

Packer 1.2.1, latest vmware fusion as of this date.

I fixed it by changing my packer template to have the ide0:0.autodetect: true as seen below:

{
  "builders": [
    {
      "type": "vmware-iso",
      ...snip...
      "vmx_data": {
        ...snip...
        "ide0:0.autodetect": true
      },
     ...

This then generated an VMX that replaced the "ClientDevice" line with the autodetect line in my source VMX:

ide0:0.autodetect = "1"
ide0:0.devicetype = "cdrom-image"
ide0:0.filename = "/Users/ericduncan/code/packer-test/local_files/ubuntu-14.04.5-server-amd64.iso"
ide0:0.present = "TRUE"

[Mrmayank]

@eduncan911 The above fix didn't work in builder 'vmware-iso' for Ubuntu. That image is built but when vmware-vmx is built using that image the same error came 'some_dir\auto detect' : A file was not found (0x4).' Also, the device type is cdrom-raw in my case but you have cdrom-image with a given path to .iso that's why it worked.

@goodwinb99 (The question whcih you posted) I think if somehow we can get rid of ide1:0.filename = "auto detect" in the first vmx build using vmware-iso, it can help to eliminate the manual part of editing the first .vmx. Any ideas how can that be done (in vmx_data)?

[DanHam]

Hi all. Hopefully the reported errors at the compacting stage of the VMX build should be fixed by #6074. Please see the comment here for further info.

[SwampDragons]

If anyone would be willing to try the patch in #6074 and verify that it solves some of the problems here, let me know your system architecture and I can build you a binary.

[embusalacchi]

I will try the patch.

[DanHam]

@embusalacchi Thanks for offering to test!

Do you need a binary built or are you able to build the binary + patch yourself? If not what OS do you need the Packer binary for? @SwampDragons should be able to provide one for you.

[embusalacchi]

@DanHam OSX That would be super helpful - OSX binary would be great.

[DanHam]

@SwampDragons Could you provide @embusalacchi with the required binary?

[SwampDragons]

@embusalacchi here you go:
packer.zip

[embusalacchi]

@SwampDragons @DanHam I tested the binary with the same workflow that failed for me yesterday with the error and it worked without a problem!

[DanHam]

@embusalacchi Great! Thanks for testing. Were you able to test with a VM with multiple disks?

[embusalacchi]

@DanHam I did not test with multiple disks but it is easy for me to do - I can do that tomorrow morning (EST) and let you know.

[embusalacchi]

A little late but I did a run with multiple disks and it worked!

[DanHam]

@embusalacchi Better late than never! Thanks a lot for helping out.

[SwampDragons]

Closed in #6074

[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.