vSAN Storage Calculator

Convert vSAN raw disk capacity into effective usable capacity after RAID overhead, slack space and dedupe or compression.

Inputs

Hosts contributing storagehosts

Capacity disks per hostdisks

Size of each capacity diskTB

Storage policy

Slack space reserved%

VMware recommends 25-30% for rebuilds, rebalancing and snapshots.

Dedupe and compression ratioratio

1.5-2x is typical for mixed workloads; measure yours before relying on it.

Storage per VMTB

Effective Usable Capacity

72.58TB

Raw Capacity

138.24TB

Capacity After RAID Overhead

69.12TB

Capacity After Slack Reserve

48.38TB

VMs Supported

145VMs

Host Count Compliance

Compliant with a spare host for maintenance rebuilds

Step by step

Values used
Hosts contributing storage = 6 hosts; Capacity disks per host = 6 disks; Size of each capacity disk = 3.84 TB; Storage policy = RAID-1 mirroring, FTT=1 (50% usable); Slack space reserved = 30 %; Dedupe and compression ratio = 1.50 ratio; Storage per VM = 0.5000 TB
vSAN Storage
effective = hosts × disks × disk size × RAID factor × (1 − slack) × dedupe ratio, where the RAID factor is 0.50 for FTT=1 mirroring, 0.33 for FTT=2 mirroring, 0.75 for RAID-5 and 0.67 for RAID-6.
Effective Usable Capacity
= 72.58 TB
Raw Capacity
= 138.24 TB
Capacity After RAID Overhead
= 69.12 TB
Capacity After Slack Reserve
= 48.38 TB
VMs Supported
= 145 VMs
Host Count Compliance
= Compliant with a spare host for maintenance rebuilds

How it works

vSAN applies overheads in a strict order: the storage policy's redundancy comes first, then slack space is held back from what remains, and dedupe and compression multiply only the data actually written. RAID-5 and RAID-6 erasure coding are far more space-efficient than mirroring but need at least 4 and 6 hosts respectively and cost more write amplification. Sizing vSAN on raw terabytes overstates real capacity by two to four times, and a cluster that hits the slack threshold stops rebuilding objects — which is precisely when a second disk failure becomes data loss.

Formula

vSAN Storage

RAID factor: Share of raw capacity left after the policy's redundancy overhead
slack: Reserve vSAN needs for rebuilds, rebalancing and snapshots
dedupe ratio: Space saving applied after RAID, only on all-flash clusters

Frequently Asked Questions

How is vSAN Storage calculated?

effective = hosts × disks × disk size × RAID factor × (1 − slack) × dedupe ratio, where the RAID factor is 0.50 for FTT=1 mirroring, 0.33 for FTT=2 mirroring, 0.75 for RAID-5 and 0.67 for RAID-6. vSAN applies overheads in a strict order: the storage policy's redundancy comes first, then slack space is held back from what remains, and dedupe and compression multiply only the data actually written. RAID-5 and RAID-6 erasure coding are far more space-efficient than mirroring but need at least 4 and 6 hosts respectively and cost more write amplification.

Why does vSAN Storage matter?

Sizing vSAN on raw terabytes overstates real capacity by two to four times, and a cluster that hits the slack threshold stops rebuilding objects — which is precisely when a second disk failure becomes data loss.

What values do I need to enter?

This calculator takes 7 inputs: Hosts contributing storage, Capacity disks per host, Size of each capacity disk, Storage policy, Slack space reserved, Dedupe and compression ratio, Storage per VM. The pre-filled defaults are a realistic starting point — replace them with figures from your own environment for a result you can act on.

Why does FTT=1 mirroring need three hosts and not two?

vSAN stores two data copies plus a witness component, and all three must live on separate hosts so no single failure can take out a majority. FTT=2 mirroring needs five hosts for the same quorum reason with three copies and two witnesses.

You might also need

VMware Datastore Capacity Calculator VMware Cluster Capacity Calculator Host Failure Impact Calculator