Oracle Partitioning Rules: VMware, Hyper-V and Cloud Licensing Explained

Hard Partitioning vs Soft Partitioning: The Fundamental Distinction

Oracle's partitioning policy draws a binary distinction between hard partitioning and soft partitioning. Hard partitioning technologies physically or at the firmware level prevent Oracle software from being executed on processors outside the assigned partition, and Oracle accepts these technologies as limiting the Processor licence obligation to the assigned cores. Soft partitioning technologies — regardless of how effective they are at restricting VM access to host resources — do not limit Oracle's licensing requirement, because Oracle's position is that the software could potentially access the physical processors and therefore all physical processors must be licensed.

This policy has been Oracle's consistent position since it was first published in 2000. It has not changed in response to the widespread adoption of VMware in enterprise data centres or the emergence of major cloud providers. Oracle considers the policy to be a function of its licence terms — specifically, the definition of "Processor" in the Oracle Master Agreement — rather than a technical determination. The practical consequence is that Oracle's licensing obligation is determined by Oracle's policy document, not by what an enterprise believes its virtualisation technology accomplishes.

The VMware Rule: Full Physical Host Licensing

Oracle classifies VMware ESXi, vSphere, vCenter, vSAN, NSX, and all related VMware virtualisation products as soft partitioning. This means that any Oracle Technology product (Database, WebLogic, SOA Suite, or any other Oracle middleware or platform product) running in a VMware VM requires Processor licences for all physical cores in the server hosting the VM — regardless of vCPU allocation, regardless of VM isolation settings, and regardless of the number of VMs on the host.

The vMotion Cluster Extension

The VMware licensing requirement extends beyond the single host where an Oracle VM is currently running. If VMware vMotion (live VM migration) is enabled in the vSphere cluster, Oracle's position is that the Oracle software could potentially run on any host in the cluster — and therefore all hosts in the cluster must be licensed. The same applies to VMware DRS (Distributed Resource Scheduler) and HA (High Availability), which automate VM migration between hosts. A VMware cluster with 8 hosts, each with 2-socket Intel Xeon servers and 32 cores per socket, would require 8 × 64 cores × 0.5 core factor = 256 Processor licences for a single Oracle Database VM with vMotion enabled.

How to Contain the VMware Licence Scope

The only way to limit Oracle's licensing scope to a subset of VMware hosts is to: disable vMotion, DRS, and HA for the Oracle VM (preventing any automated migration to unlicensed hosts); implement VM-Host affinity rules in vCenter that pin the Oracle VM to specific licensed hosts; document this configuration formally; and be prepared to demonstrate it to Oracle LMS during an audit. Oracle does not accept verbal assurances that vMotion is disabled — it requires technical evidence. Most Oracle-knowledgeable enterprises maintain a dedicated Oracle VMware cluster — physically separated VMware hosts licensed in full, running only Oracle workloads — to contain the licensing perimeter.

Hyper-V, KVM, and Other Hypervisors

Microsoft Hyper-V, Red Hat KVM, Citrix XenServer, and all other non-Oracle hypervisors are classified as soft partitioning under Oracle's policy. The same full physical host licensing requirement applies. Enterprises running Oracle Database on Hyper-V in an Azure Stack or on-premises Windows Server environment face identical Oracle licensing exposure to VMware deployments.

The Broadcom acquisition of VMware in 2023 and subsequent VMware licensing changes have prompted many enterprises to evaluate migration to KVM or other hypervisors. From an Oracle licensing perspective, this migration offers no benefit — Oracle's policy applies equally to all non-Oracle hypervisors. Enterprises migrating away from VMware due to Broadcom pricing changes should factor Oracle's unchanged partitioning policy into their infrastructure decisions, as the Oracle licensing exposure remains constant regardless of the hypervisor chosen.

Cloud Partitioning: AWS, Azure, and GCP Rules

Oracle's approach to cloud infrastructure licensing has evolved to accommodate the commercial reality that most enterprises run workloads on major cloud providers. Oracle has established specific rules for AWS, Azure, and GCP that differ from its on-premises soft partitioning rules in important ways.

The cloud-specific rule (2 vCPUs = 1 Processor licence) is significantly more favourable than the on-premises full-physical-host rule for most workloads. A workload that would require 32 Processor licences on-premises (64 physical cores × 0.5 core factor) requires only 8 Processor licences on AWS if deployed in instances with 16 vCPUs (16 vCPUs ÷ 2 = 8 Processor licences). This cost advantage is part of Oracle's strategic incentive to move customers to OCI or to run Oracle on AWS/Azure under Oracle's BYOL model, both of which generate Oracle revenue.

Oracle-Accepted Hard Partitioning Technologies

Oracle accepts the following technologies as hard partitioning that limits the Processor licence obligation to the assigned partition:

The Financial Impact: Real-World Cost Scenarios

The financial stakes of Oracle's VMware licensing rule are substantial and frequently underestimated. Consider a representative mid-enterprise Oracle environment: Oracle Database Enterprise Edition running in VMs on a 4-host VMware vSphere cluster, each host a dual-socket Intel Xeon server with 32 cores per socket.

The enterprise's assumption: 4 VMs × 4 vCPUs each = 16 vCPUs ÷ 2 (core factor equivalent) = 8 Processor licences. Annual support cost at 60% discount: 8 × $4,180 = $33,440.

Oracle's calculation: 4 hosts × 64 physical cores × 0.5 core factor = 128 Processor licences (+ vMotion cluster extension). Annual support cost at 60% discount: 128 × $4,180 = $535,040 per year.

The gap — $501,600 per year in support costs, compounded over 5 years plus the perpetual licence cost differential — represents a potential $2.5M+ LMS audit finding based solely on the VMware partitioning rule. We have seen audit findings ten times this scale in large enterprise environments with dozens of Oracle Database VMs spread across multiple VMware clusters.

Five Strategies to Manage Oracle-VMware Licensing Risk

1. Isolate Oracle VMs on Dedicated, Licensed VMware Hosts

The most pragmatic approach for enterprises already running Oracle on VMware is to create a dedicated Oracle VMware cluster — a defined set of VMware hosts whose total physical core count is fully licensed for Oracle. Disable vMotion between the Oracle cluster and non-Oracle VMware infrastructure. Implement DRS rules to prevent Oracle VMs from migrating out of the licensed cluster. Document this configuration and maintain it through all infrastructure changes. This approach accepts Oracle's VMware rule but contains the financial exposure to a defined, controlled hardware footprint.

2. Migrate Oracle to Bare Metal or Oracle VM

For enterprises willing to invest in infrastructure change, migrating Oracle workloads from VMware to bare-metal servers or Oracle VM (OVM) eliminates the soft partitioning exposure entirely. Bare-metal Oracle deployments are licensed based on the physical server's core count — typically much smaller than the VMware cluster it would otherwise require licensing for. Oracle VM, while technically limiting, is rarely chosen for new deployments due to its limited ecosystem support compared to VMware.

3. Migrate to OCI or Cloud under Oracle's Cloud Rules

Moving Oracle workloads to OCI, AWS, Azure, or GCP can significantly reduce the Processor licence count. On OCI, Oracle charges per OCPU (1 OCPU = 1 Processor licence), and BYOL discounts on OCI infrastructure are substantial. On AWS and Azure, the 2-vCPU = 1 Processor rule reduces the licence count relative to VMware physical host licensing. Oracle Cloud migration discussions also create leverage in on-premises renewal negotiations, as Oracle values cloud commitments and will offer meaningful concessions to avoid losing the on-premises licence revenue.

4. Negotiate a Custom VMware Licensing Agreement

For enterprises with large Oracle-VMware environments where a full true-up would be commercially prohibitive, negotiating a custom agreement — often structured as a ULA or ELA that covers the VMware environment at an agreed processor count — can resolve the compliance risk without accepting Oracle's LMS calculation at list price. Oracle is willing to negotiate VMware licensing arrangements for large accounts, particularly when the enterprise can demonstrate a credible migration path to OCI or commits to a multi-year Oracle spend level. See our Oracle ULA negotiation guide for how these structures work.

5. Perform a Pre-Audit Position Assessment

If your Oracle-VMware environment has never been formally assessed against Oracle's partitioning rules, conducting a proactive internal licence position review is essential before Oracle initiates an audit. The assessment calculates your true licence position under Oracle's rules, identifies the gap between your contracted licences and Oracle's requirement, and provides a basis for either remediating the gap (purchasing additional licences at renewal pricing rather than audit pricing) or challenging Oracle's methodology through a negotiated resolution. Our Vendor Audit Defence team conducts these assessments independently of Oracle, allowing you to understand your position before Oracle's LMS team does.

For comprehensive Oracle licensing guidance, including ULA negotiation, support cost reduction, and compliance strategy, see our Complete Guide to Oracle Licensing & Contract Negotiation. The Oracle Negotiation Playbook includes VMware-specific negotiation frameworks and discount benchmarks from enterprises that have successfully managed their Oracle-VMware licensing exposure.