VMware Compatibility Matrix: How to Check Hardware

Our VMware ESXi server support team checks every host build against the compatibility matrices before installing or upgrading anything. Since the Broadcom acquisition, the tools have moved: the VMware Compatibility Guide is now the Broadcom Compatibility Guide and the interoperability matrix lives at interopmatrix.broadcom.com. Old vmware.com bookmarks redirect, but search engines still surface dead paths. This page lists the current tools, what each one answers, and the exact steps for the checks that come up in practice.

The three matrices and what each one answers

Certification in these matrices is what defines "supported." If a configuration is not listed, Broadcom support can decline to troubleshoot it, regardless of whether it happens to run.

Check a server model against an ESXi version

1. Open the Broadcom Compatibility Guide and select the Server category.
2. Set the product release filter to the ESXi version you intend to run (for example, ESXi 8.0 U3).
3. Filter by partner (Dell, HPE, Lenovo, Cisco, Supermicro) and enter the exact model in the keyword field. Use the full model string — a PowerEdge R740 and R740xd are separate entries.
4. Open the model's detail page. It lists the certified ESXi releases, the certified CPU series for each release, and any footnotes on BIOS or firmware minimums.
5. Confirm the CPU series in the detail page matches the CPUs actually installed. Server-model certification is per CPU series; a chassis certified with one processor generation is not automatically certified with another.

Vendor sites publish their own support statements (Dell's VMware support pages, HPE's server support matrices), but the Broadcom guide is the authoritative record for what Broadcom will support.

Check a NIC or HBA by VID/DID

IO devices are certified by PCI identifiers, not by marketing name, because the same silicon ships under multiple brand names. From an ESXi host, get the identifiers first:

vmkchdev -l | grep vmnic
# or, per device:
lspci -v

The output includes four hex values: VID (vendor ID), DID (device ID), SVID (sub-vendor ID), and SSID (sub-device ID). Then:

1. In the Compatibility Guide, select the IO Devices category.
2. Enter the VID and DID in the search fields (SVID/SSID narrow it to the exact OEM variant).
3. Set the ESXi release filter.
4. The result lists the certified driver name and version and the firmware version it was certified with. Both matter: a certified device running an uncertified driver/firmware pairing is outside the tested configuration.

This is the check that catches most "worked in 7.x, dead in 8.x" cases. ESXi 8.0 removed the legacy vmklinux driver stack and dropped a long list of older IO devices; the removed devices are enumerated in KB 318385, Devices deprecated and unsupported in ESXi 8.0. If a NIC is in that list, no driver exists for 8.x and the upgrade will leave the host without that adapter.

Check vCenter and ESXi version interoperability

1. Open the Product Interoperability Matrix and choose Interoperability.
2. Select VMware vCenter Server as the first product and the versions you run or plan to run.
3. Select VMware vSphere Hypervisor (ESXi) as the second product.
4. The grid shows supported pairs. The standing rule holds: vCenter must be equal to or newer than every ESXi host it manages, and vCenter is upgraded first in any upgrade sequence.

The same site has an Upgrade Path view, which answers a different question: whether a direct upgrade from one version to another is supported, or whether an intermediate step is required. Check both before planning a jump across multiple releases. Solution-level interoperability (backup software, storage plugins) is documented by those vendors, but VMware-product-to-VMware-product pairs belong to this matrix.

Check guest OS support

1. In the Compatibility Guide, select the Guest OS category.
2. Filter by OS family and release (for example, Windows Server 2025, RHEL 9).
3. Set the ESXi release. The entry states the support level and the virtual hardware versions it applies to, plus footnotes on required VMware Tools or known constraints.

Guest OS listings change independently of hardware listings — an OS vendor ending support for its own release also changes its status here. For the ESXi side of the same question, the release lifecycle dates on Broadcom TechDocs and the product lifecycle pages on vmware.com govern which ESXi builds still receive updates; a matrix entry against an end-of-support ESXi release is a supported-in-the-past statement, not a current one. Release-by-release differences are covered in ESXi versions.

Exporting results

Both tools produce saved output for change records. The Compatibility Guide has an export control on result lists (CSV/spreadsheet output of the current filtered view) and printable detail pages per entry. The Interoperability Matrix can export the generated grid to PDF or CSV from the results view. Export the result with the filters visible and attach it to the change ticket — the matrices are updated continuously, and a claim that a configuration "was listed" is unverifiable later without the snapshot.

What "not listed" means

Absence from the matrix is not a statement that the configuration fails. It means one of:

• Not certified. The partner never submitted the hardware for certification against that release. Common for consumer hardware, white-box builds, and older servers against new ESXi releases. It may boot and run; it is unsupported, and support cases on it can be declined.
• Certification withdrawn or expired. The device was listed for earlier releases and the partner stopped certifying. The detail page's per-release list shows where certification stopped.
• Explicitly dropped. The device or CPU appears in a deprecation KB (see below). This is a stronger statement than absence — the platform removed the driver or enforces a block at install time.

For lab use, unlisted hardware is a routine trade-off. For production, treat the matrix as binding: the difference surfaces at the exact moment a support case is opened.

Common gotchas

• CPU generation cutoffs per ESXi release. Each major ESXi release drops older CPU generations. ESXi 8.0 removed support for CPU generations that were still accepted by 7.x — the installer and upgrade precheck raise a CPU warning or block on affected hosts, and Broadcom has stated that Intel Skylake-generation CPUs are planned for removal in releases after 8.0.x. Verify the CPU against the deprecation lists on knowledge.broadcom.com: KB 318697, CPU Support Deprecation and Discontinuation, and KB 413002 on CPU_SUPPORT_WARNING during upgrades to 8.0. A warning on 8.0 is the notice that the same CPU becomes a hard stop in the next major release.
• Server certified, CPU not. The model entry passes at a glance, but the certified CPU series for the target ESXi release excludes the processors installed. Always open the detail page.
• Device certified, driver/firmware pairing not. The IO listing certifies specific driver and firmware versions together. Upgrading ESXi without matching firmware puts the host outside the certified combination even though every part is individually listed.
• Old bookmarks. vmware.com/go/hcl and the old partnerweb URLs redirect to the Broadcom tools, but embedded links in runbooks and vendor PDFs frequently point at retired paths. Update runbooks to the two Broadcom URLs above.
• Matrix checked once, then never again. Certifications for a release continue to be added and withdrawn after GA. Re-check at upgrade planning time, not from notes taken at initial deployment.

When to hand it over

Compatibility verification is the cheap part; the cost lands when an unverified host is mid-upgrade with a NIC that has no 8.x driver. Our VMware support team runs the full pre-upgrade check — server, CPU, IO devices by VID/DID, interop grid, and upgrade path — as a standard step before any host or vCenter upgrade, and handles the upgrade itself. Background on the platform is in VMware ESXi.