vSAN ESA vs OSA: hardware requirements, data services, licensing in 9.x and the move to ESA

vSAN ESA vs OSA, feature by feature

vSAN Express Storage Architecture (ESA), introduced with vSAN 8, is a single-tier design: the NVMe devices of a host form one storage pool, and each adds capacity and performance. vSAN Original Storage Architecture (OSA) builds disk groups, each with one flash cache device in front of capacity devices, in all-flash or hybrid form. Broadcom’s vSAN design guide for 9.1 (5 May 2026) recommends ESA for new clusters from vSAN 9 and keeps all-flash OSA “for brownfield cluster expansion”. The licence is the same for both, counted on the raw capacity vSAN claims, and an OSA cluster cannot be converted to ESA in place.

Broadcom TechDocs for vSAN 8.0, VCF 9.0 and 9.1 (August to October 2026), vSAN 8.0 Update 3 guides (July 2024), vSAN design guide (5 May 2026), space efficiency paper (11 May 2026), VCF blog (7 May 2026), vSAN FAQ (30 September 2026).

OSA disk groups and cache tier vs the ESA storage pool

In OSA, each disk group pairs one flash cache device with one to seven capacity devices, and a host can have up to five. Per the vSAN 8.0 Update 3 planning guide, “vSAN uses the cache layer for write caching only” in all-flash configurations, and if a cache device fails or is removed, vSAN recovers the components of the entire disk group. Since vSAN 8.0 the write buffer can reach 1.6 TB, up from 600 GB, on cache devices of 1.6 TB or more (KB 326411).

ESA has neither disk groups nor a cache tier. Writes go first to a mirrored log in the log-structured file system (vSAN LFS), which later writes large full stripes as RAID-5 or RAID-6 without a parity read-modify-write, as VMware’s product blog explained in September 2022. Compression, encryption and checksums run near the top of the storage stack, so later processing and the network handle compressed data, per Broadcom’s space efficiency paper. For snapshots, OSA’s SparseSE system “requires IO to merge on snapshot deletion”, Broadcom’s design guide says, while in ESA a base disk and its snapshots form one vSAN object.

vSAN ESA hardware requirements and ReadyNode profiles

The vSAN requirements for VCF 9.1, updated on 5 October 2026, ask an ESA host for at least one NVMe TLC device and 128 GB of memory. For the network they set “10 GbEs minimum, recommended 25GbEs or higher”. Every capacity device, driver and firmware version must be listed in the vSAN section of the Broadcom Compatibility Guide. The 8.0 Update 3 planning guide of July 2024 had asked for four NVMe devices, 512 GB and 25 GbE. Broadcom’s current pages for vSAN 8.0 and VCF 9.0, updated in August and September 2026, set the same floor as 9.1. Above that floor, Broadcom sizes ESA hosts by ReadyNode profile, and its design guide asks for 100 Gbps on hosts with 200 TB or more.

Broadcom vSAN design guide for 9.1 (5 May 2026), values per host; vSAN-HCI-SM was formerly ESA-0.

Hosts are ESA ReadyNodes bought under one SKU or ReadyNode Emulated configurations, “built using the same OEM server hardware”, as Broadcom’s FAQ puts it. KB 326717 allows changes within rules: drives from the ESA ReadyNode bill of materials, another drive model only from the same server OEM, at least 1.6 TB and 1 DWPD per device, and it advises against mixing endurance levels. SAS and SATA devices are not supported with ESA, and Broadcom’s FAQ explains that ReadyNodes with Intel processors older than Ice Lake have an older PCIe generation and too few PCIe lanes. Whether a host runs ESX 9 at all is in our ESX 9 hardware requirements guide.

Compression, deduplication and erasure coding in OSA and ESA

OSA deduplicates and compresses only on all-flash disk groups, set cluster-wide and applied per disk group, while compression-only works per disk (8.0 Update 3 administration guide). ESA compresses per object, and Broadcom’s space efficiency paper of 11 May 2026 describes 9.1 compression as a cluster-based feature “enabled by default” that “cannot be turned off in the UI”. Global deduplication, a limited release for ESA in 9.0, is generally available from 9.1. It runs post-process and cluster-wide, on vSAN HCI and storage clusters of 3 to 64 hosts and, for now, not on stretched or two-node clusters.

OSA runs RAID-5 from four fault domains and RAID-6 from six, all-flash only, so a three-host OSA cluster can only mirror. ESA places RAID-5 as 2+1 on fewer than six hosts and as 4+1 from six. With Auto-RAID in 9.1, RAID-5 is used only on 3 to 5 hosts, always as 2+1. Clusters of six or more hosts get RAID-6 4+2. The factors below are raw capacity per unit of VM data, before compression and deduplication.

vSAN 8.0 administration documentation (133 GB for a 100 GB object with RAID 5 at FTT=1); vSAN design guide (5 May 2026); space efficiency paper (11 May 2026).

vSAN 9.0 and 9.1: OSA support, hybrid deprecation and storage clusters

Asked whether OSA is going away, Broadcom’s vSAN FAQ of 30 September 2026 answers “No, not in the foreseeable future”, adding that hybrid OSA was deprecated in the VCF 9.0 release notes and that all-flash OSA clusters remain supported.

vSAN storage clusters, previously named vSAN Max, are ESA clusters that serve storage to other clusters. Broadcom’s guidance of 5 May 2026 asks for at least 4 hosts in a single-site storage cluster, with at least 25 GbE between them. Clients can be ESA HCI, compute-only or, from 9.1, OSA clusters, and they can mount the datastore with as little as 10 GbE. Stretched clusters and witnesses are covered in our vSAN stretched cluster guide.

vSAN licensing in 9.x: TiB per core and add-on capacity

For OSA and ESA alike, Broadcom’s programme documents of June 2026 entitle each VVF core to 0.25 TiB of vSAN capacity and each VCF core to 1 TiB, and each entitlement “can only be aggregated and utilized across Cores” of its own product. KB 313548, “Counting Cores for VMware Cloud Foundation and vSphere Foundation and TiBs for vSAN”, rounds the VVF figure up to the next TiB. Beyond that, the vSAN add-on is sold per TiB; its programme document of May 2026 sets what counts: “Customer must license all raw physical storage that is claimed by Software on all the Servers in the vSAN Cluster.” We found no Broadcom document that leaves the cache devices of OSA disk groups out of that count.

In 9.0, per its release notes updated on 29 September 2026, you assign the VMware vSAN licence to a vCenter instance in VCF Operations, after its VCF or VVF licence, and every vSAN cluster in that vCenter is then licensed. Under the 9.1 licensing documentation of 1 October 2026, components added to a licensed vCenter instance “are automatically licensed”, and vSAN capacity from VCF, VVF and add-ons pools into one default licence. In Broadcom’s example, 300 VCF cores and a 50 TiB add-on make one vSAN licence of 350 TiB. Our VVF vs VCF comparison explains how that pool fits the per-product rule; our core count guide covers the KB script that reports raw TiB per cluster.

For licensing, ESA and OSA differ in the raw capacity the same data needs. Take three hosts with two 16-core CPUs each, 96 licensed cores by the rules in our core licensing guide. They bring 24 TiB of vSAN under VVF and 96 TiB under VCF. To hold 30 TiB of VM data at FTT=1, OSA needs at least 60 TiB of raw capacity, because it can only mirror on three hosts. ESA with RAID-5 2+1 needs 45 TiB, in both cases before spare capacity and data reduction. Under VVF that is at least 36 TiB of add-on capacity for OSA and 21 TiB for ESA; under VCF neither needs an add-on. The arithmetic is ours, on Broadcom’s published rules. On four or five hosts the result is reversed, since OSA’s RAID-5 needs 1.33 times the data against 1.5 times for ESA’s 2+1; from six hosts, at FTT=2, both need 1.5 times.

Our VMware optimisation service audits the estate and its licences, so you see the numbers before you sign the renewal. Send us the raw capacity of each vSAN cluster through the form below, with the cores licensed for VVF or VCF.

Migrating from vSAN OSA to ESA

There is no in-place conversion. Broadcom’s KB 405623 says an OSA cluster cannot be upgraded to ESA with the vSphere Client or the Ruby vSphere Console. KB 432894, for vSAN 8.0 to 9.1, gives the reason: OSA and ESA “use fundamentally different on-disk formats and data paths”. An in-place upgrade to vSAN 8, Broadcom’s FAQ adds, leaves a cluster on OSA.

KB 432894 describes two routes. On the side-by-side route you build a new ESA cluster on hardware listed for ESA, move the VMs with Storage vMotion and decommission the OSA cluster once all workloads are migrated and verified. The old hosts can then run as a compute-only cluster, a use Broadcom’s design guide names for “older hardware that may not be suitable for vSAN, or VSAN ESA”. Until the OSA cluster is decommissioned, vSAN claims the raw capacity of both clusters, and the vSAN programme document requires all of it to be licensed. On the second route you rebuild the existing hosts, where they meet the ESA requirements above, in this order:

1. Migrate all VMs to a different cluster and datastore with vMotion.
2. Put each host into maintenance mode with No Data Migration.
3. Delete the OSA disk groups and wipe every device of its previous partitions and metadata.
4. Move the host to the data centre level of the vCenter inventory, then into the ESA cluster, and claim its devices for the ESA storage pool.

Since 9.1 an OSA cluster can also mount the datastore of an ESA storage cluster or ESA HCI cluster, so new VM storage can go to ESA while the OSA hosts keep running compute.

Cross-cluster migrations in agreed maintenance windows, with a rollback plan at every stage, are part of our VMware optimisation service. Describe your OSA clusters in the form below, with hosts, device models and vSAN version.

When to keep OSA and when to plan ESA

By our reading of Broadcom’s documents, all-flash OSA on hosts with SAS or SATA devices or pre-Ice Lake Intel processors can stay until the hardware is replaced, since ESA cannot use those hosts as they stand and OSA remains supported. Such hosts still need a supported ESX release, and Broadcom’s KB 318697 discontinues Broadwell Xeons for 9.x and deprecates Cascade Lake. Hybrid clusters come first in the plan, as hybrid OSA is deprecated. A hardware refresh is the point to move, because Broadcom recommends ESA for new clusters and three-host clusters gain RAID-5 in place of mirroring.

What we do

Eurokommerz holds the contract and supplies the hardware under the solution, with EU invoicing, delivery and warranty under European law; engineering is by our partner Vixen.UNO. Under VMware optimisation, Vixen.UNO audits the estate and its licences, matches editions and subscriptions to your actual workloads within Broadcom’s current licensing logic, and modernises vSphere, vSAN, NSX and VCF, cross-cluster migrations included. Changes 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; 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