The Foundation: Why Oracle's Virtualisation Rules Are Different

Oracle maintains that virtualisation technologies create what it calls "soft partitioning" — an environment where Oracle software can potentially run on any server in a cluster, and therefore, Oracle's position is that all physical processors in all servers that could run Oracle software must be licensed. This is fundamentally different from how other software vendors handle virtualisation. Microsoft, IBM (for most products), and SAP all allow customers to licence only the virtual machines running their software. Oracle does not, and this asymmetry has created enormous compliance exposure for enterprises that apply a standard IT licensing approach to Oracle middleware and other products in virtualised environments.

Oracle published its partitioning policy in the document "Oracle Partitioning Policy" (most recently updated in January 2017, but still in force). This document lists the technologies Oracle officially recognises as "hard partitioning" — sufficient to limit licence counting. Everything else is soft partitioning and requires full physical host licensing. The implications are profound: a mid-sized enterprise running Oracle Database on a four-node VMware cluster with 32 cores per server needs to licence all 128 physical cores (at the applicable core factor), not the 8 or 12 virtual cores the database actually uses. This is not a grey area of interpretation; this is Oracle's stated policy, consistently applied in audits, and successfully defended in licensing disputes.

Hard Partitioning vs Soft Partitioning: The Critical Distinction

Oracle's list of hard partitioning technologies is tightly constrained. The recognised platforms include Oracle VM for x86 (OVM) when configured correctly with dedicated CPUs; Oracle VM for SPARC (LDoms) when configured with dedicated CPUs; IBM LPAR with dedicated processors (shared processor pools are soft partitioning); HP vPar; Fujitsu PPAR; Hitachi LPAR; and Solaris 11 Zones with dedicated CPUs. These constraints apply to all Oracle products, including Oracle WebLogic Server licensing in virtualised environments. For most enterprises, this list is functionally irrelevant because almost no organisation still deploys Oracle on these platforms. The installed base of Oracle workloads has migrated to VMware, Hyper-V, and cloud environments — all of which are soft partitioning in Oracle's view.

The soft partitioning category encompasses virtually every technology organisations commonly use. VMware vSphere and ESXi (all versions, including all current vSphere and vSphere with Tanzu Cloud Foundation); Microsoft Hyper-V; Linux KVM; Xen hypervisor; Docker containers; Kubernetes; any container orchestration platform; AWS EC2 standard instances; Microsoft Azure VMs standard instances; and Google Compute Engine standard instances — all are treated as soft partitioning. The practical consequence is unambiguous: if you run Oracle Database on a VMware cluster with four servers each containing 32 Intel cores (128 cores total, or 64 processor licences at 0.5 core factor), you need 64 processor licences, regardless of whether Oracle is running on one VM consuming 4 OCPUs. Oracle's LMS auditors apply this rule consistently, and the cost of exposure is severe enough that many organisations have treated this as a hard ceiling for Oracle deployments in virtualised environments.

Oracle Licensing on VMware: The Full Counting Rule

The VMware licensing position crystallises the soft partitioning rule into practice. Oracle's official position is that Oracle can be deployed on any host in a VMware cluster at any time via vMotion, DRS (Distributed Resource Scheduler), HA (High Availability), or manual migration. Because Oracle software can potentially run on any host in the cluster, Oracle requires all hosts in the cluster — and Oracle extends this to all hosts in the vCenter domain — to be fully licensed if any one of them could host Oracle workloads. This is the "full host counting" rule, and it applies to the entire vCenter domain, not just the individual cluster where Oracle is currently running.

The vCenter domain expansion is a significant aggravating factor in VMware audit exposure. If a single vCenter server manages multiple clusters (which is standard architecture in large enterprises), Oracle's LMS auditors argue that if any cluster could host Oracle workloads, all clusters under that vCenter must be licensed. This interpretation is contested — some organisations have pushed back and negotiated settlements on a per-cluster basis — but LMS has enforced the vCenter domain position successfully in multiple audit settlements, making it the de facto counting rule. Some organisations attempt to mitigate this exposure by pinning Oracle VMs to specific hosts using DRS anti-affinity rules or manual placement restrictions. Oracle explicitly does not accept VM pinning as a substitute for hard partitioning. LMS auditors review vCenter event logs, DRS migration reports, and HA failover records to identify any historical movement of Oracle VMs between hosts. Even a single vMotion event, HA failover, or DRS-initiated rebalance during the audit look-back period (typically the three years preceding the audit) creates retroactive licensing exposure for the entire cluster during that entire period.

Broadcom's acquisition of VMware in November 2023 and the subsequent shift to subscription-based VCF (VMware Cloud Foundation) pricing accelerated VMware exit discussions across enterprises. Many organisations re-evaluated their virtualisation footprint in 2024 and 2025, moving workloads to OCI, AWS, or Azure. The oracle licensing virtualisation vmware exposure, however, does not disappear with VMware decommissioning. The historical period during which Oracle was running on VMware remains auditable. Oracle can still claim exposure for the entire period that Oracle workloads were on VMware, regardless of whether that infrastructure is still in operation. Organisations planning a VMware exit should conduct an Oracle licence audit readiness review before decommissioning, while vCenter event logs are still accessible to support a forensic reconstruction of the licence position.

Oracle Licensing on Hyper-V: The Same Rules Apply

Microsoft Hyper-V is soft partitioning under Oracle's policy, applying the identical counting rules to VMware. All physical cores on all hosts in the Hyper-V cluster must be licensed if Oracle could potentially run on any host in that cluster. A common mistake: IT teams assume that because Microsoft SQL Server has generous Hyper-V licensing provisions (License Mobility, dedicated host discounts), Oracle follows the same rules. It does not. Oracle's licensing policy on Hyper-V makes no exceptions for Microsoft-owned infrastructure or integrated Microsoft licensing programmes. The same full physical host counting applies to Hyper-V as to VMware.

Some organisations attempt to argue that if they deploy Oracle on Windows Server Core hosts running Hyper-V with no other VMs, only those physical cores need licensing. Oracle does not accept this argument. The policy applies to the cluster topology, not the single-host deployment configuration. Even on a two-node failover cluster with Oracle running on only one host, both physical hosts must be licensed. If those hosts are part of a larger cluster or are managed by a centralised Hyper-V manager (such as System Center Virtual Machine Manager — SCVMM), the cluster boundary expands accordingly. The exposure is as severe in Hyper-V environments as in VMware, yet many enterprises deployed Oracle on Hyper-V under the assumption that Microsoft's licensing approach would carry through to Oracle. This has created significant exposure in organisations with substantial Hyper-V deployments.

Oracle Licensing in Cloud Environments: AWS, Azure, and OCI

Cloud adds a fundamental new dimension to the soft partitioning problem. Oracle's theoretical position on standard AWS EC2 instances and standard Azure VMs is that the cloud provider's underlying virtualisation infrastructure is soft partitioning. You cannot determine which physical host your EC2 instance is running on; instances can be migrated to different physical hosts at any time without your notification or control. Therefore, Oracle's argument is that all physical hosts in the availability zone that could run your instance must be licensed. Oracle does not enforce this position in practice against cloud consumers because it would be commercially untenable — you would need to licence thousands of physical cores for a single deployed VM. This theoretical position is the foundational argument for why OCI (Oracle Cloud Infrastructure) was created as an Oracle-approved licensing environment, offering specific sub-capacity counting models that reduce licence requirements.

The practical approved paths for cloud deployments are specific and limited. For AWS, use EC2 Dedicated Hosts, which Oracle has formally recognised as a licensing boundary. On Dedicated Hosts, you licence only the physical cores on your dedicated hosts, using the AWS-specific core factor (typically 0.5 for Intel), not the full availability zone. For Microsoft Azure, use Azure Dedicated Hosts, which provide the same licensing boundary. For OCI, standard VM shapes with BYOL (Bring Your Own Licence) deployment provide sub-capacity counting: you licence only the OCPUs in the specific shape running your database, not the full physical cluster. The cost advantage of OCI BYOL for Oracle Database workloads is substantial — typically 60 to 80 percent reduction in processor licence requirements versus full physical host counting. The approved paths are the commercially sensible routes, and organisations considering cloud migration should favour these options to reduce licence exposure during the migration.

The Oracle LMS Audit Process: How Virtualisation Exposure Is Found

Oracle's LMS team uses a specific toolkit to collect virtualisation data during audits. Oracle LMS Scripts (deployed on target servers) collect system configuration data, and since 2019, Oracle has also used the OracleMeteredUse portal for cloud-based collection and metrics. For VMware environments, LMS requests vCenter event logs, DRS migration reports, and HA failover records for the entire three-year period preceding the audit (the standard look-back period under most Oracle licence agreements). These logs are forensic evidence of which hosts could have run Oracle workloads and when. A vCenter event log showing vMotion activity proves that Oracle VMs moved between hosts; a DRS report showing overnight rebalancing proves that automation moved Oracle workloads; an HA failover record proves that Oracle ran on a secondary host during an outage.

The audit trap is historical exposure. Many organisations apply Oracle software to their VMware environment and manage the virtual licence position correctly going forward, but fail to account for the past. A VM that ran on four of the eight hosts in a cluster over the past 18 months creates retroactive exposure for all eight hosts during that entire 18-month period — even if you remediate the VM configuration today. The exposure is not future-looking; it is retroactive. LMS specifically searches event logs for evidence of Oracle binary installations on hosts where licences are not currently claimed; vMotion records showing Oracle VM migration to hosts without claimed licences; HA failover events that moved Oracle to unlicensed hosts; and DRS balancing migrations that moved Oracle to unlicensed hosts overnight. When LMS finds such evidence, the "unlicensed exposure" period is calculated backward from the audit date, and the licence shortfall is typically calculated as the full physical host count for the entire look-back period.

Remediation Options: What You Can Actually Do

Organisations facing Oracle virtualisation exposure have four practical remediation paths, each with distinct cost and implementation complexity. The first is the simplest but most expensive: licence all servers in the cluster. For a four-node cluster with 32 cores each (64 processor licences at 0.5 core factor), this may cost 600,000 to 1.2 million USD depending on Oracle Database edition and support costs. For small clusters, this is often cost-effective compared to the settlement risk. For large clusters (10 or more servers), the cost is typically prohibitive, and organisations need to pursue other remediation paths.

The second option is to migrate Oracle to a dedicated cluster running OVM (Oracle VM for x86). OVM is free software, and Oracle recognises it as hard partitioning when configured correctly with dedicated CPUs. A cluster of two to four dedicated servers running Oracle workloads under OVM hard partitioning can be licensed on a per-host basis rather than the full cluster count. The migration cost (typically three to six months of project work) is often recovered in reduced licence costs within 12 to 18 months. This is the most technically complex remediation but often the most cost-effective for large Oracle Database deployments.

The third option is to migrate Oracle workloads to OCI with BYOL. OCI's sub-capacity counting model reduces licence requirements by 60 to 80 percent versus the full physical host count in VMware. For Oracle Database Enterprise Edition workloads on heavily over-provisioned VMware clusters, OCI BYOL is typically the most cost-effective remediation path. The subscription cost (compute, storage, network) is often offset by the dramatic reduction in licence costs. Migration typically takes two to four months.

The fourth option is to negotiate a ULA (Unlimited Licence Agreement) to cover the exposure. If your organisation has significant undeclared Oracle virtualisation exposure, a ULA can be structured to include the affected products and set a deployment start date that covers the audit period. This commercially negotiates the gap and converts it to a ULA term. This is not available to all organisations — ULA eligibility depends on aggregate Oracle spend and market factors — but when available, it is a clean commercial solution. Oracle is often receptive to ULA arrangements when the alternative is a protracted audit dispute or when Oracle wants the ULA revenue more than it wants the audit settlement. This requires sophisticated negotiation and is typically supported by independent advisors.

Oracle's Position After Broadcom: Does Anything Change?

Broadcom's acquisition of VMware in November 2023 fundamentally changed VMware's commercial model, moving from perpetual licensing to subscription-based VCF. This shift accelerated VMware exit planning across enterprises. Many organisations decomissioned VMware clusters in 2024 and 2025 or migrated to competing hypervisors. Oracle's licensing policy, however, has not changed in response to Broadcom's acquisition. VMware remains soft partitioning regardless of whether customers are on legacy perpetual vSphere licences, vSphere Essentials, or the new VCF subscription model. The licensing position is unchanged, and the exposure is unchanged.

One practical implication deserves emphasis: as enterprises decommission VMware clusters, the historical Oracle licence exposure on those clusters does not disappear. Oracle can still audit the historical deployment period. For organisations planning a VMware exit, conducting an Oracle licence audit readiness review before decommissioning is essential. While the vCenter event logs are still accessible, you can reconstruct the historical licence position forensically and negotiate remediation if needed. Once infrastructure is decommissioned, the logs are often archived or lost, making retroactive reconstruction much more difficult and leaving exposure unresolved. The period of decommissioning is the optimal window for resolving virtualisation exposure before Oracle's audit team encounters it independently.