If you've spent years building vCenter, then vSAN, then NSX, then adding Aria Operations and Aria Automation one appliance at a time, VCF 9 can feel complex, but it's actually designed to simplify things for you. This post explains what VMware Cloud Foundation is today, how the pieces fit together and what actually changes in your week.
It's based on the VCF 9.1 documentation on Broadcom TechDocs. The current release is VCF 9.1.1, which went GA on 3 September 2026 and has had component patches since. VCF 9.1.0 shipped in May 2026.
What is VCF?
Broadcom describes VCF as "a full-stack IaaS platform that delivers software-defined compute, storage, networking, security, and management", with integrated automation so application teams can self-serve VMs and containers.
For you as an admin, VCF is no longer a bundle of products that happen to share a licence. It's one platform with one bill of materials, one installer and one operations console, made up of the VCF Installer, vSphere, vSAN, NSX, VCF Operations and VCF Automation.
You'll also notice the docs now say ESX rather than ESXi.
Why it's now the main platform
Broadcom has cut the portfolio down to two main offerings, VMware Cloud Foundation and VMware vSphere Foundation.
VCF is one platform, not component-by-component anymore
The old way felt like simple building blocks, but in reality it was more complex. You deployed vCenter from its ISO, built clusters, enabled vSAN, deployed NSX Managers from an OVA, then Aria Suite Lifecycle, then Aria Operations, Aria Operations for Logs and Aria Automation. Each one had its own upgrade schedule and its own compatibility checks.
A simple way to think about it: the old model is building a house by hiring every trade yourself. VCF is buying from a builder with a fixed plan and a site manager who knows the order.
VCF 9 changes that, and the docs are fairly blunt about it. From version 9, you install most components through the VCF Installer and VCF Operations workflows, and "deployment of standalone components by deploying an OVA is typically not supported", apart from specific cases where the docs tell you to.
Here's how the old components map to VCF 9.1, based on the component comparison in the 9.1 docs:
| Area | Old model (separate components) | VCF 9.1 |
|---|---|---|
| Initial deployment | vCenter, vSAN, NSX and each Aria product deployed and wired up by hand | VCF Installer deploys the management domain and fleet components from one plan or JSON spec |
| Bring-up tool | Cloud Builder (VCF 5.x) or nothing at all | VCF Installer |
| Monitoring | Aria Operations | VCF Operations |
| Logs | Aria Operations for Logs | Log management (a VCF management service) |
| Network insight | Aria Operations for Networks | VCF Operations for networks |
| Self-service | Aria Automation (and Cloud Director for providers) | VCF Automation |
| Lifecycle of the management tools | Aria Suite Lifecycle | Fleet lifecycle and SDDC lifecycle (VCF management services) |
| Lifecycle of ESX, vCenter, NSX | Per product, checked against the interoperability matrix by you | SDDC Manager capabilities, driven from VCF Operations |
| Single sign-on | Workspace ONE Access | Identity broker |
| Kubernetes | vSphere with Tanzu / IaaS Control Plane | vSphere Supervisor |
| Licensing | Keys per product | License server, part of VCF Operations |
VCF Installer vs SDDC Manager
This is the part that catches most people out. The VCF Installer and SDDC Manager are the same appliance, shipped as VCF-SDDC-Manager-Appliance-9.x.x.ova, and what it becomes depends on where you deploy it.
VCF Installer mode. If you deploy the appliance on an ESX host that isn't part of the management domain for the target deployment, it stays in installer mode after the deployment completes. You can then use it to deploy more VCF Instances and run convergence workflows.
SDDC Manager mode. If you deploy it on a host that will be part of the management domain, it switches to SDDC Manager mode during the deployment, and from then on it can't work as an installer. Broadcom's best practice is to deploy it on a local datastore, and the appliance moves to the primary datastore during the workflow. With FC storage, you can deploy it on the FC datastore from the start.
The installer downloads the binaries (or uses an offline depot), plans the deployment, deploys a new fleet, instance or VVF platform, and runs convergence. It works with major, minor and maintenance releases, but not patch releases, so you apply patches afterwards.
SDDC Manager is still there after bring-up, one per VCF Instance. The 9.1 docs describe it as "a part of VCF Operations" that provides lifecycle management for ESX, vCenter, HCX and NSX, deployment of workload domains, import of existing vCenter instances as workload domains and vSAN stretched cluster configuration. The practical difference is that you now drive most of that from VCF Operations.
What are VCF fleets, instances and domains?
VCF 9 uses three nested constructs.
VCF domain. One vCenter, one or more vSphere clusters with HA and DRS, NSX (either dedicated or shared with other domains) and principal storage. It's the closest thing to the vCenter-managed environment you know today.
- The management domain is created by the VCF Installer. It runs the management components: vCenter, NSX and SDDC Manager for the instance and, in the first instance, VCF Operations, VCF Automation, the license server and the VCF management services.
- Workload domains run your actual workloads. You create them in VCF Operations, and each one gets its own vCenter. A new workload domain can share an NSX Manager cluster with another domain or have its own.
VCF Instance. One management domain plus any workload domains. Each instance has its own SDDC Manager.
VCF fleet. Everything managed by a single set of VCF Operations and VCF Automation. A fleet holds one or more VCF Instances, and it can also include standalone vCenter instances that VCF Operations manages. The fleet components run in the management domain of the first VCF Instance.
VCF private cloud. The top level, made up of one or more fleets.
Here's an example. A company has data centres in London and Manchester. London is the first VCF Instance, so its management domain runs London's vCenter, NSX and SDDC Manager, plus VCF Operations and VCF Automation for everything. It has two workload domains: one for production, and one for a business unit that wants its own vCenter. Manchester is a second instance, with its own management domain and one workload domain. Both sit under the same VCF Operations and VCF Automation, which is what makes them one fleet.
What happened to Aria Operations and Automation?
Aria didn't disappear. It was folded into VCF and renamed, as in the table above. Two names changed again between 9.0 and 9.1. Aria Operations for Logs was VCF Operations for logs in 9.0 and is now log management. Aria Suite Lifecycle was VCF Operations fleet management in 9.0 and is now fleet lifecycle and SDDC lifecycle. VCF Automation also takes over from VMware Cloud Director.
VCF Operations is also much more than monitoring now. The docs say it helps you "build, manage, operate, and secure" the private cloud, including deploying and maintaining the fleet-level components.
VCF Automation lives at the fleet level
VCF Automation is now responsible for self-service. A provider administrator creates organisations in the Provider Management UI, and each organisation gets its own UI and its own identity source. There are two types:
- All Apps organisations get a full set of built-in cloud services: VMs, Kubernetes, networking, volumes, databases, Harbor registries, DNS, certificates and AI workloads.
- VM Apps organisations run VM-based applications without needing a Supervisor. The docs point Aria Automation customers here so they can carry on with minimal disruption.
If you're upgrading from Aria Automation 8.18 with multiple tenants, those tenants show up as separate VM Apps organisations.
Mandatory vs optional components
This table follows the VCF Installer deployment scope for VCF 9.1. Simple and High Availability are the two deployment models, and HA mostly adds extra nodes, such as three NSX Managers instead of one.
| Component | At VCF 9.1 bring-up | Notes |
|---|---|---|
| ESX hosts | Required | You image the hosts before you start |
| vCenter | Required | One per domain |
| NSX Manager | Required | One node in Simple, three in HA |
| Principal storage | Required | For a new management domain: vSAN ESA or OSA, Fibre Channel (VMFS) or NFSv3 |
| SDDC Manager | Required | One per VCF Instance |
| VCF Operations, cloud proxy and license server | Required | Replica and data nodes only in HA |
| VCF management services | Required | Services runtime, fleet lifecycle, SDDC lifecycle, software depot, identity broker, Salt RaaS, Salt master and telemetry |
| VCF Automation | Deployed by default, can be skipped | You can deploy it later as a Day-N operation |
| NSX Edge | Optional | Added after you create a workload domain |
| VCF Operations for networks | Optional, after bring-up | Deployed from VCF Operations |
| Log management and real-time metrics | Optional, after bring-up | VCF management services, Day-N |
| VCF Operations orchestrator | Optional, after bring-up | Deployed manually |
| VCF Operations HCX | Optional, after bring-up | For workload migration |
iSCSI, NFSv4.1 and NVMe over Fabrics can also be principal storage, but only when you converge existing infrastructure or import a vCenter as a workload domain, not in a fresh installer build. KB 416270 explains how. Bear in mind that the storage model comparison only ticks "Automated LCM, Patching, and Upgrades" for vSAN.
Greenfield, brownfield and convergence
There are three ways to deploy VCF 9.1: deploy a new fleet or instance (greenfield), converge existing vSphere infrastructure (brownfield), or upgrade an existing VCF 5.2.x or 9.0.x environment.
Convergence is the one most readers of this blog will care about. When you converge, your existing vCenter and hosts become the management domain of a new VCF Instance, in a new or existing fleet. Broadcom documents scenarios that start from vCenter and ESX only, or that add vSAN, NSX, Aria Operations and Aria Automation in different combinations.
Know these rules before you plan:
- Convergence covers the management domain only. You import any other vCenter instances later, as workload domains, through VCF Operations.
- The component with the earliest version sets the effective VCF version for the instance.
- Upgrades only go forward. The target has to be released after your current version, so 5.2.4 can't go to 9.1.0, but it can go to 9.1.1.
If you're on vSphere 8 with Aria Operations 8 and aren't ready for the full stack, there's a documented path to upgrade those to 9.1 without deploying everything.
What actually changes day to day
Deployment
Instead of a build sheet for each product, you fill in one plan in the VCF Installer (or a JSON spec, or the Planning and Preparation Workbook), and it deploys the lot. You create new workload domains from VCF Operations, rather than building a vCenter by hand.
Patching and lifecycle
This is the biggest change. The lifecycle chapter in the 9.1 docs opens with "Use VCF Operations to upgrade or patch VCF components". You load the binaries into the software depot first, then build an upgrade plan.
A few things to know:
- For a major or minor upgrade, the fleet-level components and the management domain go first. Workload domains can follow later as a Day-N task.
- Maintenance and patch releases don't need a strict order unless the release notes say so. 9.1.1 does: fleet lifecycle goes first, and you can't patch VCF Operations at the same time as anything else.
- If an NSX instance is shared across domains, you upgrade NSX, vCenter and ESX in every domain that shares it.
- The Component Versions tab in VCF Operations flags version drift per domain.
9.1 also adds ESX live patching for TPM-enabled hosts. Broadcom says eligible patches go on while VMs keep running, with no maintenance window, and that up to 80% of ESX patches will be live patch enabled. That's Broadcom's figure, so test it in a lab before you plan around it.
Self-service
In the old model, self-service was a separate Aria Automation project. In VCF it's part of the platform, and your role shifts towards being a provider. You hand capacity to organisations, and their admins split it between projects with quotas and policies.
Operations
Certificate, password and configuration drift management are all VCF Operations features now, and the identity broker gives you single sign-on across the fleet.
VCF vs VVF
VVF is described as the core foundation for VCF. It includes vSphere, vSphere Kubernetes Service, VCF Operations and vSAN, plus log management, and the feature comparison says VVF customers use vLCM for lifecycle.
What VVF doesn't have:
- NSX (it isn't in the VVF deployment scope)
- VCF Automation (the docs say VVF "does not include the cloud management and integrated automation capabilities" of VCF)
- SDDC Manager, workload domains, and certificate and password management
- VCF Operations for networks
The vSAN entitlement is different too. VCF includes 1 TiB of raw vSAN capacity per licensed core, and VVF includes 0.25 TiB per core, with extra capacity available as an add-on.
VCF probably makes sense if you already run NSX or need overlay networking and VPCs, you want self-service for app teams or tenants, or you run several sites or vCenters and want one operations and lifecycle model. It's also the natural next step if you're on Aria Automation or VCF 5.2 today.
VVF is probably enough if you run a handful of clusters on VLAN-backed networking, your app teams raise tickets rather than self-serve, and you want monitoring and logs without the full management footprint.
One warning if you're thinking of VVF as a stepping stone: the docs say converging VVF 9.1 with deployed VCF management services to VCF 9.1 isn't supported. Check the current upgrade guidance before you plan around it.
Where to start
The biggest change in VCF 9 isn't a component. It's the order you do things in. You design the fleet, instance and domain layout first, then the installer and VCF Operations do the plumbing you used to do by hand. You get fewer appliances to babysit, but less freedom to deploy things your own way.
If you'd like to see it before you touch production, my VCF 9 lab series builds it on a single ESX host. Start with part 1 of the lab guide. I've also written up the best technical updates in VCF 9.
Resources
- VCF Taxonomy (VCF 9.1)
- VCF Installer Overview (VCF 9.1)
- Components in VCF and vSphere Foundation (VCF 9.1)
- Deploying a New VCF or vSphere Foundation Platform (VCF 9.1)
- Completing the Deployment of Your Platform (VCF 9.1)
- Paths to Building 9.1.x Environments
- Converging Existing Virtual Infrastructure to a VCF or a vSphere Foundation Platform (VCF 9.1)
- Lifecycle Management of VCF Components (VCF 9.1)
- Storage Models (VCF 9.1)
- What Is VMware Cloud Foundation? (VCF 9.1)
- What Is vSphere Foundation? (VCF 9.1)
- VCF Operations Overview and VCF Automation Overview
- Organization Management (VCF Automation 9.1) and Create a VCF Automation Organization for VM Applications
- VMware Cloud Foundation 9.1 Release Notes, What's New in 9.1, VCF 9.1.1.0 Release Notes and Patch Releases 9.1.1.x
- VMware Cloud Foundation 9.1.1 and VMware vSphere Foundation 9.1.1 Feature Comparison & Upgrade Paths
- Add-on Licenses Included in Your VCF or vSphere Foundation Subscription
- KB 416270: Supporting all Principal Storage Options in VMware Cloud Foundation 9
- KB 456708: Upcoming End of Service for vSphere 8, vSAN 8 and related products
Feedback
If you found this guide useful, subscribe to the mailing list or follow me on X and YouTube. You can contact me through any of these with issues or suggestions for this guide.
Questions? Email me (contact@virtualg.uk) or DM me on X (@virtualg_uk).