By the time you reach this step, VCF Operations and SDDC Manager are already at 9.1 in your first VCF instance. This part is the piece a lot of admins have never done before, because it did not exist in 9.0. You deploy VCF Management Services, the container cluster that now owns fleet lifecycle, SDDC lifecycle, the software depot and the license server.

I will walk through what actually gets deployed, the IP and FQDN plan you need ready before you open the wizard, the deploy steps, the fleet management migration that happens if you came from 9.0.x, and how to wire up the fleet-level software depot afterward so the rest of the upgrade has binaries to pull.

Where this fits in the upgrade

The sequence to this point went VCF Operations first, then SDDC Manager, both to 9.1. VCF Management Services is the gate between the management stack being at 9.1 and the rest of the domain following. Until this cluster is up, you cannot upgrade NSX, vCenter or ESX, because the lifecycle engine and the depot they pull from live inside it.

VCF Operations is the control point. You register the new components against it, and it hosts the workflow that installs them. SDDC Manager keeps driving domain upgrades, but from 9.1 it takes its lifecycle instructions from the services running in this cluster.

What VCF Management Services actually is

In 9.0, fleet management ran as part of VCF Operations. In 9.1 that work moves into a dedicated container cluster with its own runtime, its own IP range and its own FQDNs. The cluster is mandatory, and it carries the pieces the rest of the upgrade depends on.

The components inside the cluster

The wizard groups the components under two FQDNs. The fleet component FQDN covers fleet lifecycle, Salt RaaS and the software depot. The instance component FQDN covers SDDC lifecycle, Salt master, real-time metrics, the metrics store and telemetry. The license server and identity broker each get their own FQDN.

First instance versus later instances

The fleet-level pieces (fleet lifecycle, software depot, license server, Salt RaaS) only deploy once, on the first VCF instance that hosts VCF Operations. When you later upgrade other instances in the same fleet, the wizard only stands up VCF services runtime, Salt master and SDDC lifecycle, because the fleet components already exist. If you plan for a full deployment on every instance, you will over-allocate IPs on the later ones.

The IP and FQDN plan you need before the wizard

This is where most first attempts stall. The wizard asks for a CIDR block for the runtime, a /28 at the floor and a /27 if you want room to grow, and it asks for FQDNs that must resolve to addresses outside that block. If DNS is not already in place, you cannot finish the wizard, and you find out at the worst possible moment.

A /28 gives you 14 usable addresses and the runtime needs 12 of them, which leaves almost nothing spare, so I reserve a /27 and its 30 usable addresses whenever the subnet has room. The runtime nodes need at least 12 addresses either way. On top of the block you need five more addresses, each with forward and reverse DNS, for the runtime FQDN, the fleet component FQDN, the instance component FQDN, the identity broker FQDN and the license server FQDN.

What each component is, and what to reserve

It helps to see the new components as a list before you open the wizard, because each one needs its own reservation. The runtime consumes the CIDR block, and the other four each need a single FQDN with forward and reverse DNS. Here is what you are reserving and why.

Which network they land on

Deploy VCF Management Services and the license server on your VCF Management Network. If you don’t run a dedicated VCF Management Network, they can go on the VM Management Network instead. Keep them on the same routed segment as the runtime CIDR block so the runtime and the FQDN addresses can reach each other without extra routing.

The push toward a /27 isn’t padding for its own sake. The spare addresses are held for future VCF management service components and for scaling the services you already run. A /28 that just barely fits today turns into a blocker the first time the platform grows, so I size up when the subnet allows it.

Deploy it, step by step

The whole thing runs from VCF Operations, not from SDDC Manager. Confirm the prerequisites first: ports open, certificates using the correct FQDNs, VCF Operations and SDDC Manager both at 9.1, the component binaries already downloaded into the depot, and a cloud proxy present in the first VCF instance. If there is no cloud proxy, deploy one before you go further, because the integration between VCF Operations, SDDC Manager and the new cluster relies on it.

The wizard path

Log in to VCF Operations and click Build in the top navigation bar. In the left pane go to Lifecycle, expand VCF Instances and pick the instance that hosts VCF Operations. Open the SDDC Manager Updates tab, then the Available Upgrades tab. In the Next steps section, click Install Components.

In the Components Installation dialog, enter the VCF Operations FQDN, the administrator username and password, then click Connect. Once it connects, fill in the /27 CIDR block, the runtime FQDN, the fleet component FQDN, the instance component FQDN, the runtime password, and the identity broker and license server FQDNs where prompted. Click Install and let it run.

What happens to fleet management if you came from 9.0.x

If you are upgrading from 9.0.x, the fleet management that used to live inside VCF Operations moves into the new cluster during this step. The workflow transfers the fleet data, and once the transfer completes, the old fleet management appliance is decommissioned and shut down. You do not remove it by hand, and you should not restart it afterward.

Configure the fleet-level software depot

There are two depot ideas at play, and mixing them up causes confusion. The first is the depot you used to pull the management services binaries before the wizard. The second is the fleet-level software depot that the new software depot component now runs. After deployment you configure that fleet-level depot, and the remaining upgrades (NSX, vCenter, ESX) pull their binaries from it.

Online or offline

If your SDDC Manager has internet access, point the depot at the online source with your Broadcom credentials and download the 9.1 bundles you need. If it does not, use the VCF Download Tool to pull the bundles to an offline depot or directly to SDDC Manager, then point the fleet depot at that location. Either way, finish the depot config and confirm the bundles are present before you start the next component upgrade. A domain upgrade that cannot find its binaries fails the precheck.

A worked example

Say you are upgrading a single management domain from 9.0.2. You carve out 10.50.12.0/27 for the runtime, which gives 30 usable addresses, and the runtime takes 12 of them. Then you register five FQDNs in DNS, all lowercase, each pointing at an address outside that /27. Here is the plan I would hand to whoever owns DNS.

How long it takes

These are field estimates from my own runs, not published figures, so treat them as planning numbers. Budget for the binary download and prereq checks up front, a cloud proxy deployment if you need one, the wizard itself, the fleet migration for a 9.0.x source, and the depot config afterward. On a healthy single-instance environment I plan for roughly two and a half to four hours end to end, with the wizard being the longest single block.

A deployment failure I have actually hit

On one run the wizard connected to VCF Operations fine, accepted the CIDR, and then failed partway through with an error that pointed at the fleet component. The cause was dull. One of the FQDNs had been created in DNS with a capital letter, because the person who added the record copied it from a design doc that used title case. The runtime and instance FQDNs resolved, the fleet one technically resolved too, but the deployment rejects any uppercase in these hostnames. We fixed the record, cleared the failed attempt, and reran. It went clean the second time.

The lesson I took from it is to validate the five FQDNs from a shell before you open the wizard, not inside it. Resolve each one forward and reverse, confirm the addresses are outside the /27, and eyeball every hostname for a stray capital. Two minutes of checking saves a failed deployment and a cleanup.

Certificates and ports are the other two

Beyond DNS, the two prerequisites that bite people are certificates and ports. The certificates on VCF Operations and SDDC Manager must use the correct FQDNs, because the new services register against them and a name mismatch stops the handshake. On ports, check the Broadcom ports and protocols list for the management services rather than assuming your existing 9.0 firewall rules cover them. The cluster introduces new listeners, and a blocked port shows up as a stalled install that is hard to read from the wizard alone.

Validate the depot before the next part

Once the fleet-level depot is configured, download at least one component bundle and confirm it lands. That single test tells you the depot component is healthy, the credentials work, and the path to the binaries is reachable. If the download fails now, you want to know before you start the dependency components in Part 10, not when a domain precheck stops on a missing bundle.

Common questions

Can I deploy VCF Management Services before SDDC Manager is at 9.1?
No. Both VCF Operations and SDDC Manager must already be at 9.1. The Install Components step lives on the SDDC Manager Updates tab and expects the 9.1 stack underneath it. Trying earlier will not present the workflow.

Do I need the full /27, or can I use a smaller block?
The wizard asks for a /27. The runtime needs at least 12 addresses, and the extra headroom in the block is there for later scale-out and additional runtime nodes. Give it the /27 rather than trying to trim it.

What if I already run VCF Identity Broker 9.0.x?
Then the wizard skips the identity broker deployment, and you upgrade the broker separately afterward. An embedded identity broker is handled during the vCenter upgrade instead, so you do not deploy a new one here.

What deploys on my second and third VCF instances?
Only VCF services runtime, Salt master and SDDC lifecycle. The fleet-level components already exist from the first instance, so later instances need a smaller footprint and fewer IPs.

How do I retrieve the service account password afterward?
Use the VCF Management Services password retrieval procedure in the deployment troubleshooting docs. Do not try to reset it by hand on the appliances.

References

Broadcom TechDocs: Deploy VCF Management Services and License Server as Part of Upgrade to 9.1
Broadcom TechDocs: VCF Management Appliances
VCF Blog: How to Upgrade to VMware Cloud Foundation 9.1
Broadcom TechDocs: Binary Management for VMware Cloud Foundation
Related on this site: VCF 9.0 vs 9.1

About The Author

Dr. Pranay Jha

Dr. Pranay Jha is a Cloud and AI Consultant with 18+ years of experience in hybrid cloud, virtualization, and enterprise infrastructure transformation. He specializes in VMware technologies, multi-cloud strategy, and Generative AI solutions. He holds a PhD in Computer Applications with research focused on Cloud and AI, has published multiple research papers, and has been a VMware vExpert since 2016 and a VMUG Community Leader.

See author's posts