TL;DR · Key Takeaways
- In 9.1 licensing leaves VCF Operations and moves to its own VCF License Server, which comes up with VCF Management Services before you upgrade any core component.
- After the license server is live, confirm every vCenter is bound to it. A vCenter that shows "not connected to a license server" will block later steps, and it is a five minute fix if you catch it now.
- Upgrade the NSX Advanced Load Balancer (Avi) before SDDC Manager builds the plan. Avi 22.1.6 is not in the 9.1 bill of materials and it will stop the plan from starting.
- Standalone Site Recovery Manager and vSphere Replication are deprecated in 9.1. They fold into one VMware Live Recovery appliance, now called VCF Protection and Recovery, and it stays licensed separately.
- Move to Enhanced vSphere Replication first, or the combined Live Recovery appliance will refuse to install.
- Worked example below: three vCenters, one unlicensed, Avi stuck at 22.1.6, and roughly a three hour window to clear both before the core plan.
By the time I reach this point in a real upgrade, VCF Operations is on 9.1 and VCF Management Services is deployed. The core plan for NSX, vCenter and ESX is right there, and it is tempting to press start. I have learned to stop here first, because three things sit slightly off the main path and every one of them can stall the plan later.
Those three are the new license server, the Avi load balancer, and whatever disaster recovery pairing you run. None of them upgrade themselves inside the core workflow, so this part is about getting them right before I let SDDC Manager touch the management domain. I will show you the order I actually use and a worked example from a fleet with three vCenters.
Where these components fit in the sequence
The 9.1 sequence starts with VCF Operations, then SDDC Manager, then VCF Management Services, then the core components. The license server rides in with Management Services, so it is technically already there when you land on this step. The two dependency components, Avi and Live Recovery, are not in that chain at all. They live on the side, and SDDC Manager checks them when it builds a plan.
The VCF 9.1 license server
What changed from 9.0
In 9.0, license keys lived inside VCF Operations. In 9.1 that job moves to a dedicated appliance, the centralized VCF License Server. It is a required component for both VCF and vSphere Foundation, and it is where every vCenter now goes to check out its entitlement. You do not deploy it by hand as a separate wizard. It instantiates as part of the VCF Management Services deployment you completed in Part 9.
The practical effect is that a component you never used to think about is now a hard dependency for licensing every vCenter in the fleet. If it is unhealthy, vCenters drift out of compliance and later upgrade steps get unhappy.
There is a second thing worth saying plainly. The license server is small, but it is not optional and it is not something you bolt on later. Because it comes up with Management Services, its health is tied to the health of that cluster. If Management Services had a rough deployment in Part 9, the first symptom you notice may actually be a licensing one, a vCenter that cannot reach the server or times out asking for an entitlement. Check the Management Services cluster status before you blame the keys.
Connecting it and checking every vCenter
Once Management Services finishes, add your VCF and vSphere keys to the license server and confirm each vCenter is pointed at it. Do not assume the migration carried every assignment over cleanly. Open the licensing view and look for any vCenter that reports it is not connected to a license server, because that message is the one that comes back to bite you two steps later.
| Aspect | VCF 9.0 | VCF 9.1 |
|---|---|---|
| Where keys live | Inside VCF Operations | Dedicated license server |
| How it deploys | Part of Operations | With Management Services |
| Required | Yes | Yes, for VCF and vSphere Foundation |
| Common failure | Key not applied | vCenter not connected to a license server |
NSX Advanced Load Balancer, upgrade it before the plan
Why an old Avi version stops the plan
If you run the NSX Advanced Load Balancer, its version has to be in the 9.1 bill of materials before SDDC Manager will build an upgrade plan. A common blocker is Avi 22.1.6, which is not compatible with the 9.1 bill of materials. SDDC Manager sees it, flags the incompatibility, and will not let the plan start. This is one of the components people forget, because Avi upgrades on its own track and not inside the core VCF workflow.
Check the interoperability matrix for the version that pairs with your 9.1 target, then upgrade Avi first. The 9.1 bill of materials calls for Avi Load Balancer 32.1.1, so teams on the 22.1.x line move up to that 32.1.x build. Confirm the exact compatible version for your fleet in the matrix before you commit, since the validated build shifts as new patches land.
Order across workload domains
One Avi controller cluster often fronts services across more than one workload domain. That matters for order. You upgrade the Avi controllers once, centrally, and the service engines follow, but the load balancing those engines provide is in use by tenant workloads that may not be part of this maintenance window at all. So before you touch Avi, list which virtual services depend on it and who owns them. I have seen an Avi upgrade run cleanly on the infrastructure side while a tenant team spent an hour wondering why a health check blipped, purely because nobody told them.
The compatibility gate itself is version based, not domain based. SDDC Manager checks the Avi version against the bill of materials for the target you selected, and if it does not match, the plan for that domain will not build. Getting the controllers onto a compatible build once clears the gate for every domain the controllers serve, which is why doing Avi early and centrally pays off.
Doing the Avi upgrade safely
VMware Live Recovery, formerly SRM and vSphere Replication
If you protect the management domain or workloads with Site Recovery Manager and vSphere Replication, 9.1 changes the shape of that pairing. The standalone SRM and vSphere Replication appliances are deprecated in 9.1. They collapse into a single VMware Live Recovery appliance, which in the VCF context is now called VCF Protection and Recovery. It stays licensed as an advanced service, separate from your core VCF entitlement.
Enhanced vSphere Replication comes first
There is an order trap here. A site running an older vSphere Replication build must move to Enhanced vSphere Replication before the combined Live Recovery appliance will install. Enhanced replication is the default and only supported site to site configuration in this release. Skip that step and the new appliance install stops. Do this on both sides of a protected pair, not just the primary.
The transition, step by step
The rough shape of the move is: get both sites onto a current vSphere Replication build, convert to Enhanced vSphere Replication, then deploy the combined VCF Protection and Recovery appliance and re-establish your protection groups and recovery plans against it. Your existing replications are not thrown away, but you do validate them after the cutover rather than assuming they carried across untouched. Test a recovery plan on a non critical group before you trust it for the workloads that matter.
One reason this release is worth the effort is the addition of cyber recovery workflows that can recover from vSAN snapshots, alongside more flexible replication topologies than the old one to one pairing allowed. That is a real capability gain, but it does not change the order. You still get onto Enhanced vSphere Replication first, and you still license it separately.
Walking the worked example
Here is the fleet I have been referring to, laid out end to end. Three vCenters, one management domain and two workload domains, with a single Avi controller cluster fronting virtual services in both workload domains, and an SRM plus vSphere Replication pairing protecting the management domain to a second site. Management Services and the license server are already deployed from Part 9.
First pass at licensing showed two of the three vCenters bound to the license server and the third reporting it was not connected. That third one carried a stale entitlement from the old model. I assigned its key by hand and it went green in about five minutes. Next, the Avi controllers were on 22.1.6, so any plan I tried to build failed the compatibility check immediately. I upgraded the controllers to a matrix compatible 32.1.1 build in roughly ninety minutes, service engines following the controllers, and the plan then built without the Avi error. Last, I kicked off the Live Recovery transition as its own workstream rather than pulling it into the same window. The whole pre plan block came to about three hours, and only after all three cleared did I let SDDC Manager start on the management domain.
The order I would actually use
My real order for this step is licensing, then Avi, then Live Recovery. I settle licensing first because it is quick and because an unlicensed vCenter breaks the core plan that comes right after. Avi is next because it is the hard gate on the plan itself. Live Recovery is last of the three, since it protects workloads rather than blocking the management upgrade, so I can run it slightly behind the others without holding up SDDC Manager.
What I would skip: I do not try to fold the Live Recovery transition into the same maintenance window as the core plan on a busy site. It has its own replication seeding and its own testing, and jamming it in adds risk for no real time saving. I would rather run it as its own workstream a day on either side.
| Component | Current | Target | Rough time | Blocks core plan? |
|---|---|---|---|---|
| License server | Keys in Operations | Dedicated server, 3 of 3 bound | ~30 min | Yes, indirectly |
| NSX Advanced Load Balancer | 22.1.6 | Matrix compatible 32.1.1 | ~90 min | Yes, directly |
| Live Recovery | SRM plus vSphere Replication | VCF Protection and Recovery | Own workstream | No |
Common questions
Do I have to deploy the license server by hand?
No. It comes up as part of VCF Management Services. Your job is to add keys and confirm every vCenter is bound to it, not to run a separate deployment wizard.
What if I do not run the NSX Advanced Load Balancer at all?
Then this gate does not apply and you can skip the Avi step. If you do run it, treat the version check as mandatory, because an out of date Avi will stop SDDC Manager from building the plan.
Can I upgrade Avi during the core plan instead of before?
No. The plan will not build while Avi sits on an incompatible version such as 22.1.6. Get it onto a matrix compatible build first, then let SDDC Manager plan the core components.
My SRM is on an old vSphere Replication build. What breaks?
The combined VMware Live Recovery appliance will not install until you move to Enhanced vSphere Replication. Do that on both sides of every protected pair before you try the new appliance.
Is Live Recovery covered by my VCF license?
No. It is an advanced service and stays licensed separately, so confirm you hold the entitlement before you plan the transition.
References
- Upgrade Sequence and Related Issues for VCF and vSphere Foundation 9.1 (Broadcom KB 440630)
- How to Upgrade to VMware Cloud Foundation 9.1 (VCF Blog)
- SDDC Manager Blocked from Plan Upgrade Due to NSX Advanced Load Balancer Incompatibility (Broadcom KB 443599)
- Unable to License vCenter After Upgrading to 9.1, vCenter Not Connected to a License Server (Broadcom KB 440471)
- Licenses Could Not Be Assigned to vCenters, License Assignment Failure on VCF 9.1 (Broadcom KB 424533)
About The Author
DrJha