> ## Content Index > Fetch the complete content index at: https://www.mohammadsiddiqui.com/llms.txt > Use this file to discover other available public pages before exploring further. # Will the hardware come with you? - URL: https://www.mohammadsiddiqui.com/will-the-hardware-come-with-you/ - Published: 2026-11-02T21:00:00.000Z - Updated: 2026-11-02T20:59:59.000Z - Description: Discontinued CPUs block the install, deprecated ones start a countdown, and the network cards fail quietly. Then the choice between import, converge and side by side, which is not the binary most people treat it as. - Author: Mohammad Siddiqui - Tags: architecture, lifecycle, operations Benjamin Lipman asked a question in the comments this week that cuts past everything else I have written this month. He is encouraging customers to plan a path to VCF 9.1, and the tricky part, in his words, is whether their hardware has a place in that plan or whether they need a greenfield build and a migration. It is the right question and it is the one that decides whether a customer can do any of the rest of it. So here is the long answer. ## Two questions, not one People collapse this into "will our kit work", and it is actually two separate checks with different answers. Can the host run ESX 9 at all. And separately, can the cluster meet the vSAN ESA device requirements. A host can pass the first and fail the second, and that is the most common outcome on hardware bought three or four years ago. ### The CPU answer Broadcom splits CPUs into two states in [KB 318697](https://knowledge.broadcom.com/external/article/318697/cpu-support-deprecation-and-discontinuat.html?ref=mohammadsiddiqui.com), and the difference matters more than the words suggest. Discontinued Blocks installation and upgrade. The KB states these will not be recognised by ESX 9.x during installation, and an upgrade from the previous release may also fail. There is no workaround. Deprecated Runs, and is supported, with limitations listed in the compatibility guide. It will be removed in the next major release. [KB 428874](https://knowledge.broadcom.com/external/article/428874/deprecated-cpu-systems-servers-in-esx-9.html?ref=mohammadsiddiqui.com) is the one to read for the specifics, and it has moved since it was first published. Cascade Lake sits in deprecated mode for VCF 9 and is still supported. Skylake-SP was originally discontinued in VCF 9.0 and, per an update dated 18 September 2026, is now supported in deprecated mode for VCF 9.x. In both cases support does not extend past 9.x. Deprecated is not a reprieve It is a countdown with a published end. If a cluster is on a deprecated CPU, it will run VCF 9.x and it will not run whatever comes after. That is not a reason to avoid 9.x. It is a reason to put the refresh date in the same plan rather than discovering it in two years. A community summary from [Daniel Micanek](https://vdan.cz/vmware/vcf/vcf-9-hardware-compatibility-check/?ref=mohammadsiddiqui.com) lists Broadwell, Kaby Lake and Skylake-W as discontinued, and Cascade Lake, EPYC 7001 and 7002, Coffee Lake and Denverton as deprecated. I have confirmed the Cascade Lake and Skylake-SP positions against the Broadcom KB directly. The rest I have not, so treat that list as a starting point and check the KB for your own silicon. ### The trap that is not the CPU This one catches people who did the CPU check properly and stopped there. Network cards and storage adapters have their own end of life list. ESX 9.0 does not claim devices on it. The practical effect is that the host upgrades successfully and then comes up without its storage controller, or without its uplinks, which is a considerably worse way to find out than being blocked at the installer. Check the four PCI IDs against the deprecated device table before the upgrade, not after. There is also a 10 GbE minimum enforced by the VCF Installer, which a lab can work around and a production design should not. ### vSAN ESA, which is where most of these conversations actually land For ESA, each NVMe device has to be certified for the release, or the server has to be an ESA ReadyNode. Certified in general is not the same as certified for this release, and that distinction is where a lot of otherwise sound hardware falls over. Check the database date before you believe the error vCenter, SDDC Manager and the VCF Installer each hold a local copy of the vSAN hardware compatibility database, and a copy more than 90 days old is treated as an error. Both a stale database and genuinely uncertified disks produce the same message about no ESA certified disks being found. Check the database date first, because one of those is a five minute fix and the other is a procurement conversation. Worth knowing: the vLCM cluster hardware compatibility check covers vSAN hardware only. It does not replace the compatibility guide checks for the server, the CPU or the network cards. Passing it is not a complete answer. ### Boot mode and secure boot, which is the one I missed Benjamin came back with this after the first draft, and he is right that it belongs here. He works with global customers running thousands of hosts across every CPU generation you can imagine, which is exactly the population where this bites. What the documentation actually says is softer than you might expect. Broadcom’s [ESX 9.0 hardware requirements](https://techdocs.broadcom.com/us/en/vmware-cis/vsphere/vsphere/9-0/esx-installation-and-setup/installing-and-setting-up-esxi/esxi-requirements/esxi-hardware-requirements.html?ref=mohammadsiddiqui.com) state that booting from UEFI is recommended, and that support for legacy BIOS is limited. Not removed. UEFI is the only option on hosts with supported data processing units. Secure boot and TPM 2.0 are not called out as hard requirements on that page. So the problem is usually not a wall. It is that on a large estate the boot mode and secure boot state are inconsistent, nobody knows which hosts are which, and the inconsistency surfaces during the upgrade rather than before it. Switching an installed host from legacy BIOS to UEFI can also change boot device and device alias behaviour, so it is a change in its own right rather than a firmware toggle on the way past. Find out before you plan anything Across an estate of any size this is a tooling question, not an inspection question. PowerCLI will tell you the firmware type per host: `(Get-VMHost).ExtensionData.Hardware.BiosInfo`. Run it across the estate, get the distribution, and you will know whether this is a footnote or a workstream before anybody commits to a date. If you want TPM-backed attestation and the trust features that depend on it, secure boot stops being optional in practice, whatever the install requirements say. [The TPM documentation](https://techdocs.broadcom.com/us/en/vmware-cis/vsphere/vsphere/9-0/vsphere-security/securing-esxi-hosts/securing-esxi-hosts-with-trusted-platform-module.html?ref=mohammadsiddiqui.com) is the place to start on that, and it is a different conversation from whether ESX will install. ## Why this is per cluster None of the above is an estate-level answer. It is a per-cluster answer, and that is good news rather than bad, because it turns one impossible decision into several tractable ones. A typical outcome on a real estate: a third of the clusters carry forward without argument, a third carry forward but cannot do ESA so they stay on existing storage, and a third are on hardware that is already due for refresh and the question answers itself. Overlay your hardware refresh calendar before you do anything else. Any cluster due for replacement inside the planning window is not a migration problem, it is a procurement item that happens to coincide. What is left is a much smaller problem than the one you started with. ## Then the path, which is not a binary There are four, and most people only discuss two of them. Import An existing vCenter and all its clusters become a workload domain inside an existing VCF instance. Reuses vCenter, clusters, hosts and storage, and optionally NSX. Converge Used when no VCF instance exists yet. The Installer builds a new management domain from an existing vCenter and hosts, deploying what is missing. Side by side A new instance built alongside, with workloads migrated in waves. The source stays available as the fallback until each wave is accepted. Stay where you are vSphere or VVF, with supported upgrades only. A legitimate answer, not a failure. The distinction that matters: import and converge change the management and lifecycle control plane. Neither is a workload migration tool. Side by side is the only one of the three that moves workloads, and it is the only one where the old environment remains a real fallback. ### What import actually costs you The [documented requirements](https://techdocs.broadcom.com/us/en/vmware-cis/vcf/vcf-9-0-and-later/9-1/building-your-private-cloud-infrastructure/working-with-workload-domains/import-an-existing-vcenter-to-create-a-workload-domain.html?ref=mohammadsiddiqui.com) are more constraining than the name suggests, and these are the ones I would check before promising anybody an import. Whole vCenter, no subset Every cluster under that vCenter comes across. If some of them should be governed separately, import is the wrong tool. Version floor VCF instance at 9.0, vCenter at 8.0 Update 3a, ESX at 8.0 Update 3, NSX at 4.2.1 where present. The version ceiling nobody expects The earliest imported component sets the workload domain effective version, and you can then only upgrade to releases published after that component release date. One old cluster constrains the whole domain. Hard blockers Enhanced Linked Mode must be broken first. vCenter HA must go. Clusters on baselines must be converted to images. DRS must be fully automated, not manual or partially automated. No vSphere Distributed Switch means no import. After import Adding hosts to imported clusters needs the vSphere Client. ESX password management through the Password Management Console is unavailable, with a documented workaround. A vCenter snapshot is not a rollback plan It does not reverse NSX changes, host preparation, VCF inventory, certificates or storage. Import and converge are controlled decommissioning workflows on the way out, not a transactional undo. If strict rollback isolation is a requirement, that requirement alone selects side by side. ## How I would decide In this order, because each step removes options and the cheap questions come first. 1. Per cluster, check the CPU state. Discontinued means that cluster is not going in place, whatever else is true. 2. Check the network cards and storage adapters. This is the one that fails quietly. 3. Check ESA device certification only for clusters where ESA is actually the intent. Plenty of clusters do not need it. 4. Overlay the hardware refresh calendar and remove everything that is being replaced anyway. 5. For what remains, ask whether the vCenter boundary is the boundary you want. If it is not, import is out on governance grounds before hardware even enters it. 6. Check the hard blockers: Enhanced Linked Mode, vCenter HA, baselines, DRS automation level, distributed switch. 7. Then choose, per domain rather than per estate. The answer for most estates is a mix, and a plan that says "we are importing four, converging one and rebuilding two" is a better plan than one that picked a single approach and made everything fit it. ## Open items Things I could not establish from public material, listed rather than guessed at: E-01 A current vendor-stated list of discontinued and deprecated CPU families in one place. The KBs carry the authoritative position but have been revised, including a reclassification in September 2026, so anything older than the live page is unreliable. E-02 Whether the deprecated CPU set for VCF 9.x is final or will be revised again before the next major release. E-03 Whether an imported workload domain version floor can be lifted later by upgrading the oldest component, or whether it is fixed at import. E-04 Whether UEFI secure boot is enforced anywhere in the VCF 9.x deployment or import path beyond the bare ESX install requirements. The public hardware requirements do not say so. Raised by a practitioner who sees this at scale, and not yet resolved. ## Sources - [Broadcom KB 428874: deprecated CPU systems and servers in ESX 9.0](https://knowledge.broadcom.com/external/article/428874/deprecated-cpu-systems-servers-in-esx-9.html?ref=mohammadsiddiqui.com) - [Broadcom KB 318697: CPU support deprecation and discontinuation in VCF releases](https://knowledge.broadcom.com/external/article/318697/cpu-support-deprecation-and-discontinuat.html?ref=mohammadsiddiqui.com) - [Broadcom TechDocs: import an existing vCenter to create a workload domain](https://techdocs.broadcom.com/us/en/vmware-cis/vcf/vcf-9-0-and-later/9-1/building-your-private-cloud-infrastructure/working-with-workload-domains/import-an-existing-vcenter-to-create-a-workload-domain.html?ref=mohammadsiddiqui.com) - [Converging vSphere to VCF 9.0: the top 10 questions answered, Broadcom](https://blogs.vmware.com/cloud-foundation/2026/04/16/converging-vmware-vsphere-to-vmware-cloud-foundation-9-0-the-top-10-questions-answered/?ref=mohammadsiddiqui.com) - [Digital Thought Disruption: brownfield vSphere to VCF 9.1, import, converge or rebuild](https://digitalthoughtdisruption.com/2026/07/25/brownfield-vsphere-vcf-9-1-import-converge-rebuild/?ref=mohammadsiddiqui.com) - [Broadcom TechDocs: ESX 9.0 hardware requirements](https://techdocs.broadcom.com/us/en/vmware-cis/vsphere/vsphere/9-0/esx-installation-and-setup/installing-and-setting-up-esxi/esxi-requirements/esxi-hardware-requirements.html?ref=mohammadsiddiqui.com) - [Broadcom TechDocs: securing ESX hosts with Trusted Platform Module](https://techdocs.broadcom.com/us/en/vmware-cis/vsphere/vsphere/9-0/vsphere-security/securing-esxi-hosts/securing-esxi-hosts-with-trusted-platform-module.html?ref=mohammadsiddiqui.com) - [Daniel Micanek: VCF 9 hardware compatibility, servers, CPUs, NICs, vSAN](https://vdan.cz/vmware/vcf/vcf-9-hardware-compatibility-check/?ref=mohammadsiddiqui.com) Related: [the staged path from vSphere 8 to VCF 9.1](https://www.mohammadsiddiqui.com/the-staged-path-from-vsphere-8-to-vcf-9-1/) and [you are estimating from the wrong number](https://www.mohammadsiddiqui.com/you-are-estimating-from-the-wrong-number/), and [your estate no longer has a version number](https://www.mohammadsiddiqui.com/your-estate-no-longer-has-a-version-number/) on why there is no single version left to record.