Packer: [vmware-iso]: VM is not removed VMs and Templates inventory although the data is removed

[pdilung]

When using vmware-iso builder on ESXi, packer does remove data files of the VM after a conversion to OVF, however the VM itself remains registered/orphaned in the inventory, despite keep_registered is explicitly set to false (which should be false by default).

Reproducible: Always.

Software used:

• Packer Version: 0.10.0 as well as 0.10.1 (perhaps earlier versions are also affected)
• Host platform: VMWare ESXi 5.5.0, 2068190
• Guest OS: RHEL 6.7 and 7.2 with openvm-tools installed.

[rickard-von-essen]

Please Gist a packer debug log (PACKER_LOG=1 packer build template.json).

[epowell]

I believe this has to do with running in vCenter. I also have this issue (on 0.8.6 and 0.10.1), but only on builds that fail. The VM is deleted from the host's inventory, but not from the vCenter inventory.

[arizvisa]

So, I had a pretty similar issue within VMware and I determined it actually was happening due to a handle leak in https://github.com/mitchellh/packer/blob/master/builder/vmware/common/step_configure_vnc.go. I have it fixed in a PR (#3417) that's still pending from sometime last year so hopefully that'll get merged sometime...

Anyways, the commit that has a bunch of related fixes is here.
https://github.com/arizvisa/packer/commit/3099ab625ddd1957d7372eb384b828fc4a66dc15

The line of code containing the handle leak is here:
https://github.com/mitchellh/packer/blob/master/builder/vmware/common/step_configure_vnc.go#L68

If you notice, the line f, err := os.Open(vmxPath) doesn't have anything closing the handle w/ f.Close(). The way I fixed it in my PR was to add a defer f.Close() after the err != nil test. What was happening on my system was that due to golang still having a handle open to the .vmx, the unregister step was failing to unregister the VM. Once golang closes the handle, however, the unregistration happens without issue.

This isn't related to ESX, but I also had some issues due to packer checking the wrong lock filename on Windows for some instances of Workstation. When locking a machine, VMware will use a combination of a directory-based lock with a file-based one. Due to Packer explicitly checking for ".vmx.lck", it would block indefinitely during the shutdown step due to waiting for the wrong lock file to be released. This is also fixed in (#3417).

The line of code containing the issue is here:
https://github.com/mitchellh/packer/blob/master/builder/vmware/common/step_shutdown.go#L124

And can be fixed by changing the check on ".vmx.lck" (which is the file-based lock) to just ".lck" (which is the directory-based one which the file-based lock is within). This change will also catch both types of locks in case one is using an older version of VMware.

[alv000h]

+1
This issue is still present in version 1.0.3

I think it has to do with "vim-cmd vmsvc/destroy" (destroy the VM and appears as orphaned)

Log:
2017/07/20 20:10:49 packer: 2017/07/20 20:10:49 starting remote command: rm -f /tmp/script_5779.sh
2017/07/20 20:10:49 packer: 2017/07/20 20:10:49 Executing shutdown command: shutdown -h now
2017/07/20 20:10:50 packer: 2017/07/20 20:10:50 starting remote command: shutdown -h now
2017/07/20 20:10:50 packer: 2017/07/20 20:10:50 Remote command exited without exit status or exit signal.
2017/07/20 20:10:50 packer: 2017/07/20 20:10:50 starting remote command: vim-cmd vmsvc/power.getstate 71
2017/07/20 20:10:51 packer: 2017/07/20 20:10:51 starting remote command: vim-cmd vmsvc/power.getstate 71
2017/07/20 20:10:52 packer: 2017/07/20 20:10:52 starting remote command: vim-cmd vmsvc/power.getstate 71
2017/07/20 20:10:53 packer: 2017/07/20 20:10:53 starting remote command: vim-cmd vmsvc/power.getstate 71
2017/07/20 20:10:54 packer: 2017/07/20 20:10:54 starting remote command: ls -1p /vmfs/volumes/Datastore/rhel_7.2_64
2017/07/20 20:10:59 packer: 2017/07/20 20:10:59 starting remote command: ls -1p /vmfs/volumes/Datastore/rhel_7.2_64
2017/07/20 20:10:59 packer: 2017/07/20 20:10:59 starting remote command: rm /vmfs/volumes/Datastore/rhel_7.2_64/vmware.log
2017/07/20 20:10:59 packer: 2017/07/20 20:10:59 starting remote command: vim-cmd vmsvc/reload 71
2017/07/20 20:13:02 packer: 2017/07/20 20:13:02 starting remote command: vim-cmd vmsvc/power.getstate 71
2017/07/20 20:13:03 packer: 2017/07/20 20:13:03 starting remote command: vim-cmd vmsvc/destroy 71
2017/07/20 20:13:03 packer: 2017/07/20 20:13:03 starting remote command: test ! -e /vmfs/volumes/Datastore/rhel_7.2_64
2017/07/20 20:13:03 packer: 2017/07/20 20:13:03 Remote command exited with '1': test ! -e /vmfs/volumes/Datastore/rhel_7.2_64
2017/07/20 20:13:04 packer: 2017/07/20 20:13:04 starting remote command: test ! -e /vmfs/volumes/Datastore/rhel_7.2_64

[jimmywig]

adding this fix to next release would be great..

[SwampDragons]

Can someone confirm whether this is still an issue with a recent version of Packer? #3417 was merged some time ago and I'd love to know whether it or any other of our recent changes to vmware fixed things.

[sylviamoss]

I tested this with the current version of Packer and it cleans VM when keep_registered is not set to true. I will close this one for now.
If this issue persists for others, please let us know.

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