Dr. Pranay Jha

Everyone celebrates the death of the deployment parameters spreadsheet. The field reality is the opposite of the marketing: the wizard is less forgiving than the old Excel sheet, because validation now runs live against your DNS and network instead of against a static file you could fudge. That is a good trade once you respect it. Here is the bring-up, start to finish.

Step 1: Deploy the Installer and get the binaries

Deploy the VCF Installer OVA to a standalone ESX host. Unlike Cloud Builder, it ships without software bundles, so your first job is to point it at the online Broadcom depot or a private offline depot. If you will run more than one instance, build the offline depot once and reuse it, because on a slow link the binary download is the longest single wait in the whole process.

Step 2: Sweep DNS before the wizard

The 9.x wizard asks for FQDNs, not IPs, for the management components, and it validates them by reverse lookup from the Installer appliance. A missing PTR record fails validation before deployment even starts. Do a standalone resolution sweep from the Installer itself first.

# From the VCF Installer shell, confirm forward AND reverse for every FQDN
for h in vcenter nsx-mgr-a sddc-mgr ops-a automation-a; do
  nslookup ${h}.example.local
done

# And confirm the reverse (PTR) resolves back to the same name
nslookup 10.0.10.21   # expect vcenter.example.local

Step 3: Run the deployment wizard

Walk the wizard in order:

1. Choose VCF (versus VVF) and the deployment path: new fleet or expand an existing fleet.
2. Set existing-component toggles, including whether you will deploy VCF Automation now or later.
3. Pick the deployment model (Simple or HA) and appliance sizes.
4. Set network options: separate ESX management network, Operations and Automation on a VDS or NSX segment, transit gateway type (centralized or distributed).
5. Choose storage: vSAN ESA or OSA, NFS, or VMFS on FC.
6. Enter the input stages: instance and domain names, DNS, NTP, ESX host details (the Installer grabs the SSL thumbprint automatically), VLANs, the VDS, NSX VIP and node FQDNs, and the SDDC Manager FQDN.
7. Review the summary, download the JSON spec, run validation, and deploy.

One bring-up deploys the full stack: vCenter, the NSX Manager cluster, SDDC Manager, and the fleet-level VCF Operations (Operations, Fleet Manager, Collector) plus VCF Automation. That is the major 9.x change. Aria Operations and Automation are no longer separate Day-2 installs, and VCF Operations lifecycle-manages the whole thing afterward. The Installer auto-generates complex passwords for every appliance, which you retrieve via the Review Passwords button. A full fleet bring-up runs roughly 4 to 6 hours in a lab, more with higher host counts. The topology you are instantiating is covered in the reference architecture.

Step 4: License within 90 days

The instance comes up in evaluation mode, fully functional, and you can add hosts, clusters, and workload domains. It must be licensed within 90 days via a license file applied through VCF Operations and the Broadcom Business Services Console. SDDC Manager is installed as a component but reduced: management moves to VCF Operations, and a few operations still require the SDDC Manager API (creating a workload domain with an LACP-enabled VDS is the common one).

The prerequisite checklist the wizard assumes

Before the wizard will validate clean, the hosts and environment need to be in a specific state. Treat this as the gate, not a suggestion.

• 4 management hosts, vSAN-ready recommended, each with at least one pNIC at 10 Gbps minimum (25 Gbps recommended for vSAN and overlay traffic).
• Self-signed certificates regenerated against each host FQDN, and stale disk partitions deleted so vSAN can claim the devices.
• NTP and DNS reachable from the hosts and from the Installer appliance, with forward and reverse records for every component FQDN.
• The required VLANs trunked and tagged, and the TEP path validated at 1600 MTU or higher end to end.
• Roughly 20 percent spare cluster headroom for future scaling. The Installer warns if it is missing, though it will not block on it.

Common bring-up failures and where they come from

Most failed bring-ups cluster around four causes, and knowing the pattern saves the debugging detour. A reverse DNS gap fails validation before deployment even starts, because the wizard resolves FQDNs by reverse lookup from the appliance. An MTU drop on a single inter-rack hop fails the TEP check even when same-rack pings pass. A clock skew between hosts and the appliance surfaces as a certificate or registration error rather than an obvious time problem. And differing ESX root passwords block the UI wizard outright, which is the moment you switch to the JSON specification path. None of these are platform faults. They are environment faults the live validation now catches earlier and louder than the old spreadsheet ever did.

What the deploy is actually doing

The roughly 4 to 6 hour window is not idle time. The Installer is forming the vSAN datastore, deploying and configuring vCenter, standing up the NSX Manager cluster and preparing the hosts as transport nodes, deploying SDDC Manager, and then bringing up the fleet services: VCF Operations with its Fleet Manager and Collector, and VCF Automation. Because everything is validated and configured in sequence, a failure two thirds of the way in usually means an environment condition that only mattered once the relevant component tried to come up, which is exactly why the front-loaded DNS, MTU, and NTP checks pay off. Keep the JSON spec from the run open in another tab so that if you do need support, you can hand over the exact input that produced the state.

What I’d Do

Two habits prevent most multi-hour bring-up failures. First, run a standalone reverse-DNS sweep from the Installer appliance before you ever open the wizard, because reverse DNS, NTP, and the TEP VLAN are where live validation bites. Second, generate and keep the JSON spec from your first run, even a run that only reached validation, and treat that file as your real source of truth, not the planning workbook. The JSON is what you re-feed for the next instance, attach to support cases, and use for rebuilds. The workbook is just a design worksheet now. With the management domain up, you are ready to deploy a VI workload domain.

References

• VCF Blog: Deployment Pathways for VMware Cloud Foundation 9
• VCF Blog: Planning a Successful VCF 9.0 Deployment
• Broadcom TechDocs: Deployment, Convergence, and Upgrade (VCF 9)

About The Author

Dr. Pranay Jha

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.

See author's posts