VMWare Fusion Deployment Issue w/OVA format

Did you try using the namespace for the required attribute?

<ProductSection ovf:required="false">

@eightup the base64 string property is meant to be the encoded ignition file produced by the fcct transpiler. Ideally this injects all aspects of a machine’s configuration in one shot with no subsequent need to install anything locally; and as such creating disposable servers that suit a strict purpose. As such we find it a very useful property when creating docker swarms.

Certainly it is possible to use the ovftool on MacOS to deploy to VMWareFusion locally using this property. For us it looks something like this:

ovftool \
	--powerOffTarget \
	--overwrite \
	--name=${MACHINE} \
	--acceptAllEulas \
	--memorySize:'*'=${MEM_SIZE} \
	--numberOfCpus:'*'=${VCPUS} \
	--allowExtraConfig \
    --extraConfig:guestinfo.ignition.config.data.encoding="base64" \
	--extraConfig:guestinfo.ignition.config.data="${EXTRA_CONFIG}" \
	${FCOS_OVA} \
	~/Virtual\ Machines.localized

Incidentally we have also successfully used powershell from Mac using VMWare’s PowerCLI tooling. However, this has required a slightly different property key. It is possible you are coming across a property key issue like this when deploying to vSphere directly using ovftool.

Our pre-processed powershell (with some bash expansions) looks something like this. The bit I want to highlight is the suffix _1 in the guestinfo properties that we found we needed to use.

...
$ovfPath = "${FCOS_OVA}"
$ovfConfig = Get-OvfConfiguration -Ovf $ovfPath
...
$ovfConfig.Common.guestinfo.ignition.config.data.encoding.value = "base64"
# The _1 suffix only gained through detailed introspection and only
# applicable on VSphere.
$ovfConfig.Common.guestinfo.ignition.config.data_1.value= ${EXTRA_CONFIG}

$vmhost = (Get-Cluster | Get-VMHost | Get-Random)

$resource = Get-ResourcePool -Name "${VI_SERVER_RESOURCE_POOL}"

Write-host "Import-VApp \
			-Source \$ovfPath \
			-OvfConfiguration \$ovfConfig \
			-VMHost \$vmhost \
			-Location \$resource \
			-Datastore ${VI_STORAGE} \
			-DiskStorageFormat ${VI_STORAGE_TYPE} \
			-Name '${MACHINE}' "

Hopefully this may help.

FYI I’ve been gathering some notes in order to later improve docs on how to provision nodes on VMware at user-guides: add platform docs for vmware · Issue #50 · coreos/fedora-coreos-docs · GitHub.

@dans

I modified the exisiting Property tags to contain that value:

@ mp3689

Using the ovftool sounds like the way to go. I haven’t yet tried VMware’s Power CLI, but I shall attempt that.
Regardless, that still renders the ovf’s Property tags useless. When the base64 string is getting injected into the file, then the Property tags are getting overwritten at that time; So there is no use to having empty Property tags pre-populated in the ovf file.

I modified the exisiting Property tags to contain that value

As you can see from my original response, I put the optional tag in the ProductSection and it worked for me. I was able to build using the OVF without having to supply the ignition properties.

@ dans

So you had to modify the ovf file for it to work for you: same as me. It would be nice not to have to modify the ovf file at all; that is my only argument.

So you had to modify the ovf file for it to work for you: same as me. It would be nice not to have to modify the ovf file at all; that is my only argument.

With respect to the properties, I actually supplied dummy values to satisfy the requirements. However, given the disk size is wrong, I had to edit the OVF anyways to get the correct size.

That’s the goal. @eightup, could you confirm that this change works for you?

@ bgilbert
I can only confirm that the Property tags had to be removed altogether. If the Property tags exist at all in the ovf file, then it errors out.

@eightup Okay, so to be clear, you’ve tried setting ovf:required="false" in the ProductSection element and you’re still getting the error?

In that case, there’s not much we can do. We can’t drop the properties entirely, because that would make it too hard to pass an Ignition config in environments that do properly support Properties. We could document a workaround like injectOvfEnv if that works. At a minimum, we can document that deploying directly to an ESX host is not supported.

Yes.

Does the Properites element have to pre-exist in the file in order to pass more Properties tags? Are you saying that it’s not possible to create the Properties element by passing additional tags?
Because if you are able to create the Properties element on the fly just by passing additional tags, then it seems it would actually be more generally utile to just leave the Property element out altogether.
Otherwise, if it’s not trivial to create a Properties element, then I agree it wold be far easier to just not support ESXi directly, and just add that note to the documentation.

Okay, thanks for testing. The Property elements cause the hypervisor UI (at least in vCenter and Workstation) to prompt the user for the Ignition config and encoding. That’s a much better experience than manually modifying VMX files, so we want to retain it where possible.

It looks like the size issue has been fixed in 31.20200210.3.0. Thank you for that!

Here are my updated instructions:

  1. Download Fedora CoreOS ova
  2. Extract ova
    • tar xvzf 31.20200210.3.0.ova -C extracted
  3. Edit the extracted ovf file
    • Set the properties to optional by adding ovf:required="false" to the ProductSection
  4. Turn it back into an ova
    • ovftool --lax --sourceType=OVF --targetType=OVA extracted/coreos.ovf 31.20200210.3.0-fixed.ova

So for me, adding that ovf:required="false" property to the ovf will fix everything.

1 Like

@dans, thanks for the update. Let me check that I understand things correctly:

You’re not importing the OVA using the VMware Fusion GUI, but are instead passing it to Fusion’s ovftool. If you set the Ignition properties using ovftool’s --prop flag, ovftool runs successfully but doesn’t propagate the values to the VMX. If you don’t pass --prop, it fails.

You’d like the ProductSection to be marked non-required, which still requires you to hand-edit the VMX but avoids having to pass dummy --prop options to ovftool.

Is that correct?

Very happy to see that the latest stable release (fedora-coreos-31.20200210.3.0-vmware.x86_64.ova) has no size issues and that one can deploy using ovftool to VMWareFusion, and with PowerCLI to vSphere without issues.

I did note that the property names when deploying via PowerCLI flipped with the latest fix such that I had to use the following property keys:

Connect-VIServer -Protocol https -Server <vSphereServer> -User <user>  -Password <password>
$ovfPath = "../bin/fedora-coreos-31.20200210.3.0-vmware.x86_64.ova"
$ovfConfig = Get-OvfConfiguration -Ovf $ovfPath
$ovfConfig.Common.guestinfo.ignition.config.data.encoding.value = "base64"
$ovfConfig.Common.guestinfo.ignition.config.data.value=<base64EncodedIgnitionFile>
...
Import-VApp -Source $ovfPath -OvfConfiguration $ovfConfig                          -VMHost $vmhost -Location $resource -DiskStorageFormat thin                                 -Name <vmName>

@fifofonix Those look like the expected property names to me.

It seems I may have misspoke. Retrying the procedure by supplying the values does not work. I tried by specifying:

–prop:guestinfo.ignition.config.data=base64 data
–prop:guestinfo.ignition.configdata.encoding=base64

That didn’t work. I then tried:

–allowExtraConfig
–extraConfig:guestinfo.ignition.config.data=base64 data
–extraConfig:guestinfo.ignition.config.data.encoding=base64

That didn’t work either. Finally I tried:

–allowAllExtraConfig
–extraConfig:guestinfo.ignition.config.data=base64 data
–extraConfig:guestinfo.ignition.config.data.encoding=base64

That didn’t work. Each time I got Line 89: Unsupported element 'Property'. This is using the VMware ovftool 4.1.0 (build-3634792) against the 31.20200210.3.0.ova on macOS Catalina 10.15.3.

The only thing that works is adding ovf:required="false" to ProductSection.

@dans in case it helps here is the full list of command line options that I have working with ovftool 4.3.0 (build-13981069) (which I know is a couple of clicks North of your version) on Mojave 10.14.6 using fedora-coreos-31.20200210.3.0-vmware.x86_64.ova

	ovftool \
		--powerOffTarget \
		--overwrite \
		--name=${MACHINE} \
		--acceptAllEulas \
		--memorySize:'*'=${MEM_SIZE} \
		--numberOfCpus:'*'=${VCPUS} \
		--allowExtraConfig \
		--extraConfig:guestinfo.hostname="${MACHINE}" \
		--extraConfig:guestinfo.ignition.config.data.encoding="base64" \
		--extraConfig:guestinfo.ignition.config.data="${EXTRA_CONFIG}" \
		${DEPLOYMENT_OVA} \
		~/Virtual\ Machines.localized

Thanks @fifofonix. I was using the ovftool that came with the latest copy of VMware Fusion. I didn’t realize that there was a newer version.

After upgrading to the latest ovftool (VMware ovftool 4.3.0 (build-7948156)), the config errors went away. However, the new ovftool seems to dislike the VirtualSCSI device. If I rename VirtualSCSI to lsilogic, it works (as specified here). However, at this time I don’t know the ramifications of making such a change.