VMWare Fusion Deployment Issue w/OVA format

When trying to deploy a FCOS cluster locally on my Mac using VMWareFusion (11.5.1) I am encountering an issue with the OVA package format.

The error returned is the same whether I try to Import the OVA package via the UI or whether I try simply to introspect the package using VMWare’s command line utility ovftool that comes bundled with VMWare Fusion: “Did not find an .ovf file at the beginning of the OVA package”.

Most easily reproduced with:
ovftool fedora-coreos-31.20200118.3.0-vmware.x86_64.ova

As a workaround I have confirmed that it is possible to export from vSphere into an OVF format, and then use this to create clusters locally by deploying it using the ovftool into VMWareFusion.

It would still be better to address the OVA format issue at its core.


  • I am able to deploy the OVA file to VMWare VSphere (v6.5.0.30000) without issues.
  • ContainerLinux CoreOS OVA tools (even the most recent ones - do not suffer this issue).
1 Like

Same problem with VMware Workstation 15 Pro (build 15.5.1 build-15018445)

I am having this same issue with VMWare Fusion Professional Version 11.5.1 (15018442) using 31.20200127.3.0.ova for Fedora CoreOS.

There is an ovf file in the ova file, but ovftool does not like it. If I extract the ova file and run ovftool in ovf mode, it complains about four things:

  • Line 54: Unsupported virtual hardware device ‘VirtualSCSI’.
    • This can be ignored
  • Line 89: Unsupported element ‘Property’
    • This must be addressed (see below)
  • No manifest file found.
    • This can be ignored, but RH really needs to provide a manifest
  • Wrong file size specified in OVF descriptor for ‘disk.vmdk’ (specified: 8589934592, actual 713167360).
    • This is fixed by changing ovf:size on the vmdk to 713167360

So what is the deal with with the Property error? The ovf has two properties which are marked as required:

  • guestinfo.ignition.config.data
  • guestinfo.ignition.config.data.encoding

In order for ovftool to build, these need to be specified using the --prop switch. However, ovftool messes this up and does not propagate those properties to the resultant vmx file. So if you really needed those to be set on the vmx file, you have to edit the resultant vmx file yourself to add them.

Once I do all this, I can get a valid vmx file that I can use with my packer build.

Compare this to the 1688.5.3.ova for the pre-fedora CoreOS and that ova works just fine. So whatever automated process Fedora is using to generate this ova is not working properly.

1 Like

I think this is probably something we need to look in to. Can one of you file an issue in our issue tracker for this? https://github.com/coreos/fedora-coreos-tracker

The guest info properties are very similar to those that existed on CL and are the means to pass in the ignition file data. So I would expect these to be in the OVF file right? I have found that these are successfully passed into the VM as it is created providing you use the --allowExtraConfig switch on the ovftool. Is there something else wrong with these properties?

I’ll happily do the grunt work of creating the issue in git once I confirm this. I think the net net would be that the one thing wrong with the current ova that MUST be fixed is simply the size?

The guest info properties are very similar to those that existed on CL and are the means to pass in the ignition file data.

Yes, but the difference is the OVF for CL marked properties as optional, FCOS does not. Marking them as required and not supplying them when invoking ovftool causes ovftool to fail with the misleading Unsupported element ‘Property' error.

I think the net net would be that the one thing wrong with the current ova that MUST be fixed is simply the size?

The size is a must fix because the only solution is to hand-edit the OVF. I would say if you don’t mark the ignition props as optional you should document how people who are not using ignition can pass dummy values into those props to satisfy ovftool.

@dans, thanks!


I get the same problem when trying to import with VMware vSphere on a standalone ESXi server (not using vCenter). One cannot use the ovftool to extract the .ovf file from the .ova due to the fact that the .ovf file itself that exists inside of the .ova is named desc.ovf for some reason:

So one is left using a tar file extractor to manually extract the .ovf file from the downloaded .ova file. But when attempting to import the .ovf file into vSphere using the ‘Deploy OVF Template’ option, it also errors out citing the ‘Property’ element. It’s possible to edit the ‘Property’ element out of the file manually, but as I understand it is quite a necessary element if one wishes to ever log in to the system once it is deployed.

One thing that I found out is that the files were packaged incorrectly. There are two files in the latest .ova download; desc.ovf and disk.vmdk. That naming convention apparently causes an issue because I extracted those two files, then used 7zip to create a new .ova (using tar format) which I named desc.ova. I was able to use ovftool on that new .ova file, and it completed the extraction without errors. However, I still run into the exact same issue with line 89 when I try to deploy that new .ovf file.

I could manually remove those elements, but then how do I authenticate? I do not want to use pxe in any way.

Futher update:
Apparently the problem with the Property tag not being supported is due to uploading the OVF directly onto the ESXi server, rather than using a vCenter server to broker it. However, according to VirtualGhetto, there is a workaround: –X:injectOvfEnv. The new ovftool includes an argument that supports the Property tag when uploading the OVF file directly to the ESXi server. It appears that you simply need to include this switch in the ovftool command:

"C:\Program Files (x86)\VMware\VMware OVF Tool\ovftool.exe" ^
    --X:injectOvfEnv  --powerOn  ^
    --prop:ovf:key=guestinfo.ignition.config.data="$PutTheBase64StringofTheIgnitionFileHere." ^
    --prop:ovf:key=guestinfo.ignition.config.data.encoding=base64 ^
C:\Users\username\FedoraCoreOS-VM\fedora-coreos-31.20200127.3.1-vmware.x86_64.ova ^

To replace the Property stanza from the original desc.ovf:

I have followed the example set here:: no luck.
I have also tried to use the –allowExtraConfig switch and had no luck.

Shouldn’t the whole .ova just be repackaged so that it works properly? Is it even ready for release?

This PR should fix most of this.

@eightup, could you try a quick test?

  1. Untar the OVA.
  2. Edit desc.ovf, adding an attribute ovf:required="false" to each of the <Property> elements.
  3. Create a new OVA from desc.ovf and disk.vmdk, e.g. with tar cf test.ova --format=ustar desc.ovf disk.vmdk.
  4. Try deploying that OVA directly to an ESXi node (not through vCenter).

If that fixes the “Unsupported element” error, we could make that change to our OVF. I’m not sure whether we should, though. While it’s technically possible to launch Fedora CoreOS on VMware without providing an Ignition config, it’s not very useful, since there’d be no way to log into the machine afterward. (Without further hacks, anyway, such as modifying the .vmx file or booting with init=/bin/sh.)