TL;DR · Key Takeaways
- In 9.1 you run prechecks in two places: the upgrade prerequisite check that ships with SDDC Manager and VCF Operations, and a separate Management Services precheck that validates the new CIDR block and DNS records before that cluster deploys.
- The precheck validates cluster and host health, vSAN health, NSX manager and edge health, vCenter services, certificate and password validity, DNS and NTP consistency, backup status, free capacity, and lifecycle bundle readiness.
- Most failures are boring: an expired password, a stale vSAN HCL database, a backup that has not run to external SFTP, or DNS records that were never created for the new services.
- The new services cluster needs at least a /28 (14 usable IPs) on the management VLAN, and it cannot reuse your 9.0.2 IPs. Get it routed before the window.
- Treat warnings as future outages. Do not start NSX, vCenter, or ESX until the precheck comes back clean.
By the time you get to prechecks, the planning is done and the temptation is to rush. I do the opposite. This is the last cheap place to catch a problem, because everything after it touches a running component. A precheck failure costs you ten minutes. The same problem found halfway through an NSX upgrade costs you the change window and maybe an incident bridge.
This part covers what the 9.1 prechecks look at, where they now live, and how I fix the things they flag. I am writing from real 9.0.x to 9.1 upgrades, so the examples are the failures I actually keep hitting, not a tidy list from a slide.
Where prechecks live in 9.1
If you upgraded 9.0 before, you know the SDDC Manager prerequisite check. That one is still here, and it still gates the SDDC Manager and domain upgrades. What is new in 9.1 is a second gate: because the upgrade deploys the VCF Management Services cluster, there is a precheck for that cluster too, and it runs before the cluster comes up. So you now clear two sets of checks, not one, and they happen at different points in the sequence.
The upgrade prerequisite check
This is the workhorse. In the 9.x model VCF Operations is the control point for lifecycle, so you plan the domain upgrade there, then click Run Prechecks on the Upgrades tab for the domain. It reads the target bill of materials from your plan and validates the live environment against it. If something is wrong, it gives you the failing check and, in most cases, the fix. Run it, read every line, and do not treat a green summary as permission to skip the detail.
The Management Services precheck
Before the new services cluster deploys, the wizard runs its own precheck on the network details you feed it: the CIDR block, the gateway, the VLAN, and the forward and reverse DNS records for the new service FQDNs. This is the check people trip on, because it depends on work outside VCF. If your network team has not routed the subnet or your DNS records do not resolve both ways, this precheck fails and the deployment will not start. It is a good failure to have early, because it is entirely preventable.
What the precheck actually validates
The prerequisite check is not one test, it is a batch of them across the stack. Here are the categories I always see, what each one is really asking, and the fix that usually clears it.
| Precheck category | What it is really checking | Common fix |
|---|---|---|
| Cluster and host health | All hosts connected, no host in maintenance mode, DRS able to evacuate | Reconnect a disconnected host, clear a stuck maintenance mode task |
| vSAN health and HCL | vSAN healthy, on-disk format current, HCL database recent enough to validate hardware | Update the vSAN HCL database, resolve any red vSAN health finding |
| NSX manager and edges | Manager cluster stable, edges healthy, no pending config on transport nodes | Resolve edge alarms, wait for a config realization to finish before you start |
| vCenter services | Core services running, free space on the appliance, a temporary IP available | Reclaim disk on the appliance, reserve a free temporary IP on the same subnet |
| Certificates and passwords | No certificate expiring inside the window, no account password expired | Rotate a soon to expire cert, reset and re-store any expired password |
| DNS and NTP | Forward and reverse records resolve, time is in sync across the fleet | Add missing PTR records, fix a drifting or unreachable NTP source |
| Backups | Recent successful SDDC Manager backup on external SFTP, component backups present | Run and confirm a fresh backup before you continue |
| Capacity and bundles | Enough free capacity to evacuate a host, upgrade bundles fully downloaded | Free capacity or add a host, re-download an incomplete bundle from the depot |
Run the prechecks, in the order I use
I run prechecks twice: once a few days before the window as a dry run, and again at the start of the window. The first run finds the slow fixes, things like a DNS record request that has to go through another team or a certificate rotation that needs approval. The second run confirms nothing drifted since. Here is the loop I follow for each run.
Fixing what it flags
Expired passwords and certificates
This is the single most common failure I see, and it is almost always a service account password that expired quietly weeks ago. The fix is to reset it and, importantly, update it wherever VCF stores it so the platform can use it during the upgrade. Certificates are the same story: a cert that expires next week will pass a casual look but fail a precheck that knows the upgrade might run past that date. Rotate anything expiring inside your window plus a buffer.
A stale vSAN HCL database
If you run vSAN, the precheck wants a current hardware compatibility database so it can validate your controllers and firmware against the target release. On an environment without internet access this database goes stale, and the check fails for a reason that has nothing to do with your actual hardware. Update the HCL database, online or with the offline file, then re-run. It is a two minute fix that people burn an hour on because the error text does not scream the obvious.
Missing or failed backups
The precheck wants a recent successful SDDC Manager backup on an external SFTP target, not a local one. If your backup has been silently failing, this is where you find out, and it is a good place to find out. Fix the SFTP target or credentials, run a backup on demand, confirm it landed, then continue.
DNS and the new CIDR block
This one is specific to 9.1 and it catches people because the work sits outside VCF. The Management Services cluster needs a fresh block of IPs on the management VLAN, defined in CIDR format, so you must hand it at least a /28 that yields 14 usable addresses. A /27 with 30 usable addresses gives you room to grow. You cannot reuse your 9.0.2 addresses, because the old components stay online orchestrating the upgrade while the new cluster comes up, and reused IPs collide mid-upgrade. Alongside the subnet, create forward and reverse DNS records for the new service names before you launch the wizard. The Management Services precheck tests both, and it will not deploy if either is missing.
Capacity and a host that cannot evacuate
The precheck also looks at whether a cluster can actually evacuate a host during the rolling upgrade. Each ESX host has to enter maintenance mode, which means DRS needs somewhere to put its workloads and, on vSAN, the cluster needs enough free capacity and enough fault domains to stay compliant while a host is down. If a cluster is packed tight or a host is already offline, the check flags it, and the honest fix is to free capacity or add a host rather than to force the upgrade and hope DRS sorts it out. I have watched a cluster that was fine at rest fail this check because one host had been sitting in a half finished maintenance task for a week, so the effective capacity was lower than the dashboard implied. Clear the stuck task, confirm the cluster can lose one host cleanly, then re-run.
A worked example
On a recent 9.0.2 to 9.1 job the prerequisite check came back with one red line: a certificate validity failure on a component that, on paper, had a cert good for another two months. The upgrade window was scheduled to run overnight and finish the next morning, so two months of validity should have been fine. It was not the leaf cert. The failing item was an intermediate in the chain that expired in nine days, and the precheck flagged the whole chain as at risk because a long running task could outlast it. We rotated the intermediate, re-imported the chain, re-ran the precheck, and the red line cleared in one pass. Total cost, about twenty minutes on the dry run three days earlier. Had we found it at the start of the window, we would have either burned the window on a cert rotation and change approval or, worse, pushed on and risked a service failing to reconnect after a restart.
Readiness before the window
Prechecks tell you if you are ready. Readiness is the work you do so they pass on the first try. Here is the schedule I run against, with who usually owns each item so nothing waits on the wrong person during the window.
| Readiness item | When | Owner |
|---|---|---|
| Route the new /28 or /27 and create service DNS records | T minus 1 week | Network team |
| Reserve a free temporary vCenter IP on the same subnet | T minus 1 week | Network and VCF admin |
| Rotate certs and reset any expiring passwords | T minus 3 days | VCF admin |
| Update the vSAN HCL database | T minus 3 days | VCF admin |
| Run and confirm an external SFTP backup | T minus 1 day | VCF admin |
| Download all upgrade bundles from the depot | T minus 1 day | VCF admin |
| Dry run precheck, fix everything red | T minus 2 to 3 days | VCF admin |
| Final precheck at the start of the window | T zero | VCF admin |
Signs it worked
You know readiness is real when the final precheck at T zero comes back with no red items and only warnings you already understand from the dry run, when the Management Services precheck passes the CIDR and DNS test on the first attempt, and when your backup and bundle downloads are both confirmed before the clock starts. If the T zero run surprises you with something new, stop and understand it. A fresh red line at the start of the window means something drifted, and drift is worth ten minutes of investigation before you commit.
Common questions
Can I skip prechecks if the environment is healthy?
No. The precheck knows things you do not, like a cert that expires during a long running task or a bundle that downloaded only partway. It costs minutes and it has saved me from real incidents more than once. Run it every time, even on a small environment.
What is the difference between a warning and a failure?
A failure blocks the upgrade until you fix it. A warning lets you proceed but is telling you about a risk. I treat warnings as things to read carefully, because some of them are future outages in polite language. If I do not understand a warning, I do not proceed until I do.
Why does the Management Services precheck fail when everything else is green?
Because it tests work that lives outside VCF: a routed subnet and DNS records your network and DNS teams create. The rest of the stack can be perfect and this check still fails if a reverse record is missing. Prepare the /28 and the records before you open the wizard.
Prechecks are the readiness step for what comes next: backups and a rollback plan before you touch anything, then the sequence itself. Part 6 covers backup and rollback in detail.
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)
- Upgrading VMware Cloud Foundation from 9.0.2 to 9.1: Practical Notes (Angry Admin)
About The Author
DrJha