Academy/VCF 9.0 Support (2V0-15.25)/Creating Workload Domains & Network Pools
This lab targets VCF 9.0

Creating Workload Domains & Network Pools

VCF 9.0Intermediatesupportadmin⏱ 60 min

VCFFTS9 course content — VCF 9.0 focused

Objectives

  • Explain workload domain components and dedicated resource allocation
  • Compare consolidated (single rack) vs standard (multi-rack, recommended) architecture
  • Select appropriate storage per cluster within a workload domain
  • Configure network pools with VLAN, MTU, subnet, gateway, and IP ranges
  • Commission ESX hosts (storage type locks after commission)
  • Walk through the 5-step workload domain creation workflow
  • Choose between Distributed and Centralized network connectivity

Prerequisites

Active Holodeck VCF 9.0 lab or access to VCF documentation

Required skills:

  • Basic VMware terminology

Tasks

Task 1 Workload Domain Architecture & Storage

Workload domain creation is a Day-1 operation that defines the blast radius and isolation boundaries for workloads. Network pool configuration determines which VLANs and IP ranges are available for vMotion, vSAN, and host TEP traffic within the domain.

Understand workload domain concepts, architecture models, and storage options

Step 1
Workload Domain Components

A workload domain runs customer workloads (VMs or containers). Components: ESX hosts dedicated to WLD cluster, vCenter per WLD (deployed in management domain), NSX Manager (deployed in management domain), NSX Edge nodes (deployed in WLD for north-south connectivity). Principal storage per cluster: vSAN, NFS v3/v4.1, VMFS on FC, vVols.

Step 2
Architecture Models
Consolidated: management and user workloads share management domain, single rack, simpler networking, separated by resource pools. Standard (RECOMMENDED): dedicated management domain, separate workload domains for customer workloads, multi-rack, more complex networking. Migration path: start consolidated → add hosts → create WLD → move VMs → migrate to standard architecture.
Step 3
Storage Options per Cluster

Storage selected PER CLUSTER in a workload domain (one cluster can use vSAN, another NFS). vSAN: preferred — fully integrated, no NFS/FC config needed, VMs use built-in storage policies. NFS: datastore must be accessible from VCF network with R/W permissions, wizard prompts for datastore name/NFS IP/path. VMFS on FC: LUN must be pre-accessible, datastore pre-created. Supplemental storage can be added post-creation.

Validation Gate

Check: What network pools must be configured before creating a workload domain?

Expected: vMotion pool (VLAN + IP range), vSAN pool (VLAN + IP range), Host TEP pool (VLAN + IP range). Each pool defines the VLAN ID and IP range for that traffic type within the new workload domain.

Common Errors

Creating a workload domain with insufficient hosts for vSAN policy
Fix: vSAN requires minimum 4 hosts for RAID-5, 6 hosts for RAID-6. If you create a workload domain with 3 hosts, only RAID-1 (FTT=1 mirroring) is available. Plan host count based on the desired vSAN storage policy.
Overlapping IP ranges in network pools across domains
Fix: Each workload domain's network pool defines IP ranges for vMotion, vSAN, and host TEP. These ranges must not overlap with other domains or the management domain. SDDC Manager validates for overlaps but only within its own database — conflicts with IPs outside VCF management are not detected.
Not assigning separate VLANs for workload domain traffic
Fix: Each workload domain should have its own VLANs for vMotion, vSAN, and TEP traffic. Sharing VLANs with the management domain or other workload domains reduces isolation and can cause broadcast domain issues at scale.
Attempting to move hosts between workload domains without decommissioning
Fix: Hosts cannot be migrated between workload domains directly. You must decommission the host from the source domain (removing it from the vSAN cluster), then commission it into the target domain. This requires vSAN data evacuation — plan for sufficient capacity in the source cluster during the operation.

Task 2 Network Pools & Workload Domain Creation

Understanding when to create separate workload domains vs using clusters within a single domain is a fundamental architecture decision. Separate domains provide stronger isolation but higher resource overhead.

Configure network pools, commission hosts, and create workload domains

Step 1
Network Pools

Network pool = range of IP addresses for specific services. Required: vMotion subnet. Optional: vSAN, NFS, iSCSI subnets. Cannot add network type after pool creation. Config: VLAN ID, MTU, network/subnet, gateway, IP inclusion range for each type. IPs auto-assigned to VMkernel ports on hosts when commissioned. VLANs must be configured on physical switches BEFORE use. Network pool subnet types: vMotion (REQUIRED in every pool), vSAN (optional), NFS (optional), iSCSI (optional). You can only commission hosts with a particular storage type if the corresponding subnet is configured in the network pool.

Step 2
Host Commissioning

Commissioning = adding host to VCF inventory. Prerequisites: preimage with correct ESX version, DNS-resolvable hostname, NTP and Syslog enabled, network pool must exist first. CRITICAL: storage type LOCKED after commission — cannot change. Can commission individually or in bulk. When added to WLD: mgmt network migrates from VSS to VDS, VDS port groups created for each network pool service.

[HOLODECK NOTE] In Holodeck, host commissioning adds nested ESXi VMs to the VCF inventory. The storage type lock at commissioning time applies the same way — once a host is commissioned for vSAN, it cannot be re-commissioned for NFS without decommissioning first. However, Holodeck hosts use virtual disks for all storage types, so the physical disk/controller compatibility checks that matter in production are bypassed.

Step 3
Workload Domain Creation Workflow
Five steps: (1) Configure network pools; (2) Commission ESX hosts; (3) Create workload domain — specify vCenter details, storage type, NSX config; (4) Select network connectivity type: Distributed (streamlined, limited NSX services, configured in wizard) or Centralized (DHCP, NAT, L3, monitoring — configured post-creation from vCenter); (5) Create VPC with public/private subnets. Access: vSphere Client → Global Inventory Lists → Hosts or SDDC Manager UI → Inventory → Hosts. During workload domain creation, select network connectivity type: (a) Distributed Network Connectivity — streamlined, limited NSX services, configured during wizard; (b) Centralized Network Connectivity — full NSX services (DHCP, advanced NAT, L3, monitoring), must be configured from vCenter AFTER workload domain creation, requires NSX Edge deployment. Also important for exam: network pool must include the storage type you plan to use — you CANNOT add a network type after pool creation.
Step 4
Holodeck Parallel

Holodeck management domain = equivalent to VCF management domain. Adding a workload domain in production mirrors what Holodeck does for the management domain. Network pool concepts map directly to Holodeck's HoloRouter VLAN/DHCP configuration. Understanding one reinforces the other.

Validation Gate

Check: When should you create separate workload domains vs additional clusters within an existing domain?

Expected: Separate domains: when you need distinct RBAC boundaries (different admin teams), different compliance regimes (HIPAA vs general), or blast radius isolation. Additional clusters within a domain: when workloads share the same admin team and compliance requirements but need resource isolation or different hardware profiles.

Common Errors

Creating too many small workload domains (over-isolation)
Fix: Each workload domain requires minimum 4 hosts (vSAN) + its own vCenter + NSX segments. Creating 5 small domains with 4 hosts each uses 20 hosts with 5 vCenter instances. Consolidating into 2 domains with 10 hosts each uses the same compute with only 2 vCenter instances — lower management overhead. Use separate domains only when isolation requirements (compliance, tenancy, blast radius) justify the cost.
Not planning domain naming conventions upfront
Fix: Workload domain names are permanent — they cannot be renamed after creation. Use a consistent naming convention (e.g., wld-prod-01, wld-dev-01) that reflects the domain's purpose and can scale as you add domains.

Design Reflection (VCDX)

Domain topology is one of the most debated VCDX design decisions. Panelists will challenge whether your domain count is justified by requirements or is over-engineering. Be prepared to defend your domain topology with specific requirement IDs and cost analysis.

Requirements

  • Plan workload domain topology based on isolation requirements
  • Configure network pools for each domain's traffic types
  • Understand host lifecycle within and between domains

Constraints

  • Minimum 4 hosts per workload domain (vSAN)
  • Domain names are permanent — cannot be renamed
  • Hosts cannot be moved between domains without decommission/recommission

Assumptions

  • Physical network infrastructure supports the required VLANs
  • IP address ranges are pre-planned and non-overlapping

Risks

  • Over-isolation creating unnecessary management overhead and resource waste
  • IP range exhaustion in network pools as domains scale

⚠ Known Pitfalls (from Community KB)

Creating workload domains without a naming convention — retroactive renaming is not possible and inconsistent names cause operational confusion at scale.
Assuming hosts can be freely moved between domains — the decommission/recommission process involves vSAN data evacuation and can take hours.

References

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