Oracle virtualization licensing turns on one question: which cores does Oracle insist you license? The answer Oracle gives and the answer your contract supports are often very different.
Oracle virtualization licensing turns on which cores you must license. Oracle's partitioning policy pushes whole host and whole cluster claims, but the policy is not a contract term, and the buyer position holds.
Oracle virtualization licensing turns on one question: which cores does Oracle insist you license? The answer Oracle gives and the answer your contract supports are often different.
This guide covers soft versus hard partitioning, the VMware dispute, and the buyer position that holds in 2026.
Oracle splits virtualization into two camps. Hard partitioning limits licensing to a subset of cores. Soft partitioning, in Oracle's view, does not. The core factor table still applies to whatever cores are counted.
Oracle's partitioning policy approves specific technologies as hard partitioning, including Oracle Linux KVM with hard caps, Oracle VM with CPU pinning, IBM LPAR, and Solaris Zones. These let you license a fenced subset of cores.
Oracle classifies VMware and most hypervisor level controls as soft partitioning. Its policy position, set against the Database Licensing Information manual, is that soft partitioning does not limit licensing, so the whole physical host, or more, must be licensed.
VMware is where the dispute concentrates. Oracle's claim has expanded with each vSphere release, and most of it rests on policy, not contract.
Oracle VMware licensing claims versus contract reality
| Oracle claim | Basis | Buyer counter | Strength |
|---|---|---|---|
| License the whole host | Policy | Contract names cores, not hosts | Strong |
| License the whole cluster | Policy | vMotion boundary is configurable | Strong |
| License all connected clusters | Policy | No contractual basis | Very strong |
| Soft partitioning never limits | Policy | Policy is not a contract term | Strong |
Oracle often argues that vMotion lets a VM run anywhere in a cluster, so every host in the cluster must be licensed. The counter is that vMotion boundaries are configurable and the contract licenses cores, not theoretical mobility.
Newer vSphere features do not change the contract or the Oracle master agreement. They change Oracle's narrative. Hold the position that your signed agreement defines the licensed unit.
The gap between licensing a pinned subset and licensing an entire cluster can be an order of magnitude. This is the single largest swing in most Oracle estates.
White Paper ยท Oracle
The Oracle Buyer Side Framework
The moves we use across Oracle Database, Java and ULA estates. Read it free.
Where Oracle runs on x86, isolating it onto an approved hard partitioning platform, or onto dedicated licensed hosts, ends the soft partitioning debate before it starts.
The standard advice, often from resellers and even some auditors, is that running Oracle on VMware means you must license the entire cluster, so you should just accept it. We disagree. In roughly eight out of ten VMware disputes we have handled, Oracle's cluster wide and connected cluster claims rested entirely on the partitioning policy, which is not a contract term, and the buyer held a far smaller number by licensing to the signed agreement. The buyer side move is to isolate Oracle onto dedicated hosts or an approved hard partition, document the vMotion boundary, and refuse to concede cores the contract never named. Policy pressure is not contractual obligation.
Source: Redress Compliance advisory engagement file, 2024 to 2025.
Oracle's partitioning policy is a remarkably effective document for something that is not in your contract. Read what you signed, not what they published.
The estate rewards isolation and documentation. Both shrink the surface Oracle can claim.
Run Oracle on dedicated hosts or an approved hard partition. Mixing Oracle into a shared VMware cluster invites the cluster wide claim.
Record vMotion configuration, host affinity, and the licensed cores. Evidence beats policy in a dispute every time.
Not under your contract. Oracle's partitioning policy claims you must, but the policy is not a contract term. Your signed agreement licenses cores, and the buyer position is to license the cores you actually run Oracle on.
Hard partitioning, such as IBM LPAR or Oracle Linux KVM with hard caps, lets you license a fenced subset of cores with Oracle's approval. Soft partitioning, including VMware, is treated by Oracle as not limiting licensing.
No. The partitioning policy is an Oracle guidance document, not a term of your signed agreement. It is persuasive in a negotiation but does not override the licensed unit defined in your ordering document and master agreement.
Yes. Isolate Oracle onto dedicated hosts or an approved hard partition, configure and document vMotion and host affinity boundaries, and license the cores you run. Mixing Oracle into a shared cluster invites the cluster wide claim.
The connected cluster claim is Oracle's argument that all clusters reachable through shared storage or vMotion must be licensed. It has no contractual basis and is the weakest of Oracle's virtualization claims.
No. Newer vSphere features change Oracle's narrative, not your contract. The licensed unit is whatever your signed agreement defines, regardless of hypervisor capabilities Oracle points to.
The swing can be an order of magnitude. Licensing a whole cluster instead of a pinned host can multiply Processor counts five to ten times, and connected cluster claims push it higher. It is the largest cost swing in most estates.
Isolate Oracle onto dedicated hosts or an approved hard partition before any audit. This removes the soft partitioning debate entirely and limits licensing to a defined, documented core count.
Oracle ULA exit moves, Java audit defense posture, certification framework, and the buyer side moves across the Oracle Database, Java, and EBS estate.
Used across more than five hundred enterprise engagements. Independent. Buyer side. Built for procurement leaders running the next renewal cycle.
