vSAN for Dummies, Part 4: Policies Beyond Mirroring (and Where Your Capacity Goes)
RAID-5/6 erasure coding explained with actual arithmetic, when stripe width helps, why thin provisioning is the default, and the capacity planning rule that keeps clusters healthy.
So far every protected object in our examples has been a mirror: FTT=1 means two full copies, so 100 GB of VM consumes 200 GB of cluster capacity. Simple, fast — and at scale, expensive. This part is about the other tools in the policy box, and about the question every vSAN admin gets asked monthly: where did all the capacity go?
RAID-5/6: paying with math instead of copies
Erasure coding stores your data plus computed parity instead of full copies. If a piece goes missing, vSAN recalculates it from what survives — same guarantee as mirroring, less capacity spent:
| Policy | Layout | 100 GB VM consumes | Overhead | Min hosts |
|---|---|---|---|---|
| FTT=1, RAID-1 | 2 copies + witness | 200 GB | 100% | 3 |
| FTT=1, RAID-5 | 3 data + 1 parity | 133 GB | 33% | 4 |
| FTT=2, RAID-1 | 3 copies + witnesses | 300 GB | 200% | 5 |
| FTT=2, RAID-6 | 4 data + 2 parity | 150 GB | 50% | 6 |
Read the last column twice: RAID-5 needs four hosts because the data-plus-parity stripe has four pieces, and each must live on its own host. Your three-node lab physically cannot do erasure coding — which itself is the lesson: policies are constrained by cluster shape. Many production design meetings are secretly about this table’s last column.
So why doesn’t everyone use RAID-5/6 everywhere? The price is paid in writes. Updating a mirrored block means writing it twice. Updating an erasure-coded block means reading old data and parity, computing, and writing multiple pieces — several I/O operations per write, plus more work during rebuilds. The honest rule of thumb:
- RAID-1 for write-heavy, latency-sensitive things (databases, VDI).
- RAID-5/6 for capacity-hungry, read-mostly things (file servers, backups, archives).
Stripe width: the setting you probably shouldn’t touch
Policies have a “Number of disk stripes per object” setting that splits each copy across multiple capacity devices. More parallelism sounds free — it isn’t. Wider stripes mean more components per object (remember the per-host and per-cluster component limits), more coordination, and rebuilds that touch more devices. Modern vSAN already distributes hot objects sensibly.
Leave it at 1 unless you’ve measured a specific bottleneck. A beginner series tells you this bluntly so a consultant doesn’t have to tell you expensively.
Thin by default, and the day that surprises you
vSAN objects are thin-provisioned unless a policy says otherwise: a 500 GB virtual disk consumes what’s written to it, not 500. This is the right default — and it means the datastore’s “free space” is a promise, not a fact. Ten VMs with 500 GB disks on a 3 TB datastore all fit comfortably at 20% full and catastrophically don’t at 80%.
The policy’s “Object space reservation” setting exists for the exceptions — set 100% for that one database whose disk must never hit a full datastore. For everything else, the fix isn’t reservations; it’s watching growth, which brings us to the rule that actually matters.
The capacity rule: rebuilds need somewhere to go
Think back to part 3. When a host died for good, vSAN rebuilt its components onto the remaining hosts’ free space. Now the punchline: if your cluster is nearly full, vSAN can survive a failure but not repair it. You’d run at reduced redundancy until a human adds capacity — under time pressure, which is the worst procurement strategy known.
Hence the operational rule: keep 25–30% free (the UI’s slack space, or in newer versions, the operations/host-rebuild reserves you can enable explicitly). This isn’t waste — it’s the shock absorber that lets the machine self-heal, and the difference between “a host died, vSAN handled it overnight” and “a host died, everyone is in a call about it.”
Read compliance as a design signal
An object can be accessible while not complying with its policy. For example, a RAID-5 policy may be valid in principle but impossible for a three-host cluster to satisfy. vSAN reports that the desired layout cannot currently be achieved; it does not invent extra hosts or silently weaken the policy. This distinction — desired state versus current state — is the mental model for everything vSAN does.
What you’ve learned
Erasure coding trades write cost for capacity and demands more hosts; stripe width is best left alone; thin provisioning makes free space a forecast, not a fact; and slack space is what makes the self-healing from part 3 actually work. In Part 5, the finale: the network vSAN deserves, reading health as an operator, ESA versus OSA, where stretched and two-node clusters fit, and what “decent at vSAN” looks like from here.