VMware License Assignment Rules

VMware licence assignment is one of the most misunderstood areas of Broadcom compliance. Customers often assume that purchasing a licence and installing the key on a host completes the assignment obligation. In reality, assignment under post-acquisition Broadcom terms is governed by a defined set of contractual and technical rules — rules that determine which deployments are covered, which features are entitled, and how aggregation across hosts and clusters is permitted. Misapplied assignment produces exposure even when the customer has, in aggregate, purchased sufficient entitlement.

This article sets out the assignment rules that govern VMware licensing under Broadcom: the metric-by-metric rules for per-CPU, per-core, per-user, and capacity-based products; the cluster-level aggregation rules for VCF; the entity-and-scope rules that constrain assignment across legal entities; and the assignment patterns that recur as audit findings.

The principle: assignment is not just installation

Installation places a licence key on a host. Assignment is the contractual act that commits that licence to a specific deployment, in compliance with the contract terms. Broadcom audit findings frequently turn on the gap between the two: a licence installed on a host where the contract terms do not permit assignment, or features in use that exceed what the assigned licence entitles, or cluster aggregation that the assignment terms do not support.

The customer's assignment posture is what is audited — not the inventory of keys, not the installation footprint, but the question of whether each deployed instance has appropriate, contractually valid assignment of an entitled licence.

Per-CPU and per-core assignment

Pre-acquisition VMware licensed primarily per CPU socket; post-acquisition Broadcom has moved most products to per-core licensing with a 16-core-per-CPU minimum. Assignment rules differ materially between the two metrics.

Per-CPU assignment

Under per-CPU terms (still present in legacy perpetual deployments), each physical CPU socket in the host requires its own assigned licence. A two-socket host requires two per-CPU licences regardless of core count per CPU. Assignment is at the host level; licences cannot be split across hosts or pooled across clusters.

Per-core assignment

Under post-acquisition per-core terms, each physical core in the host requires its own assigned licence, with the 16-core-per-CPU minimum. A two-socket host with two 12-core CPUs requires 2 × max(12, 16) = 32 core licences. A two-socket host with two 32-core CPUs requires 2 × 32 = 64 core licences. The minimum-core uplift catches customers running sub-16-core CPUs; the linear scaling catches customers running high-core-count CPUs.

Common per-core assignment errors

• Counting cores without minimum-core uplift. Hosts with 8-core CPUs are routinely licensed for 8 cores when the contract requires 16. The exposure is doubled the visible deployment.
• Counting cores without applying edition multipliers. Some editions (VCF in particular) have specific multiplier rules for the workload-domain licensing model.
• Counting active cores instead of physical cores. Hyper-threading is irrelevant; logical processors are not the licensing unit. Disabling cores in BIOS may be a remediation option in some scenarios but does not reduce the licensing requirement automatically.

Per-user assignment

Horizon and certain other VMware products use per-user metrics. Assignment rules:

• Named-user assignment: each entitled user is identified by name in the Horizon directory. Active or inactive status does not change the assignment obligation while the user remains in the entitled population.
• Concurrent-user assignment: licences cover concurrent sessions up to a defined limit. Concurrent licensing requires session-monitoring to ensure peak concurrent use does not exceed entitlement.
• User pool management: shifting users between pools, removing inactive users, and reassigning licences must be operationally managed; the assignment is not automatic.

Common per-user assignment errors

• Inactive users counted as assigned. Departed employees, role-changed users, and dormant accounts continue to consume entitlement until actively removed.
• Test and admin users counted against production entitlement. Where contracts distinguish production and test user populations, mixed-use can produce exposure.
• Concurrent-licence over-consumption. Peak-usage spikes can exceed the entitled concurrent count; ongoing monitoring is required.

VCF cluster-level assignment

VMware Cloud Foundation introduces a cluster-level assignment model that aggregates vSphere, vSAN, and NSX consumption. Assignment rules:

• Workload-domain licensing: VCF licences are assigned to workload domains, not individual hosts. Domain composition determines the licensing requirement.
• Component aggregation: vSphere, vSAN, and NSX consumption are aggregated at the workload-domain level for VCF assignment; per-product reconciliation does not produce the VCF-aligned view.
• Domain expansion: adding hosts to a workload domain expands the entitlement requirement at the domain level; assignment must be updated correspondingly.
• Domain compaction: removing hosts from a workload domain reduces the requirement, but the assignment must be actively reduced rather than passively assumed to follow.

Common VCF assignment errors

• Per-product assignment treated as VCF assignment. Customers with vSphere, vSAN, and NSX entitlements separately may believe they have VCF coverage; they do not. VCF assignment is a distinct contractual category.
• Cluster aggregation not maintained. Cluster composition changes over time; if VCF assignment is not actively maintained, it drifts out of alignment with deployment.
• Mixed-product clusters. Some clusters mix VCF-assigned and per-product-assigned hosts; the mixing rules are restrictive and routinely violated.

Entity-and-scope assignment

VMware contracts typically scope assignment to the original contracting entity and named subsidiaries or affiliates. Assignment rules:

• Contracting entity: assignment is permitted to deployments operated by the named contracting entity.
• Named affiliates: assignment may extend to specifically named affiliates or subsidiaries, often subject to ownership thresholds (50% or more, depending on contract).
• Acquired entities: deployments in entities acquired after the contract date are typically not within scope unless scope-expansion has been negotiated.
• Divested entities: deployments in entities divested from the contracting group typically require transition of the assignment to the divested entity's own contract, with associated commercial consequences.
• Partner and managed-services: assignment to deployments operated by partners, MSPs, or contractors is typically subject to specific contractual permission and may be restricted to the customer's own operations.

Common scope-assignment errors

• Post-merger deployment without scope expansion. The single most common scope finding. Acquired-entity deployment using the parent company's contract entitlement, without contractual scope expansion.
• Geographic expansion. Deployment in jurisdictions outside contractual scope, particularly in international expansions.
• Partner deployment treated as customer deployment. Partner-managed environments using customer entitlement without contractual permission.

Edition-assignment rules

Edition-tier assignment is governed by the features actively configured and consumed on the assigned hosts. The principle: the assigned edition must support the features in use, not just the features installed but inactive.

• Feature activation: edition-gated features that are configured and active on a host require edition tier sufficient to entitle them. DRS on a Standard-assigned host is a finding even if the cluster is small.
• Feature deactivation: features can be deactivated, but the deactivation must be operationally complete; partial deactivation does not reduce the entitlement requirement.
• Edition mixing: some contracts permit mixed-edition clusters under defined rules; others do not. Mixing rules should be reviewed contract-by-contract.

Use-case assignment

Some VMware contracts distinguish between production, non-production, development, and DR use. Assignment rules:

• Production assignment: production licences entitle production workloads; production-assigned licences should not be re-assigned to non-production use without contractual permission.
• Non-production discounting: contracts may offer reduced pricing for clearly non-production environments, with restrictions on production use.
• DR assignment: DR-only entitlement (where contractually defined) is typically restricted to passive DR; active DR or production use triggers different entitlement.
• Development and test: dev/test entitlement is often discounted but restricted to dev/test use; production use of dev/test entitlement is a finding.

Re-assignment and reassignment frequency

Licences can typically be reassigned between hosts and clusters, but reassignment is governed by specific rules:

• Reassignment frequency: some contracts limit reassignment frequency (typically not more than once per 90 days for an individual licence), to prevent licence-hopping that effectively doubles use.
• Reassignment documentation: reassignment should be documented in the entitlement records, with the date and the source-and-destination assignment.
• Reassignment after retirement: licences from retired hosts can be reassigned to new hosts, but the retirement should be operationally complete.

Free ESXi and unlicensed deployment

Free ESXi historically allowed unlicensed deployment of basic ESXi functionality. Post-2024 Broadcom retired the free distribution; existing free-ESXi instances became out of compliance unless converted or removed. Assignment rules for the legacy free instances:

• Existing free-ESXi instances should be inventoried and dispositioned (convert to entitled, decommission, or document exception).
• Any free-ESXi deployment continuing after the retirement date without conversion is exposure.
• Customers with material free-ESXi populations should expect this to be a focus area in audit cycles for the next 2-3 years.

Operating discipline for assignment

Strong assignment posture requires operational discipline:

Assignment register

Maintain a register that records, for each entitled licence, the current assignment: host, cluster, workload domain, entity, use case. The register should be the source of truth for assignment status and should be updated through change control.

Change control

Assignment changes — new deployment, reassignment, retirement — should be routed through a change-control procedure that updates the register at the point of change.

Periodic reconciliation

Reconcile the assignment register against the deployment discovery output at the same cadence as the broader compliance reconciliation. Discrepancies should trigger investigation and remediation.

Edition-tier verification

Periodically verify that edition tier assigned matches edition tier required by features in use. Aria Operations dashboards and custom scripts can produce the verification data.

Final word

Licence assignment is the operational discipline that converts purchased entitlement into compliant deployment. The rules vary across metrics, products, and contract terms, and the assignment patterns that satisfy the rules require deliberate management. Customers who treat assignment as automatic produce assignment that is routinely non-compliant; customers who treat it as an operational discipline produce assignment that holds up under audit scrutiny. The investment in disciplined assignment is modest; the exposure reduction across audit cycles is substantial.

VMware licence assignment — frequently asked questions

What is the difference between installation and assignment?

Installation places a licence key on a host. Assignment is the contractual act that commits that licence to a specific deployment in compliance with the contract terms. Audit findings frequently turn on the gap between the two.

How does per-core assignment work under Broadcom subscription terms?

Each physical core requires its own assigned licence, with the 16-core-per-CPU minimum. A two-socket host with two 8-core CPUs licenses as 32 cores, not 16. A two-socket host with two 32-core CPUs licenses as 64 cores.

How is VCF assignment different from per-product assignment?

VCF assigns at the workload-domain level, aggregating vSphere, vSAN, and NSX consumption. Per-product assignment does not produce VCF-equivalent coverage. The two are distinct contractual categories.

Can licences be reassigned between hosts?

Typically yes, subject to contract terms. Some contracts limit reassignment frequency (typically not more than once per 90 days) to prevent licence-hopping. Reassignment should be documented in the entitlement records.

What is the most common assignment error?

Edition mismatch: features in use exceeding the assigned edition tier. DRS on Standard-assigned hosts is the textbook example. Feature use is what determines the required edition, not just feature installation.

How do we handle post-merger entity assignment?

Deployments in acquired entities require scope expansion in the contract; using the parent's entitlement without scope expansion is exposure. Plan scope expansion as part of M&A integration, ideally before deployment expansion occurs.

What about partner-managed deployments?

Assignment to partner-managed environments using customer entitlement is typically subject to specific contractual permission. Review contracts carefully; many do not permit partner deployment without specific terms.

How should we manage Horizon user assignment?

Maintain an actively curated user population: remove departed users, manage inactive accounts, monitor concurrent use against entitled concurrent count. Drift between entitled and active populations is a routine finding driver.

What is the assignment exposure from historical free-ESXi deployments?

Material. Post-2024 free-ESXi retirement means existing free-ESXi deployments are exposure unless converted or removed. Inventory all free-ESXi instances, document disposition, and expect this to be an audit focus for several years.

How do we document assignment for audit purposes?

Maintain an assignment register that records, for each entitled licence, the current assignment: host, cluster, workload domain, entity, use case. Update through change control, reconcile periodically against deployment discovery, and retain historical assignment records for the audit look-back period.