Oracle's hard partitioning policy is the single most consequential licensing rule for enterprises running Oracle Database in virtualised environments. When hard partitioning is present, Oracle licenses only the physical processor cores assigned to the Oracle workload. When hard partitioning is absent — when you're running Oracle Database on VMware, Hyper-V, or any other non-approved hypervisor — Oracle requires licenses for every physical processor core in the entire physical server cluster, regardless of how many cores Oracle actually uses. The difference between these two positions can represent millions of dollars in Oracle license cost. Understanding which partitioning technologies Oracle officially approves, why VMware doesn't qualify, and what your practical alternatives are, is the foundation of rational Oracle Database cost management.
Oracle's partitioning policy, documented in Oracle's public "Processor Core Factor Table and Partitioning" guidance, draws a binary distinction between hard partitioning and soft partitioning. Hard partitioning limits the number of processor cores that the Oracle software can access through a physical constraint — the software cannot exceed the physical boundary regardless of configuration. Soft partitioning limits core access through a configurable mechanism — VMware vCPUs, cgroups, processor affinity settings — that can be changed or overridden through software configuration.
Oracle's position is unambiguous: only hard partitioning allows you to license a subset of the physical processor cores in a server. Soft partitioning — regardless of how it's configured, how stable the configuration is in practice, or whether Oracle's software physically accesses more than the allocated cores — does not satisfy Oracle's hard partitioning requirement. You must license all the physical processor cores in the physical server (or physical server cluster, for technologies like VMware vSphere where VMs can migrate across hosts) on which Oracle software runs.
The commercial implication is substantial. An enterprise running Oracle Database Enterprise Edition on a VMware cluster with 10 two-socket servers, each with 32 physical cores (320 cores total), but with Oracle Database consuming only 8 vCPUs across 2 VMs, must license all 320 physical cores at the applicable Core Factor Table multiplier — not 8 vCPUs. At Oracle Database EE Processor metric pricing, the difference between 8-core licensing (on a hard-partitioned approved platform) and 320-core licensing (on VMware) is substantial — potentially representing a 40x differential in Oracle Database license cost.
See our detailed guide on Oracle soft vs hard partitioning licensing rules and the specific case analysis in Oracle Database licensing on VMware for the full compliance picture.
Oracle's approved hard partitioning list has remained relatively stable over the past decade, but the practical availability and enterprise adoption of each approved technology varies significantly. Understanding what is approved in theory versus what is actually deployed in enterprise environments is necessary for developing a rational Oracle Database infrastructure strategy.
IBM LPAR with Dedicated Mode is the most widely used hard partitioning technology for Oracle Database in enterprise environments. IBM's Logical Partitioning on AIX and IBM i systems assigns physical processor cores to a partition in dedicated mode — those cores are exclusively assigned to the LPAR and cannot be accessed by other LPARs or the system as a whole. Oracle accepts this as hard partitioning, allowing you to license only the cores assigned to the LPAR running Oracle Database. The IBM POWER platform carries its own Core Factor Table multipliers, and the economics of IBM LPAR Oracle licensing depend on the specific POWER generation and the applicable core factors.
Oracle VM Server for x86 with CPU pinning is Oracle's own hypervisor technology, based on the Xen hypervisor. When vCPUs are pinned to specific physical CPUs in Oracle VM — using Oracle VM's pCPU pinning feature — Oracle considers this hard partitioning and allows licensing of only the pinned physical cores. Oracle VM is free to use and supported by Oracle, but its market adoption is limited compared to VMware vSphere — most enterprises that run Oracle on-premise use VMware infrastructure for everything except deliberately separated Oracle Database servers.
Oracle Linux KVM with CPU Pinning is Oracle's supported alternative on commodity x86 hardware. Oracle Linux (Oracle's enterprise Linux distribution) with KVM hypervisor and specific CPU pinning configuration (using libvirt XML configuration to pin vCPUs to dedicated pCPUs) is accepted by Oracle as hard partitioning. This is a technically viable option for enterprises willing to standardize Oracle Database hosting on Oracle Linux infrastructure rather than VMware.
Oracle Solaris Zones with Dedicated CPU Pools applies to Oracle SPARC and x86 platforms running Oracle Solaris. Solaris Zones configured with dedicated processor pool resources are accepted as hard partitioning. This option is primarily relevant for enterprises running Oracle Database on Oracle SPARC hardware — a diminishing segment of the market but one where the Solaris + Oracle Database combination provides specific technical advantages for mission-critical workloads.
Oracle Cloud Infrastructure (OCI) is effectively hard-partitioned by design for Oracle licensing purposes. When you provision an Oracle Database Cloud Service instance or run BYOL Oracle Database on OCI compute shapes, Oracle licenses only the cores provisioned to the compute instance — not the underlying physical host. This is one of the genuine licensing advantages of OCI over AWS and Azure for Oracle Database BYOL deployments, where Dedicated Hosts are required to achieve equivalent per-core licensing.
Our Oracle compliance review identifies your virtualisation-driven license exposure and maps practical remediation options — before Oracle's LMS team arrives with a seven-figure back-license claim.
VMware vSphere's exclusion from Oracle's approved hard partitioning list is not a technical oversight — it is a deliberate commercial position that Oracle has maintained since at least 2008 and has repeatedly confirmed in policy updates. Oracle's stated technical rationale is that VMware's soft CPU affinity settings can be changed through the VMware administration layer without Oracle's knowledge, meaning Oracle cannot guarantee that Oracle Database is not accessing physical cores beyond those configured in the vCPU assignment.
Whether Oracle's technical rationale is entirely credible is a separate debate — VMware's CPU affinity pinning, when properly configured and change-managed, is effectively stable in practice. But Oracle's policy position is what creates the licensing obligation, not the technical reality, and that position has not changed despite VMware's significant technical evolution or repeated industry challenges to Oracle's stance.
The practical cost implication depends entirely on your VMware cluster architecture. If Oracle Database VMs can migrate — through vMotion, DRS (Distributed Resource Scheduler), or HA failover — across hosts in a vSphere cluster, Oracle's position is that you must license all physical cores in the entire cluster, because Oracle Database could potentially run on any host. This is the "cluster-level" Oracle licensing interpretation that creates the most severe license exposure for enterprises that have consolidated Oracle Database workloads onto large VMware clusters for operational efficiency reasons.
VMware DRS should be disabled for VMs running Oracle Database, and vMotion should be prevented from Oracle Database VMs in a VMware environment — but even these restrictions don't change Oracle's licensing position, because the underlying VMware infrastructure still constitutes soft partitioning regardless of whether vMotion is actively used for Oracle workloads. Oracle's LMS scripts will detect that the host is running VMware, and Oracle's audit position will claim all physical cores in the cluster.
The Oracle licensing on VMware guide covers this in detail including the specific LMS script queries that Oracle uses to identify VMware hosts and the contractual challenge framework for disputing Oracle's cluster-level licensing interpretation.
IBM LPAR remains the gold standard for Oracle-approved hard partitioning in enterprise environments. The majority of organizations that have genuinely addressed their Oracle Database virtualisation licensing through approved hard partitioning have done so on IBM POWER hardware with dedicated-mode LPARs. The technical implementation is mature, Oracle accepts it without dispute in audits, and IBM POWER's performance characteristics for Oracle Database workloads are well-established.
The commercial consideration for IBM LPAR: IBM POWER hardware carries a premium over commodity x86 servers, and IBM POWER Oracle Database licensing applies Core Factor Table multipliers that vary by POWER generation. For recent POWER10 systems, Oracle's Core Factor multiplier has been 1.0 per core — meaning each physical core counts as one Oracle processor license. This is the same multiplier as Intel x86 modern architectures, which means the IBM POWER premium is a hardware cost premium rather than a licensing cost premium.
Oracle Solaris Zones with dedicated processor pools is the approved route for enterprises already running on Oracle SPARC or Oracle x86 Solaris infrastructure. The licensing mechanics require careful documentation: the Zone must have a dedicated resource pool with a defined number of physical CPUs, and that configuration must be consistent at the time of any Oracle audit measurement. Dynamic resource adjustment — changing the number of CPUs assigned to a Zone — is permissible but must be tracked and documented because Oracle licenses the maximum number of cores accessible at any point, not the minimum or average.
Oracle VM Server for x86 (OVM) provides a technically Oracle-approved hard partitioning solution on standard x86 hardware — the same hardware category where most enterprise VMware deployments run. OVM's pCPU pinning feature, when correctly configured, pins guest vCPUs to specific physical CPUs and Oracle accepts this as hard partitioning. The operational model — Oracle VMs with Oracle Database, on Oracle Linux or Oracle Solaris, on Oracle VM infrastructure — creates a fully Oracle-supported stack that eliminates the VMware soft partitioning problem.
The challenge with Oracle VM adoption is operational: enterprises that have invested in VMware vSphere operational tooling, VMware management expertise, and VMware integration with their broader infrastructure management platforms face a real operational cost in migrating Oracle Database workloads from VMware to Oracle VM. Oracle VM's market share and ecosystem development significantly trail VMware vSphere, and OVM's operational model is sufficiently different from vSphere that the transition requires meaningful operational investment.
Oracle Linux KVM with CPU pinning is the more strategically attractive option for enterprises considering migration away from VMware for Oracle workloads. Oracle Linux is a fully supported RHEL-compatible enterprise Linux distribution, and KVM is the industry-standard open-source hypervisor that underpins most major cloud provider virtualisation infrastructures. The specific CPU pinning configuration that Oracle accepts as hard partitioning — documented in Oracle's partitioning policy — uses libvirt's vcpupin and emulatorpin XML configuration to bind vCPUs and the emulator to specific physical CPUs, preventing any Oracle Database CPU access outside the pinned allocation.
The Oracle Linux KVM approach is gaining adoption among enterprises seeking to reduce VMware license cost (particularly relevant after Broadcom's 2024 VMware acquisition, which significantly increased VMware licensing costs) while simultaneously resolving Oracle Database hard partitioning compliance requirements. Migrating Oracle Database from VMware vSphere to Oracle Linux KVM with CPU pinning addresses both the VMware cost increase and the Oracle Database licensing exposure simultaneously.
Enterprises with Oracle Database on VMware have four practical strategic options for addressing the licensing compliance exposure. Each has different technical, operational, and commercial implications, and the right choice depends on the specific Oracle Database estate, the VMware footprint, and the broader infrastructure strategy of the organization.
Option 1: Physical isolation of Oracle Database servers. The simplest and most immediate resolution is to move Oracle Database VMs off shared VMware clusters onto dedicated physical servers, removing the virtualisation layer entirely. Physical servers have no partitioning ambiguity — Oracle licenses exactly the physical cores on the server. The operational cost is the loss of VMware's high-availability, live migration, and resource management features for Oracle Database workloads, and the capital cost of dedicated physical hardware. This option is most appropriate for relatively small Oracle Database estates where the operational simplicity outweighs the infrastructure investment.
Option 2: Migration to Oracle Linux KVM with CPU pinning. For enterprises committed to x86 virtualisation for Oracle Database, Oracle Linux KVM with pCPU pinning provides an Oracle-approved hard partitioning solution on commodity hardware. The migration from VMware to Oracle Linux KVM requires virtualisation platform migration for Oracle Database VMs — a technical project of moderate complexity for most Oracle Database configurations. The operational model changes meaningfully (from vSphere to KVM management tooling), but the fundamental virtualisation architecture is preserved.
Option 3: Migration to Oracle Cloud Infrastructure (OCI). For enterprises considering Oracle Database cloud migration, OCI's BYOL model provides Oracle-approved per-core licensing on OCI compute instances — functionally equivalent to hard partitioning from a licensing perspective. Oracle Database on OCI BYOL with existing on-premise Processor licenses can substantially reduce the total Oracle database infrastructure cost while simultaneously resolving VMware soft partitioning compliance risk. The BYOL to OCI licensing guide covers the specific mechanics of this transition.
Option 4: Oracle Database Standard Edition 2 on VMware. Oracle Standard Edition 2 is licensed per-server-socket rather than per-processor-core, and the soft partitioning policy applies differently — SE2 is limited to 2 sockets per server regardless of virtualisation. For Oracle Database deployments where SE2 meets the technical requirements (no RAC, no specific EE-only features), migrating from Oracle Database Enterprise Edition on VMware to SE2 on VMware changes the exposure profile entirely: the socket-based limit applies on the virtual server rather than the physical host cluster. This option requires careful technical assessment to confirm SE2 is functionally equivalent for each workload.
Our Oracle license optimization service includes a virtualisation architecture review that addresses both problems — and identifies the lowest-cost compliant path for your specific Oracle Database estate.
When Oracle's LMS audit team discovers Oracle Database running on VMware, their standard position is to calculate license exposure across all physical processor cores in the VMware cluster on which Oracle Database VMs are hosted. This calculation is presented in the audit findings as a compliance gap between current licensing and Oracle's claimed requirement — and the back-license claim amount is typically calculated at Oracle's list price for the exposure period.
The audit defense opportunity exists at two levels. First, the factual dispute: Oracle's LMS scripts must accurately identify the actual VMware cluster scope, the number of physical hosts, the Core Factor Table applicable to those hosts, and the period during which Oracle Database was deployed on those hosts. Each of these inputs is challengeable if Oracle's data collection was incomplete, if host configurations changed during the audit period, or if Oracle's cluster boundary determination was inaccurate.
Second, the contractual dispute: Oracle's partitioning policy is a policy document, not a contractual obligation in Oracle's standard license agreement. The obligation in the license agreement is to license Oracle software for all processors on which Oracle software runs. The interpretation of "processor on which Oracle software runs" in a VMware environment is not as unambiguous as Oracle's account teams suggest — and has been the subject of dispute in several high-profile Oracle audit challenges. Our Oracle audit defense service includes forensic analysis of the contractual position before any compliance settlement is accepted.
For the complete audit defense framework including VMware-specific strategies, see the Oracle Audit Guide and the Oracle audit defense playbook.
The commercial decision about how to manage Oracle Database on VMware is fundamentally a risk and cost management question. The options exist on a spectrum from accepting the current soft partitioning risk (betting that Oracle doesn't audit, or that any audit claim will be successfully challenged) to fully remediating the exposure through hard partitioning or migration to an Oracle-approved platform.
The risk of inaction is material and growing. Oracle's audit frequency has increased consistently since 2020, and VMware-related Oracle Database licensing is one of Oracle's most productive audit categories — the potential back-license exposure per audit target is high, and Oracle's LMS scripts detect VMware environments automatically. Organizations that have significant Oracle Database estates on VMware but have not audited this exposure internally are carrying an undisclosed financial liability that will be discovered either through an Oracle audit or through the due diligence of any acquisition or IPO process.
The cost of remediation depends on the approach. Physical isolation requires hardware investment but zero Oracle license cost change. Oracle Linux KVM migration requires operational investment but can be combined with other infrastructure refresh programs. OCI migration requires cloud commitment but can achieve net positive commercial outcomes through BYOL license credit application. SE2 migration requires technical assessment but may be the simplest path for workloads that don't require EE features.
For a structured analysis of your specific Oracle Database and VMware estate, our Oracle license optimization service provides the forensic inventory, compliance gap quantification, and remediation cost modelling that turns this question from a strategic worry into a manageable program with quantified commercial outcomes. The case study on a logistics company's Oracle Database consolidation — which included VMware compliance resolution — demonstrates the commercial outcome that structured remediation achieves.
The complete guide to Oracle Database licensing in VMware, Hyper-V, KVM, and cloud environments — including the approved partitioning list, audit exposure modelling, and remediation strategies.
Download Free White Paper →Weekly Oracle licensing briefing covering audit trends, partitioning policy changes, and infrastructure cost reduction strategies for enterprise Oracle environments.
A confidential virtualisation compliance assessment quantifies your Oracle Database VMware exposure, models the cost of each remediation pathway, and identifies your lowest-risk route to a defensible license position.
Schedule a Virtualisation Assessment →