Oracle treats soft partitioning, including VMware, as no limit on what must be licensed. That single position is why a virtualised estate can have its count balloon at certification, and why the boundary is set by where Oracle could run, not only where it does.
By the Meridian advisory team · Ex Oracle licensing analysts · Updated June 2026
Oracle divides partitioning into two categories and treats them very differently. Hard partitioning, achieved with a short list of Oracle approved technologies, can genuinely limit the number of processors that must be licensed to a defined subset of a machine. Soft partitioning, which Oracle defines to include VMware and most common hypervisors, does not limit scope at all in Oracle's view. Under the soft partitioning position, the licensable boundary is every piece of hardware the Oracle workload could run on, not merely the host it happens to sit on today. For a ULA holder this is mostly invisible during the term, because deployment is unlimited, and then decisive at certification, where the boundary shapes the count you declare and must defend.
Soft partitioning means potential, not actual, deployment sets the count. If your Oracle virtual machines could migrate across a large cluster, Oracle's stance points to the whole cluster. Containing that boundary is a design decision you make before the exit, not a number you negotiate at it.
Hard partitioning physically or logically pins Oracle to a fixed set of processors in a way Oracle recognises. Where it applies, you license only that fixed set. The list of technologies Oracle accepts as hard partitioning is narrow and specific, and the burden is on you to show your configuration is on it. Done correctly, hard partitioning is the cleanest way to keep a boundary small.
Soft partitioning includes the virtualization most enterprises actually run, VMware above all. Oracle's position is that because the hypervisor can move or schedule a workload across hosts, nothing technically prevents Oracle from running anywhere in the reachable estate, so everything reachable is in scope. Features that migrate virtual machines between hosts, and configurations that link clusters together, widen the reachable estate and therefore the boundary. The technology being capable is enough for Oracle, whether or not the workload ever actually moved.
Oracle treats VMware as soft partitioning. In practical terms that means VMware by itself does nothing to reduce the count, and depending on how your environment is built, an entire cluster or a set of linked clusters can be pulled into scope at certification. This is the heart of the VMware trap that catches so many ULA holders. The recognised ways to contain it are architectural: isolate Oracle onto dedicated clusters, restrict the hosts the workload can reach, and document the boundaries so they can be evidenced. In a containment situation those steps protect you. In a maximization situation the same soft partitioning logic can be used the other way, deliberately broadening a count you are entitled to grow, which is one of the few places the stance can work in the customer's favour.
The figures below are indicative and exist only to show the effect of the stance.
| Environment | Where Oracle actually runs | Boundary under Oracle's stance |
|---|---|---|
| Oracle VMs on a shared 32 host cluster | 6 hosts | 32 hosts |
| Two clusters linked for migration | 6 hosts | 64 hosts |
| Oracle isolated on a dedicated 8 host cluster | 6 hosts | 8 hosts |
The Oracle workload is identical in all three rows: six hosts of real use. On the shared cluster, the stance puts the whole thirty two hosts in scope. Link a second cluster for migration and the reachable estate, and the boundary, doubles. Isolate Oracle onto a dedicated eight host cluster and the boundary falls to those eight. Nothing about the Oracle workload changed. The architecture around it did, and the architecture is what Oracle's partitioning stance reads.
Oracle's partitioning rules live in a published policy document, not in your signed agreement. That gap is why their application can be discussed rather than simply accepted, and why your specific contract language, not the policy alone, should anchor any position you take.
Usually not directly. The partitioning policy is a separate Oracle document that the contract often does not incorporate by reference. What binds you is the agreement you signed and how it defines installation, deployment, and counting. This distinction matters because it means the soft partitioning position is a strong claim Oracle will press, not always an automatic contractual result. Whether and how it applies to your estate depends on your wording, which is exactly why partitioning questions should be assessed against the contract rather than conceded on the strength of the policy.
Understanding the stance is the first step. To act on it, read isolating Oracle workloads before exit for the architectural containment that keeps the boundary small, and read our Oracle and VMware licensing guide for the configurations that widen a count and how to control them. For the full exit method, our Oracle ULA exit strategy guide is the pillar that connects partitioning, counting, and timing.
Oracle divides partitioning into hard and soft. Hard partitioning, using approved technologies, can limit the processors that must be licensed. Soft partitioning, which includes VMware and most hypervisors, does not limit scope in Oracle's view, so the licensable boundary extends to all hardware the Oracle workload could run on, not just where it actually runs.
Oracle treats VMware as soft partitioning. That means VMware on its own does not restrict the count, and depending on the architecture an entire cluster, or even linked clusters, can be drawn into scope. Isolation, dedicated clusters, and documentation are the recognised ways to contain that boundary.
Usually not directly. The partitioning policy is a published Oracle document, not contract text, which is why its application can be contested. What binds you is your agreement and how counting is defined in it. This is an area where the gap between policy and contract matters, and where the specific wording should be checked.