OVF Import Fixes

From Cramsession
Revision as of 17:57, 2 May 2026 by Mflavell (talk | contribs) (Created page with " My stuff Gems Chats OVF Deployment Error: Unsupported ExtraConfig Importing OVA Files via OVF Tool Python Script For Session Extension Agentic AI Services STIG Status RBAC vs ABAC: Access Control Explained Understanding GraphQL: Concepts and Comparison Ubuntu NTP Time Synchronization Guide Professionalizing Security Input Validation Linux Folder Search Commands Offline Python Dependency Installation Guide Fix Python 3.12 Dependency Errors Write some powershell that can...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigationJump to search
✍️ Verified Author: Mflavell • Click to view professional profile & credentials

My stuff Gems Chats OVF Deployment Error: Unsupported ExtraConfig Importing OVA Files via OVF Tool Python Script For Session Extension Agentic AI Services STIG Status RBAC vs ABAC: Access Control Explained Understanding GraphQL: Concepts and Comparison Ubuntu NTP Time Synchronization Guide Professionalizing Security Input Validation Linux Folder Search Commands Offline Python Dependency Installation Guide Fix Python 3.12 Dependency Errors Write some powershell that can run this command after prompting the user in a GUI for the ip address and username: ssh -F /dev/null -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no username@ipaddress -D 9999 Pip3 Proxy Configuration Methods Fixing `bash\r`: No Such File Error

Settings & help Conversation with Gemini Got this problem again trying to deploy a OVF to vSphere: 


./ovftool --noSSLVerify --name="SSPI" \

--datastore="nfs" \

--network=" pg-01" \

/root/Security-Services-Platform-Installer-for-vDefend-5.2.0.0.0.25400625.ova \

'vi://administrator%40vsphere.local:VMware1VMware!@vc.test/dc-01/esx-2.test/cluster-01'

Opening OVA source: /root/Security-Services-Platform-Installer-for-vDefend-5.2.0.0.0.25400625.ova

The manifest validates

Source is signed but could not verify certificate (possibly self-signed)

Certificate information: 

 CertIssuer:/C=US/ST=California/L=Palo Alto/O=VMware, Inc.

 CertSubject:/C=US/ST=California/L=Palo Alto/O=VMware, Inc.

 -----BEGIN CERTIFICATE-----

 MIIDyzCCArOgAwIBAgIJAIR/y018RgMXMA0GCSqGSIb3DQEBCwUAME0xCzAJBgNV

 BAYTAlVTMRMwEQYDVQQIDApDYWxpZm9ybmlhMRIwEAYDVQQHDAlQYWxvIEFsdG8x

 FTATBgNVBAoMDFZNd2FyZSwgSW5jLjAeFw0xNjA5MDgwMTE3MjFaFw0yOTEyMzEw

 MTE3MjFaME0xCzAJBgNVBAYTAlVTMRMwEQYDVQQIDApDYWxpZm9ybmlhMRIwEAYD

 VQQHDAlQYWxvIEFsdG8xFTATBgNVBAoMDFZNd2FyZSwgSW5jLjCCASAwDQYJKoZI

 hvcNAQEBBQADggENADCCAQgCggEBALU9NUtC39fqG7yo2XAswUmtli9uA+31uAMw

 9FFHAEv/it8pzBQZ/4r+2bN+GnXOWhuDd1K4ApKMRvoO4LwQfZxrkx4pXrsu0gdb

 4OunHw0D8MrdzSoob8Js/uq+IJ+8Bhsc6b7RzTUt9HeDWzHasAJVgMsjehGt23ay

 9FKOT6dVD6D/Xi3qJnB/4t/XNS6L63dC3ea4guzKDyLaXIP5bf/m56jvVImFjhhT

 W2ASbnEUlZIVrEuyVcdG7e3FvZufE553JmHL0YG/0m5bIHXKRzBRx0D3HHOAzOKw

 kkOnxJHSTN4Hz8hSYCWvzUAjSYL3Q8qiTd7GHJ2ynsRnu3KlzKUCAQOjga8wgaww

 HQYDVR0OBBYEFHg8KQJdm8NPQDmYP41uEgKG+VNwMH0GA1UdIwR2MHSAFHg8KQJd

 m8NPQDmYP41uEgKG+VNwoVGkTzBNMQswCQYDVQQGEwJVUzETMBEGA1UECAwKQ2Fs

 aWZvcm5pYTESMBAGA1UEBwwJUGFsbyBBbHRvMRUwEwYDVQQKDAxWTXdhcmUsIElu

 Yy6CCQCEf8tNfEYDFzAMBgNVHRMEBTADAQH/MA0GCSqGSIb3DQEBCwUAA4IBAQAD

 K9uUhsXzpuUcWJq83Vh2HHSxZ/DdR6h+FNYHfEX8h8DOIwhRHhIHoqXkwwnpbjip

 FBtSzNKzTmzMQBwB7GwzGSsBO2TU8alX2ssnDg2AqwgIeLzclfaQlYoid678Krew

 nFryr9PYMntr7uyU1duesmey12GS2z5UIhA4BaOnrPJcLCP22nXVlPEsa46ob7XH

 j4ngZ0ck/qE58Z90GaAuxaa2R3OlHQ+AhXc3q5IixqMDa0MLPd41Qv2kC5iZ+tCf

 XVdlf4/RqQBNHR8FFVxcjpaROId9Y9/yHdsMt55nN7pf7vRf5vSk1bHvLmlOYgiR

 tAj6rdPq0c+/C+fct1cM

 -----END CERTIFICATE-----



Error: OVF Package is not supported by target: 

- Line -1: Unsupported value 'ethernet0.rxDataRingEnabled' for attribute 'key' on element 'ExtraConfig'.

- Line -1: Unsupported value 'ethernet1.rxDataRingEnabled' for attribute 'key' on element 'ExtraConfig'.

- Line -1: Unsupported value 'ethernet2.rxDataRingEnabled' for attribute 'key' on element 'ExtraConfig'.

- Line -1: Unsupported value 'ethernet3.rxDataRingEnabled' for attribute 'key' on element 'ExtraConfig'.

- Line -1: Unsupported value 'isolation.tools.diskWiper.disable' for attribute 'key' on element 'ExtraConfig'.

- Line -1: Unsupported value 'isolation.tools.memSchedFakeSampleStats.disable' for attribute 'key' on element 'ExtraConfig'.

- Line -1: Unsupported value 'isolation.tools.diskShrink.disable' for attribute 'key' on element 'ExtraConfig'.

- Line -1: Unsupported value 'isolation.tools.vmxDnDVersionGet.disable' for attribute 'key' on element 'ExtraConfig'.

- Line -1: Unsupported value 'isolation.tools.unityActive.disable' for attribute 'key' on element 'ExtraConfig'.

- Line -1: Unsupported value 'isolation.tools.guestDnDVersionSet.disable' for attribute 'key' on element 'ExtraConfig'.

- Line -1: Unsupported value 'snapshot.maxSnapshots' for attribute 'key' on element 'ExtraConfig'.

- Line -1: Unsupported value 'RemoteDisplay.maxConnections' for attribute 'key' on element 'ExtraConfig'.

Completed with errors

root@vc [ ~/ovftool ]#

This error is a classic case of vCenter strictness. The OVA you are trying to deploy contains ExtraConfig parameters (advanced VMX settings) that your target vCenter or ESXi host doesn't recognize or doesn't allow via the OVF import process.

The "Line -1" error is often a red herring; it just means the ovftool parser hit these unsupported keys within the XML structure of the .ovf file inside your .ova package.

Here is how to fix this:

Option 1: Use the --allowExtraConfig Flag The easiest way to bypass this without modifying the file is to tell ovftool to ignore the fact that it doesn't recognize these specific configuration keys.

Add --allowExtraConfig to your command:

Bash ./ovftool --noSSLVerify --allowExtraConfig --name="SSPI" \ --datastore="nfs" \ --network=" pg-01" \ /root/Security-Services-Platform-Installer-for-vDefend-5.2.0.0.0.25400625.ova \ 'vi://administrator%40vsphere.local:VMware1VMware!@vc.test/dc-01/esx-2.test/cluster-01' Option 2: Extract and Manually Edit the OVF If the flag doesn't work (which happens if the target ESXi version strictly forbids those specific hardware keys), you’ll need to strip them out manually.

Unpack the OVA: The OVA is just a tar archive.

Bash tar -xvf Security-Services-Platform-Installer-for-vDefend-5.2.0.0.0.25400625.ova Edit the .ovf file: Open the resulting .ovf file in a text editor (like vi or nano). Search for the ExtraConfig section. It will look something like this:

XML <vmw:ExtraConfig vmw:key="ethernet0.rxDataRingEnabled" vmw:value="false"/> Delete all the lines corresponding to the errors you received (e.g., rxDataRingEnabled, isolation.tools.*, etc.).

Handle the Manifest (.mf): Because you edited the .ovf file, the checksum in the .mf file will no longer match. You have two choices:

Delete the .mf file entirely.

Deploy the .ovf directly using ovftool (pointing to the .ovf file instead of the .ova) and add the --skipManifestCheck flag.

Why is this happening? Version Mismatch: The OVA was likely built on a newer version of Workstation or ESXi than the one you are deploying to.

Security Hardening: The isolation.tools settings are hardening parameters. Some vCenter versions treat these as "restricted" and won't let an OVF import inject them into the VMX file for security reasons.

Pro-tip: If you find yourself doing this often for vDefend or NSX-related appliances, Option 1 is almost always the winner. It allows the tool to pass the "extra" info to the host and let the host decide whether to use it or ignore it, rather than failing the whole deployment.

/ovftool --noSSLVerify --allowExtraConfig --name="SSPI" \

--datastore="nfs" \

--network=" pg-01" \

/root/Security-Services-Platform-Installer-for-vDefend-5.2.0.0.0.25400625.ova \

'vi://administrator%40vsphere.local:VMware1VMware!@vc.test/dc-01/esx-2.test/cluster-01'

Opening OVA source: /root/Security-Services-Platform-Installer-for-vDefend-5.2.0.0.0.25400625.ova

The manifest validates

Source is signed but could not verify certificate (possibly self-signed)

Certificate information: 

 CertIssuer:/C=US/ST=California/L=Palo Alto/O=VMware, Inc.

 CertSubject:/C=US/ST=California/L=Palo Alto/O=VMware, Inc.

 -----BEGIN CERTIFICATE-----

 MIIDyzCCArOgAwIBAgIJAIR/y018RgMXMA0GCSqGSIb3DQEBCwUAME0xCzAJBgNV

 BAYTAlVTMRMwEQYDVQQIDApDYWxpZm9ybmlhMRIwEAYDVQQHDAlQYWxvIEFsdG8x

 FTATBgNVBAoMDFZNd2FyZSwgSW5jLjAeFw0xNjA5MDgwMTE3MjFaFw0yOTEyMzEw

 MTE3MjFaME0xCzAJBgNVBAYTAlVTMRMwEQYDVQQIDApDYWxpZm9ybmlhMRIwEAYD

 VQQHDAlQYWxvIEFsdG8xFTATBgNVBAoMDFZNd2FyZSwgSW5jLjCCASAwDQYJKoZI

 hvcNAQEBBQADggENADCCAQgCggEBALU9NUtC39fqG7yo2XAswUmtli9uA+31uAMw

 9FFHAEv/it8pzBQZ/4r+2bN+GnXOWhuDd1K4ApKMRvoO4LwQfZxrkx4pXrsu0gdb

 4OunHw0D8MrdzSoob8Js/uq+IJ+8Bhsc6b7RzTUt9HeDWzHasAJVgMsjehGt23ay

 9FKOT6dVD6D/Xi3qJnB/4t/XNS6L63dC3ea4guzKDyLaXIP5bf/m56jvVImFjhhT

 W2ASbnEUlZIVrEuyVcdG7e3FvZufE553JmHL0YG/0m5bIHXKRzBRx0D3HHOAzOKw

 kkOnxJHSTN4Hz8hSYCWvzUAjSYL3Q8qiTd7GHJ2ynsRnu3KlzKUCAQOjga8wgaww

 HQYDVR0OBBYEFHg8KQJdm8NPQDmYP41uEgKG+VNwMH0GA1UdIwR2MHSAFHg8KQJd

 m8NPQDmYP41uEgKG+VNwoVGkTzBNMQswCQYDVQQGEwJVUzETMBEGA1UECAwKQ2Fs

 aWZvcm5pYTESMBAGA1UEBwwJUGFsbyBBbHRvMRUwEwYDVQQKDAxWTXdhcmUsIElu

 Yy6CCQCEf8tNfEYDFzAMBgNVHRMEBTADAQH/MA0GCSqGSIb3DQEBCwUAA4IBAQAD

 K9uUhsXzpuUcWJq83Vh2HHSxZ/DdR6h+FNYHfEX8h8DOIwhRHhIHoqXkwwnpbjip

 FBtSzNKzTmzMQBwB7GwzGSsBO2TU8alX2ssnDg2AqwgIeLzclfaQlYoid678Krew

 nFryr9PYMntr7uyU1duesmey12GS2z5UIhA4BaOnrPJcLCP22nXVlPEsa46ob7XH

 j4ngZ0ck/qE58Z90GaAuxaa2R3OlHQ+AhXc3q5IixqMDa0MLPd41Qv2kC5iZ+tCf

 XVdlf4/RqQBNHR8FFVxcjpaROId9Y9/yHdsMt55nN7pf7vRf5vSk1bHvLmlOYgiR

 tAj6rdPq0c+/C+fct1cM

 -----END CERTIFICATE-----



Error: Locator does not refer to an object: vi://administrator%40vsphere.local@vc.test:443/dc-01/esx-2.test/cluster-01

Completed with errors

It looks like you've moved past the OVF parsing error and hit a pathing/locator error. Even though your syntax looks mostly correct, ovftool is very picky about the hierarchical path when you are targeting a cluster.

The error Locator does not refer to an object means ovftool can't find a valid ESXi host or Cluster object at the end of that string.

The Fix: Check your VI Path Usually, this happens because the path structure in your environment doesn't match the command. In vSphere, a Cluster is logically "inside" a Host Folder or directly under the Datacenter, but an ESXi host is usually "inside" the cluster.

Try these three variations based on how your vCenter is actually organized:

1. The "Standard Cluster" Path (Most Likely) If cluster-01 is the name of your cluster, you usually don't include the ESXi host name in the path if you want vCenter to decide which host to put it on.

Bash 'vi://administrator%40vsphere.local:VMware1VMware!@vc.test/dc-01/host/cluster-01' Note the addition of /host/ — vCenter internally maps clusters under a hidden or visible "host" managed object folder.

2. The "Resource Pool" Path If you are deploying into a cluster, it technically has a "Resources" root.

Bash 'vi://administrator%40vsphere.local:VMware1VMware!@vc.test/dc-01/host/cluster-01/Resources' 3. Targeting the Specific Host Directly If you really want it on esx-2.test and that host is not in a cluster:

Bash 'vi://administrator%40vsphere.local:VMware1VMware!@vc.test/dc-01/host/esx-2.test' How to verify the exact path If the above don't work, you can "browse" your vCenter using ovftool to see exactly what names it expects. Run this command (it will just list the objects):

Bash ./ovftool 'vi://administrator%40vsphere.local:VMware1VMware!@vc.test/dc-01/' This will output the contents of dc-01. You might see a folder named host or vm. Keep appending the names you see to your URL until you reach your intended destination.

One small syntax check In your previous command, you had: --network=" pg-01"

Check if that leading space inside the quotes was intentional. If your port group is actually named "pg-01" (no space), remove that extra space, as it can occasionally cause the deployment to fail later in the process.

Which folder structure did you see when you ran the "browse" command?

root@vc [ ~/ovftool ]# ./ovftool --noSSLVerify --name="SSPI" \

--datastore="nfs" \

--network="pg-01" \

/root/Security-Services-Platform-Installer-for-vDefend-5.2.0.0.0.25400625.ova \

'vi://administrator%40vsphere.local:VMware1VMware!@vc.test/dc-01/host/cluster-01'

Opening OVA source: /root/Security-Services-Platform-Installer-for-vDefend-5.2.0.0.0.25400625.ova

The manifest validates

Source is signed but could not verify certificate (possibly self-signed)

Certificate information: 

 CertIssuer:/C=US/ST=California/L=Palo Alto/O=VMware, Inc.

 CertSubject:/C=US/ST=California/L=Palo Alto/O=VMware, Inc.

 -----BEGIN CERTIFICATE-----

 MIIDyzCCArOgAwIBAgIJAIR/y018RgMXMA0GCSqGSIb3DQEBCwUAME0xCzAJBgNV

 BAYTAlVTMRMwEQYDVQQIDApDYWxpZm9ybmlhMRIwEAYDVQQHDAlQYWxvIEFsdG8x

 FTATBgNVBAoMDFZNd2FyZSwgSW5jLjAeFw0xNjA5MDgwMTE3MjFaFw0yOTEyMzEw

 MTE3MjFaME0xCzAJBgNVBAYTAlVTMRMwEQYDVQQIDApDYWxpZm9ybmlhMRIwEAYD

 VQQHDAlQYWxvIEFsdG8xFTATBgNVBAoMDFZNd2FyZSwgSW5jLjCCASAwDQYJKoZI

 hvcNAQEBBQADggENADCCAQgCggEBALU9NUtC39fqG7yo2XAswUmtli9uA+31uAMw

 9FFHAEv/it8pzBQZ/4r+2bN+GnXOWhuDd1K4ApKMRvoO4LwQfZxrkx4pXrsu0gdb

 4OunHw0D8MrdzSoob8Js/uq+IJ+8Bhsc6b7RzTUt9HeDWzHasAJVgMsjehGt23ay

 9FKOT6dVD6D/Xi3qJnB/4t/XNS6L63dC3ea4guzKDyLaXIP5bf/m56jvVImFjhhT

 W2ASbnEUlZIVrEuyVcdG7e3FvZufE553JmHL0YG/0m5bIHXKRzBRx0D3HHOAzOKw

 kkOnxJHSTN4Hz8hSYCWvzUAjSYL3Q8qiTd7GHJ2ynsRnu3KlzKUCAQOjga8wgaww

 HQYDVR0OBBYEFHg8KQJdm8NPQDmYP41uEgKG+VNwMH0GA1UdIwR2MHSAFHg8KQJd

 m8NPQDmYP41uEgKG+VNwoVGkTzBNMQswCQYDVQQGEwJVUzETMBEGA1UECAwKQ2Fs

 aWZvcm5pYTESMBAGA1UEBwwJUGFsbyBBbHRvMRUwEwYDVQQKDAxWTXdhcmUsIElu

 Yy6CCQCEf8tNfEYDFzAMBgNVHRMEBTADAQH/MA0GCSqGSIb3DQEBCwUAA4IBAQAD

 K9uUhsXzpuUcWJq83Vh2HHSxZ/DdR6h+FNYHfEX8h8DOIwhRHhIHoqXkwwnpbjip

 FBtSzNKzTmzMQBwB7GwzGSsBO2TU8alX2ssnDg2AqwgIeLzclfaQlYoid678Krew

 nFryr9PYMntr7uyU1duesmey12GS2z5UIhA4BaOnrPJcLCP22nXVlPEsa46ob7XH

 j4ngZ0ck/qE58Z90GaAuxaa2R3OlHQ+AhXc3q5IixqMDa0MLPd41Qv2kC5iZ+tCf

 XVdlf4/RqQBNHR8FFVxcjpaROId9Y9/yHdsMt55nN7pf7vRf5vSk1bHvLmlOYgiR

 tAj6rdPq0c+/C+fct1cM

 -----END CERTIFICATE-----



Error: OVF Package is not supported by target: 

- Line -1: Unsupported value 'ethernet0.rxDataRingEnabled' for attribute 'key' on element 'ExtraConfig'.

- Line -1: Unsupported value 'ethernet1.rxDataRingEnabled' for attribute 'key' on element 'ExtraConfig'.

- Line -1: Unsupported value 'ethernet2.rxDataRingEnabled' for attribute 'key' on element 'ExtraConfig'.

- Line -1: Unsupported value 'ethernet3.rxDataRingEnabled' for attribute 'key' on element 'ExtraConfig'.

- Line -1: Unsupported value 'isolation.tools.diskWiper.disable' for attribute 'key' on element 'ExtraConfig'.

- Line -1: Unsupported value 'isolation.tools.memSchedFakeSampleStats.disable' for attribute 'key' on element 'ExtraConfig'.

- Line -1: Unsupported value 'isolation.tools.diskShrink.disable' for attribute 'key' on element 'ExtraConfig'.

- Line -1: Unsupported value 'isolation.tools.vmxDnDVersionGet.disable' for attribute 'key' on element 'ExtraConfig'.

- Line -1: Unsupported value 'isolation.tools.unityActive.disable' for attribute 'key' on element 'ExtraConfig'.

- Line -1: Unsupported value 'isolation.tools.guestDnDVersionSet.disable' for attribute 'key' on element 'ExtraConfig'.

- Line -1: Unsupported value 'snapshot.maxSnapshots' for attribute 'key' on element 'ExtraConfig'.

- Line -1: Unsupported value 'RemoteDisplay.maxConnections' for attribute 'key' on element 'ExtraConfig'.

Completed with errors

root@vc [ ~/ovftool ]#

It looks like the --allowExtraConfig flag isn't behaving as expected here. While that flag usually allows unknown keys to pass through, some versions of ovftool and vCenter are still remarkably stubborn if they perceive those specific "ExtraConfig" keys as a security risk or a hardware incompatibility.

Since the "soft" bypass (the flag) failed, we have to go with the "surgical" approach: stripping these requirements out of the OVF manually.

Step 1: Unpack the OVA The .ova file is just a tarball. Extract it so you can get to the XML descriptor.

Bash tar -xvf Security-Services-Platform-Installer-for-vDefend-5.2.0.0.0.25400625.ova You will now see a .ovf, a .mf (manifest), and one or more .vmdk files.

Step 2: Strip the "ExtraConfig" lines Open the .ovf file with vi or sed. We want to remove every line that contains ExtraConfig.

The Quick Way (using sed): This command creates a new file called cleaned.ovf with those lines removed.

Bash sed '/ExtraConfig/d' *.ovf > cleaned.ovf The Manual Way (using vi):

vi Security-Services-Platform-Installer-for-vDefend-5.2.0.0.0.25400625.ovf

Search for ExtraConfig.

Delete every line that looks like: <vmw:ExtraConfig vmw:key="..." vmw:value="..."/>.

Save and exit (:wq).

Step 3: Deploy using the OVF (Skipping Manifest) Because you modified the .ovf file, the checksum stored in the .mf file is now "invalid." Instead of trying to recalculate the SHA hash, we will just tell ovftool to ignore the manifest check.

Run this command: (Note: We point to the .ovf file now, not the .ova, and we use --skipManifestCheck)

Bash ./ovftool --noSSLVerify --skipManifestCheck --name="SSPI" \ --datastore="nfs" \ --network="pg-01" \ cleaned.ovf \ 'vi://administrator%40vsphere.local:VMware1VMware!@vc.test/dc-01/host/cluster-01' Why this is the "Nuclear Option" By removing these lines, you are essentially telling vCenter: "Ignore the hardware optimizations (rxDataRing) and security hardening (isolation.tools) the developer requested; just give me a standard VM." For an installer/appliance like vDefend, this is perfectly fine for getting it booted. Once it's running, the appliance's internal logic usually takes over anyway.

One final check: Ensure that pg-01 exists exactly as written (no spaces) on that cluster, as ovftool will error out immediately if the network mapping fails after the OVF is parsed.

Does the cleaned.ovf get you past the "Unsupported value" errors?

Thank works, can you turn it into a smple one-pager, seems to happen a lot

Your PDF troubleshooting guide is ready. PDF icon 

ovftool_de...oyment_fix

PDF

This one-pager covers the three-step "Surgical Fix" (Extract, Sed, and Deploy) and includes the correct syntax for the vCenter locator path, which was the second hurdle you encountered. Keep this on hand for future vDefend or NSX appliance deployments, as they frequently include these non-standard VMX parameters.

Please turn it into mediawiki format

Your MediaWiki formatted guide is ready. TXT icon 

ovftool_fi..._mediawiki

TXT

MediaWiki Source Code You can also copy and paste the source directly from here:

Code snippet

Troubleshooting: vSphere ovftool Deployment Errors

This guide addresses common "Unsupported value" errors during OVF/OVA deployment to vCenter, typically caused by ExtraConfig parameters that are incompatible with the target host or security policies.

1. The Common Error

Typically occurs when the OVA contains advanced VMX settings (like rxDataRingEnabled or isolation.tools) that the target vCenter/ESXi version does not recognize. 

Error: OVF Package is not supported by target:
 - Line -1: Unsupported value 'ethernet0.rxDataRingEnabled' for attribute 'key' on element 'ExtraConfig'.
 - Line -1: Unsupported value 'isolation.tools.*' ...

2. Solution: The Extraction & Clean Method

If the --allowExtraConfig flag fails, follow these steps to manually strip the problematic keys from the OVF descriptor.

Step 1: Unpack the OVA

The OVA file is a tar archive. Extract it to access the XML (.ovf) file. <source lang="bash"> tar -xvf your-appliance.ova </source>

Step 2: Strip ExtraConfig Lines

Use sed to remove all lines containing "ExtraConfig". <source lang="bash"> sed '/ExtraConfig/d' *.ovf > cleaned.ovf </source>

Step 3: Deploy via Cleaned OVF

Point ovftool to the new cleaned.ovf file. You must use the --skipManifestCheck flag because the OVF checksum has changed. <source lang="bash"> ./ovftool --noSSLVerify --skipManifestCheck \ --name="MY_VM_NAME" \ --datastore="MY_DATASTORE" \ --network="MY_NETWORK" \ cleaned.ovf \ 'vi://administrator%40vsphere.local:PASSWORD@vcenter-fqdn/DATACENTER/host/CLUSTER_NAME' </source>

3. Common Pathing (Locator) Fixes

If you receive the error Locator does not refer to an object, the path in your vi:// URL is likely incorrect. vCenter requires a specific hierarchy:

  • Targeting a Cluster: vi://.../DATACENTER/host/CLUSTER_NAME
  • Targeting a Resource Pool: vi://.../DATACENTER/host/CLUSTER_NAME/Resources/POOL_NAME
  • Targeting a Specific Host: vi://.../DATACENTER/host/ESXI_HOSTNAME

4. Notes

  • ExtraConfig: Removing these lines deletes hardware optimizations and security hardening. For most appliances, this is non-critical for initial deployment and boot.
  • Special Characters: Ensure the username (e.g., administrator@vsphere.local) is URL encoded (administrator%40vsphere.local).



Your Broadcom Inc. chats aren’t used to improve our models. Gemini is AI and can make mistakes. Your privacy & GeminiOpens in a new window

Troubleshooting: vSphere ovftool Deployment Errors

This guide addresses common "Unsupported value" errors during OVF/OVA deployment to vCenter, typically caused by ExtraConfig parameters that are incompatible with the target host or security policies.

1. The Common Error

Typically occurs when the OVA contains advanced VMX settings (like rxDataRingEnabled or isolation.tools) that the target vCenter/ESXi version does not recognize. 

Error: OVF Package is not supported by target:
 - Line -1: Unsupported value 'ethernet0.rxDataRingEnabled' for attribute 'key' on element 'ExtraConfig'.
 - Line -1: Unsupported value 'isolation.tools.*' ...

2. Solution: The Extraction & Clean Method

If the --allowExtraConfig flag fails, follow these steps to manually strip the problematic keys from the OVF descriptor.

Step 1: Unpack the OVA

The OVA file is a tar archive. Extract it to access the XML (.ovf) file. <source lang="bash"> tar -xvf your-appliance.ova </source>

Step 2: Strip ExtraConfig Lines

Use sed to remove all lines containing "ExtraConfig". <source lang="bash"> sed '/ExtraConfig/d' *.ovf > cleaned.ovf </source>

Step 3: Deploy via Cleaned OVF

Point ovftool to the new cleaned.ovf file. You must use the --skipManifestCheck flag because the OVF checksum has changed. <source lang="bash"> ./ovftool --noSSLVerify --skipManifestCheck --name="MY_VM_NAME" --datastore="MY_DATASTORE" --network="MY_NETWORK" cleaned.ovf 'vi://administrator%40vsphere.local:PASSWORD@vcenter-fqdn/DATACENTER/host/CLUSTER_NAME' </source>

3. Common Pathing (Locator) Fixes

If you receive the error Locator does not refer to an object, the path in your vi:// URL is likely incorrect. vCenter requires a specific hierarchy:

  • Targeting a Cluster: vi://.../DATACENTER/host/CLUSTER_NAME
  • Targeting a Resource Pool: vi://.../DATACENTER/host/CLUSTER_NAME/Resources/POOL_NAME
  • Targeting a Specific Host: vi://.../DATACENTER/host/ESXI_HOSTNAME

4. Notes

  • ExtraConfig: Removing these lines deletes hardware optimizations and security hardening. For most appliances, this is non-critical for initial deployment and boot.
  • Special Characters: Ensure the username (e.g., administrator@vsphere.local) is URL encoded (administrator%40vsphere.local).
Retrieved from "https://cramsession.net/index.php?title=OVF_Import_Fixes&oldid=1440"