A precheck failure stopped a VCF 9 install cold back in June. The host's forward DNS resolved fine. Nobody had set up the PTR record, so reverse lookup failed silently until validation caught it, and VCF Installer's pre-deployment validation doesn't do partial-proceed. One failed check, and the entire run is blocked until it's fixed in vSphere and validation runs again from the top.
That's the behavior worth understanding about what replaced Cloud Builder, more than the name change itself. VCF Installer isn't a rebrand of the same tool with a new logo. It enforces its prechecks completely. Fail one, and there's no "proceed anyway," no skipping the failed component and circling back to it later. Fix it in vSphere. Re-run the validation. Start again.
The Deploy Order Underneath It Is Fixed
The sequence VCF Installer walks through isn't a checklist you reorder to fit a particular engagement. ESX host prep comes first, then vCenter, then cluster configuration, then NSX if the deployment is on the VCF path rather than vSphere Foundation alone, then SDDC Manager — which the tooling itself calls the domain manager — then VCF Operations, then Fleet Management, then VCF Automation. That order is baked into the workflow, and trying to work around it produces exactly the kind of stalled precheck that ends up costing a day.
vSphere Foundation and full VCF 9.0 share the same installer path but land in different places. vSphere Foundation gets you the workload engine — vSphere, vSAN, built-in Kubernetes, and VCF Operations — without Fleet Management. Full VCF 9.0 adds SDDC Manager, NSX, VCF Operations Fleet Management, VCF Automation, and the domain and workload-domain construct on top of that. Knowing which one an environment is actually targeting matters before the deploy order even starts, because the endpoint changes what "done" looks like.
Host Commissioning Rules That Get Skipped More Than They Should
Hosts need to be pre-imaged with an ESX build that matches the VCF Bill of Materials before commissioning starts — not close to it, matching it. Hostnames need to resolve both forward and reverse, which is the PTR record most people forget exists until validation fails on it. Storage type can't be changed after commissioning — that's a hard rule, not a strong recommendation — so vSAN, VMFS on Fibre Channel, NFS, or vVol has to be decided before commitment, because there's no clean path to switch later without decommissioning and starting over. Network pools have to exist before commissioning, not get created alongside it. NTP and syslog need to be configured on the host first, full stop.
None of these prerequisites are new. What's new is how little room the installer gives you to discover them the hard way — validation catches the gap before deployment starts, instead of letting it surface three stages in.
The Image Builder Casualty
One transition detail that doesn't get talked about enough: the Image Builder tool that used to live inside Cloud Builder is deprecated and shouldn't be relied on going forward. If custom ESXi image assembly was part of the old workflow — folding in vendor firmware add-ons, building a specific image for a specific hardware profile — that piece needs a different answer now. go-via has become the tool people are actually reaching for in its place, community-maintained rather than shipped in the box.
- Overall install progress:
/var/log/vmware/vcf/domainmanager/domainmanager.log - vCenter deployment detail: the
ci-installer-<id>/workflow_<id>/vcsa-cli-installer.logpath under domainmanager - VCF Operations deployment: the
vcf-ops-ovf-tool-<id>.logpath under domainmanager - Upgrade activity (once the environment is live):
/var/log/vmware/vcf/lcm/lcm-activity.logfor the high-level flow,lcm-debug.logfor the granular root cause when activity-level logging isn't enough
Bringing an Existing Environment In Instead of Starting Clean
Not every VCF Installer run is a greenfield bring-up. An existing vSphere or NSX-T environment that was never VCF-managed can be brought in through two different paths depending on what it's becoming. Convert re-homes an existing vCenter, ESXi, and Aria stack as the new Management Domain. Import brings a separate existing vCenter and ESXi cluster in as a VI Workload Domain instead. They solve different problems, and picking the wrong one for a given environment's actual topology is its own way to end up mid-migration with infrastructure that doesn't match the plan.
Confirm every host's ESX build matches the target VCF Bill of Materials exactly, not approximately.
Verify forward and reverse DNS resolution for every host — check the PTR records specifically, not just the A records.
Decide storage type now. There's no changing it after commissioning without decommissioning and starting over.
Confirm network pools exist before commissioning begins, and NTP and syslog are already configured on every host.
If this is bringing an existing environment into VCF rather than a clean deployment, confirm whether Convert or Import actually matches the target topology before starting.
The precheck that stopped that install in June took about twenty minutes to fix once someone actually looked at the DNS zone. The bigger cost wasn't the fix. It was the assumption going in that the tool would flag the problem and let the rest of the deployment continue around it. It doesn't work that way anymore, and treating it like the old Cloud Builder workflow is the fastest way to lose a day to something that should have taken twenty minutes.