Oracle VMware licensing is the costliest misunderstanding in the enterprise data center. Oracle classifies VMware as a soft partition, which means it ignores where your VMs actually run and counts every physical host they could reach. This guide breaks down hard versus soft partitioning, why Oracle's policy isn't even in your contract, and the containment strategies that survive an LMS audit.
Short answer Oracle VMware licensing requires you to license every physical host an Oracle VM can reach, because Oracle treats VMware as a soft partition that does not limit the processor count. A single Oracle Database VM in a 20-host cluster obligates all 20 hosts — not the one it runs on.
Definition Oracle VMware licensing is the set of rules Oracle applies when its products run inside VMware virtual machines. Because Oracle counts every processor a VM can potentially use, running Oracle on shared VMware infrastructure typically obligates far more licenses than the workload actually consumes.
Oracle licenses its database and middleware by the Processor metric. A Processor is Oracle's unit of physical compute: physical cores multiplied by the Core Factor from Oracle's Core Factor Table. On bare metal this is simple — you count the cores in the server and apply the factor. Inside VMware it stops being simple, because Oracle refuses to count the cores allocated to your VM. Instead it counts the cores of every host the VM is permitted to migrate to.
This is not a technical accident. It is Oracle's deliberate position, and it is the single most profitable finding Oracle's LMS (License Management Services) and GLAS (Global Licensing and Advisory Services) teams pursue. The gap between what a customer believes they owe — the cores their Oracle VMs use — and what Oracle claims they owe — every core in reach — is where seven-figure back-licence claims come from. Understanding the mechanics is the difference between a routine deployment and an audit exposure that exceeds your total historical Oracle spend.
Short answer A hard partition is a physical or firmware boundary Oracle accepts as limiting the processor count to specific hardware. A soft partition is any software mechanism — like VMware — that Oracle refuses to accept, on the basis that the workload could still reach the wider hardware pool.
Hard partitioning is a technology that physically segments a server's processors so that an Oracle workload can only ever run on a defined subset of cores. Oracle's approved list is narrow: physical bare-metal isolation, IBM LPAR with dedicated processors on Power Systems, Oracle VM Server for x86 (OVM) configured for hard partitioning, Oracle Linux KVM with hard partitioning, Solaris Zones with capped CPU pools, and Oracle VM Server for SPARC (LDoms). When you use one of these, Oracle counts only the cores inside the partition.
Soft partitioning is everything else — VMware vSphere, ESXi, Microsoft Hyper-V, Nutanix AHV, generic KVM, and Xen. Oracle's reasoning is that these hypervisors let a VM migrate, fail over, or be rescheduled onto other hosts, so the workload "could" use the whole pool. Oracle therefore counts the whole pool. The distinction has nothing to do with how you actually configure the environment and everything to do with which technology vendor's name is on the hypervisor. This is Oracle's playbook: define the boundary in the way that maximises the license count, then defend it in audit.
| Technology | Oracle treatment | What gets counted |
|---|---|---|
| Bare metal (no hypervisor) | Hard | Cores in that server only |
| IBM LPAR (dedicated CPUs) | Hard | Cores in the partition |
| Oracle VM Server / OVM (capped) | Hard | Pinned cores only |
| Solaris Zones (capped pool) | Hard | Capped CPU pool |
| OCI Dedicated Host / Exadata | Hard-equivalent | Dedicated physical host |
| VMware vSphere / ESXi | Soft | Every host in reach |
| Hyper-V, Nutanix AHV, KVM, Xen | Soft | Every host in reach |
Short answer Oracle's position is that you must license every physical host an Oracle VM can migrate to. For VMware 6.x that means the entire cluster; for VMware 7.0 and later Oracle extends the claim to every host that shares storage or networking — in the worst case, the whole vCenter.
The counting boundary has expanded over time, and Oracle's audit teams update their argument as VMware adds mobility features. With VMware 5.x, Oracle's claim was contained to a single ESX cluster. With vSphere 6.0, cross-vCenter vMotion let a VM move between vCenter Server instances, and Oracle began arguing that any cluster reachable by vMotion was in scope. With vSphere 7.0, Oracle's most aggressive auditors assert that shared storage and shared networking alone make every connected host a counting target — because a VM's disk files are visible across the estate.
What this means in practice: an enterprise that deployed Oracle Database on two physical servers' worth of VMs, inside a shared 20-host cluster, faces an Oracle claim for all 20 hosts. If those 20 hosts share a vCenter with 60 more, the most aggressive Oracle argument reaches 80. This escalation is not settled law — it is Oracle's negotiating position, and it can be pushed back on with forensic evidence of the actual storage and network topology. But you cannot push back on a claim you did not see coming.
The vCenter trap. Consolidating multiple clusters under one vCenter for operational convenience is exactly the configuration Oracle's LMS scripts are built to detect. Keep Oracle workloads on a separate vCenter with isolated storage and networking, or you hand Oracle the argument that your entire virtual estate is in scope.
Short answer No. The Oracle Partitioning Policy is a non-contractual PDF Oracle publishes and revises unilaterally. Standard Oracle ordering documents and the Master Agreement do not reference it, which is the legal foundation for challenging Oracle's full-cluster VMware claim.
This is the fact Oracle's sales and audit teams least want you to internalise. The "Oracle Partitioning Policy" is an educational document on Oracle's website. It is not an exhibit to your Ordering Document, it is not incorporated by reference into your Oracle Master Agreement (OMA) or Oracle License and Services Agreement (OLSA), and Oracle can — and does — change it without notifying customers. A document that defines a multi-million-dollar obligation, yet sits outside the contract, is a document you are entitled to challenge.
Your actual contractual obligation is to license the processors on which the Oracle programs are "installed and/or running." Oracle interprets "running" expansively to mean "capable of running." That interpretation is contestable, and it has been contested — most prominently in disputes where customers argued that a VM pinned by configuration was not "running" anywhere it had not actually executed. We use this gap deliberately: our Oracle audit defense team builds the evidence-based case that your contract, not Oracle's policy PDF, defines what you owe. For the full contractual framework, see the Oracle Database Licensing Guide.
Short answer No. Oracle's LMS team rejects VMware DRS host affinity rules because they are advisory — the hypervisor can override them during High Availability events. Affinity rules are not a hard partition and offer no protection in an Oracle audit.
Many enterprises try to contain Oracle exposure by creating a DRS "must run on hosts" affinity rule that pins Oracle VMs to a subset of the cluster. It feels like a partition. It is not one. VMware HA can ignore affinity rules when a host fails, and Oracle knows this — its collection scripts specifically capture your DRS and affinity configuration so the audit team can document that you relied on a mechanism Oracle considers invalid. The configuration you built to protect yourself becomes evidence against you.
This is why "soft" matters. A hard partition limits what is physically possible; a soft partition only limits what normally happens. Oracle licenses on the basis of what is possible. The only affinity-style approach Oracle has, at times, conceded is full physical separation — a cluster whose hosts are not shared with any non-Oracle workload and whose storage and networking are isolated. Even then, the safest position is a genuinely separate cluster, not a rule inside a shared one. Before you rely on any containment design, have it reviewed: our compliance review stress-tests each configuration against Oracle's actual audit methodology.
Short answer A single Oracle Database VM in a large shared cluster routinely creates an eight-figure gap. A 20-host cluster with 64 cores per host produces 640 Processors of obligation — over $28M at list for Database Enterprise Edition before support.
The arithmetic is brutal once you follow Oracle's counting rule to its conclusion. Take a 20-host vSphere cluster, each host with two 32-core CPUs (64 cores), at the standard x86 Core Factor of 0.5. That is 20 × 64 × 0.5 = 640 Oracle Processors. At the Database Enterprise Edition list price of $47,500 per Processor, that is $30.4M in licenses before a single option pack. Even at a typical 50% enterprise discount the figure clears $15M, and Oracle's Enterprise Support adds 22% of net license value every year on top.
| Line | Calculation | Result |
|---|---|---|
| Processors Oracle counts | 20 hosts × 64 cores × 0.5 | 640 Processors |
| What you believed you owed | 2 servers × 64 cores × 0.5 | 64 Processors |
| Database EE (50% discount) | 640 × ~$23,750 | $15.2M |
| Annual support | 22% of net license value | $3.3M / yr |
| Compliance gap | 576 Processors over-counted | ~$13.7M exposure |
This is the structural reason VMware over-counting drives roughly 3.2× the licensed processor position in the environments we audit (Oracle Licensing Experts, 2026). The good news: most of that gap is a negotiating artefact, not a real obligation, because it rests on a non-contractual policy and an expansive reading of "running." We have reduced VMware-driven audit claims by an order of magnitude — see the healthcare compliance remediation case study, where a $22M VMware claim settled at $1.8M through evidence-based technical challenge.
We map every Oracle product against your actual VMware topology, apply the Core Factor Table, and separate Oracle's negotiating claim from your true contractual obligation. Our compliance review has found containable VMware exposure in the large majority of enterprise environments assessed.
Short answer Use physical isolation. A dedicated Oracle-only cluster with separate storage and networking, bare-metal servers, or OCI/cloud dedicated hosts each limit Oracle's processor count to a defined boundary Oracle accepts — instead of the whole shared estate.
There are five defensible moves, in rough order of cost and certainty:
Whichever route you choose, sequence it before any audit notice arrives, and never submit VMware collection-script output to Oracle without independent review — the cluster topology in that output defines the scope of Oracle's claim. If an audit is already underway, our audit defense and contract negotiation teams take it from here. Start with a confidential consultation or return to the Oracle Licensing Experts home page to see the full advisory.
No. Oracle classifies VMware vSphere and ESXi as soft partitioning. Oracle does not accept soft partitioning as a way to limit the number of processors that must be licensed, so every physical host a VM could run on must be fully licensed for the Oracle products in use — regardless of where the VM actually executes.
Oracle's position is that you must license every physical host an Oracle VM can reach via vMotion, DRS or HA. For VMware 6.x that is the cluster. For VMware 7.0 and later, Oracle's auditors extend the argument to every host sharing storage or networking — potentially the entire vCenter estate, not just one cluster.
No. Oracle's LMS team rejects DRS host affinity rules because they are advisory and can be overridden by the hypervisor during a failover. Affinity rules do not create a hard partition and provide no contractual protection during an Oracle audit. Oracle's scripts specifically capture them to document the gap.
No. The Oracle Partitioning Policy is a non-contractual document Oracle publishes and updates unilaterally. It is not referenced in standard Oracle ordering documents or the Master Agreement, which is the basis on which the policy can be challenged during an audit or a settlement negotiation.
No. Oracle classifies Nutanix AHV, generic KVM, Hyper-V and Xen as soft partitions, exactly like VMware. Changing hypervisor does not change Oracle's full-cluster counting rule. Only physical isolation or an Oracle-approved hard partition technology limits the processor count Oracle will assert.
Yes. Oracle frequently opens with a "soft audit" or GLAS advisory email requesting a script run rather than a formal contractual audit. The data you return defines the claim either way. Treat any request to run Oracle collection scripts in a VMware estate as the start of an audit and seek independent review first.
The complete buyer-side framework for Oracle licensing across VMware, Hyper-V, KVM, Nutanix and containers — hard-partition evidence requirements, audit-challenge methodology, and migration cost models. Download free.
Download Free Guide →Stay ahead of Oracle's VMware audit program. Weekly intelligence on compliance risk, partitioning policy changes, and migration options from former Oracle insiders now working for enterprise buyers.
Oracle Licensing Experts Team — Former Oracle licensing executives, LMS auditors, and contract managers, now working exclusively for enterprise buyers. Not affiliated with Oracle Corporation. About our team →