Oracle Licensing on VMware and Broadcom: Risks, Rules, and Migration Strategies

Oracle's Uncompromising Position on VMware

Oracle's stance on VMware and all hypervisor-based virtualisation has not changed, regardless of who owns VMware. Oracle classifies all versions of VMware ESXi — including vSphere Foundation, vSphere Standard, Cloud Foundation, and every legacy edition — as soft partitioning. Under Oracle's partitioning policy, soft partitioning technologies cannot be used to limit the Oracle licence count to a subset of the physical server.

The practical consequence is severe: if an Oracle database VM can migrate to any host in a VMware cluster — even theoretically — Oracle requires you to licence every physical core on every host in that cluster. Not the vCPUs assigned to the VM. Not the cores on the specific host where the VM is currently running. Every core, every host, in the entire cluster.

This is not a new policy, but it has become exponentially more relevant as Broadcom's acquisition has driven VMware subscription prices sharply higher. Organisations that previously absorbed the Oracle licensing exposure because VMware infrastructure costs were manageable now face a double penalty: dramatically increased VMware costs and unchanged Oracle licensing requirements that may be far larger than previously calculated.

Understanding the Soft Partitioning Rule in Practice

To understand the scale of Oracle's soft partitioning exposure, consider a representative enterprise scenario: a VMware cluster with eight hosts, each with two Intel processors containing 16 cores per processor. That is 256 physical cores across the cluster, or 128 Oracle processor licences at the 0.5 Intel core factor.

If you run a single Oracle Database Enterprise Edition VM on that cluster — even if the VM has only 4 vCPUs — Oracle's position is that you require 128 processor licences, valued at approximately $6 million at list price. Plus 22% annual support, increasing at 8% per year. The same VM on a dedicated, hard-partitioned physical server with 16 cores would require just 8 processor licences — a 16:1 difference in cost exposure.

A common misconception is that pinning a VMware VM to specific hosts using affinity rules or DRS exemptions satisfies Oracle's hard partitioning requirements. It does not. VMware's DRS rules are software-defined constraints, which Oracle classifies as soft partitioning. Only hardware-level partitioning — using technologies Oracle explicitly recognises in its partitioning policy — qualifies.

The Broadcom Factor: Why This Matters More Now

Broadcom completed its acquisition of VMware in late 2023 for approximately $69 billion. The subsequent licensing changes have been dramatic: Broadcom eliminated perpetual VMware licences and moved all products to subscription-only pricing. It also discontinued many standalone products, requiring customers to purchase bundle subscriptions — VMware Cloud Foundation or vSphere Foundation — that include capabilities they may not need.

For many enterprises, VMware subscription costs increased between 200 and 400 percent upon renewal. This has triggered widespread VMware migration planning, which creates an inflection point for Oracle licensing strategy:

• Organisations migrating off VMware have an opportunity to restructure their Oracle deployment to a hard partitioning model at the same time, eliminating the soft partitioning exposure permanently.
• Organisations staying on VMware under Broadcom's new model need to quantify their Oracle exposure explicitly and decide whether to accept it, insure against it, or remediate it.
• Oracle has increased LMS audit activity targeting VMware environments, aware that the VMware transition creates uncertainty and compliance gaps that generate audit settlements.

VMware Technologies and Oracle's Classification

Oracle's partitioning policy lists approved hard partitioning technologies. No VMware product is on this list. The following VMware technologies are all treated as soft partitioning regardless of how they are configured:

• VMware ESXi (all versions)
• vSphere (Foundation, Standard, Enterprise Plus)
• VMware Cloud Foundation
• VMware Workstation and Fusion
• vSAN (for storage isolation does not affect compute licensing)
• NSX (network isolation does not affect compute licensing)
• DRS affinity and anti-affinity rules
• vSphere Resource Pools with CPU limits

None of these configurations change Oracle's requirement to licence the entire physical cluster. The only way to reduce Oracle licence exposure in a VMware environment is to eliminate the Oracle workload from that VMware infrastructure entirely, or to limit Oracle to dedicated hosts that are isolated from the wider VMware cluster — effectively treating those hosts as physically separate from the cluster, with no VM migration path to unlicensed hosts.

Approved Hard Partitioning Technologies

Oracle maintains an approved list of hard partitioning technologies that do qualify for reduced licence counting. The relevant ones for organisations considering a VMware migration include:

• Oracle VM (OVM): Oracle's own hypervisor, which Oracle approves for hard partitioning. OVM uses KVM-based virtualisation on Oracle Linux.
• Oracle Linux KVM with hard partitioning configuration: KVM running on Oracle Linux, when properly configured with CPU pinning and NUMA topology controls, is approved by Oracle for hard partitioning treatment.
• IBM LPAR (on IBM Power Systems): Approved for hard partitioning on Power hardware.
• Solaris Zones (on SPARC): Approved for hard partitioning on Oracle SPARC hardware.
• Physical hardware partitioning: NUMA-based hardware partitioning on supported servers.
• Oracle Exadata and Engineered Systems: Hard partitioned by design with Oracle's own engineered system configurations.

Quantifying Your Oracle VMware Exposure

Before developing a strategy, organisations must quantify their actual exposure. This requires three steps:

First, identify every VMware cluster that hosts an Oracle database VM, application server, or middleware instance. Document the total physical core count for each cluster — not just the hosts where Oracle currently runs, but every host to which Oracle VMs could theoretically migrate.

Second, apply Oracle's processor counting rules: total physical cores multiplied by the relevant core factor (0.5 for Intel x86) multiplied by the Oracle product's list price per processor licence. This gives list-price exposure. Actual negotiated exposure will be lower, but the list-price calculation establishes your maximum risk.

Third, compare this cluster-wide licence count against the licences you actually own. The gap is your compliance exposure — the amount Oracle could claim in a formal audit settlement. In our experience, this gap is frequently five to twenty times larger than organisations expected when they count only the vCPUs assigned to Oracle VMs.

Strategic Options for Oracle on VMware Environments

Once exposure is quantified, organisations have four strategic options, each with different cost, complexity, and risk profiles:

Option 1: Accept and Licence the Full Cluster

This is Oracle's preferred outcome. Purchasing sufficient licences to cover the entire cluster removes audit risk but is often prohibitively expensive. For large VMware clusters, this may require tens of millions of pounds in licence investment. It is rarely the right answer unless the Oracle workload genuinely requires the full cluster and the alternative costs are comparable.

Option 2: Hard Partitioning Through Physical Isolation

Remove Oracle VMs from the general VMware cluster and place them on dedicated hardware, physically isolated from the rest of the VMware infrastructure. This requires that Oracle VMs cannot migrate to hosts that are not licensed — which means no shared management cluster, no DRS migrations to unlicensed hosts, and documented network isolation. When properly implemented, Oracle accepts this as equivalent to on-premises hard partitioning. This approach requires careful architecture design and typically Oracle validation.

Option 3: Migrate Oracle Workloads to Oracle Linux KVM

As part of or ahead of the broader VMware exit, migrate Oracle database and application workloads to Oracle Linux with KVM. Oracle Linux KVM, when properly configured with CPU pinning and documented NUMA topology constraints, qualifies for hard partitioning treatment. This simultaneously solves the VMware licensing problem and the Broadcom cost problem. The migration complexity is significant but one-time; the licensing benefit is permanent.

Option 4: Migrate Oracle Workloads to Cloud (OCI or Azure)

Moving Oracle databases from VMware to cloud removes the VMware soft partitioning exposure entirely. In OCI, Dedicated VM Hosts qualify for hard partitioning treatment. In Azure, the 2:1 vCPU counting rule applies, which for most workloads is significantly cheaper than licensing a full VMware cluster. This is the most frequently chosen path for organisations already undertaking a broader cloud migration alongside their VMware exit.

Oracle's Audit Activity in VMware Environments

Oracle has historically viewed VMware environments as among the highest-yield targets for licence audits. The gap between the licences organisations believe they need (based on vCPU counts) and what Oracle claims they need (based on cluster-wide core counts) consistently produces large compliance claims with relatively limited effort from Oracle's LMS team.

The Broadcom acquisition has increased audit activity in VMware environments for two reasons: first, organisations undertaking VMware migrations are touching infrastructure in ways that trigger Oracle's monitoring indicators; second, Oracle is aware that the combination of VMware cost pressure and Oracle audit claims can accelerate Oracle Cloud or Oracle engineered system discussions — which is commercially favourable for Oracle.

If you receive a contact from Oracle's GLAS team — whether framed as an LMS audit, a licence review, or an advisory engagement — while running Oracle on VMware, treat it as a compliance engagement from the first communication. Do not provide information informally. Engage independent Oracle licensing advisors before responding. The first responses to Oracle's requests establish the position you will defend for the remainder of the audit process.

Key Recommendations for Oracle VMware Environments

To summarise the critical actions for any organisation running Oracle on VMware infrastructure in a Broadcom world:

• Conduct a full Oracle licence position assessment that uses cluster-wide core counts, not vCPU counts, for all VMware environments
• Align any VMware exit strategy with Oracle licensing remediation — migration is the optimal time to restructure Oracle's physical deployment
• Evaluate Oracle Linux KVM as the target state for Oracle database workloads leaving VMware — it provides hard partitioning recognition and removes Broadcom dependency
• For Oracle workloads moving to cloud, prefer OCI for databases (hard partitioning available) with Azure for application tiers via the OCI-Azure Interconnect
• Do not assume that DRS affinity rules, CPU reservations, or resource pool limits satisfy Oracle's partitioning requirements — they do not
• If Oracle contacts you while running Oracle on VMware, engage independent advisors immediately — the opening compliance claims routinely exceed actual obligations by 40 to 70 percent
• Oracle support increases by 8% per year — any settlement amount includes future support escalations, making early remediation far cheaper than deferred action

The combination of Broadcom's VMware pricing changes and Oracle's immovable soft partitioning policy creates a genuine crisis for many enterprise IT organisations. The organisations that navigate it most effectively are those that treat it as a strategic transformation opportunity — using the forced VMware migration as the catalyst to restructure Oracle's licensing footprint into a defensible, efficient, long-term position.