Oracle's virtualisation licensing policy is the single largest source of unexpected compliance exposure in enterprise IT. Oracle does not recognize VMware as a "hard partition" — the only mechanism that limits Oracle's license counting to specific physical processors. This means every physical host in a VMware cluster must be fully licensed for Oracle Database, Oracle Middleware, or Oracle Java if any VM in that cluster runs any Oracle product. For enterprises running Oracle on shared VMware infrastructure alongside other workloads, the potential audit claim can be multiples of what the organization has ever spent on Oracle licensing in total. This is not a theoretical risk — it is the finding Oracle's LMS team pursues most aggressively and most profitably.
Oracle published its policy on virtualisation and partitioning in the "Oracle Partitioning Policy" document, periodically updated and available on Oracle's technology network. The document establishes two categories of partitioning: hard partitions, which Oracle accepts as limiting the license count to specific hardware; and soft partitions, which Oracle does not accept as limiting the license count.
Oracle's position is explicit: VMware vSphere, VMware ESXi, Microsoft Hyper-V, KVM, Xen, and virtually all common hypervisors used in enterprise data centers are classified as "soft partitions." Because these hypervisors allow virtual machines to migrate dynamically between physical hosts — through features like VMware vMotion, VMware DRS (Distributed Resource Scheduler), and High Availability — Oracle argues that an Oracle workload running on a VM could potentially access the compute resources of any host in the cluster. Oracle's license counting follows this potential access, not the actual current VM placement.
The practical consequence: if Oracle Database is running in a VM on Host 3 of a 20-host VMware cluster, Oracle's license counting rules require all 20 hosts to be fully licensed for Oracle Database. Moving the Oracle VM to Host 3 from Host 2 does not help — the counting requirement applies to the cluster as a whole, not to any individual host. Even configuring DRS affinity rules to pin the Oracle VM to specific hosts does not satisfy Oracle's requirement, because DRS affinity rules are soft (advisory) policies that the hypervisor can override.
DRS Affinity Rules Are Not a Hard Partition. Oracle's LMS team specifically challenges DRS affinity rules as a license containment strategy. Oracle's position is that DRS affinity rules do not constitute a hard partition because they can be overridden by the hypervisor. Enterprises relying on DRS rules to limit their Oracle license exposure are in a vulnerable position in an LMS audit.
Oracle's VMware policy has been the subject of legal and commercial challenges for over a decade. Oracle's position remains unchanged. See our detailed analysis in Oracle Audit for Virtualised Environments and the broader context in our Oracle Audit Guide. For compliance reviews specifically focused on VMware exposure, our Oracle Compliance Review service provides a forensic assessment of every VMware cluster running Oracle products.
Oracle recognises a limited set of technologies as hard partitions — mechanisms that genuinely restrict Oracle's ability to access physical processor resources in ways Oracle accepts for license counting purposes. The key qualifying technologies as of 2026 are: Oracle VM Server for x86 (Oracle's own hypervisor, with hard partition configured), LPAR (IBM AIX Logical Partitions with dedicated processors on IBM Power Systems), Solaris Zones with dedicated CPU pools (Oracle Solaris Container technology), and physical server isolation (bare metal, no hypervisor).
Oracle VM Server for SPARC (LDoms) also qualifies as a hard partition on SPARC hardware. Dedicated Hosts on Oracle Cloud Infrastructure (OCI) qualify — when Oracle workloads run on dedicated physical OCI hosts with no other tenants, Oracle accepts the physical boundary as a hard partition equivalent.
The implications for enterprise architecture are significant. If you want to run Oracle on a server that also runs non-Oracle workloads without licensing the entire server for Oracle, your options are technically limited to Oracle's own hypervisor (OVM) or IBM LPAR on IBM Power. OVM is less capable than VMware for most enterprise environments, and IBM Power hardware costs more than x86. Most enterprises choose instead to isolate Oracle workloads onto dedicated physical servers or dedicated hypervisor clusters — accepting the cost of physical isolation to avoid the cost of licensing the entire shared VMware estate.
We calculate your actual Oracle VMware exposure — counting every Oracle product running on shared VMware infrastructure, applying Oracle's Core Factor Table, and comparing your current license position to Oracle's claim methodology. Our compliance review has identified VMware exposure in 85% of enterprise environments audited, with an average gap of 3.2× the licenced position.
The first step in managing Oracle VMware compliance risk is calculating the full exposure. This requires identifying every Oracle product running on shared VMware infrastructure and mapping the associated VMware cluster topology — specifically, the number of physical hosts in each cluster and the processor count per host.
| VMware Cluster | Physical Hosts | Cores/Host | Core Factor | Oracle Processor Count |
|---|---|---|---|---|
| Example: 20-host vSphere cluster | 20 | 64 (2×32) | 0.5 | 640 Processors |
| Oracle DB EE cost (list, 50% disc.) | 640 × $23,750 | $15,200,000 | ||
| Annual support (22%) | 22% of $15.2M | $3,344,000/yr | ||
| What organization had licenced | 2 servers × 2 sockets × 16 cores × 0.5 | 32 Processors | ||
| Compliance gap | 608 Processors unlicensed | $14,440,000 exposure | ||
This scenario — a 20-host VMware cluster with Oracle running on two physical servers' worth of VMs — produces a $14.4M compliance gap at a 50% discount. At list price, the gap is over $28M. This is not an extreme example: it reflects a common enterprise architecture where Oracle was deployed on a small number of VMs in a large shared VMware cluster, without anyone calculating the Oracle license implication of the cluster topology.
The exposure calculation must cover all Oracle products running in the cluster, not just Oracle Database. If Oracle WebLogic, Oracle Java SE, Oracle Middleware, Oracle EBS, or Oracle Fusion applications run in VMs on the same VMware cluster as Oracle Database, each product must be separately licenced across all physical hosts. The license exposure can multiply quickly across a complex Oracle application stack.
Our Oracle Audit Risk Assessment tool provides an initial exposure calculation for VMware environments. For a forensic assessment, our compliance review team provides a full VMware topology analysis with exposure quantification.
Broadcom's acquisition of VMware in November 2023, and the subsequent transition of VMware's product portfolio to subscription-only licensing, has added a new dimension to Oracle VMware cost calculations. Broadcom's elimination of perpetual VMware licenses and transition to VMware vSphere+ and VMware Cloud Foundation (VCF) subscriptions has increased VMware TCO for many enterprises — making the total cost of running Oracle on VMware even less attractive.
More importantly for Oracle licensing, Broadcom's product changes have accelerated enterprise evaluation of VMware alternatives — including KVM, Nutanix AHV, and bare metal — as infrastructure platforms. From an Oracle licensing perspective, all of these hypervisor alternatives share the same problem as VMware: Oracle classifies them as soft partitions. Moving from VMware to KVM or Nutanix does not change your Oracle license counting obligation.
The only infrastructure change that resolves Oracle's VMware licensing problem is moving Oracle workloads to bare metal (dedicated physical servers) or to OCI dedicated infrastructure (which Oracle accepts as equivalent to bare metal for counting purposes). Our Oracle Cloud Advisory service includes a VMware-to-OCI migration analysis that quantifies the Oracle license saving from moving to dedicated OCI infrastructure versus the cloud service cost, allowing enterprises to make a data-driven platform decision.
Oracle's LMS audit scripts (Collection Scripts, USMM, and Review Lite) are specifically designed to discover virtualised Oracle deployments and their underlying physical infrastructure. When Oracle runs an LMS audit in a VMware environment, the scripts collect: Oracle software installation details (product, version, options enabled), virtual machine configuration (vCPUs allocated, memory, OS), VMware host configuration (physical processors, cores, host names), and VMware cluster membership (which VMs are in which clusters, which clusters share which hosts).
The cluster membership data is the critical element. Oracle's script output maps each Oracle VM to its host cluster, and Oracle's audit calculation team then applies the full physical host count for the cluster as the license basis. Enterprises that have only ever licenced the two physical servers equivalent to their Oracle VMs will receive an audit finding showing 20× or more the licenced Processor count.
The LMS scripts also capture VMware DRS and affinity rule configuration — specifically to document that the enterprise was using DRS rules as a containment strategy, which Oracle will reject as a valid partition mechanism. This documentation is used by Oracle's audit team to counter the enterprise's argument that DRS rules limited the exposure.
If Oracle has initiated an LMS audit and you are running Oracle in a VMware environment, engage our Oracle Audit Defense team before submitting any LMS script output. The data submitted to Oracle defines the scope of Oracle's audit claim — and the VMware cluster topology data in those scripts is the most consequential data Oracle will receive from your environment. See the Healthcare Compliance Remediation case study for an example of how we reduced a $22M VMware Oracle audit claim to $1.8M through evidence-based technical challenge.
Enterprises running Oracle on VMware have five realistic options for containing their license exposure: accept the full cluster counting and ensure they are licenced for all hosts; isolate Oracle to a dedicated VMware cluster that contains only Oracle workloads; migrate Oracle from VMware to bare metal dedicated servers; migrate Oracle to OCI with dedicated infrastructure; or exit the Oracle products running in VMware for alternatives that do not trigger Oracle's counting rules.
Dedicated Oracle-only VMware clusters. Creating a VMware cluster that runs exclusively Oracle workloads separates the Oracle license counting requirement from the enterprise's broader VMware estate. If the dedicated cluster has 4 physical hosts with 2×16 cores each (64 total cores at 0.5 factor = 32 Processors), the Oracle license requirement is 32 Processors — not the 640 Processors in the shared 20-host cluster. This is the most common Oracle VMware containment strategy and is achievable within a standard VMware environment without hypervisor changes. The cost is the hardware and power overhead of maintaining a separate cluster.
Bare metal server isolation. Moving Oracle workloads from VMs to bare metal physical servers eliminates the hypervisor soft partition issue entirely. Oracle licensing on bare metal is straightforward: count the physical processors in the specific servers running Oracle, apply the Core Factor Table, and you have your license requirement. This is Oracle's preferred architecture from a compliance perspective — and it is increasingly cost-competitive as bare metal server costs have declined relative to the Oracle license savings from eliminating VMware-based over-counting.
OCI dedicated infrastructure. Oracle Cloud Infrastructure's dedicated compute options — Dedicated VM Hosts and Exadata Cloud Service — provide the benefits of cloud flexibility with Oracle-accepted hard partition equivalence. An Oracle Database deployment on an OCI Dedicated VM Host is licenced based on the Dedicated VM Host's physical processor count — not the broader OCI host pool. This is the cloud equivalent of bare metal isolation, accepted by Oracle for BYOL counting purposes.
The long-term solution to Oracle's VMware licensing problem is removing Oracle from shared VMware infrastructure. The migration destination depends on Oracle's technical requirements, the organization's infrastructure strategy, and the relative costs of cloud versus on-premise bare metal.
For Oracle Database workloads, the migration options are: bare metal physical servers (lowest Oracle license risk, no cloud dependency), OCI Dedicated VM Hosts or ExaCC (cloud flexibility with Oracle-accepted partitioning), AWS Bare Metal instances (physical isolation accepted by Oracle, with BYOL at 1:1 processor mapping), or Azure Dedicated Hosts (similar physical isolation benefit). All three cloud options provide Oracle-accepted hard partition equivalence, allowing BYOL with processor counting limited to the dedicated physical host.
For enterprises choosing to exit Oracle products entirely from VMware rather than migrate to dedicated infrastructure, the question is which Oracle products are driving the VMware exposure and whether open-source or cloud-native alternatives can replace them. PostgreSQL, MySQL Enterprise, and cloud databases (Amazon Aurora, Azure SQL, Google AlloyDB) are technically capable replacements for Oracle Database EE in many workloads. WebLogic can often be replaced with Red Hat JBoss, IBM OpenLiberty, or cloud-native container runtimes. These replacements remove Oracle's counting rules from the VMware environment entirely — not just limiting the count, but eliminating it.
Download our Oracle Virtualisation Compliance Guide for a complete framework covering VMware, Hyper-V, KVM, and container environments — including the technical evidence requirements for challenging Oracle's audit findings in virtualised environments.
Complete framework for Oracle licensing in VMware, Hyper-V, KVM, and container environments. Includes 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, containment strategies, 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 →