Oracle Virtualization Licensing: Core Rules Every Enterprise Must Know

Oracle's Fundamental Virtualization Licensing Rule

Oracle's approach to virtualization licensing flows from a single, non-negotiable principle: Oracle licences its software based on the physical hardware capacity that could run it, not the virtual hardware actually assigned to it. Unless you use a technology on Oracle's approved hard partitioning list, Oracle treats your entire physical environment as in scope for licensing.

This means that configuring an Oracle database to run with 4 virtual CPUs on a physical server with 32 cores does not limit your Oracle licence obligation to those 4 vCPUs. Oracle requires you to licence all 32 cores (multiplied by the appropriate Core Factor from Oracle's Core Factor Table). The virtual CPU assignment is, in Oracle's view, irrelevant to the licence count.

This principle is encoded in Oracle's Partitioning Policy, a standalone document that Oracle distributes separately from its standard licence agreements. The Partitioning Policy defines which technologies constitute "hard partitioning" — the only category Oracle accepts as genuinely limiting licence scope — and which constitute "soft partitioning," which Oracle does not accept as a licence boundary.

The Core Factor Table: How Oracle Counts Processors

Before examining the partitioning rules, it is worth understanding how Oracle counts processors for its Processor metric, since this is the foundation of virtually all virtualization licensing calculations.

Oracle does not simply count physical cores. It applies a Core Factor from its published Core Factor Table, which varies by processor type. For most modern enterprise processors, the applicable factors are:

• Intel and AMD multi-core processors: 0.5 — meaning each core counts as half an Oracle processor licence
• Sun UltraSPARC T-series: 0.25
• IBM POWER processors: 1.0 for most models
• Intel Itanium: 0.5

For a typical x86 server with 2 sockets and 16 cores per socket (32 cores total), Oracle's licence obligation is 32 × 0.5 = 16 processor licences. For a 10-host VMware cluster with the same per-host specification, the cluster-wide obligation is 160 processor licences under Oracle's soft partitioning rules.

Soft Partitioning: What Oracle Rejects

The vast majority of virtualisation technologies in common enterprise use are classified as soft partitioning by Oracle. Oracle's position is that soft partitioning uses software controls — operating system schedulers, hypervisor policies, CPU affinity rules — to restrict which physical processors Oracle software executes on. Because these controls can be changed, overridden, or bypassed, Oracle does not accept them as a genuine physical limit on licence scope.

Technologies Oracle explicitly classifies as soft partitioning include VMware vSphere and ESXi in all configurations, Microsoft Hyper-V, Citrix XenServer, Amazon EC2 and most cloud virtual machines, Nutanix AHV in most configurations, and any use of CPU affinity, DRS rules, resource pools, or vCPU pinning to restrict Oracle deployments.

The implication is stark: if Oracle software is deployed anywhere in a VMware cluster, all physical processors in every host in that cluster — including hosts where Oracle software has never and could never realistically run — are potentially in scope for Oracle licensing under Oracle's interpretation of the Partitioning Policy.

Hard Partitioning: What Oracle Accepts

Oracle's approved hard partitioning technologies physically segment a server so that Oracle software can only access a defined subset of processors regardless of software configuration. The approved technologies are narrow and mostly Oracle's own products:

• Oracle VM Server for x86 (OVM): Oracle's own hypervisor. When VMs are assigned specific CPU pools with no cross-pool migration, this qualifies as hard partitioning. OVM is technically capable but operationally less mature than VMware.
• Oracle Linux KVM: Qualifies when configured with specific pinned CPU assignments per Oracle's hard partitioning data sheet. Requires careful configuration and documentation.
• IBM LPAR (dedicated partitions): IBM Power Systems LPARs configured with dedicated processor assignment qualify. Shared processor pools do not.
• Oracle Solaris Zones: Non-global zones with dedicated processor sets assigned via the zone configuration qualify as hard partitioning.
• SPARC Physical Domains: PDom partitioning on SPARC Enterprise M-Series systems qualifies.
• Fujitsu PRIMEQUEST: With Oracle's specific approval documentation.

The limited scope of this list explains why so many enterprises end up with Oracle virtualization compliance problems. The technologies Oracle approves are either Oracle's own products (creating lock-in), SPARC/Power systems with specific configurations, or require complex manual configuration that most enterprise operations teams do not maintain.

Cloud Environments: A Partial Exception

Oracle's approach to cloud environments has evolved to create a partial exception from the full-cluster licensing rule, but only in specific circumstances.

For Oracle Cloud Infrastructure (OCI), Oracle licenses its software on a per-OCPU basis, eliminating the cluster-wide exposure problem entirely. This is one of the most compelling licensing arguments for OCI migration — the soft partitioning rules that apply on-premises simply do not apply in the same way on OCI.

For AWS, Azure, and Google Cloud, Oracle has published authorised cloud environments documentation that specifies how Oracle software must be licensed in each cloud. In most cloud configurations, Oracle licences are required based on the number of vCPUs assigned to the virtual machine, with a 2:1 conversion ratio (2 vCPUs = 1 Oracle processor licence) for most cloud providers. This is significantly more favourable than the full-physical-server rule that applies in VMware environments on-premises.

However, the cloud exceptions only apply when Oracle software is deployed on single cloud virtual machines, not when deployed across multi-node clusters or container orchestration platforms without explicit Oracle authorisation. Container and Kubernetes deployments of Oracle software carry their own licensing complexity that requires specific analysis.

Reducing Virtualization Licensing Exposure: Practical Steps

Enterprises facing significant Oracle virtualization licensing exposure have several practical paths to reducing that exposure. None involve convincing Oracle to change its Partitioning Policy — instead, they restructure deployments to legitimately reduce the physical scope Oracle can claim.

Physical Cluster Isolation

Dedicating a specific set of physical hosts exclusively to Oracle workloads, with no VMware migration capability beyond those hosts, limits Oracle's licence scope to those dedicated hosts. This requires genuine physical separation — dedicated hosts, no DRS migration outside the Oracle cluster, and clear documentation. When properly implemented and documented, Oracle auditors have accepted physical isolation arguments.

Migration to OCI or Authorised Cloud

Moving Oracle workloads from VMware to OCI or AWS replaces the cluster-wide licensing problem with per-vCPU or per-OCPU licensing. For organisations with large VMware clusters running Oracle software, the licensing savings from cloud migration can offset the operational migration cost within a few years — sometimes within months.

Migration to Oracle-Approved Hypervisors

Migrating Oracle workloads from VMware to Oracle VM Server or Oracle Linux KVM with hard partitioning configuration eliminates the soft partitioning problem. This path is operationally disruptive but can dramatically reduce Oracle processor licence obligations for organisations with large VMware deployments. Redress Compliance has supported multiple enterprises through this transition with total savings exceeding $10 million in avoided licence obligations.

ULA for High-Growth VMware Estates

For enterprises where VMware-driven Oracle licensing exposure is already very large, an Oracle Unlimited Licence Agreement (ULA) can provide a path to resolving existing risk while deploying as broadly as needed during the term. The ULA mechanism allows unrestricted deployment of specified products for a fixed fee — meaning additional Oracle deployments in the VMware environment during the ULA term cost nothing beyond the fixed ULA fee. At certification, all deployed instances become perpetual licences regardless of where they run.

What to Do Before an Oracle Audit

Proactive management of Oracle virtualization licensing risk is vastly more effective than reactive audit response. Organisations that conduct independent internal assessments before Oracle initiates a compliance review are consistently better positioned to manage costs and defend their compliance position.

The essential pre-audit steps are: first, complete a full software discovery to identify every Oracle product deployed in your virtualised infrastructure. Second, map those deployments against the physical host topology, including all VMware clusters and any Oracle-approved partitioning technologies in use. Third, compare theoretical Oracle licence obligations under Oracle's soft partitioning rules against currently licensed quantities. Fourth, document any physical isolation, hard partitioning, or cloud deployment configurations that could legitimately limit Oracle's licence scope. Fifth, engage an independent Oracle licensing advisor to review the analysis and advise on the most cost-effective remediation strategy before Oracle becomes aware of the gap.

For a deeper analysis of VMware-specific issues, including financial scenarios and Broadcom acquisition implications, see our comprehensive guide: Oracle Virtualisation Licensing and VMware: The Complete Enterprise Guide.