Packer: vmware-iso not exporting VM (at all)

[aptituz]

Hi,

I'm trying to generate an OVF with the vmware-iso builder, by having the format parameter set to 'ovf' (which should also be the default). The problem is, that the export steps does not seem to be called, there is no "Exporting the machine .. " message or alike. From the builds last log lines:

2016/03/10 00:51:32 ui: ==> vmware-iso: Cleaning VMX prior to finishing up...
==> vmware-iso: Cleaning VMX prior to finishing up...
2016/03/10 00:51:32 ui:     vmware-iso: Unmounting floppy from VMX...
2016/03/10 00:51:32 packer: 2016/03/10 00:51:32 Deleting key: floppy0.present
    vmware-iso: Unmounting floppy from VMX...
2016/03/10 00:51:32 ui:     vmware-iso: Detaching ISO from CD-ROM device...
    vmware-iso: Detaching ISO from CD-ROM device...
2016/03/10 00:51:32 ui:     vmware-iso: Disabling VNC server...
    vmware-iso: Disabling VNC server...
2016/03/10 00:51:32 packer: 2016/03/10 00:51:32 Writing VMX to: output-vmware-iso/centos7.vmx
2016/03/10 00:51:32 packer: 2016/03/10 00:51:32 Executing: /Applications/VMware Fusion.app/Contents/Library/vmrun [-T fusion list]
2016/03/10 00:51:32 packer: 2016/03/10 00:51:32 stdout: Total running VMs: 0
2016/03/10 00:51:32 packer: 2016/03/10 00:51:32 stderr:
2016/03/10 00:51:32 ui: Build 'vmware-iso' finished.
2016/03/10 00:51:32 Builds completed. Waiting on interrupt barrier...
2016/03/10 00:51:32 ui: 
==> Builds finished. The artifacts of successful builds are:
2016/03/10 00:51:32 machine readable: vmware-iso,artifact-count []string{"1"}
Build 'vmware-iso' finished.

I'm using 0.9.0 on OSX with VMWare Fusion 7. If needed, I can create the gists etc requested in the bug template, but I think that it's not necessary:

In the source I found the line 38 (https://github.com/mitchellh/packer/blob/master/builder/vmware/iso/step_export.go#L38) which I think is the culprit: I'm not a go programmer but I read it as "if remote type is not esx5 - stop". That way ovftool is never called and therefore no file created.

Best Regards,
Patrick

[jim3ma]

Now step_export just can only export esx vm, we can add other vm support.

[aptituz]

Yeah, you are right. The current test for esx5 is needed, because their is no actual support in generateArgs.

However, I think adding support for generating ovf files directly would be quiet easy. The generateArgs function would only need to return [c.VMName, c.VMname + '.' + s.Format] if RemoteType is not set. The check in line 38 could then be removed.
Or am I am overseeing anything?

[cbednarski]

@aptituz Thanks for opening an issue. The way this feature is implemented it is only intended to work with a remote build on ESXi. If you are configuring format (I have to guess because you did not post your config) please note that this is documented specifically under the remote builds section.

If you are configuring something else can you please indicate that here? Thanks!

[jim3ma]

@aptituz the generateArgs now are parameters about exporting for esxi server, like all remote_* parameters.
If we want to add fusion support, the generateArgs should return local path for the vm created in fusion, then the ovftool will convert it into special format you want.
I think we can do it with graceful solution.

[aptituz]

@cbednarski You don't have to guess about the parameter or not, since I wrote it in my very first sentence of this issue. :) But, indeed, you are right: I missed that this parameter is part of the remote build section.

Okay, so I understand that it's not a bug as I thought but a feature request. Well. :)

[jim3ma]

@aptituz I have tried to use ovftool to convert vmx to ovf or ova. It's okay. If you want to get ovf or ova, you can have a try.

[cbednarski]

You don't have to guess about the parameter or not, since I wrote it in my very first sentence of this issue. :)

@aptituz Oops! Sorry, I missed that. Thanks for pointing that out. :)

I have two thoughts:

• Accepting and silently ignore format for a non-remote build is a bug. We should warn / error that this is not valid.
• It might be better for this feature to be added as a post-processor instead of a builder option. I'm not sure how confusing this might be given the current implementation but I think that is more consistent with respect to how other parts of packer work.

[aptituz]

No problem.

I agree to your first point and don't have any strong opinion about the second. It would just be cool if it made it into the packer codebase, since there are some externally fostered ovf post-processors around left abandoned and therefore not api-compatible anymore.

[jim3ma]

The vsphere post-processor now need to fetch exported vmx, ovf or ova, then upload them to vsphere. Currently, the ovftool is installed on Packer side. If we change the exports of vmware-iso builder, this post-processor maybe need to review.

[dave2]

I think we actually need to separate the ESXi/vSphere paths from the locally-running VMware hypervisors. That, and maybe use govmomi (the actual VMware-provided GO SDK) for vSphere interaction

The main downside to govmomi is direct ESXi allows control of an ESXi server without any VC license, which govmomi doesn't allow (since the API is read-only without a VC license).

[jamesjuran2]

I hit this issue as well trying to generate an OVA file with VMware Fusion -- it simply never attempts to generate the OVA. It would be much nicer if it at least caught this condition early, and if the docs for the vmware-iso builder reflected this reality.

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