TL;DR · Key Takeaways
- Workload domain creation now lives in VCF Operations, not SDDC Manager. Commission hosts first.
- Storage type is fixed at commission time. An ESA-commissioned host cannot later join an NFS or OSA domain.
- On the NSX step you create a new NSX Manager (dedicated) or join an existing one (shared). Pick the 3-node HA size for production.
- Enable vSphere Supervisor is on by default. Leave it on only if you mean it, because it commits you to an NSX Edge cluster.
- A vLCM cluster image is mandatory. Hosts are remediated to it during cluster creation.
The mechanics of creating a workload domain in VCF 9 are straightforward. The two things that catch teams out are not steps, they are defaults: a storage choice that is welded on at commission time, and a Supervisor toggle that is checked by default and quietly commits you to an NSX Edge cluster. Get those decisions right and the rest is a wizard.
Step 1: Commission the hosts
Hosts must be commissioned into the global free pool before use. In VCF 9 this is done from the management domain vCenter under Global Inventory Lists, Hosts, Unassigned Hosts, Commission Hosts, or via the SDDC Manager UI. Add them individually or with a JSON template. The platform briefly enables SSH to grab the host key, then disables it. Each host needs at least one pNIC at 10 Gbps minimum, its management VMkernel on the management network, and a hostname equal to its FQDN with forward and reverse DNS.
The critical decision here is storage type, because it is fixed at commission. The JSON enums make the options explicit: VSAN, VSAN_ESA, VSAN_MAX, NFS, VMFS_FC, and the deprecated VVOL. A vSAN ESA host can only join an ESA cluster, never OSA or NFS, so map hosts to domains before you commission, not after.
Step 2: Create the workload domain in VCF Operations
The flow lives in VCF Operations now. Go to Inventory, Detailed View, expand VCF Instances, select the instance, then Add Workload Domain, Create New. Review the prerequisites, Select All, Proceed. Work through the wizard:
- Name the domain and choose storage: tick Enable vSAN ESA for ESA, or select NFS, VMFS on FC. vSAN Storage clusters (formerly vSAN Max) require ESA.
- Choose the VDS profile: Default single VDS (recommended), or split storage and NSX traffic across 2 or 3 switches.
- On the NSX step, create a new NSX Manager instance dedicated to this domain, or join an existing one to share. New instances deploy as Standard single-node or High-Availability 3-node, with Medium, Large, or XL appliances. The NSX model is explained in Part 10.
- Choose connectivity: Centralized (required for Supervisor, configure the Edge cluster afterward) or Distributed (enter the VLAN, gateway CIDR, and transit-gateway IP blocks, and the domain is VPC-ready immediately).
- Confirm the vLCM cluster image. It is mandatory, and hosts are remediated to it during cluster creation.
Monitor progress under Fleet Management, Tasks. Note that creating a workload domain with an LACP-enabled VDS still requires the SDDC Manager API, one of the few operations that has not fully moved to VCF Operations. The vSAN architecture decision behind the storage choice is in Part 6.
Network pools and the VDS profile
Two prerequisites quietly decide whether the wizard proceeds. First, a network pool with free IPs must exist and must support the host storage type before you commission, and the domain needs either a static IP pool or DHCP advertising on the NSX host-overlay TEP VLAN. Second, you choose a VDS profile that you cannot easily change later. The Default profile is a single VDS carrying all traffic and is the right answer for most designs. The alternatives split traffic across switches: Storage Traffic Separation and NSX Traffic Separation each use two VDS, Storage plus NSX Separation uses three, and Custom lets you map it yourself. Each traffic type, management, vMotion, vSAN, and NSX, can be configured only once per cluster, so plan the mapping before you start rather than backing out of it.
Centralized or distributed connectivity
The NSX step asks you to pick a connectivity model, and the two paths lead to very different day-one footprints. Centralized routes through NSX Edge nodes and is required if you intend to run the Supervisor, but it leaves you to configure the Edge cluster afterward before the domain becomes VPC-ready. Distributed routes VPC traffic in the hypervisor: you enter the VLAN ID, the gateway CIDR, an external IP block, and a private transit-gateway IP block, and the domain is VPC-ready as soon as it is created, with no Edge VMs in the path. For a VM-only domain that does not need centralized north-south services, distributed is the lighter and faster choice. The constructs behind these options are explained in the NSX explainer.
| Dimension | Centralized | Distributed |
|---|---|---|
| Data path | Through NSX Edge nodes | Routed in the hypervisor (no Edge VMs) |
| vSphere Supervisor | Required path for Supervisor | Not supported (VM and VPC only) |
| VPC-ready | After you build the Edge cluster | Immediately at domain creation |
| Inputs needed | Edge cluster (day-N) | VLAN, gateway CIDR, external and transit IP blocks |
| Day-one footprint | Heavier: Edge appliances, TEP and uplink VLANs | Lighter |
| Best for | Centralized north-south or Supervisor domains | VM-only domains |
How many hosts you actually need
The official workload-domain page does not print a single fixed host minimum, because for a new vSAN domain the figure is derived from the failures-to-tolerate you pick, not stated as a constant. FTT=1 on vSAN OSA means 3 hosts; ESA and stretched configurations change the math. The import and converge paths are more forgiving, allowing as few as 2 hosts on NFS or VMFS-on-FC, or 3 vSAN-ready nodes. The honest planning answer is to derive the minimum from your FTT choice and confirm it against configmax.broadcom.com for your release, rather than carrying a number from a blog into a customer design. If the management-domain hosts carry an express patch, the workload-domain hosts must carry the same one, or the cluster image remediation will not line up.
The verdict on the Supervisor toggle
Enable vSphere Supervisor is activated by default in the workload domain wizard. Leaving it on creates a Supervisor, a control-plane VM, a vSphere zone, and NSX VPC networking, and then it commits you to deploying an NSX Edge cluster with an active-standby Tier-0 gateway before the domain is actually usable for VPC or Supervisor workloads. That is extra Edge appliances, extra TEP and uplink VLANs, and a half-finished Supervisor stranded in your inventory if you do not follow through. My verdict: for a traditional VI workload domain that will only run VMs, deactivate Enable vSphere Supervisor at creation. You can always enable it later from the vSphere Client, and you avoid stranding a partial Supervisor and the Edge footprint it demands. The docs describe the toggle neutrally and will not tell you to turn it off unless you mean it.
What’s Next
Plan your host-to-domain storage mapping before you commission, and decide the Supervisor question deliberately rather than accepting the default. With workload domains in place, the next layer is the networking that runs inside them, covered in the NSX explainer. Are your new domains VM-only, or are you committing to Supervisor and the Edge cluster up front?
References
- Broadcom TechDocs: Working with Workload Domains (VCF 9)
- Broadcom TechDocs: Commission Hosts
- VCF Blog: Deployment Pathways for VMware Cloud Foundation 9
About The Author
