How Oracle licenses software on virtual machines turns on its partitioning policy: a memorandum that recognises only approved hard-partitioning technologies as bounding the licensable cores and excludes soft partitioning such as VMware vSphere. Admodum, an independent buyer-side advisory, reads hard versus soft, the VMware question, why the policy is not contractually binding, and the buyer-side defensible position.
The Oracle Partitioning Policy is a publisher-published policy memorandum, sitting on the Oracle public site. The memorandum names a list of approved hard-partitioning technologies and asserts that any technology not on the list is treated as soft partitioning, which the publisher does not recognise as bounding the licensable core count.
The memorandum is therefore a publisher position document. It is not a contractual instrument; it is not part of the Oracle Master Agreement, the OLSA, the order document or any subsequent ordering schedule. The buyer’s contractual position rests on those documents and not on the memorandum.
This distinction is the buyer’s most undervalued lever. The Admodum methodology treats the memorandum as evidence of the publisher’s reading rather than as binding contractual law. The wider editorial sits at the Oracle pillar; the deeper read on the VMware question sits at Oracle and VMware after Broadcom.
The memorandum names the approved hard-partitioning technologies. The current list reads: Physical Partitions (LPAR on IBM Power), Dynamic System Domains (DSD on Sun/Oracle hardware), Solaris Zones (Capped Containers with hard caps configured on CPUs), Oracle VM Server for x86 (in approved configurations with CPU pinning), Oracle VM Server for SPARC (LDOM), IBM PR/SM (mainframe), Fujitsu PPAR, and a small number of named alternatives.
For each named technology, the buyer must operate the technology in the configuration named in the memorandum (CPU pinning, capped containers, named LPAR designs) for the bounded-core read to apply. A loosely configured Solaris Zone or an unpinned Oracle VM Server x86 environment fails the bounded-core test even though the underlying technology is on the named list.
The bounded-core read converts a host carrying (say) sixty-four physical cores into a licensable read of (say) eight cores against the partitioned workload, where the partition is hard-bounded to eight cores. The arithmetic then runs against the core-factor table and the processor metric.
The memorandum excludes from the bounded-core read any partitioning technology not on the named list. The most commercially material exclusion is VMware vSphere; other excluded technologies are Microsoft Hyper-V, KVM, Xen, OS-level CPU pinning (outside Solaris Zones) and similar.
The memorandum’s exclusion of VMware vSphere is not a statement that the licensable read at a host or cluster level is wrong; it is the publisher’s assertion that the bounded-core read does not apply. The buyer-side contractual position then reads: in the absence of a contractual partitioning clause, the licensable read is the deployed cores running the Oracle workload, which the buyer should be able to demonstrate from the cluster’s affinity-rule configuration, the published version-by-version host-mobility scope and the actual deployment history.
The buyer running Oracle Database on VMware vSphere holds three positions. The first is the affinity-rule discipline: a DRS / HA configuration that pins the Oracle VM to a named set of hosts, with a documented anti-affinity rule against the wider cluster, bounds the licensable core count to those named hosts as the deployment-level evidence.
The second is the version-by-version host-mobility scope. The published vSphere version determines the host-mobility scope (storage vMotion, cross-cluster vMotion, cross-vCenter Enhanced Linked Mode, cross-Datacenter mobility in later versions). The buyer documents the deployment-level mobility scope at the date of any audit; the documented scope is the buyer’s defensible read.
The third is the wider Broadcom context. The acquisition has reset the VMware commercial surface and has compressed the renewal cycle; the Oracle-on-VMware question therefore now reads against a moving VMware-side commercial position as well as the Oracle-side policy memorandum. The deeper read sits at Oracle and VMware after Broadcom, and the wider Broadcom read sits at the Broadcom / VMware pillar.
A buyer responding to an LMS audit on a virtualised estate holds the partitioning conversation at the technical-review phase. The publisher’s position will read the memorandum and propose a host- or cluster-level licensable core count; the buyer’s counter reads the deployment-level evidence (affinity rules, host pinning, mobility scope, deployment history) and proposes the deployment-level licensable core count.
The two positions are not symmetric in their evidentiary basis. The publisher cites the memorandum (a policy document); the buyer cites the contract (an order document and a master agreement) and the deployment evidence (affinity rules, mobility logs, deployment history). The contractual evidence is the load-bearing evidence; the policy memorandum is supporting publisher narrative.
The wider audit-anatomy read sits at LMS audit anatomy; the scope-control read sits at LMS scope control; the settlement-position read sits at LMS settlement position; the audit-defence programme sits at audit defence.
The buyer holds three positions against the partitioning policy. The first is the deployment evidence (affinity-rule configuration, host pinning, mobility logs), maintained as a continuous artefact rather than an audit-time exercise. The second is the contractual position (the order document, the master agreement, any explicit partitioning clause where one exists), read against the policy memorandum rather than under it. The third is the architectural position (the design choice to operate the Oracle workload inside a hard-partitioned configuration where the commercial economics warrant it).
The Admodum methodology runs the partitioning read at engagement start and embeds it inside the audit-quality inventory. The output is a defensible deployment-level licensable core position that the buyer can present at any subsequent LMS audit.
The wider editorial context sits in the Oracle licensing pillar. The aggregated reading list sits in the Oracle knowledge hub. The engagement entry point sits in the Oracle practice.
Oracle licenses software on virtual machines through its partitioning policy. The policy recognises only approved hard-partitioning technologies as bounding the licensable core count; soft partitioning such as VMware vSphere, Microsoft Hyper-V and KVM is excluded, so Oracle asserts that every processor on which the software could run must be licensed. Crucially, this policy is a non-contractual memorandum.
Oracle's policy position is that all hosts where an Oracle VM could run must be licensed, but that position rests on a policy memorandum, not the contract. A buyer's contractual position rests on the order document and deployment evidence such as affinity rules, host pinning and the version-by-version vMotion scope, which can support a narrower, deployment-level licensable core count.
Hard partitioning physically binds an Oracle workload to a fixed set of processor cores using an Oracle-approved technology, for example IBM LPAR, Oracle VM Server / LDOM, or Solaris Zones with capped CPUs, so only those cores are licensable. Soft partitioning, such as VMware, Hyper-V and KVM, is not recognised by Oracle as limiting the licensable cores.
No. The Oracle partitioning policy is a publisher policy memorandum published on Oracle's website. It is not part of the Oracle Master Agreement, the OLSA or the order document, so it is not a contractual instrument. The buyer's contractual position rests on the signed agreement, not on the policy.
VMware vSphere is treated as soft partitioning under Oracle's policy, meaning Oracle does not recognise it as bounding the licensable core count. The buyer's defence is deployment evidence, documented host affinity, pinning and mobility scope, read against the contract rather than the policy.
A senior Admodum Oracle advisor will run the partitioning read against your virtualised Oracle estate on a private call. Active audits route to the Audit Defence programme; deployment-level inventory builds sit inside the Oracle practice.