vSAN sizing for ESA: from raw to usable capacity, storage policies, reserves and host count

How to calculate vSAN usable capacity

vSAN sizing works back from usable capacity, which is the raw capacity of all capacity devices in the cluster, minus the capacity vSAN needs to repair data after a host failure and for internal operations, divided by the overhead of the storage policy. On vSAN ESA, RAID-5 2+1 and RAID-6 4+2 need 1.5 times the data in raw capacity, RAID-5 4+1 needs 1.25 times and mirroring 2 to 4 times. Broadcom’s vSAN design guide of 5 May 2026 asks for capacity equal to one full host to stay unused, so that components can be rebuilt after one failure or during maintenance.

As a formula, usable = (raw - reserves) / factor, calculated in TiB of raw capacity. Compression and deduplication come afterwards, as savings vSAN reports once data is written, and Broadcom’s design guide states that its policy overhead “is prior to savings from compression and deduplication”.

This guide assumes vSAN ESA with one site and no fault domains. OSA and its erasure coding rules are in our vSAN ESA vs OSA comparison, and site mirroring is covered in our vSAN stretched cluster guide.

vSAN storage policies and minimum hosts per policy

Broadcom’s VCF 9.1 documentation on vSAN policies, updated on 5 October 2026, defines failures to tolerate (FTT) as the number of host and device failures an object can tolerate. With fault domains, vSAN needs 2n+1 of them for n failures, and a host outside a fault domain counts as its own single-host fault domain. Mirroring with FTT=2 therefore needs five hosts, and FTT=3 needs seven.

For ESA, the same page says vSAN creates “an optimized RAID-5 format based on the cluster size”. Below six hosts it uses RAID-5 2+1, and from six hosts RAID-5 4+1, which consumes 125 GB of raw capacity for a 100 GB disk. After a change in host count, vSAN readjusts the format after 24 hours. RAID-6 on ESA is a 4+2 scheme spread across at least six hosts.

Broadcom TechDocs VCF 9.1, What are vSAN Policies (5 October 2026); vSAN design guide (5 May 2026); vSAN FAQ (6 October 2026); KB 405876. Hosts with N+1 is the minimum plus one host, as the FAQ recommends; RAID-5 4+1 spans five hosts, so its six-host threshold already leaves one spare.

The last column follows Broadcom’s vSAN FAQ of 6 October 2026, which recommends “sizing a cluster host count to one additional host beyond the requirements of the storage policies used”. A cluster of six hosts can run RAID-6, but after one host fails there is no sixth host to place the missing components on until the host returns. The same page that lists RAID-1 with FTT=3 says the option “will be deprecated in a future vSAN release”.

Operations reserve and host rebuild reserve in vSAN 8 and 9.0

Before vSAN 7 Update 1, the design guide recalls, a slack space of 25 to 30 percent was typically planned for failures and maintenance; that release added two optional settings for it. Broadcom’s KB 326889 describes the operations reserve as capacity for transient activities such as policy changes and rebalancing. The host rebuild reserve is kept for recovery after a single host failure.

The design guide sizes the host rebuild reserve on the assumption that the largest host in the cluster has failed. KB 326889 adds that it decreases as hosts are added, since one host becomes a smaller share of the cluster. Per the vSAN 8.0 documentation, the host rebuild reserve can only be enabled after the operations reserve. Both need at least four hosts and are not available on stretched clusters, ROBO (two-node) clusters or clusters with fault domains. For clusters with fault domains, the design guide points back to the older guidance of keeping about 25 percent of capacity unused.

KB 326889 also sets the thresholds of the vSAN capacity health check. It defines the host rebuild threshold as total capacity minus the operations reserve and the host rebuild reserve. With the host rebuild reserve enabled, the check turns yellow at the lower of 70 percent of total capacity and 80 percent of that threshold, and red at the lower of 90 percent and the threshold itself. Without it, yellow comes at the lower of 70 percent and the host rebuild threshold. A warning, the KB says, means that the cluster may not have enough capacity to repair after a failure.

Auto-RAID and the effective capacity view in vSAN 9.1

In vSAN for VCF 9.1, Auto-RAID chooses the policy from the cluster size. Broadcom’s design guide and its VCF blog post of 8 May 2026 give FTT=1 with RAID-5 on 3 to 5 hosts and FTT=2 with RAID-6 on 6 or more, both at 1.5 times the object size. Below three hosts in a single-site cluster, Auto-RAID uses FTT=0 at 1.0 times the object size, which leaves objects without redundancy. The 9.1 release notes, updated on 8 October 2026, state that “vSAN clusters use RAID-6 as the default RAID level”. Per the vSAN FAQ, RAID-5 4+1 is no longer used when Auto-RAID is enabled.

Per the blog post, Auto-RAID is enabled by default on new clusters, while clusters upgraded to 9.1 keep their existing storage policies and get a health alert that recommends Auto-RAID. To create a custom VM storage policy in 9.1, the TechDocs page on vSAN policies says, you must first disable vSAN ESA Auto-RAID.

The effective capacity view needs Auto-RAID. Broadcom’s VCF blog post of 11 May 2026 says the view sets aside capacity for operational activities and host failures automatically, so the reserves are no longer set by hand. The design guide calls the old operations reserve and host rebuild reserve settings legacy and redundant with these views when Auto-RAID is in use. Provisioned sizes are shown without the policy overhead, so a 100 GB VM under RAID-6 appears as about 100 GB rather than 150 GB. Clusters without Auto-RAID keep the legacy capacity view, and the previous section applies to them.

Our VMware optimisation service covers vSAN version and architecture updates, with all changes in agreed maintenance windows and a rollback plan at every stage. Tell us which vSAN clusters you have upgraded to 9.1 and which storage policies they run.

Compression and deduplication in a vSAN sizing

vSAN ESA evaluates each incoming 4 KB block on 512-byte sectors and can store a highly compressible block in one eighth of its size, according to Broadcom’s space efficiency paper of 11 May 2026. The vSAN FAQ calls compression “an opportunistic space efficiency feature”, and the paper recommends a conservative estimate of compression rates for production data. Already compressed image and video files are not reduced further. VM encryption in vSphere, the same paper says, negates the savings from deduplication, which is why it recommends vSAN’s own encryption services.

The effective capacity view in 9.1 does not forecast unused capacity from compression or deduplication, per Broadcom’s blog post of 11 May 2026. Savings appear as ratios at cluster level once data has been written. For a new cluster we size without data reduction and treat the ratio measured later as headroom.

Raw capacity per host: drives, TB and TiB

Drive vendors state capacity in decimal terabytes, while vSAN and its licences count in tebibytes of 2^40 bytes. A 7.68 TB NVMe device holds about 6.98 TiB, so eight of them give about 55.9 TiB of raw capacity per host. Broadcom’s KB 394440 adds that a drive can be slightly larger than its label, giving the example of a 15.36 TB device of 13.9707 TiB against 13.9698 TiB calculated from the specification.

The design guide sets 1.6 TB as the smallest device supported for production use with ESA, and the vSAN FAQ allows up to 64 hosts in one cluster. Equal hosts keep the host rebuild reserve, which follows the largest host, easy to plan. Raw TiB is also the licence metric for vSAN, as our guide to VMware licensing after Broadcom explains.

vSAN ReadyNode Sizer and Broadcom’s sizing tools

Broadcom’s design guide of 5 May 2026 encourages all vSAN sizing to go through the vSAN Sizing tool, which it describes as “Being deprecated summer 2026”, and names the VCF Private Cloud Sizer, then in beta, as its replacement. For storage estimates it recommends the vSAN ReadyNode Sizer and says that “the vSAN Sizer will take into account file system, metadata and checksum overheads”. The vSAN FAQ of 6 October 2026 says sizing “was historically achieved through the vSAN ReadyNode Sizer” and names Live Optics and RVTools for assessing a current environment. As of October 2026 we found no Broadcom document that says which tool has replaced the vSAN Sizing tool.

Any sizer needs the same inputs, which come from the current estate: used capacity per VM rather than provisioned capacity, growth over the planning horizon, the storage policy and the host configuration. Forecasting that growth is the subject of our vSphere capacity planning guide.

Worked examples for 6, 12 and 24 hosts

The examples below are ours, calculated on Broadcom’s published rules. Each host has eight 7.68 TB NVMe TLC devices, 55.9 TiB of raw capacity, and the cluster runs vSAN 9.1 with Auto-RAID. The 70 percent ceiling on raw use is our own planning rule, not a Broadcom recommendation. We set it at the highest point where the KB 326889 health check can turn yellow. In all three clusters it keeps more than one host’s capacity unused, and no compression is counted. On vSAN 8 or 9.0 with the host rebuild reserve on, a six-host cluster warns earlier, at about 67 percent or less, because that reserve alone is a sixth of the capacity.

Our arithmetic and our 70 percent planning rule on Broadcom’s design guide (5 May 2026), TechDocs VCF 9.1 vSAN policies (5 October 2026), KB 326889 and KB 394440; marked example, before file system and metadata overheads.

The six-host cluster meets the RAID-6 minimum but not the recommended seventh host, so after a host failure its objects run with one failure tolerated less until the host is back. The custom RAID-5 4+1 policy on twelve hosts holds about 60 TiB more VM data than RAID-6, at FTT=1 instead of FTT=2, and needs Auto-RAID disabled first. At 24 hosts one host is about 4 percent of the cluster, so the 70 percent plan keeps far more back than one rebuild needs.

Working from demand instead, 1,000 VMs with an average of 250 GiB used each come to about 244 TiB of data. The steps are these:

1. Take the used capacity per VM and its growth over the planning horizon from the current cluster or an assessment tool.
2. Multiply by the policy factor for the planned host count, 1.5 for Auto-RAID on ESA, which gives 366 TiB.
3. Divide by the planned raw use, 0.7 under our planning rule, which gives 523 TiB.
4. Divide by the raw TiB per host and round up, here to 10 hosts, then check the result against the policy minimum plus one host.
5. Count compression and deduplication only as headroom once the cluster reports a measured ratio.

Ten hosts at this density run RAID-6 under Auto-RAID and include the extra host Broadcom recommends. Denser hosts lower the host count, with the effect on licensed cores shown in our host consolidation guide, while each host’s share of the rebuild reserve grows.

Our VMware optimisation service includes an audit of the estate with its actual resource usage, and Eurokommerz supplies the hardware under the solution. Send us the hosts, drives and used capacity of each vSAN cluster through the form below, with the growth you plan for.

What we do

Under VMware optimisation, our engineering partner Vixen.UNO audits your VMware estate and licences and modernises vSphere, vSAN, NSX and VCF. Eurokommerz holds the contract and supplies the hardware under the solution, with EU invoicing, delivery and warranty under European law. Changes, including cross-cluster migrations, run in agreed maintenance windows with a rollback plan at every stage, followed by support under an agreed SLA. The first call is free of charge, and the price of the technical assessment, with its report, TCO and ROI model and action plan ahead of renewal, is fixed before work begins.

FAQ