It leaves multiple files in the output-vmware-iso folder. Also the vm is still in vmware fusion.
I cannot import the output into vmware fusion/ virtualbox.
==> vmware-iso: Gracefully halting virtual machine...
vmware-iso: Waiting for VMware to clean up after itself...
==> vmware-iso: Deleting unnecessary VMware files...
vmware-iso: Deleting: output-vmware-iso/startMenu.plist
vmware-iso: Deleting: output-vmware-iso/vmware ubuntu-14-04dev0.1.plist
vmware-iso: Deleting: output-vmware-iso/vmware ubuntu-14-04dev0.1.vmx.lck/M53286.lck
vmware-iso: Deleting: output-vmware-iso/vmware.log
==> vmware-iso: Cleaning VMX prior to finishing up...
vmware-iso: Detaching ISO from CD-ROM device...
==> vmware-iso: Compacting the disk image
Build 'vmware-iso' finished.
==> Builds finished. The artifacts of successful builds are:
--> vmware-iso: VM files in directory: output-vmware-iso
$ ls output-vmware-iso/
disk-s001.vmdk vmware ubuntu-14-04dev0.1.nvram
disk-s002.vmdk vmware ubuntu-14-04dev0.1.vmsd
disk-s003.vmdk vmware ubuntu-14-04dev0.1.vmx
disk-s004.vmdk vmware ubuntu-14-04dev0.1.vmx.lck/
disk.vmdk vmware ubuntu-14-04dev0.1.vmxf
This is correct. the VMware builder builds VMware machines, not OVA.
Would it not be possible to add export option like virtualbox?
format = vmx/ovf/ova.
If vmx, nothing happens. But if ovf or ova, ovftool file.vmx file.ova is called.
No experience with .go, else I would I added a PR.
Perhaps the reason this isn't done is that the output of the build is left on the ESXi host's datastore, and ovftool isn't available on the host.
if its not available, give an error. User will change the output format to vmx. Why should somebody who has ovftool on their host, require to have to write another script outside of packer to automate this? Its not just a simple command if you are building a complete automated setup system. You have to add error checking to figure out if the VM was built successfully.
I don't believe that ovftool is officially supported on the host, and having it available from the ESXi shell probably isn't very common. Most users would have to be pointed to instructions (e.g., http://www.virtuallyghetto.com/2012/05/how-to-deploy-ovfova-in-esxi-shell.html) on how to install ovftool on ESXi.
Alternatively, the output directory could be automatically copied back (via scp) to the packer client, and ovftool could be run there. This would add to the build time but has additional benefits (e.g., if you're generating an ova, you're probably planning to copy it off the host anyway).
I agree this would be a nice feature.
ovftool can be used to create an ova from a remote VM:
ovftool vi://[esxi host]/[vmname] [vmname].ova
This assumes that [vmname] is (re-)registered on [esxi host].
Ideally, we could use an OVFTool post-processor that does this, pointing at the remote VM and exporting to a file. But here's some hackery to tide you over.
As of Packer v0.8.6 I am using these provisioning actions to do this with ovftool installed on the local box alongside Packer: Target is an ESXi 6.0.0 host.
{
"type": "shell-local",
"command": "vim-cmd vmsvc/power.off `vim-cmd vmsvc/getallvms | grep '\\[{{user `remote_datastore`}}\\] {{user `output_directory`}}/{{user `vm_name`}}.vmx' | cut -d' ' -f 1`",
"execute_command": ["sshpass", "-p", "{{user `remote_password`}}", "ssh", "-o", "StrictHostKeyChecking no", "-o", "UserKnownHostsFile /dev/null", "{{user `remote_username`}}@{{user `remote_host`}}", "{{.Command}}"]
},
{
"type": "shell-local",
"command": "mkdir -p output && ovftool --noSSLVerify 'vi://{{user `remote_username`}}:{{user `remote_password`}}@{{user `remote_host`}}/{{user `vm_name`}}' output/{{user `vm_name`}}-{{user `build_number`}}.ova"
},
{
"type": "shell-local",
"command": "vim-cmd vmsvc/power.on `vim-cmd vmsvc/getallvms | grep '\\[{{user `remote_datastore`}}\\] {{user `output_directory`}}/{{user `vm_name`}}.vmx' | cut -d' ' -f 1`",
"execute_command": ["sshpass", "-p", "{{user `remote_password`}}", "ssh", "-o", "StrictHostKeyChecking no", "-o", "UserKnownHostsFile /dev/null", "{{user `remote_username`}}@{{user `remote_host`}}", "{{.Command}}"]
}
The unfortunate-looking power off and power on are both required - OVFTool requires a powered-off VM, and Packer (even though it checks the power state first) will fail if the VM is not powered on as expected.