vSAN Capacity, Policy, and Feature Requests on an ESA Cluster
An 8-host vSAN cluster runs vSAN 8 with the Express Storage Architecture. Each host has 2 x 3.84 TB NVMe drives, giving roughly 61 TB of raw capacity; the cluster currently reports 44 TB consumed (about 72%). All hosts are in a single site, spread across two racks, and there is no witness host. Two requests land on your desk. BU-A wants a 12 TB database VM with a storage policy of FTT=2 using RAID-6 erasure coding. BU-B wants 400 general-purpose VMs on a policy of FTT=1, RAID-1, with deduplication and compression enabled. The cluster currently runs a mix of RAID-1 FTT=1 and RAID-5 FTT=1 objects. No capacity expansion is approved this quarter.
1. Will BU-A's 12 TB FTT=2 RAID-6 object provision? Show the arithmetic and state what you would tell BU-A.
Read the worked answer
Arithmetic
- Raw capacity: ~61 TB. Consumed: 44 TB. Free: ~17 TB.
- On vSAN ESA, RAID-6 with FTT=2 uses a 4+2 layout, i.e. 1.5x space amplification (plus small metadata overhead).
- 12 TB logical x 1.5 = 18 TB of raw consumption.
- 44 + 18 = 62 TB against 61 TB raw, with zero slack for rebuilds or snapshots.
Verdict - it does not fit. Even the raw numbers fail, and that ignores the ~25–30% free-capacity headroom you need to absorb a host rebuild or an object repair. The policy itself is legal (ESA RAID-6 FTT=2 requires at least 6 hosts; you have 8), so the blocker is capacity, not compliance.
What to tell BU-A
- The request cannot be satisfied at current cluster utilisation without expansion or reduced scope.
- Options in order of preference: (a) add capacity to the cluster; (b) reduce the object to a size that fits with headroom; (c) accept FTT=1 RAID-5 (1.33x) as an interim risk decision signed off by the business owner - but note this changes the failure domain posture for a database.
- Do not accept the workload and let it sit in a 'reduced availability' or non-compliant state; that silently erodes the cluster's ability to rebuild.
Reasoning - vSAN policy compliance is evaluated continuously, but capacity admission is your job, and slack space is what lets a rebuild finish without taking the cluster offline.
2. What happens to BU-B's policy request on this cluster, and what would you recommend instead?
Read the worked answer
What happens
- The vSAN Express Storage Architecture does not provide deduplication. Compression is supported per-object on ESA; deduplication is an OSA-era capability. A policy that requests deduplication on an ESA datastore is not honoured the way the requester expects, and the compliance status will not show the space savings they budgeted for.
- Therefore the assumption behind the 400 VMs - that dedup will claw back space - is false, and the capacity plan for BU-B must be rebuilt without it.
What to recommend
- Confirm the datastore's architecture with the requester and rebuild the sizing on compression alone, if any. For 400 mostly-identical general-purpose VMs, compression gives modest, workload-dependent savings - do not bank on it.
- If deduplication is a hard requirement, that is an OSA datastore decision and belongs in a cluster-design conversation, not a policy edit on this cluster.
- Keep FTT=1 RAID-1 for the 400 VMs: it is 2x amplification, so 400 x (configured size) x 2 must fit inside the free capacity with headroom. On ~17 TB free this likely means a smaller average VM disk than the requester assumed.
- Re-check the resulting mix: adding RAID-1 bulk next to an existing RAID-5 population changes rebuild cost per host, which matters more than the headline free-space number.
Reasoning - the trap is treating a policy checkbox as a capacity guarantee. Policy capabilities are bounded by the storage architecture, and an unsupported option silently becomes 'no saving'.
3. The business asks what happens if a host fails after you accept whatever fits. How do you answer, and what operational settings do you check?
Read the worked answer
Answer to the business
- FTT=1 objects (RAID-1 or RAID-5) tolerate one host failure and rebuild onto remaining hosts. FTT=2 RAID-6 objects tolerate two, but cost 1.5x.
- The real question at 72% consumed is whether the rebuild can complete. If free capacity is thin, a rebuild may not have anywhere to place the repaired components, and objects can go into a reduced-availability state or the cluster can hit a capacity threshold that blocks writes.
- Quantify it: for each host, state raw capacity, current used, and the projected post-rebuild utilisation. If a single host's data will not fit into the remaining free space, the rebuild will not finish - that is the answer, not a reassurance.
Settings to verify
- Object repair timer - default 60 minutes; keep it, but know it delays rebuild start.
- Capacity alerts - the 75% and 80% thresholds matter; at 72% you are about to trip the first one, so set the alert recipient list deliberately.
- Cluster evacuation - a host in maintenance mode with 'Ensure accessibility' will not free space; choose 'Full data evacuation' only when capacity allows.
- Resync throttling - confirm the rebuild will not starve running workloads.
- Health checks - verify no pre-existing component or network health issues before a rebuild is ever needed.
Reasoning - availability posture in vSAN is a function of policy multiplied by free capacity. The second factor is the one people forget to report to the business.