VMware Licensing in Disaster Recovery

Disaster recovery is one of the areas where VMware customers have historically taken pragmatic positions on licensing — running DR hosts cold or warm without full production licensing, using third-party replication tools that minimised licensed VMware footprint at the DR site, and treating recovery as something to license fully only if it became routine. Under Broadcom's subscription model, those positions are harder to defend. The audit teams have been explicit that DR deployments are within scope, and the discovery techniques that surface DR usage have improved. This article walks through DR licensing in the current Broadcom environment.

The fundamental principle

VMware's licensing terms — historically and under Broadcom — have always treated installed software as licensed. The principle is that if the software is installed on a host, the host requires a licence appropriate to that software, regardless of whether the host is actively running production workloads. Cold, warm, and hot DR hosts all carry installed VMware software and therefore all require licences.

The "DR exception" that some customers have relied on historically was largely a matter of audit-team discretion rather than contract. When VMware was the licensor, and audits were less aggressive, DR hosts were sometimes overlooked or licensed at reduced cost as part of broader negotiations. Under Broadcom, that discretionary tolerance has narrowed substantially.

What counts as DR for licensing purposes

Several deployment patterns get described as "DR," with different licensing implications:

Cold DR — installed but powered off. Hosts have VMware installed but are powered off until a DR event. The installed software is technically still licensed; powering off does not eliminate the licence requirement.

Warm DR — running, not handling workload. Hosts are powered on and running VMware, but no production workloads are scheduled to them outside DR events. The licence is unambiguously required.

Hot DR — replicated workloads ready to run. Hosts are running, and replicated workloads are present (either in storage or in suspended/standby state). Licence is required and at appropriate edition for the running components.

Active-active across sites. Both sites run workloads in steady state, with capacity reserved at each for the other's failover. This is not DR in the traditional sense — both sites are production and require production licensing.

Cloud-based DR. The DR site is a cloud provider (AWS, Azure, GCP, OCI) running VMware via the provider's offering. The licensing model is provider-specific and typically subscription/consumption based.

SRM and replication licensing

Site Recovery Manager (SRM) and vSphere Replication have their own licensing structure. SRM is licensed per protected VM. vSphere Replication has tiers tied to the protected scope. These are additive to the underlying vSphere licensing at both source and target sites.

The audit-discovery method for SRM is the SRM configuration itself — protection groups, recovery plans, protected VM counts. Broadcom's data requests routinely include SRM exports. The customer's licence inventory must cover the protected VM count, not just a subset.

For vSphere Replication, the discovery is in the replication configuration and the replicated VM inventory. Customers using vSphere Replication outside of SRM (just for replication without orchestrated recovery) still need the appropriate vSphere Replication entitlement.

Third-party replication and the licensing implication

Many customers use third-party replication tools — Zerto, Veeam, Commvault, Dell RecoverPoint, NetApp SnapMirror — to handle workload replication without using VMware-native tools. The argument has historically been that if the replication is not VMware's, the DR target's VMware licensing requirement should be limited to what's actually running on the target.

Broadcom's position is that the target host's installed VMware still requires a licence. The third-party replication tool replicates the workload to the DR storage; when failover occurs, the target host runs the recovered VMs on its installed VMware. The licensing requirement attaches to the installed software, not the replication mechanism.

For customers, the practical implication is that third-party replication does not reduce the DR site's VMware licensing requirement. It may reduce the SRM or vSphere Replication requirement (since those are not in use), but the base vSphere licensing at the DR site remains.

Cold standby and licensing

Cold standby — hosts that are powered off until needed — has historically been an area where customers minimised licence cost. Several positions have been argued over the years:

• "Cold hosts have no running workload, so no licence is needed." The licensing terms typically require licence on installed software, not running workload. Cold hosts with installed VMware are still licensed.
• "Cold hosts are emergency-only; the licence requirement is reduced." No contractual basis under current Broadcom terms; emergency use is still use.
• "We have a separate DR licence at reduced cost." Historic VMware "DR licence" programs existed under specific conditions; most have been deprecated. Validate against current Broadcom catalogue.

The defensible position under Broadcom is that cold standby hosts require full licensing of the installed vSphere edition and any other VMware components installed. Customers should plan capacity and budget accordingly.

The 72-hour rule and historical DR positions

Some customers have referenced a "72-hour rule" or similar limited-use exception, suggesting that DR hosts can be operated for short periods (during testing or actual DR events) without full licensing. This concept exists in some VMware product documentation in narrow contexts but is not a general DR exception.

Under Broadcom, customers should not rely on a 72-hour or similar exception unless they have specific contract language supporting it. The audit teams will not accept verbal or marketing-material references to historical exceptions. Contract language is the only durable basis.

Cloud DR — AWS, Azure, GCP, OCI

VMware Cloud on AWS, Azure VMware Solution, Google Cloud VMware Engine, and Oracle Cloud VMware Solution are positioned as natural DR targets. The licensing model for these is generally consumption-based — the customer pays the cloud provider for the underlying capacity, and the VMware licensing is included in the provider's pricing.

The audit-defence implication is favourable: cloud DR via a provider's VMware offering does not create the same kind of standalone licensing exposure as customer-deployed DR. The customer's exposure is to the cloud provider's billing, not to a VMware compliance claim.

The caveat: if the customer extends VMware Cloud Foundation or other VMware products from on-premises into the cloud target — for example, NSX federation between on-premises and cloud — those extensions may have additional licensing implications. The cloud provider's bundled VMware does not necessarily cover federation or extension scenarios.

Capacity planning and the DR-exposure trap

A common trap: the customer's production environment has, say, 20 hosts. The DR environment is sized to host the production workload during a failover, also 20 hosts. The customer holds VMware licences for the 20 production hosts but has been treating the 20 DR hosts as out-of-scope. Under Broadcom, the DR hosts require licensing at the same edition. The customer's actual VMware licensing requirement is 40 hosts, not 20.

This doubles the licensing footprint and the cost. For large enterprises, this is the single largest DR-related audit finding pattern. Mitigations:

• Right-size the DR environment — DR capacity does not need to match production capacity host-for-host; performance during DR can be at a lower level than production
• Use cloud-based DR for some workloads — shift from owned DR infrastructure to consumption-based cloud DR for the workloads that can tolerate it
• Negotiate a DR-specific licensing arrangement with Broadcom — sometimes available, particularly during renewal discussions, but not standard
• Reduce the DR scope — accept that not every production workload requires full DR, and re-tier accordingly

Audit-discovery techniques for DR

Broadcom's audit teams use several techniques to identify DR deployments:

vCenter inventory. If the DR site is managed by a separate vCenter, the customer is expected to include both vCenters in the audit response. If the DR site is managed by the same vCenter via linked mode, the DR hosts appear in the same inventory.

SRM configuration. SRM protection groups directly identify protected VMs and the recovery scope. SRM-using customers cannot easily hide the DR scope.

Storage replication configurations. Some audit data requests ask for storage replication configurations, which surface the DR target hosts even if vCenter inventory is incomplete.

Network topology. NSX and physical network configurations often show the DR site connectivity, indicating the existence and size of the DR estate.

Procurement records. Hardware purchase records cross-checked against host inventory can reveal DR hosts that are not in the customer's submitted vCenter inventory.

The customer's defence position must address the DR estate explicitly, with documented licensing for each DR host. Omitting the DR estate from the audit response is not a defensible strategy.

The role of SRM versus alternatives

SRM is the VMware-native DR orchestration product. It is well-integrated, well-instrumented, and well-discovered by audit. The alternatives — Zerto, Veeam Disaster Recovery, Commvault, and others — provide similar orchestration capabilities outside the VMware product set.

For licensing purposes, the choice of orchestration tool affects only the SRM/vSphere Replication entitlement, not the base vSphere licensing of the DR site. Customers should not choose third-party tools expecting them to reduce VMware licensing exposure; they reduce only the SRM/replication exposure.

That said, the operational case for third-party DR tools is real. Zerto, for example, has historically offered superior RPO/RTO for some workload classes. Commvault provides better integration with broader backup workflows. Veeam Disaster Recovery is well-suited to organisations already using Veeam Backup & Replication. These considerations matter independently of the licensing question.

Cloud DR economics

The shift to cloud-based DR (VMware Cloud on AWS, Azure VMware Solution, etc.) has been accelerated by Broadcom's pricing. Where on-premises DR requires full vSphere/vSAN/NSX licensing across DR hosts, cloud DR consumes provider capacity only during testing or actual DR events. For workloads with low failover probability, the consumption model is materially cheaper.

The economics flip for workloads with high failover frequency or for workloads requiring continuous DR availability. The cloud consumption model becomes expensive at scale. The choice between owned DR and cloud DR depends on the specific workload profile, the RTO/RPO requirements, and the failover frequency expectations.

Planning recommendations

Inventory the DR estate explicitly

Treat the DR site as a first-class component of the VMware estate. Maintain host counts, licensed editions, and entitlement coverage records that include DR. Do not allow DR to be a footnote in the inventory.

Document the DR licensing position

For each DR host, document the licensing rationale — which entitlement covers it, what edition, what scope. If the customer is relying on a contract-specific DR provision, capture the contract language and the date.

Plan for DR within renewal cycles

DR licensing requirements should be part of every renewal discussion. Subscription renewals that don't address DR scope explicitly leave the DR exposure unresolved.

Consider DR re-architecture

If the DR footprint is large, the licensing cost may justify re-architecting toward cloud DR, scope reduction, or alternative DR strategies. Run the numbers; the right answer may not be the historical answer.

Frequently asked questions

Do cold DR hosts require VMware licensing?

Yes, in the general case. The licensing requirement attaches to installed software, regardless of whether the host is powered on.

Can we use a "DR licence" at reduced cost?

Some historical VMware DR licensing programs existed; most are not available under current Broadcom terms. Verify against the current catalogue and against your specific contract.

Does using Zerto or Veeam reduce our vSphere DR licensing requirement?

No. Third-party replication tools reduce or eliminate the SRM/vSphere Replication entitlement requirement but do not change the underlying vSphere licensing of the DR site hosts.

How is the DR site discovered in audit?

Through vCenter inventory, SRM configurations, storage replication configurations, network topology, and procurement records. The DR estate is discoverable; concealment is not a defensible strategy.

What about active-active deployments?

Active-active is not DR for licensing purposes — both sites are production and require full production licensing.

Is cloud-based DR (VMware Cloud on AWS, etc.) a way to reduce DR licensing exposure?

Yes, in many cases. Cloud DR shifts the licensing to the cloud provider's consumption-based model, eliminating the standalone DR-host licensing requirement. The economics depend on failover frequency and workload profile.