vSAN Capacity Calculator

vSAN never gives you 100% of raw capacity as usable. FTT replication, slack space, dedup overhead, and ESA encoding all eat into it. This calculator models all of them and tells you exactly how much usable capacity you actually get from a given hardware layout — and what changes when you move from FTT=1 to FTT=2 or from RAID-1 to RAID-5.

What changed for VCF 9.1 / 9.1.1

• Auto-RAID (ESA). One system-managed policy replaces per-VM RAID choices: FTT=0 below 3 hosts, RAID-5 2+1 at 3–5 hosts and RAID-6 4+2 at 6+ hosts, both at 1.5× overhead. Stretched clusters add a RAID-1 site mirror (2.0× / 3.0×); 2-node is 2.0×. Auto-RAID never uses the older 4+1 RAID-5 layout.
• Compression moved from LZ4 to zStandard and is always on. Expect a higher ratio than 9.0, arriving gradually on upgraded clusters as data is rewritten.
• Global deduplication is GA. Cluster-wide, post-process, 4 KB blocks, on HCI clusters of 3–64 hosts and vSAN storage clusters, now with data-at-rest encryption. Not supported on stretched or 2-node clusters. In VCF 9.0 it was limited availability via a Technical Qualification Request.
• Units. Device sizes are entered as vendor decimal TB and converted to binary TiB, which is what the vSAN UI reports. A 3.84 TB NVMe device is 3.49 TiB.

VCF 9.1.1 (September 2026) builds on the 9.1 storage stack; its vSAN additions (S3-compatible object storage, tech preview) do not change capacity maths.

When to use this tool

Use this tool when you need to:

• Size disk capacity for a new VCF deployment — confirm raw hardware purchase delivers the workload's usable capacity needs.
• Compare protection policies — how much capacity does FTT=2 cost vs FTT=1? Is RAID-5 worth it for the savings?
• Compare OSA vs ESA — ESA is more efficient but requires all-NVMe.
• Validate an existing cluster — does your deployed cluster have enough usable capacity for the workload roadmap?
• Plan capacity expansion — how many disks/hosts do I add for X more TB usable?

How it works

vSAN usable capacity is what's left after several deductions from raw:

1. Raw capacity = disks × per-disk size × hosts
2. Minus FTT overhead: RAID-1 = ÷2, RAID-5 = ÷1.33, RAID-6 = ÷1.5, FTT=2 RAID-1 = ÷3
3. Minus slack space: typically 25-30% reserved for resync, rebuilds, and policy changes
4. Plus dedup/compression bonus: 1.5-3× effective capacity gain (varies by workload)
5. Minus ESA performance leg overhead (ESA only): ~5-10%

The tool runs all of these and shows the final number plus a breakdown of where each deduction comes from.

Step-by-step walkthrough

1. Pick architecture

OSA (Original Storage Architecture) uses cache + capacity disk groups. Each host has 1-5 disk groups, each with 1 cache device + 1-7 capacity devices. ESA (Express Storage Architecture) uses a single tier — every NVMe drive is both cache and capacity. Pick OSA for hybrid or older hardware; ESA for new all-NVMe clusters.

2. Set cluster topology

• Number of hosts — typically 4-8 in a VCF management cluster, more for workload domains.
• Fault domains — None (host-based protection), or 3/4/5 explicit fault domains for rack/site protection.
• OSA: Disk groups per host — typically 1-2 for modest deployments, up to 5 for high-density.
• OSA: Capacity disks per disk group — typically 4-7 capacity disks per group.
• ESA: NVMe drives per host — typically 4-12 NVMe drives.

3. Pick disk capacity

Select from the dropdown. Common ESA NVMe sizes: 1.92 TB, 3.84 TB, 7.68 TB, 15.36 TB. Common OSA capacity sizes for hybrid: 1/2/4 TB HDD or matching SSD sizes for all-flash. The tool uses the listed raw size and accounts for the typical decimal-vs-binary discrepancy.

4. Choose policy management

Auto-RAID (ESA, VCF 9.1+) picks the layout for you from cluster size and topology — the calculator shows the layout in force and a scale-out table for other host counts. Manual policies let you compare classic storage policies:

• FTT=1 RAID-1 (mirror) — 2× storage cost. Needs 3 hosts. On ESA only worth it for 2-node clusters.
• FTT=1 RAID-5 — ESA: adaptive 2+1 (1.5×, 3 hosts) or 4+1 (1.25×, 6 hosts) for manually assigned policies; OSA: fixed 3+1 (1.33×, 4 hosts, all-flash).
• FTT=2 RAID-1 — 3× storage cost, 5 hosts. Avoid on ESA; RAID-6 gives FTT=2 at half the cost.
• FTT=2 RAID-6 (4+2) — 1.5× storage cost, 6 hosts. Auto-RAID's default at 6+ hosts.

Stretched clusters multiply every layout by 2 for the site mirror. Fault domains, when set, are what placement minimums are checked against.

5. Set reserves

Modern vSAN uses Reserved Capacity: an Operations Reserve (~5%) for resync and policy changes, and an optional Host Rebuild Reserve of roughly one host (1/N) so a failed host can be rebuilt in full. The total therefore falls as clusters grow — about 30% on 4 hosts, 8% on 32. The legacy fixed slack model (25–30%) is kept for older designs. VMware recommends 25-30% for typical use; 30% is the default. If you go below 20%, you risk policy operations failing during host failures. Above 35% is conservative but wastes capacity.

6. Set compression and deduplication

ESA compresses every 4 KB block (zStandard in 9.1); enter the ratio you expect, typically 1.5–2×. Global deduplication is a separate post-process saving on top of compression; size day-1 capacity without it and treat the ratio as an estimate. OSA uses one combined dedup + compression ratio. Highly workload-dependent:

• 1.0× (none) — for compressed workloads (databases with native compression, encrypted data)
• 1.5× — typical mixed workload
• 2-3× — VDI, file servers, dev/test (lots of duplicate data)

If unsure, use 1.0× to get conservative usable; the actual savings are bonus.

7. Read results

The tool shows:

• Total usable capacity — your final answer
• Per-host usable — average per host
• Capacity breakdown — pie/bar chart showing raw → FTT → slack → effective with dedup
• Comparison table — what the same hardware gives you under different FTT policies

Examples

Common mistakes

Related tools

Tools that pair well with vSAN Capacity Calculator:

FAQ