Oracle treats two kinds of partitioning very differently, and the distinction decides how far a count reaches. Hard partitioning can limit what you license. Soft partitioning, in Oracle's view, does not. Understanding which is which is the foundation of every virtualization decision at certification.
Hard partitioning physically limits the processors a workload can use and, under Oracle's policy, limits what must be licensed. Soft partitioning, such as VMware's, does not limit scope in Oracle's view, so the whole physical environment a workload can reach may have to be counted. The distinction decides how far a count extends, which is why it sits under almost every virtualization question at certification.
The technology you virtualize with is a licensing decision, not just an infrastructure one. Oracle's partitioning stance can quietly turn a handful of virtual machines into a cluster sized count.
Oracle publishes a partitioning policy that splits the world into approved hard partitioning and everything else. Hard partitioning means a physical or firmware level boundary that fixes the processors available to a workload, and Oracle recognises a defined set of technologies as qualifying. Soft partitioning means anything that allocates resources in software in a way the workload could, in principle, exceed. Oracle's position is that soft partitioning does not constrain the licensing scope, because the software could be reconfigured to use more. The policy is Oracle's own interpretation rather than contract text, which is exactly why it has to be read against your specific agreement.
This is where the cost sits. Because Oracle treats common virtualization as soft partitioning, its position is that every physical host a workload could run on must be counted, not just the hosts it actually runs on. In a clustered environment with features that move virtual machines between hosts, that can mean an entire cluster, and where clusters are connected, sometimes more than one. A deployment of Oracle on a few virtual machines can therefore expand into a count covering dozens of processors of physical capacity. At certification that cuts both ways. As a risk it inflates exposure, and in a maximization setting the same rule can support a larger defensible count where deployment genuinely runs across a large cluster.
A services firm ran Oracle on six virtual machines inside a large soft partitioned cluster. Measured by the virtual machines alone, the count looked small. Under Oracle's partitioning stance, the relevant scope was the physical hosts the workload could reach across the cluster, a far larger number. The firm had a choice. Isolate Oracle onto a dedicated cluster to bound the scope, or, where the larger footprint was genuinely deployed, document it and certify the higher count. Either path needed measurement and evidence. Figures are indicative and depend on the specific contract language.
Where an approved hard partitioning technology fixes the processors a workload can use, Oracle's policy accepts that boundary, and the count can be limited to the partitioned capacity rather than the whole host.
Reserving specific hosts or a dedicated cluster for Oracle, with no path for the workload to reach other hardware, bounds the scope to that island. The isolation has to be real and configured, not merely intended.
Whatever the technical approach, the position is only as strong as the evidence that Oracle can and cannot run where you say. Cluster configuration, host reservations, and the rules that enforce them are the proof that holds a bounded count.
Which technologies your agreement and Oracle's policy treat as hard partitioning, how your clusters are configured, and what your contract says about virtualization all decide the outcome. Two firms running the same hypervisor can carry very different counts because their isolation and contracts differ. In ULA work the answer almost always depends on the specific wording and the technical reality, so partitioning is assessed against your own environment and agreement.
If your Oracle estate runs virtualized, map your partitioning position before certification, because it shapes the whole count. Start with the ULA exit strategy pillar guide, then read dedicated clusters as a defense and stopping VM sprawl near certification.
Hard partitioning physically limits the processors a workload can use and, under Oracle's policy, limits what must be licensed. Soft partitioning, such as VMware's, does not limit scope in Oracle's view, so the whole physical environment a workload can reach may have to be counted. The distinction decides how far a count extends.
Oracle treats VMware as soft partitioning, so it does not limit licensing scope under Oracle's policy. That stance means an entire VMware cluster, and sometimes connected clusters, can be swept into the count even if Oracle runs on only a few virtual machines. It is the central virtualization risk at certification.
Approved hard partitioning technologies, physical isolation, and dedicated clusters reserved for Oracle are the recognised ways to bound scope. The defense is built on isolation plus documentation that shows where Oracle can and cannot run. Whether a given approach holds depends on the technology and the specific contract, so it is assessed case by case.
Book a confidential assessment and we will map your partitioning position, bound the scope where it should be bounded, and document it to hold.