CPU pinning is necessary but almost never sufficient to cap your Oracle license count. This is the technical proof an auditor demands and the control stack that survives contact with Oracle LMS.
How to Prepare for Your Oracle SaaS Negotiation
The 90-day renewal proposal with a 9 to 12 percent uplift is the bill for not preparing. The ARR compensation game, the utilization audit that finds 30 to 50 percent shelfware, benchmarks targeting 0 to 3 percent, one costed alternative, and sequencing toward May 31.
CPU pinning is necessary but almost never sufficient to cap your Oracle license count. This is the technical proof an auditor demands and the control stack that survives contact with Oracle LMS.
The question comes up in every virtualization review we run: "We pinned the Oracle VM to specific cores, so we only license those cores, right?" The honest answer is that pinning by itself decides nothing. Oracle's Partitioning Policy does not reward the act of pinning. It rewards a specific, named list of technologies configured in a specific way, and it rejects everything else as soft partitioning that licenses the entire physical host or cluster. Whether your pinning reduces the count depends entirely on which platform you pinned on and whether you can prove the pin is permanent and the VM cannot roam.
After 25 years of negotiating and defending this exact fact pattern with Oracle, we can tell you where the money is lost: customers treat pinning as a licensing control when Oracle treats it as an evidence problem. This page walks the cross-platform logic, the audit-grade proof required on each approved technology, and how to stack controls into a cap that holds. For the wider policy framing, start with the Oracle Partitioning Policy explainer, then return here for the evidence test.
Oracle divides all virtualization into two buckets: hard partitioning and soft partitioning. Only Oracle-approved hard partitioning technologies, as named in the Oracle Partitioning Policy document, are permitted to limit the number of software licenses required for a given server or cluster. Any technology not on that list is soft partitioning by default, and soft partitioning licenses the whole physical environment the Oracle binary can reach. Hard partitioning is narrowly defined as partitioning that "physically bounds the number of processors" available to Oracle software. When it applies, you license the processors in the partition, not the physical server.
Two structural facts drive everything downstream. First, the Partitioning Policy is not part of your signed contract. Oracle publishes it as guidance and applies it during audits, but it sits outside the Oracle Master Agreement unless it has been explicitly referenced into your ordering documents. That cuts both ways: it is not a contractual right you can enforce, and Oracle can revise it. Second, the deciding test on most platforms is CPU overcommit. Oracle treats hypervisors that support overcommit (a VM borrowing cycles beyond its allocation) as soft partitioned, and hypervisors that cannot as hard partitioned. Pinning does not change whether the platform can overcommit.
Oracle does not reward the act of pinning. It rewards a named technology, configured to Oracle's specification, evidenced at audit time.
VMware is the case that costs customers the most, because the assumption is so intuitive and so wrong. We have watched customers assume vSphere CPU pinning counts as hard partitioning; Oracle treats it as soft partitioning and licenses every host in the cluster. Oracle's policy explicitly disallows software or OS-based controls used to reduce licensing, and it names them: VMware DRS rules, CPU affinity settings, vSphere CPU pinning, or any similar configuration. In Oracle's reading these are all soft partitioning.
The reasoning Oracle applies is that affinity and pinning rules are reversible. You might set a "Must run on Host A only" rule for the Oracle VM, and Oracle will still treat the entire cluster as licensable because that rule can be changed or overridden in seconds and is not a permanent, hardware-based partition. The trigger that expands the perimeter is mobility. If a VM can move between hosts through vMotion, DRS, HA, or any automated migration feature, Oracle's position is that Oracle software must be licensed on every host in the cluster the VM could potentially run on. Since Broadcom's acquisition reshaped VMware pricing and cluster design, this exposure is worth re-modeling; see Oracle on VMware after Broadcom for the current math.
The same logic sinks other soft-partition platforms. If you are on Nutanix AHV, the cluster is the license unit, not the VM, for exactly the same overcommit and mobility reasons. Pinning does not rescue you there either.
The list is finite and Oracle publishes it. Anything not named here is soft partitioning. The table below is the current approved set, with the critical condition each carries. Note that "capped" is not a nicety; on several technologies it is the whole point, and an uncapped configuration reverts you to soft partitioning.
| Approved technology | Vendor / platform | Mandatory condition |
|---|---|---|
| Physical Domains (PDomains / Dynamic Domains) | Oracle / Sun | Domain physically bounds processors |
| Solaris Zones | Oracle Solaris | Capped Zones / Containers only; uncapped does not qualify |
| LPAR (with DLPAR on AIX 5.2+) | IBM | Partition bounds processors |
| Micro-Partitions | IBM | Capped partitions only |
| vPar, nPar | HP-UX | Hardware or firmware partition |
| Integrity Virtual Machine | HP Integrity | Capped partitions only |
| Secure Resource Partitions | HP-UX | Capped partitions only |
| PPAR | Fujitsu | Physical partition |
| Oracle Linux KVM | Oracle | Capped via CPU pinning, migration disabled |
Two observations from the negotiating table. First, the dominant enterprise virtualization platform, VMware, is deliberately absent, while Oracle's own VM and Oracle Linux KVM qualify. That is not an accident; it creates a standing commercial incentive for Oracle to hunt for VMware-hosted Oracle during audits. Second, Oracle Linux KVM was added later, and it is the platform where pinning genuinely counts, provided you evidence it correctly. For the core-counting mechanics on that platform, see Oracle licensing on KVM and OLVM, and for the Zones equivalent, Solaris Zones capped versus uncapped.
This is where estates that could win still lose. In roughly one in three estates we review that use Oracle Linux KVM or Solaris Zones, the capping was not set the way the policy requires, which voids the benefit entirely. The customer believed they had a hard partition; the auditor found soft partitioning and priced the whole host. Oracle does not accept verbal assurances that migration is disabled or pinning is in place. The bar is technical evidence, not attestation.
On Oracle Linux KVM the requirements are precise and sequenced. CPU pinning must be configured as one of the first tasks after the VM is created, and at minimum before the Oracle Database software is installed. Pinning cannot roam: it binds the VM to a particular KVM host and cannot be transferred between hosts. Live migration of a pinned VM to another Oracle VM Server is not permitted under the license terms, so DRS and DPM policies must not be enabled for server pools containing pinned guests. In Oracle Linux Virtualization Manager you must select "Do not allow migration" as the Migration Mode so the VM can never move off its host.
A subtle trap: if the VM is running when you change pinning, a restart or reboot is not sufficient. You must stop the VM and then start it from the Virtualization Manager for the pinning change to take effect. Skip that and your configuration file says one thing while the live binding says another, which an auditor will find.
The tooling Oracle expects is specific. Use the olvm-vmcontrol utility (from the Oracle Linux yum server or Unbreakable Linux Network) to set and read the CPU and vCPU bindings through the Virtualization Manager. For independent verification, run virsh --readonly vcpuinfo. The tell is the CPU Affinity field: on a 48-CPU host, an affinity value of 0-47 means the CPUs have NOT been pinned and the manager is free to use any CPU. That is the exact output Oracle will screenshot to reject your cap.
An affinity value of 0-47 on a 48-CPU host is not a pinned VM. It is a full-host license waiting to be assessed.
olvm-vmcontrol get output showing the actual CPU/vCPU binding, dated and tied to the host.virsh --readonly vcpuinfo output showing a bounded affinity set (not 0-N across all CPUs).Pinning is one control. A cap that holds is a stack of controls, each closing a door Oracle would otherwise walk through. The pattern we deploy for clients uses Oracle-approved hard partitioning as the foundation, then removes every path Oracle uses to argue the perimeter is larger. Disable live migration for Oracle workloads. Remove shared SAN access so an auditor cannot argue the binary could reach other hosts. Dedicate hardware where feasible. Maintain evidence continuously (logs, screenshots, configuration files), document Oracle workload placement and CPU entitlements, and write the audit response plan before the audit letter arrives.
Understand what Oracle looks for to reject your cap. If Oracle finds that migration is enabled, that Oracle binaries exist on multiple hosts, or that shared SAN access exists, it can demand retroactive licensing for every accessible core. Any one of those three is enough. On soft-partition platforms where hard partitioning is not available at all, the industry-standard containment pattern is a dedicated cluster: physically separated hosts licensed in full and running only Oracle workloads, so the licensing perimeter is bounded by the cluster edge rather than the whole data center. That is a mitigation, not a cap, but it converts an unbounded exposure into a known cost.
If you are choosing a platform rather than defending one, the decision belongs upstream. Weigh KVM, Solaris Zones, and OCI against your workload and audit posture using the virtualization decision matrix and the broader soft partitioning audit-defense guide before you commit hardware.
The economics justify the rigor. Where capped configurations were implemented correctly and evidenced at audit time, we see savings of 30 to 60 percent on Database Enterprise Edition against a full-host license. On the exposure side, estates that had hard partitioning available but left it unconfigured carried 50 to 70 percent avoidable exposure, meaning half to two-thirds of the assessed shortfall existed only because the evidence was missing, not because the technology was wrong. The delta between a defensible cap and a full-host assessment is the difference between a routine renewal and a seven-figure compliance event.
| Scenario | License basis | Typical outcome |
|---|---|---|
| VMware cluster, CPU pinning only | Every host in the cluster | Full soft-partition exposure; pinning ignored |
| OLVM, pinned but affinity 0-N or migration enabled | Full physical host | Benefit voided; retroactive assessment |
| OLVM, capped + migration disabled + evidenced | Pinned cores only | 30 to 60 percent saving vs full host |
| Hard partitioning available but unconfigured | Full physical host | 50 to 70 percent avoidable exposure |
Before any renewal or audit, run the evidence test on your own estate first, the same way you would run an internal Oracle license audit. If your pinning cannot survive a virsh vcpuinfo screenshot and a migration-mode check, it is not a cap. Fix the configuration, retain the proof, and only then claim the reduced count. For where you sit in Oracle's targeting, review how Oracle selects audit targets so you know whether the clock is already running.
No. Oracle's Partitioning Policy explicitly names vSphere CPU pinning, CPU affinity, and DRS rules as soft partitioning. Oracle licenses every host in the cluster the VM could run on, regardless of the pin, because the rule is reversible and the platform supports CPU overcommit and vMotion.
Pinning counts on Oracle Linux KVM when the VM is capped, migration is set to "Do not allow migration," and the binding is evidenced. It is also part of qualifying configurations on Oracle's approved list such as capped Solaris Zones and IBM LPAR. It never counts on VMware or Nutanix AHV.
Technical proof, not verbal assurance. Expect to produce olvm-vmcontrol binding output, a virsh --readonly vcpuinfo showing a bounded CPU affinity set, confirmation that migration and DRS/DPM are disabled, and timestamps proving pinning was applied before the Oracle binary was installed.
Run virsh --readonly vcpuinfo and check the CPU Affinity field. On a 48-CPU host, a value of 0-47 means the CPUs are not pinned and the manager can use any CPU. Also note that changing pinning on a running VM requires a full stop and start; a restart or reboot does not apply the change.
Not by default. Oracle publishes the policy as guidance and applies it during audits, but it sits outside your Oracle Master Agreement unless it has been explicitly referenced into your ordering documents. That means it is not a contractual right you can enforce, and Oracle can revise it.
A dedicated cluster: physically separated hosts licensed in full, running only Oracle workloads, with no shared SAN access to other environments. This bounds the perimeter to the cluster edge and converts unbounded exposure into a known, fixed cost, though it is a mitigation rather than a true core-level cap.
The strategic framework for Oracle audit defense across LMS, license verification, and contractual response. Beyond the tactical playbook.
Gated with a work email on the download page. No sales follow up you did not ask for.
Get the White Paper →
500+ enterprise clients. 11 vendor practices. Industry recognized. One conversation can change what you pay for the next three years.
One buyer side briefing a week. Renewal signals, audit moves, and the levers that work. No vendor spin.