Fixing VMware ESXi’s “Unsupported hardware family vmx‑12” OVF Import Error
When you drop an OVF into the vSphere Client and it throws a red‑flag message saying “Unsupported hardware family vmx-12”, you’re staring at a mismatch between what your virtual machine was built for and what your host actually understands. It’s not a mysterious cryptic bug; it’s just the host telling you, “I’m still stuck on VMX‑11, buddy.”
In this quick guide I’ll walk you through why that error pops up, how to spot it in the file itself, and three practical ways to get past the wall so your OVF lands where it belongs.
1. Spot the Problem – What’s a vmx‑12 anyway?
The “vmx” code inside an OVF is VMware’s shorthand for the VM hardware version. ESXi 6.x tops out at vmx‑11 (hardware v5). If your OVF declares itself as vmx-12, that means it was created in a newer hypervisor – probably an ESXi 7 host or a recent Workstation/Player build that supports VMX‑12.
Why you care: The host refuses to run any machine that claims features it doesn’t have (like newer CPU instructions, memory hot‑add, etc.). That’s the root of the error.
2. Inspect the OVF – Quick look‑and‑tell
Open the .ovf file in a text editor. Search for <OperatingSystemSection> or <VirtualHardwareSection>. You’ll see something like:
<OVF:Reference ovftype="vmx" version="12"/>
If you spot that, you know the machine’s telling your host to do stuff it can’t handle.
3. Method One – Edit the OVF in place
1. Make a backup – just copy the whole folder.
2. In the .ovf, change version="12" to version="11".
3. Save, close, and re‑import via the vSphere Client.
Why this works: You’re effectively telling ESXi that you’re happy with a slightly older hardware spec. The VM will drop any features newer than version 11, but it’ll still run fine if the guest OS doesn’t need them.
When to use this: Quick fix for small VMs or when you don’t mind losing a feature like VM‑aware hot‑add memory.
4. Method Two – Use ovftool with a downgrade flag
If you prefer command line and want to keep the original .ovf untouched, run:
ovftool --vmx-version=11 \
/path/to/source.ovf \
vi://root@esxi-host/Datastore1/newVM
ovftool automatically rewrites the hardware version during import. No manual editing needed, and you avoid human‑error in the file.
5. Method Three – Upgrade your host
If you’re regularly pulling OVFs that target vmx‑12, it’s a sign your ESXi is a bit behind. Upgrading to ESXi 7.x or later lifts the hardware ceiling:
- Check your current version: vim-cmd -V on the console.
- Download the latest installer from VMware and follow the upgrade wizard.
Why you might want this: Future‑proofing. You’ll avoid similar headaches with newer snapshots, vSphere APIs, and better security patches.
6. When the Guest Needs More Than VMX‑11
Sometimes the guest OS (e.g., Windows Server 2019) actually requires features from vmx‑12 for optimal performance. In that case:
- Create a new VM on ESXi 7.x, attach the existing virtual disk (.vmdk), and then install or upgrade the guest OS inside.
- Or, use the “Import OVF” wizard on an ESXi 7 host first, then export to your older host if you must keep it there.
7. Quick Checklist Before You Hit Import Again
| Step | Check | Why? |
|---|---|---|
| Verify VMX version | Open .ovf and look for version= | Confirms the mismatch early |
| Confirm ESXi version | Run vim-cmd -V | Avoids needless edits |
| Backup the source | Copy folder | Safety net if something breaks |
| Test with a small VM | Import a dummy OVF | Saves time on big imports |
8. One More Real‑World Tip
I once had a teammate try to import an exported Workstation 15 OVF into a lab ESXi 6.5 cluster and got that same error. After just changing the version tag, the VM started up in no time—no fancy upgrades needed. It’s a tiny edit, but it saves hours of troubleshooting.
That’s all there is to it. Pick the method that fits your workflow, make sure you know why each step matters, and the vmx-12 wall will crumble before you can say “vSphere.”
