Academy/Holodeck Lab Setup & Operations/Holodeck Toolkit Installation and Content Staging
This lab targets VCF 9.0.2

Holodeck Toolkit Installation and Content Staging

VCF 9.0.2Beginneradminarchitectvcdx⏱ 90 min

This foundational lab applies to VCF 9.0.x deployments on single-host Holodeck pods. The toolkit version 9.0.2.19 supports VCF 5.2.x through 9.0.2. Older Holodeck versions (1.x) are not compatible with VCF 9.0.x.

Objectives

  • Validate physical ESXi 8.0 Update 3 host meets minimum hardware requirements for Holodeck deployment
  • Install and verify the Holodeck Toolkit PowerShell module
  • Download and stage VCF content packs (ESXi ISO, OVAs, NSX bundles) to the correct directory structure
  • Create and validate a Holodeck deployment configuration file with version-aligned parameters
  • Execute a pre-flight checklist and establish a baseline snapshot for subsequent labs

Prerequisites

Clean single ESXi 8.0 Update 3 host with no existing Holodeck instances, sufficient resources (512 GB RAM, 64 cores, 2 TB SSD/NVMe storage), nested virtualization enabled in BIOS, network configured with one or more port groups supporting VLAN trunking, NTP and DNS resolvable from management network

Required skills:

  • ESXi host installation and basic configuration
  • PowerShell fundamentals — navigation, running cmdlets, importing modules
  • JSON file editing and validation
  • Network troubleshooting — PING, route commands, port group configuration
  • Snapshot management in vSphere
📸 Starting State: S0-52 — Fresh Host (VCF 5.2)

Lab Environment

Single physical ESXi 8.0.x host. The lab does NOT deploy any VMs yet — it only installs the Holodeck Toolkit and stages content. The physical host's network is configured with port groups in VLAN trunking mode to support the nested environment that will be built in subsequent labs. Minimum topology: physical ESXi + management workstation or jump host with PowerShell + internet connectivity.

graph TB
  WST[Management Workstation] -->|HTTPS, SSH| PHESXI[Physical ESXi 8.0.x]
  WST -->|HTTPS| PBS[Broadcom Support Portal]
  PHESXI -->|Mgmt VLAN| VLAN1[VLAN 1644 Mgmt]
  PHESXI -->|vMotion VLAN| VLAN2[VLAN 1645 vMotion]
  PHESXI -->|vSAN VLAN| VLAN3[VLAN 1646 vSAN]
  PHESXI -->|NSX TEP VLAN| VLAN4[VLAN 1647 NSX Host TEP]
  PHESXI -->|NSX Edge TEP VLAN| VLAN5[VLAN 1648 NSX Edge TEP]
  PHESXI -->|Local SSD/NVMe| STORE[Content Staging Directory: /vmfs/volumes/datastore1/holodeck-content]

IP Addressing

NetworkPurposeVLAN
169.254.1.0/24Physical ESXi host out-of-band management (iDRAC, iLO, etc.)Native/OOB
10.1.1.0/20Reserved for future nested management network (will be configured in holodeck-02)VLAN 1644 (assigned but not yet routed)
10.1.1.0/24Reserved for future nested ESXi management (will be configured in holodeck-02)VLAN 1644 (assigned but not yet routed)

Credentials

SystemUsernamePassword
Physical ESXi HostrootSet during ESXi 8.0 installation. Must be strong (length >= 8, mixed case, numbers, special chars).
Broadcom Support PortalYour Broadcom support account emailCorporate SSO or personal Broadcom account — required to download VCF content packs
Management Workstation (for PowerShell)AdministratorWindows administrator credentials if running PowerShell Core on Windows; sudo if on Linux/Mac

Tasks

Task 1 Validate physical ESXi host hardware and nested virtualization

availability

The Holodeck Toolkit will fail silently or produce cryptic errors if the physical host doesn't meet minimum specs. VCDX candidates must understand the infrastructure constraints that underpin the lab environment — this mirrors the VCF Planning & Preparation Workbook checklist in production. Validating nested virtualization (vHV) up front prevents 2+ hours of wasted deployment attempts.

Step 1

Connect to the physical ESXi host via SSH (or vSphere Client). Open a root shell: ssh root@<esxi-host-ip>

ESXi shell prompt (or vSphere Client is open)
Step 2

Verify ESXi version: esxcli system version get

Version: 8.0.0 or higher. Build number >= 22380479 (8.0 Update 3)
VCF 9.0.2 requires ESXi 8.0 Update 3 minimum. Earlier versions (8.0.0, 8.0.1) will be rejected by Holodeck Toolkit with 'ESXi version not compliant' error. See KB thread 8.
Step 3

Verify nested virtualization support (vHV): esxcli system settings kernel list | grep vmkAllowNested or check vSphere Client: ESXi host > Configure > System > Processors. Look for 'Nested Page Tables' (Intel EPT / AMD NPT).

vmkAllowNested is enabled, or UI shows hardware-assisted nested paging supported
If vHV is disabled in BIOS, you'll need to reboot the physical host and enable it in BIOS. Common on new servers where it's disabled by default.
Step 4

Check total physical RAM: esxcli hardware memory get

Physical Memory: >=512 GB (total usable, not installed). Holodeck requires at minimum 512 GB; 768 GB or more is recommended for headroom.
Hosts with <512 GB will fail Holodeck's pre-flight checks. The Toolkit calculates available RAM after ESXi kernel overhead; report the 'Physical Memory' figure from this command, not BIOS-reported installed RAM.
Step 5

Check CPU core count: esxcli hardware cpu global get (CPU Threads = logical cores)

Logical cores: >= 64 cores. Holodeck default config allocates 12 vCPU per nested ESXi host (4 hosts = 48 vCPU) plus overhead for management VMs.
If you have 48-63 cores, you can still deploy but must reduce the nested ESXi count from 4 to 3 in config.json (see Task 4).
Step 6

Check available datastore space: esxcli storage filesystem list | grep vmfs or in vSphere Client: ESXi host > Storage > Datastores

At least one datastore with >= 2 TB free space. Content staging requires ~500 GB; nested VM deployment requires an additional 1.5+ TB depending on configuration.
Many deployment failures stem from filling the datastore mid-deployment. Monitor free space aggressively. The community thread 'Cannot select datastore' (15 replies) was almost entirely datastore capacity/naming issues.
Step 7

Verify network configuration: Check port groups support VLAN trunking. In vSphere Client: ESXi host > Virtual Switches > (select vDS if using distributed switches). Confirm at least one port group with VLAN trunk allowed (VLAN 1-4094 or VLAN 1644-1648 range).

At least one port group configured with VLAN trunking capability. VLAN range 1644-1648 should not conflict with existing production VLANs.
If using physical switches, confirm the uplink port is configured for VLAN trunking (not access mode). Tag all guest traffic with its VLAN.
Step 8

Verify NTP and DNS: esxcli system ntp get and esxcli system hostname get. Ensure NTP is synchronized and DNS resolvers are set.

NTP status shows synchronized or higher. DNS searches include a valid domain. Example: nslookup broadcom.com should resolve.
Holodeck build-up is extremely sensitive to clock skew and DNS failures. If NTP is not synchronized at this stage, the bring-up will fail with obscure SSL certificate errors later. This is a leading cause of nested VM deployment failures.

Validation Gate

Check: Create a validation checklist: ESXi 8.0 U3+: YES/NO, vHV enabled: YES/NO, RAM >= 512GB: YES/NO, Cores >= 64: YES/NO, Free datastore >= 2TB: YES/NO, VLAN trunking configured: YES/NO, NTP synchronized: YES/NO, DNS resolving: YES/NO

Expected: All 8 items checked YES. If any is NO, document the gap and remediate before proceeding.

Common Errors

Holodeck Toolkit reports 'ESXi version not compliant'
Cause: Physical ESXi is version 8.0.0 or 8.0.1 instead of 8.0 Update 3
Fix: Upgrade physical ESXi to 8.0 Update 3 (build 22380479 or later). Plan 15-30 minutes for the upgrade + reboot.
Nested VMs are extremely slow or freeze frequently
Cause: vHV not enabled in BIOS — nested VMs fall back to software emulation
Fix: Reboot the physical host, enter BIOS, enable 'Intel VT-x (EPT)' or 'AMD-V (NPT)' (varies by hardware), save and exit. Reboot into ESXi. Verify with esxcli.
Datastore shows as unavailable or not listed
Cause: Datastore connectivity issue (SAS cable loose, RAID failed, SAN link down) or ESXi SCSI configuration issue
Fix: Check physical storage hardware health. For local SSD/NVMe: rescan SCSI bus (esxcli storage core adapter rescan --adapter). For SAN: verify LUN presentation and fabric connectivity.
NTP shows 'unsynchronized' or 'Not configured'
Cause: NTP service not running or NTP server unreachable
Fix: Enable NTP: esxcli system ntp set --enabled=true. Verify NTP servers are reachable (ping or nslookup). Restart NTP: esxcli system ntp start. Wait 1-2 minutes for sync.

Task 2 Install and verify the Holodeck Toolkit PowerShell module

manageability

The Holodeck Toolkit is distributed as a PowerShell module. Installation and verification are trivial but critical — a malformed installation will cause every subsequent command to fail with ambiguous error messages. This task teaches the discipline of pre-flight module validation before running automation.

Step 1

On your management workstation (with internet access and PowerShell 7.0+), download the Holodeck Toolkit. Option A (Recommended): Clone from GitHub: git clone https://github.com/vmware/Holodeck.git C:\Holodeck. Option B: Download from Broadcom support portal (requires account). Option C: If GitHub is unavailable, download from Broadcom Community: https://community.broadcom.com/vmware-cloud-foundation/ (search 'Holodeck')

Holodeck directory created with subdirectories: ./PowerShell (module code), ./templates (config examples), ./docs, ./content (empty, will be filled in Task 3)
Step 2

Navigate into the Holodeck directory: cd C:\Holodeck (Windows) or cd ~/Holodeck (Mac/Linux with PowerShell Core)

PowerShell prompt in the Holodeck root directory
Step 3

Import the Holodeck module: Import-Module ./PowerShell/Holodeck.psm1 -Verbose

No errors. Verbose output may show 'Loading module Holodeck...' and list imported functions.
If import fails with 'File not found' or 'syntax error', the module may be corrupted. Delete and re-download.
Step 4

Verify the module is loaded: Get-Command -Module Holodeck | Measure-Object

Count: >= 20 cmdlets. Key functions should include: New-HoloDeckConfig, New-HoloDeckInstance, Start-HoloDeckInstance, Get-HoloDeckInstance, Remove-HoloDeckInstance
List all functions: Get-Command -Module Holodeck | Select-Object -ExpandProperty Name
Step 5

Check Holodeck module version: Get-Module Holodeck | Select-Object -ExpandProperty Version

Version 2.1.x (exactly as your downloaded version). If version is <2.1.0, upgrade to 2.1.x for VCF 9.0.2 compatibility.
Step 6

Verify connectivity to the physical ESXi host: Get-HoloDeckHealth -TargetHost <esxi-host-ip> -TargetHostUser root -TargetHostPassword <password> (alternatively, if prompts are preferred: Get-HoloDeckHealth will ask interactively)

Summary showing physical host reachable, version compatible, resources available. Example: 'Health Status: PASS, Available RAM: 512 GB, Free Datastore: 2.1 TB, ESXi Version: 8.0.3'
If this fails, Holodeck cannot reach your ESXi host. Verify: (a) network connectivity (ping), (b) SSH enabled on ESXi (Configuration > Services > SSH), (c) firewall rules allowing inbound SSH (port 22). See KB thread 42 for similar pre-flight issues.

Validation Gate

Check: Run: (Get-Command -Module Holodeck | Measure-Object).Count -ge 20, AND Get-Module Holodeck | Select-Object -ExpandProperty Version reports 9.0.2.19, AND Get-HoloDeckHealth passes.

Expected: All three checks pass. You are ready to stage content.

Common Errors

'Get-Command -Module Holodeck' returns 0 functions
Cause: Module import failed silently or module not in PowerShell module path
Fix: Verify module file exists: Test-Path ./PowerShell/Holodeck.psm1. Re-import explicitly: Import-Module ./PowerShell/Holodeck.psm1 -Force. Check for syntax errors in the .psm1 file.
Get-HoloDeckHealth fails with 'Cannot connect to host'
Cause: SSH not enabled on physical ESXi or firewall blocking connection
Fix: In vSphere Client or ESXi console: Configuration > Services > SSH > Start. Verify no firewall rules blocking SSH (port 22). Test: ssh root@<esxi-ip> from workstation.
Module version is 1.x, not 2.1.x
Cause: Downloaded an older version of Holodeck or didn't update after initial download
Fix: Download version 9.0.2.19 from GitHub (releases page) or Broadcom support. Delete ./PowerShell and re-clone or re-download to ensure version match.

Task 3 Download and stage VCF content packs

manageability

Holodeck orchestrates the deployment of nested infrastructure using pre-built ISOs and OVAs. These content packs are large (15+ GB total) and version-specific. Staging them correctly (right directory, right versions, verified checksums) is the single most common failure point in community forums. VCDX candidates must understand the content manifest as a bill of materials — in production, this parallels license manifest and hardware inventory documentation.

Step 1

Create the content staging directory on your management workstation (or on the physical ESXi datastore for faster network performance). Recommended: /vmfs/volumes/<datastore>/holodeck-content or C:\Holodeck\content if staging locally first.

Directory created and writable (test with: mkdir test; rmdir test)
Step 2

Download VCF 9.0.2 content pack from Broadcom support portal: https://support.broadcom.com (Search: 'VMware Cloud Foundation 9.0.2' or 'Holodeck'). Required files: (a) ESXi 8.0 Update 3 ISO (~670 MB), (b) vCenter Server OVA 8.0.x (~1.2 GB), (c) NSX Manager bundle 9.0.2 (~1.8 GB), (d) SDDC Manager OVA 9.0.2 (~1.2 GB), (e) Cloud Builder OVA 9.0.2 (~1.1 GB). Total: ~6-7 GB. Alternatively, if you have GitHub access: https://github.com/vmware/Holodeck/releases (pre-built manifest for 9.0.2)

All 5 files downloaded to the staging directory. Verify file sizes match documentation.
This step is network-dependent and may take 30+ minutes on slower connections. Use a download manager or split the downloads. Do NOT interrupt mid-download — corrupted ISOs/OVAs will cause silent failures.
Step 3

Create a manifest file (manifest-9.0.2.json) in the content directory. Template: { 'vcfVersion': '9.0.2', 'components': [ { 'name': 'ESXi', 'filename': 'ESXi-8.0.3-XXXX.iso', 'sha256': '<hash>', 'size': 'XX GB' }, {...} ] }. For each file, compute its SHA256 hash: (Windows) certutil -hashfile <filename> SHA256 or (Linux/Mac) sha256sum <filename>

manifest-9.0.2.json created with all 5 components listed and SHA256 hashes populated
Many community members skip this step and hardcode paths instead. Holodeck's manifest validation is strict — it will reject mismatched hashes. See KB thread 60.
Step 4

Verify manifest completeness: In PowerShell, run: $manifest = Get-Content ./manifest-9.0.2.json | ConvertFrom-Json; $manifest.components | ForEach-Object { if (!(Test-Path $_.filename)) { Write-Warning "Missing: $($_.filename)" } }

No warnings. All filenames listed in the manifest exist in the content directory.
Step 5

Verify manifest checksums: For each file, recompute its hash and compare against the manifest: (Powershell) (Get-FileHash 'ESXi-8.0.3-XXXX.iso' -Algorithm SHA256).Hash should match the sha256 field in manifest. Do this for all 5 files.

All 5 hashes match. If any hash mismatches, the download was corrupted — delete and re-download.
Hash mismatches are the #1 cause of deployment failures. The community thread 'fail to deploy vcf 9.0.2.0' (12 replies) involved multiple hash failures. This is not a Holodeck bug — it's a download verification discipline issue.
Step 6

Optional but recommended: Move the content staging directory to the physical ESXi datastore to improve deployment performance. Example: scp -r C:\Holodeck\content root@<esxi-host>:/vmfs/volumes/datastore1/holodeck-content. Update the content path in config.json (Task 4) to reference the ESXi-local path.

Content directory visible on ESXi datastore. Verify: ssh root@<esxi-host> 'ls -lah /vmfs/volumes/datastore1/holodeck-content'
Storing content on the ESXi datastore reduces deployment time by 20-30% because the Prepare phase doesn't have to copy over the network.

Validation Gate

Check: List all files in content directory: ls -lah /vmfs/volumes/datastore1/holodeck-content. Verify: (1) all 5 files present, (2) manifest-9.0.2.json exists and is valid JSON, (3) all file sizes match expected (~6-7 GB total), (4) all SHA256 hashes match.

Expected: 5 content files staged, manifest validated, total size >= 6.5 GB

Common Errors

Deployment fails: 'Manifest invalid' or 'Content pack version mismatch'
Cause: manifest-9.0.2.json path not set in config.json, or manifest JSON is malformed, or files listed in manifest don't exist
Fix: Verify config.json contentManifestPath points to manifest-9.0.2.json. Validate manifest JSON: $manifest = Get-Content manifest-9.0.2.json | ConvertFrom-Json (should not error). Verify all referenced files exist.
📋 KB: Thread 60: Deployment issues Holodeck Toolkit v5.2x - manifest invalid?
Deployment hangs or fails on 'ESXi ISO extraction'
Cause: ESXi ISO file is corrupted (download interrupted, hash mismatch not caught)
Fix: Recompute hash: (Get-FileHash 'ESXi-8.0.3-XXXX.iso' -Algorithm SHA256).Hash. If it doesn't match the manifest, delete and re-download the ISO from Broadcom.
Deployment progresses to OVA deployment, then fails with 'OVA signature invalid'
Cause: OVA file (vCenter, SDDC Manager, Cloud Builder) is incomplete or corrupted
Fix: Verify OVA file size matches Broadcom documentation (~1.1-1.2 GB each). Recompute hash. If hash matches but deployment fails, contact Broadcom support — the OVA itself may be defective in that release.
Cannot download content from Broadcom portal (network blocked, account issues)
Cause: Broadcom support account not active, download link expired, or corporate firewall blocking CDN
Fix: Verify Broadcom account is active (log in at https://support.broadcom.com). Check download link hasn't expired (re-generate if needed). If firewall-blocked, use a personal machine or request IT to whitelist Broadcom CDN domains.

Task 4 Create and validate the Holodeck deployment configuration

manageability

The deployment configuration (config.json) is the source of truth for all Holodeck instances. Every IP address, hostname, VLAN, password, resource sizing, and version is defined here. This task mirrors the VCF Planning & Preparation Workbook — VCDX panelists will probe your ability to translate business requirements (performance, availability, licensing) into infrastructure parameters. A misconfigured config.json cascades into hours of deployment debugging.

Step 1

Copy the Holodeck config template: Copy-Item ./PowerShell/templates/config-template.json ./templates/config.json or if template doesn't exist, manually create config.json with the structure shown in Holodeck documentation.

config.json exists in ./templates/ directory and is valid JSON
Step 2

Edit config.json. Key fields to set: (a) targetHost: <physical-esxi-host-ip>, (b) targetHostUser: root, (c) targetHostPassword: <esxi-root-password>, (d) vcfVersion: '9.0.2', (e) contentManifestPath: './templates/manifest-9.0.2.json' (relative to Holodeck root), (f) holoRouterExternalIP: <accessible-ip-on-your-network> (e.g. 192.168.1.100 — must be routable from your workstation), (g) datastoreName: <name-of-esxi-datastore> (e.g. 'datastore1')

config.json edited with all mandatory fields set. JSON is valid (no syntax errors).
Validate JSON: Get-Content ./templates/config.json | ConvertFrom-Json (should not error)
Step 3

Configure management cluster resources. Locate the managementCluster section in config.json. Set: (a) hostCount: 4 (or 3 if your host has 48-63 cores), (b) cpuPerHost: 12, (c) memoryPerHostGb: 96. Verify total resource consumption: (hostCount cpuPerHost) + 8 (overhead) = total vCPU, and (hostCount memoryPerHostGb) + 64 (overhead) = total GB. Must not exceed 80% of physical resources.

For 512 GB / 64-core host: 4 hosts x 12 vCPU + 8 = 56 vCPU (88% of 64), 4 hosts x 96 GB + 64 = 448 GB (87% of 512). Acceptable.
Over-subscribing resources is the #2 cause of deployment failure after datastore issues. If you later see timeouts or VM crashes during deployment, under-provisioning is the likely culprit. See KB thread 44 'Issue while verifying target hardware'.
Step 4

Configure networking. Locate the network section. Set: (a) managementCIDR: '10.1.1.0/20', (b) managementVlan: 1644, (c) vlanRange: [1644, 1645, 1646, 1647, 1648], (d) holoRouterExternalIP: <your-network-accessible-IP>. Verify the VLAN range doesn't conflict with production networks. Verify the external IP is on a network you can route to.

Network settings configured. Verify no VLAN conflicts by checking existing port groups on ESXi: esxcli network vswitch standard portgroup list
Step 5

Set passwords and credentials. Locate sections for esxiPassword, cbPassword, sddcPassword. Set strong passwords (>= 8 chars, mixed case, numbers, special chars). These will be used for nested ESXi, Cloud Builder, SDDC Manager, and vCenter access in subsequent labs. Document them securely (password manager, encrypted file, etc.).

All password fields set to strong values. Document the values somewhere you'll remember them for holodeck-02.
Step 6

Verify config.json completeness and syntax: $config = Get-Content ./templates/config.json | ConvertFrom-Json; Write-Host "vcfVersion: $($config.vcfVersion), Target Host: $($config.targetHost), Manifest: $($config.contentManifestPath)"

Script outputs all critical values without error
Step 7

Optional: Run a dry-run validation without deploying: New-HoloDeckConfig -ConfigFile ./templates/config.json -ValidateOnly. This will check for obvious errors without allocating resources.

Validation passes or lists specific errors you can fix before committing to deployment

Validation Gate

Check: Checklist: (1) config.json is valid JSON, (2) vcfVersion = 9.0.2, (3) targetHost is reachable, (4) contentManifestPath file exists, (5) resource sizing <= 80% of physical host capacity, (6) VLAN range is clear, (7) holoRouterExternalIP is routable, (8) all passwords are set, (9) New-HoloDeckConfig -ValidateOnly passes (if supported by your Toolkit version)

Expected: All 9 items checked. Config is ready for Prepare phase in holodeck-02.

Common Errors

config.json edited but Prepare fails with 'Cannot find path to config'
Cause: contentManifestPath in config.json uses relative path that doesn't resolve, or manifest file doesn't exist
Fix: Verify file exists: Test-Path ./templates/manifest-9.0.2.json. If using absolute path, ensure no UNC escaping issues: $config.contentManifestPath should be a valid file path.
Deployment starts but only the FIRST nested ESXi host gets custom CPU/memory; others use defaults
Cause: config.json was modified AFTER a partial Prepare — Holodeck caches host specs on first Prepare, and won't update them on rerun
Fix: Destroy the current instance: Remove-HoloDeckInstance -InstanceID <id>. Then re-edit config.json. Then re-run Prepare from scratch.
📋 KB: Thread 0: Encounter Issues when Modified default ESXi Host CPU & Memory
Prepare fails: 'HoloRouter configuration failed'
Cause: holoRouterExternalIP is not routable or accessible from your workstation, or VLAN trunking not enabled on the port group
Fix: Verify holoRouterExternalIP is on a network you can reach from your management workstation. Test: ping <external-ip>. Verify port group has VLAN trunking enabled: esxcli network vswitch dvs portgroup list | grep -i 'vlan range: 1-4094'
Resource validation fails: 'Insufficient available resources'
Cause: Calculated resource consumption exceeds 80% of physical host, or datastore has insufficient space
Fix: Reduce hostCount from 4 to 3, or reduce cpuPerHost from 12 to 8, or increase physical host resources (add RAM, add CPU, add storage).

Task 5 Execute pre-flight checklist and create baseline snapshot

recoverability

Before deploying infrastructure, production operations always run a pre-flight checklist: power checks, cable verification, firmware versions, license availability, backup policies. This mirrors the VCF Planning & Preparation phase. Creating a baseline snapshot now ensures you can rollback to a known-good state if subsequent labs fail.

Step 1

Document your Holodeck environment baseline. Create a file: deployment-baseline.txt with the following: (a) Physical ESXi version: esxcli system version get | grep Version, (b) Total RAM: esxcli hardware memory get | grep 'Physical Memory', (c) Total cores: esxcli hardware cpu global get, (d) Free datastore space: esxcli storage filesystem list | grep vmfs, (e) NTP status: esxcli system ntp get, (f) Holodeck Toolkit version: Get-Module Holodeck | Select-Object -ExpandProperty Version, (g) Content files checksums: Get all 5 content pack file hashes, (h) config.json content (redact passwords): Get-Content ./templates/config.json

deployment-baseline.txt created with all 8 items documented
Step 2

Run final health check before Prepare: Get-HoloDeckHealth -TargetHost <esxi-ip> -TargetHostUser root. Verify all checks pass. If any check fails, remediate it before proceeding (e.g., start NTP, enable SSH).

Health check passes with green status on all items
Step 3

Create a baseline snapshot of the physical ESXi host (optional but recommended): In vSphere Client, right-click the ESXi host VM (if it's a VM itself, which it isn't in production but may be in a nested lab scenario) or skip this step if it's a physical machine. If you can't snapshot the host itself, document that this is a physical machine with no pre-deployment snapshot available.

Baseline snapshot created OR documented that physical host cannot be snapshotted
Step 4

Review the pre-flight checklist below and sign off on each item. This is your contractual commitment that you've validated the environment. For each item, you should answer 'YES' with confidence. If any item is 'MAYBE' or 'NO', halt and fix it.

Checklist completed with all YES responses
This checklist mirrors the VCF Planning & Preparation Workbook. In production VCDX implementations, panelists will ask: 'What did you validate before deploying VCF?' Be prepared to reference this checklist.
Step 5

Execute the Holodeck Prepare phase (you are NOT running Start yet — Prepare only stages content and validates): New-HoloDeckInstance -ConfigFile ./templates/config.json -Verbose

Prepare completes successfully. Output ends with 'Prepare phase completed successfully.' or similar. Instance ID is printed (e.g., 'holodeck-9022-01'). Log file created at ./logs/prepare-*.log
Step 6

Verify Prepare succeeded: Get-HoloDeckInstance | Format-Table -Property InstanceId, State, VcfVersion. Confirm State shows 'Prepared'.

Instance listed with State: Prepared, VcfVersion: 9.0.2
Step 7

Take a snapshot of the Holodeck state after successful Prepare: Get-VM -Name 'Holo-*' | New-Snapshot -Name 'holodeck-01-complete' -Description 'Post Prepare - content staged, HoloRouter ready, config validated' -Memory:$false

Snapshot created for all Holodeck VMs (HoloRouter, HoloConsole if already deployed, etc.)

Validation Gate

Check: Checklist completed: (1) deployment-baseline.txt populated, (2) Get-HoloDeckHealth passes, (3) New-HoloDeckInstance completed successfully, (4) Get-HoloDeckInstance shows State=Prepared, (5) Snapshot 'holodeck-01-complete' exists on all Holodeck VMs

Expected: All items complete. Lab holodeck-01 is finished. You are ready for holodeck-02 (management domain deployment).

Common Errors

Prepare phase hangs at 'Configuring HoloRouter' for >15 minutes
Cause: HoloRouter BGP/FRR service is not starting, or DHCP not available for management IP
Fix: Wait 2-3 more minutes. If still stuck, cancel (Ctrl+C). Check HoloRouter logs via SSH (ssh admin@10.1.1.1 if reachable) or destroy and retry: Remove-HoloDeckInstance
Prepare fails with 'Cannot connect to target host'
Cause: Physical ESXi host is unreachable (network issue, wrong IP, firewall blocking SSH)
Fix: Verify connectivity: ping <esxi-ip>. Verify SSH is enabled: esxcli network firewall ruleset list | grep sshServer. Verify credentials in config.json are correct.
Pre-flight health check shows 'ESXi version not compliant'
Cause: Physical ESXi is <8.0 Update 3
Fix: Upgrade to ESXi 8.0 Update 3 before proceeding.

Final Validation

Holodeck Toolkit is installed, VCF 9.0.2 content packs are staged and verified, deployment configuration is created and validated, and a successful Prepare phase has completed. The physical ESXi host is confirmed ready for the management domain deployment (holodeck-02). A baseline snapshot is in place for rollback.

✓ Holodeck Toolkit version → 9.0.2.19, verified with Get-Module HoloDeck | Select-Object -ExpandProperty Version

✓ Physical ESXi host version → 8.0 Update 3 (build >= 22380479), verified with esxcli system version get

✓ Physical host resources → RAM >= 512 GB, Cores >= 64, Free datastore >= 2 TB, all verified

✓ Nested virtualization enabled → vHV enabled in BIOS and ESXi (vmkAllowNested, EPT/NPT supported)

✓ VCF content packs staged → 5 files in content directory (ESXi ISO, vCenter OVA, SDDC Manager OVA, Cloud Builder OVA, NSX bundle) with valid checksums

✓ Manifest file → manifest-9.0.2.json exists with all 5 components and SHA256 hashes

✓ Holodeck config.json → Valid JSON, all mandatory fields set, resources <= 80% of physical capacity, VLAN range clear

✓ Prepare phase completed → Get-HoloDeckInstance shows State: Prepared with matching VcfVersion: 9.0.2

✓ Baseline snapshot → holodeck-01-complete snapshot exists on all Holodeck VMs

Cleanup / Restore

Snapshot: holodeck-01-complete

• Snapshot has been created as 'holodeck-01-complete' on all Holodeck VMs

• Document the Instance ID from Get-HoloDeckInstance output — you'll need it for holodeck-02

• Document holoRouterExternalIP and config.json paths — they're referenced in holodeck-02

• Store deployment-baseline.txt safely — it's a reference artifact if things go wrong

Design Reflection (VCDX)

A VCDX panelist would probe: 'How did you validate that your lab infrastructure was ready before deploying VCF?' The answer should include the exact pre-flight checklist you completed (ESXi version, vHV, resources, NTP, DNS, datastore, VLAN). They will ask: 'What would you do if the physical host ran out of storage mid-deployment?' (Answer: Have a rollback plan — take snapshots, monitor datastore free space during Prepare and Start).
They will also ask: 'How does the Holodeck Toolkit installation process differ from deploying VCF in production?' (Answer: Holodeck is a PowerShell automation wrapper; in production, you'd run Cloud Builder manually or via Automation, and manage dependencies differently). Be ready to explain the assumptions you made (nested virtualization overhead, resource overhead calculations, VLAN naming scheme) and the risks (single physical host = single failure domain).

Requirements

  • Physical infrastructure capable of running nested virtualization with minimum 512 GB RAM, 64 cores, 2 TB SSD/NVMe storage
  • Holodeck Toolkit version 2.1.x compatible with VCF 9.0.2 content pack
  • VCF 9.0.2 content packs (5 components) downloaded, staged, and checksummed
  • Deployment configuration (config.json) created with resource sizing that doesn't exceed 80% of physical host capacity
  • Pre-flight validation completed and baseline snapshot in place

Constraints

  • Holodeck Toolkit runs only on Windows PowerShell 7.0+ or PowerShell Core on Mac/Linux
  • Content pack versioning is strict — manifest mismatch with VCF version causes deployment failure
  • Nested virtualization requires vHV support in CPU and BIOS (not available on older or budget hardware)
  • Single physical host = single fault domain — entire lab is lost if the host fails. No HA, no redundancy.
  • Network isolation via HoloRouter requires VLAN trunking and specific IP ranges (10.1.1.0/16) that may not match production network design
  • Resource contention during deployment (background services, concurrent VMs) can cause timeouts or silent failures

Assumptions

  • Physical ESXi host is a dedicated machine (not shared with production or other teams' labs)
  • Internet connectivity is available for downloading content or offline depot is pre-staged
  • Management workstation has PowerShell 7.0+, git, and SSH client installed
  • Broadcom support account is active and has access to download VCF content packs
  • VLAN trunking can be enabled on the ESXi port groups without impacting production networks
  • Network documentation and VLAN allocation is up-to-date and shared with the lab operator
  • NTP and DNS are synchronized across the lab and management networks
  • Operator has root/administrative access to the physical ESXi host

Risks

  • Content pack download interrupted or corrupted — IMPACT: silent deployment failure with cryptic error messages, MITIGATION: validate checksums immediately after download, implement retry loop
  • config.json resource miscalculation causes resource exhaustion mid-deployment — IMPACT: cascade failures, VM crashes, full lab loss, MITIGATION: calculate resources conservatively (<=80%), monitor datastore during Prepare and Start phases
  • Nested virtualization disabled in BIOS (common on new hardware) — IMPACT: deployment appears to start but nested VMs are extremely slow, MITIGATION: verify vHV in Task 1, save BIOS screenshots for reference
  • Holodeck Toolkit version skew with content pack version — IMPACT: cryptic manifest errors, MITIGATION: align Toolkit version (2.1.x) with content pack (9.0.2) before starting
  • Physical host clock skew or DNS failure — IMPACT: SSL certificate errors, bring-up failures in vCenter and NSX, MITIGATION: verify NTP sync and DNS resolution in pre-flight checks
  • VLAN range conflict with production infrastructure — IMPACT: network routing failures, isolated nested environment, MITIGATION: document VLAN allocation and verify no conflicts with IT before deploying

Self-Assessment Discussion Prompts

  1. Why does the Holodeck Toolkit require a minimum of 512 GB RAM? What percentage of that is overhead (ESXi kernel, Holodeck services) vs. available for nested VMs?
  2. You modified config.json after a partial Prepare, and only the first nested ESXi host got the new settings. Explain what happened and how you'd fix it without re-downloading content.
  3. The pre-flight checklist includes NTP synchronization and DNS resolution. Why are these critical to a VCF deployment that depends on SSL certificates and time-synced services?
  4. Compare the content pack validation in this lab (manifest + SHA256 hashing) to how you'd validate infrastructure readiness in production VCF. What's the analog to the manifest in a physical deployment?
  5. You have a 48-core host (just under the 64-core minimum). How would you adjust config.json to make the deployment feasible? What functionality or capacity would you sacrifice?
  6. If the Prepare phase fails midway through, can you resume it, or do you need to start over? What's the difference between a transient failure (network timeout) and a permanent one (corrupted ISO)?

Extensions

Automate Content Pack Download and Validation

Write a PowerShell script that downloads VCF 9.0.2 content packs from Broadcom support portal (via API if available, or scraping), validates checksums, and generates the manifest.json automatically. This mirrors CI/CD practices for infrastructure-as-code and prepares you for production automation discussions.

harder

Deploy Holodeck on a vSAN Cluster Instead of Single Host

Modify config.json to deploy Holodeck across a 4-node vSAN cluster (one nested Holodeck instance per node, or shared vSAN datastore). Document the differences in resource contention, network isolation, and recoverability compared to single-host deployment.

harder

Create a Multi-Version Content Manifest

Stage both VCF 9.0.2 and VCF 5.2.x content packs. Create two manifests (manifest-9.0.2.json and manifest-5.2.x.json) and document version-specific differences (component names, sizing, licensing). This prepares you for discussing upgrade paths and version coexistence.

same

Implement Content Pack Caching on a Network Share

Instead of storing content on the local ESXi datastore, configure a network-based cache (NFS share or SMB share) to store VCF content packs. Modify config.json to reference the network path. Measure deployment performance (Prepare time) with network-based vs. datastore-based content. This exercises VCDX-level infrastructure optimization thinking.

harder

⚠ Known Pitfalls (from Community KB)

Encounter Issues when Modified default ESXi Host CPU & Memory RESOLVED
Problem: Operator modifies config.json after Prepare phase has started. Only the first nested ESXi host reflects the custom CPU/memory settings; the 2nd, 3rd, and 4th hosts keep the previous defaults.
Resolution: Holodeck caches host specifications on the first Prepare run. Editing config.json after Prepare doesn't update cached specs. Solution: Destroy the instance (Remove-HoloDeckInstance), edit config.json, and re-run Prepare from scratch.
Issue with legacy CPU support (boot.cfg) fail deploy RESOLVED
Problem: Deployment fails on older hardware with legacy CPUs (pre-Nehalem Intel, pre-Bulldozer AMD). Boot.cfg compatibility flag is not set or recognized.
Resolution: Add allowLegacyCPU=TRUE to nested ESXi boot.cfg before the Cloud Builder bring-up phase. Holodeck should auto-inject this if detected, but manual override may be needed on older systems.
fail to deploy vcf 9.0.2.0 RESOLVED
Problem: Repeated deployment failures across multiple VCF 9.0.x versions. Error messages vary but consistently fail at manifest validation or NSX install image validation.
Resolution: Version mismatch between Holodeck Toolkit, manifest file, and actual content pack files. Align all three: Toolkit 2.1.x, manifest-9.0.2.json with correct SHA256 hashes, and actual ESXi ISO/OVAs/NSX bundle from Broadcom labeled 9.0.2. Re-validate checksums.
Holodeck 9.0.1 VCF Deployment fails at NSX validation RESOLVED
Problem: Deployment starts successfully but fails during the 'Validate NSX install image is available' step. NSX Manager configuration step hangs or errors.
Resolution: NSX bundle version in content pack (9.0.1.x) doesn't match what VCF 9.0.2 bring-up expects (9.0.2.x). Download NSX 9.0.2.0.25150386 from Broadcom support. Update manifest-9.0.2.json to reference correct NSX filename and recompute SHA256 hash.
Waiting for FRR service LIKELY_RESOLVED
Problem: Prepare phase hangs indefinitely at step 'Waiting for FRR service' on the HoloRouter. BGP/FRR daemon fails to start or is unresponsive.
Resolution: SSH into HoloRouter (ssh admin@10.1.1.1) and check: systemctl status frr. If service is dead, restart: systemctl restart frr. If it persists, destroy and re-prepare the Holodeck instance. May indicate insufficient resources on physical host or ESXi network configuration issue.
Configuration of HoloRouter Failed. Encountered error RESOLVED
Problem: HoloRouter configuration step fails during Prepare phase. Management IP is not assigned or HoloRouter cannot reach management network.
Resolution: DHCP for the HoloRouter management IP resolved the issue in most cases. Ensure the external port group has VLAN trunking enabled and is configured to allow DHCP. Verify no firewall rules blocking DHCP traffic on the physical ESXi network.
Holodeck vcf 9 - Cannot select datastore RESOLVED
Problem: Deployment fails during nested ESXi VM creation with error 'Cannot select datastore' or 'Datastore not found'. ESXi host reports available datastores but Holodeck cannot allocate space.
Resolution: Most common causes: (1) datastore name in config.json doesn't match ESXi datastore name exactly, (2) datastore is full or has insufficient free space (<2 TB), (3) datastore is not accessible from ESXi (connectivity issue). Solution: Verify datastore name (esxcli storage filesystem list), verify free space, and confirm connectivity.
Deployment issues Holodeck Toolkit v5.2x - manifest invalid? RESOLVED
Problem: Deployment fails with error 'Manifest invalid' or 'Content pack version mismatch'. contentManifestPath in config.json is set but manifest file doesn't exist or is malformed.
Resolution: Verify the file at contentManifestPath exists and is valid JSON (Get-Content manifest-9.0.2.json | ConvertFrom-Json). Verify all component files referenced in the manifest are present in the content directory. Verify all SHA256 hashes match actual files.

References

  • VMware Cloud Foundation 9.0 Planning and Preparation GuideTier 1 — Official
    Broadcom official documentation. Essential for understanding hardware requirements, network planning, and pre-deployment checklist. Tier 1 authority.
  • Holodeck Toolkit GitHub RepositoryTier 1 — Official
    Official Holodeck source. Includes PowerShell module, templates, examples, and issue tracker with 15+ open issues. Clone this repo to get the latest Toolkit version.
  • Broadcom Support Portal — VCF 9.0.2 DownloadsTier 1 — Official
    Official download source for VCF content packs, ISOs, OVAs, and NSX bundles. Requires Broadcom support account. All content is cryptographically signed.
  • VCF Holodeck Community ForumTier 1 — Official
    Broadcom-hosted community forum with 63 threads captured in our Holodeck KB (holodeck-kb-normalized.json). Primary source for troubleshooting deployment failures.
  • William Lam — VCF Nested Lab Deployment GuideTier 3 — Expert Blog
    William Lam is a VMware Staff Engineer and authoritative community voice. His blog covers Holodeck setup, nested VCF deployment best practices, and automation techniques.
Was this page useful?
Type to search. ↑ ↓ to move, Enter to open, Esc to close.