Oracle on VMware — the soft partitioning problem.

Hard partitioning versus soft partitioning.

Oracle's Partitioning Policy — referenced in every Oracle licence agreement as a non-contractual document — divides virtualisation into "hard partitioning" (which Oracle accepts as licence-limiting) and "soft partitioning" (which it does not). Hard partitioning means technologies like LPARs on IBM POWER, Solaris Zones with capped resources, OVM with hard pinning, or OCI virtual machines with bound shapes. Soft partitioning means almost everything else: VMware vSphere, KVM, Hyper-V in most configurations, AWS dedicated hosts in many configurations.

In practice Oracle's audit position with respect to VMware is the most consequential consequence of this policy. The policy holds that any ESXi host that an Oracle database VM "can move to" via vMotion is itself a licensable host. In older VMware deployments, that argument extended cluster-to-cluster within a single vCenter, then vCenter-to-vCenter once Enhanced vMotion was introduced. The 2019 partitioning policy update preserved Oracle's audit posture; subsequent VMware version changes (vSphere 7 and 8) have further expanded Oracle's audit interpretation. Because soft partitioning is the finding Oracle's LMS team leans on hardest, it is also the one our Oracle audit defense work most often overturns.

Why this matters commercially

A two-vCPU Oracle Database VM on a 32-host VMware cluster — running on dual-socket Intel Xeon servers — generates a licence requirement, in Oracle's reading, of 32 × 2 × 0.5 = 32 processor licences. At list, that is approximately $1.5M for Database Enterprise Edition alone, before options. The actual deployment is two vCPUs. The asymmetry is the licensing event.

vCenter inventory, vMotion history, and DRS settings.

Oracle LMS audit packages for virtualised environments typically ask for: vCenter inventory exports (every host, every cluster, every datastore mount), vMotion history logs (every VM movement event with source and destination host), DRS affinity rule definitions, and storage vMotion records showing where Oracle VM disks have resided. The reason: each of those data sources is used to expand or constrain the licensable footprint.

• Inventory — establishes the hosts on which the database is deployed today.
• vMotion history — establishes the hosts on which the database has previously deployed. Oracle's position is that all those hosts require licences.
• DRS affinity rules — establish where the VM could move. Even if the VM has not moved, an unrestricted DRS rule is treated as evidence that movement is permitted.
• Cluster topology — establishes how many hosts are connected. The connected count, not the active count, drives the licence claim.

Hard isolation, not policy assertion.

There is no soft fence that works against Oracle's interpretation. Audit defence on VMware requires hard isolation — physical or contractual. The proven approaches:

Dedicated Oracle cluster

Build a separate vSphere cluster — separate hosts, separate vCenter where possible — dedicated to Oracle workloads, sized to the actual licence position. The cluster is fenced from the rest of the estate by lack of shared storage and lack of shared vCenter, so vMotion is physically impossible. This is the most defensible architecture and the one Oracle's auditors have the least room to contest. A dedicated cluster comes with operational overhead — separate patching, separate networking, often separate storage — but typically pays for itself in three months on any material Oracle estate.

OCI migration

Migrating Oracle workloads to OCI under either BYOL or Universal Credits removes the on-prem virtualisation question entirely. OCI's bare-metal and VM shapes are recognised as hard partitioning. The trade-off is moving to Oracle infrastructure — but for workloads that are not strategically locked to on-prem, OCI BYOL on a fixed shape is often cheaper than the licence position needed to run the same workload on VMware. Customers with ULA balances pending certification often use OCI migration to capture certification upside.

Hard partitioning with OLVM or KVM

Oracle Linux Virtualization Manager (OLVM) and certain KVM configurations with CPU pinning are recognised by Oracle as hard partitioning. Migration off VMware to OLVM removes the soft-partitioning exposure entirely but introduces operational complexity comparable to running a separate VMware cluster. Customers with a strong Oracle Linux footprint sometimes choose this path; customers with a unified VMware operating model rarely do.

When the LMS letter has already arrived.

When an audit is in progress and dedicated infrastructure is not in place, the defensive moves are different. The objective is to limit the scope of the claim to what the contract — not Oracle's non-contractual policy — actually requires. The arguments that move the needle:

1. The partitioning policy is non-contractual. Oracle's licence agreement references "installed and/or running" — not "could be installed". The partitioning policy is published as guidance, not contractual language. Customers with strong legal counsel push back on the policy's enforceability rather than accepting its scope.
2. DRS rules and vMotion history demonstrate actual scope. If DRS rules have always restricted the Oracle VM to a defined subset of hosts and vMotion has never crossed that subset, those facts limit the realistic claim. Auditors will resist this but it is the foundation of negotiation.
3. Storage scope. If Oracle VM disks have only existed on a defined set of datastores, the hosts that could feasibly run the database are limited to those with access to those datastores. This is a technical fence that has weight.
4. Contractual carve-outs. Some ULAs and ELAs include language that specifically addresses virtualisation. That contractual language overrides the partitioning policy and should be relied upon when available.