ESX 9 hardware requirements: CPUs, I/O devices, boot media and how to check each host

What ESX 9 needs, and what stops it

Broadcom’s hardware requirements for ESX 9.0 and 9.1, updated on 24 August and 29 September 2026, set the same floor: a server and CPU listed for the release in the Broadcom Compatibility Guide (BCG), a 64-bit x86 host with at least two CPU cores, NX/XD and hardware virtualisation (Intel VT-x or AMD RVI) enabled, 8 GB of RAM, a Gigabit or faster Ethernet controller and a persistent boot disk of at least 32 GB. Broadcom recommends 12 GB of RAM for production VMs, 128 GB of boot device for new servers and UEFI, as “support for legacy BIOS is limited”.

Four conditions block the upgrade or break it: a CPU series discontinued for 9.x (the installer “will block or prevent the installation”), a boot disk below 8 GB (the upgrade “is blocked”), an end of life I/O device, which ESX 9 does not recognise, and a cluster still on baselines: “To complete an upgrade to VCF 9, all clusters must transition” to images (KB 424294). A fifth decides support: “Hardware that was supported for VCF 8.x/ESXi 8.0 is not automatically supported for VCF 9.x/ESXi 9.0” (KB 443586). The rest is mostly deprecated: supported now, removed later.

CPUs: deprecated is not discontinued

KB 318697 has two phases. A deprecated CPU series installs with CPU_SUPPORT_WARNING, “The CPUs in this host may not be supported in future VCF releases”, and stays supported “through the lifetime of that stated VCF release, updates, and patches, or until End-of-General Support (EoGS)”, while the server model stays listed in the BCG; KB 413002 confirms you “can proceed with the upgrade”. A discontinued series is blocked.

Skylake-SP changed phase: KB 428874, updated on 18 September 2026, now supports it “in Deprecated Mode for VCF 9.x” on servers the BCG may mark “VCF Supported. Confirm w/ Vendor”, with no further driver enhancements, best-effort fixes, hardware and firmware support left to the server maker, an override procedure for installing and upgrading, and no support “beyond VCF 9.x”.

Broadcom KB 318697 (no date on the page, read on 4 October 2026) and KB 428874 (updated 18 September 2026). Unnamed series have no 9.x notice; servers still need a BCG listing.

I/O devices: restricted, end of life and the 9.1 list

KB 391170 sorts deprecated devices into two classes. A restricted device keeps a driver and a BCG listing marked “Restricted”, gets no driver enhancements, only best-effort fixes, and “will be removed in the next major release”. An end of life device, or its driver, has been removed: ESX 9.0 does not claim it, and “If you proceed to upgrade to ESX 9.0 from a host with an EOL device, the following non-recoverable consequences may occur”: lost access to datastores, to the network or to the host’s configuration. Replace them first; the lists are spreadsheets attached to the KB.

VCF 9.1 deprecates more, for later removal: Marvell FastLinQ 57800/57810/57811 and 41000/45000 adapters, Cisco VIC 1200 and 1300, AMD Solarflare 8000 and X2, and the Marvell/Aquantia Atlantic drivers. The 9.1 notes call the 57810 deprecated, while KB 442745 says the BCM57810 10Gb Base-T card is end of life for ESX 9.0, with an upgrade that “fails or results in complete loss of network connectivity”. Identify each adapter by the four PCI IDs that vmkchdev -l prints and search the BCG for them (KB 323110), starting where KB 443586 points: “I/O controllers and NVMe storage devices, as driver requirements have shifted”.

Boot media and system storage

SD and USB devices remain supported for the boot banks in 9.0 and 9.1, but OSDATA on them “is being deprecated”: best practice is a separate persistent local device of at least 128 GB, and a host upgraded on USB or SD should get OSDATA on a persistent disk or SAN LUN.

VCF 9.1 deprecates USB and SD boot devices, ESX without persistent system storage for OSDATA and system storage under 32 GB, for removal in the next major release. KB 317631 keeps USB and SD boot “through the VCF 9.0 product release, including the update releases”; its guideline, stricter than the requirements pages, gives 128 GB, in binary gigabytes, as the 9.x boot device minimum, with at least 100 MB/s and 128 TBW over five years, and Broadcom no longer certifies new servers that boot from USB or SD. For a new host, a persistent SSD of at least 128 GiB with that endurance meets all of them.

Memory, firmware mode and TPM

ESX 9 needs 8 GB of RAM, which esxcli hardware memory get shows, and “Intel Optane PMEM is no longer supported in ESX 9.0”. KB 313152 says vSphere 8.0 dropped legacy BIOS for new platforms from Cascade Lake and Rome on, and that an upgraded legacy BIOS server may “no longer function”, generally with no fix besides UEFI or a downgrade; its order: switch to UEFI on the old release, reboot, resolve device issues, then upgrade only if the host works. vsish -e get /hardware/firmwareType shows the mode (KB 436768), and esxcli patches of 8.0 hosts in legacy mode stop at a BIOS_FIRMWARE_TYPE warning unless --no-hardware-warning is added (KB 391610, 414676).

A TPM is not on the requirements list. To use one, the vSphere 9.0 security guide asks for TPM 2.0 enabled in UEFI, UEFI Secure Boot and the TPM set to SHA-256 and the TIS/FIFO interface, “not CRB”; ESX then stores its configuration encryption key in the TPM. esxcli hardware trustedboot get shows whether ESX sees a TPM.

Drivers, firmware and cluster images

vSphere Lifecycle Manager handles firmware as part of the cluster image: it arrives as a firmware and drivers add-on from “a special vendor depot, whose content you access through a software module called a hardware support manager”, which the hardware vendor provides. “Firmware updates are not available for clusters or hosts that you manage with baselines”, and vCenter 9.0 no longer supports baseline-managed clusters. For mixed hardware, “vLCM images for heterogeneous hardware-based clusters are only supported starting in ESX 9” (KB 424294), so such clusters reach ESX 9 through a temporarily unrestricted Update Manager, then move to an image “immediately”. In KB 441837, a vendor add-on built for 9.0 is rejected by the 9.1 base image until the vendor’s 9.1 add-on is imported. Per the VCF 9.0 notes, “CIM providers for ESX 8.x and earlier are not supported in ESX 9.0”. For vSAN, KB 428874 keeps Cascade Lake and Skylake-SP ReadyNodes in deprecated mode for 9.x.

How to check each host

On each 8.x host, esxcli hardware platform get and esxcli hardware cpu list describe the platform and its CPUs; esxcli hardware pci list and vmkchdev -l list PCI devices and their IDs; esxcli network nic get -n vmnic0 gives a NIC’s driver and firmware; and in esxcli storage core device list the boot device shows Is Boot Device: true, its size and Is USB (KB 305267). In vCenter 9.x, the host-level hardware compatibility check on the host’s Updates tab tests the “server model and I/O devices” of any host against the BCG for the ESX version you pick, and lists compatible, incompatible and unknown devices. It needs the Customer Experience Improvement Program enabled and vCenter online and does not validate firmware; on vCenter 9.1.0.0, vLCM hardware checks fail for hosts older than 8.0 Update 2 (KB 437157). Against an ESX 9 image, a cluster compliance check marks a host “incompatible” when the image cannot be applied, and the remediation pre-check adds health checks.

Broadcom KBs as named; TechDocs: ESX 9.0 and 9.1 hardware requirements, VCF 9.0 and 9.1 support notes, vSphere 9.0 Lifecycle Manager guide, read on 4 October 2026.

The next step needs only your inventory: one row per host with server model, CPU model, the PCI IDs of every adapter, controller and NVMe device, boot device type and size, firmware mode and cluster lifecycle mode. Against KB 318697, the KB 391170 lists and the BCG, each host is ready, ready after a part or firmware change, or stays on 8.x until replaced.

How long a 9.x hardware decision lasts

Broadcom’s VCF blog of 16 July 2025 set out its “general expectation going forward”: support for major releases “for six (6) years from that major release”, plus an optional year of Extended Support “in certain cases”, “an estimated End of Service date of 17-June 2031” for 9.x, a three-year major release cadence, and minor releases about every nine months, the initial ones expected to get 27 months of support and the last 45. As of 4 October 2026 we found no Broadcom page with an end date for 9.0 or 9.1, or a date for the next major release.

That release is where deprecated CPUs, restricted devices, USB and SD boot and system storage under 32 GB are due to go, the 9.1 adapter deprecations in a future one, and KB 428874 tells owners to “plan ahead”. Hosts that cannot run ESX 9 can wait on ESXi 8 until vSphere 8 support ends, in an image-managed cluster of uniform hardware, as our vSphere 8 guide sets out: vCenter 9.0 manages ESX 8.0 hosts “in the same cluster with ESX 9.0 hosts” (KB 424129), and vCenter 9.1 accepts ESXi 8.x hosts licensed with 8.x keys plus licence capacity from the 9.x subscription (KB 441187). Replacement hosts can change the core count to license (core count guide); Extended Support is in our support guide. Which hosts move, wait or go belongs in the dated action plan our VMware optimisation service draws up ahead of renewal and end of support.

What we do

Eurokommerz holds the contract and supplies the hardware under the solution, with EU invoicing, delivery and warranty under European law; engineering is by our partner Vixen.UNO. Under VMware optimisation, the Vixen.UNO team takes a full inventory of your VMware estate and draws up an action plan ahead of renewal and end of support, with dates. The first step is a free call; the paid technical assessment, its price fixed before work begins, delivers a report, a TCO and ROI model and that plan. Upgrades of vSphere, vSAN, NSX and VCF follow in agreed maintenance windows with a rollback plan at every stage, then support under an agreed SLA. Our infrastructure audit, a separate fixed-price product, works from the exports you provide, without access to your production systems.

FAQ