Oracle Audit for Virtualised Environments: VMware, Hyper-V & KVM

Oracle's Virtualisation Licensing Policy Explained

Oracle's virtualisation licensing policy is contained in a document called the "Oracle Partitioning Policy" — a short but enormously consequential document that Oracle updates periodically and that is not incorporated by reference into Oracle's standard licence agreements. This last point is significant: Oracle's partitioning policy is Oracle's interpretation of its licence agreement counting rules, not a contractual document that you agreed to when you purchased Oracle licences.

The core of Oracle's policy is the distinction between "hard partitioning" and "soft partitioning." Hard partitioning technologies — Oracle's list includes Oracle VM, LDoms/Cdom, Solaris Containers, IBM LPAR, and certain other approved configurations — are recognised by Oracle as creating a genuine hardware partition that limits Oracle's licence counting to the cores allocated to the Oracle partition. Soft partitioning technologies — which include VMware, Microsoft Hyper-V, KVM, Xen (without specific configuration), and virtually every other mainstream enterprise virtualisation platform — are treated by Oracle as not providing any licence limitation. Under Oracle's policy, running Oracle software in a soft partitioning environment means you must licence all physical cores on the server, or in Oracle's most aggressive interpretation, all physical cores across the entire VMware cluster.

Oracle's stated justification for this policy is that soft partitioning technologies allow software to migrate dynamically between physical hosts — meaning that Oracle's software "could" run on any core in the cluster at any time. Therefore, Oracle asserts, all cores must be licenced. This argument has significant technical and contractual weaknesses that have been successfully exploited in challenging Oracle's virtualisation audit claims. For the full background on Oracle's counting methodology, see the Oracle Core Factor Table guide and the complete Oracle Database Licensing Guide.

Hard Partitioning vs Soft Partitioning: Oracle's Framework

Understanding Oracle's distinction between hard and soft partitioning is prerequisite to assessing your virtualisation compliance risk and the defences available to you.

Hard partitioning technologies recognised by Oracle allow licence counting to be limited to the cores or CPUs assigned to the Oracle partition. Oracle's approved hard partitioning list (as of early 2026) includes: Oracle VM Server for x86, Oracle VM Server for SPARC (LDoms/CDoms), Oracle Solaris Containers/Zones with pinned CPU assignments, IBM LPAR with dedicated processor assignments, HP Superdome with hard partitions, Fujitsu M10 with DR configurations, and certain AWS dedicated host configurations. If you run Oracle software in one of these environments with the partition properly configured and documented, Oracle counts only the cores in the Oracle partition — not the full physical host or cluster.

Soft partitioning technologies include all VMware hypervisor products (ESXi, vSphere, vCenter), Microsoft Hyper-V, KVM, Xen, Nutanix AHV, and all other hypervisors not on Oracle's approved hard partitioning list. Under Oracle's policy, if Oracle software runs in any of these environments, the entire physical server must be licenced — or in the case of shared clusters, Oracle's position is typically that the entire cluster must be licenced. This is the source of the most frequent and highest-value Oracle audit claims against enterprise customers.

The table below summarises Oracle's treatment of common virtualisation configurations in audit contexts:

Oracle on VMware: The Highest-Risk Configuration

VMware is the dominant enterprise hypervisor and the source of the majority of large-scale Oracle compliance disputes. Oracle's position on VMware is well-documented in its Partitioning Policy and consistently applied in LMS audit engagements: VMware is a soft partitioning technology, and therefore all physical cores in the cluster where Oracle VMs run must be licenced.

The scale of exposure this creates is difficult to overstate. A typical enterprise VMware cluster has 20 to 40 physical hosts, each with dual-socket processors containing 24 to 48 cores per socket. A modest 20-host cluster with 2×24-core Intel processors has 960 physical cores. At Oracle's Core Factor of 0.5 for Intel processors, that is 480 processor licences required. Oracle Database Enterprise Edition lists at approximately $47,500 per processor licence — meaning the raw Oracle licence value of a single VMware cluster, before annual support, is $22.8M. This is Oracle's audit claim for a single cluster running a handful of Oracle VMs.

The VMware exposure is compounded by Oracle's audit timing methodology. Oracle does not just count current deployments — it claims licences for the entire period during which Oracle was running in the VMware environment. A VMware cluster that has been running Oracle VMs for five years generates five years of annual support reinstatement claims in addition to the back-licensing claim. This is why Oracle VMware virtualisation claims routinely reach hundreds of millions of dollars for large enterprise customers.

Several specific VMware configurations are relevant to how Oracle applies its methodology. A VMware DRS cluster with affinity rules pinning Oracle VMs to specific hosts does not change Oracle's minimum claim of all cores on those hosts — but it does limit Oracle's ability to extend the claim across the entire cluster to only the hosts where Oracle VMs were actually running. DRS pin documentation with timestamps is valuable evidence in limiting Oracle's claimed scope. A VMware cluster where Oracle VMs were running only on a designated subset of hosts, with other hosts having no Oracle VMs and evidence (vCenter historical data) to prove it, can be used to argue for a host-limited rather than cluster-wide licence count. This argument does not always succeed but frequently reduces Oracle's opening claim when supported by detailed technical evidence. See our detailed analysis in the Oracle Compliance in Virtualised Environments guide.

Oracle on Microsoft Hyper-V

Microsoft Hyper-V is treated by Oracle as a soft partitioning technology, subject to the same full-physical-host licensing requirement as VMware. However, the practical Oracle audit approach for Hyper-V environments differs from VMware in several important respects that affect both the audit methodology and the available defences.

Hyper-V environments are more commonly implemented on single-host or small-cluster configurations than VMware, particularly in mid-enterprise organisations. Oracle's audit exposure for a single-host Hyper-V deployment is limited to the cores on that physical server — a much smaller claim than a large VMware cluster. However, organisations running Hyper-V Failover Clusters with shared CSV storage face the same cluster-wide claim risk as VMware: Oracle will assert that any host in the failover cluster that could receive the Oracle VM must be licenced.

Hyper-V offers a configuration capability that VMware does not: physical core assignment through Hyper-V's native partitioning combined with Windows Server Core licensing structures. Under Microsoft's own virtualisation licensing model, Hyper-V with physical CPU partitioning can achieve a form of hard partitioning at the Windows OS level. Oracle does not formally recognise this configuration as hard partitioning, but it creates technical and contractual evidence that can be used to challenge Oracle's full-host claim — particularly where the partition configuration is documented, unchanging, and prevents Oracle VM migration to other hosts.

The key Hyper-V defence is documentation of physical host isolation: if Oracle's Hyper-V VMs were hosted on a specific physical machine and that machine was not part of a live migration cluster, Oracle's licence obligation is limited to that machine's physical cores. Obtaining and preserving Hyper-V configuration logs, virtual machine placement history, and live migration configuration documentation is essential preparation for any Hyper-V Oracle audit. Engage our Oracle Audit Defence team before responding to Oracle's data collection requests.

Oracle on KVM and Linux-Native Virtualisation

KVM (Kernel-based Virtual Machine), the native Linux hypervisor, is increasingly used as a VMware alternative following Broadcom's acquisition of VMware and subsequent pricing changes. Oracle treats KVM as a soft partitioning technology, and the same full-physical-host licensing requirement applies in Oracle's policy. However, KVM environments offer several technical configuration options that create stronger defences than VMware in certain scenarios.

Linux cgroup (control group) configurations can be used to assign specific physical CPU cores to specific KVM guests at the kernel level. When Oracle VMs are pinned to a specific set of physical cores using cgroups with CPU affinity settings, and when those settings are persistent, documented, and unchanged, a credible technical argument can be made that the Oracle VM cannot access other physical cores — creating an effective hard partition. Oracle has not formally accepted this argument in audit contexts, but it has been used successfully in pre-litigation commercial negotiations to limit the scope of Oracle's virtualisation claim. The key is that the configuration must be demonstrably hardware-level — not just scheduler hints — and must have been in place for the entire audit period.

Red Hat Enterprise Linux with KVM is particularly relevant here: RHEL's virtualisation stack includes additional features for CPU partitioning and NUMA topology control that can be used to construct a technical defence. Any organisation deploying Oracle on KVM should document their CPU pinning configuration, maintain configuration history, and conduct a compliance simulation before Oracle engages.

Oracle VM Server: The Compliant Alternative

Oracle VM Server for x86 is Oracle's own hypervisor product, based on the Xen hypervisor, and it is on Oracle's approved hard partitioning list. When Oracle Database or other Oracle software is deployed in an Oracle VM Server environment with CPU cores properly pinned to the Oracle VM guest, Oracle counts only the allocated cores — not the entire physical host. This is the only way to achieve hard-partition licence limitation on standard x86 Intel/AMD hardware without using Oracle SPARC or proprietary server platforms.

The commercial trade-off with Oracle VM Server is that it requires running a separate hypervisor platform alongside VMware or Hyper-V — which adds infrastructure complexity and management overhead. Many enterprises run a dedicated Oracle VM Server cluster for Oracle workloads specifically to achieve hard partitioning licence limitation, while continuing to run their non-Oracle workloads on VMware. This architecture is a legitimate and frequently cost-effective strategy for large Oracle deployments where the licence savings from hard partitioning outweigh the infrastructure overhead of maintaining a separate hypervisor.

Oracle VM Server must be properly configured to achieve the hard partitioning benefit. CPU pin assignments must be static and enforced — not just advisory. The Oracle VM environment must be running the Oracle-supported OVM release, with valid Oracle VM support. And critically, the hard partitioning configuration must be active for the entire audit period — Oracle will assert that any period during which the configuration was not properly implemented requires full-host licensing for that period. Our Oracle Licence Optimisation team assesses whether Oracle VM migration is cost-effective for your specific deployment.

Challenging Oracle's Virtualisation Audit Claims

Oracle's virtualisation audit claims are more successfully challenged than any other category of Oracle compliance finding. This is because Oracle's Partitioning Policy is not incorporated into Oracle's standard licence agreement — it is an interpretive document that Oracle creates unilaterally. When customers challenge Oracle's virtualisation claims through independent legal counsel, Oracle's ability to enforce the maximum claim is limited by the contractual language that actually exists, not by Oracle's preferred policy interpretation.

The foundation of a successful virtualisation challenge is a technical counter-assessment that presents Oracle with specific evidence contradicting the basis of its claim. The technical evidence should include: a forensic inventory of all servers running Oracle software with exact CPU configuration and core counts, a vCenter or Hyper-V historical log showing the actual hosts where Oracle VMs resided during the audit period, CPU pin configuration documentation showing any affinity rules or partitioning constraints in place, and an analysis of VM migration history showing whether Oracle VMs actually moved between hosts and when. Oracle's claim that Oracle VMs "could have" run on other hosts is weakened significantly by evidence that Oracle VMs demonstrably never did run on those hosts.

The contractual challenge focuses on the enforceability of Oracle's Partitioning Policy as an audit methodology against customers whose licence agreements do not reference the policy. Oracle's standard Processor Definition section defines licence counting as applying to "all physical processors" where Oracle programs are installed and running — it does not say "all processors in the cluster" or "all processors on the physical host." The extension from installed processors to cluster processors is Oracle's interpretation, not the contract's explicit language. Engaging experienced Oracle licensing counsel to challenge this interpretation — and to ask Oracle to demonstrate contractual basis for the cluster-wide count — is standard practice in successful virtualisation defence engagements.

Finally, the commercial settlement context matters. Oracle's virtualisation audit programme is revenue-generation — Oracle wants a commercial resolution that converts you to a compliant position, ideally by purchasing more licences or cloud services. Understanding Oracle's commercial objective creates negotiation opportunities. Enterprises that combine a strong technical and legal challenge with a clear commercial counter-offer — purchasing a smaller number of additional licences to cover a narrowly-defined genuine gap, or committing to an Oracle cloud migration timeline — frequently achieve settlements at a fraction of Oracle's initial claim.