Series · Part 8 of 10VCF Fundamentals to Advanced
  1. What is VMware Cloud Foundation (VCF)?
  2. Why VCF? Business Value & Use Cases
  3. VCF Licensing Explained
  4. VCF Architecture Deep Dive
  5. VCF Hardware Requirements & Bill of Materials
  6. VCF Networking with NSX — Deep Dive
  7. VCF Storage: vSAN OSA vs ESA
  8. VCF Workload Domains ExplainedYou are here
  9. VCF Day 2 Operations
  10. Installing VCF 9.1 Step-by-Step

Understanding VCF Workload Domains

The workload domain is VCF’s fundamental unit of infrastructure isolation. While the management domain houses all platform management services, workload domains (formally called VI Workload Domains) are where actual business workloads run. Each workload domain is a fully isolated private cloud unit with its own vCenter Server, NSX deployment, and vSAN datastore.

Understanding workload domain design is critical for architects designing multi-tenant environments, compliance-isolated workloads, and elastic scale-out deployments.

Workload Domain Anatomy

Each VI Workload Domain consists of the following components, all deployed and managed by SDDC Manager:

  • vCenter Server — One dedicated vCenter Server per domain. SDDC Manager deploys it automatically during domain creation. vCenter manages only the ESXi hosts within its own domain.
  • ESXi Cluster(s) — One or more vSphere clusters within the domain. The first cluster is the Principal Cluster. Additional clusters can be added later.
  • NSX Deployment — One NSX Manager cluster (3 VMs) per domain. NSX provides overlay networking for all VMs in the domain.
  • vSAN Datastore(s) — One vSAN datastore per cluster. The cluster’s ESXi hosts contribute their local disks to the vSAN pool.
  • Network Pool — An SDDC Manager–managed IP pool that allocates VMkernel IPs (vSAN, vMotion, NSX TEP) when hosts are added to the domain.

Workload Domain Isolation Model

Isolation in workload domains operates at multiple levels:

  • Management plane isolation — Each domain has its own vCenter. An admin with access to Domain A’s vCenter has no visibility into Domain B’s vCenter.
  • Network isolation — Each domain has its own NSX deployment. Overlay segments in Domain A are entirely independent of Domain B’s segments. Cross-domain communication requires explicit T0 uplinks through the physical network or dedicated interconnect segments.
  • Storage isolation — Each cluster’s vSAN datastore is independent. Datastores are not shared between domains.
  • Lifecycle isolation — SDDC Manager can patch or upgrade each domain independently. You can update the management domain without touching workload domains.

Typical Workload Domain Designs

Pattern 1: Environment Isolation (Dev/Test/Prod)

The most common pattern. Three workload domains — Dev, Test, Production — each with their own vCenter and NSX. Security and compliance teams love this because Production VMs are physically isolated from Dev/Test at the management plane level. Dev and Test can share hardware types; Production gets the high-performance NVMe/ESA nodes.

Pattern 2: Business Unit Isolation (Multi-Tenant)

Each business unit or customer gets their own workload domain. The IT team manages SDDC Manager centrally, but each BU admin only has access to their own vCenter. This works well for service providers offering private cloud to multiple internal customers or external tenants.

Pattern 3: Workload-Specific Domains

Specialized domains for specific workload types:

  • VDI Domain: Dedicated domain with ESA NVMe hosts for VMware Horizon. Optimized storage policies for boot storm handling.
  • Kubernetes Domain: Domain with Tanzu enabled, providing TKG Kubernetes clusters managed by SDDC Manager.
  • Database Domain: Domain with highest-performance ESA hosts running SQL Server, Oracle, or other latency-sensitive databases.

Creating a Workload Domain — Process

Workload domain creation is driven entirely through SDDC Manager UI or API. The process:

  1. Add hosts to the free pool: Commission bare-metal hosts into SDDC Manager’s free host pool. SDDC Manager installs ESXi, validates hardware, and assigns VMkernel IPs from the network pool.
  2. Create a network pool (if a new one is needed): Define IP ranges for vSAN, vMotion, and NSX TEP VMkernel adapters for this domain.
  3. Initiate domain creation in SDDC Manager: Provide domain name, select hosts from the free pool, specify vSAN configuration (OSA or ESA), NSX configuration (T0 uplinks, Edge cluster sizing), and vCenter sizing.
  4. SDDC Manager orchestrates: Deploys vCenter Server VM, creates vSAN cluster, deploys 3 NSX Manager VMs, deploys NSX Edge VMs, configures BGP peering, validates BOM compliance.
  5. Domain is ready: Typically 60–90 minutes. You receive the vCenter FQDN and NSX Manager VIP.

Expanding a Workload Domain

Adding hosts to an existing workload domain is straightforward via SDDC Manager:

  1. Rack new hardware and commission it in SDDC Manager (installs ESXi, validates HW)
  2. In the domain’s cluster settings, add the commissioned hosts
  3. SDDC Manager configures the host for vSAN, assigns NSX TEP IPs, joins it to the cluster
  4. vSAN automatically rebalances data across the expanded cluster

Stretched Clusters in VCF

VCF supports vSAN Stretched Clusters for site-level HA. A stretched cluster spans two physical sites, with an odd-site witness host providing quorum. This enables zero-RPO, near-zero-RTO failover between sites for VMware workloads — no application-level clustering required.

  • Minimum configuration: 3 hosts at Site A + 3 hosts at Site B + 1 witness host (can be a VM at a third site)
  • Latency requirement: <5 ms RTT between sites for vSAN traffic (10 ms maximum supported)
  • NSX consideration: Stretched clusters require careful NSX T0 design — each site should have local Edge nodes with active T0 uplinks to avoid asymmetric routing
  • VCF 9.x: Stretched cluster configuration is managed through SDDC Manager, including automated witness appliance deployment

Deleting a Workload Domain

SDDC Manager can fully decommission a workload domain. This is a destructive operation that:

  • Removes all VMs from the domain (you must migrate or delete VMs first)
  • Unregisters and deletes the vCenter Server appliance
  • Unregisters and deletes the NSX Manager cluster
  • Removes ESXi hosts from the cluster and returns them to the free pool
  • The freed hosts can then be recommissioned into a different workload domain

Workload Domain Limits (VCF 9.1)

Resource Maximum
Workload domains per SDDC Manager 15
Clusters per workload domain 8
Hosts per cluster 64
Total hosts per SDDC Manager 500

Broadcom Documentation

Up Next → Part 9: VCF Day 2 Operations — SDDC Manager internals, lifecycle management, patching strategy, certificate rotation, password management, and backup/recovery for the full VCF stack.