Oracle still counts every core a database can reach across your VMware estate, and Broadcom's pricing has quietly pushed you onto larger, denser clusters that widen that count. This guide quantifies the exposure, names where your leverage sits, and tells you exactly what to do before the audit letter arrives.
Oracle still counts every core a database can reach across your VMware estate, and Broadcom's pricing has quietly pushed you onto larger, denser clusters that widen that count. This guide quantifies the exposure, names where your leverage sits, and tells you exactly what to do before the audit letter arrives.
Two vendors changed your risk profile in the same 24 months, and they did not coordinate. Oracle never moved its partitioning policy when Broadcom bought VMware. Broadcom moved the cost line. The result is a squeeze that most Oracle customers running databases on vSphere have not yet priced: Broadcom's subscription repricing pushes you to consolidate onto fewer, larger clusters to control per-core spend, and Oracle counts every physical core in those larger clusters as licensable whether the database runs there or not.
After 25 years negotiating against Oracle License Management Services and its successor GLAS team, I can tell you the mechanism plainly. Oracle classifies VMware as soft partitioning. Its position is that you must license every physical processor in every host in the cluster where an Oracle virtual machine can run, regardless of vCPU allocation. A four-vCPU database on a 32-host cluster, in Oracle's opening claim, carries 32 hosts of licenses. Broadcom's economics make that 32-host cluster more likely, not less.
The correct buyer-side response is to read the two contracts independently and to fund your Oracle containment or migration project from the VMware renewal savings you are about to negotiate anyway. This article maps the exposure across four axes: the policy Oracle enforces (and its contractual weakness), the vMotion scope that drives the multiplier, the Broadcom consolidation pressure that widens it, and the defense that has held at settlement for two decades. If you want the architecture-first version, our Oracle on VMware containment guide pairs directly with this exposure map.
Start with the single most important fact in this dispute: the word "VMware" does not appear in your Oracle license agreement. Neither does the cluster-counting rule. Oracle enforces both through its Partitioning Policy, a document that Oracle itself labels non-binding. The policy text states that it "is for educational purposes only," that "it may not be incorporated into any contract," and that it "does not constitute a contract or a commitment to any specific terms." That disclaimer is your leverage, and you should quote it back in every audit response.
The operative language Oracle relies on reads: "Unless explicitly stated, Soft Partitioning is not permitted to determine or limit the software licenses required for a given server or a cluster of servers." Oracle uses this to argue that no VMware configuration (DRS affinity rules, CPU pinning, host affinity groups) reduces the count. The practical effect is that a single Oracle node on a large host can license the entire host, and the license boundary becomes the cluster rather than the server.
Oracle then goes further. In audits I have defended, GLAS has argued that the boundary is every host within reach of live migration, including across linked vCenter inventories. That scope can multiply the licensable core count several times over the cores actually running Oracle. Many customers are genuinely surprised by this during an audit, because they read their contract, found nothing about VMware, and reasonably assumed they only owed what the database consumed. The gap between contract text and Oracle policy is exactly where the fight lives.
Oracle's cluster-counting rule lives in a document Oracle itself says is non-binding and cannot be incorporated into any contract. That disclaimer is not trivia. It is your central negotiating position.
Understand the asymmetry. Oracle's contract grants you a license measured in Processors, and the ordering document defines Processor by reference to the core factor table and the partitioning rules "as described in Oracle's policy." Oracle's counsel knows the policy is not itself contractual. That is why Oracle audits VMware estates through commercial pressure and the threat of a large opening claim rather than through litigation. The moment a customer forces the question into court, Oracle's appetite tends to evaporate. More on that when we reach the Mars precedent.
Let me quantify what Oracle's position costs, because the number is the entire point. Take a common mid-size cluster: 10 hosts, each with two Intel Xeon processors at 32 cores, for 640 physical cores. Suppose Oracle Database Enterprise Edition runs on exactly one virtual machine with four vCPUs. What you consume is trivial. What Oracle claims is not.
| Basis of count | Cores counted | Core factor (Intel 0.5) | Processor licenses | EE list @ $47,500 | Annual support @ 22% |
|---|---|---|---|---|---|
| Cores actually running Oracle (4 vCPU) | 2 (rounded) | 0.5 | 1 | $47,500 | $10,450 |
| One host (2 sockets, 64 cores) | 64 | 0.5 | 32 | $1,520,000 | $334,400 |
| Full 10-host cluster | 640 | 0.5 | 320 | $15,200,000 | $3,344,000 |
| Oracle cross-cluster claim (linked inventories, illustrative 2x) | 1,280 | 0.5 | 640 | $30,400,000 | $6,688,000 |
That table is not a scare tactic. It is Oracle's published example logic applied to list prices. The 640-core cluster carries 320 Enterprise Edition processor licenses at Oracle's standard rule, and Oracle's opening claim frequently reaches beyond the cluster into linked inventories, doubling again. The concise audit version is the one I quote in every kickoff meeting: a four-host Oracle VM on a 32-host cluster carries 32 host licenses in Oracle's math.
How large is the gap between claim and reality in practice? Across roughly 30 to 40 Oracle virtualization engagements our team ran between 2024 and 2025, soft-partitioned estates faced license claims a median 3.5 times the cores actually running Oracle. Opening claims that priced every host in every reachable cluster inflated the position 4 to 10 times over a properly contained architecture. That is the spread you are negotiating inside. The full mechanics of how consolidation inflates the count sit in our vSphere 8 cluster sizing analysis.
Median claim inflation across 30 to 40 engagements: 3.5x the cores actually running Oracle. Opening claims that reached across linked clusters ran 4 to 10x over a contained design.
The reason the cluster boundary is contentious, and the reason it keeps growing, is live migration. Oracle argues that because vMotion can move a database VM to any host it can reach, every reachable host must be licensed. The technical reach of vMotion expanded materially across vSphere versions, and Oracle's claimed scope tracked it.
Two amplifiers make this worse. First, Oracle explicitly refuses to recognize software controls: DRS host affinity rules, CPU affinity settings, and vSphere CPU pinning are all treated as soft partitioning that "is not permitted to determine or limit" the count. You cannot pin your way out of the claim, and any advisor who tells you otherwise is exposing you. Second, Oracle treats shared infrastructure as a vMotion enabler. Shared datastores extend the boundary. Layer-2 stretched networks across data centers extend the boundary to every host on the stretched fabric. The storage angle is the one buyers most often miss, and we cover it in the Storage vMotion scope analysis.
The full argument Oracle deploys, and how to answer each element, sits in our vMotion and DRS audit-argument breakdown. The short version for your architecture team: the only reliable way to cap the count is to remove the reachability, not to constrain it in software. That means physical isolation, which we address next.
Here is the interaction that most Oracle customers have not yet connected. Broadcom collapsed VMware's portfolio from roughly 8,000 SKUs and 168 bundles down to four primary subscription bundles: VMware Cloud Foundation (VCF), vSphere Foundation (VVF), vSphere Standard, and vSphere Enterprise Plus. Perpetual licensing is gone. VCF lists at $350 per core per year, down from the initial post-acquisition $700 in January 2024 but still a per-core subscription that punishes fragmented, small clusters.
Per-core subscription economics reward density. When every core carries an annual fee, the CFO's instinct is to consolidate workloads onto fewer, larger, more utilized clusters to avoid paying for idle capacity. Broadcom reinforced that direction with its April 2025 announcement of a 72-core minimum per product purchase, regardless of actual usage. VMware reversed that back to a 16-core minimum later in 2025, but the strategic direction is set: Broadcom is optimizing for massive, dense enterprise clusters.
Broadcom's per-core subscription rewards density. Oracle's soft-partitioning rule punishes it. The same consolidation that lowers your VMware bill can multiply your Oracle claim.
Now overlay Oracle's rule. The consolidation that lowers your VMware bill enlarges the cluster that Oracle counts. If your Oracle database follows a general workload consolidation onto a 40-host VCF cluster, Oracle's opening claim priced against every reachable core is catastrophic. The two vendors are pulling you in opposite directions, and only one of them is auditing you for revenue.
There is a genuine opportunity buried in this, and it is the thesis of the guide. Broadcom's repricing of large general-purpose clusters is forcing estates to shrink and segment VMware anyway. That redesign is an Oracle containment opportunity if you capture it deliberately. Smaller, physically isolated Oracle clusters mean a smaller Oracle scope. Fund the Oracle containment project from the VMware renewal saving, and you can improve both positions in the same budget cycle. We break down the renewal negotiation itself in the Broadcom VMware licensing guide.
There are only two defensible destinations for Oracle on VMware in 2026: a physically isolated dedicated cluster, or off VMware entirely. Everything in between is exposure you cannot fully defend. Take the containment path first, because it is the lower-disruption move and it works.
A contained Oracle cluster is a small set of hosts (frequently two to four) with its own vCenter or, more conservatively, its own separate vCenter instance, no shared datastores with the broader estate, no stretched Layer-2 fabric reaching other clusters, and vMotion boundaries that physically stop at the cluster edge. The point is not to configure a software control Oracle will reject. The point is to remove the technical reachability so there is no host outside the cluster that a database could migrate to. When you license the physical cores in that isolated cluster in full, and only those cores, you have a position Oracle's own logic cannot extend.
| Design element | Exposed estate | Contained cluster |
|---|---|---|
| Cluster size Oracle counts | Entire reachable inventory | 2 to 4 dedicated hosts |
| Shared datastores | Yes, extends boundary | None with non-Oracle hosts |
| Stretched L2 network | Often present | Removed or isolated |
| vCenter linkage | Enhanced linked mode common | Separate or unlinked |
| Typical claim vs. contained | 4x to 10x higher | Baseline (the defensible count) |
The economics usually favor containment decisively. If your exposed position implies 320 processor licenses and a contained four-host cluster implies 32, you have removed roughly $13.7 million of list exposure and $3 million of annual support from the audit conversation before you negotiate a dollar. The step-by-step build, including the CPU choices and the physical separation checklist, is in our dedicated Oracle VMware cluster design guide. Before you attempt partial-cluster licensing (licensing only some hosts within a shared cluster), read the partial-cluster licensing analysis, because Oracle rejects it and the myth costs customers money at audit.
Containment caps the count. Migration eliminates the dispute. For estates where the Oracle footprint is large, where the VMware renewal is painful, or where the compliance risk simply is not worth managing year after year, moving Oracle off VMware is the cleaner answer. The candidate destinations each have a different licensing profile, and you must count before you commit.
The head-to-head cost and risk comparison between staying on a contained VMware cluster and moving to OCI is the decision most of my clients agonize over, and it deserves its own model. We built it out in the VMware versus OCI 2026 cost comparison. The short guidance: run both scenarios on your actual shapes and support base before you take Oracle's migration incentive, because the incentive is priced to make the OCI number look better than a properly contained VMware position often is.
The core factor table converts physical cores into Oracle Processor licenses, and for the entire current Intel Xeon server portfolio it sits at 0.5, meaning each core counts as half a Processor. A two-socket, 64-core Intel server therefore requires 32 Processor licenses. The January 2026 update to the table added multiple Intel Xeon 69xxP, 67xxE, 67xxP, 65xxP, and 63xxP variants, all at 0.5, confirming that the current generation stays at that factor.
Do not treat that 0.5 as permanent. The core factor table is not contractual, and Oracle reserves the right to change it. A future revision to 1.0 would double your effective license count overnight with no change to your infrastructure. In any material Oracle negotiation you should either freeze the applicable core factor for the contract term in your ordering document, or move the relevant products to Named User Plus where the metric does not depend on the table at all. This is a quiet, high-value clause that Oracle rarely volunteers. The broader mechanics are covered in our 2026 virtualization licensing guide.
The core factor is 0.5 for every current Intel Xeon, but the table is not contractual. Freeze your factor in the ordering document or you are one Oracle revision away from doubling the count.
The Enterprise Edition license is only the base. The audit findings that hurt most are database options and management packs deployed without matching licenses, because they carry their own per-Processor price and their own cluster-wide count. On a 320-Processor VMware exposure, an unlicensed option multiplies across the same inflated core base.
| Component | List price per Processor | Common trigger |
|---|---|---|
| Database Enterprise Edition | $47,500 | The base license |
| Advanced Security | $11,500 | TDE, network encryption enabled |
| Diagnostics Pack | $7,500 | AWR, ADDM, performance views accessed |
| Tuning Pack | $5,000 | SQL Tuning Advisor (requires Diagnostics Pack) |
Note the compounding. If Diagnostics Pack applies at $7,500 per Processor across a 320-Processor VMware claim, that single pack adds $2.4 million of list exposure before support. Options are the reason a VMware audit finding is rarely just about the database. Your evidence pack must show what is genuinely deployed and used, feature by feature, so Oracle cannot assert usage across the inflated core count. The definitive list of audit triggers is in our Oracle Database licensing pillar.
The single most useful fact in any VMware audit defense is what happened when a customer refused to accept Oracle's soft-partitioning position and forced the question. Mars, the confectionery company, took Oracle to court after Oracle threatened to terminate its entire Oracle license inventory during an audit dispute over VMware. Mars pushed back on Oracle's cluster-counting claim. Oracle did not put up a fight. It settled rather than litigate the policy it knows is non-binding.
Read the lesson correctly. The precedent does not mean you should sue Oracle. It means Oracle's commercial pressure rests on customers accepting a policy Oracle is unwilling to defend in court. Your job is to make the credible case that you understand the policy is non-binding, that your architecture is contained, and that you are prepared to escalate. That posture routinely moves settlements down to the 10 to 25 percent range of Oracle's opening claim.
That posture only works if you can prove your position, which requires an evidence pack assembled before the audit, not during it. At minimum it contains a documented topology showing cluster boundaries, a statement of vMotion and DRS configuration, storage and network isolation evidence, a deployed-feature inventory for options and packs, and a written record of the contract terms Oracle actually granted. We detail every artifact in the evidence pack guide, and the containment-plus-proof discipline is summarized across our virtualized-environment licensing overview.
Oracle settled with Mars rather than litigate the VMware policy. That is the whole tell. Contain the architecture, hold the non-binding argument, and settlements land at 10 to 25 percent of the opening claim.
Sequence the work so the VMware renewal funds the Oracle fix. Here is the order I run with clients this year.
The core message stands after 25 years of this vendor's tactics: Oracle's VMware claim is large, policy-based, and non-contractual, and it grows precisely when Broadcom's economics push you toward denser clusters. You do not defeat it by pinning CPUs or citing DRS rules Oracle refuses to recognize. You defeat it by physically containing the architecture, proving the containment with evidence, and holding the non-binding-policy line that Oracle has consistently declined to test in court. Do those three things and you convert a multi-million-dollar opening claim into a defensible count you actually owe.
No. Oracle classifies VMware as soft partitioning and requires you to license every physical core in every host a database VM can reach, not just the vCPUs assigned. This position comes from Oracle's Partitioning Policy, not from your license contract, and Oracle itself labels that policy non-binding and unable to be incorporated into any contract.
Oracle refuses to recognize software controls including DRS host affinity, CPU affinity, and vSphere CPU pinning as ways to limit the count. The only reliable way to cap Oracle's cluster scope is to physically remove reachability through a dedicated, isolated cluster with no shared datastores, no stretched Layer-2 network, and no linked vCenter inventory.
Broadcom did not change Oracle's policy, it changed the cost line. Its per-core VCF subscription (list $350 per core per year) rewards consolidating workloads onto fewer, larger, denser clusters. Because Oracle counts every physical core in the reachable cluster, that same consolidation can multiply your Oracle claim. Read the two contracts independently and fund the Oracle fix from the VMware renewal saving.
Across roughly 30 to 40 engagements in 2024 to 2025, soft-partitioned estates faced claims a median 3.5 times the cores actually running Oracle, and opening claims that reached across linked clusters ran 4 to 10 times over a properly contained architecture. A four-vCPU database on a 10-host, 640-core cluster can carry 320 Enterprise Edition Processor licenses in Oracle's math.
Yes, as leverage. Mars took Oracle to court after Oracle threatened to terminate its licenses in a VMware dispute, and Oracle settled rather than litigate the policy it knows is non-binding. The lesson is not to sue but to demonstrate you understand the policy is non-contractual, that your architecture is contained, and that you are prepared to escalate. That posture routinely lands settlements at 10 to 25 percent of the opening claim.
Both are defensible; everything in between is exposure. Containment caps the count via a physically isolated cluster and is lower-disruption. Migration to OCI, authorized-cloud BYOL, or approved hard-partitioning technology eliminates the dispute entirely. Model the contained-cluster count against the migration alternatives on your actual shapes and choose the lower total cost of risk, not the lower sticker price.
Oracle Exadata can lock you into full core licensing across X9M, X10M, and Cloud at Customer. The buyer side strategy to size the platform and cut the bill.
Gated with a work email on the download page. No sales follow up you did not ask for.
Get the White Paper →
500+ enterprise clients. 11 vendor practices. Industry recognized. One conversation can change what you pay for the next three years.
One buyer side briefing a week. Renewal signals, audit moves, and the levers that work. No vendor spin.
