Sarge Siddiqui

VxRail is not a dead end any more. Four topologies still are.

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.

The supported VxRail to VCF 9.1 path alongside the four deployment types with no supported path, and the Dell hardware generations in scope
One check before the vCenter step
If the cluster runs vSphere Supervisor, read KB 457944 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 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, 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 sorts for: it splits an estate into what moves as is, what needs work first, and what has to be replaced. 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.

Sources

All checked 6 November 2026.

Share Share Share Share Share Email

Read next

Will the hardware come with you?

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.