Academy/VCF 9.0 Support (2V0-15.25)/VMware Cloud Foundation Installation — Deployment Wizard & JSON Spec
This lab targets VCF 9.0

VMware Cloud Foundation Installation — Deployment Wizard & JSON Spec

VCF 9.0Intermediatesupportadmin⏱ 90 min

VCFFTS9 course content — VCF 9.0 focused

Objectives

  • Access and configure VCF Installer appliance (online/offline depot)
  • Explain VCF Fleet concept (Operations + Automation + Instances)
  • Walk through the 11-step deployment wizard configuration sequence
  • Select appropriate DVS profile based on NIC count (2/4/6)
  • Use JSON deployment specification for repeatable deployments
  • Describe the 8-step installation workflow sequence
  • Identify key log files for troubleshooting VCF installation

Prerequisites

Active Holodeck VCF 9.0 lab or access to VCF documentation

Required skills:

  • Basic VMware terminology

Tasks

Task 1 VCF Installation — Wizard & JSON Methods

VCF deployment via Cloud Builder is a wizard-driven process, but the real work happens in the deployment JSON specification. Understanding the JSON spec structure and common misconfigurations is essential for successful bring-up.

Master both VCF installation methods with detailed configuration sequence

Step 1
VCF Installer Appliance

VCF Installer = separate appliance deployed OUTSIDE target environment. Access via FQDN with admin@local credentials. Pre-deployment: (1) Review prerequisites, (2) Configure depot settings — online (Broadcom credentials) or offline (Binary Transfer Utility). Binaries NOT included in appliance — must be downloaded.

Step 2
VCF Fleet Deployment Concepts

VCF Fleet = VCF Operations + VCF Automation + 1+ VCF Instances. Each VCF Instance must have a management domain. Can reuse existing VCF Operations instance. Can convert existing vCenter into management domain vCenter. Deployment models: Simple (1 NSX node, 1 VCF Ops, 1 VCF Auto — NOT production) vs HA (3 nodes each — VIP auto for NSX, no LB for VCF Ops from installer, VCF Auto handles LB internally).

Step 3
Deployment Wizard Configuration Sequence
Step-by-step: (1) General info — instance name, mgmt domain name, deployment model, DNS, NTP; (2) VCF Operations — appliance details, fleet mgmt appliance, collector appliance; (3) VCF Automation — FQDN, primary IP, secondary IP, CIDR for container communication (4 IPs for 3-node HA); (4) vCenter — FQDN, datacenter name, cluster name, domain, appliance size; (5) NSX Manager — appliance size, FQDN, admin/root/audit passwords; (6) Storage — vSAN (OSA/ESA, FTT, dedup/compression) or NFS or VMFS-FC; (7) Hosts — up to 64 ESX hosts, fingerprint verification; (8) Networks — VLAN, CIDR, MTU, gateway for mgmt/VM mgmt/vMotion/vSAN; (9) DVS — profiles based on NIC count (2/4/6 NICs); (10) SDDC Manager — appliance config; (11) Review → Validate → Deploy.
Step 4
DVS Configuration Profiles
Profiles based on physical NIC count: 2 NICs → default/unified fabric (single VDS, all traffic), 4 NICs → Storage Traffic Separation (2 VDS, vSAN on separate NICs) OR NSX Traffic Separation (2 VDS, NSX on separate NICs), 6 NICs → Storage + NSX Traffic Separation (3 VDS — mgmt/vMotion/VM on VDS1, vSAN on VDS2, NSX on VDS3).
Step 5
JSON Deployment Specification

Alternative to wizard: upload JSON spec file containing all config parameters. JSON can be generated from wizard inputs (download after completing wizard) or created manually. After upload: preview in JSON format, edit via wizard, validate, deploy. Useful for repeatable deployments and automation.

Step 6
Holodeck Parallel — New-HoloDeckInstance

Holodeck automates the same workflow that VCF Installer performs manually. New-HoloDeckInstance deploys Cloud Builder which orchestrates the bring-up sequence. The config.json maps directly to the deployment specification JSON — same parameters, same validation. Understanding both methods reinforces VCF installation concepts.

[HOLODECK NOTE] Holodeck deployment via New-HoloDeckInstance automates the Cloud Builder + JSON spec process. Key difference: Holodeck pre-configures networking (VLANs, port groups) on the physical host's vSwitch, so DVS profile selection in the wizard maps to virtual NICs, not physical pNICs. The 2/4/6 NIC DVS profiles in production correspond to physical NIC separation for management, vSAN, vMotion, and NSX traffic — in Holodeck all traffic shares the physical host's NICs.

Validation Gate

Check: List the five most critical pre-validation checks Cloud Builder performs before starting VCF bring-up

Expected: 1. DNS forward/reverse resolution for all hostnames. 2. NTP reachability and time sync. 3. ESXi host SSH accessibility. 4. Network connectivity between hosts. 5. Password complexity validation.

Common Errors

IP address conflicts in the deployment JSON spec
Fix: The deployment JSON contains IP assignments for all components (ESXi management, vMotion, vSAN, NSX TEPs, management VMs). A single IP conflict causes bring-up failure at the component that encounters the duplicate. Use a spreadsheet to track all IP assignments before generating the JSON.
DNS records not created before bring-up
Fix: Cloud Builder validates forward and reverse DNS for every hostname in the JSON spec. Missing or incorrect DNS records cause validation failure before deployment even begins. Create all A and PTR records before starting bring-up. Common miss: reverse PTR records for management VMs.
Using incorrect NTP or DNS server IPs in the JSON spec
Fix: NTP and DNS servers specified in the JSON must be reachable from the management network. If they are on a different VLAN, ensure routing is in place. Cloud Builder pre-validation checks NTP sync — failure here blocks the entire deployment.
Password complexity not meeting VCF requirements
Fix: VCF enforces strict password complexity: minimum 8 characters, at least one uppercase, one lowercase, one digit, one special character. Passwords in the JSON spec that don't meet this are rejected during validation, not during deployment — so the error message can be confusing.

Task 2 VCF Installation Workflow & Troubleshooting

Understanding which components are deployed in which order during bring-up helps troubleshoot failures at specific stages. The bring-up sequence is: ESXi commissioning → vCenter → NSX Manager → vSAN → SDDC Manager → VCF Operations → VCF Automation.

Understand the sequential installation workflow and key log files

Step 1
Installation Workflow Sequence

Ordered sequence: (1) ESX Hosts Preparation — interactive install, mgmt VLAN, VM VLAN, NTP config; (2) vCenter Deployment; (3) SDDC Manager Deployment; (4) vSphere Cluster Configuration — hosts migrated from VSS to VDS; (5) NSX Deployment and Configuration; (6) VCF Operations Fleet Management Deployment; (7) VCF Operations Deployment and Configuration; (8) VCF Automation Deployment and Configuration.

Step 2
Key Log Files

Installation progress visible in VCF Installer UI Tasks section. Detailed log files for each phase of installation. For troubleshooting: identify which workflow step failed, examine corresponding logs, check for config validation errors. Two installation log slides in lecture manual (7-44, 7-45) cover specific log file locations and common error patterns.

Validation Gate

Check: What is the correct order of component deployment during VCF bring-up?

Expected: ESXi host commissioning → vCenter deployment → NSX Manager deployment → vSAN cluster creation → SDDC Manager handoff → VCF Operations deployment → VCF Automation deployment

Common Errors

Attempting to re-run bring-up after partial failure without cleanup
Fix: If bring-up fails mid-process (e.g., after vCenter deploys but before NSX), you cannot simply re-run the wizard. Partially deployed components must be cleaned up first. Cloud Builder provides a 'retry' option for some failures, but persistent failures require manual cleanup and fresh start.
Not validating ESXi host connectivity before bring-up
Fix: Cloud Builder needs SSH access (port 22) to all ESXi hosts on the management network. If any host is unreachable, bring-up fails during commissioning. Test SSH connectivity from the Cloud Builder VM to every host before starting.

Design Reflection (VCDX)

VCF bring-up is a Day-0 operation that VCDX candidates should understand end-to-end. Panelists may ask about failure scenarios during bring-up and your recovery strategy. Know the deployment sequence and where common failures occur.

Requirements

  • Understand Cloud Builder deployment wizard and JSON specification
  • Know the bring-up component deployment sequence
  • Identify pre-validation checks and common failure points

Constraints

  • All DNS records must exist before bring-up
  • All hosts must be reachable via SSH on management network
  • Password complexity must meet VCF requirements

Assumptions

  • Network infrastructure (switches, VLANs, routing) is pre-configured
  • DNS and NTP services are operational and reachable

Risks

  • IP conflicts in JSON spec causing mid-deployment failure
  • DNS misconfiguration blocking pre-validation
  • Partial deployment failure requiring manual cleanup

⚠ Known Pitfalls (from Community KB)

Generating the deployment JSON without cross-checking IP assignments — use a planning spreadsheet with VLOOKUP to prevent duplicates.
Assuming Cloud Builder will automatically create DNS records — it validates them but does not create them.

References

Was this page useful?
Type to search. ↑ ↓ to move, Enter to open, Esc to close.