How VCF 9.1 Consolidates the Management Plane into a Single Unified Platform
In this blog
The old world
If you have been managing a VMware Cloud Foundation environment for any length of time, you know the appliance sprawl that comes with it. Before VCF 9.1, keeping the lights on meant maintaining a collection of separate, purpose-built appliances, each with its own upgrade schedule, its own credentials, and its own way of breaking at the worst possible moment.
Here is what you were dealing with:
| Before (VCF 9.0.x) | After (VCF 9.1) |
| Fleet Management Appliance | Absorbed into VCF Management Services |
| Aria Suite Lifecycle | Absorbed into VCF Management Services |
| VMware Identity Manager | Absorbed into VCF Management Services |
| Aria Operations for Logs | Absorbed into VCF Management Services |
Four separate appliances. Four separate upgrade paths. Four separate failure domains. In VCF 9.1, all four are gone — decommissioned automatically as part of the upgrade process — and their functions are absorbed into a single unified platform called VCF Management Services.
What is VCF Management Services?
VCF Management Services is not just a rebrand. It is a fundamentally different architecture. Rather than running lifecycle and operational functions as standalone VMs, everything now runs as containerized services inside a Kubernetes-based runtime — the VCF Services Runtime — deployed on your VCF Instance infrastructure.
Think of VCF Management Services as the engine room of your VCF environment. You don't interact with it directly on a day-to-day basis, but it orchestrates everything from host upgrades to license management to identity brokering. The VCF Services Runtime provides the Kubernetes cluster that hosts all of these services, and it is managed through a dedicated vsp.local admin account — kept separate from your SSO domain for operational isolation.
| Key Point: VCF Management Services must always be deployed on a vSphere dvPortGroup — not an NSX segment. This is a hard constraint with no exceptions. |
Fleet-Level vs. Instance-Level: The Key Architectural Split
This is the concept that trips people up most often, so it is worth spending time here. VCF Management Services components are divided into two tiers based on their scope of responsibility.
Fleet-Level Components
Fleet-level components run only on the first VCF Instance — your management domain equivalent. They handle operations that span the entire VCF fleet, regardless of how many VCF Instances you have:
| Component | Scope | What It Does |
| Fleet Lifecycle Management | Fleet | Governs upgrades and lifecycle operations across all VCF Instances from a single control point |
| Salt RaaS (Run-as-a-Service) | Fleet | Centralized automation execution plane — coordinates configuration and automation tasks fleet-wide |
| Log Management | Fleet | Centralized log aggregation for all VCF Instances, replacing Aria Operations for Logs |
| License Server | Fleet | Manages the full license inventory for all VCF Instances. Replaces license management in VCF Operations |
Instance-Level Components
Instance-level components run on every VCF Instance, including the first. They handle operations specific to that instance:
| Component | Scope | What It Does |
| SDDC Lifecycle | Instance | Handles lifecycle operations for that specific VCF Instance — host onboarding, cluster expansion, etc. |
| Salt Master | Instance | Executes automation tasks locally on that instance |
| Identity Broker | Instance | Handles authentication federation for that instance — replacing VMware Identity Manager |
| Real-time Metrics | Instance | Collects and forwards performance data for that instance |
| Software Depot | Instance | Local software repository for that instance, used for host image management |
| Telemetry | Instance | Collects and forwards telemetry data upstream |
The practical implication: your first VCF Instance carries the full load — fleet-level plus its own instance-level components. Every additional VCF Instance carries only its instance-level components. This is why the /27 CIDR block requirement is larger for the first instance.
The License Server: How Licensing Changes in 9.1
One of the most operationally significant changes in VCF 9.1 is how licensing works. The License Server is a new fleet-level component that ships as part of VCF Management Services, and it becomes the single license authority for your entire VCF fleet.
Where Licenses Come From
Prior to 9.1, your VCF licenses lived in VCF Operations. When you upgrade VCF Operations to 9.1 and then deploy VCF Management Services, those licenses transfer from VCF Operations into the new License Server. The transfer happens in one of two ways:
- Connected mode: If your environment has connectivity to Broadcom's licensing backend, the license transfer is automatic. No manual steps required.
- Disconnected mode: For air-gapped environments, you manually register your licenses through the VCF Business Services console.
The Error You Will See — And Why It Is Normal
Here is something that catches administrators off guard during the upgrade. Between the moment you upgrade VCF Operations and the moment VCF Management Services is fully deployed and the license transfer completes, your environment will display this error:
| "Licenses could not be synchronized with vCenter instances" |
This is expected behavior — not a failure. It is simply the window where VCF Operations has been upgraded (and is no longer holding licenses) but the new License Server is not yet online. The error clears automatically once VCF Management Services is deployed and the license transfer completes. Do not attempt to troubleshoot it or roll back. Just continue the upgrade sequence.
The IP Address Tax: Budget This Before You Upgrade
If there is one thing that catches teams off guard during a VCF 9.1 upgrade, it is the IP address requirement. During the upgrade you have to deploy VCF Management Services — and that runtime layer is hungry for IPs.
VCF Services Runtime: The /27 CIDR Block
VCF Management Services needs a /27 CIDR block (30 usable addresses) on your management network. The SDDC Manager UI asks for CIDR format when upgrading from 9.0.x — which is different from a fresh VCF Installer deployment, which accepts an IP range. The practical effect: the smallest CIDR that meets the 12-address minimum is a /28, but Broadcom recommends a full /27 to leave room for Day-N service scale-out.
On top of that CIDR block, you need five FQDNs that resolve to IP addresses completely outside the range — each one dedicated and non-overlapping:
| Component | Scope | What It Does |
| VCF Services Runtime FQDN | Fleet + Instance | Control plane endpoint for the runtime cluster itself |
| Fleet Component FQDN | Fleet | Resolves to fleet lifecycle, Salt RaaS, and software depot |
| Instance Component FQDN | Instance | Resolves to SDDC lifecycle, Salt master, real-time metrics, metrics store, and telemetry |
| Identity Broker FQDN | Fleet | Skipped if VCF Identity Broker 9.0.x is already deployed — upgrade it separately afterward |
| License Server FQDN | Fleet | Note: license server is IPv4-only, even in dual-stack environments |
| Internal CIDR conflict to check: VCF Services Runtime uses 198.18.0.0/15 as its internal pod network by default. If anything on your network already uses that range, you must override it to 240.0.0.0/15 or 250.0.0.0/15 before deployment — this cannot be changed after the fact. |
VCF Automation Needs Its Own CIDR Too
Separately from the VCF Management Services /27, VCF Automation 9.1 requires its own dedicated /29 subnet (5 usable IPs) for the VCF Automation nodes on the runtime cluster. IP addresses for this block must reside on the same network where your current Automation nodes are deployed. You also need an additional FQDN for the VCF Services Runtime instance hosting Automation — resolving to an IP outside that /29.
The takeaway: before you schedule your upgrade window, coordinate with your network team to carve out a /27 on the management network, a /29 for VCF Automation, and have five pre-registered FQDNs ready in DNS. IP planning is the longest lead-time item in the whole upgrade — not the upgrade itself.
What Actually Lands on VCF Management Services
When the upgrade of your first VCF Instance completes, the following services are running on the runtime cluster:
| Component | Scope | What It Does |
| VCF Services Runtime | Fleet | The Kubernetes-based host layer — the container platform everything else runs on top of |
| Fleet Lifecycle | Fleet | Lifecycle management for fleet-level components across all VCF Instances |
| Software Depot | Fleet | Centralized binary repository replacing the per-instance SDDC Manager depot |
| Salt RaaS | Fleet | Remote access and automation framework, fleet-wide |
| License Server | Fleet | Single license authority for all VCF Instances — replaces licensing in VCF Operations |
| SDDC Lifecycle | Instance | Manages lifecycle for the specific VCF Instance |
| Salt Master | Instance | Instance-level configuration management and automation |
| Real-Time Metrics / Metrics Store | Instance | Infrastructure telemetry collection for the instance |
| Telemetry | Instance | Usage and diagnostics data for the instance |
| Identity Broker | Fleet | Authentication and identity brokering — deployed if not already present |
For every additional VCF Instance in your fleet, only VCF Services Runtime, Salt master, and SDDC lifecycle are deployed — the fleet-level components (fleet lifecycle, Salt RaaS, software depot, license server) are shared from the first instance.
What This Means for Your Upgrade
Understanding this architecture shift is not just academic — it directly affects how you plan and sequence your VCF 9.0.x to 9.1 upgrade. A few things to keep front of mind:
- Cloud Proxy is a hard gate. If you have VCF Operations collectors but no Cloud Proxy deployed, you cannot upgrade to 9.1. Collectors and Cloud Proxy are separate components — having one does not satisfy the requirement for the other.
- Identity Broker must be on the management network. If you are running Identity Broker in appliance mode on an NSX overlay segment, it must be migrated to the management network before upgrading to 9.1.
- The Fleet Management Appliance decommissions itself. You do not manually remove it. The VCF Operations 9.1 upgrade handles the decommission automatically. Do not try to clean it up yourself before upgrading.
- IP planning needs to happen first. A /27 CIDR for VCF Services Runtime, a /29 for VCF Automation, and five pre-registered FQDNs must all be ready before the upgrade starts. See the IP Address Tax section above for the full breakdown.
- License transfer happens at Step 4. In the upgrade sequence, VCF Management Services is deployed immediately after VCF Operations is upgraded — that is when licenses transfer. This is step 4 in the upgrade order, not the last step.
The Bottom Line
VCF 9.1's consolidation of four separate appliances into VCF Management Services is not just a cleanup exercise — it is a meaningful architectural improvement. A unified runtime means a unified upgrade path, centralized observability, and a single platform to operate and troubleshoot instead of four.
For customers running VCF 9.0.x, the upgrade is worth the planning effort. The pre-upgrade checklist is real — Cloud Proxy, Identity Broker network placement, CIDR allocation, and Single Image compliance all need to be verified before you start. But once you are through it, the operational simplicity on the other side is a genuine improvement.
WWT has deep experience in VCF architecture, design, and upgrades. If your team is planning a move to VCF 9.1 and wants to walk through the readiness checklist, architecture design, or upgrade sequencing with an experienced team, reach out — we have done this before.