Running Oracle Database or Oracle middleware on VMware is one of the most common — and most expensive — disputes in an Oracle licence audit. The core of the disagreement is simple to state: Oracle's published policy treats VMware as soft partitioning, which Oracle says does not limit the number of processors that must be licensed. Customers, by contrast, often expect to license only the hosts or clusters where Oracle actually runs. Closing that gap is a central discipline of Oracle audit defence, and it is where six- and seven-figure audit findings are most often manufactured.
Hard partitioning versus soft partitioning
Oracle divides virtualisation and partitioning technologies into two buckets in its Partitioning Policy document. Hard partitioning technologies are accepted by Oracle as a way to limit the processors that must be licensed — the approved list historically includes technologies such as Oracle VM (with CPU pinning configured to Oracle's rules), Solaris Zones (capped), IBM LPAR, and physical hardware partitions. Soft partitioning — which Oracle's policy explicitly says is "not permitted as a means to determine or limit the number of software licenses required" — includes VMware vSphere, Microsoft Hyper-V, and similar hypervisors that can move or reassign workloads dynamically.
The critical thing buyers must understand is that the Partitioning Policy is a policy document, not a contract term. It is published on Oracle's website and is referenced in sales conversations, but it is generally not incorporated into the Oracle Master Agreement or the Ordering Document a customer signs. That distinction matters enormously in a dispute, because Oracle's contractual right to payment flows from the agreement, not from a policy PDF that Oracle can revise unilaterally.
Why vMotion and cluster design drive the claim
Oracle's audit argument on VMware has evolved with VMware's own architecture. The aggressive position Oracle auditors have advanced is that because vMotion, DRS, and shared storage allow a virtual machine to run on — or migrate to — any host in a cluster (and, with some vCenter architectures, any host any cluster a vCenter can reach), every physical core that a VM could land on must be licensed. On a large vSphere estate that turns a four-host Oracle cluster into a claim spanning dozens or hundreds of hosts.
There is no clause in a standard Oracle licence agreement that says "you must license every host a VM could theoretically migrate to." This is an inference Oracle draws from the soft-partitioning policy. Customers who can demonstrate hard technical and procedural boundaries — and who hold Oracle to what the signed contract actually says — routinely contain the licensable footprint to the hosts where Oracle is genuinely installed and running.
| Containment control | What it does | Audit relevance |
|---|---|---|
| Dedicated Oracle cluster | Physically separate vSphere cluster reserved for Oracle workloads | Strongest. Bounds the licensable core count to known hosts |
| Separate vCenter / SSO domain | Removes the "any host in the estate" migration argument | Counters Oracle's cross-vCenter mobility claim |
| Host affinity / DRS "must run" rules | Pins VMs to a defined host group | Supporting evidence; weaker alone because rules are reversible |
| Disabled vMotion / Storage vMotion logs | Demonstrates VMs have not moved beyond the cluster | Evidentiary — historical proof of actual placement |
vSphere version myths
A persistent myth holds that a particular VMware version (often cited as vSphere 5.1, or later 6.x) is the point at which "Oracle can make you license the whole estate." There is no contractual basis for tying licence scope to a vSphere release number. What changed across versions was VMware's capability for cross-cluster and cross-vCenter mobility, which Oracle auditors then used to widen their argument. The defensible answer is the same regardless of version: licence the cores where Oracle runs, document the boundaries, and decline to accept inferences that the contract does not support.
Buyer takeaway: The VMware exposure in an Oracle audit is rarely a licensing fact — it is a negotiating position built on a policy document. The customers who pay the inflated number are usually the ones who accept Oracle's framing without separating contract from policy. Architecture (a dedicated, separately-managed Oracle cluster) and contract discipline together are what cap the claim. See our Oracle audit defence service for how this is run in a live audit.
Practical containment checklist
Before an audit ever lands, buyers running Oracle on VMware should be able to answer four questions with evidence: which physical hosts have ever run Oracle; whether those hosts sit in a cluster isolated from non-Oracle workloads; whether that cluster is managed by a vCenter that cannot reach the rest of the estate; and whether vMotion history confirms VMs have stayed inside the boundary. If all four are documented, the licensable footprint is defensible. If none are, the estate is exposed to Oracle's broadest interpretation.
Related reading: disaster recovery and failover licensing, interpreting Oracle LMS script output, and Oracle on IBM LPAR. For the full programme, start with the Oracle audit defence pillar.
How the VMware claim is resolved in practice
When a VMware finding surfaces, it usually arrives as a single large number with little line-by-line support. The buyer-side response is to decompose it: identify every host Oracle has actually been installed on, distinguish those from hosts Oracle merely could reach, and require Oracle to point to the specific contract language — not the policy PDF — that obliges payment for theoretical reach. In parallel, an architecture remediation (creating a dedicated, separately-managed Oracle cluster, or moving the workload to a hard-partitioning platform) removes the future exposure and strengthens the present negotiation. The combination of a contract argument and a credible remediation path is what moves a settlement from the headline figure toward the genuinely licensable footprint. Buyers should also weigh whether consolidating Oracle onto fewer, fully-licensed hosts is cheaper over three years than perpetuating a sprawl that invites the dispute every audit cycle.
Common questions
Is Oracle's partitioning policy legally binding?
The policy is published guidance, not, in most agreements, an incorporated contract term. Payment obligations derive from the signed Master Agreement and Ordering Document. This is precisely why the contract-versus-policy distinction is the centre of any VMware defence.
Does isolating Oracle to its own cluster really help?
Yes. A dedicated cluster managed by its own vCenter is the strongest available containment because it removes the cross-host and cross-vCenter mobility arguments Oracle relies on to widen the claim, and it gives you a finite, evidenced core count to license.