VxRail uses VMware vSAN as its storage layer, pooling local NVMe or flash drives across nodes into one datastore. vSAN runs in two architectures: OSA, built on cache and capacity disk groups, and ESA, a single-tier all-NVMe design. Data services, capacity overhead, and usable storage differ between them, so sizing depends on which architecture the cluster runs.
A vendor quote for a VxRail cluster lists raw terabytes. What lands in vCenter after storage policies, slack space reservations, and the binary-to-decimal conversion is a smaller number, and the gap between the two catches more buyers than it should. The gap also depends on which vSAN architecture the cluster runs, which is not always the first thing a sizing conversation covers.
How vSAN Works Inside VxRail
Every node in a VxRail cluster contributes its local drives to a single shared datastore that every host in the cluster can reach. There is no external array, no fabric, and no LUN to carve up. A virtual machine’s data is broken into objects and components and distributed across multiple nodes according to the storage policy assigned to that VM.
The trade is worth stating plainly, because it is the whole architectural bargain everything else in this article follows from. Removing the SAN removes a tier of hardware and a tier of licensing. In its place, the storage layer now shares CPU, memory, and network bandwidth with the workloads it serves. That sharing is efficient when it is sized correctly and painful when it is not, which is why capacity planning matters more on vSAN than it did on a dedicated array.
vSAN OSA and vSAN ESA: Which Architecture Is Your Cluster Running
OSA, the original storage architecture, organizes drives into disk groups, each with one cache device and multiple capacity devices. It is a two-tier design, and it has a blast-radius characteristic worth knowing before it becomes a problem: a single cache device failure takes the entire disk group offline, not just the one drive.
ESA, introduced with vSAN 8, is single-tier and all-NVMe. There are no disk groups and no cache tier. Each node running ESA needs a minimum of 16 CPU cores and 128 GB of memory, and drives connect over PCIe lanes through the backplane rather than through a storage controller. SAS and SATA SSDs are not supported, and neither are spinning disks. Compression moved to the top of the stack under ESA, so data is compressed before it crosses the network between nodes, meaning less data gets transmitted, encrypted, and checksummed at every step downstream.
Here is how to answer the section heading for your own cluster. There is no in-place upgrade path from OSA to ESA, so a cluster deployed on VxRail 7.0 and upgraded forward through several software versions is almost certainly still running OSA today, regardless of what version number it reports. But no in-place path is not the same as no path. The blocker is a destructive reformat of the storage layer, not necessarily a purchase order. VMware’s own migration guidance confirms that hosts already running vSAN OSA can join a new ESA cluster once their existing drives are fully wiped of prior partitions and metadata, and workloads are evacuated first. If a cluster’s nodes are already all-NVMe and ESA-certified, moving to ESA is a migration project with a rebuild window, not automatically a hardware refresh. New hardware becomes necessary specifically when the existing drives are not NVMe or do not meet the ESA floor covered below, not as a blanket rule.
| vSAN OSA | vSAN ESA | |
|---|---|---|
| Disk layout | Two-tier disk groups: cache plus capacity devices | Single-tier flat pool, no disk groups |
| Drive requirement | SAS, SATA, or NVMe. Hybrid supported. | NVMe only, via PCIe backplane. No storage controller. |
| Node minimum | Standard VxRail node requirements | 16 cores / 128 GB — vSAN ReadyNode floor, see note below |
| Compression | 4 KB to 2 KB or not at all. Cluster-wide setting. | Variable ratio up to 8:1. On by default, per-policy override. |
| Deduplication | Cluster-wide setting, applied per disk group | Not at cluster level under vSphere 8. Global dedup, limited availability in VCF 9.0, GA in 9.1. |
| RAID-5 / RAID-6 | Capacity savings with a real write penalty | Near RAID-1 performance at RAID-6 capacity |
| Single drive failure | Cache device failure takes the whole disk group offline | Failure is contained to the individual device |
Table 1. vSAN OSA and ESA compared. Confirm against the current VxRail support matrix at publication time.
A note on that node minimum row: the 16-core, 128 GB figure is the floor set by VMware’s vSAN ReadyNode program for ESA, not a VxRail-specific number. Dell renamed its ESA profile tiers in November 2025. The entry tier formerly called ESA-AF-0 is now vSAN-HCI-SM, and that smallest profile now supports 10GbE networking, which the original profile definitions did not. Check the current profile name and per-model specification against a live quote rather than an older document.
vSAN Data Services
Compression
OSA compression is binary at the block level: a 4 KB block either compresses to 2 KB or it does not compress at all. ESA changed the model. Compression now happens whenever it makes sense, down to whatever ratio the data allows, up to a theoretical 8:1 per block, and it is enabled by default at the cluster level with a per-policy override available. One caveat worth knowing before enabling compression on an object that already has data: it only applies to new writes. Blocks written before compression was turned on stay uncompressed.
Deduplication
On OSA, deduplication is a cluster-wide setting applied per disk group. On ESA under vSphere 8, there is no cluster-level deduplication at all. Global deduplication first appeared in vSAN for VCF 9.0 under limited availability through Broadcom’s Technical Qualification Request program: single-site clusters only, 3 to 16 hosts, 25GbE or faster networking, and no support for data-at-rest encryption at that stage.
It went generally available in vSAN for VCF 9.1 with those restrictions relaxed, supporting clusters of 3 to 64 hosts, though stretched clusters and 2-node clusters remain excluded. One detail worth flagging for anyone weighing encryption against data reduction: unlike the 9.0 limited release, global deduplication in 9.1 works alongside data-at-rest encryption without losing data reduction ratios, which is unusual. Encrypted data normally defeats deduplication entirely, because every encrypted block looks unique even when the underlying data is not.
Encryption
Both data-at-rest and data-in-transit encryption are supported. On VxRail 8.0.300 and later, vSAN encryption can be turned on during initial cluster deployment or enabled and disabled afterward as a day two operation. The layer at which encryption happens matters for capacity. Encrypting at the vSAN layer preserves compression and deduplication savings. Encrypting at the virtual machine layer does not, because the data already arrives at storage encrypted, and encrypted data does not compress or deduplicate well regardless of which layer applied it.
Erasure Coding and What ESA Changed
On OSA, RAID-5 and RAID-6 saved real capacity, but the write penalty was severe enough that most teams stayed on RAID-1 mirroring anyway, despite paying double the storage cost for it. ESA removed that trade. Dell’s own framing is RAID-1 performance at RAID-6 capacity, and in practice it holds up well enough that erasure coding stops being a compromise and becomes the default choice on ESA clusters, new or migrated.
Adaptive RAID-5 is worth understanding specifically, because it is not widely known outside of people who size vSAN clusters for a living. On ESA, a cluster of 3 to 5 hosts uses a 2+1 layout: two components for data, one for parity. A cluster of 6 or more hosts uses 4+1. The capacity efficiency of the exact same named policy changes with host count. Adding a sixth host to a five-host cluster can improve storage efficiency across the whole datastore without touching a single policy setting. For more on how node count, cluster limits, and expansion affect VxRail design, see VxRail scalability and node growth planning.
VCF 9.1 took this a step further with Auto-RAID, the successor to VMware’s earlier Auto-Policy Management feature. Instead of an administrator choosing a resilience level per VM, Auto-RAID continuously evaluates cluster conditions such as host count and topology and assigns the optimal RAID configuration on its own, adjusting automatically as hosts are added or removed. It is enabled by default on new VCF 9.1 clusters, and an existing cluster can move to it by switching the datastore’s default storage policy. The adaptive RAID-5 behavior described above is exactly the kind of decision Auto-RAID is designed to make without a person in the loop.
| Policy | Storage cost | Raw retained | Minimum hosts |
|---|---|---|---|
| FTT=1, RAID-1 mirror | 2.0x | 50% | 3 |
| FTT=1, RAID-5 (OSA 3+1) | 1.33x | 75% | 4 |
| FTT=1, RAID-5 (ESA 2+1) | 1.5x | 67% | 3 to 5 |
| FTT=1, RAID-5 (ESA 4+1) | 1.25x | 80% | 6 |
| FTT=2, RAID-1 mirror | 3.0x | 33% | 5 |
| FTT=2, RAID-6 (4+2) | 1.5x | 67% | 6 |
Table 2. Storage policy capacity overhead. Figures are before slack space. Apply a further 25 to 30 percent reservation to reach usable capacity.
What This Means for Clusters Staying on OSA
Most of the installed base is running OSA and will keep running OSA for a while, whether by choice or because a full ESA migration is not on this year’s budget. VCF 9.1 gave that installed base a new option worth knowing about: mixed-mode remote datastore mounting between OSA and ESA clusters. In practice, an existing OSA cluster does not have to be decommissioned to get value from newer ESA storage. It can be repointed to run as a vSphere compute cluster while its storage needs are served by a separate ESA storage cluster, extending the useful life of hardware that already works rather than retiring it on a fixed schedule. VMware’s own migration documentation lists exactly this pattern, repurposing existing OSA hosts as a way to transition off OSA gradually, as one of the intended use cases for the feature.
That matters for a straightforward reason: not every organization on OSA needs a hardware refresh to benefit from what ESA does well. Some need a rebuild window and a migration plan for nodes that already qualify. Others can keep OSA hardware in service longer than a straight refresh timeline would suggest, pointed at ESA-backed storage instead of being replaced outright. Either path is a smaller, more defensible project than a wholesale platform swap, and it is worth raising before a refresh conversation defaults to the biggest possible number.
Storage Policies: Protection Is Per VM, Not Per Cluster
Storage policies attach to individual virtual machines rather than to the cluster as a whole, so one datastore can run FTT=1 RAID-5 for general workloads and FTT=2 RAID-1 for a database simultaneously. Changing a policy triggers a resync, which moves data across the cluster and consumes capacity while it runs. Failure behavior and rebuild timing during an actual node loss belong to a separate conversation. See VxRail High Availability and Disaster Recovery Design for the fault tolerance table and node minimums by failure scenario.
Calculating Usable Capacity From Raw Capacity
A formula is less useful here than a worked number, so here is one built on a realistic configuration.
A six-node cluster with eight 3.84 TB NVMe drives per node holds 184.32 TB raw. Under FTT=1 RAID-5 in a 4+1 layout, roughly 80 percent survives RAID overhead, leaving about 147 TB. Reserving 25 percent slack space for rebuilds and resync operations brings usable capacity to roughly 110 TB.
The detail that rarely makes it into a quote: drive capacity is sold in decimal terabytes and reported by vCenter in binary tebibytes. That 184.32 TB shows up as roughly 167 TiB before a single storage policy is applied, and the 110 TB of usable capacity calculated above shows up on screen as roughly 100 TiB. The number on the purchase order and the number in the interface were never going to match at any stage of the calculation, and carrying the conversion all the way through avoids a confusing conversation after deployment rather than just flagging that a gap exists.
Slack space deserves its own line item, not a footnote. VMware recommends keeping 25 to 30 percent of the datastore free for rebuilds, resyncs, and storage policy changes. vSAN 7.0 and later automates much of this accounting for you through the operations reserve and host rebuild reserve settings, which set capacity aside specifically for these events rather than leaving it to a rule of thumb. Running well below the recommended threshold puts that safety margin at risk, and policy operations can become unreliable during a host failure, which is precisely the moment the cluster most needs them to succeed. That reservation is not conservative padding. It is capacity vSAN needs in order to do its job when something breaks.
Every figure in this section is an estimate. Compression ratios vary by workload, metadata overhead varies by object count, and ESA’s performance-leg components add their own variability. Anything that is going into an actual purchase decision should be validated against Dell’s vSAN ReadyNode Sizer before the order goes in.
Where vSAN Capacity Planning Goes Wrong in Production
Most capacity problems that end up on Maven’s desk trace back to one of four patterns, and none of them are exotic.
- Sizing on the raw number. The cluster gets purchased against raw capacity, the policy overhead and slack reservation get discovered after deployment, and the environment is capacity-constrained from the day it goes live.
- Running the datastore hot. At 85 percent full, a node failure triggers a rebuild with nowhere to put the recovered data. The rebuild stalls, the cluster stays in a degraded state longer than it should, and the fix ends up being an emergency drive purchase under time pressure.
- Treating data reduction savings as guaranteed capacity. Compression ratios vary by workload, sometimes significantly. Planning against an assumed ratio means planning against a number that moves every time the workload mix changes.
- Disk group failure on OSA clusters sized around drive-level assumptions. A single cache device failure takes the entire disk group offline, not the one drive. Teams that sized their failure domain around individual drives are surprised by the actual blast radius the first time it happens.
This is what a capacity problem actually looks like from the inside
Our case study on resolving persistent vSAN performance issues without hardware replacement covers a cluster where application owners reported ongoing slowness that looked, on the surface, like a hardware problem. It was a capacity and configuration issue that had been building for months before anyone noticed the pattern. That is the common thread across most of these incidents: a capacity problem rarely announces itself as a capacity problem. It shows up as slow VMs, and the root cause takes someone who can read the storage layer, the hypervisor layer, and the application layer together.
Maven diagnoses these cross-layer issues directly, without routing a capacity problem through a hardware replacement cycle it does not need. Learn more on our Hyperconverged Infrastructure (HCI) Recovery and Support page, or contact us to talk through a specific vSAN sizing or performance question.
FAQ: VxRail vSAN Storage and Capacity
How much usable capacity does a VxRail vSAN cluster actually provide?
Usable capacity depends on the storage policy and the slack space reservation. A cluster on FTT=1 RAID-1 retains about half its raw capacity after mirroring, and FTT=1 RAID-5 in a 4+1 layout retains about 80 percent. Subtracting the 25 to 30 percent slack space VMware recommends, a realistic planning figure lands between 35 and 60 percent of raw capacity depending on the policy chosen.
What is the difference between vSAN OSA and vSAN ESA?
OSA is the original two-tier architecture, organizing drives into disk groups with a cache device and capacity devices. ESA, introduced in vSAN 8, is single-tier and all-NVMe with no disk groups. It requires hardware meeting the vSAN ReadyNode floor for ESA, and it delivers RAID-5 and RAID-6 performance close to RAID-1, which OSA could not do. There is no in-place upgrade from OSA to ESA, but OSA hosts that already meet the hardware floor can move to an ESA cluster once their drives are wiped, which is a migration project rather than a hardware refresh in every case.
Does vSAN support deduplication and compression?
Compression is supported on both. Deduplication is supported on vSAN OSA as a cluster-wide setting applied per disk group. On vSAN ESA, cluster-level deduplication did not exist under vSphere 8. It arrived in vSAN for VCF 9.0 as a limited-availability feature restricted to single-site clusters of 3 to 16 hosts on 25GbE or faster, without support for data-at-rest encryption. It went generally available in vSAN for VCF 9.1, supporting clusters of 3 to 64 hosts and working alongside encryption without losing data reduction ratios.
Is data encrypted on VxRail vSAN?
vSAN supports both data-at-rest and data-in-transit encryption. On VxRail 8.0.300 and later, encryption can be enabled during initial cluster deployment or turned on and off afterward as a day two operation. Encrypting at the vSAN layer preserves data reduction savings. Encrypting at the virtual machine layer does not, because the data reaches storage already encrypted.
How much free space does vSAN need?
VMware recommends keeping 25 to 30 percent of the vSAN datastore free. That space is used for rebuilds after a failure, resync operations, and storage policy changes. vSAN 7.0 and later track much of this automatically through the operations reserve and host rebuild reserve settings. Running well under the recommended threshold puts that safety margin at risk and can make policy operations unreliable during a host failure, which is exactly when the cluster most needs them to work.
Can vSAN replace a traditional SAN array?
It depends on refresh timing and workload rather than a blanket yes or no. vSAN is a strong fit for most virtualized enterprise workloads, and ESA closed much of the historical performance gap with dedicated arrays. But a large share of production environments run well on platforms like Unity XT, PowerStore, Compellent, VNX, 3PAR, Nimble, and NetApp FAS, often well past the point a straight refresh calendar would suggest replacing them, and workloads needing very high sequential throughput or bare-metal storage access are still better served by a dedicated array in many cases. The right call depends on where a given array sits in its lifecycle and what the workload actually needs, not on which architecture is newer.
Sizing a VxRail vSAN cluster, or troubleshooting one that’s already tight on space?
Maven’s engineers work directly with organizations validating vSAN capacity plans and diagnosing storage performance issues that hardware replacement alone will not fix. Contact Maven IT Solutions to talk through your cluster’s specific storage picture.
