Academy/Holodeck Lab Setup & Operations/Dual-Site Holodeck Deployment
This lab targets VCF 9.0.2

Dual-Site Holodeck Deployment

VCF 9.0.2Advancedarchitectvcdx⏱ 180 min

Holodeck 2.1.x added native dual-site support via New-HoloDeckNetworkConfig with -Site parameter. Applicable to VCF 9.0.0+ only. Requires a single physical host with doubled resource footprint.

Objectives

  • Design a non-overlapping IP addressing scheme for a dual-site Holodeck topology
  • Configure the Holodeck Toolkit to deploy Site B management domain with cross-site routing
  • Establish HoloRouter-A to HoloRouter-B peering using BGP or static routes
  • Validate bidirectional management plane reachability and DNS cross-resolution
  • Map a dual-site lab topology to production VCDX disaster recovery and stretched cluster architecture using RCAR framework

Prerequisites

Single Holodeck 9.0.2 management domain fully deployed and healthy (holodeck-02 completed). Physical host must have minimum 768 GB RAM, 64+ logical cores, 2+ TB SSD (due to doubled resource footprint for Site B). Site A instance must be in a stable state — snapshot taken. No existing dual-site configuration.

Prior labs: holodeck-02

Required skills:

  • VCF management domain architecture (SDDC Manager, vCenter, NSX)
  • IP address planning and CIDR notation
  • BGP routing concepts (or comfort with static route configuration)
  • vCenter Enhanced Linked Mode concepts
  • NSX federation and multi-site networking
  • Disaster recovery and RTO/RPO analysis
📸 Starting State: S3-52 — Management Domain Deployed (VCF 5.2)

Lab Environment

Dual physical Holodeck instances on a single ESXi host OR on two separate physical hosts. Site A (production) uses 10.1.0.0/20 management CIDR with 4 ESXi hosts in 10.1.1.0/24. Site B (DR) uses 10.2.0.0/20 management CIDR with 4 ESXi hosts in 10.2.1.0/24. HoloRouter-A and HoloRouter-B are configured in dual-site mode with BGP peering (optional) or static route redistribution to achieve cross-site reachability. Both sites reach the shared HoloRouter's routing interfaces on 10.1.16.1 (Site A) and 10.2.16.1 (Site B).

graph TB
  PHY[Single ESXi Host - 768 GB RAM] --> HR[HoloRouter Dual-Site 10.1.16.1 / 10.2.16.1]
  HR -->|BGP Peering| BGP[BGP: Site A ASN 65001 | Site B ASN 65002]
  subgraph SiteA["Site A - Production (10.1.0.0/20)"]
    HR1[HoloRouter-A 10.1.16.1]
    HR1 --> ESXiA1[ESXi-01 10.1.1.101]
    HR1 --> ESXiA2[ESXi-02 10.1.1.102]
    HR1 --> ESXiA3[ESXi-03 10.1.1.103]
    HR1 --> ESXiA4[ESXi-04 10.1.1.104]
    HR1 --> CBA[Cloud Builder 10.1.0.200]
    HR1 --> SDDC_A[SDDC Manager 10.1.0.4]
    HR1 --> VC_A[vCenter-A 10.1.0.6]
    HR1 --> NSX_A[NSX Manager-A 10.1.0.10]
  end
  subgraph SiteB["Site B - DR (10.2.0.0/20)"]
    HR2[HoloRouter-B 10.2.16.1]
    HR2 --> ESXiB1[ESXi-01 10.2.1.101]
    HR2 --> ESXiB2[ESXi-02 10.2.1.102]
    HR2 --> ESXiB3[ESXi-03 10.2.1.103]
    HR2 --> ESXiB4[ESXi-04 10.2.1.104]
    HR2 --> CBB[Cloud Builder 10.2.0.200]
    HR2 --> SDDC_B[SDDC Manager 10.2.0.4]
    HR2 --> VC_B[vCenter-B 10.2.0.6]
    HR2 --> NSX_B[NSX Manager-B 10.2.0.10]
  end
  BGP -->|Cross-site IP reachability| HR1
  BGP -->|Cross-site IP reachability| HR2

IP Addressing

NetworkPurposeVLAN
10.1.0.0/20Site A management network supernetVLAN 1644
10.1.1.0/24Site A ESXi host management VMkernelVLAN 1644
10.1.2.0/24Site A vMotion (if stretched cluster)VLAN 1645
10.1.3.0/24Site A vSAN (if stretched vSAN)VLAN 1646
10.1.4.0/24Site A NSX Host TEPVLAN 1647
10.1.5.0/24Site A NSX Edge TEPVLAN 1648
10.2.0.0/20Site B management network supernetVLAN 1704
10.2.1.0/24Site B ESXi host management VMkernelVLAN 1704
10.2.2.0/24Site B vMotion (if stretched cluster)VLAN 1705
10.2.3.0/24Site B vSAN (if stretched vSAN)VLAN 1706
10.2.4.0/24Site B NSX Host TEPVLAN 1707
10.2.5.0/24Site B NSX Edge TEPVLAN 1708

Credentials

SystemUsernamePassword
Physical ESXi HostrootSet during ESXi installation
HoloConsole (Webtop)holodeckDefault Holodeck password from Toolkit docs
Site A ESXi HostsrootSet by Holodeck config.json esxiPassword field
Site B ESXi HostsrootSet by Holodeck Site B config.json esxiPassword field
Cloud Builder Aadmin@localSet by Holodeck config.json cbPassword field
Cloud Builder Badmin@localSet by Holodeck Site B config.json cbPassword field
SDDC Manager Aadministrator@vsphere.localSet in VCF bring-up spec JSON
SDDC Manager Badministrator@vsphere.localSet in VCF bring-up spec JSON
vCenter-Aadministrator@vsphere.localSame as SDDC Manager A SSO password
vCenter-Badministrator@vsphere.localSame as SDDC Manager B SSO password
NSX Manager-AadminSet in VCF bring-up spec JSON
NSX Manager-BadminSet in VCF bring-up spec JSON. API password is VMware123!VMware123! (doubled)

Tasks

Task 1 Plan the dual-site topology and IP addressing scheme

availability

In VCDX design, topology and addressing are foundational. A panelist will probe your understanding of failure domain boundaries, network isolation, and resource allocation across sites. Dual-site planning surfaces the architectural trade-offs: single physical host = no site-level HA, but identical infrastructure = simpler operational model. This task mirrors the VCF Planning and Preparation Workbook exercise for multi-site deployments.

Step 1

Document your dual-site topology in a design worksheet (text or spreadsheet). Start with Site A baseline (from holodeck-02): management CIDR 10.1.0.0/20, ESXi cluster 10.1.1.0/24, vMotion 10.1.2.0/24, vSAN 10.1.3.0/24, NSX Host TEP 10.1.4.0/24, NSX Edge TEP 10.1.5.0/24, VLAN range 1644-1648.

Worksheet or document showing Site A network baseline with all subnets and VLANs mapped
Step 2

Design Site B network configuration using non-overlapping IP ranges. Recommended: Site B management CIDR 10.2.0.0/20 (no overlap with 10.1.0.0/20), ESXi cluster 10.2.1.0/24, vMotion 10.2.2.0/24, vSAN 10.2.3.0/24, NSX Host TEP 10.2.4.0/24, NSX Edge TEP 10.2.5.0/24, VLAN range 1704-1708 (no overlap with 1644-1648). This design allows symmetric topologies while avoiding overlap.

Site B network configuration with all subnets and VLANs mapped — all ranges must be non-overlapping with Site A
Overlapping CIDRs are a critical failure mode. The KB thread 'Holodeck 9.0.2 dual-site IP config' (thread index 10) documents a case where Site A and Site B inadvertently used the same CIDR range, causing routing conflicts. Always verify non-overlap before proceeding.
Step 3

Document cross-site routing requirements. Both sites must reach each other's management plane (SDDC Manager, vCenter, NSX). Create a routing table for each direction: Site A to Site B routes (10.2.0.0/20 via Site B HoloRouter gateway) and Site B to Site A routes (10.1.0.0/20 via Site A HoloRouter gateway). Note the gateway IPs: HoloRouter-A will have interfaces in both 10.1.16.1/24 and an externally-accessible IP; HoloRouter-B will have interfaces in both 10.2.16.1/24 and an externally-accessible IP.

Routing table document showing bidirectional routes and gateway IPs
In a real dual-site VCF deployment, you would use BGP, OSPF, or static routes on physical switches. In Holodeck, the HoloRouter(s) handle this via Set-HoloRouter -dualsite flag with FRR (BGP daemon) configuration.
Step 4

Analyze physical resource requirements. Site A already allocated ~16 vCPU + 384 GB RAM (4 ESXi hosts at 12vCPU/96GB each) from your physical host. Site B will need the same: ~16 vCPU + 384 GB RAM. Total dual-site footprint: ~32 vCPU + 768 GB RAM (plus 32 GB for management VMs). Verify your physical host has at least 768 GB RAM and 64 logical cores. If using a single physical host, document resource contention risks and mitigations.

Resource allocation table showing Site A usage, Site B usage, total usage, and comparison to physical host capacity
Resource exhaustion on a single physical host can cause cascading failures. The KB thread 'Holodeck 9.0.2 Dual Site B vCenter not deploying' (thread index 19) shows a case where Site B vCenter deployment failed due to insufficient remaining memory on the physical host. Mitigation: monitor physical host memory during Site B deployment, or use two separate physical hosts if available.
Step 5

Create a failure domain analysis. In this dual-site topology on a single physical host, what is the failure domain boundary? Answer: Both Site A and Site B share the same single point of failure (the physical host). In production, you would have separate physical hosts or data centers. Document how this affects your RTO/RPO strategy (covered in Task 5).

Failure domain matrix showing: failure mode (e.g., physical host crash), blast radius (both sites lost), detection time, recovery time, and mitigation

Validation Gate

Check: Review your design worksheet: (1) Site A and Site B CIDRs are non-overlapping, (2) VLAN ranges are non-overlapping, (3) cross-site routing table is complete, (4) resource allocation is verified against physical host capacity, (5) failure domain analysis is documented.

Expected: All five validation points pass. You are ready to implement the dual-site Holodeck configuration.

Common Errors

CIDR overlap between Site A (10.1.0.0/20) and Site B (10.1.0.0/20 or 10.1.16.0/20) — routing conflicts after both sites deploy
Cause: Copy-paste error or misunderstanding of Site B CIDR planning — the second site must use a completely non-overlapping address space
Fix: Re-design Site B using a different CIDR block (e.g., 10.2.0.0/20 or 192.168.0.0/20 if using a different octet entirely). Destroy Site B instance and reconfigure from scratch with correct CIDR.
📋 KB: Thread 10: Holodeck 9.0.2 dual-site IP config
Physical host memory exhaustion during Site B deployment — OOM killer activates, Site A becomes unstable
Cause: Insufficient buffer between Site A allocation and total physical host memory. Site B deployment causes memory oversubscription.
Fix: Monitor physical host memory continuously during Site B Prepare and Start phases. If nearing 90% utilization, pause Site B deployment and reduce resource allocations (e.g., 3 ESXi hosts instead of 4). Alternatively, deploy Site B on a second physical host if available.
📋 KB: Thread 19: Holodeck 9.0.2 Dual Site B vCenter not deploying

Task 2 Deploy Site B Holodeck instance with cross-site network configuration

availability

Executing the dual-site deployment is the operational foundation for VCDX multi-site architecture discussions. This task surfaces the orchestration complexity: two independent VCF bring-ups running on shared infrastructure, with potential resource contention and deployment ordering dependencies. Understanding what can fail independently vs what is tightly coupled is critical VCDX knowledge.

Step 1

On the HoloConsole or management workstation, open PowerShell and navigate to the Holodeck runtime directory: cd C:\Holodeck\holodeck-runtime

PowerShell prompt at holodeck-runtime directory
Step 2

Create a new Holodeck configuration for Site B. Use: New-HoloDeckConfig -Description 'holodeck-06-site-b' -TargetHost <your-physical-esxi-host> -Username root -Password <esxi-root-password>. Capture the generated ConfigID (e.g., 'a1b2').

New config generated with ConfigID. Output shows: [SUCCESS] HoloDeckConfig <id> is generated successfully!
The ConfigID is used in subsequent commands. Save it to a notepad file for reference.
Step 3

Configure Site A network (if not already configured from holodeck-02). Run: New-HoloDeckNetworkConfig -Site a -MasterCIDR 10.1.0.0/20 -VLANRangeStart 10

Network configuration generated successfully for Site A with CIDR 10.1.0.0/20 and VLANs starting at 1644 (10+1634)
Step 4

Configure Site B network. Run: New-HoloDeckNetworkConfig -Site b -MasterCIDR 10.2.0.0/20 -VLANRangeStart 40. This generates a separate network config for Site B with CIDR 10.2.0.0/20 and VLANs starting at 1704 (40+1664).

Network configuration generated successfully for Site B with CIDR 10.2.0.0/20 and VLANs starting at 1704
If you see 'Network config file for site b already exists', you may be overwriting a previous attempt. Verify the previous site-b instance was destroyed (Remove-HoloDeckInstance) before re-creating.
Step 5

Configure the HoloRouter for dual-site operation. Run: Set-HoloRouter -dualsite. This configures BGP peering between Site A and Site B router interfaces and sets up VLAN interfaces for both sites on the physical host.

HoloRouter configuration completes with [SUCCESS] HoloRouter Configured Successfully
After Set-HoloRouter -dualsite, restart the HoloRouter VM if BGP peering does not immediately converge. The KB thread 'Holodeck 9.0.2 dual-site IP config' (thread index 10) documents a case where a HoloRouter reboot cleared the interface config and resolved the issue.
Step 6

Edit the Site B configuration file to customize hostname, IP assignments, and resource sizing. Open: notepad ./templates/config.json. Locate the 'site' or 'siteId' field and set it to 'b' or '2' (depending on Holodeck version). Verify managementCIDR is 10.2.0.0/20. Optionally adjust ESXi host resource sizing to avoid contention (e.g., reduce from 12vCPU/96GB to 10vCPU/80GB per host if physical host is constrained).

config.json updated with Site B parameters, site field set to 'b', managementCIDR set to 10.2.0.0/20
Step 7

Prepare the Site B Holodeck instance. Run: New-HoloDeckInstance -ConfigFile ./templates/config.json -Verbose. This stages Site B artifacts, validates host compatibility, and configures HoloRouter-B interfaces. Monitor for errors.

Prepare phase completes with 'Prepare phase completed successfully.' Progress stream shows content validation, ESXi ISO extraction, OVA staging, HoloRouter-B deployment.
Prepare takes 15-30 minutes. If it exceeds 45 minutes or hangs at 'Waiting for FRR service', see the common errors below.
Step 8

Verify Site B HoloRouter is configured. From HoloConsole, SSH to the HoloRouter and run: vtysh -c 'show bgp summary'. You should see two neighbors (Site A and Site B) with established connections, or if using static routing, verify the routing table with 'show ip route'.

BGP summary shows Site A-to-Site B peering established, or static routes show 10.2.0.0/20 reachable via Site B gateway
Step 9

Start the Site B VCF deployment. Run: Start-HoloDeckInstance -InstanceID <site-b-config-id> -Verbose. This orchestrates nested ESXi provisioning, Cloud Builder deployment, and full VCF bring-up for Site B. Monitor the verbose output for progress.

Deployment progresses through ESXi provisioning, Cloud Builder initialization, SDDC Manager deployment, vCenter deployment, NSX deployment, and host commissioning. Final output: 'VCF Management Domain deployment completed successfully. Instance ID: <id>, State: Running'
Site B deployment takes 90-150 minutes. Resource contention with Site A may slow it down further. Monitor physical host memory every 10-15 minutes (esxtop on physical host). If memory utilization exceeds 95%, the deployment may fail. Consider pausing and resuming if necessary.

Validation Gate

Check: Run: Get-HoloDeckInstance | Format-Table -Property InstanceId, State, VcfVersion, Site. Verify both Site A and Site B instances show 'Running' state.

Expected: Two Holodeck instances listed: Site A (or Instance 1) and Site B (or Instance 2), both in Running state, both VCF 9.0.2

Common Errors

Set-HoloRouter -dualsite hangs at 'Configuring iptables' or 'Waiting for FRR service' for 10+ minutes
Cause: HoloRouter initialization timeout or BGP daemon (FRR) slow to start — resource contention on physical host
Fix: Wait up to 30 minutes for FRR to start. If still stuck, SSH into HoloRouter (ssh admin@10.1.1.1 or 10.1.1.2 depending on site) and run: systemctl restart frr. If that fails, reboot the HoloRouter VM or destroy and re-run Set-HoloRouter -dualsite.
📋 KB: Thread 10: Holodeck 9.0.2 dual-site IP config (resolution: HoloRouter reboot cleared the config)
New-HoloDeckInstance fails with 'Cannot select datastore' or similar storage error during ESXi provisioning
Cause: Physical datastore is full or Space is insufficient after Site A allocation. Datastore name mismatch between config.json and physical inventory.
Fix: Verify physical datastore free space exceeds 500 GB (minimum for Site B). Check datastore name in config.json matches the physical host inventory. If necessary, use vSphere Client to clean up orphaned VMs or snapshots from failed previous attempts.
📋 KB: Thread 51: Holodeck vcf 9 - Cannot select datastore
Site B vCenter deployment fails: vmware-vpostgres service crashes on start, services stopped
Cause: vCenter VM insufficient memory on physical host. Site A and Site B memory allocations are oversubscribed. Alternatively, DNS not working on Site B (vCenter needs DNS to initialize).
Fix: Check physical host memory utilization (esxtop). If >95%, reduce Site B ESXi host memory allocation or reduce host count. Verify DNS on Site B management network: ping Site B DNS IP from a Site B ESXi host. If DNS fails, verify HoloRouter-B DNS service is running (see Task 3).
📋 KB: Thread 19: Holodeck 9.0.2 Dual Site B vCenter not deploying
Site B ESXi hosts deploy successfully, but Cloud Builder initialization fails: 'VCF Installer is not ready yet'
Cause: Cloud Builder VM is resource-starved (insufficient memory or CPU after Site A allocation). Or NTP/DNS not synced on Site B.
Fix: SSH to Site B Cloud Builder (ssh admin@10.2.0.200) and check: (a) ntpq -p to verify NTP sync, (b) nslookup sddc-manager.site-a.vcf.lab to verify DNS, (c) systemctl status vcf-bringup to see initialization status. Fix DNS or NTP if needed, then restart the bring-up service.

Task 3 Configure cross-site networking and validate bidirectional reachability

manageability

Cross-site networking is where the architecture comes alive. In VCDX terms, this task probes your understanding of Layer 3 network design, failure domain isolation, and multi-site management traffic engineering. A panelist will ask: 'How do you ensure vCenter-A can manage ESXi-B?' or 'What happens if the cross-site link fails?' This task makes those questions concrete.

Step 1

Verify HoloRouter BGP or static routes are configured for cross-site routing. From HoloConsole, SSH into the HoloRouter (ssh admin@10.1.1.1 or whichever is the main router IP) and run: vtysh -c 'show bgp ipv4 unicast' or if static routing: vtysh -c 'show ip route'. You should see routes for both 10.1.0.0/20 and 10.2.0.0/20 advertised or installed.

BGP output shows both Site A and Site B CIDRs with valid next-hops, or static routing shows 10.1.0.0/20 and 10.2.0.0/20 in the routing table
Step 2

Test reachability from Site A to Site B management plane. From HoloConsole, ping Site B SDDC Manager: ping 10.2.0.4. Then ping Site B vCenter: ping 10.2.0.6. Both should reply with <1ms latency (same physical host).

Reply from 10.2.0.4 and 10.2.0.6, each with <2ms latency
Step 3

Test reachability from Site B to Site A management plane. SSH to Site B HoloConsole or a Site B ESXi host (ping from 10.2.x.x range) and ping Site A SDDC Manager: ping 10.1.0.4. Then ping Site A vCenter: ping 10.1.0.6. Both should reply.

Reply from 10.1.0.4 and 10.1.0.6, each with <2ms latency
Step 4

Configure DNS cross-resolution. From Site A HoloConsole, add Site B FQDNs to the HoloRouter DNS forwarder. SSH to HoloRouter and edit /etc/dnsmasq.conf to add: address=/sddc-manager-b.site-a.vcf.lab/10.2.0.4, address=/vcenter-b.site-a.vcf.lab/10.2.0.6, address=/nsx-manager-b.site-a.vcf.lab/10.2.0.10. Restart DNS: systemctl restart dnsmasq. Repeat for Site B (add Site A FQDNs).

DNS service restarts without errors. nslookup vcenter-b.site-a.vcf.lab from Site A resolves to 10.2.0.6.
Alternatively, use /etc/hosts files on each management VM if centralized DNS configuration is not available.
Step 5

Validate SDDC Manager awareness of both sites. From Site A SDDC Manager UI (https://10.1.0.4), navigate to Administration > Licensing or Inventory > Workload Domains. Verify Site A is listed. Then attempt to configure Site B workload domain addition (if your VCF licensing allows multi-domain). If multi-domain is not enabled, document the licensing constraint.

SDDC Manager shows management domain in Site A. If attempting to add Site B workload domain, proceed to next step.
Step 6

If deploying NSX federation (multi-site), configure NSX-A to peer with NSX-B. From NSX Manager-A UI (https://10.1.0.10), navigate to System > Federation. Click 'Join Federation' and enter NSX Manager-B IP (10.2.0.10) and credentials. Complete the federation handshake. Verify bidirectional federation status: both NSX managers should show 'Federation Status: Connected'.

NSX Federation configured and both NSX managers show 'Connected' status
NSX federation is optional for this lab. If your NSX licensing does not include federation, skip this step and document the constraint.
Step 7

Test management plane operations from both sites. From Site A vCenter, verify that you can see Site B ESXi hosts by navigating to Inventory > Hosts. If Enhanced Linked Mode is configured (vCenter-A linked to vCenter-B), you should see both sites' objects. Create a test VM on Site A cluster and verify it's managed by Site A vCenter.

Site A vCenter correctly manages Site A resources. If Linked Mode is enabled, both Site A and Site B objects are visible.

Validation Gate

Check: Perform three checks: (1) ping 10.2.0.4 and 10.2.0.6 from Site A, (2) ping 10.1.0.4 and 10.1.0.6 from Site B, (3) nslookup vcenter-b.site-a.vcf.lab from Site A resolves to 10.2.0.6 and vice versa.

Expected: All three checks pass. Bidirectional IP and DNS reachability confirmed between sites.

Common Errors

Ping to Site B management IPs fails: 'Destination unreachable' or 'Request timed out'
Cause: Cross-site routing not configured, or BGP peering failed. HoloRouter routes not correctly propagated.
Fix: Verify HoloRouter BGP neighbors with vtysh -c 'show bgp summary'. If neighbors are not established, check if FRR service is running (systemctl status frr). Check BGP configuration: vtysh -c 'show running-config | include bgp' to see peer definitions. If needed, restart FRR and re-check BGP state.
📋 KB: Thread 10: Holodeck 9.0.2 dual-site IP config (resolution: HoloRouter reboot)
DNS resolution fails: nslookup vcenter-b.site-a.vcf.lab returns NXDOMAIN or timeout
Cause: DNS forwarder not configured for Site B FQDNs, or DNS service not reachable from Site A network
Fix: SSH to HoloRouter and verify dnsmasq is running (systemctl status dnsmasq). Check /etc/dnsmasq.conf for Site B address entries. Add entries if missing, then systemctl restart dnsmasq. Verify DNS service is listening on 10.1.1.1 or the configured DNS IP.
📋 KB: Thread 30: Issue with DNS resolution in Holodeck dual-site deployment
BGP peering shows 'Established' but ping still fails — routes not in routing table
Cause: BGP peering established but routes not being advertised. Route-map or prefix-list filtering may be blocking routes.
Fix: Check BGP advertised routes: vtysh -c 'show ip bgp neighbors 10.2.0.1 advertised-routes' (or Site A IP from Site B perspective). If no routes are advertised, check the BGP configuration for missing 'network' statements or route-map issues.

Task 4 Validate dual-site management plane operations

manageability

Post-deployment validation proves that the dual-site architecture is operational and ready for VCDX-level design discussions. This task operationalizes the abstract concepts: Can you manage both sites from a single pane of glass (SDDC Manager or vCenter Linked Mode)? What visibility does each site have into the other? How do you know if the cross-site link is healthy? These are the questions a VCDX panelist will ask during design defense.

Step 1

From HoloConsole webtop, open Firefox and navigate to SDDC Manager-A: https://10.1.0.4. Log in with administrator@vsphere.local. Navigate to Inventory > Workload Domains. Verify the management domain shows Status: Active with 4 hosts, 1 cluster.

SDDC Manager-A dashboard shows management domain Active
Step 2

Open a new tab and navigate to SDDC Manager-B: https://10.2.0.4. Log in with administrator@vsphere.local (Site B credentials). Verify Site B management domain shows Status: Active with 4 hosts, 1 cluster.

SDDC Manager-B dashboard shows management domain Active
Step 3

Open a third tab and navigate to vCenter-A: https://10.1.0.6. Log in with administrator@vsphere.local. Navigate to Hosts and Clusters. Verify the management cluster shows 4 connected ESXi hosts, vSAN health green, DRS enabled, HA enabled.

vCenter-A shows management cluster with 4 healthy hosts, vSAN green, HA/DRS enabled
Step 4

Open a fourth tab and navigate to vCenter-B: https://10.2.0.6. Log in with administrator@vsphere.local (Site B credentials). Navigate to Hosts and Clusters. Verify the management cluster shows 4 connected ESXi hosts, vSAN health green, DRS enabled, HA enabled.

vCenter-B shows management cluster with 4 healthy hosts, vSAN green, HA/DRS enabled
Step 5

Configure vCenter Enhanced Linked Mode (optional but recommended for VCDX). In vCenter-A, navigate to Administration > System Configuration > Enhanced Linked Mode. Click 'Join'. Enter vCenter-B FQDN (vcenter-b.site-a.vcf.lab or IP 10.2.0.6) and Site B administrator@vsphere.local credentials. Complete the pairing. Repeat from vCenter-B to establish bidirectional link.

vCenter-A and vCenter-B show 'Linked Mode Status: Connected' in Administration > System Configuration
Step 6

Navigate to NSX Manager-A: https://10.1.0.10. Log in with admin. Navigate to System > Fabric > Nodes > Host Transport Nodes. Verify all 4 Site A ESXi hosts show Configuration State: Success and Transport Node Status: Up. Repeat for NSX Manager-B to verify Site B hosts.

NSX Manager-A shows 4 host transport nodes up, NSX Manager-B shows 4 host transport nodes up
Step 7

Test cross-site management from Site A vCenter. In vCenter-A Linked Mode view, verify you can see both Site A and Site B objects (datacenters, clusters, hosts). Create a test folder in Site A datacenter. From Site B vCenter, verify the folder is visible (if Linked Mode is working). This proves bidirectional management plane visibility.

vCenter Linked Mode shows both sites' objects. Test folder created on Site A is visible in Site B vCenter.
Step 8

Document the dual-site operational readiness. Create a status report showing: (a) Both SDDC Managers healthy and licensed, (b) Both vCenters healthy and Linked Mode connected, (c) Both NSX Managers healthy and federation status (if applicable), (d) Cross-site ping reachability confirmed, (e) Management traffic can traverse between sites without errors.

Status report document with all five operational health metrics completed and passing

Validation Gate

Check: Verify: (1) SDDC Manager-A and SDDC Manager-B both show Active status, (2) vCenter-A and vCenter-B both show 4 healthy hosts with green vSAN/HA/DRS, (3) vCenter Linked Mode connected (if deployed), (4) NSX-A and NSX-B both show 4 host transport nodes up.

Expected: All management components dual-site healthy. Cross-site operations fully functional.

Common Errors

vCenter Linked Mode pairing fails: 'Cannot establish connection to remote vCenter'
Cause: DNS resolution failing between sites, or SSL certificate validation failing due to FQDN mismatch
Fix: Verify DNS is working: nslookup vcenter-b.site-a.vcf.lab from Site A should resolve. Ensure you use FQDN (not IP) for Linked Mode pairing. Accept self-signed certificates when prompted.
NSX Manager-B shows some host transport nodes as 'Install Failed' after deployment
Cause: NSX VIB installation on Site B ESXi hosts timed out or failed due to resource contention
Fix: In NSX Manager-B, select the failed host and click 'Resolve'. Wait for re-installation to complete. If it fails again, check Site B ESXi host memory and network connectivity.

Task 5 Design exercise — Map dual-site Holodeck to production DR architecture using RCAR

recoverability

This is the VCDX defense moment. You have a working dual-site lab. Now articulate the architectural decisions, trade-offs, and risk mitigations using the RCAR framework. A VCDX panelist will probe: 'Why is this design suitable for DR?' 'What are the RPO and RTO assumptions?' 'How does your stretched cluster design differ from active-active?' 'What failover automation have you considered?' This task forces you to think like an architect, not just a lab technician.

Step 1

Define the production DR scenario that your dual-site Holodeck represents. Example: 'Site A is the primary production datacenter (Houston). Site B is the DR datacenter (Dallas). Business applications run on Site A vSAN clusters. Site B is initially cold (powered off or minimal resources). RPO target: 1 hour (hourly snapshots + vSphere Replication). RTO target: 2 hours (manual failover via SDDC Manager + NSX policy failover).' Document your scenario in a design worksheet.

Scenario document describing primary site, DR site, business objectives, RPO/RTO targets
Step 2

Create RCAR analysis for your design: Requirements, Constraints, Assumptions, Risks.

Completed RCAR worksheet (see breakdown below)
Step 3

REQUIREMENTS: What must the design achieve? List at least 5 requirements. Example: (a) Ability to replicate application VMs from Site A to Site B, (b) Automatic network failover via NSX (traffic redirects to Site B IPs), (c) SDDC Manager can manage both sites, (d) RPO <= 1 hour, RTO <= 2 hours, (e) Cross-site management traffic must be encrypted and authenticated.

Requirements list with at least 5 items
Step 4

CONSTRAINTS: What limits your design? List at least 4. Example: (a) Single physical host in the lab (vs two separate data centers in production), (b) Holodeck 2.1.x supports dual-site but not NSX stretched security groups, (c) vSAN stretched cluster requires L2 adjacency (vMotion VLAN must span sites — not possible in this lab setup), (d) Licensing: dual-site failover requires additional per-host licenses, (e) Network latency: <5ms RTT required for stretched vSAN (lab has <2ms, but real WAN would not).

Constraints list with at least 4 items describing technical, operational, and licensing limits
Step 5

ASSUMPTIONS: What are you assuming will be true in production? List at least 4. Example: (a) Assume vSphere Replication licenses are available, (b) Assume cross-site network has <5ms latency and 1 Gbps+ bandwidth, (c) Assume vCenter Enhanced Linked Mode is deployed and functioning, (d) Assume Site B is pre-provisioned and ready for failover (not a cold DR site requiring hours to boot), (e) Assume SDDC Manager can manage both sites without license overhead.

Assumptions list with at least 4 items stating what you're taking for granted
Step 6

RISKS: What can go wrong? List at least 6 with impact and mitigation. Example: (a) Risk: Cross-site network link fails. Impact: Site B becomes unreachable; applications on Site A continue running but replication stops. Mitigation: Monitor cross-site latency and packet loss continuously. If link fails, manual failover is required (RTO extends to 4+ hours). (b) Risk: vCenter Linked Mode breaks during failover (split-brain scenario). Impact: Operator confusion, potential dual VM registration. Mitigation: Document failover runbook explicitly stating which vCenter (A or B) is authoritative post-failover. (c) Risk: RPO not met due to replication lag. Impact: Data loss up to max lag period. Mitigation: Monitor replication lag per VM; alert if any VM exceeds RPO threshold. (d) Risk: Stretched vSAN cluster experiences latency-induced failures. Impact: vSAN rebuild operations slow down, increasing window of vulnerability. Mitigation: Use synchronous replication only for critical VMs; asynchronous for bulk workloads. (e) Risk: DNS failover not automated — Site B FQDNs not automatically updated. Impact: Applications connect to stale Site A IPs post-failover. Mitigation: Use dynamic DNS updates via DHCP or implement application-level connection pooling with fallback. (f) Risk: Disaster recovery drill reveals missing backup of SDDC Manager or vCenter configuration. Impact: Can't re-provision management domain on Site B if Site A fails completely. Mitigation: Weekly backup of SDDC Manager DB and vCenter; store offsite.

Risks list with at least 6 items, each describing impact and mitigation
Step 7

Map VCDX Design Quality dimensions to your dual-site architecture. For each of the 5 dimensions (Availability, Manageability, Performance, Recoverability, Security), describe how your design addresses it and where trade-offs were made. Example: Availability: Stretched vSAN with RAID-1 provides N+1 node failure tolerance. Trade-off: RAID-1 uses 50% of capacity. Performance: Asynchronous vSphere Replication avoids cross-site latency impact on Site A; RPO trade-off is 1 hour instead of near-zero. Manageability: Dual SDDC Managers (one per site) simplifies independent lifecycle operations but increases operational burden. Security: Cross-site replication traffic is encrypted; NSX Federation provides separate policy domains per site for workload isolation.

Design quality matrix with 5 rows (Availability, Manageability, Performance, Recoverability, Security) and columns for design choice, trade-offs, and rationale
Step 8

Create a failover decision tree. Starting from 'Primary site failure detected', walk through the decision logic: (a) Is it a network link failure only (Site A still operational but unreachable)? Decision: Do NOT failover; fix the link. (b) Is it a complete Site A power loss? Decision: Initiate failover (RTO 2 hours). (c) Is it a partial failure (e.g., vCenter-A down but ESXi-A hosts up)? Decision: SDDC Manager can manage from Site B; no failover needed. Document the tree as a flowchart or table.

Failover decision tree showing at least 3 failure scenarios and the corresponding action (failover or not)
Step 9

Simulate a failover scenario. Assume Site A vCenter has become unavailable (you can disconnect its network or shut it down). Document the steps an operator would follow to: (a) Confirm Site A is truly down, (b) Update DNS to point to Site B vCenter (or confirm NSX failover has redirected traffic), (c) Open Site B vCenter and verify all replicated VMs are present and can be powered on, (d) Power on critical application VMs on Site B, (e) Verify applications are accessible on Site B IPs, (f) Document the actual RTO achieved and compare to target (2 hours). Do NOT actually perform the simulation in this lab — instead, write out the step-by-step runbook and estimate timings.

Failover runbook with steps (a)-(f) and estimated total RTO. Example: 'Confirm Site A down: 5 min. Update DNS: 5 min. Verify Site B vCenter: 10 min. Power on critical VMs (50 VMs × 1 min avg): 50 min. Verify application availability: 15 min. Total RTO: ~85 minutes (target 2 hours) — PASS.'

Validation Gate

Check: Verify all 9 steps completed: (1) Scenario documented, (2) RCAR worksheet created, (3)-(6) RCAR sections filled (Requirements, Constraints, Assumptions, Risks), (7) Design Quality matrix completed for all 5 dimensions, (8) Failover decision tree documented, (9) Failover runbook written with RTO estimate.

Expected: Complete design exercise documentation suitable for VCDX oral defense. A panelist would be able to ask follow-up questions on any section and receive detailed, architectural responses.

Common Errors

RCAR sections are vague or generic (e.g., 'Requirement: High availability' with no quantified targets)
Cause: Not connecting the lab topology to specific production constraints. RCAR is not a template exercise but a reflection on YOUR design.
Fix: Go back to the lab: What did you actually build? Map each component (e.g., vSAN stretched cluster, NSX federation, vSphere Replication) to a specific RCAR section. Be concrete: 'Stretched vSAN requires L2 adjacency' is a Constraint. 'We assume vMotion VLAN can span 10 Gbps cross-site link' is an Assumption.
Failover decision tree missing critical scenarios or not actionable (e.g., 'If anything fails, failover' with no logic)
Cause: Not thinking through the operational reality of dual-site failover. A panelist will ask: 'What if vCenter-A is down but ESXi-A is up? Do you failover?'
Fix: Expand the decision tree to at least 5 failure scenarios: (1) vCenter-A only, (2) SDDC Manager-A only, (3) NSX Manager-A only, (4) entire Site A network link down, (5) partial link failure (high latency only). For each, specify: Failover or not? Which components?'

Final Validation

A complete dual-site Holodeck deployment (Site A and Site B) is fully operational with validated cross-site networking, management plane visibility, and a production-ready DR architecture design documented using RCAR framework. All 5 design qualities (Availability, Manageability, Performance, Recoverability, Security) have been analyzed with explicit trade-offs articulated. This lab is the gateway to VCDX multi-site architecture discussions.

✓ Two Holodeck instances running: Site A (10.1.x.x) and Site B (10.2.x.x), both state = Running → Get-HoloDeckInstance shows two instances with different IP ranges

✓ Cross-site IP reachability: ping 10.2.0.4 from Site A succeeds; ping 10.1.0.4 from Site B succeeds → Both pings reply with <2ms latency

✓ Cross-site DNS: nslookup vcenter-b.site-a.vcf.lab from Site A resolves to 10.2.0.6; vice versa → Both DNS lookups resolve correctly

✓ SDDC Manager-A and SDDC Manager-B both show management domain Active status → Inventory > Workload Domains shows Active with 4 hosts each

✓ vCenter-A and vCenter-B both show 4 healthy ESXi hosts, vSAN green, HA/DRS enabled → Hosts and Clusters view shows green health indicators

✓ NSX Manager-A and NSX Manager-B both show 4 host transport nodes in Success/Up state → System > Fabric > Nodes shows 4/4 transport nodes up per site

✓ vCenter Enhanced Linked Mode configured and connected (optional) → Administration > System Configuration shows Linked Mode Status: Connected (if deployed)

✓ RCAR design exercise completed: Requirements, Constraints, Assumptions, Risks, Quality Matrix, Failover Decision Tree, Failover Runbook → Design documentation comprehensive enough for VCDX oral defense

Cleanup / Restore

Snapshot: holodeck-06-complete

• Take snapshots of all Holodeck VMs from both Site A and Site B: Get-VM -Name 'Holo-*' | New-Snapshot -Name 'holodeck-06-complete' -Description 'Post dual-site deployment — both sites healthy, cross-site networking validated' -Memory:$false -Quiesce:$false

• Document dual-site topology: Create or update your lab notebook with Site A and Site B IP addressing, FQDN mappings, and cross-site routing configuration

• Archive RCAR design exercise: Save your design documentation (RCAR, Design Quality Matrix, Failover Runbook) to a central location for future reference and VCDX preparation

Design Reflection (VCDX)

Dual-site is the VCDX differentiator. A VCDX panelist examining a multi-site VCF design probes these dimensions: (1) Why dual-site vs single-site? (Answer: DR, business continuity, geographic diversity for compliance). (2) How do you decouple Site A from Site B operationally? (Answer: Separate SDDC Managers, separate vCenter clusters, ESXi hosts per-site, potential NSX federation for policy isolation). (3) What assumptions are baked into your cross-site latency budget? (Answer: <5ms RTT for stretched vSAN, <50ms RTT for asynchronous replication).

(4) How do you handle split-brain scenarios during failover? (Answer: DNS failover, explicit failover runbook, SDDC Manager authority per site). (5) What is your actual RTO and RPO, and how was it validated? (Answer: Lab simulation, failover runbook, documented assumptions). Be prepared to defend every architectural choice: 'Why stretched vSAN instead of separate clusters?' (Answer: Seamless VM migration for maintenance, unified capacity pool, but introduces L2 requirement and latency sensitivity).

'Why not active-active?' (Answer: Requires Byzantine consensus algorithms, complex DNS, split-brain risk; active-passive with fast failover is simpler and more operationally sound for this business profile).

Requirements

  • Ability to replicate application VMs from Site A to Site B with RPO <= 1 hour
  • Automatic or semi-automatic network failover via NSX (failover policies or manual SDDC Manager workload domain failover)
  • SDDC Manager can manage workload domain resources at both sites for provisioning and lifecycle
  • vCenter visibility across both sites (Enhanced Linked Mode or separate SDDC Manager UIs)
  • Cross-site management traffic fully encrypted and authenticated
  • Failover RTO <= 2 hours (includes detection, DNS update, VM power-on, application startup)
  • Dual-site architecture must be operationally sustainable (runbooks, monitoring, alerting in place)

Constraints

  • Single physical ESXi host in lab (vs separate data centers in production) — shared failure domain
  • Holodeck 2.1.x dual-site support does not include stretched vSAN (requires separate vSAN clusters per site or async replication of vSAN objects)
  • vMotion VLAN spanning both sites would require L2 adjacency (not available in pure BGP/Layer 3 design of this lab). Workaround: Live migration disabled; use vSphere Replication instead
  • NSX multi-site federation available but Distributed Firewall policies are not automatically synced (must be manually deployed per site or via NSX policy templates)
  • Licensing: vSphere Replication per-VM costs scale with replica count. NSX Federation requires multi-site add-on license
  • Cross-site replication bandwidth: 1 Gbps network limit assumed (lab has virtual link; production WAN may be congested)
  • SDDC Manager single-instance per site (no HA for SDDC Manager itself in this lab). Production would likely deploy redundant SDDC Managers per site

Assumptions

  • Cross-site network latency <5ms RTT (met in lab; real WAN would be 50-150ms, requiring async replication only)
  • Cross-site network availability >99.9% (SLA on WAN link or redundant paths)
  • vSphere Replication licenses available for all application VMs
  • Site B is pre-provisioned with compute capacity (4 ESXi hosts ready) — not a cold DR site requiring provisioning time
  • NSX Federation licenses available if multi-site NSX is required
  • DNS failover is manual (ops team updates DNS to point to Site B post-failover); no automated DNS update
  • vCenter Enhanced Linked Mode is desired for operational convenience; not required for failover success
  • Business tolerance for some manual failover steps (not fully automated) — acceptable due to infrequent failover events

Risks

  • Cross-site network link failure or high latency (>5ms RTT). — Impact: vSphere Replication lag increases beyond RPO tolerance. If stretched vSAN were used, split-brain risk. Site A applications remain up; Site B replication stalls. — Mitigation: Continuous monitoring of cross-site ping latency and replication lag. Alert if latency >5ms or replication lag >15 minutes (exceeds RPO). Failover decision: if link down >30 min, manual failover to Site B. If latency increased but link operational, continue replication.
  • vCenter Linked Mode breaks during failover (split-brain: both vCenters claim authority). — Impact: Operator confusion. Dual VM registration possible if apps powered on at both sites. Data corruption risk. — Mitigation: Failover runbook explicitly states: 'After failing over, Site B vCenter is sole authority. Site A vCenter must be isolated (network disconnect) until recovery.' Document this in vSphere alerting.
  • RPO not met due to replication lag or network congestion. — Impact: Data loss up to max lag. For critical applications, unacceptable. — Mitigation: Implement per-VM replication lag alerting. Prioritize critical VMs for replication (sync replication). Bulk workloads use async. Weekly DR drill to measure actual RPO achieved.
  • Site A complete power loss (not just network failure). — Impact: All Site A management domain components offline. SDDC Manager cannot manage. Failover to Site B mandatory. RTO extends if Site B vCenter takes 30+ minutes to discover all replicated VMs. — Mitigation: Power on Site B vCenter and SDDC Manager immediately post-failure. Run inventory scan to re-discover replicated VMs. Pre-create VM placement policies on Site B to speed power-on sequencing. Test in DR drill quarterly.
  • Disaster recovery drill reveals missing backup of SDDC Manager configuration or vCenter settings. — Impact: Cannot re-provision management domain on Site B if Site A is unrecoverable. RTO becomes days, not hours. — Mitigation: Weekly backup of SDDC Manager PostgreSQL database. Weekly backup of vCenter config (using native backup tools or vSphere APIs). Store backups offsite (cloud storage or secondary site). Test restore quarterly.
  • Stretched vSAN split-brain: network partition between Site A and Site B vSAN clusters. — Impact: Both partitions remain online, potentially writing conflicting data. Cluster corruption. — Mitigation: If using stretched vSAN (advanced extension), deploy VMware Site Recovery Manager (SRM) with vSAN synchronous replication and Byzantine agreement (requires witness VM). Preferred: DO NOT use stretched vSAN; use separate vSAN clusters per site with async replication instead.
  • Operator error during failover: powers on VMs on both Site A and Site B simultaneously (not checking Site A status first). — Impact: Duplicate VMs, split-brain applications, data corruption. — Mitigation: Automate failover as much as possible: SDDC Manager API-driven workload domain failover, NSX policy automation for network redirection. Runbook includes verification step: 'Confirm all Site A VMs are powered off before powering on Site B replicas.' Implement VM registration locking in vCenter to prevent dual registration.

Self-Assessment Discussion Prompts

  1. Why is dual-site architecture critical for VCDX candidates to understand, and how does it differ from a single-site HA deployment?
  2. In your dual-site design, what is the failure domain boundary? What shared components exist between Site A and Site B that could cause correlated failures?
  3. How does your design handle network partitioning (split-brain) between Site A and Site B? What prevents two vCenters from independently managing the same VM?
  4. Compare two DR strategies: (a) stretched vSAN with synchronous replication, (b) separate vSAN clusters with async vSphere Replication. What are the RPO/RTO/cost trade-offs?
  5. If your cross-site network latency is 50ms (typical WAN) instead of <2ms (lab), how would your design change? What components could no longer be stretched?
  6. How would you automate failover detection and DNS failover in a production dual-site VCF deployment? What monitoring and alerting would you implement?
  7. In vCenter Enhanced Linked Mode across sites, a network partition occurs (Site A and Site B lose connectivity). Both vCenters are still running independently. What is the risk, and how do you recover?
  8. Your business requires RPO of 15 minutes and RTO of 1 hour. Is your dual-site Holodeck lab design capable of meeting these targets? What changes would be needed?
  9. NSX Federation provides separate policy domains per site. How does this affect network failover behavior? If Site A NSX is down, can Site B NSX automatically take over Site A workloads?
  10. Document the exact steps and timing for a failover scenario: Site A datacenter power loss at 2 PM. When are applications fully operational on Site B? What manual interventions are required?

Extensions

Deploy stretched vSAN cluster across Site A and Site B

Configure a vSAN cluster that spans both sites using synchronous replication and a witness VM. This advanced configuration is the foundation for stretched cluster designs in VCDX architecture. Document the latency sensitivity, failure domain implications, and how vSAN rebuild operations differ in stretched vs separate cluster designs.

much harder

Implement NSX Federation and test multi-site security policies

Deploy NSX Federation between NSX Manager-A and NSX Manager-B. Create separate Tier-0 and Tier-1 gateways per site. Define security policies that differ between sites (e.g., Site A allows L7 inspection, Site B does not). Test cross-site VM communication with policies enforced. Document how NSX federation differs from stretched NSX (not supported in Holodeck).

much harder

Deploy VMware Site Recovery Manager (SRM) for automated failover

If SRM licenses are available, deploy SRM on Site A and Site B. Configure protection groups for application VMs. Create recovery plans with VM boot sequencing and network remapping. Test failover automation: execute a full failover plan from Site A to Site B, measure actual RTO, document the orchestration workflow.

much harder

Simulate a complete Site A failure and document recovery procedures

Disconnect or shut down all Site A VMs and management domain components. From Site B, execute a full failover: update DNS, power on application VMs, restore vCenter configuration from backup if needed. Measure actual RTO and RPO achieved. Document deviations from planned failover and lessons learned. This is the closest simulation to a real DR scenario.

harder

Deploy vSphere Replication across sites with per-VM RPO targets

Configure vSphere Replication between Site A and Site B. Set different RPO targets per VM: critical apps = 15 min, standard = 1 hour, dev/test = 4 hours. Monitor replication lag and verify RPO compliance. Test recovery of individual VMs. Document how RPO variation affects cross-site network bandwidth utilization and cost.

harder

Design and implement multi-site workload domain in SDDC Manager

Using SDDC Manager, design a workload domain that spans Site A and Site B ESXi clusters. If license permits, add a workload domain to Site B and configure it for failover readiness. Document how SDDC Manager manages lifecycle operations (patching, upgrades) across sites.

harder

Conduct a full DR drill with metrics and sign-off

Schedule a formal DR drill: intentionally fail over from Site A to Site B. Measure and document: (1) Detection time, (2) Failover execution time, (3) Application startup time, (4) Application availability verification time, (5) Total RTO. Compare actual RTO to design target. Have stakeholders sign off on the drill results. This is the most realistic VCDX preparation exercise.

same

⚠ Known Pitfalls (from Community KB)

Holodeck 9.0.2 dual-site IP config RESOLVED
Problem: Router interfaces set to default CIDR despite custom Site B configuration via New-HoloDeckNetworkConfig -Site b. User tried multiple config recreations without change.
Resolution: HoloRouter reboot cleared the interface configuration and resolved the issue. Key insight: Set-HoloRouter -dualsite must be followed by a router reboot or FRR service restart to apply new network configs.
Holodeck 9.0.2 Dual Site B vCenter not deploying LIKELY_RESOLVED
Problem: Site B vCenter deployment fails with vmware-vpostgres service crashing on start. Services stopped state unrecoverable across two deployment attempts.
Resolution: DNS not working on Site B was identified as a contributing factor. Ensure Site B has correct DNS configuration (pointing to Site B HoloRouter DNS IP, not Site A). Verify sufficient physical host memory remains after Site A allocation.
Issue with DNS resolution in Holodeck dual-site deployment OPEN
Problem: Deployment completes but ESXi hosts configured with gateway IP as DNS instead of dedicated DNS IP. Site A: 10.1.168.129 expected but 10.1.16.1 assigned. Cross-site DNS resolution fails.
Resolution: Network Manager DNS configuration not properly propagated to ESXi hosts. Workaround: manually configure DNS on ESXi hosts post-deployment, or ensure Holodeck network config includes correct DNS server assignments in DHCP scope.

References

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