Oracle's processor-based licensing model requires a customer to licence every physical processor in a server running Oracle software. This is straightforward in bare-metal environments. In virtualised environments — which now account for the majority of Oracle Database and Middleware deployments — the question of how many processors need to be licensed is governed by Oracle's partitioning policy, a document that Oracle maintains on its website but interprets aggressively in audit contexts.
The fundamental issue: if you are running Oracle Database on VMware — which the majority of enterprises do — Oracle's partitioning policy requires you to licence all physical processors in every VMware host in the cluster where Oracle is running, regardless of how many virtual CPUs you have assigned to the Oracle VM. This is because Oracle considers VMware to be "soft partitioning," which does not limit Oracle's licence exposure. The commercial impact of this interpretation can be enormous: an enterprise running Oracle on a 20-host VMware cluster with dual 32-core processors per host faces a licence requirement for 40 sockets × 32 cores × 0.5 (Oracle's core factor for modern processors) = 640 processor licences for Oracle, even if Oracle is actually running on a fraction of that capacity.
This article is part of our Complete Oracle Licensing Guide. For the audit implications of partitioning gaps, see Oracle Audit Defence. For cloud-specific Oracle licensing, see Oracle on AWS BYOL.
Hard Partitioning vs. Soft Partitioning: The Core Distinction
Oracle's partitioning policy draws a bright line between two categories of virtualisation technology:
Hard partitioning is defined as partitioning that "physically bounds the number of processors" available to Oracle software. When hard partitioning is used, Oracle's licence requirement is limited to the number of processors in the hard partition — not the physical server. Hard partitioning is Oracle's approved model for limiting licence exposure in virtualised environments.
Soft partitioning covers any mechanism that allocates processors to a virtual environment without physically restricting Oracle's ability to use additional processors. Under Oracle's policy, soft partitioning does not limit licence requirements — the customer must licence all physical processors in the physical server regardless of the virtual processor allocation.
VMware is explicitly classified as soft partitioning: Oracle's partitioning policy document specifically lists VMware as a soft partitioning technology. This means enterprises running Oracle on VMware must licence all physical processors in the VMware host(s) — with no reduction for vCPU limits, DRS rules, or any other VMware-based capacity constraint. This is not Oracle's interpretation — it is Oracle's stated policy, published on their website.
Oracle's Approved Hard Partitioning Technologies
Oracle maintains a list of technologies that qualify as hard partitioning for licence metric purposes. As of 2026, the approved hard partitioning technologies include:
| Technology | Hard Partition? | Notes |
|---|---|---|
| Oracle VM Server for SPARC (LDOM/LPAR) | Yes | SPARC hardware only |
| Oracle VM Server for x86 | Yes | Oracle's own x86 hypervisor |
| Sun Solaris Containers / Zones | Yes | Solaris OS only |
| IBM LPAR (PowerVM) | Yes | IBM Power hardware only |
| IBM Micro-Partitioning | Yes | IBM Power hardware only |
| HP vPars / nPars | Yes | HP hardware only |
| Fujitsu SPARC Enterprise Partitioning | Yes | Fujitsu hardware only |
| VMware vSphere / ESXi | No | Soft partition — all physical processors must be licensed |
| Microsoft Hyper-V | No | Soft partition — all physical processors must be licensed |
| KVM / QEMU | No | Soft partition — all physical processors must be licensed |
| Docker / Containers (non-Solaris) | No | Soft partition — all physical processors must be licensed |
| AWS EC2 (standard) | No | BYOL requires 2 vCPUs = 1 physical core for most shapes |
| Azure (standard) | No | Same vCPU counting applies |
The practical implication of this list is that the dominant enterprise virtualisation platform — VMware — does not qualify for hard partitioning, while Oracle's own VM technology does. This creates a persistent commercial incentive for Oracle to identify VMware-based Oracle deployments in customer environments during audits.
The VMware Compliance Exposure: How It Accumulates
VMware Oracle compliance exposure typically accumulates gradually and often without the knowledge of the IT teams managing Oracle deployments. Several common scenarios create exposure:
vSphere DRS and VM Migration
VMware's Distributed Resource Scheduler automatically migrates virtual machines across hosts to balance load. When Oracle VMs are eligible for DRS migration — which is the default configuration — Oracle's partitioning policy interprets all hosts in the DRS cluster as potentially running Oracle software, requiring all processors in all cluster hosts to be licensed. Many enterprises have Oracle running on a 4-host cluster within a 20-host vSphere cluster and have no awareness that Oracle is treating the entire 20-host cluster as in-scope for licensing.
The mitigation for this specific scenario is to create a dedicated Oracle cluster with hard boundaries — typically a small cluster of hosts running only Oracle workloads, managed separately from the broader vSphere environment. This does not change the fundamental soft partitioning classification of VMware, but it reduces the physical processor count that needs to be licensed by removing Oracle VMs from the broader cluster.
vMotion and Snapshot Operations
Live migration (vMotion) of Oracle VMs to a new host — even temporarily for maintenance — technically exposes all physical processors of the destination host under Oracle's rules. In practice, Oracle's audit focus is on the steady-state environment rather than transient migrations, but enterprises operating under an active ULA or approaching ULA certification should document and control vMotion events involving Oracle VMs.
Development and Test VMware Environments
Development, test, and staging environments running Oracle on VMware are subject to the same partitioning rules as production environments, unless the licence agreement explicitly provides for non-production use. Oracle's standard licence agreements require separate licensing for non-production Oracle deployments, and many enterprises significantly undercount their VMware-hosted development Oracle estate.
The financial scale of VMware compliance exposure: An enterprise running Oracle Database Enterprise Edition (licensed at $47,500 per processor in 2026) on a 10-host VMware cluster with 2 × 16-core processors per host faces a licence requirement for 10 × 2 × 16 × 0.5 = 160 processor licences. At Oracle list price, that is $7.6M for licences — plus 22% annual support ($1.67M/year). Enterprises in this situation frequently have actual Oracle deployments on 2–3 hosts, with the remaining capacity owed under Oracle's interpretation of the partitioning policy.
Mitigation Strategies for VMware Oracle Environments
Oracle VM Server for x86
Oracle's own virtualisation platform — Oracle VM Server for x86 — qualifies as hard partitioning. Migrating Oracle workloads from VMware to Oracle VM eliminates the VMware compliance exposure. This migration is technically straightforward for workloads that are already virtualised, but carries operational trade-offs: Oracle VM lacks many of VMware's enterprise management features and its commercial ecosystem is significantly smaller. For organisations whose primary concern is Oracle compliance, however, Oracle VM is the most direct technical solution.
Physical Servers or Dedicated Hosts
Running Oracle on bare-metal physical servers eliminates virtualisation licensing questions entirely. Licensing a dedicated physical server requires licensing only the processors in that server — no cluster-wide counting applies. Modern high-core-count processors (AMD EPYC, Intel Xeon Scalable) mean that bare-metal Oracle deployments can achieve significant consolidation ratios without triggering the VMware cluster-wide exposure.
Oracle-Dedicated VMware Cluster
While this does not change Oracle's soft partitioning classification of VMware, creating a small dedicated Oracle cluster — containing only Oracle VMs and isolated from the broader vSphere environment — minimises the processor count in scope for Oracle licensing. This is the most common pragmatic mitigation for enterprises committed to VMware as their virtualisation platform.
Cloud Migration as Compliance Management
Moving Oracle workloads to OCI or using Oracle's cloud licence portability provisions can reframe the licensing model from physical processor counting to cloud-specific metrics. Oracle's cloud on-premises model (Bring Your Own License to OCI) uses Oracle's cloud core factor, which is generally more favourable than the VMware physical processor counting. See our guide to Oracle on AWS BYOL for the full cloud licensing picture.
Oracle Audit and VMware: What to Expect
Oracle LMS audit scripts are specifically designed to identify Oracle software installed on VMware hosts and to enumerate all physical processors in the relevant VMware cluster. The output typically reflects the full-cluster processor count rather than the vCPU allocation — which is Oracle's intended interpretation. When reviewing Oracle audit findings related to VMware, the key questions are: what is the scope of the VMware cluster as Oracle defines it; whether any DRS policies or host affinity rules reduce the applicable cluster; and whether any aspects of the deployment configuration constitute hard partitioning arguments that Oracle has not acknowledged.
Specialist advisory is particularly valuable in VMware-related Oracle audit findings because the technical and contractual arguments around cluster scope, DRS configuration, and partitioning policy interpretation require expertise in both Oracle licensing and VMware architecture. For related guidance on audit defence, see our Oracle Audit Defence Guide and our Audit Defence Handbook.