VCF 9.0 Workload Domains: Architecture and Provisioning

Workload domains are the fundamental building blocks of a VCF 9.0 deployment. They define how compute, storage, and networking resources are organized, isolated, and managed across your private cloud. Getting the workload domain architecture right early in the design process has long-term implications for scalability, security isolation, and operational complexity. This post covers the architecture, design considerations, and provisioning process for VCF 9.0 workload domains.

What Is a Workload Domain?

A workload domain (also called a VI workload domain) is a discrete unit of infrastructure within VCF that combines a vSphere cluster, a vSAN datastore, and an NSX networking instance into a managed, policy-driven environment. Each workload domain has its own dedicated vCenter Server and NSX Manager cluster, providing strong isolation from other domains. This isolation makes workload domains ideal for separating environments by business unit, security classification, regulatory requirement, or application tier. From an operational perspective, SDDC Manager treats each workload domain as an independent lifecycle unit that can be upgraded, expanded, or decommissioned independently.

Design Considerations: How Many Domains?

One of the first design decisions in a VCF deployment is how to carve up workload domains. More domains provide better isolation but increase operational overhead, since each domain adds a vCenter and NSX Manager pair to manage. Fewer domains simplify operations but reduce isolation. A pragmatic starting point for most enterprise deployments is two to three workload domains: one for production workloads, one for non-production (dev, test, staging), and optionally one for regulated workloads that require stricter isolation. As your VCF footprint grows, you can add domains without disrupting existing ones.

Host Requirements and Commissioning

Before provisioning a workload domain in SDDC Manager, hosts must be commissioned. Commissioning is the process of bringing a bare-metal server under SDDC Manager's management. The host must be running a supported version of ESXi, have network connectivity to the SDDC Manager management network, and pass the pre-commissioning health checks. In VCF 9.0, SDDC Manager can automate ESXi deployment to bare-metal servers using the Cloud Builder tool during initial bring-up, or you can add hosts to the free pool manually for subsequent workload domain expansions. A minimum of four hosts is required to create a new workload domain when using vSAN ESA with RAID-5 protection.

Network Design for Workload Domains

Each workload domain requires a dedicated set of VLANs and IP address ranges for vSphere management, vMotion, vSAN, NSX overlay (TEP), and optionally NSX edge uplinks. Careful IP planning before provisioning is critical — these ranges cannot easily be changed after deployment. In VCF 9.0, NSX is configured per workload domain, meaning each domain gets its own NSX Manager cluster and overlay transport zone. If you need inter-domain connectivity, it is routed through your physical network or through shared T0 gateways depending on your design. Document your network design in a configuration workbook before initiating SDDC Manager provisioning.

Provisioning a Workload Domain in SDDC Manager

Once hosts are commissioned and network configuration is prepared, provisioning a workload domain from the SDDC Manager UI is a guided workflow. You provide the domain name, select the hosts from the free pool, specify the vSAN configuration (ESA or OSA, storage policy, disk groups or device selection), configure the NSX settings including transport zones and TEP IP pools, and define the vCenter deployment size. SDDC Manager validates the inputs against the VCF compatibility matrix before starting deployment. The provisioning workflow typically takes 45 to 90 minutes and is fully automated once initiated. You can monitor progress in the SDDC Manager tasks view.

Expanding and Decommissioning Domains

Adding hosts to an existing workload domain is straightforward: commission the new hosts in SDDC Manager, then use the expand cluster workflow to add them to the target cluster. vSAN automatically rebalances data across the expanded cluster. Removing a workload domain requires migrating all workloads off first, then initiating the decommission workflow in SDDC Manager, which reconfigures the hosts back to the free pool. In VCF 9.0, the decommission workflow has been improved to handle NSX cleanup more reliably than previous versions, reducing the manual cleanup steps that were sometimes required in VCF 4.x.

Workload domains are the architectural foundation of VCF 9.0, and getting the design right upfront makes everything downstream simpler. Take the time to define your isolation requirements, plan your IP addressing, and validate your hardware against the HCL before provisioning begins. The investment in design time pays back immediately in smoother deployments and fewer post-deployment surprises. This post completes the VCF 9.0 series — check out the companion posts on SDDC Manager, vSAN ESA, and the overall VCF 9.0 What's New overview for the full picture.