Holodeck Environment Discovery Playbook

VCF 5.2.2Intermediateadminarchitectvcdx⏱ 120 min

Verified on VCF 5.2.2 with Holodeck Toolkit 9.0.2.19. The discovery methodology applies to any VCF version (5.2.x or 9.0.x) — only API responses and component versions change. For VCF 9.0.x, the domain suffix and IP scheme are identical; NSX version changes to 9.0.x.

Objectives

Systematically discover all components of an existing Holodeck VCF deployment using a 4-phase methodology
Use Holodeck Toolkit cmdlets to query network, DNS, IP pools, and BGP configuration
Authenticate to SDDC Manager API, vCenter REST API, and NSX Manager API
Map the complete vCenter object hierarchy (datacenters, folders, hosts, VMs, datastores)
Document deployment architecture for team handoff or VCDX design validation

Prerequisites

Access to an existing Holodeck VCF lab environment (shared or inherited) with all management domain components running (SDDC Manager, vCenter, NSX Manager)

Required skills:

PowerShell Core 7.x fundamentals
REST API authentication (Basic auth, Bearer tokens)
Basic understanding of VCF SDDC Manager, vCenter, and NSX
kubectl CLI basics for Kubernetes pod management

📸 Starting State: S3-9x — Management Domain Deployed (VCF 9.x)

Lab Environment

Existing Holodeck VCF lab (management + workload domains deployed). Read-only discovery — no modifications. HoloRouter (10.1.1.1) provides DNS, DHCP, BGP routing as K8s pods. Standard Holodeck NAT: 10.1.x.x (management) and 172.16.x.x (overlay). DNS resolution issues with FQDNs in PowerShell — use IP addresses for all API calls. Holodeck Toolkit cmdlets require Import-HoloDeckConfig before querying.

Credentials

System	Username	Password
HoloRouter SSH	`root`	VMware123!
SDDC Manager API	`administrator@vsphere.local`	Master password doubled: VMware123!VMware123!
vCenter REST API	`administrator@vsphere.local`	Master password doubled: VMware123!VMware123!
NSX Manager API	`admin`	Master password doubled: VMware123!VMware123!
ESXi hosts	`root`	Master password doubled: VMware123!VMware123!

Tasks

Task 1 Phase 1: HoloRouter Discovery

Step 1

SSH into HoloRouter — Connect to the HoloRouter VM via SSH. Default credentials: root / VMware123!

ssh root@10.1.1.1

HoloRouter login prompt or shell

Step 2

Query Kubernetes Pods — HoloRouter runs Kubernetes internally. List all pods across all namespaces to discover core services (SDDC Manager, vCenter, NSX Manager, dnsmasq, etc.).

kubectl get pods -A

Pods in namespaces: default, kube-system, holodeck-system, vmware-system-sddc, vmware-system-vcenter, vmware-system-nsx. You should see sddc-manager, vcenter, nsx-manager, dnsmasq-dns pods.

HoloRouter runs K8s — services are pods, NOT systemd daemons

Pods may take 2-5 minutes to reach 'Running' state after HoloRouter boot

Some pods (e.g., nsx-manager-pod) may show 'CrashLoopBackOff' temporarily during startup

Step 3

Examine HoloRouter Startup Configuration — Review the startup script to understand how HoloRouter provisions the lab environment, including which versions of VCF, NSX, and ESXi are deployed.

cat /holodeck-runtime/startup_script.sh | head -100

Startup script showing environment variables: HOLODECK_VCF_VERSION, HOLODECK_NSX_VERSION, HOLODECK_ESXI_VERSION, master password, domain configuration, etc.

Script may be 5000+ lines — use 'head', 'grep', or 'less' to navigate

Master password is visible in plaintext in this script (use caution in production)

Step 4

Inspect DNS Configuration — Check the HoloRouter's DNS resolver configuration to understand how components find each other by FQDN.

cat /etc/resolv.conf

nameserver 10.1.1.1 (HoloRouter itself), search domains for VCF and NSX FQDNs, etc.

DNS forwarders may point to external resolvers or to dnsmasq-dns pod

resolv.conf is auto-generated by dnsmasq; manual edits may not persist

Validation Gate

✓ Successfully SSH'd into HoloRouter (10.1.1.1)

✓ Identified at least 5 major pods (sddc-manager, vcenter, nsx-manager, dnsmasq-dns, etc.)

✓ Located and reviewed /holodeck-runtime/startup_script.sh

✓ Confirmed DNS resolver pointing to dnsmasq-dns service

✓ Documented HoloRouter IP and kubectl availability

Task 2 Phase 2: Holodeck Toolkit Discovery

Step 1

Import Holodeck Toolkit Module — Load the Holodeck Toolkit PowerShell module. This module is pre-installed on the HoloRouter or available via PowerShell Gallery.

Import-Module HoloDeckToolkit -Force; Get-Module HoloDeckToolkit

ModuleType: Script, Version: 9.0.2.x, ExportedCmdlets listing Get-HoloDeck* cmdlets

Module must be imported from a PowerShell session running on or connected to HoloRouter

If module not found, install via: Install-Module -Name HoloDeckToolkit -Repository PSGallery

Step 2

Query Holodeck Config — Get the Holodeck configuration metadata. This tells you the instance ID and config file location.

Get-HoloDeckConfig

ConfigID (SHA5 hash), InstanceID (another hash), BasePath (/holodeck-runtime), DeploymentVersion (5.2.2 or 9.0.x), etc.

ConfigID and InstanceID are required for subsequent cmdlet calls

Store these values in variables: $ConfigID = (Get-HoloDeckConfig).ConfigID

Step 3

Import Holodeck Configuration — CRITICAL STEP: Import the Holodeck config using the ConfigID from step 2. All subsequent queries depend on this import.

$ConfigID = (Get-HoloDeckConfig).ConfigID; Import-HoloDeckConfig -ConfigID $ConfigID

Configuration imported successfully. No errors.

MUST run this before any Get-HoloDeck* queries, or cmdlets will fail with 'Configuration not found'

If you skip this step, you'll see errors like 'The term Get-HoloDeckSubnet is not recognized'

Step 4

Retrieve Holodeck Instance Details — Get detailed information about the Holodeck instance, including deployment topology and component versions.

$InstanceID = (Get-HoloDeckConfig).InstanceID; Get-HoloDeckInstance -InstanceID $InstanceID

InstanceID, DeploymentVersion (5.2.2), HoloDeckVersion (9.0.2.19), ESXiVersion (8.0 Update 3), NSXVersion (4.2.3), Topology (Management, Workload, Edge clusters), ComponentCount, etc.

Get-HoloDeckInstance requires explicit -InstanceID parameter; -ListAvailable does not work in all versions

DeploymentVersion may differ from InstanceID — document both

Step 5

Query Management Network Topology — Discover the management network(s): gateway, VLAN, subnet, and reserved IP ranges.

Get-HoloDeckSubnet

Subnet: 10.1.1.0/24, Gateway: 10.1.1.254, VLAN: 1, Subnet: 10.1.2.0/24 (secondary), etc. Also shows reserved IP ranges for various components.

Holodeck may have multiple subnets for management, overlay, and application traffic

Reserved IPs include HoloRouter (10.1.1.1), SDDC Manager (10.1.1.5), vCenter (10.1.1.6), NSX Manager (10.1.1.7), etc.

Step 6

Query Application Network Configuration — Get application-level network configuration: segments, IP pools for workload VMs.

Get-HoloDeckAppNetwork

AppNetworks list: segment names (e.g., 'app-network-1'), VLAN/Overlay type, DHCP/Static pools, VNI (if overlay), etc.

Overlay networks are NSX-created; VLAN networks are vSphere virtual port groups

IP pools may overlap between different app networks — verify isolation

Step 7

Query BGP Configuration — Discover Border Gateway Protocol settings for NSX edge connectivity and multi-site scenarios.

Get-HoloDeckBGPConfig

BGP AS number, Router ID, Neighbor configuration, Route leaking policies, etc.

BGP is optional in Holodeck; if not deployed, cmdlet may return empty or default values

Edge cluster BGP configuration is distinct from management BGP

Step 8

Query Overlay Network Subnets — Discover NSX overlay network subnets and VNI assignments.

Get-HoloDeckOverlaySubnet

Overlay subnets: VLAN 2-4094 (typical), Subnet ranges (e.g., 172.16.0.0/12), VNI pool (e.g., 5000-7000), Encapsulation (VXLAN/Geneve), etc.

Overlay subnets are separate from management subnets

VNI pool conflicts can occur if multiple labs run on same infrastructure

Step 9

Query Service IP Pools — Get IP pool assignments for NSX services (NAT, DHCP, DNS relay, etc.).

Get-HoloDeckAppIpPools

IP pools for workload VMs, Load balancer VIPs, NSX service IPs, etc.

Get-HoloDeckServiceIPPools may error on some versions; use Get-HoloDeckAppIpPools instead

Service IP pools are separate from workload IP pools

Step 10

Examine Runtime Configuration Files — Inspect the on-disk configuration files to verify cmdlet output and discover additional metadata.

ls -la /holodeck-runtime/config/

config.json, network.yaml, specs.yaml, versions.txt, etc.

Files are owned by root; read-only for other users

config.json is large (~10MB); use 'jq' to parse

Step 11

Review Configuration JSON — Parse the configuration JSON to extract detailed networking, credentials, and topology.

cat /holodeck-runtime/config/config.json | jq '.network' | head -50

Network block with subnets, VLANs, IP pools, gateway addresses, DNS forwarders, etc.

File is large; use 'jq' filters to target specific keys

Credentials are visible in plaintext; treat this file as sensitive

Step 12

Examine Network YAML Specification — Review the network YAML file for high-level topology overview.

cat /holodeck-runtime/config/network.yaml

YAML structure: management_subnet, overlay_subnet, app_networks, bgp_config, etc.

YAML is human-readable but may be machine-generated; formatting may be unusual

Some fields may be commented out or marked as 'experimental'

Step 13

Review Specifications File — Check the specs.yaml file for a human-friendly summary of deployment configuration.

cat /holodeck-runtime/config/specs.yaml

Readable specification: VCF version, NSX version, ESXi hosts (count, vCPU, RAM), vCenter cluster config, etc.

specs.yaml is sometimes auto-generated and may lag actual deployment

Use this as a reference, but verify against API responses

Validation Gate

✓ Successfully imported HoloDeck Toolkit module

✓ Ran Get-HoloDeckConfig and captured ConfigID and InstanceID

✓ Imported config with Import-HoloDeckConfig

✓ Queried and documented all Holodeck cmdlets: Instance, Subnet, AppNetwork, BGP, Overlay, AppIpPools

✓ Reviewed runtime config files: config.json, network.yaml, specs.yaml

✓ Created a table with at least: Management subnets, Overlay subnets, App networks, BGP settings, Service IP pools

Task 3 Phase 3: VCF API Discovery

Step 1

Prepare Authentication Payload — Create a PowerShell hashtable with the correct SDDC Manager credentials. CRITICAL: The password must be DOUBLED (e.g., 'VMware123!VMware123!').

$sddc_ip = '10.1.1.5'; $username = 'administrator@vsphere.local'; $password = 'VMware123!VMware123!'; $body = @{ username = $username; password = $password } | ConvertTo-Json; Write-Host $body

JSON: { "username": "administrator@vsphere.local", "password": "VMware123!VMware123!" }

Password must be DOUBLED: single password ('VMware123!') will fail with 401 Unauthorized

Username MUST be 'administrator@vsphere.local', NOT 'admin@vcf.lab' or 'admin'

FQDN is 'sddcmanager-a' (NO HYPHEN), but use IP address (10.1.1.5) for API calls due to PowerShell DNS resolver issues

Step 2

Authenticate and Get Bearer Token — POST to /v1/tokens endpoint to obtain a bearer token for subsequent API calls.

$response = Invoke-RestMethod -Uri "https://$sddc_ip/v1/tokens" -Method Post -Body $body -ContentType 'application/json' -SkipCertificateCheck; $token = $response.accessToken; Write-Host "Token: $token"

Token response with 'accessToken' (long string), 'refreshToken', 'expiresIn' (3600 seconds), etc.

Tokens expire after 1 hour; refresh using refreshToken if needed

HTTPS endpoint requires -SkipCertificateCheck in PowerShell (self-signed cert)

Use Invoke-RestMethod, NOT curl (curl is aliased to Invoke-WebRequest in PowerShell, which behaves differently)

If you get 401 Unauthorized, double-check the doubled password

Step 3

Create Authorization Header — Build the Authorization header for all subsequent API calls using the bearer token.

$headers = @{ Authorization = "Bearer $token" }

Headers hashtable ready for use in API calls

Step 4

Query System Information — Get high-level VCF system information: version, build, deployment status, etc.

Invoke-RestMethod -Uri "https://$sddc_ip/v1/system" -Headers $headers -SkipCertificateCheck | ConvertTo-Json

VCF version (5.2.2), build number, deployment status ('ready' or 'standby'), system time, installed components, etc.

System may report 'standby' if HA failover is in progress

Build numbers change between patch releases

Step 5

Query SDDC Manager Instances — Discover all SDDC Manager nodes in the deployment (HA cluster).

Invoke-RestMethod -Uri "https://$sddc_ip/v1/sddc-managers" -Headers $headers -SkipCertificateCheck | ConvertTo-Json -Depth 10

Array of SDDC Manager nodes: id, hostname (sddcmanager-a, sddcmanager-b, etc.), primaryIp, version, status, etc.

Holodeck usually deploys 1 or 3 SDDC Manager nodes (single vs. HA)

primaryIp is the management network IP, not the floating VIP

Step 6

Query VCF Domains — Get all VCF domains (workload domains and management domain).

Invoke-RestMethod -Uri "https://$sddc_ip/v1/domains" -Headers $headers -SkipCertificateCheck | ConvertTo-Json -Depth 10

Array of domains: id, name ('MGMT', 'WLD-01', etc.), type ('management' or 'workload'), status, cluster count, etc.

Every VCF deployment has exactly one management domain (MGMT)

Workload domains are optional; Holodeck may have 0, 1, 2+ workload domains depending on deployment template

Step 7

Query Clusters Per Domain — Discover all clusters within each domain.

$domains = Invoke-RestMethod -Uri "https://$sddc_ip/v1/domains" -Headers $headers -SkipCertificateCheck; $domains | ForEach-Object { Invoke-RestMethod -Uri "https://$sddc_ip/v1/domains/$($_.id)/clusters" -Headers $headers -SkipCertificateCheck | ConvertTo-Json -Depth 10 }

Per domain: cluster id, name, type ('management', 'workload', 'edge'), status, host count, etc.

Management domain typically has 2 cluster types: management cluster (vSAN) and edge cluster (NSX edges)

Workload domains have management and workload clusters

Step 8

Query Hosts — Discover all ESXi hosts across all clusters.

Invoke-RestMethod -Uri "https://$sddc_ip/v1/hosts" -Headers $headers -SkipCertificateCheck | ConvertTo-Json -Depth 10 | head -200

Array of hosts: id, fqdn, ipAddress, clusterid, cpu count, memory (GB), vSAN membership, status, etc.

Hosts are grouped by cluster; use clusterid to map hosts to their cluster

vSAN status indicates whether host is part of vSAN cluster

Output may be large (100+ lines); use 'head' or pipe to file

Step 9

Query vCenter Instances — Discover all vCenter instances managed by SDDC Manager.

Invoke-RestMethod -Uri "https://$sddc_ip/v1/vcenters" -Headers $headers -SkipCertificateCheck | ConvertTo-Json -Depth 10

Array of vCenters: id, fqdn, primaryIp, version, domainid, status, etc.

Management domain has one vCenter (e.g., 'vcenter.mgmt.local', 10.1.1.6)

Each workload domain may have its own vCenter or share the management vCenter

Step 10

Query NSX Clusters — Discover NSX Manager clusters and their managers.

Invoke-RestMethod -Uri "https://$sddc_ip/v1/nsxt-clusters" -Headers $headers -SkipCertificateCheck | ConvertTo-Json -Depth 10

Array of NSX clusters: id, name, node count, primary manager, certificate status, version, etc.

NSX cluster != ESXi cluster; NSX cluster is a cluster of NSX Manager nodes

Holodeck typically deploys 3 NSX Manager nodes (HA)

Step 11

Query Network Pools — Discover IP pools available for new workload domains or clusters.

Invoke-RestMethod -Uri "https://$sddc_ip/v1/network-pools" -Headers $headers -SkipCertificateCheck | ConvertTo-Json -Depth 10

Array of network pools: id, name, status ('AVAILABLE', 'IN_USE', etc.), subnet, gateway, VLAN, pool size, etc.

Network pools are used during domain/cluster commission; in-use pools cannot be deleted

Pool subnet conflicts can block new domain deployments

Step 12

Query Credentials — Discover stored credentials used by VCF (vCenter, NSX, host passwords, etc.).

Invoke-RestMethod -Uri "https://$sddc_ip/v1/credentials" -Headers $headers -SkipCertificateCheck | ConvertTo-Json -Depth 10

Array of credentials: id, accountType ('USER', 'SERVICE'), username, creationTime, lastRotated, expiryDate, etc. (passwords are NOT returned for security reasons)

VCF API does not return plaintext passwords; use for audit/rotation status only

Service account passwords are automatically rotated; check lastRotated timestamp

Expired credentials are flagged with expiryDate in the past

Step 13

Query DNS Configuration — Discover DNS settings for the VCF system and NSX.

Invoke-RestMethod -Uri "https://$sddc_ip/v1/system/dns-configuration" -Headers $headers -SkipCertificateCheck | ConvertTo-Json -Depth 10

DNS servers (e.g., 8.8.8.8, 8.8.4.4), search domains (e.g., 'mgmt.local', 'sfo.local'), etc.

DNS is configured at the SDDC Manager level and inherited by NSX

Custom DNS servers may be needed if lab is isolated from internet

Step 14

Query NTP Configuration — Discover NTP (time sync) servers used by VCF.

Invoke-RestMethod -Uri "https://$sddc_ip/v1/system/ntp-configuration" -Headers $headers -SkipCertificateCheck | ConvertTo-Json -Depth 10

NTP servers (e.g., 'ntp.ubuntu.com', 'pool.ntp.org'), server mode, etc.

Holodeck uses pool.ntp.org by default, but lab may not have internet access

Time skew between nodes can cause authentication failures

Step 15

Query Task History — Review recent VCF tasks (domain creations, host commissions, etc.) to understand deployment timeline.

Invoke-RestMethod -Uri "https://$sddc_ip/v1/tasks?filter=status%3DSUCCESSFUL" -Headers $headers -SkipCertificateCheck | ConvertTo-Json -Depth 10 | head -100

Array of tasks: id, name, status ('SUCCESSFUL', 'FAILED', etc.), startTime, endTime, result, etc.

Task history can be large; use filters (status, creationTime) to narrow results

Failed tasks are critical for troubleshooting; note their error messages

Task timestamps are in UTC; convert to local time if needed

Step 16

Query Backup Configurations — Discover backup settings and schedules.

Invoke-RestMethod -Uri "https://$sddc_ip/v1/backup-configurations" -Headers $headers -SkipCertificateCheck | ConvertTo-Json -Depth 10

Backup config: frequency, backup window, encryption, storage backend, etc.

Backup is optional in Holodeck; may not be configured

Production backups are critical; Holodeck labs often have backups disabled

Step 17

Query Bundle Information — Discover installed software bundles and their versions.

Invoke-RestMethod -Uri "https://$sddc_ip/v1/bundles" -Headers $headers -SkipCertificateCheck | ConvertTo-Json -Depth 10

Bundles: VCF, vCenter, vSAN, NSX, ESXi bundle versions, etc.

Bundles are pre-loaded for deployment; mismatch between bundles can cause failures

Bundle versions must be compatible; VCF 5.2.x requires specific NSX, vCenter versions

Validation Gate

✓ Successfully authenticated to SDDC Manager API (10.1.1.5)

✓ Obtained bearer token with doubled password (VMware123!VMware123!)

✓ Queried and documented: System, SDDC Managers, Domains, Clusters, Hosts, vCenters, NSX Clusters

✓ Queried and documented: Network Pools, Credentials, DNS, NTP, Tasks, Backups, Bundles

✓ Created a VCF deployment architecture diagram: domains → clusters → hosts

✓ Noted any failed tasks in task history

✓ Confirmed FQDN of SDDC Manager as 'sddcmanager-a' (no hyphen)

Task 4 Phase 4: vCenter and NSX Deep Dive

Step 1

Prepare vCenter Authentication — Create authentication header for vCenter REST API. Use Basic auth with doubled password.

$vcenter_ip = '10.1.1.6'; $username = 'administrator@vsphere.local'; $password = 'VMware123!VMware123!'; $auth = [Convert]::ToBase64String([Text.Encoding]::ASCII.GetBytes("$username`:$password")); $headers_vc = @{ Authorization = "Basic $auth"; Accept = 'application/json' }

Headers hashtable with Basic auth and Accept headers

Step 2

Authenticate to vCenter and Get Session ID — POST to /api/session to create a vCenter session and obtain a session ID.

$session_response = Invoke-RestMethod -Uri "https://$vcenter_ip/api/session" -Method Post -Headers $headers_vc -SkipCertificateCheck; $session_id = $session_response; Write-Host "Session ID: $session_id"

Session ID (long string, e.g., '52e69b5c-2a5a-21a0-...')

vCenter returns session ID as a plain string, NOT a JSON object

Session ID expires after inactivity; create new session if API calls fail with 401

Use IP address (10.1.1.6), not FQDN, for the same PowerShell DNS resolver reasons as SDDC Manager

Step 3

Create vCenter API Header with Session — Build header for subsequent vCenter API calls using the session ID.

$headers_vc_session = @{ 'vmware-api-session-id' = $session_id }

Headers hashtable with vmware-api-session-id

Step 4

Query Datacenters — Discover all datacenters in the vCenter hierarchy.

Invoke-RestMethod -Uri "https://$vcenter_ip/api/vcenter/datacenter" -Headers $headers_vc_session -SkipCertificateCheck | ConvertTo-Json -Depth 10

Array of datacenters: datacenter (moref ID), name (e.g., 'Datacenter'), etc.

Holodeck typically has 1 datacenter per vCenter instance

moref (managed object reference) is used to identify objects in subsequent API calls

Step 5

Query Folders — Discover the folder hierarchy (resource organization).

Invoke-RestMethod -Uri "https://$vcenter_ip/api/vcenter/folder" -Headers $headers_vc_session -SkipCertificateCheck | ConvertTo-Json -Depth 10

Array of folders: folder (moref ID), name, type ('DATACENTER', 'VM', 'HOST', etc.), parent, etc.

Folders are organized in a tree; use parent field to traverse hierarchy

System folders are hidden by default; query will only return user-created folders

Step 6

Query Hosts — Discover all ESXi hosts visible in vCenter.

Invoke-RestMethod -Uri "https://$vcenter_ip/api/vcenter/host" -Headers $headers_vc_session -SkipCertificateCheck | ConvertTo-Json -Depth 10

Array of hosts: host (moref ID), name, connection_state ('CONNECTED', 'DISCONNECTED', etc.), power_state, etc.

Hosts may show as DISCONNECTED if vCenter lost connectivity; check host power status

Host names should match SDDC Manager /v1/hosts query

Step 7

Query Resource Pools — Discover resource pools for VM placement and resource limits.

Invoke-RestMethod -Uri "https://$vcenter_ip/api/vcenter/resource-pool" -Headers $headers_vc_session -SkipCertificateCheck | ConvertTo-Json -Depth 10

Array of resource pools: resource_pool (moref), name, cpu_allocation, memory_allocation, etc.

Holodeck may have resource pools for different workload tiers (production, dev, etc.)

Root resource pool is the cluster itself; user-created pools are children

Step 8

Query Datastores — Discover all datastores (storage) in vCenter.

Invoke-RestMethod -Uri "https://$vcenter_ip/api/vcenter/datastore" -Headers $headers_vc_session -SkipCertificateCheck | ConvertTo-Json -Depth 10

Array of datastores: datastore (moref), name, type ('VSAN', 'VMFS', 'NFS', 'VVOL', etc.), capacity, free_space, etc.

Holodeck typically uses vSAN for storage (VSAN type)

Free space should be >20% for healthy vSAN cluster; <10% is warning level

Step 9

Query Virtual Machines — Discover all VMs in the vCenter inventory.

Invoke-RestMethod -Uri "https://$vcenter_ip/api/vcenter/vm" -Headers $headers_vc_session -SkipCertificateCheck | ConvertTo-Json -Depth 10 | head -100

Array of VMs: vm (moref), name, power_state ('POWERED_ON', 'POWERED_OFF'), memory_mb, cpu_count, etc.

VM count may be large (100+); filter by power state or resource pool if needed

System VMs (NSX Manager, vCenter, etc.) appear as regular VMs in vCenter

Step 10

Query Networks — Discover vSphere networks (port groups, virtual switches).

Invoke-RestMethod -Uri "https://$vcenter_ip/api/vcenter/network" -Headers $headers_vc_session -SkipCertificateCheck | ConvertTo-Json -Depth 10

Array of networks: network (moref), name, type ('STANDARD_PORTGROUP', 'DISTRIBUTED_PORTGROUP', 'OPAQUE', etc.), etc.

Opaque networks are NSX-created overlay networks

Standard port groups are vSphere native; Distributed port groups are vSphere Distributed Switch (VDS)

Step 11

Query vSAN Health (if available) — Check vSAN cluster health. Note: This endpoint may not be available in vCenter 8.0.3.

Invoke-RestMethod -Uri "https://$vcenter_ip/api/vcenter/vsan/clusters" -Headers $headers_vc_session -SkipCertificateCheck -ErrorAction SilentlyContinue | ConvertTo-Json -Depth 10

vSAN cluster health: cluster ID, health status ('HEALTHY', 'WARNING', 'CRITICAL'), etc.

This endpoint returns NOT_FOUND (404) in vCenter 8.0.3; if so, skip and note in report

Use curl to vCenter host: `curl -s -k -u administrator@vsphere.local:VMware123!VMware123! https://10.1.1.6/rest/com/vmware/vsan/cluster/health -H 'vmware-api-session-id: ...'` as workaround

Step 12

Prepare NSX Authentication — Create Basic auth header for NSX Manager API. Use doubled password.

$nsx_ip = '10.1.1.7'; $username = 'admin'; $password = 'VMware123!VMware123!'; $auth_nsx = [Convert]::ToBase64String([Text.Encoding]::ASCII.GetBytes("$username`:$password")); $headers_nsx = @{ Authorization = "Basic $auth_nsx"; Accept = 'application/json' }

Headers hashtable with Basic auth for NSX

Step 13

Query NSX Transport Zones — Discover NSX transport zones (overlay and VLAN transport zones).

Invoke-RestMethod -Uri "https://$nsx_ip/api/v1/transport-zones" -Headers $headers_nsx -SkipCertificateCheck | ConvertTo-Json -Depth 10

Array of transport zones: id, display_name, transport_type ('OVERLAY', 'VLAN', etc.), host_switch_name, etc.

Overlay TZs are for NSX segments; VLAN TZs are for VLAN segments

host_switch_name is the name of the NSX distributed switch (e.g., 'nsxvswitch')

Step 14

Query NSX Transport Node Profiles — Discover transport node profiles (configuration templates for hosts).

Invoke-RestMethod -Uri "https://$nsx_ip/policy/api/v1/infra/sites/default/enforcement-points/default/transport-node-profiles" -Headers $headers_nsx -SkipCertificateCheck | ConvertTo-Json -Depth 10

Array of transport node profiles: id, display_name, host_switch_spec (uplink configuration), etc.

Profile names often reference the data plane (e.g., 'Edge-TN-Profile', 'Host-TN-Profile')

Uplink config specifies which vNICs are bound to NSX

Step 15

Query NSX Segments — Discover logical segments (NSX L2/L3 networks).

Invoke-RestMethod -Uri "https://$nsx_ip/policy/api/v1/infra/segments" -Headers $headers_nsx -SkipCertificateCheck | ConvertTo-Json -Depth 10 | head -100

Array of segments: id, display_name, transport_zone_path, subnet (CIDR), etc.

Segments can be overlay or VLAN; transport_zone_path reveals the type

Segments are the NSX equivalent of vSphere port groups

Step 16

Query DNS Zone Records — Extract all pre-provisioned DNS records from dnsmasq pod. This reveals the FQDN and IP mapping for all components.

kubectl exec -n kube-system -it dnsmasq-dns-pod -- cat /etc/hosts | head -50

DNS records: 10.1.1.1 holodocker, 10.1.1.5 sddcmanager-a, 10.1.1.6 vcenter, 10.1.1.7 nsx-manager, 10.1.2.x mgmt-cluster-hosts, etc. (~160 total records)

Pod name may vary (e.g., 'dnsmasq-dns', 'dnsmasq-dns-0'); use `kubectl get pods -A | grep dns` to find it

File is ~3-5KB; review in full to understand complete naming scheme

Some records are for internal NSX services; not all are workload-accessible

Step 17

Compile Final Inventory Documentation — Aggregate all discovery data into a comprehensive inventory document or spreadsheet.

# Create summary tables (pseudocode — adapt to your format):
# 1. Components table: FQDN, IP, type (SDDC Manager, vCenter, NSX), status, version
# 2. Hosts table: FQDN, IP, cluster, vSAN status, power state
# 3. Networks table: Name, type (management, overlay, app), subnet, gateway
# 4. Datastores table: Name, type, capacity, free space, usage %
# 5. Key credentials: username, type (administrator, service), last rotated, expiry
# 6. DNS zones: all ~160 records extracted from /etc/hosts

Comprehensive inventory document with all components, networks, and credentials mapped

Validation Gate

✓ Successfully authenticated to vCenter REST API (10.1.1.6) with doubled password

✓ Successfully authenticated to NSX Manager API (10.1.1.7) with doubled password

✓ Queried and documented: Datacenters, Folders, Hosts, Resource Pools, Datastores, VMs, Networks

✓ Queried and documented: NSX Transport Zones, Transport Node Profiles, Segments

✓ Extracted DNS zone records from dnsmasq pod (confirmed ~160 pre-provisioned records)

✓ Compiled comprehensive inventory document with all components, networks, credentials, and FQDNs

✓ Verified that all IPs and FQDNs from Phases 1-3 appear in vCenter and NSX queries

Final Validation

Comprehensive Holodeck VCF Environment Inventory Document

Components & Infrastructure

• All component FQDNs (sddcmanager-a, vcenter, nsx-manager, holodeck-holomaster, mgmt-esx-01, etc.) with corresponding IP addresses

• SDDC Manager nodes: hostname, primaryIp, version, status

• vCenter instances: FQDN, primaryIp, version, managed domains

• NSX Manager cluster: node count, manager IPs, version, status

VCF Domains & Clusters

• Domain inventory: Management domain (MGMT) and all workload domains (WLD-01, etc.) with cluster counts

• Cluster inventory per domain: cluster name, type (management/workload/edge), host count, cluster status

• All ESXi hosts: hostname, IP, cluster membership, CPU/memory specs, vSAN participation status

Network Topology

• Management networks: subnets, VLANs, gateways (e.g., 10.1.1.0/24, 10.1.2.0/24, etc.)

• Overlay networks: VLAN range, VNI pool, encapsulation type

• Application networks: segment names, CIDR blocks, DHCP/Static pools, isolation level

• BGP configuration: AS number, router ID, neighbors, route leaking policies

Storage & Compute

• Datastores: name, type (vSAN/VMFS/NFS), capacity, free space, usage percentage

• vSAN configuration: disk groups, capacity tier, license level, health status

• Resource pools per cluster: name, CPU allocation, memory allocation, shares

• vCenter inventory count: total VMs, powered-on count, templates, system VMs

Credentials & Security

• All credential types managed by VCF: service accounts (vCenter, NSX, SDDC Manager, ESXi), their last rotation date, and expiry status

• Master password status (note: Holodeck default is VMware123!VMware123! — doubled)

• Certificate status: SDDC Manager, vCenter, NSX Manager SSL certificates and expiry dates

• Permissions audit: administrator accounts, service account roles

System Configuration

• DNS servers and search domains configured in VCF

• NTP servers and time sync status

• Backup configurations: enabled/disabled, frequency, retention policy

• Syslog configuration: syslog servers, log levels

Deployment Timeline & History

• VCF deployment date (extracted from task history)

• Recent major tasks (domain creations, host commissions) with timestamps and status

• Any failed tasks with error messages

• Last system update/patch date

DNS Zone Map

• All ~160 DNS records from /etc/hosts in dnsmasq pod, organized by component type

• Naming convention analysis: IP scheme (10.1.x.x patterns), FQDN patterns (e.g., mgmt-esx-01.mgmt.local, nsx-manager.nsx.local, etc.)

✓ Document is comprehensive and machine-readable (markdown, spreadsheet, or JSON format acceptable)

✓ All component FQDNs and IPs are cross-referenced: SDDC Manager API ↔ vCenter API ↔ NSX API ↔ DNS records should all align

✓ All 4 discovery phases are represented in the document

✓ No contradictions in IP assignments or FQDN resolution

✓ Document is suitable for team handoff or VCDX design panel review

Cleanup / Restore

No cleanup needed — this is a read-only discovery exercise. All queries are informational; no VCF, vCenter, or NSX configurations were modified.

Design Reflection (VCDX)

A VCDX panelist might ask: 'You inherited this VCF environment — walk me through how you assessed its current state before proposing changes.' This lab builds exactly that skill — systematic discovery without assumptions. By the end, you've documented every component, network, and credential. You know the deployment version, topology, and health status. You can confidently brief a team on what you found and propose improvements based on observed state, not speculation.

Self-Assessment Discussion Prompts

How would you verify the health of a VCF environment you didn't deploy? What would you look for first?
What risks exist when inheriting a VCF environment where credentials have been rotated and you don't have the new passwords?
How does the discovery methodology differ between production VCF and nested Holodeck? What assumptions can you make about Holodeck that might not apply to production?
If you discovered that DNS records in /etc/hosts are inconsistent with vCenter's registered FQDNs, what would be your troubleshooting approach?
How would you use the Holodeck Toolkit cmdlets as a starting point to build a self-service discovery tool for your team?

References

Vcf Api DocsTier 1 — Official
Vcenter Rest ApiTier 1 — Official
Nsx Policy ApiTier 1 — Official
Holodeck ToolkitTier 1 — Official
Vcf Security HardeningTier 1 — Official

Mark complete