Deployment overview and component checklist
Pick the right path into VMware Cloud Foundation 9.1, see which components are mandatory and which are optional, and follow the guide product by product from bare metal to a validated fleet.
TL;DR · Key Takeaways
- There are three supported ways into VCF 9.1: a greenfield build with the VCF Installer, converging an existing vSphere estate into a new fleet, or importing a running vSphere, vSAN and NSX environment into an existing fleet.
- Greenfield builds a clean management domain from bare hosts. Converge and import reuse what you already run, with no application downtime and no data migration.
- Converge requires vSphere 8.0 Update 3 or later, and import requires vSphere 8.0 Update 3a or later. A domain that already runs NSX needs NSX 4.2 or later, whether you converge or import it.
- Every path validates forward and reverse DNS, NTP, and host FQDNs before it will start. Short names in the inventory will stop you.
- VCF 9.1 introduces VCF Management Services, a mandatory container cluster, so plan a fresh block of management IP addresses whichever path you take.
- Match your starting point to a path in the table below, then confirm the version floors before you download a single bundle.
Most people ask how to deploy VCF 9.1 before they have asked the more useful question, which is which of the three deployment paths their environment actually qualifies for. Pick the wrong one and you either rebuild hosts you did not need to touch, or you stall halfway through a converge because a guardrail you never read about refused to let the workflow continue. This series walks all of it end to end, but this first part is the map. Read it, decide your path, and the rest of the series follows the one you chose.
Here are the three roads into 9.1, who each one is for, the version floors that gate them, and a worked example of choosing between them for a mixed estate. If you are coming from an older release and want the in-place upgrade rather than a fresh deployment, that is a different project, and my VCF 9.1 Upgrade series covers it.
Three ways into VCF 9.1
Your starting point decides the path, not your preference. A rack of freshly imaged hosts wants a greenfield build. A running vSphere 8 estate you do not want to rebuild wants a converge or an import. The difference between converge and import is whether a VCF fleet already exists to fold the environment into. Read the row that matches what you have today.
Your starting point decides the path. Converge builds a new fleet from an estate, import adds an estate to an existing fleet.
VCF 9.1 components, mandatory and optional
A VCF 9.1 deployment is a set of products. Some you must deploy for a supported fleet, and some you add only when you need them. The cards below show each product, what it does, and whether it is mandatory or optional. The parts that follow deploy them in this order, the mandatory core first, then the optional products one at a time.
VCF 9.1 products and whether each is mandatory or optional. Mandatory items form the core fleet, optional items are added when you need them.
Greenfield with the VCF Installer
Greenfield is the path Broadcom builds for first. You deploy the VCF Installer appliance, point it at a set of prepared hosts, and it stands up a management domain from nothing: vCenter, NSX, SDDC Manager, VCF Operations and the new VCF Management Services cluster, all wired together. You choose to deploy to a new fleet and leave the existing components option unchecked. Before it lays down a single appliance the installer validates DNS resolution, NTP reachability, NIC speed, disk eligibility and IP availability, and if any of those fail the bring-up stops right there. This is the cleanest path because you design the whole thing on paper first, but it is also the one that assumes you have hosts you are free to wipe.
Converge an existing vSphere estate
Converge is for a running vSphere estate that has no VCF fleet yet. Using the VCF Installer you convert an existing vCenter and its ESX hosts into a VCF management domain in place, reusing the vCenter, and optionally existing VCF Operations and NSX, to instantiate the fleet. Your estate has to be on vSphere 8.0 Update 3 or later before you begin. The headline benefit is that there is no application downtime and no data migration, because the workloads never move. Converge supports an estate that already runs NSX, provided NSX is version 4.2 or later, and the installer brings that NSX across at its current version so you can upgrade it once the fleet is up. The catch that stops people is a different guardrail: the converge workflow will not proceed if the vCenter uses Enhanced Linked Mode, so you have to break that link before you begin.
Import a brownfield vSphere, vSAN and NSX environment
Import is for when a VCF fleet already exists and you want to bring an existing environment under it as a VI workload domain, managed centrally through VCF Operations. Clusters you import need vSphere 8.0 Update 3a or later, and if the estate already runs NSX it has to be NSX 4.2 or later. If there is no NSX in the estate, the import deploys it for you. Two prerequisites catch people every time: SSH has to be enabled on the existing vCenter, and every ESX host has to appear in the inventory by its fully qualified domain name rather than a short name. Import also validates that no SDDC Manager extension is already registered on the vCenter, because a vCenter that a fleet has previously claimed cannot be cleanly imported again. When it runs, all vSphere clusters in that vCenter come across together, so scope the vCenter before you scope the import.
| Path | Version floor | Hard guardrail |
|---|---|---|
| Greenfield | Supported host firmware and disks on the 9.1 compatibility guide | Hosts are wiped, so nothing in production can be on them |
| Converge | vSphere 8.0 Update 3 or later | vCenter not in Enhanced Linked Mode, NSX 4.2 or later if attached |
| Import | vSphere 8.0 Update 3a, NSX 4.2 or later if attached | SSH on, host FQDNs in inventory, no existing SDDC Manager extension |
Prerequisites that gate every path
Some requirements do not care which path you pick. Forward and reverse DNS has to resolve for every component FQDN, because the installer works from names and will not accept an address whose reverse lookup fails. NTP has to be reachable and answering, since certificate trust across the fleet depends on time being in sync. And 9.1 adds VCF Management Services, a mandatory container cluster that did not exist in earlier releases, which means a fresh block of contiguous management addresses on every path. Plan a /27 on the management network so you have headroom, size the hosts against the compatibility guide, and have your FQDN and addressing plan written down before you open any wizard. The parts that follow go deep on each of these.
A worked example, choosing a path for a mixed estate
Say you have two things to bring into 9.1: a rack of new hosts for a fresh management domain, and an existing vSphere 8 cluster running vSAN and NSX that carries live workloads. It is tempting to look for one path that does both. There is not one. The new rack is a greenfield build, so you deploy the VCF Installer and stand up the management domain from bare metal. The existing vSAN and NSX cluster then folds into the fleet you just built, and because a fleet already exists at that point it comes in by import, as a VI workload domain through VCF Operations. Converge would have been the option only if you had made that existing cluster the foundation of the fleet instead of the new rack. Two paths, run in order, greenfield first and import second, because import needs a fleet to import into.
What the rest of this series covers
This series works product by product. Parts 2 to 4 cover the foundations, the prerequisites and readiness checklist, the network, DNS and NTP setup, and deploying the VCF Installer appliance. Parts 5 to 7 build the mandatory core, the management domain, VCF Management Services with the license server, and VCF Operations. Parts 8 to 19 add the optional products one at a time, VCF Operations for Logs, VCF Operations for Networks, a VI workload domain, NSX Edge clusters, Avi Load Balancer, vDefend Distributed Firewall, VCF Automation, Data Services Manager, vSphere Supervisor and VKS, Private AI Foundation, VMware HCX, and a stretched cluster. Parts 20 and 21 cover the converge and import scenarios for existing environments. Part 22 closes with post-deployment validation and licensing. Each part states whether the product is mandatory or optional and gives the steps to deploy it.
Common questions
Can one deployment do greenfield and converge together?
No. Each cluster takes one path based on what it runs today. A mixed estate is more than one path, run in order, with greenfield or an existing fleet first so there is something for an import to land in.
My vSphere estate runs NSX. Can I converge it?
Yes, as long as NSX is version 4.2 or later and the vCenter is not in Enhanced Linked Mode. The installer converges the existing NSX at its current version, and you upgrade it after the fleet is up. Whether you converge or import comes down to whether a VCF fleet already exists, not whether NSX is present.
What version does my estate need for converge or import?
vSphere 8.0 Update 3 or later to converge, and 8.0 Update 3a or later to import. An estate that already runs NSX needs NSX 4.2 or later on either path. Confirm the exact build against the 9.1 release notes before you plan a window.
Do I need new IP addresses for a deployment?
Yes. VCF 9.1 adds the mandatory VCF Management Services cluster, which needs a fresh contiguous block on the management network. Plan a /27 whichever path you take.
References
- Broadcom TechDocs: Deployment, Convergence, and Upgrade (VCF 9.1)
- Broadcom TechDocs: Converging Existing vSphere Infrastructure to VCF
- VCF Blog: Deployment Pathways for VMware Cloud Foundation 9
About The Author
DrJha