Oracle Linux KVM is the only KVM variant that can legally cap an Oracle license count, and only when vCPUs are pinned exactly as Oracle's data sheet prescribes and documented in a form an auditor will accept. This page separates the approved configuration from the six ways buyers accidentally forfeit the cap and pay for every core in the host.
Oracle Linux KVM is the only KVM variant that can legally cap an Oracle license count, and only when vCPUs are pinned exactly as Oracle's data sheet prescribes and documented in a form an auditor will accept. This page separates the approved configuration from the six ways buyers accidentally forfeit the cap and pay for every core in the host.
Buyers keep reading Oracle's Server Partitioning policy as a list of approved products. It is not. It is a list of approved configurations, and the difference is worth millions on a large host. The policy's own language on the relevant entry is conditional from the first clause: Oracle Linux KVM or Oracle VM Server "may be used as hard partitioning technology only as..." followed by the configuration requirement. Then comes the sentence that ends most arguments before they start: Oracle has "deemed certain technologies, possibly modified by configuration constraints, as hard partitioning, and no other technology or configuration qualify." Read those two together and the practical consequence is blunt. Native upstream KVM, Red Hat KVM and RHV, oVirt, Proxmox VE, and OpenShift Virtualization are soft partitioning by default. Under soft partitioning you license every physical processor in the physical server regardless of how many vCPUs you allocated to the Oracle guest. A four-vCPU database VM on a dual-socket 64-core host is a 64-core license event, not a four-core one.
Two facts about the document itself matter in negotiation. It is dated February 14, 2022, it is marked "for educational purposes only," and it expressly states it may not be incorporated into any contract and is subject to change without notice. That cuts both ways, and we cover the second edge in the section on turning policy into terms. Our soft partitioning audit defense guide works through the count mechanics in detail.
| Platform | Oracle's default classification | Licensable cores |
|---|---|---|
| Oracle Linux KVM, pinned per data sheet, OLVM-managed | Hard partitioning | Pinned cores only |
| Oracle Linux KVM, unpinned or standalone | Soft partitioning | All physical cores in host |
| Native or upstream KVM | Soft partitioning | All physical cores in host |
| Red Hat KVM and RHV | Soft partitioning | All physical cores in host |
| oVirt | Soft partitioning | All physical cores in host |
| Proxmox VE | Soft partitioning | All physical cores in host |
| OpenShift Virtualization | Soft partitioning | All physical cores in host |
The policy approves configurations, not product badges, and the catch-all sentence says no other configuration qualifies.
This is the finding that surprises most infrastructure teams. A greenfield Oracle Linux KVM or OLVM build carries full-host liability until it is pinned. Oracle's own hypervisor gives you no discount for buying into the ecosystem. Practitioner guidance is explicit that OLVM can be used to configure hard-partitioned VMs but does not do so by default, and Oracle's licensing commentary is equally direct: using an approved hard partitioning technology does not automatically reduce the license count. You must configure it as Oracle requires, hard-cap CPU usage, and document it. Running Oracle Database on Oracle VM Server or Oracle Linux KVM saves nothing unless vCPUs are pinned to specific physical cores and cannot float.
Treat the entitlement as a three-part precondition chain, all three required, no partial credit:
The consequence buyers miss: a standalone Oracle Linux KVM host pinned only with virsh sits outside the documented procedure. The pinning may be technically identical at the kernel level, but you cannot produce the evidence trail Oracle's process expects, and an auditor is not obliged to accept an undocumented equivalent. Practitioners who have built this describe it candidly: the compliant configuration is quite difficult to actually construct correctly. Budget engineering time accordingly, and see how this compares to other platforms in our 2026 virtualization licensing overview. In 25 years of these disputes, "we run Oracle's hypervisor" has never once been accepted as a standalone defense.
Oracle's Hard Partitioning with Oracle Linux KVM data sheet defines the accepted mechanism narrowly: binding vCPUs to specific physical CPU threads or cores and preventing those vCPUs from being scheduled on any physical CPUs, threads, or cores other than the ones specified. The sanctioned instrument is olvm-vmcontrol, and Oracle's guidance is to install it on the OLVM engine host, not on a jump box or an admin laptop, because the utility talks to the engine API rather than to libvirt directly. This matters for a reason buyers underestimate: an unmanaged Oracle Linux KVM host pinned only with virsh sits outside the documented path. Oracle does not require OLVM to run Oracle Linux KVM, but the hard partitioning procedure is written against OLVM management, and in 25 years of these arguments I have never seen Oracle's LMS team accept a pin that could not be traced back to the engine. Assume that a standalone host pinned by hand is a full-socket liability until proven otherwise, and read our Oracle soft partitioning audit defense guide for what happens when it is not.
The utility takes three commands: getvcpu, setvcpu, and rmvcpu. A representative pin looks like olvm-vmcontrol -m <olvm_fqdn> -u admin@internal -v <vm> -c setvcpu -s 0,1 -e -f. Two operational facts follow. First, the VM must be rebooted before the CPU setting takes effect, so a pin applied on Friday and not restarted until the next maintenance window is not a pin during that interval. Second, the pin does not travel, which makes host affinity documentation part of the evidence pack rather than an optional nicety.
Set a two-layer verification standard and enforce it as a change-control gate. Layer one: getvcpu must return explicit per-vCPU output, for example vcpu 0 pinned to cpuSet[0-3], captured with a timestamp and the VM name. Layer two: independent confirmation on the KVM host itself via virsh, because auditors treat a single tool's word as an assertion and two tools' agreement as evidence. The string "No CPU pinning is configured" is the one output that converts a design intention into an audit finding, and it is the string your monitoring should alert on. Store both outputs per VM, per quarter, with the reboot record attached.
A pin that has not been rebooted into effect and captured in two independent tools is not a pin, it is an intention.
Most failed pins we unwind are arithmetic errors, not policy errors. The engineer read the policy correctly, understood that vCPUs must be prevented from floating, and then pinned to the wrong integers. Take a common two-socket host: 24 physical cores (2 x 12) with hyperthreading enabled, producing 48 logical CPUs, two vCPUs per core. Linux enumeration on many platforms interleaves siblings across NUMA nodes, so node0 holds one set of thread IDs and node1 holds the other, and sibling threads of a single core are not adjacent integers. Pinning a VM to "cores 0 to 7" without mapping sibling threads leaves half of each core's execution capacity outside the pinned set, which means Oracle can be scheduled on physical cores you did not license. That is a soft partition wearing hard partition paperwork.
| Assumption made | Physical reality on a 2 x 12 core host with SMT | License consequence |
|---|---|---|
| "8 cores pinned" via cpuSet[0-7] | 8 logical CPUs, siblings unpinned, spans 8 cores partially | Oracle schedulable outside the set, cap forfeited |
| Sibling pairs mapped, cpuSet[0-7,24-31] | 8 full physical cores, both threads bound | 8 cores countable, cap defensible |
| Pinned set spanning node0 and node1 | vCPUs cross socket boundary | NUMA-mode condition not met |
| No maximum core count recorded | Set can be widened silently | Policy requirement for a capped count unmet |
Treat Oracle's NUMA-mode requirement as a documented licensing condition, not performance tuning advice. The pinned set must sit within a coherent node topology, and your evidence should show the host's lscpu sibling map alongside the getvcpu output so the arithmetic is auditable by a third party. The policy also requires every approved hard partitioning technology to carry a capped or maximum number of cores, which means an engineering ticket saying "pinned as needed" fails on its face. Record the maximum core count per VM, per host, and reconcile it quarterly against your entitlement position using the same discipline described in our Oracle virtualization licensing guide for 2026. Do this before Oracle asks, because after they ask, the arithmetic is theirs to interpret.
A valid hard partition is a state, not an event. Oracle's Hard Partitioning with Oracle Linux KVM data sheet makes the fragility explicit: live migration of CPU-pinned VMs to another Oracle Linux KVM node is not permitted, and because live migration is not permitted, the cluster (a pool of OL KVM nodes with shared storage) must not be configured with any scheduling policy available in OLVM. That is two separate forfeitures in one sentence. Migrating one pinned guest breaks the pin for that guest. Leaving a scheduling policy enabled on the cluster breaks the argument for every pinned guest on every node in that pool, because Oracle's position is that the capability to move, not the observed movement, defeats the physical restriction. Teams that came from Oracle VM Server carry the same exposure forward: the legacy guidance that DRS and DPM policies should not be enabled for server pools containing pinned guests is applied by analogy to OLVM automation, and in our audit-defense work we routinely find these policies switched on by an infrastructure team that never read the licensing paper. Three quieter failures follow. Pinning does not traverse hosts and cannot be transferred, so each pinned VM must be tied to a named KVM host with written affinity, and a missing affinity record is treated as an unproven pin. Non-Oracle guests left unpinned on the same host are free to be scheduled onto the pinned physical cores, which contradicts the claim that those cores are exclusively reserved. Finally, the pin only takes effect after a reboot and can silently vanish across a host reboot, an OLVM upgrade, or a VM redefinition, at which point `getvcpu` returns "No CPU pinning is configured." Each of these six converts the whole physical host back to a soft-partition count, exactly as described in our Oracle soft partitioning audit-defense guide.
Migrating one pinned guest breaks that guest; leaving a scheduling policy enabled breaks every node in the pool.
Size the gap yourself before an auditor sizes it for you. Take a two-socket host with 24 physical cores total (12 per socket), running one Enterprise Edition database VM with 4 vCPUs pinned to 4 hyperthreads on 2 physical cores. Correctly pinned and documented, the licensable footprint is 2 cores times the 0.5 Intel core factor, so 1 Processor license. Fail any of the six tests above and the host is soft-partitioned: 24 cores times 0.5 equals 12 Processor licenses, a 12x multiplier for a workload that never changed. Now scale it. A four-node cluster with one unmanaged OLVM scheduling policy pulls all four nodes into scope even if only one node hosts the database, because Oracle argues the VM could be scheduled anywhere in the pool.
| Scenario | Cores counted | Core factor | Processor licenses |
|---|---|---|---|
| Single host, pinned correctly | 2 | 0.5 | 1 |
| Single host, soft-partition finding | 24 | 0.5 | 12 |
| Four-node cluster, pinned per host | 2 | 0.5 | 1 |
| Four-node cluster, scheduling policy enabled | 96 | 0.5 | 48 |
The 48-license figure is the number that matters, and it is only the base. Enterprise Edition rarely travels alone: RAC, Multitenant, Advanced Security, and Diagnostics and Tuning are each licensed per Processor on the same count, so a stack with three options multiplies the 47-license shortfall by four before any discount is applied. Oracle then adds back support on the shortfall, typically calculated from the date the unlicensed configuration began, which in our experience compounds a two-year-old misconfiguration into roughly half again the license claim. Run this arithmetic per cluster, per option, and compare it against the same exercise for your other estates using our 2026 Oracle virtualization licensing overview. If the modeled exposure exceeds the cost of rebuilding the pins properly, and it almost always does by an order of magnitude, remediate before you respond to anything from Oracle LMS.
Read finding 1 again and let it sink in: Oracle's own partitioning PDF says it is "for educational purposes only," reflects policies in effect as of February 14, 2022, "may not be incorporated into any contract," and is "subject to change without notice." That is Oracle telling you, in writing, that the document you are betting a seven-figure license position on binds nobody. It cuts both ways in theory and one way in practice. Oracle will cite the policy when it produces a finding against you, then disclaim it as non-contractual when you try to hold Oracle to the pinning procedure you followed correctly for three years. The only durable protection is language inside the ordering document or a signed amendment, and in 25 years of negotiating this exact point I have never seen Oracle volunteer it. You have to ask, and you have to ask when you have something Oracle wants.
Three clauses are worth pursuing, in descending order of what Oracle will actually concede. First, a named list of approved hard partitioning technologies for your estate, with the OLVM pinning procedure referenced by document title and version (the "Hard Partitioning with Oracle Linux KVM" data sheet as of a stated date), so the approved method is fixed rather than floating. Second, a defined licensable-core methodology for named hosts: list the serial numbers or host identifiers, state that licensable cores equal the pinned thread set, and remove the argument entirely for those machines. Third, and hardest to get, a change-of-policy protection stating that any subsequent Oracle revision to the partitioning policy does not retroactively expand scope for licenses purchased under this order. Oracle resists all three because the partitioning policy is a unilateral instrument, and unilateral instruments are worth more to the party holding the pen than any single deal is. Sales will tell you LMS or Global Licensing and Advisory Services owns the policy and cannot be bound. That is a routing answer, not a legal one, and it dissolves when the deal is large enough.
Timing is everything. Ask for this at renewal, at ULA exit certification, or bundled into any new Enterprise Edition purchase, never in isolation and never during an active audit. A standalone request signals that you know you are exposed and invites the review you are trying to avoid. Folded into a purchase Oracle wants to book before quarter end, the same clause becomes a small concession attached to a large number. If you cannot get any of it, price that failure honestly: you are running an unprotected configuration, and the analysis in our guide to which cores count across Oracle virtualization becomes your operating baseline rather than a reference. In the absence of terms, evidence discipline is the entire defense, and evidence discipline is only as good as the last month you verified it.
Thirty days is enough to move from unknown exposure to a defensible position. Work the sequence in order, because step two is worthless if step one is wrong.
On escalation: if the inventory shows a misclassified host, price the exposure at your actual Processor list and discount before you respond to any Oracle contact. Do not answer an audit notice, a "license review," or a friendly architecture questionnaire until that number exists, because the size of the gap determines whether you negotiate or remediate first. Route the pinning evidence pack through counsel or an independent advisor rather than uploading it into an Oracle-supplied collection script, which captures far more than the pinning question requires. Our soft partitioning audit defense guide covers what those scripts return and how to scope data provision narrowly.
No. Only technologies Oracle names in its partitioning policy qualify, and the policy states that no other technology or configuration qualifies. Upstream KVM, Red Hat Virtualization, oVirt, Proxmox VE, and OpenShift Virtualization are treated as soft partitioning, so every physical core in the host is licensable regardless of how few vCPUs you assign. CPU pinning on those platforms is a performance measure, not a licensing one.
Oracle's documented hard partitioning procedure requires the Oracle Linux KVM host to be managed by Oracle Linux Virtualization Manager and the pin to be applied with the olvm-vmcontrol utility. OLVM is not required to run Oracle Linux KVM generally, but it is required for the licensing path. Pinning a standalone host with virsh alone sits outside the documented method and gives an auditor an easy line of attack.
Yes. Oracle's data sheet states that live migration of CPU-pinned VMs to another Oracle Linux KVM node is not permitted under the hard partitioning policy, and that clusters holding pinned guests must not be configured with any OLVM scheduling policy. Enabling automated placement, even without an actual migration event, is enough to put the cap in dispute. Pin the VM to a named host and document the affinity.
Two independent layers, captured over time. Run getvcpu through olvm-vmcontrol so the output names each vCPU and its cpuSet, then confirm the same binding on the KVM host with virsh, and archive both with timestamps, hostnames, and change records. A single point-in-time screenshot is weak; a monthly verification history covering the full period under review is what holds up.
Because hyperthreading and NUMA layouts mean logical CPU numbering rarely maps to physical cores in a simple range. On a 24-core, two-socket host with hyperthreading you have 48 logical CPUs, and NUMA nodes often interleave sibling threads. If the pin set omits siblings, Oracle can still schedule on threads belonging to unlicensed cores, which defeats the cap.
You can ask, and it is the only durable protection, because the policy PDF is marked as educational, is not incorporated into any contract, and can change without notice. Pursue a named approved-technology list, a defined licensable-core methodology per host, and change-of-policy protection at renewal, ULA exit, or a new Enterprise Edition purchase. Expect resistance, and expect it to require negotiation leverage rather than a support ticket.
Oracle Analytics is sold as a perpetual per-processor server (OAS) and a per-OCPU cloud subscription (OAC). The prices, the metric math, and why the migration to OAC does not rever
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.
