TL;DR · Key Takeaways
- VCF 9.1 adds VCF Management Services, a container cluster that hosts fleet lifecycle, SDDC lifecycle, the software depot and the new license server. It is mandatory, not optional.
- The 9.0 Fleet Management Appliance is gone. Its job moves into two services, Fleet Lifecycle and SDDC Lifecycle, inside VCF Management Services, and the old appliance is powered off and decommissioned.
- The sequence starts with VCF Operations, not SDDC Manager. Ops first, then SDDC Manager, then deploy VCF Management Services, then NSX, vCenter and ESX.
- The standalone Identity Broker cluster from 9.0 folds into VCF Management Services, and licensing moves to a central VCF License Server.
- Plan for a /27 on the management network and a Cloud Proxy in the instance that hosts VCF Operations before you start.
- Start with the VCF 9.1 Upgrade Planning Tool. It generates a phase-by-phase plan for your exact starting point.
I have upgraded enough VCF fleets to know the hard part of a 9.1 upgrade isn’t clicking buttons. It’s the surprise halfway through, when a component you forgot about blocks the whole plan. 9.1 moves more furniture than a normal dot release, so before any bundle gets downloaded, the job is to get the mental model right.
This first part is the map for the rest of the series. I’ll cover what actually changed, why it’s worth the maintenance window, and the exact order the upgrade runs in. Read this one before you touch anything, then follow the planning parts that come next. If you want the component-level detail on Operations itself, my VCF 9 Operations series covers it, and for a side by side of the two releases see my 9.0 vs 9.1 breakdown.
What actually changed in 9.1
Most of what’s new in 9.1 is a reshuffle of the management plane. The workload side (vSphere, vSAN, NSX) upgrades much like before. The part that’s different is how the fleet manages itself.
VCF Management Services, the new center of gravity
The headline change is a component called VCF Management Services. It’s a container cluster that Broadcom describes as a common runtime for the fleet’s lifecycle and operational pieces, and it is mandatory. You cannot upgrade the rest of the stack to 9.1 until it’s deployed. Inside it live the parts that used to be spread across separate appliances: fleet lifecycle, SDDC lifecycle, the software depot that feeds updates, and the new license server.
If you ran 9.0, think of this as where the Fleet Management Appliance’s job went, except broken into services and run as containers instead of a single VM.
What got decommissioned
Three things from 9.0 go away during the upgrade. The standalone Fleet Management Appliance is replaced by two services, Fleet Lifecycle and SDDC Lifecycle, that now run inside VCF Management Services. Once its data is transferred, the old appliance is powered down and ready to decommission. The external Identity Broker cluster (vIDB) folds into VCF Management Services and its standalone VMs are powered off. And per component or Aria based licensing gives way to a central VCF License Server. None of these are optional. The upgrade path assumes them.
Why upgrade, the honest case
Faster patches
The reason I’d push a 9.0.x shop to move sooner than later is the patch cadence. Once you’re on 9.1 with the software depot and fleet lifecycle in place, updates and patches flow through one mechanism instead of you chasing bundles per product. Broadcom has been clear that getting to 9.1 is what lets you take the faster patch releases.
One license server
Licensing in the 9.0 world was spread out and easy to get wrong. The central license server in 9.1 gives you one place to hold and assign entitlements, with local control and room to scale. If you have ever fought a license assignment failure on a vCenter, this is the change that removes that class of problem, once it’s set up correctly.
Security and staying current
There’s a plainer reason too. Running an older VCF means running a larger attack surface. Each release folds in fixes across vSphere, NSX and the management plane. Staying a version behind on infrastructure this central isn’t a position I’d want to defend to an auditor.
| Function | VCF 9.0 | VCF 9.1 |
|---|---|---|
| Fleet lifecycle | Fleet Management Appliance (VM) | Fleet Lifecycle service in VCF Management Services |
| SDDC lifecycle | SDDC Manager driven | SDDC Lifecycle service in VCF Management Services |
| Update source | Per product bundles | Software Depot in VCF Management Services |
| Licensing | Per component / Aria | Central VCF License Server |
| Identity | Standalone Identity Broker cluster (vIDB) | Folded into VCF Management Services |
Which component upgrades first?
Here’s the part people get wrong. The sequence does not start with SDDC Manager. It starts with VCF Operations.
VCF Operations is mandatory in 9.x, and on a 9.0.x fleet it’s the component that owns fleet management. The upgrade uses the Operations upgrade to move that fleet management data into the new VCF Management Services cluster, then decommissions the old Fleet Management Appliance. If you tried to upgrade SDDC Manager or deploy Management Services first, you’d be moving furniture before the truck arrived.
The order that works: run prechecks, upgrade VCF Operations, upgrade SDDC Manager to 9.1, deploy VCF Management Services and the license server, then upgrade the management domain core as NSX, vCenter, ESX, and finish the NSX Edge cluster.
One detail that trips people: NSX is two steps
In 9.x the NSX VIBs ship inside ESX, so NSX upgrades in two passes. You upgrade the NSX management stack first, then finalize by upgrading the Edge cluster after vCenter and ESX are done. If you treat NSX as one step, you’ll wonder why the workload domain won’t show as finished.
Where you can upgrade from
Not every environment takes the same road to 9.1. You can come from 9.0.x, which is the cleanest path and the one this series follows step by step. You can come from 5.2.x, which is a longer trip with more remediation and, in most cases, an intermediate stop before 9.1. And you can come from a standalone vSphere Foundation or a vSphere 8 with Aria Operations 8 footprint. Part 2 breaks down each supported path and the version floors that go with them. For this part, the thing to hold onto is that your starting point decides how much of the upgrade is remediation versus a straight version bump.
The prerequisites that actually bite
Prechecks in SDDC Manager catch most problems, but a handful of prerequisites are the ones I see stall real upgrades. Handle these before upgrade day, not while the clock is running.
A temporary IP for every vCenter
The vCenter upgrade needs a temporary IP address on the management network for each vCenter server while it migrates. One free address per vCenter, reachable and not already claimed by something else. On a tight subnet this is easy to forget until the workflow asks for it and you don’t have one ready.
Certificates and passwords that haven’t quietly expired
The upgrade validates certificate and password validity across components. An expired or about to expire certificate, or a password that rotated out from under SDDC Manager, will fail a precheck. Check these a week ahead so you have time to fix them calmly instead of during a window. If certificates are a recurring pain in your environment, that’s its own project worth doing first.
The vSAN hardware compatibility database
If you run vSAN, the hardware compatibility database needs to be current before the ESX upgrade. A stale HCL database can flag hosts that are actually fine, or miss ones that aren’t. Refresh it as part of prep so the host remediation step has accurate data to work from.
Bundles and the Operations version floor
Download the upgrade bundles ahead of the window so you’re not waiting on transfers mid-upgrade. And if you’re coming from 5.2.x, VCF Operations has to be on 8.18 before it can move to 9.1, which can mean an intermediate hop. From 9.0.x you don’t hit that floor, but you still want Operations fully current so the 9.1 bundles show up in the depot at all.
What VCF Management Services needs before you start
Two requirements catch people who skip the planning workbook.
Network space
VCF Management Services wants a block of contiguous IPs on the management network. The minimum works out to a /28, but Broadcom recommends a full /27, which is 30 usable addresses, so you have headroom. If your management subnet is already tight, sort this out before upgrade day, not during it.
A cloud proxy
The integration between VCF Operations, SDDC Manager and VCF Management Services needs a Cloud Proxy in the VCF instance where VCF Operations lives. If you don’t have one there, you’ll deploy it as part of the upgrade. Knowing that in advance saves a mid-upgrade scramble.
| Component | Required for the 9.1 core upgrade? | When |
|---|---|---|
| VCF Operations | Yes, mandatory and first | Step 2 |
| SDDC Manager | Yes | Step 3 |
| VCF Management Services + License Server | Yes, mandatory | Step 4 |
| NSX, vCenter, ESX | Yes | Step 5 |
| VCF Automation (ex Aria Automation) | No, only if deployed | After core, Day-N |
| Workload domains | No, optional Day-N | Later windows |
A worked example: planning a 9.0.2 management domain
Here’s how I’d frame a real one. Say you’re on 9.0.2, one management domain, NSX and vSAN in play, VCF Operations already deployed, no Aria Automation. The first thing I do is not open SDDC Manager. I open the VCF 9.1 Upgrade Planning Tool, tell it I’m on 9.0.2, and let it generate the phased plan plus the resource and networking requirements for that exact footprint.
Then I map maintenance windows to phases. Prechecks and the Operations upgrade in one window, allowing a couple of hours and expecting the fleet management transition to take time. SDDC Manager and the Management Services deployment in the next. NSX, vCenter and ESX across one or more windows depending on host count and how long you can drain clusters. The Edge finalize at the end. A single small management domain can land in a long day. A fleet with several workload domains is a multi-day plan, and that’s fine, because workload domains can be upgraded later as a Day-N job.
Common questions
Do I have to deploy VCF Management Services, or can I skip it?
You can’t skip it. It’s mandatory, and the rest of the 9.1 upgrade is gated on it being deployed. Plan the network space for it up front.
Can I upgrade SDDC Manager first to get it out of the way?
No. VCF Operations goes first because it carries the fleet management data that moves into VCF Management Services. SDDC Manager is the third step, after Operations and before the Management Services deploy.
What happens to my old Fleet Management Appliance and Identity Broker?
Both are retired during the upgrade. Their functions move into VCF Management Services, and the old VMs are powered down and ready to decommission. Don’t delete them until you’ve confirmed the new services are healthy.
How long does a 9.0.x to 9.1 upgrade take?
It depends on host count and how many workload domains you have. A single small management domain can finish in a day. Larger fleets are multi-day. Use the Upgrade Planning Tool to get phase estimates for your footprint, and upgrade workload domains later as Day-N work.
Where should I actually start?
With the Planning and Preparation Workbook and the VCF 9.1 Upgrade Planning Tool, before you download a single bundle. Parts 3 and 4 of this series go deep on both.
What the rest of this series covers
The plan for the next thirteen parts follows the upgrade itself. Parts 2 through 4 stay in planning: supported paths to 9.1, the Planning and Preparation Workbook, and the Upgrade Planning Tool. Parts 5 through 7 are prepare: prechecks and fixing what they flag, backups and a rollback plan before you touch anything, and the full sequence with why the order matters. Parts 8 through 12 are execute, one component at a time, from VCF Operations through the workload domains. Parts 13 and 14 land it, with post-upgrade validation and troubleshooting a stalled upgrade. If you’re upgrading a real fleet, read the planning parts before you schedule anything, and keep the general VCF 9 series handy for the component details this upgrade touches.
References
- How to Upgrade to VMware Cloud Foundation 9.1 (VCF Blog)
- Upgrade Sequence and Related Issues for VCF and vSphere Foundation 9.1 (Broadcom KB 440630)
- Announcing the VCF 9.1 Upgrade Planning Tool (VCF Blog)
About The Author
DrJha