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 and import both require vSphere 8.0 Update 3 or later. Importing a domain that already runs NSX needs NSX 4.2 or later.
- 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.
I will keep this practical. 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.
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 3a or later before you begin. The headline benefit is that there is no application downtime and no data migration, because the workloads never move. The catch that stops people is a guardrail: the converge workflow will not proceed if an NSX Manager is already attached to the vCenter you are converting, so a vSphere estate that already runs NSX is an import candidate, not a converge one.
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. This is the path that accepts NSX. Clusters you import need vSphere 8.0 Update 3 and NSX 4.2 or later. 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 3a or later | No NSX Manager attached to the vCenter being converged |
| Import | vSphere 8.0 Update 3, NSX 4.2 or later | 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 cannot converge, because NSX is attached, so once the greenfield fleet is up you import that cluster as a VI workload domain through VCF Operations. Two paths, run in order, greenfield first and import second, because import needs a fleet to import into. Trying to force the NSX cluster through converge is exactly the mistake the guardrail exists to catch.
What the rest of this series covers
The parts ahead follow the deployment itself. Parts 2 to 4 are foundations: prerequisites and the readiness checklist, network design and the addressing plan, and deploying the VCF Installer appliance. Parts 5 to 8 are the greenfield build: management domain bring-up, VCF Management Services and the fleet, your first VI workload domain, and NSX with Edge clusters and Avi load balancing. Parts 9 and 10 cover converging an existing vSphere estate and its guardrails and rollback. Parts 11 and 12 cover importing a brownfield vSphere, vSAN and NSX environment and validating it. Parts 13 and 14 close with stretched cluster and multi-instance designs, then post-deployment validation and first-week operations. Follow the track for the path you chose above.
Questions I get first
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?
No. The converge workflow refuses when an NSX Manager is attached to the vCenter. That estate is an import candidate, brought into an existing fleet as a workload domain, and it needs NSX 4.2 or later.
What version does my estate need for converge or import?
vSphere 8.0 Update 3 or later for both. Import of an NSX domain also needs NSX 4.2 or later. 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