An Oracle VMware audit is a License Management Services review of where Oracle Database runs inside your vSphere estate — and it produces the single largest compliance claims Oracle makes. Oracle treats VMware as soft partitioning, so it argues you must license every physical core in every host an Oracle VM could reach. This guide explains exactly how Oracle builds that claim, and how to challenge it.
Short answer: In an Oracle VMware audit, Oracle's LMS team uses vCenter data to claim you must license every physical core in every ESXi host where an Oracle VM could run via vMotion — not just the hosts where it actually runs. This soft-partitioning stance routinely inflates the claim 3-5x over the defensible position.
An Oracle VMware audit is a License Management Services (LMS) compliance review focused on where Oracle programs — almost always Oracle Database Enterprise Edition and its options — run inside a VMware vSphere environment. Oracle GLAS/LMS requests virtualisation evidence, maps the maximum possible reach of every Oracle VM, and builds a processor-licensing claim from it.
Unlike a database-only review, the VMware audit hinges on infrastructure data: which ESXi hosts exist, how they are grouped into clusters, what their physical core counts are, and which virtual machines carry Oracle software. Oracle's LMS team combines that infrastructure map with the database-tier evidence from USMM and Review Lite scripts to attribute Oracle Database EE — and any enabled options such as Diagnostics Pack, Tuning Pack, or Partitioning — to every host it deems reachable.
Because VMware deployments concentrate many workloads onto shared hardware, this is where Oracle's most aggressive compliance positions surface. VMware virtualisation creates the single biggest Oracle compliance trap, and the resulting back-licence claims regularly run into seven figures. The full process sits inside our Oracle Audit Guide; this article is the buyer-side deep dive on the virtualisation-specific mechanics.
Short answer: Soft partitioning is any technology Oracle does not recognise as a way to restrict where its software can run. Oracle's partitioning policy names VMware as soft partitioning, so Oracle argues that CPU pinning, resource pools, and host affinity do not limit your licensing obligation.
Hard partitioning is a method Oracle explicitly approves for limiting licensable cores — for example Oracle VM with CPU pinning, Solaris Zones with capped CPUs, IBM LPAR, or physical partitions. Soft partitioning is everything Oracle does not approve, which includes VMware vSphere in all its forms. This distinction is set out in Oracle's "Partitioning Policy" document, which Oracle itself stamps as non-contractual — a critical point covered below.
The practical consequence is severe. Because the VMware vMotion feature can live-migrate a running VM between hosts, and the Distributed Resource Scheduler (DRS) can do so automatically, Oracle takes the position that an Oracle VM "could run" anywhere within reach. Oracle then demands a full processor licence — Processor (per-core) metric — for every physical core in every host the VM could theoretically land on. Your actual runtime placement is treated as irrelevant. For the underlying database-licensing rules this connects to, see our Oracle Database Licensing Guide.
The policy is not your contract. Oracle's partitioning policy carries the line "for educational purposes only" and is not incorporated into the Oracle Master Agreement or OLSA. Your licensing obligation is defined by your signed contract and Oracle's standard definitions of Processor and Named User Plus — not by a policy PDF. That gap is the foundation of every credible VMware audit defence.
Oracle's scoping argument has expanded with each vSphere release. The further Oracle can push the boundary, the more physical cores it can count, and the larger the back-licence claim. Oracle's audit teams use the table below as their default opening position; each row also has a defensible counter-position that an independent advisor will hold.
| vSphere environment | Oracle's claimed licensing boundary | Defensible counter-position |
|---|---|---|
| Single cluster, vSphere 5.x | Every host in the cluster | Only hosts the Oracle VM is configured to run on |
| Multiple clusters, vSphere 6.0+ | Every host under the same vCenter (cross-vCenter vMotion) | Hosts in the dedicated Oracle cluster, isolated by configuration |
| Linked vCenters / Enhanced Linked Mode | Every host across all linked vCenters | Physically and logically separated Oracle estate only |
| Storage shared with non-Oracle hosts | All hosts with access to the shared datastore | Storage access alone does not run Oracle software |
The key escalation happened with vSphere 6.0, which introduced cross-vCenter and long-distance vMotion. Oracle's LMS team uses this capability to argue that the licensable boundary is no longer the cluster but the entire vCenter — or every linked vCenter. In a large enterprise running hundreds of hosts on one vCenter, this single argument can multiply a legitimate claim of a few dozen cores into thousands. This is exactly the contested item our Oracle Database licensing on VMware analysis dissects line by line.
Before you export anything from vCenter, talk to a former Oracle LMS insider. Our Oracle Audit Defense team manages the data exchange so Oracle never sees more of your estate than the contract requires.
Oracle's evidence request in a VMware audit is broader than most customers expect, and what you hand over directly determines the size of the claim Oracle can build. Oracle's LMS team typically asks for vCenter exports or an RVTools spreadsheet covering the whole virtual estate — far more than the Oracle workloads alone.
The core data points Oracle wants are: every ESXi host with its exact CPU make, model and physical core count; the cluster each host belongs to; vCenter and Enhanced Linked Mode topology; and the full VM inventory so Oracle can identify which guests run Oracle software. Alongside this it collects database-tier evidence from USMM, Review Lite, and the DBA_FEATURE_USAGE_STATISTICS view to prove which options and packs were enabled.
The defensible principle is simple: Oracle is entitled to evidence about its own software's use, not a complete map of your data centre. Handing Oracle a full RVTools export of every host and cluster gives the LMS team the raw material to maximise scope. An independent advisor scopes the data exchange so Oracle receives what your contract requires and nothing that needlessly widens the cluster boundary. The disciplined sequencing of this exchange is one of the 15 plays in our Oracle Audit Defense Playbook.
Short answer: You challenge an Oracle VMware audit on two fronts at once — contractually, by pointing out the partitioning policy is non-binding, and technically, by proving the realistic runtime boundary of the Oracle VMs. Together these forensic challenges typically cut Oracle's opening processor claim by more than half.
The contractual challenge starts with your signed agreement. Oracle's Processor definition licenses processors "on which the programs are installed and/or running." An independent advisor pushes Oracle to reconcile its "could run anywhere" cluster argument against the actual installed-and-running language in your contract — because the expansive policy position is not what you agreed to.
The technical challenge attacks the inflated core count item by item. Effective evidence includes: documented DRS "must-run" host-affinity rules tying Oracle VMs to named hosts; a dedicated cluster physically separated from the rest of the estate; an isolated vCenter with no linked mode to the wider environment; and correction of Core Factor or CPU-model errors in Oracle's calculation. Each excluded host removes cores from the claim.
The combined effect is significant. Across our engagements, Oracle's initial VMware processor claim is overstated by 3-5x the defensible position, and disciplined challenge plus workload isolation routinely removes the majority of it before settlement (Oracle Licensing Experts, 2026). The remaining gap then becomes a normal commercial negotiation, where Oracle list price is itself a starting position open to a 40-70% discount. A worked example sits in our healthcare compliance case study, where a multi-host VMware exposure was reduced by over 90%.
The most durable defence is architectural, not legal. If Oracle Database is isolated so it genuinely cannot migrate across your wider estate, Oracle's "could run anywhere" argument collapses on the facts.
This isolation strategy is the same one we deploy in live engagements through our Oracle Compliance Review, which benchmarks your current VMware exposure and produces a right-sized target architecture before Oracle ever sends a notification letter.
Yes. Oracle's standard Master Agreement and OLSA grant Oracle the right to audit your use of Oracle programs, which includes virtualised deployments. Oracle's LMS team will request vCenter exports to map where Oracle Database runs. You can negotiate scope, timing, and the format of data shared, but you cannot refuse the audit outright without breaching your contract.
Oracle classifies VMware as soft partitioning, which it does not accept as a way to limit licensing. Because vMotion and DRS can move an Oracle VM to any host, Oracle's policy claims you must license every physical core in every host where the Oracle VM could possibly run. In large vSphere environments Oracle extends this to all clusters connected to the same vCenter.
Host affinity and DRS "must-run" rules do not appear in Oracle's official partitioning policy, so Oracle's LMS team will reject them as a contractual limit. However, documented affinity rules, dedicated clusters, and isolated vCenters are strong technical evidence used in negotiation to challenge an inflated processor count and reduce the defensible scope of the claim.
Oracle requests vCenter or RVTools exports listing every ESXi host, its CPU model and physical core count, cluster membership, and the VMs running Oracle software. Combined with USMM and Review Lite output from the database tier, this lets Oracle map the maximum possible Oracle footprint and apply the Core Factor to every host it deems in scope.
Across our engagements, Oracle's initial VMware processor claim is overstated by 3-5 times the defensible position (Oracle Licensing Experts, 2026). Reductions come from limiting cluster scope, removing non-Oracle hosts, correcting Core Factor errors, and isolating Oracle workloads onto dedicated clusters before settlement.
The cleanest defence is to isolate Oracle Database onto a dedicated vSphere cluster with its own vCenter, separated from the wider estate, and to document that boundary. Alternatively, deploy Oracle on an Oracle-approved hard partitioning technology. Either approach removes Oracle's argument that the database could migrate across your entire VMware estate.
We have defended VMware audits across thousands of ESXi hosts. Whether you have a notification letter or a draft compliance report, our Audit Defense team challenges the cluster scope forensically and negotiates the settlement. Start at our contact page or explore the full advisory practice.
By Fredrik Filipsson — Former Oracle sales and licensing professional, 25+ years' experience. Founder of Oracle Licensing Experts. 100% buyer-side advisory — never works for Oracle. LinkedIn ↗ · About our team →
Reviewed by the Oracle Licensing Experts review board — former Oracle License Management Services consultants and enterprise procurement specialists.
Oracle keeps expanding its virtualisation scope arguments. Join 2,000+ Oracle stakeholders who receive weekly buyer-side briefings from former Oracle LMS insiders.