Academy/Holodeck Lab Setup & Operations/Deploy VCF 9.0.x Management Domain Using Holodeck Toolkit
This lab targets VCF 9.0.2

Deploy VCF 9.0.x Management Domain Using Holodeck Toolkit

VCF 9.0.2Intermediateadminarchitectvcdx⏱ 180 min

Core workflow applies to VCF 9.0.0 through 9.0.2. VCF 5.2.x uses the same Toolkit but different content manifest files — see Extension 1.

Objectives

  • Configure the Holodeck Toolkit deployment parameters for a VCF 9.0.x management domain
  • Execute a successful Holodeck-driven nested VCF deployment from Prepare through Start
  • Validate that all management domain components (vCenter, SDDC Manager, NSX Manager, ESXi hosts) are healthy post-deployment
  • Interpret common deployment failures using Holodeck logs and the community knowledge base
  • Articulate the nested architecture's relationship to production VCF design constraints

Prerequisites

Physical ESXi 8.0.x host with Holodeck Toolkit installed and content pack staged (holodeck-01 completed). No existing Holodeck instance running. Sufficient resources: minimum 512 GB RAM, 64 logical cores, 2 TB SSD/NVMe datastore. Internet connectivity or offline depot configured.

Prior labs: holodeck-01

Required skills:

  • ESXi host management via vSphere Client
  • Basic PowerShell navigation and command execution
  • Understanding of VCF management domain architecture (Cloud Builder, SDDC Manager, vCenter, NSX)
  • Familiarity with nested virtualization concepts
📸 Starting State: S2-52 — Cloud Builder Ready (VCF 5.2)

Lab Environment

Single physical ESXi host running Holodeck Toolkit. The Toolkit provisions: 1x HoloRouter (virtual router/gateway), 1x HoloConsole (jumpserver/webtop), 4x nested ESXi hosts (management cluster), 1x Cloud Builder, which in turn deploys: 1x SDDC Manager, 1x vCenter Server, 1x NSX Manager cluster (or single node depending on profile). All nested components communicate through the HoloRouter on an isolated 10.1.1.0/16 supernet.

graph TB
  PHY[Physical ESXi Host] --> HR[HoloRouter 10.1.1.1]
  PHY --> HC[HoloConsole/Webtop]
  HR --> ESXi1[ESXi-01 10.1.1.101]
  HR --> ESXi2[ESXi-02 10.1.1.102]
  HR --> ESXi3[ESXi-03 10.1.1.103]
  HR --> ESXi4[ESXi-04 10.1.1.104]
  HR --> CB[Cloud Builder 10.1.1.200]
  CB --> SDDC[SDDC Manager 10.1.1.5]
  CB --> VC[vCenter 10.1.1.6]
  CB --> NSX[NSX Manager 10.1.1.10]

IP Addressing

NetworkPurposeVLAN
10.1.1.0/20Management network (SDDC Manager, vCenter, NSX, Cloud Builder)VLAN 1644 (default)
10.1.1.0/24ESXi host management VMkernelVLAN 1644
10.1.2.0/24vMotionVLAN 1645
10.1.3.0/24vSANVLAN 1646
10.1.4.0/24NSX Host TEPVLAN 1647
10.1.5.0/24NSX Edge TEPVLAN 1648

Credentials

SystemUsernamePassword
Physical ESXi HostrootSet during ESXi installation
HoloConsole (Webtop)holodeckDefault Holodeck password from Toolkit docs
Nested ESXi HostsrootSet by Holodeck config.json esxiPassword field
Cloud Builderadmin@localSet by Holodeck config.json cbPassword field
SDDC Manageradministrator@vsphere.localSet in VCF bring-up spec JSON
vCenter Serveradministrator@vsphere.localSame as SDDC Manager SSO password
NSX ManageradminSet in VCF bring-up spec JSON

Tasks

Task 1 Review and customize the deployment configuration

manageability

Understand and validate the deployment parameters before committing to a 2+ hour automated build. In production, this mirrors the VCF Planning and Preparation Workbook review — a VCDX-critical checkpoint.

Step 1

Open PowerShell on the HoloConsole (or your management workstation with the Holodeck module imported). Navigate to the Holodeck runtime directory: cd C:\Holodeck\holodeck-runtime

PowerShell prompt at the holodeck-runtime directory
Step 2

Open the deployment configuration file: notepad .\templates\config.json

JSON file opens showing the deployment parameters
This is the master control file. Every IP, hostname, resource sizing, and content version is set here.
Step 3

Verify the vcfVersion field is set to '9.0.2' (or your target version). Verify contentManifest points to a valid manifest file for that version in the content/ directory.

vcfVersion: 9.0.2 and contentManifest path resolves to an existing file
Mismatched manifest and VCF version is the #1 cause of deployment failure. The forum thread 'fail to deploy vcf 9.0.2.0' (12 replies) was caused by exactly this mismatch.
Step 4

Review ESXi host resource sizing in the managementCluster section. Default: 4 hosts, each with 12 vCPU and 96 GB RAM. If your physical host has less than 512 GB RAM, reduce to 3 hosts or lower per-host memory (minimum 64 GB per nested ESXi for management domain).

Resource values that total less than 80% of your physical host's capacity
Only the FIRST nested ESXi host picks up custom CPU/memory values if you edit config.json after a partial deployment. This is a confirmed community issue — see 'Encounter Issues when Modified default ESXi Host CPU & Memory' (8 replies, RESOLVED).
Always customize config.json BEFORE the first New-HoloDeckInstance run. If you need to change sizing after a failed attempt, destroy the instance first.
Step 5

Verify the networking section: confirm the management CIDR (default 10.1.1.0/20), VLAN range (1644-1648), and that the holoRouterExternalIP is on an accessible network from your workstation.

Networking values match your physical environment's available VLAN and IP ranges
The VLAN range must not conflict with existing port groups on the physical host. The community thread 'Lab VLAN Range' documents conflicts when using default VLANs on shared infrastructure.
Step 6

Save and close config.json. Review the changes by running: Get-Content .\templates\config.json | ConvertFrom-Json | Format-List

Formatted output of all deployment parameters

Validation Gate

Check: Manually confirm: vcfVersion matches your target, contentManifest file exists, ESXi host count x resource per host < physical host capacity, VLAN range is clear.

Expected: All four checks pass. You are ready to prepare the instance.

Common Errors

Deployment later fails with 'manifest invalid' or content pack not found
Cause: contentManifest path in config.json points to a file that doesn't exist or is for a different VCF version
Fix: Verify the file at the contentManifest path exists and its internal version tag matches vcfVersion. Re-download content pack if needed.
📋 KB: Thread 60: Deployment issues Holodeck Toolkit v5.2x - manifest invalid?
Only first ESXi host gets custom CPU/memory; others use old values
Cause: config.json was modified after a partial deployment — Holodeck caches host specs on first Prepare
Fix: Destroy the current instance (Remove-HoloDeckInstance), edit config.json, then re-run Prepare from scratch.
📋 KB: Thread 0: Encounter Issues when Modified default ESXi Host CPU & Memory

Task 2 Prepare the Holodeck instance

availability

The Prepare phase stages all artifacts, validates host compatibility, and configures the HoloRouter. In production terms, this is the equivalent of the VCF Planning & Preparation phase — validating that infrastructure meets the deployment checklist before committing.

Step 1

In PowerShell, run: New-HoloDeckInstance -ConfigFile .\templates\config.json -Verbose

A progress stream showing: content validation, ESXi ISO extraction, OVA staging, HoloRouter deployment, HoloConsole deployment, network configuration. Final line should read 'Prepare phase completed successfully.'
This step takes 15-30 minutes. Do not interrupt it. If you see 'Waiting for FRR service' for more than 10 minutes, the HoloRouter BGP daemon may be stuck — see Task 2 common errors below.
Step 2

Verify the HoloRouter is reachable: ping 10.1.1.1 from HoloConsole or your workstation (if routed).

Reply from 10.1.1.1: bytes=32 time<1ms
If pinging from an external workstation (not HoloConsole), you need a static route: route add 10.1.1.0 mask 255.255.240.0 <holorouter-external-IP>
Step 3

Verify the HoloConsole webtop is accessible: open a browser and navigate to https://<holoconsole-ip>:8443

Guacamole-based webtop login screen appears
The webtop provides a Firefox browser pre-configured to reach all management IPs. Use it for all subsequent UI-based validation.
Step 4

Check the Prepare output log: Get-Content C:\Holodeck\holodeck-runtime\logs\prepare-*.log -Tail 50

Log shows all validations passed, no ERROR lines

Validation Gate

Check: Run: Get-HoloDeckInstance | Format-Table -Property InstanceId, State, VcfVersion

Expected: Instance state shows 'Prepared' with your target VCF version

Common Errors

Prepare hangs at 'Waiting for FRR service' for 10+ minutes
Cause: HoloRouter BGP/FRR daemon failed to start — usually a resource contention or ESXi host networking issue
Fix: SSH into the HoloRouter (ssh admin@10.1.1.1) and check: systemctl status frr. If dead, restart: systemctl restart frr. If it persists, redeploy the HoloRouter by destroying and re-preparing.
📋 KB: Thread 37: Waiting for FRR service
'Configuration of HoloRouter Failed. Encountered error'
Cause: HoloRouter management IP assignment failed — DHCP vs static conflict or port group misconfiguration
Fix: Verify the external portgroup has VLAN trunking enabled and DHCP is available on the management network. If DHCP is unavailable, the HoloRouter should fall back to a static IP — but some versions require manual config.
📋 KB: Thread 42: Configuration of HoloRouter Failed. Encountered error
PreCheck ERROR: Target Host ESXi version is not compliant
Cause: Physical host ESXi version is older than what the VCF content pack requires
Fix: Upgrade the physical ESXi host to at least 8.0 Update 3 for VCF 9.0.x. Alternatively, add allowLegacyCPU=TRUE to boot.cfg if it's a CPU compatibility issue rather than ESXi version.
📋 KB: Thread 8: Issue with legacy CPU support (setting not added to boot.cfg)
'Issue while verifying target hardware'
Cause: Holodeck's pre-flight hardware check fails — usually insufficient RAM, cores, or datastore space
Fix: Verify: (a) total RAM > sum of nested ESXi + overhead, (b) datastore has at least 1.5 TB free, (c) no other VMs competing for resources. Shut down unnecessary VMs on the physical host.
📋 KB: Thread 44: Issue while verifying target hardware

Task 3 Start the full VCF management domain deployment

availability

This is the automated bring-up — equivalent to running Cloud Builder in production. Holodeck orchestrates nested ESXi provisioning, Cloud Builder deployment, and the full VCF SDDC bring-up workflow. Understanding what happens inside this black box is critical for VCDX because panelists will probe your understanding of the bring-up sequence.

Step 1

Run: Start-HoloDeckInstance -InstanceID <your-instance-id> -Verbose

Progress stream begins. Major milestones in order: (1) Nested ESXi deployment, (2) Cloud Builder OVA deployment, (3) Cloud Builder initialization, (4) VCF bring-up spec submission, (5) SDDC Manager deployment, (6) vCenter deployment, (7) NSX Manager deployment, (8) Host commissioning, (9) Cluster creation, (10) Final validation.
Full deployment takes 90-150 minutes. Monitor via the Verbose output stream. Do NOT close the PowerShell window.
Step 2

While waiting, monitor the Cloud Builder UI for detailed bring-up progress. From HoloConsole webtop, open Firefox and navigate to https://10.1.1.200 (Cloud Builder). Log in with admin@local credentials from config.json.

Cloud Builder dashboard showing 'Bring-up in Progress' with a multi-step progress tracker
The Cloud Builder UI provides much more granular status than the PowerShell output. If a step is stuck, the UI will show the specific sub-task and any pre-check failures.
Step 3

Watch for the NSX validation step specifically. VCF 9.0.x requires NSX 9.0.2.x. If the deployment pauses with 'Validate NSX install image is available fails', check the content pack version.

NSX validation passes and deployment continues to host commissioning
The community thread 'Holodeck 9.0.1 VCF Deployment fails' (9 replies, RESOLVED) documents a version mismatch where VCF 9.0.1 deployment expects NSX 9.0.2.x but the bundled image was 9.0.1.x. Fix: download NSX 9.0.2.0.25150386 and update the content manifest.
Step 4

Wait for the PowerShell command to complete. The final output should indicate success.

'VCF Management Domain deployment completed successfully. Instance ID: <id>, State: Running'

Validation Gate

Check: Run: Get-HoloDeckInstance | Format-Table -Property InstanceId, State, VcfVersion, ManagementDomainStatus

Expected: State: Running, ManagementDomainStatus: Active

Common Errors

'Cannot select datastore' during nested ESXi provisioning
Cause: The target datastore on the physical host is full, misnamed, or inaccessible. This was the most-discussed thread in the community (15 replies).
Fix: Verify the physical datastore referenced in config.json exists, has sufficient free space (>1.5 TB), and is accessible from the physical ESXi host. If using vSAN on the physical host, ensure the vSAN datastore is healthy.
📋 KB: Thread 51: Holodeck vcf 9 - Cannot select datastore
'VCF Installer is not ready yet' — bring-up hangs waiting for Cloud Builder
Cause: Cloud Builder VM deployed but its initialization services are not completing — network, DNS, or NTP issue
Fix: SSH into Cloud Builder (ssh admin@10.1.1.200) and check: (a) DNS resolution: nslookup sddc-manager.site-a.vcf.lab, (b) NTP sync: ntpq -p, (c) Service status: systemctl status vcf-bringup. Fix the root cause and restart the service.
📋 KB: Thread 5: VCF Installer is not ready yet
NSX validation fails: 'Validate NSX install image is available fails'
Cause: NSX bundle version in content pack doesn't match what VCF 9.0.x bring-up expects
Fix: Download NSX 9.0.2.0.25150386 from Broadcom support portal. Place in the content directory. Update the content manifest to reference the correct NSX bundle filename and checksum.
📋 KB: Thread 23: Holodeck 9.0.1 VCF Deployment fails
'Start-HoloDeckInstance -InstanceID xxxxxx command failed. Cannot find instance.'
Cause: Instance ID from Prepare phase doesn't match, or the Prepare output was lost/instance was removed
Fix: Run Get-HoloDeckInstance to list valid instance IDs. Re-run Prepare if no instance exists. Use the exact InstanceID from the Prepare output.
📋 KB: Thread 2: Start-HoloDeckInstance -InstanceID xxxxxx command failed. Cannot find instance.

Task 4 Validate management domain health — SDDC Manager and vCenter

manageability

Post-deployment validation is where you prove the management domain is production-equivalent. VCDX panelists will expect you to articulate what 'healthy' looks like and what you would check. This task builds that muscle memory.

Step 1

From HoloConsole webtop Firefox, navigate to SDDC Manager: https://10.1.1.5. Log in with administrator@vsphere.local.

SDDC Manager dashboard loads showing the management domain overview
Step 2

Navigate to Inventory > Workload Domains. Verify the management domain is listed with Status: Active.

Management domain shown with Active status, 4 hosts, 1 cluster
Step 3

Navigate to Inventory > Hosts. Verify all 4 ESXi hosts show Status: Active with no warnings or errors.

4 hosts, all Active, no yellow/red indicators
Step 4

Open a new tab. Navigate to vCenter: https://10.1.1.6. Log in with administrator@vsphere.local.

vSphere Client loads showing the management cluster
Step 5

In vSphere Client, navigate to the management cluster. Verify: (a) 4 ESXi hosts are connected, (b) vSAN health is green, (c) DRS is enabled, (d) HA is enabled and admission control is configured.

Cluster summary shows 4 connected hosts, vSAN health green, DRS and HA both enabled
Take a screenshot of this view — it's a key artifact for VCDX design documentation.
Step 6

Verify vCenter services: from vSphere Client, navigate to Administration > System Configuration > Services. Confirm all services are Running.

All vCenter services show status: Running (green)

Validation Gate

Check: SDDC Manager: Workload Domains > management domain = Active. vCenter: Cluster > 4 hosts connected + vSAN green + HA/DRS enabled.

Expected: All management plane components healthy with no warnings

Common Errors

SDDC Manager UI not accessible (connection timeout or 503)
Cause: SDDC Manager services still initializing post-deployment, or DNS not resolving
Fix: Wait 10-15 minutes after deployment completes. SSH to SDDC Manager and run: systemctl status domainmanager. If DNS fails, verify the HoloRouter DNS forwarder is running.
📋 KB: Thread 24: Holodeck 9.0.1 DNS troubleshooting

Task 5 Validate NSX Manager and transport node status

availability

NSX is the most failure-prone component in nested deployments due to TEP tunnel overhead and resource contention. Validating NSX health independently is a VCDX best practice that demonstrates operational maturity.

Step 1

From HoloConsole webtop, navigate to NSX Manager: https://10.1.1.10. Log in with admin and the NSX password from the bring-up spec.

NSX Manager dashboard loads showing the system overview
Step 2

Navigate to System > Fabric > Nodes > Host Transport Nodes. Verify all 4 ESXi hosts are listed with Configuration State: Success and Transport Node Status: Up.

4 host transport nodes, all Success / Up
Step 3

Navigate to System > Fabric > Nodes > Edge Transport Nodes. Verify edge nodes are deployed (if your deployment profile includes them) with Status: Up.

Edge node(s) listed with Status: Up (or empty if management-only deployment)
If you used the -ManagementOnly flag, edge nodes are not deployed. This is expected.
Step 4

Navigate to Networking > Tier-0 Gateways. Verify the default Tier-0 gateway is present and in Active status.

Tier-0 gateway listed with status indicators green
Step 5

Run an NSX health check via API: From HoloConsole PowerShell, run: Invoke-RestMethod -Uri 'https://10.1.1.10/api/v1/cluster/status' -Headers @{Authorization='Basic '+[Convert]::ToBase64String([Text.Encoding]::ASCII.GetBytes('admin:<nsx-password>'))} -SkipCertificateCheck

JSON response showing cluster_status: STABLE and all control/management planes active

Validation Gate

Check: NSX Manager: All host transport nodes Success/Up + cluster status STABLE

Expected: NSX fabric fully operational with no degraded components

Common Errors

Host transport nodes show 'Install Failed' or 'Not Ready'
Cause: NSX VIB installation on nested ESXi hosts failed — resource contention or network timeout during deployment
Fix: In NSX Manager, select the failed host and click 'Resolve'. If that fails, SSH to the ESXi host and check: esxcli software vib list | grep nsx. Re-prepare the transport node from NSX Manager.
NSX Manager UI unreachable (timeout)
Cause: NSX Manager VM is resource-starved in the nested environment — common with <96 GB per ESXi host
Fix: Check NSX Manager VM resource usage in vCenter. Increase memory reservation if possible. In nested environments, NSX Manager is the most memory-hungry component.

Task 6 Configure external access and take a post-deployment snapshot

recoverability

External access (reaching the nested environment from your workstation without the webtop) and a clean snapshot are operational hygiene steps that save hours of re-deployment time. This mirrors production change management: validate, document, snapshot.

Step 1

On your physical workstation (outside the Holodeck pod), add a static route to reach the nested management network. Windows: route add 10.1.1.0 mask 255.255.240.0 <holorouter-external-ip> -p. Linux/Mac: sudo ip route add 10.1.1.0/20 via <holorouter-external-ip>

Route added successfully
The -p flag on Windows makes the route persistent across reboots.
Step 2

Verify external access: ping 10.1.1.5 (SDDC Manager) and ping 10.1.1.6 (vCenter) from your workstation.

Replies from both IPs
Step 3

Configure DNS forwarding on your workstation to resolve the nested environment's FQDNs. Add a conditional forwarder pointing *.site-a.vcf.lab to the HoloRouter DNS (10.1.1.1). Alternatively, add static hosts file entries for sddc-manager.site-a.vcf.lab (10.1.1.5), vcenter.site-a.vcf.lab (10.1.1.6), nsx-manager.site-a.vcf.lab (10.1.1.10).

nslookup vcenter.site-a.vcf.lab resolves to 10.1.1.6 from your workstation
DNS resolution is the #1 overlooked step. Without it, certificate validation will fail and browser access to management UIs will show security warnings. The community thread 'External Jumpserver Access' (4 replies, RESOLVED) walks through this exact scenario.
Step 4

Open your workstation browser and navigate to https://vcenter.site-a.vcf.lab (accept the self-signed certificate). Verify you can log in.

vSphere Client accessible from your physical workstation
Step 5

Take a snapshot of the entire Holodeck instance. In PowerShell on HoloConsole: snapshot all VMs in the management pod using: Get-VM -Name 'Holo-*' | New-Snapshot -Name 'holodeck-02-complete' -Description 'Post management domain deployment - all components healthy' -Memory:$false -Quiesce:$false

Snapshots created for all Holodeck VMs
Exclude memory snapshots to save significant disk space. The VMs will need to be rebooted after a revert, but it's much faster than re-deploying.

Validation Gate

Check: From workstation browser: (1) https://vcenter.site-a.vcf.lab loads, (2) https://sddc-manager.site-a.vcf.lab loads, (3) Get-VM -Name 'Holo-*' | Get-Snapshot shows holodeck-02-complete snapshot on all VMs.

Expected: External access working for all three management UIs + clean snapshot in place for all pod VMs

Common Errors

Can ping management IPs but browser shows 'connection refused' or certificate error
Cause: DNS not configured — browser is trying to connect by IP but the management services expect FQDN-based access with matching certificates
Fix: Add DNS entries or hosts file entries as described in Step 3. Use FQDNs, not IPs, for browser access.
📋 KB: Thread 3: External Jumpserver Access
Webtop (HoloConsole) browser is extremely slow or unresponsive
Cause: HoloConsole VM has insufficient resources or the Guacamole service is overloaded
Fix: Increase HoloConsole VM memory to 8 GB. Use external access (direct workstation browser) instead of the webtop for daily work.
📋 KB: Thread 45: Slow mgmt with webtop

Final Validation

The management domain is fully deployed and externally accessible. All five management plane components (SDDC Manager, vCenter, NSX Manager, 4x ESXi hosts, Cloud Builder) are healthy. A clean snapshot is in place for future labs.

✓ SDDC Manager Dashboard: management domain Active → Active with 4 hosts, 1 cluster

✓ vCenter Cluster: 4 hosts connected, vSAN green, HA/DRS on → All green, no alarms

✓ NSX Manager: all host transport nodes Success/Up → 4/4 transport nodes healthy

✓ External access: FQDN-based UI access from workstation → Three management UIs reachable by FQDN

✓ Snapshot: holodeck-02-complete exists on all pod VMs → Snapshot present for rollback

Cleanup / Restore

Snapshot: holodeck-02-complete

• Snapshot all Holodeck VMs as 'holodeck-02-complete' (already done in Task 6)

• Close any open browser tabs to management UIs to free HoloConsole resources

• Document the IP-to-FQDN mapping in your lab notebook for reference in subsequent labs

Design Reflection (VCDX)

A VCDX panelist examining a VCF management domain design would probe: Why four hosts instead of three? What is the failure domain boundary? How does the management domain's availability model differ from workload domains? What are the implications of running SDDC Manager as a single instance (no HA)? How would you size the management cluster in a production environment where nested virtualization overhead doesn't exist? Be prepared to explain why the Holodeck configuration (4 ESXi hosts, single-fault vSAN) is a learning configuration, not a production reference architecture.

Requirements

  • Management domain must host SDDC Manager, vCenter, NSX Manager, and provide compute for lifecycle operations
  • All management services must be accessible from the operator workstation
  • Environment must be restorable to a known-good state for repeatable lab exercises

Constraints

  • Nested virtualization imposes ~15-25% performance overhead vs bare-metal
  • Single physical host = single fault domain (no host-level HA in nested environment)
  • Holodeck default resource sizing limits workload domain expansion
  • Network isolation via HoloRouter prevents direct L2 adjacency with physical infrastructure

Assumptions

  • Physical host has sufficient resources (512 GB RAM, 64 cores, 2 TB SSD)
  • Internet connectivity is available for content downloads (or offline depot is pre-staged)
  • VCF licensing is available (Holodeck provides evaluation licenses)
  • Operator has basic PowerShell and vSphere administration skills

Risks

  • Resource exhaustion on physical host causes cascading failures across all nested VMs — IMPACT: full lab loss, MITIGATION: snapshots + resource monitoring
  • Holodeck Toolkit version incompatibility with VCF content pack — IMPACT: deployment failure, MITIGATION: pre-validate manifest checksums
  • HoloRouter failure isolates entire nested environment — IMPACT: total management plane outage, MITIGATION: snapshot HoloRouter separately, know the FRR recovery procedure
  • Nested vSAN performance may not represent production behavior — IMPACT: misleading performance baselines, MITIGATION: use vSAN health checks but don't benchmark nested I/O

Self-Assessment Discussion Prompts

  1. Why does VCF require a minimum of 4 hosts for the management domain? What would change with 3 hosts?
  2. The HoloRouter is a single point of failure. In production, what would replace its function? (Answer: physical ToR switches + BGP peering or static routes)
  3. If SDDC Manager becomes unavailable, can you still manage vCenter and NSX directly? What capabilities are lost?
  4. How does the VCF bring-up sequence enforce ordering (Cloud Builder -> SDDC Manager -> vCenter -> NSX)? Why can't these be deployed in parallel?
  5. What is the difference between vSAN FTT=1 (RAID-1) and FTT=0 in the context of a 4-node nested lab vs production?
  6. If you needed to add a workload domain to this environment, what additional resources and configuration would be required?

Extensions

Deploy a VCF 5.2.x Management Domain for Comparison

Repeat this lab using the VCF 5.2.x content manifest to experience the differences in bring-up workflow, component versions (vCenter 8.0, NSX 4.x), and SDDC Manager UI. Document 5 specific differences between the 5.2.x and 9.0.x deployment experiences.

same

Deploy with the -ManagementOnly Flag

Re-deploy using Start-HoloDeckInstance with -ManagementOnly to skip VCF Automation. Compare the resulting management domain to the full deployment. Identify which Day 2 operations require VCF Automation and which can be done via SDDC Manager alone.

same

Dual-Site Holodeck Deployment

Configure a second Holodeck instance as Site B with cross-site networking (different IP ranges). This exercises the dual-site Holodeck configuration documented in the community thread 'Holodeck 9.0.2 dual-site IP config' and prepares you for VCDX stretched cluster and disaster recovery design discussions.

harder

Deliberately Introduce and Recover from a Deployment Failure

Intentionally misconfigure one element (wrong NSX bundle version, insufficient memory, invalid VLAN) to trigger a known failure from the community KB. Practice interpreting the error logs, identifying root cause using the playbook, and recovering without a full redeploy.

harder

⚠ Known Pitfalls (from Community KB)

Holodeck vcf 9 - Cannot select datastore RESOLVED
Problem: ESX VMs created but datastore selection fails during instance creation
Resolution: Verify physical datastore name, capacity, and accessibility. Clean up orphaned VMs from failed attempts.
Unable to deploy additional Workload Domain RESOLVED
Problem: Workload domain deployment fails after management domain is healthy
Resolution: Licensing and resource validation issues — ensure evaluation licenses are applied and additional hosts are commissioned
Issue with legacy CPU support (boot.cfg) fail deploy RESOLVED
Problem: Deployment fails on older hardware with legacy CPUs — boot.cfg setting not applied
Resolution: Add allowLegacyCPU=TRUE to nested ESXi boot.cfg before the Cloud Builder bring-up
fail to deploy vcf 9.0.2.0 RESOLVED
Problem: Repeated deployment errors across VCF 9.0.x versions
Resolution: Version mismatch between manifest and content pack. Align NSX bundle version with VCF requirements.
Holodeck 9.0.1 VCF Deployment fails at NSX validation RESOLVED
Problem: NSX install image validation fails during bring-up
Resolution: Download NSX 9.0.2.0.25150386 and update content manifest to match
Configuration of HoloRouter Failed. Encountered error RESOLVED
Problem: HoloRouter configuration step fails during Prepare phase
Resolution: DHCP for management IP resolved the issue. Ensure portgroup has VLAN trunking enabled.
Waiting for FRR service LIKELY_RESOLVED
Problem: Prepare phase hangs waiting for FRR (BGP) service on HoloRouter
Resolution: Restart FRR service on HoloRouter: systemctl restart frr
Encounter Issues when Modified default ESXi Host CPU & Memory RESOLVED
Problem: Only first ESXi host reflects custom CPU/memory — others keep defaults
Resolution: Customize config.json before first Prepare. Destroy and re-prepare if already partially deployed.

References

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