Using FileWave OVA appliances with older VMware ESXi versions

FileWave download pages include OVA images for FileWave Server, Booster, and Imaging Virtual Server (IVS) appliances. An OVA is a packaged virtual appliance. It normally contains an OVF descriptor file, one or more virtual disks, and sometimes a manifest file used for checksum validation.

Each FileWave OVA is built with a VMware virtual hardware compatibility level. For example, the FileWave 16.3.0 download page states that the VMware OVA images require vmx-19 support, which means VMware vCenter/ESXi 7.0 Update 2 or newer. If you try to import that OVA on an older ESXi host, the import may fail before the appliance is even created.

Warning: Older VMware ESXi versions may be outside Broadcom support and may contain known security vulnerabilities. Do not treat this process as a recommendation to keep running unsupported ESXi in production. Use this only as a temporary workaround, lab/test option, or migration aid. For production systems, FileWave recommends using a supported hypervisor platform and keeping ESXi patched.

When to use this article

Use this article when all of the following are true:

You downloaded a FileWave OVA appliance from a FileWave Downloads page.
You are trying to import it into VMware ESXi or vCenter.
The import fails because the OVA was created for a newer virtual hardware version than your ESXi host supports.
You understand this is a best-effort compatibility change, not a guaranteed supported production configuration.

This article does not apply to Hyper-V VHD images, already-running appliances, or issues caused by the FileWave software inside the appliance.

What this changes, and what it does not change

This process changes the VMware virtual hardware version declared by the OVA package. That can allow an older ESXi host to accept the import.

It does not magically convert every virtual device inside the appliance. If the OVA uses a device that your ESXi host cannot emulate, such as a newer storage controller or another newer virtual hardware feature, the import or boot may still fail. In that case, the right answer is usually to use a newer ESXi host or create a new compatible VM and migrate/attach the disk with help from a VMware administrator.

Before you start

Confirm your ESXi version. In the ESXi Host Client, select Host and check the ESXi version/build. In vCenter, check both the vCenter version and the ESXi host version. If vCenter manages the host, both vCenter and the ESXi host must support the virtual hardware version you choose.
Download the FileWave OVA again if needed. Start from a clean copy of the OVA from the FileWave Downloads page for your FileWave release.
Verify the download. FileWave download pages list an MD5 value for OVA files. Compare the downloaded file's MD5 value before modifying it.
Work on a copy. Keep the original OVA unchanged so you can start over if needed.
Use a test VM first. Do not try this directly with your only production recovery path.

Optional: check the original OVA MD5 value

On macOS:

md5 FileWave_Server_16.3.0.ova

On Linux:

md5sum FileWave_Server_16.3.0.ova

On Windows PowerShell:

Get-FileHash -Algorithm MD5 .\FileWave_Server_16.3.0.ova

Compare the result to the MD5 shown on the FileWave Downloads page. If it does not match, download the OVA again before continuing.

Choose the correct virtual hardware version

The value you are changing in the OVF file looks like vmx-19, vmx-17, vmx-13, and so on. Choose the newest version your ESXi/vCenter environment supports.

VMware environment	Maximum virtual hardware version	OVF value to use
ESXi / vCenter 6.0	Version 11	`vmx-11`
ESXi / vCenter 6.5	Version 13	`vmx-13`
ESXi / vCenter 6.7	Version 14	`vmx-14`
ESXi / vCenter 6.7 Update 2 or later	Version 15	`vmx-15`
ESXi / vCenter 7.0	Version 17	`vmx-17`
ESXi / vCenter 7.0 Update 1	Version 18	`vmx-18`
ESXi / vCenter 7.0 Update 2 or Update 3	Version 19	`vmx-19`

Example: if a FileWave OVA declares vmx-19 but your host is ESXi 6.0, you would try vmx-11. If your host is ESXi 7.0 Update 3, you should leave or use vmx-19.

Broadcom maintains the official compatibility list here: ESXi hosts and compatible virtual machine hardware versions.

Method 1: try VMware OVF Tool first

VMware OVF Tool is usually the cleaner way to rewrite an OVA for an older virtual hardware version. If you can use OVF Tool, try this method before manually editing the OVA.

Download and install VMware OVF Tool from Broadcom: Open Virtualization Format (OVF) Tool.
Open Terminal on macOS/Linux or PowerShell on Windows.
Confirm OVF Tool runs:

ovftool --version

On Windows, the full path may be needed:

& "C:\Program Files\VMware\VMware OVF Tool\ovftool.exe" --version

Convert the OVA to the maximum virtual hardware version your host supports.

Example for ESXi 6.0:

ovftool --lax --maxVirtualHardwareVersion=11 "FileWave_Server_16.3.0.ova" "FileWave_Server_16.3.0-esxi60.ova"

Example for ESXi 6.5:

ovftool --lax --maxVirtualHardwareVersion=13 "FileWave_Server_16.3.0.ova" "FileWave_Server_16.3.0-esxi65.ova"

Example for ESXi 7.0 Update 2 or Update 3:

ovftool --lax --maxVirtualHardwareVersion=19 "FileWave_Server_16.3.0.ova" "FileWave_Server_16.3.0-esxi70u2.ova"

If this creates a new OVA successfully, import the new OVA into ESXi. If ESXi still complains about unsupported devices, the problem is deeper than the virtual hardware version string and the manual edit method probably will not be enough either.

Method 2: manually edit the OVA package

Use this method when OVF Tool is not available or does not create the package you need. The steps are simple, but accuracy matters. A one-character typo in the OVF or manifest can make the package fail to import.

Step 1: extract the OVA

On macOS or Linux:

mkdir FileWave-ova-work
cd FileWave-ova-work
tar -xvf ../FileWave_Server_16.3.0.ova
ls -lh

On Windows PowerShell:

mkdir C:\Temp\FileWave-ova-work\ncd C:\Temp\FileWave-ova-work\ntar -xf C:\Downloads\FileWave_Server_16.3.0.ova\nGet-ChildItem

You should see files similar to these:

FileWave_Server_16.3.0.ovf
FileWave_Server_16.3.0.mf
FileWave_Server_16.3.0-disk1.vmdk

The names may differ depending on whether you downloaded the Server, Booster, or IVS appliance. The important files are:

.ovf - the descriptor file that describes the VM.
.vmdk - the virtual disk file. Do not edit this file.
.mf - the manifest file containing checksums. This must be updated or removed after editing the OVF.
.cert - a signature file, if present. A manual edit invalidates the signature.

Step 2: find the virtual hardware version

On macOS or Linux:

grep -n "VirtualSystemType" *.ovf

On Windows PowerShell:

Select-String -Path *.ovf -Pattern "VirtualSystemType"

You are looking for a line like this:

<vssd:VirtualSystemType>vmx-19</vssd:VirtualSystemType>

Step 3: edit the OVF file

Open the .ovf file in a plain text editor. Do not use Microsoft Word or another rich-text editor.

Change the vmx-## value to the version your ESXi host supports.

Example: change this for a newer OVA:

<vssd:VirtualSystemType>vmx-19</vssd:VirtualSystemType>

to this for ESXi 6.0:

<vssd:VirtualSystemType>vmx-11</vssd:VirtualSystemType>

or this for ESXi 6.5:

<vssd:VirtualSystemType>vmx-13</vssd:VirtualSystemType>

Save the file as plain text.

Step 4: check for virtual devices that may still be too new

Before rebuilding the OVA, search the OVF for devices that commonly cause older ESXi imports to fail.

On macOS or Linux:

grep -niE "nvme|tpm|secure|efi|sata|scsi|vmxnet|e1000|ResourceSubType|guest|VirtualSystemType" *.ovf

On Windows PowerShell:

Select-String -Path *.ovf -Pattern "nvme|tpm|secure|efi|sata|scsi|vmxnet|e1000|ResourceSubType|guest|VirtualSystemType"

For ESXi 6.0, be especially cautious with:

NVMe controllers - older ESXi versions may not support the virtual NVMe controller used by newer appliances.
vTPM - virtual TPM support depends on newer VMware features and key provider configuration.
Secure Boot - older ESXi or older VM compatibility levels may not support the same Secure Boot configuration.
Newer guest OS identifiers - Debian 13 may not appear as a selectable guest OS on older ESXi. A generic 64-bit Debian/Linux guest type may be used after import.

If you see a clearly unsupported device, stop and use a newer ESXi host or ask a VMware administrator to create a compatible VM manually. Changing storage controllers by hand can make Linux fail to boot if the boot disk appears under a different controller than expected.

Step 5: update or remove the manifest

After editing the OVF file, the manifest checksum is no longer correct. If you skip this step, ESXi may report a checksum or file digest error.

Open the manifest file:

cat *.mf

You will see entries similar to one of these:

SHA1(FileWave_Server_16.3.0.ovf)= oldhashvalue
SHA256(FileWave_Server_16.3.0.ovf)= oldhashvalue

If the manifest uses SHA1, calculate a new SHA1 value for the OVF:

shasum -a 1 FileWave_Server_16.3.0.ovf

If the manifest uses SHA256, calculate a new SHA256 value for the OVF:

shasum -a 256 FileWave_Server_16.3.0.ovf

On Windows PowerShell, use one of these:

Get-FileHash -Algorithm SHA1 .\FileWave_Server_16.3.0.ovf
Get-FileHash -Algorithm SHA256 .\FileWave_Server_16.3.0.ovf

Copy the new hash value into the matching .ovf line inside the .mf file. Do not change the VMDK hash unless you changed the VMDK file, which you should not do.

If a .cert file exists, the original signature will no longer be valid after a manual edit. In that case, the simplest option is usually to remove both the manifest and certificate files and import the OVA as unsigned:

rm -f *.mf *.cert

On Windows PowerShell:

Remove-Item *.mf,*.cert -ErrorAction SilentlyContinue

Importing an unsigned OVA may produce a warning. That warning is expected if you removed the manifest/signature files yourself.

Step 6: rebuild the OVA

An OVA is a TAR archive. Do not create a ZIP file and rename it to .ova.

If you kept and updated the manifest:

tar -cvf ../FileWave_Server_16.3.0-esxi60.ova FileWave_Server_16.3.0.ovf FileWave_Server_16.3.0.mf *.vmdk

If you removed the manifest and certificate:

tar -cvf ../FileWave_Server_16.3.0-esxi60.ova FileWave_Server_16.3.0.ovf *.vmdk

On Windows PowerShell, the same idea works with Windows' built-in tar command:

tar -cf ..\FileWave_Server_16.3.0-esxi60.ova .\FileWave_Server_16.3.0.ovf .\FileWave_Server_16.3.0.mf .\*.vmdk

If your appliance has more than one .vmdk file, include all of them.

Import the modified OVA into ESXi

Log into the ESXi Host Client or vCenter.
Select the host or cluster where the appliance should run.
Choose Create/Register VM or Deploy OVF Template, depending on your VMware interface.
Select Deploy a virtual machine from an OVF or OVA file.
Choose the modified OVA file, not the original OVA.
Choose the datastore, network, and disk provisioning option.
If you removed the manifest/signature, accept the unsigned-package warning only if you are sure you are using the OVA you modified.
Finish the import.
Power on the VM and open the console.
Confirm the appliance reaches the Linux login or FileWave appliance setup screen.

After the appliance boots, continue with the normal FileWave appliance setup steps for Server, Booster, or IVS. For 15.5 and newer appliances, also complete the first-login password change workflow.

Troubleshooting

Symptom	Likely cause	What to do
`Unsupported hardware family vmx-##`	The OVF still declares a virtual hardware version that is too new.	Re-check the `VirtualSystemType` line and confirm the ESXi/vCenter version supports the value you used.
Checksum, digest, or manifest error	The OVF was edited but the `.mf` file was not updated.	Update the manifest hash or remove the `.mf` and `.cert` files and import as unsigned.
Unsupported virtual device	The OVA uses a virtual device the older ESXi host does not support.	Use a newer ESXi host, or have a VMware administrator build a compatible VM and attach/convert the disk.
The VM imports but does not boot	The disk controller, firmware mode, or boot device changed enough that Linux cannot boot.	Do not keep hand-editing blindly. Use a newer host or rebuild a compatible VM with the correct disk/controller mapping.
Debian 13 is not listed as a guest OS	Older ESXi versions do not know about newer Debian releases.	Choose the closest generic 64-bit Debian/Linux guest type available. This only changes VMware's guest label/settings, not the OS inside the appliance.

Safer alternatives

If this is for a production FileWave Server, Booster, or IVS, the safer options are:

Upgrade ESXi/vCenter to a supported version that matches the OVA requirements on the FileWave Downloads page.
Deploy the FileWave appliance on a newer supported virtualization platform.
For FileWave Server or Booster deployments where appropriate, install FileWave on a customer-managed Debian system using the installer from the same FileWave release page instead of using the pre-built OVA.
Contact FileWave Support or Professional Services if this is part of a migration or recovery plan.

The manual OVA edit is a useful escape hatch, but it should not become the long-term plan for running production infrastructure on an unsupported VMware platform.

Using FileWave OVA appliances with older VMware ESXi versions

When to use this article

What this changes, and what it does not change

Before you start

Optional: check the original OVA MD5 value

Choose the correct virtual hardware version

Method 1: try VMware OVF Tool first

Method 2: manually edit the OVA package

Step 1: extract the OVA

Step 2: find the virtual hardware version

Step 3: edit the OVF file

Step 4: check for virtual devices that may still be too new

Step 5: update or remove the manifest

Step 6: rebuild the OVA

Import the modified OVA into ESXi

Troubleshooting

Safer alternatives

Related content