Oracle's policy insists you license every host in the cluster, but the contract only obligates you where the software is installed and running. This piece separates policy from contract, quantifies the exposure, and tells you exactly what a partial claim needs to survive an audit.
Oracle's policy insists you license every host in the cluster, but the contract only obligates you where the software is installed and running. This piece separates policy from contract, quantifies the exposure, and tells you exactly what a partial claim needs to survive an audit.
Yes, you can license a subset of hosts in a VMware cluster running Oracle, but only if you have engineered and documented containment before Oracle asks. The reason people get this wrong is that they conflate two separate documents: Oracle's Partitioning Policy (which says no) and your Oracle Master Agreement (which says something narrower). In 25 years of negotiating this exact point across dozens of estates, I have watched buyers surrender seven figures because they treated a marketing PDF as if it were their contract. It is not.
The Partitioning Policy states plainly that soft partitioning "is not permitted as a means to determine or limit the number of software licenses required for any given server." Oracle classifies VMware as soft partitioning. Follow that logic and every physical host in the cluster is licensable. But the policy carries its own disclaimer: it is "for educational purposes only" and "may not be incorporated into any contract." That single sentence is the entire buyer-side argument, and it is a real one. For the full exposure picture, start with our Oracle licensing on VMware reference.
The Partitioning Policy is not your contract. Your contract counts processors where Oracle is installed and running, not where it might someday run.
The contractual definition that governs your bill is short: "Processor: shall be defined as all processors where the Oracle Programs are installed and/or running." Read it twice. It says installed and/or running. It does not say "installed, running, or reachable." It does not reference the Partitioning Policy. It does not mention VMware, vMotion, DRS, or clusters. It is silent on virtualization architecture entirely.
House of Brick, an Oracle-focused engineering firm, reads this the way a plain-English court would: "If no Oracle product is installed on a physical server, then there is no liability, even if the physical server is in the same VMware cluster as other physical machines that do have Oracle products installed." Scott & Scott, on the legal side, put the burden back on Oracle: the fact that Oracle "unilaterally has identified VMware to be a soft partitioning technology does not, by itself, give Oracle LMS the right to assume that all processors within a vCenter have been used to install and/or run those programs."
So the contract permits a partial claim. The policy forbids it. That gap is not academic. It is the difference between licensing 32 cores and licensing 160, and Redress Compliance has measured that gap in the field: across roughly 30 to 40 Oracle virtualization engagements run between 2024 and 2025, soft-partitioned estates faced license claims a median 3.5 times the cores actually running Oracle.
Consider the standard worked example. An Oracle Database Enterprise Edition VM using four vCPUs sits on a vSphere cluster of 10 physical servers, each with 16 physical cores, so 160 cores total. Under Oracle's policy reading, all 160 cores are licensable. Apply the 0.5 x86 core factor and that is 80 processor licenses at a list price of $47,500 each, roughly $3.8 million in license fees, plus 22 percent annual support (about $10,450 per processor) forever.
| Scenario | Licensable cores | Processors (0.5 factor) | List license cost | Annual support |
|---|---|---|---|---|
| Policy reading (whole cluster) | 160 | 80 | $3,800,000 | $836,000 |
| Contract reading (2 pinned hosts) | 32 | 16 | $760,000 | $167,200 |
| Delta | 128 | 64 | $3,040,000 | $668,800 |
That is a $3.04 million difference in first-year license cost and a recurring $668,800 in support on a single database VM. The support figure compounds: over five years the containment position saves roughly $3.3 million in support alone. This is why vSphere consolidation quietly inflates exposure. See how vSphere 8 cluster consolidation widens your Oracle license count for the mechanics.
The contract says "installed and/or running." The word that quietly destroys most partial claims is "running," combined with VMware's own mobility features. If your Oracle VM can vMotion, be moved by DRS, or restart via HA onto an unlicensed host, then that host is a place where the program can run. Oracle's auditors argue, and House of Brick agrees on the engineering point, that if a VM "moves to an unlicensed host, then it is not in compliance."
Oracle counts every host the workload can move to, not just the host it runs on today. vMotion, DRS, and Storage vMotion each extend the audit surface. Worse, from vSphere 6.0 onward Storage vMotion can extend the cluster boundary across data centers, and Oracle's auditors treat that wider boundary as the licensable pool. Our breakdown of why Oracle says the whole cluster could run the database covers this argument in detail, and Storage vMotion and shared datastores exposes the cross-datacenter trap most buyers miss.
Affinity rules do not persuade Oracle by themselves. Disabled mobility, proven with technical evidence, is the only thing that holds.
A crucial subtlety: VM-Host affinity rules alone will not save you. You can build a "Must run on Host A only" rule, but Oracle will still treat the entire cluster as the licensed environment, because a "should" rule can be overridden and does not physically prevent movement. A soft affinity rule is a preference, not a boundary. The buyer who says "we have affinity rules" and stops there has already lost the argument.
Even Dell EMC and Oracle's own joint reference guide concedes the technical point: "a customer could license a subset of the cores on a single server if the soft partitioning technology limits the number of cores that can be used." The same guide then delivers the decisive caveat: if the database can move to an unlicensed node "and no rules exist to limit its movement, the customer should license the applicable ESXi server." Containment, not argument, is the load-bearing wall.
To make a partial claim survive an audit, you must do all of the following before the auditor arrives:
The cleanest architecture is a dedicated cluster where the licensing boundary is unambiguous. We walk through that design in designing a dedicated Oracle VMware cluster to cap the license count, and the audit-facing documentation is covered in the evidence pack that defends a contained Oracle VMware estate. Build both before you need them, because reconstructing containment history after an audit letter lands is close to impossible.
Mars Incorporated v. Oracle Corporation, filed October 23, 2015 in the Superior Court of California, remains the only litigation expressly concerning Oracle licensing on VMware. Oracle LMS admitted in writing that it was seeking information about servers not running Oracle, demanding that "all additional servers and/or clusters not running Oracle must be licensed" given Mars' use of VMware 5.1 and higher. The scale was enormous: Mars had spent an estimated $100 million on Oracle over three years, and Oracle's claim could conservatively have doubled that.
Then Oracle blinked. On December 16, 2015, Oracle and Mars agreed not to proceed to court and settled. The precedent, such as it is, cuts in the buyer's favor: when a well-advised customer forced the contract-versus-policy question toward a judge, Oracle chose not to test its policy in front of one. That is a tell. Oracle prefers to win this on audit posture and buyer fatigue, not on a courtroom ruling that might expose the policy as non-binding. Do not expect a written admission from Oracle; expect a demand letter and pressure.
Here is where Redress Compliance departs from the usual advice. The standard counsel is to "fight Oracle by arguing the policy is not contractually binding." We disagree with treating that as the whole strategy. In most virtualization engagements we ran, that argument alone did not lower the claim, because Oracle holds the audit position and the burden of proof falls on the buyer. The legal argument is your shield, not your sword. The sword is architecture and evidence.
The pattern that works is layered: engineer genuine containment, document it with technical evidence, and hold the contractual "installed and/or running" language as the interpretive frame that your evidence supports. Estates defended this way, with evidence, settled the VMware element at 10 to 25 percent of Oracle's opening claim in our files. Estates that relied on assertions alone paid far closer to the full policy number. The difference between a $3.8 million claim and an $760,000 outcome is not a clever argument. It is whether you disabled vMotion two years ago and can prove it today.
The real answer to the question is this: the contract lets you license only some hosts, Oracle's policy pretends otherwise, and the only version of "some hosts" that survives an audit is one you engineered and documented in advance. Everything else is a negotiation you enter without leverage.
No. The Partitioning Policy PDF states on its face that it is "for educational purposes only" and "may not be incorporated into any contract." Your binding obligation comes from the Oracle Master Agreement's Processor definition, which counts processors where Oracle is installed and running. The policy is Oracle's interpretation, not your contract.
Not on their own. Oracle treats a soft affinity rule as a preference that can be overridden, so it will still claim the entire cluster. Affinity rules only help as a supporting control alongside disabled vMotion, DRS, and HA, plus technical evidence that the VM physically cannot move to an unlicensed host.
On a 10-host, 160-core cluster running a single Enterprise Edition VM, the policy reading demands 80 processor licenses (about $3.8 million list) while a contained two-host reading needs 16 (about $760,000). That is roughly a $3 million license delta plus about $668,800 in recurring annual support.
No. Oracle and Mars settled out of court on December 16, 2015, before any ruling. Oracle had demanded that all servers and clusters not running Oracle be licensed, then chose not to test that position in front of a judge. The absence of a Oracle victory is itself informative for buyers.
Yes, significantly. From vSphere 6.0 onward, Storage vMotion can extend the cluster boundary across data centers, and Oracle's auditors treat that wider reach as the licensable pool. Shared datastores are a common hidden scope expander that pull adjacent hosts into a claim.
Technical evidence, not verbal assurances. Oracle expects vCenter configuration exports, DRS automation state, cluster settings, and timestamped documentation proving vMotion, DRS, and HA were disabled for the Oracle VMs across the entire audit lookback period. Reconstructing this after an audit letter is nearly impossible, so build it in advance.
Oracle treats VMware as soft partitioning and can claim every core in the cluster or vCenter. Get the white paper on exposure and the buyer side defense.
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.
