> ## 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. # VxRail is not a dead end any more. Four topologies still are. - URL: https://www.mohammadsiddiqui.com/vxrail-vcf-9-1-upgrade-path/ - Published: 2026-11-11T21:00:00.000Z - Updated: 2026-11-11T21:00:00.000Z - Description: Dell and Broadcom co-developed an in-place upgrade, so the hosts stay. The prerequisites and the four excluded topologies decide whether it applies to you. - Author: Sarge Siddiqui - Tags: VCF, Lifecycle, Architecture One check before the vCenter step If the cluster runs vSphere Supervisor, read [KB 457944](https://knowledge.broadcom.com/external/article/457944?ref=mohammadsiddiqui.com) first. Upgrading vCenter from 8.0 U3 or 9.0.x to 9.1 or 9.1.1 can delete the Supervisor control plane VMs if the vLCM database was reset in the past. It is fixed in vCenter 9.1.1.0100 (build 25784172), so aim for that patch level or later. Captured 6 November 2026 against Broadcom's own announcement, the VCF 9.1.1 on VxRail 9.1.100 release detail, and Dell's support boundaries. Version numbers move. Check the current matrix before you commit a date to anyone. For two years the honest answer to a VxRail customer asking about VCF 9 was uncomfortable. The platform was supported, the hardware was fine, and the only route onto the current version appeared to involve wiping the hosts. That is not an upgrade, it is a rebuild with the same serial numbers, and nobody budgets for it willingly. That changed, and then it changed again in October, and most people I speak to have only half the story. Here is the whole thing, including the four deployment types the new path still does not cover. ## What actually changed Dell and Broadcom co-developed an **in-place upgrade** to VCF 9.1\. [Broadcom's own post](https://blogs.vmware.com/cloud-foundation/2026/06/16/vmware-cloud-foundation-9-1-path-for-dell-vxrail-customers/?ref=mohammadsiddiqui.com) puts it plainly: customers follow the established VxRail upgrade process and the hosts do not need to be wiped and reimaged. Your existing kit carries forward. Two prerequisites gate it. The VMware software on the environment has to be **5.2.2 or later**, and VxRail has to be **8.0.361 or later**. If you are below either line, you have a two-stage project rather than one, and the first stage is the one people forget to put in the plan. Then in October, [VCF 9.1.1 landed on VxRail 9.1.100](https://davidring.ie/2026/10/29/vmware-cloud-foundation-9-1-1-released-on-dell-vxrail-9-1-100/?ref=mohammadsiddiqui.com), which supports in-place upgrades from VCF 5.2 and later and brings the bill of materials to 9.1.1.0 across ESXi, vSAN, vCenter, SDDC Manager, NSX, VCF Operations and VCF Automation. ## The four exclusions, which is the part to read twice Broadcom lists four deployment types with **no supported upgrade path in this release**. They have to wait for something after VCF 9.1, and no date has been given. - **Stretch Cluster** - **Dynamic Node** - **Two-node** - **Satellite Node** Why this matters more than it looks Stretched clusters are not an edge case in regulated environments. They are often the thing the availability design was built around, and the thing an auditor asked about. Two-node and satellite deployments are how most people run branch and edge. So the customers most likely to be told "good news, there is an in-place path now" are also the ones most likely to find their particular topology is not in it. Establish which of your clusters fall into these four before the upgrade conversation starts, not during it. ## Mixed hardware, with rules VCF 9.1 lets you put VxRail and Dell vSAN Ready Nodes in the same instance. That is new, and useful if you have been buying Ready Nodes alongside an ageing VxRail estate. The rules around it are strict enough to matter at design time. Each workload domain has to be homogeneous A workload domain is all VxRail or all Dell vSAN Ready Node. You cannot blend the two inside one domain, so the mixing happens at the instance level, between domains, not within a cluster. The management domain stays VxRail-only If VxRail is present anywhere in the instance, the management domain must remain exclusively VxRail. This is the constraint most likely to break a plan that assumed new Ready Nodes could take over management as the old hardware aged out. They cannot, not while any VxRail remains. Dell hardware only Third-party vSAN Ready Nodes are not supported in a VCF on VxRail instance. VCF on VxRail remains a Dell-engineered and Dell-supported system, and configurations outside the documented Dell guardrails need formal review before they are even considered. You end up running two lifecycle models side by side VxRail clusters keep integrated VxRail LCM. Dell vSAN Ready Node clusters use the standard VCF lifecycle process. VCF Operations and SDDC Manager give you one operational view across both, but the patching mechanics underneath are different. Worth knowing before you promise anyone a single pane of glass means a single process. ## The hardware floor, which has moved The October release draws its supported platform line across four Dell generations, and where that line falls will decide a refresh budget for some people. - **14G: Cascade Lake only.** First-generation Intel Xeon Scalable, which is Skylake, is out of scope for vSphere and VxRail 9.x entirely. Not deprecated, out of scope. - **15G and 16G:** Intel and AMD. - **17G: Intel, greenfield only**, and only as standard vSAN ESA clusters. Two constraints worth putting in the design document Standard vSAN clusters only in this release. And IPv4 only, which lands on anyone who has been building toward dual stack. Neither is permanent, and neither has a published end date. ## What I would do with this 1. Inventory your VxRail clusters by topology first, not by version. The question that decides everything is whether any of them are stretched, two-node, dynamic or satellite. 2. Check the current VMware software version against the 5.2.2 floor and VxRail against 8.0.361\. If either is short, that is a separate piece of work with its own change window. 3. Identify every 14G node and establish whether it is Cascade Lake or Skylake. Skylake has no path, so that is a hardware line item, not an upgrade task. 4. If you were planning to retire VxRail gradually by adding Ready Nodes, check where your management domain is going to live. The VxRail-only rule may reorder your whole sequence. 5. Decide now who owns patching for each cluster type, because you are going to be running two lifecycle processes under one console. The useful thing here is not that the path exists. It is that the path has a shape, and the shape excludes exactly the deployments that were hardest to build in the first place. A customer who went to the trouble of a stretched VxRail cluster did it for a reason, and that reason has not gone away just because the upgrade documentation has not caught up with it yet. Tools that go with this The CPU generation question above is exactly what [Estate Readiness Triage](https://www.mohammadsiddiqui.com/estate-readiness-triage/) sorts for: it splits an estate into what moves as is, what needs work first, and what has to be replaced. [Upgrade Runway](https://www.mohammadsiddiqui.com/upgrade-runway/) then works backwards from your end of general support date to the latest date you could still start. Free to use, including with customers. Nothing you enter leaves your browser. [Everything else on VCF](https://www.mohammadsiddiqui.com/vcf/). ## Sources All checked 6 November 2026. - [Broadcom, VMware Cloud Foundation 9.1 path for Dell VxRail customers](https://blogs.vmware.com/cloud-foundation/2026/06/16/vmware-cloud-foundation-9-1-path-for-dell-vxrail-customers/?ref=mohammadsiddiqui.com), 16 June 2026\. The in-place upgrade, the prerequisites, the four unsupported deployment types and the mixed hardware rules. - [David Ring, VMware Cloud Foundation 9.1.1 Released on Dell VxRail 9.1.100](https://davidring.ie/2026/10/29/vmware-cloud-foundation-9-1-1-released-on-dell-vxrail-9-1-100/?ref=mohammadsiddiqui.com), 29 October 2026\. Build numbers, supported platform generations and the standard-cluster and IPv4 constraints. - [Dell, Dell and Broadcom's Continued Commitment to VxRail](https://www.dell.com/en-us/blog/dell-and-broadcoms-continued-commitment-to-vxrail/?ref=mohammadsiddiqui.com). - [Broadcom KB 450374, Transitioning from vSphere 9.1 (VxRail) to VCF 9.1 (VxRail)](https://knowledge.broadcom.com/external/article/450374/transitioning-from-vsphere-91-vxrail-to.html?ref=mohammadsiddiqui.com). - [CloudNews, VxRail Gets a Second Life](https://cloudnews.tech/vxrail-gets-a-second-life-dell-and-vmware-open-an-upgrade-path-to-vcf-9-1/?ref=mohammadsiddiqui.com), 4 September 2026\. Useful on what the path does and does not change commercially.