TL;DR · Key Takeaways
- Download the VCF 9.1 Planning and Preparation Workbook (a Microsoft Excel file) and validate every host against the Broadcom compatibility guide before you schedule anything.
- VCF Operations is mandatory in 9.x. Get it to 8.18 before the 9.1 step, and bring Aria Operations for Networks to 6.14 first if you run it.
- Reserve one temporary IP per vCenter, refresh the vSAN HCL database, and confirm certificate and password validity, all before the precheck.
- Plan 12 to 30 static IPs plus matching FQDNs and DNS records for the new VCF Management Services nodes.
- The SDDC Manager upgrade precheck is the gate. It must pass clean, and when it fails it tells you the exact item to fix.
- Confirm a cloud proxy exists in the first VCF instance that hosts VCF Operations, or the later steps stall.
I have never seen a VCF upgrade go sideways during the upgrade itself. It goes sideways in the week before, when someone skips the prep and lets SDDC Manager find the problems the hard way. Version 9.1 adds a few new moving parts, so the prep list is a little longer than it used to be, but the shape is the same: get your inputs straight, get every component to a version the upgrade can accept, then let the precheck confirm it.
This part is the checklist I run before I touch a single bundle. It covers the Planning and Preparation Workbook, the minimum starting versions, the core prerequisites that trip people up, and the SDDC Manager precheck. If you have read Part 2 on supported upgrade paths, this picks up right where confirming your path leaves off.
Why the prep phase decides the outcome
The upgrade engine in VCF is good at its job when the environment matches what it expects. It is unforgiving when it does not. A certificate that expires next week, a host that quietly fell off the compatibility list, a vCenter with no spare IP for its temporary address, any one of these will stop the run partway through, which is the worst place to stop. Doing the prep is how you move those failures out of the change window and into a calm afternoon where you have time to fix them.
There are five stages, and they run in order. Each one feeds the next.
Start with the Planning and Preparation Workbook
The workbook is a Microsoft Excel file Broadcom publishes for each release. People think of it as a deployment artifact, something you fill in once when you build a fleet and never open again. For an upgrade it is still the fastest way to catch a requirement that changed under you. Download the 9.1 copy fresh every time, because the numbers move between releases.
What is inside it
It gathers the inputs a VCF fleet needs: hardware sizing, network addressing, software versions, and the external services like DNS, NTP and directory that everything leans on. For 9.1 it also covers the new pieces, so it now accounts for the VCF Management Services nodes and their addressing alongside the older components. Two companion tools sit next to it. The Configuration Maximums tool tells you whether your planned scale is supported, and the Ports and Protocols tool tells you which firewall rules the new services need.
How I actually use it
I do not fill in every cell. I go to the network and addressing tabs first, because that is where 9.1 changed the most, then I walk the hardware rows against the live inventory. The one row I never skip is the compatibility check. Pull each host model and its storage controllers, then confirm them against the compatibility guide for 9.1 specifically. A server that was fine on 9.0 can drop off the list for the newer ESX build, and you want to know that now, not when the ESX step refuses to remediate a cluster.
Get every component to its minimum starting version
VCF 9.1 will not accept just any starting point. Some components have to be on a specific release before the upgrade can pick them up, and if they are behind you have to run an interim upgrade first. This is the part people underestimate, because a component two releases back can mean an extra maintenance window before the real work even starts.
| Component | Minimum starting version for 9.1 | What it means for you |
|---|---|---|
| VCF Operations (was Aria Operations) | 8.18 | Mandatory in 9.x. If it is behind 8.18, upgrade to 8.18 first. If it is not deployed at all, you deploy it as part of the upgrade. |
| Aria Operations for Networks | 6.14 | Only if you run it. Reach 6.14, then import it into VCF Operations fleet management before upgrading. |
| Aria Automation | Latest 8.x | Be on the latest release. I treat this as a separate workstream because custom content takes time to validate. |
| SDDC Manager, vCenter, NSX, ESX | Supported 9.0.x | Confirm your exact build is on a supported path to 9.1 (Part 2 covers this). |
| VMware Identity Manager 3.3.x | Plan the move | If you still run it from an older Aria stack, plan to transition to VCF Identity Broker rather than carry it forward. |
One more dependency sits underneath all of this. VCF Operations, SDDC Manager and the new VCF Management Services need a cloud proxy in the first VCF instance where Operations is hosted. If that instance has no cloud proxy, you deploy one before the upgrade, because later steps rely on that integration path being in place.
The core prerequisites that stop upgrades
These are the software-side prerequisites specific to the upgrade. None of them are hard on their own. They fail runs because they are easy to forget.
A temporary IP for each vCenter
The vCenter upgrade uses a temporary IP address on the same network as the appliance while the new version comes up beside the old one. You need one free address per vCenter, and it has to be reachable and not already in use. On a fleet with several domains that is several addresses, so reserve them together and write them down.
Certificate and password validity
Check that certificates are valid, use the correct FQDN, and are not about to expire mid-upgrade. Do the same for service and admin passwords. An account that expires during the run leaves a component half-upgraded and unable to authenticate, which is a bad place to be at two in the morning.
Refresh the vSAN HCL database
The vSAN hardware compatibility database needs to be current so the health checks judge your hardware against the right list. If your environment is offline you download the update and load it manually. A stale HCL throws warnings that look alarming but are really just an out-of-date reference file.
Download the bundles and reserve IPs and FQDNs
Pull the upgrade bundles ahead of the window so you are not waiting on a download during the change. Then reserve the addressing for VCF Management Services. Plan for a minimum of 12 static IPs, up to around 30 depending on scale-out plans, each with a matching FQDN and forward and reverse DNS. The new nodes must not sit inside the IP ranges you assign to the management services themselves, and the FQDNs have to resolve cleanly before you start.
| Prerequisite | Why it matters | How I check it |
|---|---|---|
| Temporary IP per vCenter | Used during the vCenter upgrade so old and new run side by side | Ping the address, confirm it is free, record one per domain |
| Certificates valid and FQDN-correct | An expiry mid-run leaves a component unable to authenticate | Check expiry dates and subject names on each component |
| Passwords not expiring | Same failure mode as certificates, just via accounts | Review rotation policy against the planned window |
| vSAN HCL current | Health checks judge hardware against the reference list | Update online, or load the file manually if air-gapped |
| Bundles downloaded | Avoids a long download inside the change window | Stage them in the depot ahead of time |
| 12 to 30 IPs and FQDNs reserved | VCF Management Services nodes need clean addressing and DNS | Confirm forward and reverse DNS resolves for each name |
How long the prep phase takes
On a healthy 9.0.x fleet where everything already sits close to the required versions, prep is a day or two of checks: pull the workbook, confirm hardware, reserve the addressing, refresh the HCL, run the precheck. When VCF Operations is several releases back, prep can stretch to a week or more, because each interim Operations upgrade is its own window with its own validation before you can even see the 9.1 path.
The riskiest single prep step is getting VCF Operations to 8.18. It is the component the whole 9.1 sequence starts with, so if it is far behind you may be chaining two or three upgrades just to reach 8.18. I test this one first, on the least critical instance when I have the option, and I confirm the cloud proxy is healthy both before and after, because a broken Operations-to-SDDC integration blocks everything downstream. If I could only fully rehearse one part of the prep, it would be this one.
What I would skip: chasing a spotless workbook with every optional cell filled. It burns hours and the precheck catches the things that actually matter. Spend that time on versions, addressing and backups instead.
Run the SDDC Manager precheck
After the workbook, the versions and the core prerequisites, the last prep step is the upgrade precheck inside SDDC Manager. It looks at the whole environment and reports errors before you commit. When it flags something it gives you the detail and the remediation, so you fix the item, then run it again. Keep running it until it passes clean. A precheck with warnings you have decided to ignore is a run waiting to stall.
Common questions
Do I have to fill in the whole workbook for an upgrade?
No. For an upgrade the value is in the network, addressing and hardware-compatibility rows. I use those to catch requirements that changed since 9.0 and to lay out the new management services addressing. The rest is more useful for a fresh deployment.
What if VCF Operations is not deployed at all?
It is mandatory in 9.x, so it gets deployed as part of the upgrade. If it already exists but sits below 8.18, upgrade it to 8.18 first, then let the 9.1 process take it forward and migrate fleet management into the new VCF Management Services cluster.
How many IP addresses do I really need?
Plan for at least 12 for the VCF Management Services nodes, and up to around 30 if you expect to scale out. Each needs a matching FQDN with working forward and reverse DNS, and they must not fall inside the ranges you assign to the management services.
Can I ignore a precheck warning to save time?
I would not. The warnings that look harmless, like a missing reverse DNS record, are the ones that stall the management services deployment. Fix it and re-run. A clean precheck is faster than recovering a parked upgrade.
Where does the cloud proxy fit in?
The first VCF instance that hosts VCF Operations needs a cloud proxy for the integration between Operations, SDDC Manager and VCF Management Services. If it is not there, deploy it during prep, because the later steps assume it exists.
Related reading: VCF 9.0 vs 9.1 and the earlier supported upgrade paths guide.
References
- Broadcom TechDocs: Planning and Preparation (VCF 9.1)
- Broadcom TechDocs: Upgrading to VMware Cloud Foundation 9.1
- VCF Blog: How to Upgrade to VMware Cloud Foundation 9.1
- Broadcom KB: Upgrade Sequence and Related Issues for VCF 9.1
About The Author
DrJha