Oracle's Partitioning Policy is one of the most consequential — and most misunderstood — documents in enterprise software licensing. It establishes a fundamental rule: only hard partitioning technologies can limit the number of processors Oracle counts for licensing purposes. VMware, Hyper-V, KVM, Docker, and nearly every virtualisation technology enterprises actually use are classified as soft partitioning. The practical consequence is that Oracle can require you to license every physical core in a VMware cluster, not just the cores allocated to your Oracle VMs.
Oracle's Software Investment Guide and its associated Processor Core Factor Table contain a Partitioning Policy that defines how Oracle counts processors for licensing purposes when software is deployed on virtualised or partitioned hardware. The policy makes a binary distinction: technologies that Oracle classifies as "hard partitioning" can limit the processor count; technologies classified as "soft partitioning" cannot.
The policy applies specifically to Oracle Database processor licensing, Oracle Middleware processor licensing (WebLogic, SOA Suite), and most Oracle technology products licensed on a Processor metric. It does not apply to Named User Plus licensing — NUP licensing counts users regardless of hardware. For enterprises that have moved to virtualised, consolidated infrastructure over the past decade, this policy is the source of the largest Oracle compliance gap in their estate.
Oracle's LMS audit scripts — specifically the USMM collection script — identify the virtualisation platform in use, the physical host topology, and the Oracle Database installations. When Oracle determines that a virtualised environment uses a soft partitioning technology, Oracle's position is that the license count must cover all physical processors in the physical host cluster that Oracle software could potentially access — not just the processors or cores allocated to the Oracle VM.
The VMware standard: Oracle's most commercially aggressive application of the Partitioning Policy is against VMware environments. VMware vSphere — the dominant virtualisation platform in enterprise data centers — is classified as soft partitioning. Oracle has maintained this position despite VMware's Distributed Resource Scheduler (DRS) being capable of hard-restricting VM movement. Oracle does not accept DRS configuration as hard partitioning.
Soft partitioning, in Oracle's definition, encompasses any partitioning or virtualisation technology where the allocation of processors to the Oracle software environment can be changed dynamically without physically reconfiguring hardware. The key characteristic is flexibility — soft partitioning technologies allow VMs to move between physical hosts, scale CPU allocations dynamically, or run Oracle workloads on hardware that also runs non-Oracle workloads.
Oracle's position on soft partitioning is that because the Oracle software could potentially run on any processor in the cluster — at any point in time, depending on workload scheduling — all processors in the cluster must be licensed. This is the "could be used" standard, as opposed to the "is being used" standard that would be more commercially reasonable from the buyer's perspective.
Oracle's official documentation lists soft partitioning technologies that include: VMware ESX/vSphere/vCenter, Microsoft Hyper-V, IBM PowerVM (in certain configurations), Xen (including AWS, Azure, and GCP hypervisor layers based on Xen), KVM-based virtualisation, Docker and container-based environments, Solaris Zones (non-certified configurations), and CPU affinity configurations that are not enforced at the hardware level. This list is not exhaustive — Oracle has claimed soft partitioning status for other technologies not explicitly listed, including newer container and Kubernetes environments.
Hard partitioning, according to Oracle's policy, refers to physical or logical partitioning mechanisms that "definitively limit the number of accessible processors" to Oracle software at the hardware level — where the limitation is enforced by hardware or firmware and cannot be overridden by software configuration. Hard partitioning is the only mechanism Oracle recognises for limiting the processor count in an Oracle Database processor license calculation.
Oracle's current approved hard partitioning technologies include: Oracle VM Server for SPARC (LDOMs/Logical Domains), Oracle VM Server for x86 (OVM) — specifically when Oracle-defined configuration requirements are met, IBM LPAR (Logical Partitions — Power series, in specific configurations), Fujitsu M10 PPAR (Physical Partitions), HP Superdome nPars, and physical server isolation (dedicated single-tenant hardware where Oracle is the sole workload). Oracle VM Server for x86 is particularly important because it is Oracle's preferred virtualisation solution for x86 environments and is deliberately designed to give Oracle licensing certainty — while creating a commercial incentive to use Oracle's own hypervisor over VMware.
Oracle VM complexity: Oracle VM Server for x86 qualifies as hard partitioning only when specific configuration requirements are met — including that Oracle VMs are not allowed to migrate to physical hosts that are not part of the licenced processor pool. If live migration is enabled across the full cluster without Oracle's pinning requirements, Oracle VM reverts to soft partitioning treatment. The configuration requirements must be verified and documented for Oracle audit purposes.
| Technology | Oracle Classification | License Scope | Notes |
|---|---|---|---|
| VMware vSphere/ESX | Soft Partitioning | All physical cores in cluster | Oracle does not accept DRS hard affinity as hard partitioning |
| Microsoft Hyper-V | Soft Partitioning | All physical cores in cluster | Including Windows Server 2022 virtualisation |
| KVM | Soft Partitioning | All physical cores in cluster | Including RHEV and oVirt |
| Docker / Containers | Soft Partitioning | All physical cores on host | Kubernetes scheduling makes this a cluster-wide issue |
| AWS (EC2) | Soft Partitioning | All physical cores on host hardware | BYOL on AWS = whole physical host if non-dedicated |
| Oracle VM Server for x86 | Hard Partitioning | Pinned vCPUs only | Requires Oracle-specified configuration; no unrestricted live migration |
| Oracle VM Server for SPARC (LDOMs) | Hard Partitioning | Assigned vCPUs only | Full hardware-level CPU isolation |
| IBM LPAR (Power) | Hard Partitioning | Assigned physical cores | Dedicated CPU mode; not shared LPAR |
| Bare metal (no virtualisation) | Hard Partitioning | Physical cores × Core Factor | Cleanest licensing position |
| AWS Dedicated Hosts | Hard Partitioning | All cores on dedicated host | Dedicated, single-tenant hardware — still counts all cores |
Our Oracle compliance review service maps your virtualisation topology against Oracle's Partitioning Policy to quantify your actual exposure. Know your risk before Oracle's LMS team does.
VMware vSphere is the dominant virtualisation platform in enterprise data centers. It is also the technology that creates the single largest Oracle licensing compliance risk in most enterprises' IT estates. Oracle's refusal to recognize VMware as hard partitioning — despite VMware's ability to hard-pin VMs to specific physical hosts — is one of the most contested positions in enterprise software licensing.
Oracle's commercial logic is clear: enterprises that consolidate Oracle Database onto shared VMware clusters would otherwise only pay for the few cores allocated to their Oracle VMs. Oracle's Partitioning Policy forces those enterprises to license all cores in the VMware cluster — which can be 4x to 20x the allocated core count, representing a proportional multiplier on the Oracle license bill. The Oracle Database Licensing on VMware article covers this in full detail with specific calculation examples.
Oracle's official position is that VMware does not provide sufficient guarantees of hardware-level isolation to qualify as hard partitioning. Oracle's argument is that even with DRS affinity rules, VMware can theoretically override those rules in certain cluster failure scenarios, meaning Oracle software is not definitively restricted to specific physical processors at all times. This is technically accurate but commercially convenient — the practical risk of Oracle software accessing unlicensed processors due to VMware failover is theoretical; the compliance bill for licensing the full cluster is real and immediate.
The financial impact of Oracle's Partitioning Policy on enterprises running Oracle Database in VMware environments is substantial. Consider a concrete example: an enterprise running Oracle Database Enterprise Edition on 4 VMware VMs, each with 4 vCPUs allocated, within a VMware cluster comprising 6 physical hosts, each with 2 × 20-core Intel Xeon processors.
| Scenario | Core Count | Core Factor | Processor Licenses | Annual Support (22%) |
|---|---|---|---|---|
| Oracle's "correct" count (soft partitioning) | 240 cores (6 hosts × 2 sockets × 20 cores) | 0.5 (Intel) | 120 Processor licenses | ~$2.64M/year |
| What enterprise believes they need | 16 vCPUs (4 VMs × 4 vCPU) | 0.5 (Intel) | 8 Processor licenses | ~$176,000/year |
| Compliance gap (annual) | 112 Processor licenses short | – | – | ~$2.46M/year exposure |
This example — which is representative of real-world VMware Oracle Database compliance gaps identified in LMS audits — illustrates why the Partitioning Policy is Oracle's most powerful audit tool. The enterprise believes it is licenced for 8 processors; Oracle claims 120. The gap is a $15–20M back-license claim plus 22% annual support going forward. The average Oracle audit claim in VMware environments is 3–5× what the customer believed they owed.
Oracle's LMS audit process specifically investigates the virtualisation topology of any environment where Oracle technology products are detected. The USMM collection scripts gather data on the hypervisor type, the physical host hardware, the number of physical sockets and cores per host, and the VM configuration. LMS analysts then compare the license count declared by the customer against the full physical core count of the cluster — under Oracle's soft partitioning interpretation.
Oracle's LMS teams have pre-built scripts that identify VMware environments, extract the vCenter topology (hosts, VMs, cluster membership), and produce a processor license calculation based on the full physical cluster rather than individual VM allocations. This calculation is presented to the customer in the audit findings report as Oracle's "position" — which is technically their opening commercial claim, not a settled legal determination.
Challenging the VMware soft partitioning claim in an LMS audit requires a combination of technical evidence (demonstrating specific DRS rules, VM pinning, or infrastructure isolation that limits Oracle's access in practice) and a commercial negotiation strategy that uses the gap between Oracle's claim and the customer's position as the basis for a settlement. Our audit defense team has successfully challenged VMware partitioning claims in multiple LMS audits — reducing claimed exposure by 40–70% in the most complex cases.
Enterprises that identify a soft partitioning compliance gap have several remediation paths, each with different cost and operational implications.
Replacing VMware with Oracle VM Server for x86 on the hosts running Oracle Database workloads eliminates the soft partitioning risk — but requires migration effort, retraining, and potentially higher operational management cost. Oracle VM Server is a technically capable hypervisor but lacks the enterprise management ecosystem of VMware vSphere. This option is most viable for dedicated Oracle Database infrastructure where the management overhead of running a separate hypervisor is acceptable.
Running Oracle Database on dedicated bare-metal servers with no virtualisation eliminates the partitioning question entirely — you license all physical cores on the dedicated host, but those cores are only running Oracle workloads. For high-performance Oracle Database deployments that don't require VM-level flexibility, bare metal is the cleanest licensing position.
Running Oracle BYOL on AWS Dedicated Hosts or OCI dedicated infrastructure provides single-tenant hardware where all cores are allocated to your Oracle workloads — you license all cores on the host, but the host is dedicated. This eliminates the cluster-wide licensing problem of shared VMware. Note that AWS Dedicated Hosts are not the same as AWS EC2 Dedicated Instances — only Dedicated Hosts provide the physical single-tenancy that Oracle's Partitioning Policy requires for hard partitioning treatment.
For enterprises that cannot operationally migrate away from VMware, negotiating a commercial settlement with Oracle that licenses the actual deployment scope — rather than the full cluster — is the most pragmatic short-term option. This requires a structured negotiation that challenges Oracle's cluster-wide license claim with evidence-based counter-arguments. The settlement typically involves purchasing additional processor licenses at a negotiated price that is significantly less than Oracle's back-license list price.
Oracle's Partitioning Policy is Oracle's policy — it is not a legally mandated standard or court-settled principle. It is Oracle's commercial interpretation of how its license terms should apply to virtualised environments. That means it is subject to negotiation, challenge, and commercial settlement. Enterprises that approach Oracle's soft partitioning claims as fixed facts — and accept Oracle's full cluster-wide license count without challenge — are conceding a commercial position that Oracle's LMS team knows is aggressive and often inflated beyond what Oracle would accept in a negotiated settlement.
Effective challenges to soft partitioning claims require: a precise technical inventory demonstrating actual VM allocation and host isolation, evidence that Oracle software cannot dynamically access the full cluster (through DRS hard affinity rules, dedicated cluster configurations, or other technical controls), a benchmarking analysis that shows what comparable organizations actually pay in VMware environments, and a commercial negotiation strategy that uses migration alternatives (Oracle VM, OCI) as leverage. The Oracle Virtualisation Compliance Guide covers the negotiation approach in detail.
A European healthcare group received an Oracle LMS claim of $6.2M based on full VMware cluster licensing for Oracle Database EE across 8 hosts. Our team produced a technical inventory demonstrating VM pinning configuration, challenged the LMS calculation, and negotiated a settlement that covered actual allocated cores plus a 20% buffer — reducing the claim to $1.4M. Read the full case study →
Complete analysis of Oracle's Partitioning Policy, technology classifications, audit risk calculations, and negotiation strategies for VMware and other virtualisation environments.
Download Free White Paper →Oracle audit risk updates, VMware licensing changes, and compliance strategies for enterprise IT and licensing teams.
We map your virtualised Oracle estate against Oracle's Partitioning Policy, calculate actual vs claimed exposure, and advise on the most cost-effective remediation path. Former Oracle insiders — 100% buyer-side.
Schedule a Compliance Review →Not affiliated with Oracle Corporation. Independent advisory only.