Dual-Site Auto-Generation on Holodeck 9.1 — One-Pass Site A + Site B Configuration and Second-Site Deployment
Objectives
- Generate a complete dual-site (Site A + Site B) Holodeck configuration in a single New-HoloDeckConfig pass and explain how one-pass generation differs from the 9.0.x per-site workflow
- Inspect and verify the auto-generated Site A and Site B configuration files for non-overlapping CIDR, VLAN, and port-group allocation
- Switch the active PowerShell session context between site configurations using Import-HoloDeckConfig with the 9.1 -Site parameter
- Run pre-deployment validation for both sites and deploy the Site B management domain alongside an existing Site A instance
- Validate cross-site reachability and management-plane health across the dual-site topology
- Articulate, in VCDX defense terms, why automated configuration generation reduces configuration drift, and defend the choice between dual-site DR and stretched-cluster topologies
Prerequisites
Holodeck 9.1 tooling installed and a Site A VCF 9.1.0.0 management domain deployed and healthy (holodeck91-02 completed), OR a clean physical host if you intend to deploy both sites in this lab. Physical host sizing for dual-site: minimum 768 GB RAM, 64+ logical cores, 2+ TB SSD (the Site B footprint doubles the single-site allocation). Nested ESX template must be 8.0 U3 or later — Holodeck 9.1 enforces this minimum. Snapshot of the Site A instance taken before starting.
Prior labs: holodeck91-02
Required skills:
- Holodeck 9.1 lifecycle cmdlets (New-HoloDeckConfig, Import-HoloDeckConfig, New-HoloDeckInstance, Start-HoloDeckPrecheck) from holodeck91-01/02
- IP address planning and CIDR notation
- VCF management domain architecture (SDDC Manager, vCenter, NSX) — note the 9.1 unified management services runtime
- BGP routing concepts or comfort with static route inspection (vtysh)
- Disaster recovery concepts: RTO/RPO, failure domains, active-passive vs stretched topologies
Lab Environment
Single physical ESXi host (or modest vSphere cluster) running two Holodeck 9.1 instances. Site A (production role) uses the 10.1.0.0/20 management supernet; Site B (DR role) uses 10.2.0.0/20. Unlike 9.0.x — where each site's network configuration was generated manually and independently (a documented source of overlap errors) — Holodeck 9.1 generates both site configurations from a single New-HoloDeckConfig invocation, guaranteeing deterministic, non-overlapping CIDR/VLAN allocation. The HoloRouter provides routing between sites plus the 9.1 built-in service stack: Technitium DNS (port 5380), HashiCorp Vault (8200), Authentik SSO (9443), and an authenticated Webtop (30000), all behind an HTTPS reverse proxy.
graph TB
PHY[Physical ESXi Host - 768+ GB RAM] --> HR[HoloRouter 9.1<br/>HTTPS reverse proxy<br/>Technitium DNS :5380 / Vault :8200 / Authentik :9443]
HR -->|One-pass config generation| CFG[New-HoloDeckConfig<br/>Site A + Site B configs generated together]
subgraph SiteA["Site A - Production (10.1.0.0/20)"]
ESXA[4x Nested ESX 8.0U3+ 10.1.1.10x]
SDDCA[SDDC Manager-A 10.1.0.4]
VCA[vCenter-A 10.1.0.6]
NSXA[NSX Manager-A 10.1.0.10]
end
subgraph SiteB["Site B - DR (10.2.0.0/20)"]
ESXB[4x Nested ESX 8.0U3+ 10.2.1.10x]
SDDCB[SDDC Manager-B 10.2.0.4]
VCB[vCenter-B 10.2.0.6]
NSXB[NSX Manager-B 10.2.0.10]
end
HR --> SiteA
HR --> SiteB
SiteA <-->|Cross-site routing via HoloRouter| SiteBIP Addressing
| Network | Purpose | VLAN |
|---|---|---|
10.1.0.0/20 | Site A management supernet (auto-generated by New-HoloDeckConfig) | Site A VLAN block (auto-assigned — record actual IDs from generated config) |
10.1.1.0/24 | Site A nested ESX host management | Site A management VLAN |
10.2.0.0/20 | Site B management supernet (auto-generated in the same pass) | Site B VLAN block (auto-assigned, guaranteed non-overlapping with Site A) |
10.2.1.0/24 | Site B nested ESX host management | Site B management VLAN |
172.16.0.0/12 | NSX overlay ranges (both sites, segmented per site by the generated configs) | Overlay / Geneve |
Credentials
| System | Username | Password |
|---|---|---|
| HoloRouter SSH | root | Set at HoloRouter OVA deployment (9.1 default documented in toolkit docs) |
| SDDC Manager A / B | administrator@vsphere.local | Set in the generated bring-up spec. API calls use the doubled master password convention (e.g. VMware123!VMware123!) — verify this convention still holds on your 9.1 build |
| vCenter A / B | administrator@vsphere.local | Same SSO password as the site's SDDC Manager |
| NSX Manager A / B | admin | Set in generated bring-up spec; doubled password for API auth |
| HoloRouter web services (Vault/Authentik/Technitium/Webtop) | admin (service-specific) | 9.1 puts all HoloRouter services behind Authentik SSO + HTTPS reverse proxy — retrieve initial credentials per the 9.1 toolkit docs; Authentik defaults were an open question at release, verify on your build |
Tasks
Task 1 Generate the dual-site configuration in a single pass
manageabilityThis is the headline 9.1 workflow change (rn-9-1-018). In 9.0.x you ran New-HoloDeckNetworkConfig once per site and manually kept CIDRs and VLAN ranges from colliding — the community KB documents real failures from exactly that manual step. In 9.1, one New-HoloDeckConfig invocation emits both site configurations with deterministic, non-overlapping allocation. A VCDX panelist will recognize this as the classic 'automate the error-prone step' pattern: the tool now owns cross-site consistency instead of the operator.
On the management workstation (or HoloConsole), open PowerShell 7.x and import the Holodeck 9.1 toolkit module. Confirm the module version reports a 9.1.x build: Get-Module HoloDeckToolkit | Select-Object Name, Version
Generate the dual-site configuration. Run New-HoloDeckConfig with your target host parameters (TargetHost, Username, Password, datastore/network selections as in holodeck91-01). In 9.1 this single invocation generates TWO configuration files: one for Site A and one for Site B.
Verify which site context is loaded. Run Get-HoloDeckConfig and confirm the session shows the Site A configuration as active. Note the ConfigId, InstanceID, and site indicator fields.
Inspect both generated configuration files on disk (location per your 9.1 install, typically under the holodeck runtime config directory — verify the exact path against your live 9.1 toolkit). Compare side by side: management CIDR (expect 10.1.0.0/20 vs 10.2.0.0/20 or your chosen supernets), VLAN ranges, port-group names, and reserved component IPs for SDDC Manager, vCenter, and NSX on each site.
Practice the site context switch. Load Site B: Import-HoloDeckConfig -ConfigId <site-b-config-id> -Site b. Run Get-HoloDeckConfig again and confirm the active context now reports Site B. Then switch back to Site A the same way.
Validation Gate
Check: Two configuration files exist (Site A + Site B) from a single New-HoloDeckConfig pass. Diff confirms non-overlapping CIDRs/VLANs/port groups. Import-HoloDeckConfig -Site b successfully switches session context and back.
Expected: Dual-site configuration generated and verified; operator can deliberately control site context.
Common Errors
Task 2 Precheck both sites and verify the 9.1 dual-site fixes
availability9.1 hardened exactly the failure points that broke 9.0.x dual-site deployments: VLAN range handling, Site B port groups, and VCF installer validation (rn-9-1-020). Prechecking both sites BEFORE committing hours of deployment time is the operational discipline a panel expects — 'how do you know the second site will deploy cleanly?' should have a better answer than 'we tried it'.
With the Site A context loaded, run the pre-deployment validation: Start-HoloDeckPrecheck -Site a. Review every check: binary/content validation, target host reachability, networking (port groups, VLANs), storage headroom.
Switch context to Site B (Import-HoloDeckConfig -ConfigId <site-b-id> -Site b) and run Start-HoloDeckPrecheck -Site b.
Verify storage and memory headroom for the second site on the physical host BEFORE deploying. From the physical ESXi host client (or esxtop), record current consumed memory and datastore free space. Site B needs approximately the same footprint Site A consumed (~384 GB RAM and ~500+ GB disk for a 4-host management domain — verify against your actual Site A consumption).
Verify nested ESX template version. Holodeck 9.1 enforces a minimum nested ESX of 8.0 U3. Confirm the template/ISO version the toolkit will use for Site B hosts.
Validation Gate
Check: Start-HoloDeckPrecheck passes for both -Site a and -Site b. Headroom calculation documented. Nested ESX template confirmed at 8.0 U3+.
Expected: Both sites cleared for deployment with documented capacity evidence.
Common Errors
Task 3 Deploy the Site B management domain alongside Site A
availabilityDeploying a second full VCF instance next to a live one is a controlled-risk exercise in shared-infrastructure thinking: the two sites are logically independent (separate SDDC Manager, vCenter, NSX, vSAN) but physically entangled (same host, same HoloRouter). VCDX panels probe exactly this distinction — 'what is actually isolated here, and what only looks isolated?'
Take a snapshot of all Site A VMs before starting (Get-VM pattern from earlier labs). Label it clearly (e.g. 'pre-siteb-deploy').
Confirm the Site B context is loaded (Get-HoloDeckConfig shows Site B), then start the deployment: New-HoloDeckInstance with the Site B configuration, followed by (or including, per your 9.1 workflow) Start-HoloDeckInstance for the Site B InstanceID. Use -Verbose for a progress stream. Alternative path: 9.1 also supports driving this deployment from the GitOps/UI pipeline (rn-9-1-016) — this lab uses the cmdlet path for repeatability; note the alternative in your runbook.
While deployment runs, verify Site A remains healthy: SDDC Manager-A UI reachable, vCenter-A shows all hosts connected, vSAN health green. Record any degradation with timestamps.
When deployment completes, query both instances. Switch contexts as needed and run Get-HoloDeckInstance for each site's InstanceID.
Log in to the Site B management plane: SDDC Manager-B (10.2.0.4 or the address from your generated config), vCenter-B, NSX Manager-B. Verify the management domain shows Active with all hosts commissioned. Note: 9.1's unified management services runtime (rn-9-1-001) means the SDDC Manager / VCF Operations footprint differs from what the 9.0 labs describe — record what you actually observe.
Validation Gate
Check: Get-HoloDeckInstance shows Site A and Site B both Running on VCF 9.1.0.0. Site B SDDC Manager/vCenter/NSX all healthy. Site A suffered no persistent degradation.
Expected: Two independent VCF 9.1 management domains operational on the dual-site topology.
Common Errors
Task 4 Validate the dual-site topology — cross-site routing, DNS, and management-plane independence
manageabilityA dual-site lab is only useful for DR rehearsal if the sites can actually reach each other AND fail independently. This task validates both properties. The 9.1 twist: DNS is now served by Technitium on the HoloRouter behind the HTTPS reverse proxy (rn-9-1-017), which changes how you inspect and extend cross-site name resolution compared to the 9.0.x dnsmasq procedures.
Verify cross-site IP reachability. From a Site A source (HoloConsole or a Site A component), ping Site B SDDC Manager and vCenter (10.2.0.4, 10.2.0.6 or your generated addresses). Repeat in the reverse direction from Site B.
Inspect cross-site routing on the HoloRouter. SSH to the HoloRouter and review the routing state for both site supernets (vtysh 'show ip route' if FRR-based routing is in use on your build, or the routing method your 9.1 router uses — verify against live 9.1 toolkit, as the 9.1 router service stack changed substantially from 9.0.x).
Validate cross-site DNS with Technitium. Open the Technitium DNS console on the HoloRouter management IP, port 5380 (behind the HTTPS reverse proxy — authenticate as required on your build). Verify both Site A and Site B zones/records were provisioned by the dual-site generation. Test resolution both ways: from Site A, resolve a Site B FQDN; from Site B, resolve a Site A FQDN.
Verify management-plane independence. Confirm that Site A and Site B each have their own SDDC Manager, vCenter, SSO domain, NSX management cluster, and vSAN datastore — i.e., no shared management state between sites other than the HoloRouter transit/DNS layer.
Perform a controlled independence test: restart a non-critical Site B management service (or briefly disconnect a Site B nested host NIC), and confirm Site A registers zero impact. Restore immediately.
Validation Gate
Check: Bidirectional cross-site ping and DNS resolution pass. Both site supernets routed. Component inventory confirms parallel independent management stacks. Site B disturbance produced no Site A impact.
Expected: Dual-site topology validated: connected where intended, isolated where intended.
Common Errors
Task 5 Design exercise — auto-generation, drift, and the dual-site vs stretched decision
recoverabilityThis is the defense-facing payload of the lab. You now have first-hand evidence of what one-pass configuration generation buys you (deterministic non-overlap, no race conditions, symmetric sites) and what it does not (shared physical failure domain, no automatic DR orchestration). Convert that evidence into VCDX-grade positions using RCAR.
Write a one-page position: 'Why automated dual-site configuration generation reduces configuration drift.' Ground it in what you observed: (a) both sites derive from one allocation computation — no human transcription between sites; (b) the config diff you produced in Task 1 shows addresses differ, architecture does not; (c) the 9.0.x failure modes this eliminates (KB thread 10 CIDR overlap, Site B port group collisions) were all human-transcription errors; (d) race-condition elimination when generating/deploying sites in parallel.
Define the production scenario your lab models: Site A primary, Site B DR, active-passive, with target RPO/RPO. State explicitly which lab properties transfer to production (symmetric config generation, independent management stacks, cross-site DNS) and which do not (shared physical host, <2ms inter-site latency, single HoloRouter as shared transit).
Build the dual-site vs stretched-cluster comparison. For each topology document: failure domain boundaries, latency requirements (stretched vSAN needs ~<5ms RTT and L2 adjacency; dual-site async replication tolerates WAN latency), RPO achievable (near-zero sync vs minutes-hours async), operational complexity (witness placement and split-brain handling vs failover runbooks), and licensing/cost. Conclude with which business profiles each fits.
Complete an RCAR worksheet for the dual-site design (minimum: 5 requirements, 4 constraints, 4 assumptions, 6 risks with impact and mitigation). Include at least one risk unique to 9.1 tooling: e.g., wrong-site-context operator error enabled by fast context switching.
Prepare panel-response drills: answer aloud, in under two minutes each — (a) 'Your two sites were generated from one template. What happens to your symmetry claim after two years of independent Day-2 change?' (b) 'Why not stretch the cluster instead?' (c) 'Where exactly does your failure-domain boundary sit in this lab, and where would it sit in production?'
Validation Gate
Check: All five artifacts exist: drift position paper with diff evidence, scenario + applicability table, dual-site vs stretched matrix, RCAR worksheet, panel drill answers.
Expected: Design documentation strong enough to survive follow-up probing in a VCDX defense.
Final Validation
A dual-site Holodeck 9.1 deployment is operational from a single-pass auto-generated configuration: Site A and Site B configs produced together with guaranteed non-overlap, Site B deployed alongside a live Site A, cross-site routing and Technitium DNS validated bidirectionally, and management-plane independence demonstrated. The design exercise converts the tooling change into defense material: automation of the cross-site consistency problem, and a reasoned dual-site vs stretched topology position.
✓ Task 1: Single New-HoloDeckConfig pass produced Site A + Site B configs; context switching via Import-HoloDeckConfig -Site b verified → Two config files, non-overlapping allocation confirmed by diff, session context controllable
✓ Task 2: Prechecks pass for both sites with documented capacity headroom → Start-HoloDeckPrecheck green for -Site a and -Site b; ESX 8.0 U3+ confirmed
✓ Task 3: Site B deployed alongside live Site A → Get-HoloDeckInstance shows both instances Running on VCF 9.1.0.0; Site A undisturbed
✓ Task 4: Cross-site reachability, DNS, and independence validated → Bidirectional ping + Technitium DNS resolution; independent management stacks; Site B disturbance invisible to Site A
✓ Task 5: Design exercise complete → Drift position, topology comparison, RCAR, and panel drills documented
Cleanup / Restore
Snapshot: holodeck91-05-complete
• Snapshot all VMs of BOTH sites with a clear label (e.g. 'holodeck91-05-complete') — subsequent Day-2 labs (holodeck91-08/09) can run against either site
• Archive the Task 1 config diff, RCAR worksheet, and topology comparison to your VCDX evidence folder
• If physical resources are constrained, Stop-HoloDeckInstance the Site B instance (do NOT remove it) to reclaim RAM for later labs — record which site is stopped in your lab notebook
• If you must fully reclaim Site B: use Remove-HoloDeckInstance against the SITE B context only, and verify the site context twice before executing. Do not use -ResetHoloRouter on a shared or dual-site router — it tears down global routing/DNS state for everything on the host
Design Reflection (VCDX)
Two defense threads converge in this lab. THREAD 1 — configuration drift as an availability risk: panels increasingly probe operational consistency, not just steady-state architecture. The 9.1 one-pass generation is a concrete instance of the strongest anti-drift pattern: derive all instances from one computation rather than validating N hand-built instances against each other. Be ready to generalize: the same argument justifies infrastructure-as-code for production VCF (and the toolkit's own GitOps path), golden-image host provisioning, and declarative NSX policy.
Also be ready for the counterpunch: generation guarantees symmetry at time zero only — without ongoing enforcement (drift detection, redeploy-from-source discipline), two years of independent Day-2 change erodes the symmetry claim. THREAD 2 — topology selection: dual-site active-passive DR vs stretched cluster is a classic panel fork. Dual-site (this lab): independent failure domains, tolerant of WAN latency, asynchronous replication RPO in minutes, explicit failover with runbooks — simpler to reason about, slower to recover.
Stretched: near-zero RPO and transparent HA restart across sites, but demands <5ms RTT, L2 adjacency or overlay stretch, witness placement, and rigorous split-brain design — a harder operational commitment. The VCDX move is to bind the choice to stated business requirements (RPO/RTO, distance between sites, network budget, operational maturity) rather than to technology preference.
Finally, name the lab's honesty caveat before the panel does: both 'sites' share one physical host and one HoloRouter, so the lab rehearses logical topology and operational workflow, not genuine site-level failure isolation.
Requirements
- Two complete, independently manageable VCF 9.1 management domains (Site A production role, Site B DR role)
- Deterministic, non-overlapping network allocation across sites, produced without manual cross-site transcription
- Bidirectional cross-site management-plane reachability (IP and DNS) for replication and failover tooling
- Site B deployable next to a live Site A without disrupting Site A operations
- Operator ability to target either site unambiguously (session context control) for all lifecycle actions
- Design documentation sufficient to defend the dual-site vs stretched decision against stated RPO/RTO targets
Constraints
- Single physical host: both sites share one hardware failure domain and one HoloRouter transit/DNS layer — site-level disaster isolation cannot be genuinely rehearsed
- Physical capacity: dual-site requires ~768 GB RAM / 64+ cores / 2+ TB SSD; Site B sizing may need reduction on smaller hosts
- Holodeck 9.1 minimum nested ESX 8.0 U3 — older templates are rejected by the hardened installer validation
- Lab latency (<2ms) is unrepresentative of production inter-site links; latency-sensitive conclusions (stretched vSAN feasibility) cannot be validated here
- 9.1 HoloRouter service stack (Technitium/Vault/Authentik behind HTTPS proxy) invalidates 9.0.x DNS/service procedures; exact ingress paths and defaults must be verified per build
Assumptions
- Site A instance (holodeck91-02) is healthy and snapshotted before Site B deployment begins
- The auto-generated Site B allocation does not collide with any OTHER instance on a shared physical host (coordinate InstanceIDs and CIDRs with colleagues on shared hardware)
- The doubled-password API convention from 9.0.x persists on 9.1 builds (verify on first API call)
- Cmdlet-driven deployment path chosen for repeatability; GitOps/UI path (rn-9-1-016) assumed equivalent in outcome but not exercised here
- Production mapping assumes real dual-site would add: independent physical infrastructure per site, WAN latency, replication tooling, and failover orchestration not present in the lab
Risks
- Physical memory exhaustion during Site B deployment destabilizes live Site A — IMPACT: both sites degraded, possible total lab loss. MITIGATION: pre-deployment headroom calculation (Task 2), esxtop monitoring during deploy, Site A snapshots as rollback line, reduce Site B sizing when marginal.
- Wrong-site-context operator error: destructive cmdlet executed against the unintended site — IMPACT: damage to the healthy site. MITIGATION: Get-HoloDeckConfig context check before every action; personal runbook rule; snapshots before any destructive step.
- Stale 9.0.x artifacts (port groups, DNS records, module versions) contaminate the 9.1 dual-site deployment — IMPACT: precheck failures or subtle routing/DNS misbehavior. MITIGATION: clean the host of prior-version artifacts; never mix toolkit module versions in one session.
- Symmetry erosion over time: Day-2 changes applied to one site only — IMPACT: DR site no longer representative; failover fails when needed. MITIGATION: change-management rule that Day-2 changes apply to both sites or are logged as accepted asymmetry; periodic config re-diff against the generated baseline.
- Shared HoloRouter as hidden single point of failure for BOTH sites' transit and DNS — IMPACT: one router fault severs cross-site operations and name resolution everywhere. MITIGATION: acknowledge explicitly in the design; in production map this to redundant WAN/DNS infrastructure; see holodeck91-10 for the distributed VNA alternative to single-router networking.
- Treating lab DR rehearsal as production DR validation — IMPACT: false confidence in RPO/RTO claims. MITIGATION: applicability table (Task 5 step 2) states exactly which conclusions transfer; production targets validated only by production-representative testing.
Self-Assessment Discussion Prompts
- Explain precisely how one-pass dual-site generation eliminates the CIDR-overlap failure class. What error classes does it NOT eliminate?
- Your two sites are symmetric today because one tool generated both. Describe a governance mechanism that keeps them defensibly symmetric after two years of Day-2 operations.
- The 9.1 release notes say dual generation 'eliminates race conditions when deploying dual-site in parallel.' What was the race, and what does its existence tell you about the 9.0.x allocation model?
- Defend choosing dual-site active-passive DR over a stretched cluster for a business with RPO 1 hour / RTO 4 hours and 40ms inter-site RTT. Now invert it: what requirement changes would flip your recommendation to stretched?
- In this lab, what is the true failure-domain boundary between Site A and Site B? List every shared component and classify each as acceptable-in-lab-only or acceptable-in-production.
- A panelist asks: 'Auto-generation is convenient, but you cannot explain an allocation you did not make. Walk me through why Site B got the VLANs it got.' How do you answer without hand-waving?
- How would you extend this dual-site foundation toward a rehearsable failover: what replication, DNS failover, and runbook elements are missing between this lab and a testable DR capability?
Extensions
Drive the Site B Deployment via the GitOps Pipeline
Repeat the Site B deployment using the 9.1 Click-to-Deploy GitOps path (HoloRouter OVA with GitOps enabled, GitLab-driven pipeline, rn-9-1-016) instead of cmdlets. Compare: auditability of the pipeline vs verbose cmdlet logs, rollback story, and how the GitOps path handles the dual-site configuration pair. Document which path you would standardize on for a team lab and why.
sameDual-Site Workload Domain Rehearsal
With both management domains up, deploy a small VI workload domain on each site (see holodeck-05 methodology, adapted to 9.1) and document the full dual-site estate: per-site licensing, capacity, and the management-plane inventory a DR runbook would need. Note where 9.1's unified management services runtime changes the component inventory vs the 9.0 twin lab.
harderCross-Site Failover Runbook and Tabletop Exercise
Author a complete Site A to Site B failover runbook (detection, decision tree, DNS cutover via Technitium, service verification, RTO accounting) and run it as a tabletop exercise without executing destructive steps. Time each phase against a 2-hour RTO target and identify the longest-lead-time step.
harderDrift Injection and Detection
Deliberately introduce three configuration drifts on Site B (e.g., an extra port group, a changed NTP source, a modified DNS record) and build a detection script that diffs live state against the generated configuration baseline. This turns the drift position paper from Task 5 into a working control.
same⚠ Known Pitfalls (from Community KB)
References
- Announcing the General Availability of Holodeck 9.1 — VMware Cloud Foundation BlogTier 1 — Official
Official GA announcement: VCF 9.1.0.0/VVF 9.1.0.0/5.2.4 support, dual-site auto-generation, VNA cluster support, Day-2 operations, HoloRouter service stack. - Holodeck 9.1 DocumentationTier 1 — Official
Official 9.1 docs — authoritative for New-HoloDeckConfig dual-generation behavior, Import-HoloDeckConfig -Site parameter, and precheck workflow. Verify all cmdlet parameters here before deployment. - Simplify Multisite PoCs Using Holodeck — VMware Cloud Foundation BlogTier 1 — Official
Multisite deployment patterns with Holodeck; written against 9.0.2 but the topology reasoning carries into 9.1. - Holodeck-9.1/01-release-announcement.md + 02-structured-changelog.md (repo-local)
../../Holodeck-9.1/02-structured-changelog.mdlocal fileTier 2 — VMware Press
Captured release announcement and structured changelog used as the content baseline for this lab, including open questions to resolve against official release notes. - VCF Holodeck Toolkit — Broadcom Community ForumTier 1 — Official
Threads 10 (dual-site IP config), 19 (Site B vCenter not deploying), 30 (dual-site DNS) document the 9.0.x failure modes this lab's 9.1 workflow addresses. Note corpus is 9.0.x-era — verify applicability on 9.1. - academy-v2/content/releases/vcf-9.1.json — rn-9-1-018, rn-9-1-020
../releases/vcf-9.1.jsonlocal fileTier 2 — VMware Press
Canonical changelog entries this lab implements: dual-site config auto-generation (rn-9-1-018) and the VLAN/Site-B/installer fixes (rn-9-1-020).