Holodeck Toolkit Installation and Content Staging (Holodeck 9.1)

VCF 9.1.0.0Beginneradminarchitectvcdx⏱ 90 min

Holodeck 9.1 deploys VCF 9.1.0.0, VVF 9.1.0.0 and VCF 5.2.4. Supported range: VCF 9.1.0.0 down to VCF 5.2 (9.1.0.0, 9.0.2.0, 9.0.1.0, 9.0.0.0, 5.2.4, 5.2.3, 5.2.2, 5.2.1, 5.2). Minimum nested ESX 8.0 U3. Docs list release 'May 2026'; GA publicly announced 2026-07-01 (VCF 9.1 itself GA'd 2026-05-12 per techdocs). No GitHub releases are published for vmware/Holodeck — vmware.github.io/Holodeck/9.1/ is the sole source of truth. Exact toolkit build number and PowerShell module version to be captured during the live W5 deployment.

Objectives

Validate the physical host meets Holodeck 9.1 requirements, including nested ESX 8.0 U3 minimum for the nested layer
Install and verify the Holodeck 9.1 toolkit and understand the two deployment drivers: PowerShell cmdlets vs Click-to-Deploy GitOps
Download and stage VCF 9.1.0.0 content (and optionally VVF 9.1.0.0 / VCF 5.2.4) to the correct directory structure
Create and validate a Holodeck 9.1 deployment configuration, including the new dual-site (Site A + Site B) auto-generated config pair
Execute a pre-flight checklist and establish a baseline snapshot for subsequent 9.1 labs

Prerequisites

Clean physical ESXi host with no existing Holodeck instances. Holodeck 9.1 deploys VCF 9.1.0.0, VVF 9.1.0.0, or VCF 5.2.4 (supported range VCF 9.1.0.0 down to VCF 5.2); the nested ESX layer requires minimum ESX 8.0 U3. Docs-published Holodeck 9.1 minimums (single-site VCF): 48 logical cores, 650 GB RAM, 2.2 TB NVMe (dual-site: 96 cores / 1536 GB / 5 TB). Soft-validated — deployment proceeds with less but performance is impacted, nested virtualization enabled in BIOS, VLAN-trunk-capable port groups, NTP and DNS resolvable from the management network. Verify final 9.1 sizing (GitOps/GitLab appliance and VNA overhead are open questions) against the live 9.1 toolkit.

Required skills:

ESXi host installation and basic configuration
PowerShell fundamentals — navigation, running cmdlets, importing modules
JSON file editing and validation
Git/GitOps concepts (repositories, commits, pipelines) for the Click-to-Deploy path
Network troubleshooting — PING, route commands, port group configuration
Snapshot management in vSphere

📸 Starting State: S0-91 — Fresh Host (Holodeck 9.1)

Lab Environment

Single physical ESXi host. This lab does NOT deploy nested VMs yet — it stages the Holodeck 9.1 toolkit and content and (optionally) the GitOps-enabled HoloRouter OVA. Minimum topology: physical ESXi + management workstation with PowerShell + internet connectivity.

graph TB
  WST[Management Workstation] -->|HTTPS, SSH| PHESXI[Physical ESXi Host]
  WST -->|HTTPS| PBS[Broadcom Support Portal]
  PHESXI -->|Mgmt VLAN| VLANS[VLAN trunk range — verify 9.1 defaults]
  PHESXI -->|Local SSD/NVMe| STORE[Content Staging Directory]
  WST -.->|GitOps path| HR91[HoloRouter 9.1 OVA + GitLab UI]

IP Addressing

Network	Purpose	VLAN
`10.1.0.0/20`	Default nested management supernet carried forward from the 9.0 baseline — verify 9.1 defaults against live toolkit	9.0-era default VLAN range; VLAN range handling was fixed in 9.1 — verify

Credentials

System	Username	Password
Physical ESXi Host	`root`	Set during ESXi installation. Must be strong (length >= 8, mixed case, numbers, special chars).
Broadcom Support Portal	`Your Broadcom support account email`	Corporate SSO or personal Broadcom account — required to download VCF content
HoloRouter 9.1 services (Vault :8200, Authentik :9443, Technitium :5380, Webtop :30000)	`verify against live 9.1 toolkit`	Authentik default credentials and SCIM expectations are open questions from the 9.1 announcement — capture on first live deployment

Tasks

Task 1 Validate physical host hardware and nested virtualization

availability

Holodeck fails silently or with cryptic errors if the physical host does not meet minimum specs. For 9.1 the confirmed floor is nested ESX 8.0 U3; the resource minimums below are the 9.0 baseline pending live 9.1 verification (the GitOps/GitLab appliance and VNA clusters may add overhead). Validating nested virtualization up front prevents hours of wasted deployment attempts.

Step 1

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

ESXi shell prompt (or vSphere Client is open)

Step 2

Verify physical ESXi version: esxcli system version get. Holodeck 9.1's published minimum applies to the NESTED ESX layer (8.0 U3); the physical host minimum for the 9.1 toolkit itself — verify against live 9.1 toolkit documentation (9.0 baseline required physical ESXi 8.0 U3).

ESXi version at or above the 9.1-documented physical minimum

Nested ESX below 8.0 U3 is explicitly unsupported by Holodeck 9.1. If reusing an existing nested template (e.g. shared-host labs), confirm the template is 8.0 U3 or later before any 9.1 deploy.

Step 3

Verify nested virtualization support (vHV): check vSphere Client > ESXi host > Configure > System > Processors for hardware-assisted nested paging (Intel EPT / AMD NPT), or the equivalent esxcli kernel setting.

vHV enabled / hardware-assisted nested paging supported

If vHV is disabled in BIOS, reboot the physical host and enable it. Common on new servers where it is disabled by default.

Step 4

Check total physical RAM: esxcli hardware memory get. 9.0 baseline minimum was 512 GB — verify the 9.1 minimum against live toolkit docs (GitLab + VNA overhead unknown).

Physical Memory at or above the verified 9.1 minimum (>= 512 GB per 9.0 baseline)

Step 5

Check CPU core count: esxcli hardware cpu global get. Docs-published 9.1 minimum: 48 logical cores single-site (96 dual-site).

Logical cores at or above the verified 9.1 minimum (>= 64 per 9.0 baseline)

Step 6

Check available datastore space: esxcli storage filesystem list. 9.0 baseline required >= 2 TB free (content staging ~500 GB + nested deployment 1.5+ TB) — verify 9.1 footprint.

At least one datastore with free space at or above the verified 9.1 requirement

Step 7

Verify network configuration: confirm at least one port group supports VLAN trunking and the planned VLAN range does not conflict with production. VLAN range handling was fixed in Holodeck 9.1 — verify default VLAN range and any changed -VLANRangeStart semantics against live 9.1 toolkit.

VLAN-trunk-capable port group present; no VLAN conflicts with existing networks

Step 8

Verify NTP and DNS: esxcli system ntp get and confirm DNS resolution (e.g. nslookup broadcom.com). Note: on the 9.1 HoloRouter, DNS is served by Technitium DNS (:5380) rather than the 9.0-era dnsmasq pods — upstream-forwarder behavior must be re-validated on first live 9.1 deploy.

NTP synchronized; DNS resolving

Holodeck bring-up is extremely sensitive to clock skew and DNS failures — unresolved NTP/DNS issues surface later as obscure SSL certificate errors.

Validation Gate

Check: Checklist: physical ESXi at verified 9.1 minimum: YES/NO, nested ESX template >= 8.0 U3: YES/NO, vHV enabled: YES/NO, RAM at verified minimum: YES/NO, cores at verified minimum: YES/NO, datastore free space sufficient: YES/NO, VLAN trunking configured: YES/NO, NTP synchronized: YES/NO, DNS resolving: YES/NO

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

Common Errors

Toolkit pre-flight reports a version compliance error

Cause: Physical or nested ESX below the supported minimum (nested ESX must be 8.0 U3+ on Holodeck 9.1)

Fix: Upgrade the non-compliant layer. Exact 9.1 error strings and compliance checks: verify against live 9.1 toolkit.

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, enable Intel VT-x (EPT) / AMD-V (NPT) in BIOS, and re-verify from ESXi.

Task 2 Install the Holodeck 9.1 toolkit and choose a deployment driver

manageability

Holodeck 9.1 introduces a second deployment driver: Click-to-Deploy GitOps, where the HoloRouter OVA (deployed with GitOps enabled) auto-provisions GitLab and drives full deployments from the UI with no manual PowerShell. The classic cmdlet path remains available. This task installs the toolkit, records the 9.1 module inventory, and makes a deliberate, documented choice of driver — a repeatability/auditability decision a VCDX panelist can probe.

Step 1

Obtain the Holodeck 9.1 release on your management workstation. Download from the official docs Downloads page / Broadcom support portal — no GitHub releases exist for vmware/Holodeck.

Holodeck 9.1 toolkit files present locally (directory layout: verify against live 9.1 toolkit)

Step 2

Decide and document your deployment driver for this lab series: (a) PowerShell cmdlet path (imperative, verbose output, fine-grained control), or (b) Click-to-Deploy GitOps path (HoloRouter OVA with GitOps enabled auto-provisions GitLab; deployments triggered from the UI). Record the rationale — repeatability, auditability, and shared-host coordination all differ between the two.

Driver decision documented with rationale

Step 3

Import the Holodeck 9.1 PowerShell module (needed even if you plan to use GitOps, for query/lifecycle cmdlets). Module path and file name: verify against live 9.1 toolkit.

Module imports without errors

Step 4

Verify the module is loaded and record the 9.1 cmdlet inventory and module version: Get-Command -Module <module-name>. Expected cmdlet count and version string: verify against live 9.1 toolkit. Note the confirmed 9.1 behavior change: New-HoloDeckConfig now auto-generates Site A AND Site B configurations in one pass.

Cmdlet inventory captured; module version recorded for the lab notebook

Step 5

If using the GitOps path: stage the HoloRouter 9.1 OVA and identify the GitOps-enable deployment option. Exact OVF properties, GitLab version bundled, and appliance resource overhead: verify against live 9.1 toolkit (open questions from the release announcement).

HoloRouter 9.1 OVA staged; GitOps-enable option identified and documented

Step 6

Run the toolkit's health/connectivity check against the physical ESXi host. Exact cmdlet name and parameters: verify against live 9.1 toolkit (9.0 baseline used a health-check cmdlet targeting the host over SSH).

Health check passes: host reachable, version compatible, resources available

If this fails, verify network connectivity, SSH enabled on ESXi, and firewall rules before proceeding.

Validation Gate

Check: Verify: (1) 9.1 module imports and cmdlet inventory captured, (2) module version recorded, (3) deployment driver decision documented, (4) health/connectivity check passes (exact cmdlet: verify against live 9.1 toolkit)

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

Common Errors

Module import fails or returns zero cmdlets

Cause: Corrupted download or wrong module path

Fix: Re-download the 9.1 release and re-import with -Force. Exact module layout: verify against live 9.1 toolkit.

Health/connectivity check cannot reach the host

Cause: SSH not enabled on physical ESXi or firewall blocking the connection

Fix: Enable SSH on the ESXi host and confirm port 22 reachability from the workstation.

Task 3 Download and stage VCF 9.1 content

manageability

Holodeck orchestrates nested deployment from version-specific content. Staging the right content for the target (VCF 9.1.0.0, VVF 9.1.0.0, or VCF 5.2.4) with verified checksums remains the single most common failure point in the 9.0-era community record — assume the discipline carries forward until the 9.1 KB says otherwise.

Step 1

Create the content staging directory on your management workstation or directly on the physical ESXi datastore.

Directory created and writable

Step 2

Download the VCF 9.1.0.0 content set from the Broadcom support portal (and VVF 9.1.0.0 or VCF 5.2.4 sets if you plan those deployment types). Exact component list, file names, and sizes for 9.1: verify against live 9.1 toolkit documentation.

All required 9.1 content files downloaded to the staging directory

Do NOT interrupt downloads mid-transfer — corrupted images cause silent failures later. Use the download token / entitlement mechanism required by your account type.

Step 3

Create or obtain the 9.1 content manifest. Manifest file naming, format, and whether the 9.1 toolkit generates it for you: verify against live 9.1 toolkit.

9.1 content manifest present, listing every staged component with checksums

Step 4

Verify manifest completeness: confirm every file referenced by the manifest exists in the staging directory.

No missing files

Step 5

Verify checksums for every staged file against the manifest (Get-FileHash / sha256sum).

All hashes match. Any mismatch = delete and re-download that file.

Hash mismatches were the #1 cause of 9.0-era deployment failures. Treat checksum validation as non-negotiable.

Step 6

Optional: move the content staging directory onto the physical ESXi datastore to speed up the deployment phase, and update the content path in your configuration accordingly.

Content directory visible on the ESXi datastore

Validation Gate

Check: Verify: (1) all 9.1 content files present, (2) manifest exists and is valid, (3) all checksums match, (4) content path recorded for the configuration step

Expected: Content staged and verified for VCF 9.1.0.0 (and any optional VVF 9.1.0.0 / VCF 5.2.4 sets)

Common Errors

Deployment later fails with a manifest or content-version mismatch error

Cause: Manifest, toolkit version, and staged content are not aligned to the same release

Fix: Align all three to 9.1 (toolkit 9.1 + 9.1 manifest + 9.1-labelled content) and re-validate checksums. Exact 9.1 error strings: verify against live 9.1 toolkit.

Cannot download content from the Broadcom portal

Cause: Entitlement/download-token issue, expired link, or corporate firewall blocking the CDN

Fix: Verify the Broadcom account entitlement (purchased, trial, NFR, VCP, or VCP + VMUG Advantage), regenerate the link, or whitelist the CDN.

Task 4 Create and validate the Holodeck 9.1 deployment configuration

manageability

The deployment configuration is the source of truth for the instance. 9.1 changes the workflow: New-HoloDeckConfig now auto-generates Site A AND Site B configurations in one pass (dual-site by default). On shared hosts this is a double-edged sword — the auto-generated Site B must be reviewed for IP/VLAN collisions with any existing instances before it is ever used. This mirrors the VCF Planning & Preparation Workbook discipline.

Step 1

Generate the configuration with New-HoloDeckConfig. Confirmed 9.1 behavior: this now produces BOTH Site A and Site B configurations in a single pass. Exact parameters and output layout: verify against live 9.1 toolkit.

Site A and Site B configuration artifacts generated; ConfigID (or equivalent) recorded

Step 2

Set the core fields: target host, credentials, and target version (VCF 9.1.0.0 — or VVF 9.1.0.0 / VCF 5.2.4 for those deployment types). Valid -Version value strings for the 9.1 toolkit: verify against live 9.1 toolkit.

Core fields set; configuration parses as valid JSON

Step 3

Review management cluster resource sizing. 9.0 baseline defaults were 4 nested hosts x 12 vCPU / 96 GB; 9.1 defaults and any VNA-related sizing deltas: verify against live 9.1 toolkit. Keep total consumption <= 80% of physical capacity.

Resource sizing documented and within the 80% envelope

Step 4

Review networking: management CIDR, VLAN range, and external router IP. VLAN range handling was fixed in 9.1 and Site B port-group issues were resolved — verify the corrected defaults and confirm the auto-generated Site B ranges do not collide with anything existing on the physical network (critical on shared hosts).

Network settings reviewed for BOTH auto-generated sites; no collisions

Step 5

Set strong passwords for all credential fields and record them securely. Note: the 9.1 HoloRouter bundles HashiCorp Vault (:8200) for secrets management — whether deployment credentials flow through Vault: verify against live 9.1 toolkit.

All password fields set and documented securely

Step 6

Validate configuration completeness and syntax (parse the JSON, echo the critical values: version, target host, content path).

All critical values print without error

Step 7

If the 9.1 toolkit supports a validate-only/dry-run mode, run it before committing resources. Cmdlet/flag name: verify against live 9.1 toolkit (9.1 also hardened VCF installer validation, so expect stricter checks than 9.0).

Validation passes or lists specific errors to fix

Validation Gate

Check: Checklist: (1) Site A + Site B configs generated and reviewed, (2) version set to 9.1.0.0 (or VVF/5.2.4 target), (3) content path valid, (4) resources <= 80% of capacity, (5) no IP/VLAN collisions for either site, (6) passwords set, (7) dry-run validation passes if available

Expected: Configuration ready for the deployment phase in holodeck91-02

Common Errors

Auto-generated Site B config collides with an existing instance on a shared host

Cause: 9.1 generates Site B automatically; on multi-instance shared hosts the defaults may overlap existing IP/VLAN allocations

Fix: Review and adjust the Site B CIDR/VLAN allocations before any deploy. Coordinate with other instance owners on the shared host.

Configuration edits made after a partial deployment do not take effect

Cause: 9.0-era behavior cached host specs on first prepare; whether 9.1 retains this behavior: verify against live 9.1 toolkit

Fix: Assume the safe pattern: destroy the instance, edit the config, redeploy from scratch.

Task 5 Execute pre-flight checklist and create baseline snapshot

recoverability

Production operations always run a pre-flight checklist before deploying infrastructure. Creating a baseline now ensures rollback to a known-good state if subsequent labs fail. On the GitOps path, the 'prepare' equivalent is the pipeline's staging stage — capture what it does on the first live run.

Step 1

Document the environment baseline in deployment-baseline.txt: physical ESXi version, RAM, cores, datastore free space, NTP status, Holodeck 9.1 module version, content checksums, and the (redacted) configuration.

deployment-baseline.txt created with all items documented

Step 2

Run the final toolkit health check before deploying (exact cmdlet: verify against live 9.1 toolkit). Remediate any failing item before proceeding.

Health check passes on all items

Step 3

Create a baseline snapshot where possible, or document that the physical host cannot be snapshotted.

Baseline snapshot created OR documented as not applicable

Step 4

Review and sign off the pre-flight checklist (mirrors the VCF Planning & Preparation Workbook). Every item must be a confident YES.

Checklist completed with all YES responses

Step 5

Execute the prepare/staging phase. PowerShell path: New-HoloDeckInstance against your configuration (exact 9.1 parameters: verify against live 9.1 toolkit). GitOps path: deploy the GitOps-enabled HoloRouter OVA and observe GitLab auto-provisioning and the initial pipeline stages from the UI.

Prepare/staging completes successfully; instance ID or pipeline run recorded; logs captured

Step 6

Verify the prepared state via the toolkit query cmdlets or the GitOps UI (exact state names for 9.1: verify against live 9.1 toolkit).

Instance/pipeline reports a successfully prepared state with version 9.1.0.0

Step 7

Take a snapshot of the Holodeck state after successful prepare: name it 'holodeck91-01-complete'.

Snapshot 'holodeck91-01-complete' created on all Holodeck VMs deployed so far

Validation Gate

Check: Checklist: (1) deployment-baseline.txt populated, (2) health check passes, (3) prepare/staging phase completed successfully, (4) prepared state verified, (5) snapshot 'holodeck91-01-complete' exists

Expected: All items complete. Lab holodeck91-01 is finished; ready for holodeck91-02 (management domain deployment).

Common Errors

Prepare/staging hangs at HoloRouter configuration

Cause: 9.0-era causes were FRR/DHCP issues; the 9.1 router runs a different services stack (Technitium DNS, reverse proxy, Vault, Authentik) — root causes must be re-baselined

Fix: Capture logs and re-diagnose on the live 9.1 router; do not assume 9.0-era fixes (dnsmasq edits, FRR restarts) apply. Verify against live 9.1 toolkit.

Prepare fails with a target-host connectivity error

Cause: Physical ESXi unreachable, wrong credentials, or SSH/firewall blocking

Fix: Verify connectivity, SSH service, and configuration credentials.

Final Validation

The Holodeck 9.1 toolkit is installed, a deployment driver (PowerShell vs Click-to-Deploy GitOps) has been deliberately chosen and documented, VCF 9.1.0.0 content is staged and checksum-verified, the auto-generated Site A + Site B configuration pair has been reviewed for collisions, and a successful prepare/staging phase has completed with a baseline snapshot in place. 1 deployment (W5).

✓ Holodeck toolkit version → 9.1 module version recorded (exact version string: verify against live 9.1 toolkit)

✓ Support matrix understood → Candidate can state: deploys VCF 9.1.0.0 / VVF 9.1.0.0 / VCF 5.2.4; supported range VCF 9.1.0.0 down to VCF 5.2; minimum nested ESX 8.0 U3

✓ Physical host resources → Validated against 9.1 minimums (9.0 baseline values used pending verification)

✓ Nested virtualization enabled → vHV enabled in BIOS and visible to ESXi

✓ VCF 9.1 content staged → All 9.1 content files present with matching checksums and a valid manifest

✓ Configuration pair reviewed → Auto-generated Site A + Site B configs reviewed; no IP/VLAN collisions; resources <= 80% of capacity

✓ Prepare phase completed → Toolkit/pipeline reports prepared state for version 9.1.0.0

✓ Baseline snapshot → holodeck91-01-complete snapshot exists

Cleanup / Restore

Snapshot: holodeck91-01-complete

• Snapshot 'holodeck91-01-complete' has been created on all Holodeck VMs deployed so far

• Document the instance ID (or GitOps pipeline reference) — needed for holodeck91-02

• Document the deployment-driver decision and configuration paths — referenced in holodeck91-02

• Store deployment-baseline.txt safely as a reference artifact

Design Reflection (VCDX)

A VCDX panelist would probe: 'How did you validate lab infrastructure readiness before deploying VCF 9.1?' — answer with the pre-flight checklist (versions including the nested ESX 8.0 U3 floor, vHV, resources, NTP/DNS, VLANs). New for 9.1: 'Why did you choose the GitOps driver over PowerShell (or vice versa)?' — be ready to argue repeatability (declarative config in Git, pipeline-driven) vs control/visibility (imperative cmdlets, verbose output), and to explain what the auto-generated dual-site config changes about your collision-avoidance process on shared infrastructure.

Requirements

Physical infrastructure capable of nested virtualization at the verified 9.1 minimums (9.0 baseline: 512 GB RAM, 64 cores, 2 TB SSD/NVMe)
Holodeck 9.1 toolkit aligned with VCF 9.1.0.0 content (or VVF 9.1.0.0 / VCF 5.2.4 targets)
Nested ESX layer at 8.0 U3 minimum
Content staged and checksum-verified before any deployment attempt
Deliberate, documented choice of deployment driver (PowerShell vs GitOps)

Constraints

Supported deployment range is bounded: VCF 9.1.0.0 down to VCF 5.2 — older targets are out of scope on this toolkit
Single physical host = single fault domain; the entire lab is lost if the host fails
GitOps path resource overhead (GitLab appliance) is unquantified until live verification
9.0-era community KB has zero verified 9.1 content — troubleshooting references must be re-baselined

Assumptions

9.0 baseline hardware minimums carry forward until live 9.1 verification proves otherwise
Broadcom entitlement is active for 9.1 content downloads
The dual-site auto-generated Site B config can be safely adjusted before use on shared hosts
PowerShell cmdlet path remains fully supported alongside GitOps

Risks

Unverified 9.1 sizing causes resource exhaustion mid-deployment — MITIGATION: conservative <=80% allocation, monitor during deploy, capture actuals for the lab notebook
Auto-generated Site B config collides with existing shared-host instances — MITIGATION: review both site configs before any deploy; coordinate teardown windows
Assuming 9.0-era fixes (dnsmasq DNS edits, FRR restarts) apply to the 9.1 services stack — MITIGATION: re-diagnose from live logs; treat all 9.0 workarounds as unverified
Content/toolkit/manifest version skew — MITIGATION: align all three to 9.1 and enforce checksum validation

Self-Assessment Discussion Prompts

The 9.1 support matrix spans VCF 9.1.0.0 down to VCF 5.2. What does that range enable for upgrade-path rehearsal, and what does the 8.0 U3 nested ESX floor rule out?
Argue both sides of the GitOps vs PowerShell driver decision for a solo lab vs a shared team lab. Which quality dimensions (manageability, recoverability) dominate each case?
New-HoloDeckConfig now emits Site A and Site B in one pass. What new failure mode does this introduce on a shared physical host, and what process change mitigates it?
The 9.1 HoloRouter replaces the dnsmasq-era DNS path with Technitium. Why should every 9.0-era DNS workaround be treated as unverified, and how would you re-baseline them?
What would you capture during the first live 9.1 deployment to convert this stub lab into a fully verified manual?

References

HoloDeck 9.1 Release Announcement (captured verbatim) Holodeck-9.1/01-release-announcement.mdlocal fileTier 1 — Official
Primary source for confirmed 9.1 facts: VCF 9.1.0.0/VVF 9.1.0.0/5.2.4 targets, support range to 5.2, nested ESX 8.0 U3 minimum, GitOps, VNA, services stack.
HoloDeck Toolkit 9.1 — Structured Reference & Changelog Holodeck-9.1/02-structured-changelog.mdlocal fileTier 1 — Official
Structured capture with open questions (GitLab version/overhead, VNA sizing, Technitium vs dnsmasq, Authentik defaults, upgrade path).
Holodeck Toolkit GitHub RepositoryTier 1 — Official
Official source — verify 9.1 release assets, docs, and issue tracker here.
Broadcom Support Portal — VCF 9.1 DownloadsTier 1 — Official
Official download source for VCF 9.1.0.0 / VVF 9.1.0.0 / VCF 5.2.4 content. Requires entitlement.

Mark complete