, ,

VCF 9.1 Deployment Overview and Component Checklist (VCF 9.1 Deployment Series, Part 1)

The three supported ways into VCF 9.1, a greenfield VCF Installer build, converging an existing vSphere estate, or importing a brownfield vSAN and NSX environment, and how to choose the right one for your starting point.

VCF 9.1 Deployment · Part 1 of 17

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.

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.

What you have todayPathDowntimeBest for
Bare or reimaged hosts, no vCenter yetGreenfield with the VCF InstallerNone, nothing in production yetNew racks, a clean design, no legacy to carry
Running vSphere 8 estate, no VCF fleetConverge with the VCF InstallerNone for workloadsTurning an existing estate into a first VCF fleet
Running vSphere, vSAN and NSX, VCF fleet already existsImport via VCF OperationsNone for workloadsFolding a domain into a fleet you already run
Table 1. Starting point decides the path. Converge builds a new fleet from an estate, import adds an estate to an existing fleet.
Where you startPath into 9.1Bare or reimaged hostsvSphere 8 estate,no VCF fleetvSphere, vSAN, NSX,VCF fleet existsGreenfield, VCF InstallerConverge into a new fleetImport into the fleet
Figure 1. Three starting points, three supported paths. This series covers each one in its own set of parts.

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 table lists 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.

ProductWhat it doesMandatory or optional
VCF InstallerDeploys and converges the fleetMandatory, it is the deployment tool
Management domain: vCenter, ESX, vSAN, NSX, SDDC ManagerCore control plane and first clusterMandatory
VCF OperationsFleet management, monitoring and capacityMandatory in 9.x
VCF Management ServicesFleet lifecycle, SDDC lifecycle, software depot, license server, identity brokerMandatory in 9.1
VI workload domainSeparate cluster for production workloadsOptional
NSX Edge clusterNorth-south routing, NAT and gateway firewallOptional, needed for overlay egress
Avi Load BalancerApplication load balancingOptional
VCF AutomationSelf-service provisioning and cloud consumptionOptional
vSphere Supervisor and VKSKubernetes on vSphereOptional
Private AI Foundation with NVIDIAGPU and AI workloadsOptional
Stretched clusterMulti-AZ availability for a clusterOptional
Table 2. VCF 9.1 products and whether each is mandatory or optional. Mandatory items form the core fleet, optional items are added when needed.

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.

PathVersion floorHard guardrail
GreenfieldSupported host firmware and disks on the 9.1 compatibility guideHosts are wiped, so nothing in production can be on them
ConvergevSphere 8.0 Update 3a or laterNo NSX Manager attached to the vCenter being converged
ImportvSphere 8.0 Update 3, NSX 4.2 or laterSSH on, host FQDNs in inventory, no existing SDDC Manager extension
Table 3. Version floors and the one guardrail that most often reroutes a path. Confirm each against the 9.1 release notes for your build.

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.

How to decide your path. Write down what each cluster runs today: vCenter version, whether NSX is attached, whether vSAN is in play, and whether a VCF fleet already exists. That one inventory answers the path question for every cluster without guesswork. New hosts go greenfield, NSX-free estates without a fleet can converge, everything with NSX or an existing fleet imports. Decide per cluster, not per project.

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 14 add the optional products one at a time, a VI workload domain, NSX Edge clusters, Avi Load Balancer, VCF Automation, vSphere Supervisor and VKS, Private AI Foundation, and a stretched cluster. Parts 15 and 16 cover the converge and import scenarios for existing environments. Part 17 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?
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.

VCF 9.1 Deployment · Part 1 of 17
Complete Guide  |  Next: Part 2

References

About The Author


Discover more from Journal of Intelligent Infrastructure

Subscribe to get the latest posts sent to your email.

Leave a Reply

Your email address will not be published. Required fields are marked *

Architect’s Toolkit

About the Author

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.

Discover more from Journal of Intelligent Infrastructure

Subscribe now to keep reading and get access to the full archive.

Continue reading