vSAN. Where capacity becomes claim.

vSAN moved to a per-TiB capacity model and was repackaged into vSphere Foundation and VMware Cloud Foundation under Broadcom. Hyper-converged customers now carry a different compliance shape than they did at the time they bought. We defend, assess, and negotiate the vSAN estate.

How vSAN licensing changed.

The historical vSAN entitlement was per-CPU, with editions for Standard, Advanced, and Enterprise covering progressively richer feature sets. Under Broadcom, vSAN is sold per-TiB of raw or usable capacity (with the precise definition varying by entitlement vintage) and bundled into VVF (8 TiB per core entitlement) and VCF (1 TiB per core entitlement). vSAN Express Storage Architecture (ESA) is the strategic platform — vSAN OSA remains supported but is no longer the forward product.

For customers that grew capacity quickly between renewals, the per-TiB conversion can produce a meaningful uplift versus the original per-CPU entitlement.

What auditors look for first.

An auditor on a vSAN engagement will ask for vSAN cluster inventories, configured capacity per cluster, deduplication and compression ratios, ESA-vs-OSA breakdown, stretched-cluster and witness-host configurations, and the disk-group composition across all storage nodes.

The contested ground is usually capacity measurement — what counts as "licensed capacity" and how raw, usable, and effective capacity are treated under the specific entitlement on the buyer's contract.

Three vSAN audit traps.

Raw vs usable capacity dispute

Auditors default to raw configured capacity. Contract language often supports usable or effective capacity. A clean reading of the entitlement clause typically reduces the licensable TiB number materially.

VVF / VCF bundle entitlement

Where the customer has VVF or VCF subscriptions, the included vSAN capacity per core often already covers most or all of the deployment. Bundle credit is frequently understated in initial audit calculations.

Stretched-cluster double-count

Stretched cluster capacity, witness appliance footprint, and HA-replica capacity can be double-counted in raw measurements. The audit framework rarely accounts for this without the buyer making the argument.

Defences we use in vSAN engagements.

Below are the contractual and technical levers that recur in vSAN audit defence. The mix depends on the entitlement vintage and the specific deployment architecture.

Per-CPU vs per-TiB entitlement preservation under master agreement

Raw vs usable vs effective capacity definition

VVF and VCF bundle credit reconciliation

Stretched-cluster and witness host exclusion

HA-replica and FTT capacity treatment

Edition feature usage challenge (Advanced vs Enterprise)

ESA-vs-OSA entitlement applicability

Reserved-capacity vs consumed-capacity measurement

Decommissioned disk group evidence

Disaster recovery and standby exemption claims

Lab, test, and development capacity treatment

Affiliate, subsidiary, and divested-entity scope

Public cloud BYOL vSAN treatment

Patch and upgrade telemetry interpretation disputes

Capacity-spike methodology under audit period

Bundle proration on partial-year usage

Where the savings tend to land

In documented vSAN engagements the largest reductions usually come from VVF / VCF bundle credit reconciliation — the audit calculation often understates how much vSAN capacity is already included in the customer's subscription. The second largest comes from raw-vs-usable capacity disputes. The third comes from stretched-cluster and witness exclusions. As with vSphere, most reductions are won inside the methodology rather than by challenging the right to audit.

vSAN licensing questions.

Should we move from vSAN OSA to ESA?

vSAN ESA is the forward platform and is required for some VVF and VCF feature sets. The migration has performance, hardware, and licensing implications. For most enterprise estates, ESA is the right destination but should be sequenced with vSphere upgrade cycles and renewal events.

What counts as "capacity" for licensing?

The definition depends on the specific entitlement and contract version. Some entitlements reference raw configured capacity; some reference usable capacity post-overhead. The contractual definition is contestable in audit and is one of the most valuable defences to establish early.

Does VVF or VCF really cover our vSAN footprint?

Often more of it than initial Broadcom calculations show. VVF includes 8 TiB per core. VCF includes 1 TiB per core. For most consolidated hosts the entitlement covers a substantial share of deployed capacity. Bundle credit reconciliation is one of the first items on our engagement checklist.

Can we keep running vSAN without renewing support?

Existing perpetual entitlements remain valid for the licensed scope. Loss of support means no patches, no new versions, and no entitlement to ESA migration. The compliance position does not change with support lapse, but the operational and security posture does.

Will the auditor look at vSAN separately from vSphere?

vSAN is almost always scoped together with vSphere because cluster inventory drives both calculations. We routinely negotiate a single co-ordinated defence across vSphere, vSAN, and NSX to prevent double-counting and inconsistent methodology between products.

vSAN. Where capacity becomes claim.

How vSAN licensing changed.

What auditors look for first.

Three vSAN audit traps.

Defences we use in vSAN engagements.

Where the savings tend to land

vSAN licensing questions.

vSAN claim landed?
The methodology is contestable.

vSAN. Where capacity becomes claim.

How vSAN licensing changed.

What auditors look for first.

Three vSAN audit traps.

Defences we use in vSAN engagements.

Where the savings tend to land

vSAN licensing questions.

vSAN claim landed?The methodology is contestable.

vSAN claim landed?
The methodology is contestable.