5.3 VI Workload Domain Deployment, Commissioning Hosts, & Storage Attachment

5.3 VI Workload Domain Deployment, Commissioning Hosts, & Storage Attachment

Executive Overview: While the Management Domain hosts the control-plane engines that govern the private cloud, business value is unlocked through Virtual Infrastructure (VI) Workload Domains. Managed centrally through SDDC Manager, VI Workload Domains provide dedicated, isolated compute, storage, and networking environments for tenant applications. Expanding capacity requires an orderly lifecycle: defining Network Pools, commissioning bare-metal ESXi hosts into unassigned inventory, executing the Workload Domain deployment wizard, configuring principal storage architectures, and dynamically scaling clusters through automated host addition and evacuation.

---

Virtual Infrastructure (VI) Workload Domain Architecture

A VI Workload Domain is a logical administrative boundary encapsulating one or more vSphere clusters, software-defined storage, and virtual networking.

• Administrative & Fault Isolation: Each VI Workload Domain is governed by its own dedicated vCenter Server Appliance (VCSA) deployed automatically by SDDC Manager into the Management Domain's management cluster. This ensures that administrative permissions, vCenter upgrade schedules, and potential control-plane outages in one workload domain never affect another.
• Scalability Boundaries: A single VI Workload Domain can contain multiple vSphere clusters, scaling up to maximum vCenter limits (up to 96 ESXi hosts per cluster and hundreds of hosts per domain), with a single SDDC Manager supporting up to 25 workload domains across the enterprise fabric.

┌─────────────────────────────────────────────────────────────────────────┐
│               VI WORKLOAD DOMAIN CREATION LIFECYCLE                     │
├─────────────────────────────────────────────────────────────────────────┤
│  1. Configure Network Pool in SDDC Manager (vMotion, vSAN, Geneve TEP)  │
│                                  │                                      │
│                                  ▼                                      │
│  2. Commission ESXi Hosts (Assign FQDN, Credentials, Network Pool, Type)│
│                                  │                                      │
│                                  ▼                                      │
│  3. Launch VI Workload Domain Wizard in SDDC Manager                   │
│     - Name & vCenter Sizing (Tiny, Small, Medium, Large)                │
│     - NSX Topology: Dedicated NSX Cluster vs. Shared NSX Cluster        │
│     - Principal Storage Selection (vSAN ESA, OSA, NFS, FC, vVols)       │
│     - Select Commissioned Hosts & Execute Automated Build               │
│                                  │                                      │
│                                  ▼                                      │
│  4. Day-2 Lifecycle: Attach Supplemental Storage & Scale Clusters       │
└─────────────────────────────────────────────────────────────────────────┘

---

Network Pools: Pre-Allocating Hypervisor IP Fabrics

Before any new physical ESXi host can be commissioned into SDDC Manager, administrators must define one or more Network Pools.

• The Role of Network Pools: In a dynamic cloud environment, manual IP address entry on individual hypervisor adapters invites human error and configuration drift. Network Pools provide pre-defined pools of static IP addresses that SDDC Manager automatically assigns to hypervisor VMkernel interfaces during host commissioning and cluster creation.
• Traffic Types Managed by Network Pools:
  • vMotion: Static IP ranges, subnet masks, default gateways, and VLAN IDs dedicated to live migration.
  • vSAN: Static IP ranges, subnet masks, default gateways, and VLAN IDs dedicated to vSAN storage replication (required if vSAN is selected as principal storage).
  • Host Geneve Overlay TEP: Static IP ranges used to configure VMkernel Tunnel Endpoints (vmk10, vmk11) on ESXi hosts when joining the NSX transport network.
• Static Allocation Guarantee: Network Pools ensure that every commissioned host receives contiguous, deterministic IP assignments without requiring external DHCP servers for hypervisor infrastructure adapters.

---

ESXi Host Commissioning Workflow

Host commissioning is the formal onboarding process that registers physical ESXi hardware into the SDDC Manager inventory as consumable, unassigned capacity.

1. Host Preparation Prerequisites

Before initiating commissioning, the physical server must satisfy baseline criteria:

• Standard ESXi installation matching the exact VCF Bill of Materials (BOM) build.
• DNS forward (A) and reverse (PTR) records configured on corporate DNS servers.
• Management VMkernel interface (vmk0) configured with static IP, mask, and default gateway.
• Local storage drives completely blank (no remnant partition tables or foreign VMFS volumes).
• Active SSH daemon enabled with valid root credentials.

2. The Commissioning Wizard in SDDC Manager

Administrators navigate to Inventory > Hosts > Commission Hosts in the SDDC Manager UI (or submit a bulk JSON payload via the SDDC Manager REST API). For each host, the administrator specifies:

• Host FQDN: Fully qualified domain name resolving bidirectionally in DNS.
• Storage Type: Designating the storage architecture this host is qualified to join:
  • vSAN ESA: Host has certified all-NVMe storage matching ESA ReadyNode profiles.
  • vSAN OSA: Host has certified SSD cache + capacity disk groups.
  • External Storage: Host has Fibre Channel HBAs, NFS mounts, or vVols connectivity without local vSAN storage.
• Network Pool Association: Linking the host to a pre-created Network Pool to draw vMotion, vSAN, and Geneve TEP IP addresses.
• Credentials: Root credentials for SDDC Manager to access and configure the host.

3. Automated Validation and State Placement

Upon clicking Validate, SDDC Manager contacts the host via SSH and vSphere API, authenticates, verifies certificate thumbprints, audits hardware compatibility, tests network reachability, and inspects local disks. If validation passes, the host is placed into the Unassigned Hosts pool, ready to be consumed by new or existing workload domains.

---

VI Workload Domain Deployment Wizard: Sizing & NSX Topologies

When deploying a new VI Workload Domain via SDDC Manager (Inventory > Workload Domains > + Workload Domain), administrators navigate through several critical architectural decisions.

1. vCenter Server Sizing Options

SDDC Manager automatically deploys a new vCenter Server Appliance (VCSA) to govern the workload domain. Administrators must select an appropriate sizing profile based on projected inventory:

2. NSX Manager Deployment Topologies: Dedicated vs. Shared

For network virtualization, SDDC Manager offers two distinct architectural options:

• Dedicated NSX Manager Cluster (Recommended for Production):
  • SDDC Manager deploys a brand-new, dedicated 3-node NSX Manager cluster specifically for this VI Workload Domain.
  • Benefits: Complete operational and fault isolation. Routing changes, distributed firewall policies, and maintenance upgrades occur independently of any other workload domain.
  • Drawbacks: Consumes additional management compute and memory resources (3 NSX Manager virtual appliances consume a combined 12 vCPUs and 48–96 GB RAM).
• Shared NSX Manager Instance:
  • The new VI Workload Domain connects to an existing NSX Manager cluster previously deployed for another VI Workload Domain (or the Management Domain).
  • Benefits: Conserves management hardware resources and IP address space by eliminating redundant NSX Manager virtual machines.
  • Drawbacks: Broadens the operational blast radius. A control-plane failure or misconfiguration in the shared NSX Manager cluster impacts multiple workload domains simultaneously.

---

Principal vs. Supplemental Storage Architectures

VMware Cloud Foundation enforces a strict conceptual divide between Principal Storage and Supplemental Storage.

1. Principal Storage (Mandatory at Cluster Creation)

Principal storage is the primary datastore configured during initial cluster creation. The deployment wizard cannot proceed without specifying principal storage. Supported options include:

• vSAN Express Storage Architecture (ESA): Certified all-NVMe architecture using a single, high-performance storage pool per host without discrete disk groups.
• vSAN Original Storage Architecture (OSA): Traditional two-tier architecture requiring dedicated cache SSDs and capacity drives.
• NFS (Network File System): NFS v3 or v4.1 datastores mounted across dedicated, high-speed Ethernet storage networks.
• VMFS on Fibre Channel (FC): High-performance block storage provisioned via dedicated Fibre Channel Host Bus Adapters (HBAs) and SAN switching fabrics.
• vSphere Virtual Volumes (vVols): Policy-driven, array-integrated storage containers connected via a VASA (vSphere APIs for Storage Awareness) provider.

2. Supplemental Storage (Day-2 Capacity Expansion)

Supplemental storage refers to secondary datastores attached to an existing cluster after the workload domain has been successfully provisioned. Supplemental storage can leverage any vSphere-supported protocol (NFS, iSCSI, VMFS on FC, or vVols) and is typically used for secondary tier workloads, database backup targets, or content libraries.

---

Cluster Scaling: Adding and Removing Hosts

SDDC Manager provides automated workflows to scale VI Workload Domain clusters up or down dynamically.

1. Adding Hosts to a Cluster

• The administrator commissions one or more new hosts into SDDC Manager's unassigned pool.
• Under the target Workload Domain and Cluster, the administrator selects Add Host.
• SDDC Manager orchestrates the automated expansion:
  • Configures the ESXi host with the cluster's vSphere Distributed Switch (VDS).
  • Prepares the host as an NSX Transport Node, creating Geneve TEP interfaces with IP addresses drawn from the assigned Network Pool.
  • Adds the host to the vSphere cluster and claims local disks into the vSAN storage pool (or mounts external principal datastores).
  • vSphere HA and DRS automatically assimilate the new compute and storage capacity.

2. Removing Hosts from a Cluster

• The administrator selects Remove Host in SDDC Manager.
• vSAN Data Evacuation Mode: If the cluster is backed by vSAN, the administrator must specify the maintenance evacuation policy:
  • Ensure Accessibility (default): Migrates sufficient data to ensure all VMs remain accessible if an additional host fails, but does not replicate all components immediately.
  • Full Data Evacuation: Migrates every single data component to remaining hosts in the cluster, guaranteeing full fault tolerance (FTT) compliance before the host is removed.
  • No Data Evacuation: Discards local data replicas (only used if all data is already mirrored or non-critical).
• SDDC Manager evacuates workloads via vMotion, places the host in maintenance mode, unconfigures NSX transport node profiles, removes the host from the vSphere cluster, and returns the host to the Commissioned Unassigned Hosts pool.

---

Exam Watch: Key Scenarios and Candidate Traps

[!IMPORTANT] Network Pools Must Precede Host Commissioning: You cannot commission an ESXi host in SDDC Manager without associating it with a valid Network Pool. If an exam scenario asks why host commissioning cannot proceed or why an administrator cannot select IP ranges during the host onboarding wizard, the missing step is creating the Network Pool.

[!TIP] Dedicated vs Shared NSX Manager Decision: Pay close attention to scenario constraints on the exam. If the prompt specifies "strict multi-tenant regulatory compliance and isolated fault domains," the correct architecture is a Dedicated NSX Manager cluster. If the scenario emphasizes "minimizing control-plane resource overhead and management licensing footprint," the correct selection is a Shared NSX Manager cluster.

[!WARNING] vSAN Evacuation Mode Pitfall: When decommissioning an ESXi host from a production vSAN cluster to repurpose hardware, selecting Ensure Accessibility allows rapid host removal but leaves the cluster temporarily in an under-protected state if another failure occurs. For permanent host removal, Full Data Evacuation is the required enterprise procedure.