5.8 Workload Domain Storage: Principal vs. Supplemental Storage

5.8 Workload Domain Storage: Principal vs. Supplemental Storage

Exam Focus: The blueprint lists "configure Workload Domain storage" as its own objective. Almost every exam item on this topic turns on one distinction — principal storage is a creation-time decision that cannot be reversed, supplemental storage is anything added afterwards.

---

The Two Categories

The immutability of the principal choice is the reason it deserves design attention. An organisation that deploys a VI workload domain on NFS principal storage and later standardises on vSAN cannot convert that cluster; it must build a new cluster with the desired principal storage and migrate workloads.

---

Supported Principal Storage Types

Management domain

The management domain uses vSAN as its principal storage. The management appliances — vCenter, NSX Managers, SDDC Manager, and the VCF Operations nodes — land on that datastore during bring-up.

VI workload domains

VI workload domains have a genuine choice:

---

How Each Choice Changes Operations

Capacity scaling. With vSAN, capacity is a function of the hosts in the cluster — growing capacity means adding hosts or devices to hosts, and adding a host adds compute at the same time. With external storage, capacity grows by presenting more from the array, independently of host count. A scenario that says "we need more storage but not more compute" is pointing away from vSAN.

Failure domains. vSAN's resilience is expressed in storage policy across hosts and fault domains, as covered in Chapter 3. External array resilience is the array's responsibility and is invisible to vSphere policy.

Where the policy is enforced. Storage policy-based management applies to every datastore type, but what the policy means differs:

• On vSAN, the policy specifies FTT, placement scheme, and space efficiency, and vSAN enforces it directly.
• On vVols, the policy expresses capabilities the array advertises and enforces, such as array-side replication or snapshot policy.
• On VMFS and NFS, policy use is typically limited to tagging and capability matching for placement rather than protection enforcement.

---

Adding Supplemental Storage

Supplemental storage is the answer to most day-2 storage requests, precisely because principal storage cannot change. Common patterns:

• Adding an NFS datastore to a vSAN-backed cluster for bulk, low-cost capacity such as templates, ISOs, or archives.
• Presenting VMFS on FC LUNs to a cluster whose principal storage is vSAN, to host a workload with an array-specific requirement.
• Attaching a second vSAN datastore where the topology supports it, for tiering.

The operational caution is that supplemental datastores broaden the cluster's dependency surface. A cluster whose principal storage is vSAN but whose critical database sits on a supplemental FC LUN now depends on both the vSAN cluster health and the FC fabric.

---

Protocol-Specific Considerations

The four principal storage choices differ in more than transport, and the differences drive real design decisions.

vSAN. Because capacity is contributed by the cluster's own hosts, every host added for capacity also adds CPU and memory to the cluster, and every host removed takes capacity with it. Maintenance mode therefore has a storage dimension that does not exist with external arrays: evacuating a host may require moving data, which is why the Ensure accessibility and Full data migration options exist. vSAN is also the only principal storage type whose protection is expressed in vSphere storage policy and enforced by vSphere itself.

NFS. Provisioning is simple — the datastore is a mounted export, and capacity is grown on the filer without touching vSphere. The dependency to plan for is the network path: NFS datastore traffic shares the physical fabric with everything else unless it is deliberately separated onto its own VMkernel adapters and VLAN. Availability follows the filer's own clustering rather than anything vSphere controls.

VMFS on Fibre Channel. The FC fabric is a separate network with its own zoning, multipathing, and failure modes. Multipathing policy and path selection are configured per device on the host, and a zoning error typically presents as a datastore visible to some hosts in the cluster but not others — which in turn blocks vSphere HA and vMotion for VMs on that datastore.

vVols. Each virtual disk becomes an array-side object rather than a file inside a shared LUN, so array services such as snapshots and replication operate at virtual machine granularity. This requires a storage provider (VASA) registered with vCenter, and that registration becomes a dependency: if the provider is unreachable, provisioning and policy operations fail even though existing I/O continues.

Cluster Consistency

Every host in a cluster must see the principal storage identically. A datastore presented to only a subset of hosts breaks the assumptions vSphere HA and DRS rely on, because a VM cannot be restarted or migrated onto a host that cannot reach its files. When troubleshooting a cluster where HA fails to restart specific VMs, uneven storage presentation is a standard early check.

---

Exam Watch: Key Scenarios and Candidate Traps

[!IMPORTANT] "Change the principal storage" is never the answer. If a scenario asks how to move an existing cluster from one principal storage type to another, the correct response is to deploy a new cluster with the desired principal storage and migrate workloads. Look for that shape in the answer options.

[!TIP] Separate the capacity question from the compute question. vSAN couples them, external storage decouples them. Scenarios that stress growing one without the other are testing whether you noticed.