Holodeck Instance Lifecycle Management (Holodeck 9.1)
Objectives
- Design and execute a multi-checkpoint snapshot strategy for Holodeck 9.1 lab environments
- Execute Remove-HoloDeckInstance on a 9.1 instance and verify complete cleanup of nested infrastructure (VMs, port groups, router state)
- Redeploy from a fresh configuration pair (or GitOps pipeline re-run) and measure redeploy time vs snapshot revert time
- Version-control the 9.1 Site A + Site B configuration pair and demonstrate config overlay patterns across the supported version range
- Deploy and compare side-by-side VCF 5.2.4 and VCF 9.1.0.0 instances to articulate version-specific architectural differences
- Automate Holodeck lifecycle operations via PowerShell and/or the GitOps pipeline, and document best practices for lab reset and scheduling
Prerequisites
Holodeck 9.1 pod with VCF 9.1.0.0 management domain deployed and healthy (holodeck91-02 completion snapshot available). Sufficient datastore space for 2+ snapshots per VM (9.0 baseline guidance: minimum 200 GB free — verify against the larger 9.1 footprint, 2.2 TB single-site baseline). PowerShell access to the Holodeck 9.1 runtime, and GitLab UI access if the GitOps driver was chosen in holodeck91-01.
Prior labs: holodeck91-02
Required skills:
- Holodeck 9.1 instance deployment and basic PowerShell scripting
- vSphere VM snapshot creation and revert operations
- Understanding of VCF component versioning and binary staging structure
- File system navigation and JSON editing
Lab Environment
Primary Holodeck pod (VCF 9.1.0.0) from holodeck91-02. Secondary instance (VCF 5.2.4) deployed in Task 4 on the same physical host using a separate, non-overlapping configuration. Isolation via HoloRouter networking (9.1 defaults: Site A 10.1.0.0/20, Site B 10.2.0.0/20 — the auto-generated Site B config exists even for single-site deployments).
graph TB PHY[Physical ESXi Host — 9.1 envelope: 48 CPU / 650 GB / 2.2 TB single site] --> HR[HoloRouter 9.1 — services stack behind HTTPS proxy] HR --> MGMT-A[VCF 9.1.0.0 Instance] HR --> MGMT-B[VCF 5.2.4 Instance — Task 4, non-overlapping CIDR/VLAN] MGMT-A --> SNAP1[Snapshot: lcm-post-deploy-9.1.0.0] MGMT-A --> SNAP2[Snapshot: lcm-post-validation-9.1.0.0] HR -.->|GitOps path| GL[GitLab pipeline + runner]
IP Addressing
| Network | Purpose | VLAN |
|---|---|---|
10.1.0.0/20 | Site A primary instance (VCF 9.1.0.0) — 9.1 default MasterCIDR | 9.1 default Site A VLANs 0, 10-25 — verify actuals from the deployed instance |
10.2.0.0/20 | Site B default supernet (auto-generated config pair). Task 4 secondary instance must use a non-overlapping custom /20 (e.g. 10.3.0.0/20) if Site B ranges are reserved | 9.1 default Site B VLANs 40-58 — verify; VLAN range handling was fixed in 9.1 |
Credentials
| System | Username | Password |
|---|---|---|
| Physical ESXi Host | root | Configured during ESXi installation |
| HoloRouter 9.1 (SSH) and services stack (Vault :8200, Authentik :9443, Technitium :5380, Webtop :30000, GitLab) | root (SSH); per-service accounts per the 9.1 docs reference | Root password set during OVA deployment. Service defaults documented in holodeck-official-docs-reference-9.1.md (master password convention) — confirm on the live deployment; Authentik admin username has a docs discrepancy (akadmin vs admin) |
| SDDC Manager / vCenter | administrator@vsphere.local | Master password from the VCF bring-up spec (9.1 docs publish a single master-password convention for all nested components) |
Tasks
Task 1 Design and execute a multi-checkpoint snapshot strategy
recoverabilitySnapshots are your lab reset button. In production they are not allowed as a protection mechanism, but in a lab they enable rapid rollback after experiments fail. VCDX panelists expect you to articulate when to snapshot (post-major-milestone), what to snapshot (which VMs), and the trade-offs (memory vs non-memory, disk overhead, consolidation timing). The mechanics are PowerCLI and largely version-agnostic; the 9.1 deltas are the larger VM inventory and disk footprint.
Open your management session (PowerShell workstation or the authenticated 9.1 Webtop) and navigate to the Holodeck 9.1 runtime location (9.0 baseline: the holodeck-runtime directory; exact 9.1 layout on your chosen console: verify against live 9.1 toolkit).
Review the current instance state: Get-HoloDeckInstance (signature documented unchanged in 9.1). Record the instance ID and confirm the version reports 9.1.0.0 (exact output field names: verify against live 9.1 toolkit).
List all Holodeck VMs currently deployed via PowerCLI (9.0 baseline naming: Get-VM -Name '<InstanceID>' or 'Holo-'). Record the actual 9.1 VM inventory — it may include additional appliances vs 9.0 (e.g. VNA cluster nodes if the distributed networking option was chosen).
Check datastore free space to estimate snapshot overhead: Get-Datastore | Format-Table -Property Name, FreeSpaceGB, CapacityGB. The 9.1 footprint is larger than 9.0 (2.2 TB single-site baseline) — size snapshot headroom accordingly.
Create a non-memory snapshot at the post-deployment milestone: New-Snapshot across the instance VMs with name 'lcm-post-deploy-9.1.0.0', -Memory:$false -Quiesce:$false.
Verify snapshot creation: Get-Snapshot across the instance VMs, sorted by name, showing Created and SizeGB.
Perform a non-disruptive operational check (e.g. document current SDDC Manager state), then take a second checkpoint named 'lcm-post-validation-9.1.0.0'.
Examine snapshot metadata and total growth: Get-Snapshot -Name 'lcm-*' | Measure-Object SizeGB -Sum. Keep total snapshot consumption below 50% of free datastore space.
Document your naming convention in SNAPSHOT_NAMING.txt: '<component>-<phase>-<version>' (examples: lcm-post-deploy-9.1.0.0, lcm-post-wld-9.1.0.0). Version-scope every snapshot name so 9.0-era and 9.1 checkpoints can never be confused on a shared host.
Validation Gate
Check: Verify: (1) at least 2 snapshots exist per VM, (2) names follow <component>-<phase>-<version> with the 9.1.0.0 version scope, (3) all snapshots are non-memory, (4) total snapshot size < 50% of free datastore space
Expected: Multi-checkpoint snapshot strategy in place with documented naming and growth tracking
Common Errors
Task 2 Destroy and redeploy an instance to verify cleanup and measure redeploy time
recoverabilityThe destroy-redeploy cycle is the ultimate validation that your instance is reproducible and the toolkit cleans up after itself. VCDX panelists probe: how do you ensure repeatability, detect orphaned resources, and automate this? On 9.1 there are two redeploy drivers to time (PowerShell vs GitOps pipeline re-run), and the one-config-one-deployment rule means a redeploy starts from a FRESH config pair.
Before destroying, back up instance metadata: Get-HoloDeckInstance | ConvertTo-Json | Out-File instance-backup-before-destroy.json. Also record the deployment parameters actually used (Version, InstanceID, CIDR, VLANRangeStart, networking switches) — you need them for an identical redeploy.
Stop the instance gracefully: Stop-HoloDeckInstance -InstanceID <id> (documented unchanged from 9.0.2 — graceful ordered shutdown). Prefer this over blunt per-VM power-off.
Record pre-destruction datastore state: capture FreeSpaceGB for the target datastore(s) for later comparison.
Execute instance removal: Remove-HoloDeckInstance (documented unchanged in 9.1; optional -ResetHoloRouter clears router networking with an automatic reboot). Decide DELIBERATELY whether to include -ResetHoloRouter: on a shared host it resets global router state for every tenant, and its behavior under the 9.1 services stack (Technitium, reverse proxy, GitLab runner) must be re-validated before use.
Verify cleanup: (a) no instance VMs remain (Get-VM count 0 for the instance prefix), (b) instance-specific port groups removed, (c) datastore space reclaimed vs the step-3 baseline (expect a larger reclaim than 9.0 given the 9.1 footprint).
Generate a FRESH configuration for the redeploy: New-HoloDeckConfig -TargetHost <host> -UserName <u> -Password <p>. Confirmed 9.1 behavior: this creates TWO config files (Site A + Site B) and auto-loads Site A into the session. Do NOT reuse the consumed config from the destroyed deployment (one-config-one-deployment rule).
Start the timed redeploy. PowerShell path: New-HoloDeckInstance -Version 9.1.0.0 -InstanceID <id> with the recorded parameters (start a stopwatch first). GitOps path: trigger the deployment pipeline from the GitLab UI and use the pipeline duration as the measurement.
Compare redeploy time vs snapshot revert time. Reference points: snapshot revert ~5-10 minutes; 9.0-era Academy baseline for a mgmt-only redeploy was 90-150 minutes, while the official docs still publish only 9.0.0.0 timings (ManagementOnly 4-5 h). No 9.1-specific timings are published — your measurement IS the enrichment data for this stub.
Validation Gate
Check: After destroy: (1) no instance VMs remain, (2) port groups cleaned, (3) datastore space recovered. After redeploy: (1) instance healthy at 9.1.0.0, (2) redeploy time measured and logged, (3) fresh config pair used (not the consumed one)
Expected: Complete lifecycle cycle demonstrated: destroy validates cleanup, redeploy validates reproducibility, timing captured for the 9.1 KB
Common Errors
Task 3 Version-control the 9.1 configuration pair and demonstrate overlay patterns
manageabilityConfiguration management at scale: template reuse, inheritance, and override patterns instead of copy-paste. The 9.1 twist: every New-HoloDeckConfig run now yields a Site A + Site B pair, so your version-control scheme must track pairs, and version-scoped naming matters more because one toolkit drives targets from 5.2 to 9.1.0.0.
Locate the 9.1 configuration artifacts on the HoloRouter: the template at /holodeck-runtime/templates/config.json (confirmed in the 9.1 docs) and per-deployment configs under /holodeck-runtime/config/. Confirmed: 9.1 creates TWO files per config (Site A + Site B); the naming scheme of the pair: verify against live 9.1 toolkit.
Create a version-control directory structure for configs: configs/{base,overlays,deployed,archive} in your working area.
Copy the 9.1 template as your base: config-base-9.1.0.0.json. Capture the live template's default nested-host sizing while you are here — 9.1 defaults are unpublished (9.0 baseline: 4 hosts x 12 vCPU / 96 GB) and this is a W5 capture item.
Record the valid 9.1 -Version strings in your convention doc: '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'. Version-scope every config filename (e.g. config-vcf9100-mgmt-only.json, config-vcf524-mgmt-only.json) so cross-version drift is impossible to miss.
Build an overlay example: load the base config into a PowerShell object, apply a scenario delta (e.g. reduced nested host count or a mgmt-only profile), and save as a deployed config. Use object manipulation (ConvertFrom-Json / ConvertTo-Json -Depth 20), never hand-edited JSON.
Document the naming convention in CONFIG_NAMING.md, including the new pair convention: every generated config is a Site A + Site B pair; archive them together; note which member was consumed by a deployment (one config = one deployment).
Create a VERSION_HISTORY.txt log recording each config's creation date, target version, deployment outcome, and measured deploy time.
Write a pre-deployment validation function: parse the config, assert the version string is in the valid 9.1 set, assert the binaries folder /holodeck-runtime/bin/<version>/ is staged, and assert the CIDR does not collide with any recorded allocation on the shared host. Note for session recovery: Import-HoloDeckConfig -ConfigID <id> -Site a (the -Site parameter is mandatory in 9.1).
Validation Gate
Check: Verify: (1) base config exists at configs/base/, (2) at least 2 version-scoped deployed configs, (3) naming convention documents the Site A/B pair handling, (4) version history log populated, (5) validation function passes
Expected: Config management framework in place, adapted to the 9.1 pair-generation and multi-version reality
Common Errors
Task 4 Deploy side-by-side VCF 5.2.4 and 9.1.0.0 instances and document version differences
manageabilityThis is VCDX gold. The 9.1 toolkit's supported range (VCF 9.1.0.0 down to 5.2) turns upgrade-path rehearsal into a lab exercise: run the 5.2 maintenance line beside 9.1 and articulate what changed (bring-up orchestrator, component versions, UI, licensing, services). Panelists probe exactly these version-boundary design decisions when upgrades are on the table.
Confirm the version plan: the 9.1 toolkit deploys VCF 9.1.0.0 / VVF 9.1.0.0 / VCF 5.2.4 (official docs also list 5.2.3). Choose 5.2.4 as the comparison target and confirm your entitlement covers the 5.2.4 content set.
Stage the VCF 5.2.4 binaries to /holodeck-runtime/bin/5.2.4/ (5.2.x deployments need the ESX ISO + Cloud Builder OVA; 9.x uses the VCF Installer OVA instead). Verify checksums — do not rename files to force a match.
Plan non-overlapping networking for the second instance: a custom /20 CIDR (e.g. 10.3.0.0/20) and a -VLANRangeStart clear of the primary instance (Site A needs >= 16 consecutive VLAN IDs). Check existing allocations first (Get-HoloDeckSubnet -Site a and Get-HolodeckServiceIPPools -Site a; signatures documented unchanged in 9.1).
Resource-check before committing: the VCF 9.1 single-site envelope is already 48 CPU / 650 GB / 2.2 TB. Concurrent 5.2.4 + 9.1.0.0 instances will likely exceed a shared host — the recommended pattern is sequential: snapshot the 9.1 instance (Task 1 checkpoints), deploy 5.2.4, compare, then remove it. 9.1 soft validation will warn rather than block if you push past recommendations; treat warnings as design data, not noise.
Deploy the 5.2.4 instance: New-HoloDeckInstance -Version 5.2.4 -InstanceID <unique-id> with the planned CIDR/VLAN parameters (5.2.x-specific switches and behavior on the 9.1 toolkit: verify against live 9.1 toolkit).
Once deployed, list both instances via Get-HoloDeckInstance and confirm two healthy instances at different versions.
Access both management planes and document differences: (a) bring-up orchestrator (Cloud Builder for 5.2.x vs VCF Installer for 9.x, including the Installer compatibility matrix), (b) SDDC Manager UI and Day-2 menus, (c) component versions (vCenter, NSX 4.x vs 9.x-aligned), (d) evaluation licensing (5.2.x: 60-day trial; 9.x: 90-day trial, License Later mode), (e) the surrounding services experience (9.1 HoloRouter services stack vs the 5.2-era access model).
Write the comparison document with at least 5 concrete architectural or operational differences, each tied to a design implication (upgrade windows, capacity, automation surface, security posture).
Close with a VCDX design reflection: what the 5.2-to-9.x boundary means for a customer's upgrade design — orchestrator replacement, component re-versioning, licensing change, and operational-model shift — and which of those you can now demonstrate live rather than assert.
Validation Gate
Check: Verify: (1) both instances deployed and healthy (sequentially or concurrently per the documented resource decision), (2) both management planes accessed, (3) comparison document with 5+ differences and design implications, (4) VCDX reflection written
Expected: Side-by-side comparison complete with architectural insights ready for panelist discussion
Common Errors
Task 5 Automate Holodeck operations and build a lab reset capability
manageabilityOperational maturity means repeatability and automation. On 9.1 you have two automation substrates: your own PowerShell module (imperative, flexible) and the built-in GitOps pipeline (declarative runs with a durable audit trail). VCDX-level thinking builds the PowerShell framework AND evaluates when the pipeline is the better control plane.
Create a PowerShell module (HoloDeckOps.psm1) with a deployment wrapper that logs every run: timestamped log file, the New-HoloDeckConfig call (capturing BOTH generated config IDs), the New-HoloDeckInstance call with -Version 9.1.0.0, and error capture. Exact 9.1 cmdlet output to parse: verify against live 9.1 toolkit.
Add checkpoint functions: New-HoloDeckCheckpoint / Revert-HoloDeckCheckpoint wrapping PowerCLI snapshot create/revert for the instance VM set (version-agnostic mechanics, carried from the 9.0 twin).
Create Reset-Lab.ps1 that reverts all instance VMs to a named snapshot (default 'holodeck91-02-complete'), with confirmation prompt and per-VM missing-snapshot handling, then powers the VMs back on.
Create ScheduledSnapshot.ps1: weekly non-memory checkpoint named auto-weekly-<date> plus cleanup of snapshots older than 28 days. Schedule it via your workstation's task scheduler.
Add the Task 3 config validation function to the module (version string in the 9.1 valid set, binaries staged, CIDR collision check) so every automated deploy is pre-validated.
Create Show-LabStatus.ps1: instance inventory (Get-HoloDeckInstance), datastore usage, and snapshot counts per VM in one dashboard output.
Evaluate the GitOps pipeline as the audit-grade driver: open the pre-loaded Holodeck repository in GitLab, read the pipeline definition, and review the pipeline run history from your deployments. Compare against your module on repeatability (identical runs), auditability (who/what/when per run), and control (intervention mid-run). Record which driver your lab standardizes on and why.
Document the automation framework in AUTOMATION_README.md: function inventory, reset/schedule usage, idempotency notes (state on HoloRouter — re-run New-HoloDeckInstance to resume from failure, carried into 9.1), and the GitOps-vs-PowerShell decision.
Validation Gate
Check: Verify: (1) module with at least 3 functions, (2) Reset-Lab.ps1 and ScheduledSnapshot.ps1 created, (3) config validation wired in, (4) status dashboard works, (5) GitOps pipeline reviewed with a documented driver decision, (6) README complete
Expected: Repeatable, idempotent lab operations framework in place, with a deliberate choice of automation driver
Common Errors
Final Validation
The Holodeck 9.1 instance lifecycle is fully managed: snapshots checkpoint progress, a destroy-redeploy cycle validated cleanup and reproducibility with measured 9.1 timings, the Site A + Site B config pair is version-controlled with overlay patterns, a 5.2.4 instance was compared side-by-side against 9.1.0.0 across the toolkit's full support range, and an automation framework exists with a deliberate PowerShell-vs-GitOps driver decision. 1 deployment (W5).
✓ Snapshots: at least 2 named checkpoints per VM → Names follow <component>-<phase>-<version> with 9.1.0.0 scoping; all non-memory
✓ Destroy-redeploy cycle completed with timings → Cleanup verified (VMs, port groups, datastore); redeploy from a FRESH config pair; actual 9.1 timings logged (no official 9.1 timing table exists)
✓ Config management framework → Version-scoped base/deployed/overlay configs; Site A/B pair convention documented; validation function passes
✓ Version comparison: 5.2.4 vs 9.1.0.0 → 5+ documented differences with design implications (orchestrator, components, licensing, UI, services stack)
✓ Automation: module + reset + schedule + dashboard + driver decision → All scripts runnable; GitOps pipeline reviewed; standardization decision documented
Cleanup / Restore
Snapshot: holodeck91-07-complete
• Take a final snapshot 'holodeck91-07-complete' across all instance VMs after all tasks complete
• Consolidate intermediate lcm-* snapshots (keep only holodeck91-02-complete and holodeck91-07-complete)
• Remove the 5.2.4 comparison instance if still deployed, and verify its cleanup (Task 2 checklist)
• Archive config files (including both members of each Site A/B pair) and automation scripts to your reference location
• If on a shared host: record allocation changes in the shared registry and note every place live 9.1 behavior diverged from this stub
Design Reflection (VCDX)
A VCDX panelist examining operational maturity would probe: how do you manage multiple lab scenarios simultaneously; can you roll back a failed change; how would you standardize deployments across a team; can you articulate snapshot-vs-redeploy trade-offs with measured numbers? The 9.1-specific angles: (1) the toolkit now hands you an audit-grade deployment driver (GitOps pipeline history) — defend when pipeline-driven lifecycle beats imperative cmdlets and vice versa; (2) the one-config-one-deployment rule plus auto-generated Site A/B pairs changes your configuration-management design — pairs must be tracked and consumed configs never reused; (3) the support range down to VCF 5.2 makes upgrade rehearsal demonstrable — use the side-by-side evidence, not doctrine.
Requirements
- Support rapid environment reset for iterative design testing (snapshot revert in minutes)
- Enable version-comparison testing across the toolkit's supported range (VCF 9.1.0.0 down to 5.2) on shared infrastructure
- Provide reproducible, version-controlled configurations including the 9.1 Site A/B pair convention
- Detect and clean up orphaned resources after instance removal
- Automate routine operations with an auditable execution record (GitOps pipeline history or logged PowerShell runs)
Constraints
- The 9.1 resource envelope (48 CPU / 650 GB / 2.2 TB single site) constrains concurrent multi-version instances far more than 9.0-era sizing did
- One config = one deployment; consumed configs cannot drive redeploys
- Snapshots are lab-only mechanisms — storage-intensive and not a production protection pattern
- Nested performance does not represent production; timing data is directional only
- 9.0-era KB and workarounds are unverified against the 9.1 services stack
Assumptions
- Stop/Start/Remove-HoloDeckInstance behave per their unchanged documented signatures on 9.1
- The GitOps pipeline can serve as a lifecycle driver equivalent to the cmdlet path for full deployments
- 9.0 baseline snapshot guidance (non-memory, <50% free space) carries forward until 9.1 evidence says otherwise
- Broadcom entitlement covers both 9.1.0.0 and 5.2.4 content sets
Risks
- Snapshot chain corruption causes restore failures — MITIGATION: periodic consolidation and test restores
- -ResetHoloRouter on a shared host destroys other tenants' networking — MITIGATION: coordinate teardown windows; re-validate its 9.1 behavior before first use
- Resource exhaustion during side-by-side testing destabilizes the primary instance — MITIGATION: sequential pattern with checkpoints; treat soft-validation warnings as stop signals
- Config pair mismanagement (reusing a consumed config, losing the Site B twin) breaks reproducibility — MITIGATION: pair-aware archiving and the pre-deploy validation function
- Applying 9.0-era fixes to the 9.1 stack corrupts router state — MITIGATION: treat all 9.0 workarounds as unverified; re-diagnose from live logs
Self-Assessment Discussion Prompts
- When would you snapshot vs redeploy on 9.1, and how do your MEASURED timings change the answer vs the 9.0-era baseline?
- The GitOps pipeline gives you deployment audit history for free. What does that change about your automation design compared to hand-rolled PowerShell logging?
- One config = one deployment, and every config generation now yields a Site A + Site B pair. Design a configuration-management scheme that makes misuse structurally impossible.
- You have one physical host at the 9.1 resource envelope and need to compare 5.2.4, 9.1.0.0, and a future release. Sequence the work and justify the checkpoint strategy.
- Which parts of your 9.0-era reset/automation scripts survive contact with the 9.1 services stack unchanged, and how would you prove it?
- If you provisioned Holodeck 9.1 labs for 10 VCDX candidates, would you standardize on the GitOps driver or the cmdlet path? Defend both answers.
Extensions
Holodeck-as-Code on the Built-in Pipeline
Extend the pre-loaded GitLab pipeline: fork the deployment repo, parameterize it for your config overlay scheme, and add a validation stage that runs your Task 3 checks before any deploy. 9.1 makes this native — the extension is making it YOURS.
harderAutomated Health Checks and Alerting
Build a monitoring loop that checks instance health (SDDC Manager availability, NSX fabric status, datastore space, HoloRouter services stack endpoints) and triggers remediation (snapshot revert, VM restart) on anomalies.
harderMulti-Tenant Lab Hosting Service
Design a system where multiple users provision independent Holodeck 9.1 instances on shared infrastructure: quota management, allocation registry (CIDR/VLAN), Authentik-backed RBAC, and automated cleanup of abandoned instances.
much harderFull CI/CD Lab Testing Workflow
Wire config commits to automatic pipeline-driven deployment, post-deploy validation tests, and result reporting — turning the destroy-redeploy cycle of Task 2 into a scheduled regression test for the lab platform itself.
much harderMulti-Host Holodeck Estate
Span the lifecycle framework across multiple physical hosts (or a DRS cluster target): coordinated snapshots, cross-host allocation registry, and estate-wide status dashboards.
much harder⚠ Known Pitfalls (from Community KB)
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: targets, support range, GitOps, services stack, dual-site auto-generation. - HoloDeck Toolkit 9.1 — Structured Reference & Changelog
Holodeck-9.1/02-structured-changelog.mdlocal fileTier 1 — Official
Structured capture with open questions (GitLab overhead, VNA sizing, Technitium vs dnsmasq, upgrade path). - Holodeck 9.1 Official Docs (versioned site)Tier 1 — Official
Use the /9.1/ URLs only — un-versioned pages serve stale legacy content. Cmd reference confirms unchanged Stop/Start/Remove signatures and the Import-HoloDeckConfig -Site breaking change. - Holodeck Toolkit GitHub RepositoryTier 1 — Official
Issue tracker for 9.1-era issues: GH#139 (GitLab first boot), GH#143 (Day-2 All-Apps Org), GH#151 (9.1 depot file set). - Broadcom Support Portal — VCF 9.1 / 5.2.4 DownloadsTier 1 — Official
Official content source for both comparison targets. Requires entitlement; use the latest manifest for 9.1 depots.