Tools / Guides / vSAN Capacity Calculator
// Guide · Pre-deployment & planning

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.

OSA / ESARAID-1 / RAID-5 / RAID-6FTT PolicyDedup & CompressionSlack SpaceUsable vs Raw
Open the tool Jump to walkthrough

Quick start

  1. Pick architecture — OSA (legacy disk groups) or ESA (modern single-tier all-NVMe).
  2. Set cluster topology — host count, fault domains (or none for host-based), disks per host (and disk group count for OSA).
  3. Pick disk capacity — per-disk size from preset list (1.92TB / 3.84TB / 7.68TB / 15.36TB NVMe etc.).
  4. Choose FTT policy — FTT=1 RAID-1, FTT=1 RAID-5, FTT=2 RAID-1, FTT=2 RAID-6.
  5. Set slack space + dedup ratio — slack defaults to 25-30% per VMware guidance; dedup typical 1.5-3×.
  6. Read the result — usable capacity, per-host usable, and a breakdown of where capacity went.
On this page

When to use this tool

Use this tool when you need to:

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

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. Pick FTT policy

The vSAN policy applied to all VMs in the cluster:

5. Set slack space

vSAN reserves slack for resync operations, rebuilds, and policy changes. 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 dedup/compression ratio

Effective storage gain from dedup + compression. Highly workload-dependent:

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

7. Read results

The tool shows:

Examples

Example · 4-host ESA cluster, FTT=1 RAID-1

4 hosts × 6× 7.68 TB NVMe = 184 TB raw.

  • ÷ 2 (RAID-1) = 92 TB
  • × 0.7 (30% slack) = 64 TB usable (no dedup assumed)
  • × 1.5 dedup bonus = 96 TB effective
Example · Same hardware with RAID-5

Same 4 hosts × 6× 7.68 TB NVMe = 184 TB raw.

  • ÷ 1.33 (RAID-5 4+1) = 138 TB
  • × 0.7 (30% slack) = 97 TB usable
  • × 1.5 dedup bonus = 145 TB effective

Same hardware, +50% usable capacity by switching to RAID-5 — at the cost of slightly higher write amplification.

Common mistakes

Assuming dedup ratio without measuring Dedup ratios vary 1.0× to 4× depending on workload. Don't plan capacity assuming 2× when your data might compress to 1.1×. Use 1.0× for capacity planning, treat dedup as bonus.
Forgetting RAID-5 minimum hosts RAID-5 needs ≥4 hosts (3+1+1). RAID-6 needs ≥6 hosts (4+2). Picking RAID-5 on a 3-host cluster is impossible — vSAN will silently downgrade to RAID-1.
🚨
Slack space too low Below 20% slack, a single host failure can leave vSAN unable to maintain the policy during rebuild. Stay at 25-30%. The "saved" capacity isn't worth the risk.
OSA cache:capacity ratio wrong OSA cache should be ~10% of capacity. 1× 800 GB cache for 8 TB capacity = right. 1× 400 GB cache for 16 TB capacity = bottleneck. ESA doesn't have this — single tier eliminates the ratio problem.
Mixing disk sizes within a disk group (OSA) Capacity device sizing must be consistent within an OSA disk group. Mismatched sizes mean wasted capacity at the smallest common denominator.

Tools that pair well with vSAN Capacity Calculator:

FAQ

Should I use ESA or OSA for a new deployment?
ESA on VCF 9 with all-NVMe hosts. ESA is simpler (no cache/capacity tiers), faster, and has better data services. OSA only if you have legacy hardware that doesn't meet ESA HCL.
Why does my actual usable differ from the tool's estimate?
Tool computes the maximum theoretical. Actual usable depends on real workload dedup ratios, snapshot reservations, and any host-specific reserved capacity. Use the tool's number as a planning ceiling.
Can I change FTT policy on an existing cluster?
Yes — vSAN re-balances data to match the new policy. But the operation requires temporary additional capacity, which is exactly why slack space matters. Don't attempt large policy changes near capacity limit.
Does ESA still need slack space?
Yes — same 25-30% rule applies. ESA changes the protection mechanics, not the operational headroom needed for resyncs.
What about stretched cluster capacity?
Stretched cluster doubles storage need (each site has full data). Compute for a single site, then multiply by 2 for total raw. Some witness storage is also needed at the third site.