Oracle's soft partitioning rule for VMware is the single largest source of unexpected licence compliance exposure in enterprise IT. Most organisations running Oracle on VMware are under-licensed — often massively so — and don't know it until Oracle's LMS team appears. The Broadcom acquisition of VMware has added further complexity. This guide explains the rules, the risks, and the strategies for managing Oracle licensing on VMware.
Oracle's partitioning policy distinguishes between "hard partitioning" — virtualisation technologies that Oracle recognises as reliably limiting a programme's access to physical processor resources — and "soft partitioning" — all other methods, including VMware. For hard partitioning technologies (Oracle VM Server, Oracle Linux KVM, OCI, Solaris Zones, and IBM LPAR), the Oracle licence requirement is based on the allocated virtual processor count. For soft partitioning, Oracle requires licensing of all physical processor cores on the server or cluster where Oracle software is installed or running.
VMware vSphere, vCenter, and ESXi are explicitly classified by Oracle as soft partitioning. This means that for Oracle Database deployed on a VMware environment, Oracle's position is that every physical processor core in the VMware cluster hosting that Oracle VM must be licensed — not just the cores allocated to the Oracle VM. This is Oracle's published policy, and it is the position Oracle's LMS team enforces in audits.
The practical impact is severe. A VMware cluster with 10 physical hosts, each with 2× 32-core processors, has 640 physical cores. An Oracle Database VM in that cluster might be configured with 4 vCPUs. The organisation may believe it needs only 4 processor licences (multiplied by the core factor). Oracle's position is that the full 640 physical cores must be licensed. The licence shortfall in this scenario is enormous — and this scenario is extremely common in enterprise environments. This article is part of our broader Oracle license negotiation pillar guide.
If your Oracle Database, WebLogic, or Fusion Middleware products are deployed on VMware ESXi hosts in a shared cluster, you are almost certainly under-licensed under Oracle's published policy — regardless of how many vCPUs the Oracle VMs are configured with. This is one of the most common and most expensive Oracle compliance findings. Independent assessment before Oracle contacts you is strongly recommended.
The compliance exposure in Oracle-on-VMware environments stems from two compounding factors: Oracle's soft partitioning rule (which requires all physical cores in the cluster to be licensed) and the natural tendency for Oracle VMs to share infrastructure with non-Oracle workloads in the same VMware cluster. As VMware clusters grow over time — adding hosts to support other applications — the Oracle licence requirement grows correspondingly, even if the Oracle Database VM remains at the same vCPU count.
Want independent help negotiating better terms? We rank the top advisory firms across 14 vendor categories — free matching, no commitment.
The exposure is further compounded by Oracle's DRS (Distributed Resource Scheduler) policy. Oracle's LMS team argues that if VMware DRS is enabled on a cluster, Oracle's VMs can theoretically be migrated to any host in the cluster — meaning Oracle requires all hosts in the cluster to be licensed. Even with DRS disabled or constrained, Oracle may still assert the full cluster requirement depending on the vMotion capabilities and cluster topology.
Quantifying this exposure requires a detailed infrastructure analysis: mapping all VMware clusters, identifying which clusters host Oracle software of any kind, identifying all physical hosts in those clusters, and calculating the total physical core count. Our Oracle licence calculation guide covers the specific calculation methodology, including core factor tables. The result is frequently surprising — often revealing that the actual Oracle licence requirement is 5–20 times what has been purchased.
Setup: 4 hosts × 2 sockets × 16 cores = 128 physical cores. Oracle DB VM with 4 vCPUs.
Licences owned: 4 NUP or 2 processor licences (based on vCPU).
Oracle's claim: 128 × 0.5 core factor = 64 processor licences.
Setup: 20 hosts × 2 sockets × 32 cores = 1,280 physical cores. Multiple Oracle DB VMs.
Licences owned: Based on total vCPU count — perhaps 40 processor licences.
Oracle's claim: 1,280 × 0.5 core factor = 640 processor licences.
Broadcom completed its acquisition of VMware in late 2023 and subsequently made significant changes to VMware's commercial model — discontinuing perpetual licence sales, moving to subscription-only bundles (VMware Cloud Foundation), and restructuring the partner ecosystem. These changes have prompted many organisations to reassess their VMware infrastructure strategy, with some actively evaluating migration away from VMware to alternative hypervisors or to bare metal.
For Oracle licensing, the Broadcom changes create both risks and opportunities. The risk is that VMware migration projects undertaken without Oracle licensing expertise can inadvertently change the Oracle licence requirement in ways that create new compliance exposure — for example, migrating from VMware to a hypervisor that Oracle still classifies as soft partitioning, or migrating in a way that briefly runs Oracle on more physical hosts than are licensed.
The opportunity is that the Broadcom cost increases create business justification for infrastructure changes that could also reduce Oracle licence exposure — for example, migrating Oracle Database workloads to bare metal or Oracle VM, which eliminates the soft partitioning problem entirely. Organisations reviewing their VMware strategy because of Broadcom's changes should simultaneously assess the Oracle licensing implications of each infrastructure option. Our Oracle audit defense playbook provides context for how Oracle views VMware migration scenarios in an audit context.
If your organisation is moving away from VMware because of Broadcom's price increases, the Oracle licensing implications of each alternative hypervisor or infrastructure option must be assessed before the migration programme is committed. Some "cheaper" hypervisor options may not reduce — and may even increase — Oracle's licence claim on the same infrastructure.
Organisations seeking to reduce Oracle licence exposure from VMware have two primary hard partitioning options that Oracle explicitly recognises: Oracle VM Server (OVM) and Oracle Linux KVM (under specific conditions). Both provide Oracle recognition of the virtual allocation as the licensing boundary, dramatically reducing the Oracle licence requirement compared to VMware.
Get the IT Negotiation Playbook — free
Used by 4,200+ IT directors and procurement leads. Oracle, Microsoft, SAP, Cloud — all covered.
Oracle VM Server is Oracle's own hypervisor based on the Xen hypervisor technology. Oracle explicitly lists OVM as a hard partitioning technology, meaning Oracle Database licence requirements are based on the allocated vCPU count, not the physical host count. OVM is free to use but requires Oracle Linux or compatible guest OS, and has fallen behind VMware and KVM in terms of modern features and enterprise adoption.
Oracle Linux KVM (Kernel-based Virtual Machine on Oracle Linux) is recognised by Oracle as hard partitioning when specific configuration requirements are met — including the use of Oracle Linux as the hypervisor OS and specific Oracle tools for VM management. KVM on Oracle Linux is more modern than OVM and is Oracle's preferred virtualisation path for on-premises Oracle workloads. Migrating from VMware to Oracle Linux KVM, while operationally non-trivial, can dramatically reduce Oracle Database licence requirements.
Bare metal deployment — running Oracle Database directly on physical servers without a virtualisation layer — eliminates the partitioning issue entirely, with Oracle licence requirements based purely on the physical processor core count of the servers running Oracle. For some Oracle workloads, particularly high-performance Oracle Database deployments, bare metal may be the most straightforward and cost-effective solution to the VMware licensing problem. Our Oracle partitioning and licensing guide covers the technical and commercial details of all partitioning options.
Organisations with significant Oracle-on-VMware exposure have four main strategic paths: licence the full exposure (purchase sufficient Oracle licences to cover all physical cores in the relevant VMware clusters — expensive but immediately compliant); isolate Oracle on dedicated hosts (move Oracle VMs to a dedicated VMware cluster with no non-Oracle workloads, reducing the licensed core count to only the Oracle cluster); migrate to Oracle VM or Oracle Linux KVM (eliminate the soft partitioning problem by moving to a hard partitioning technology Oracle recognises); or migrate Oracle workloads to OCI (moving Oracle Database to Oracle Cloud eliminates the on-premises partitioning question entirely and provides BYOL economics — see our Oracle cloud migration credits guide).
The optimal path depends on the organisation's infrastructure strategy, Oracle commercial relationship, and cloud migration plans. A dedicated Oracle VMware cluster is often the fastest near-term fix — reducing the licensed scope to only the hosts in the Oracle cluster without requiring a hypervisor migration. OCI migration may be the right long-term answer for organisations already planning cloud migration, but it requires careful evaluation of OCI economics. Independent Oracle advisory is essential for selecting the right path. See our Oracle negotiation firm rankings for advisors with specific Oracle-on-VMware expertise.
Running Oracle on VMware? Get a compliance assessment before Oracle contacts you.
If Oracle's LMS team initiates an audit of an environment where Oracle runs on VMware, the organisation will almost certainly be presented with a large licence shortfall claim based on the full physical core count of the VMware cluster. The first step in managing this situation is to establish an independent compliance position — running the same analysis Oracle runs, but with full control over the inputs and the opportunity to argue the most favourable interpretation of the data.
Key arguments available in Oracle VMware audit situations include: challenging the cluster boundary (is every host in the alleged cluster actually accessible to Oracle — or are there network, DRS, or policy configurations that limit Oracle's reachability?); challenging the vMotion scope (can Oracle's VMs actually vMotion to every host Oracle claims, or is the environment configured to restrict this?); and identifying any hosts that were added to the cluster after the Oracle licence was purchased (in some cases, the licence can be argued to cover the configuration at the time of purchase).
None of these arguments will eliminate Oracle's claim entirely, but they can significantly reduce the shortfall Oracle asserts. Specialist Oracle advisory firms with specific Oracle-on-VMware audit experience, such as those ranked in our Oracle negotiation firm rankings, are essential in these situations. Our Oracle audit defense playbook and free audit defense guide provide the broader audit management framework.
The most commercially effective way to resolve a large Oracle-on-VMware exposure — whether discovered proactively or in an audit — is to convert it into an ELA negotiation. If the licence shortfall is large, an ELA that covers the full exposed product set may cost significantly less than purchasing the exact number of licences Oracle claims are required, while also providing unlimited deployment rights for a defined period that gives the organisation time to normalise its infrastructure.
Oracle's commercial team is often willing to negotiate ELA structures that resolve historical exposure as part of a forward-looking commercial relationship — particularly if the organisation is also willing to discuss OCI adoption or other Oracle revenue growth opportunities. This dynamic means that resolving Oracle-on-VMware exposure through an ELA negotiation is one of the most frequent scenarios where specialist Oracle advisory firms add the highest value. The negotiation must be structured by advisors who understand both Oracle's internal commercial incentives and the specific VMware exposure, to achieve the best possible outcome.
For broader Oracle optimisation context, see our Oracle licence optimisation guide and our Oracle ELA renewal negotiation guide. Download our free Oracle licensing guide for comprehensive reference on Oracle commercial strategy.
Oracle-on-VMware compliance exposure is one of the most financially significant risks in enterprise IT. Independent assessment before Oracle contacts you gives you the time and leverage to resolve it on your terms.