Oracle soft partitioning in 2026. Every core counts until you prove otherwise.

Oracle's partitioning policy names nine technologies as hard partitioning and rejects everything else, which means KVM, containers, and most of what you actually run in 2026 default to a full-server or full-cluster license count. This guide shows exactly how the count is built on each platform, where Oracle's audit position exceeds its own written policy, and which architectural moves survive an LMS review.

The 2026 Baseline: Nine Approved Technologies, Everything Else Is Soft

Every soft partitioning argument you will ever have with Oracle collapses into one closed list published in a single PDF (oracle.com/assets/partitioning-070609.pdf). That document names the technologies Oracle deems hard partitioning, then adds the sentence that does all the damage: no other technology or configuration qualifies. That is not guidance, it is a default. Unless your platform appears on the list and is configured the way Oracle requires, the counting basis is every physical core in the server, and in clustered configurations Oracle's audit teams will push for every core in the cluster. After 25 years of arguing this list line by line, my advice is blunt: treat hard partitioning as an exception you earn and document, not a property your hypervisor has. Note also the structural asymmetry buyers keep missing. The list is short, static, and skewed toward legacy Unix and Oracle's own stack, while the technologies actually in production in 2026 (KVM, Nutanix AHV, Proxmox, Kubernetes) are absent by design. That is a commercial choice, not a technical judgment, and it is worth naming as such when you negotiate.

Read down the condition column and the pattern is unmistakable. The universal precondition is a capped or maximum number of cores or processors for the given partition. Anything that lets a workload consume more cores than you licensed, whether through uncapped shares, a scheduling policy, or live migration to a second host, breaks the cap and therefore breaks the defense. This is why capability, not usage, drives the count. Oracle does not ask what the VM consumed last quarter; it asks what the VM was technically permitted to reach. Our field data on this is unflattering: in roughly one in three estates running Oracle Linux KVM or Solaris Zones, the capping was not configured the way the policy requires, which voided the benefit entirely. The technology was approved. The implementation was not. If you have never had a third party verify your cap configuration against the policy text, assume you are in that third until proven otherwise, and read the mechanics in our Oracle partitioning policy breakdown before you assert a reduced count in writing.

Hard partitioning is not a property your hypervisor has; it is an exception you earn, configure, and document.

The practical takeaway for 2026: build your license position from the list, not from your architecture diagram. Inventory every host running Oracle software, map each to one of the ten entries above or to nothing, and treat the "nothing" bucket as full-server (or full-cluster) exposure until you have evidence otherwise. That bucket is where audit claims are manufactured, and it is also where the cheapest remediation lives, because moving three databases off a shared 96-core cluster onto two capped or dedicated hosts changes the count arithmetically rather than argumentatively.

The Policy Is Not Contractual, and Why That Argument Alone Loses Audits

Now the part every general counsel latches onto. The partitioning PDF disclaims itself. Oracle states plainly that the document may not be incorporated into any contract, does not constitute a commitment to specific terms, and is subject to change without notice. Independent legal analysis reaches the same conclusion from the other direction: Scott and Scott LLP's November 2024 review found that the license agreement's own counting language does not expressly or impliedly incorporate the Partitioning Policy, and that at best the policy functions as a safe harbor for Oracle-approved technologies. Both propositions are correct. Your OLSA or OMA obligates you to license processors on which the programs are installed or running; it does not obligate you to accept Oracle's list of nine plus one as the exclusive definition of a partition boundary.

The non-binding argument wins arguments about the policy and loses arguments about the invoice.

Then reality intrudes. Across the virtualization engagements we have handled, the non-binding argument on its own did not reduce the claim. Not once as the primary lever. Three reasons, all structural. First, Oracle holds the audit position, which means the number on the table is Oracle's number and the practical burden of disproof sits with you. Second, if the policy is not contractual, you have removed the safe harbor without supplying a substitute definition, and Oracle's fallback (all installed cores) is the literal contract text. Third, the argument is a litigation argument, and Oracle prices litigation risk against a customer who wants a renewal, cloud credits, and a support waiver in the same quarter. Do not deploy your best legal point where it produces a stalemate instead of a discount.

The sequence that works is the reverse. Build the architectural and evidentiary case first: configuration exports proving caps, migration and scheduling policy settings proving no host can be reached, storage and network isolation, change control history showing the boundary held over time. That is what moves a per-cluster count to a per-host count, and it is measurable. Hold the non-contractual argument in reserve as settlement leverage on the residual, where it does real work: capping penalty interest, resisting retroactive backdating, and pushing Oracle toward a forward-looking commercial resolution rather than a compliance invoice. If you are heading into renewal with unresolved virtualization exposure, sequence the technical remediation before the commercial conversation, as we set out in our guidance on reducing your Oracle footprint before renewal. The legal point is your closing argument, not your opening one.

Oracle Linux KVM and OLVM: The Only KVM That Can Cap, and the Conditions That Void It

There is exactly one KVM-family entry that Oracle's own server partitioning policy will accept as hard partitioning, and it is Oracle's own: Oracle Linux KVM and Oracle VM Server. Note the phrasing Oracle uses, because it is deliberate. The policy says these products may be used as hard partitioning technology "only as specified," which means the exception is not attached to the product, it is attached to a configuration you must build and then keep intact. Buy Oracle Linux KVM, pin CPUs, and assume you are capped, and you have bought nothing. In roughly one in three estates we review that rely on Oracle Linux KVM or Solaris Zones for a capped count, the capping was not implemented the way the policy requires, which voids the benefit entirely and hands Oracle a full-cluster claim on the day the audit letter lands.

Two configuration choices kill the cap, and both are the kind of thing a virtualization team turns on for good operational reasons without ever being told it is a licensing event. First, a cluster of Oracle Linux KVM nodes on shared storage must not be configured with any scheduling policy available in Oracle Linux Virtualization Manager. Not a tuned policy, not a conservative one: any. OLVM's default posture and its scheduling policies exist to balance load, which is precisely the behavior Oracle reads as "this VM could move." Second, live migration used with pinned VMs running Oracle software removes hard partition treatment. Enable one, and the cap you paid for evaporates. In our experience the scheduling policy is the more common failure, because it is set once at cluster build time by an infrastructure engineer and never revisited, while live migration at least tends to leave an audit trail someone remembers.

When the cap breaks, Oracle does not immediately jump to every core in the cluster. The documented fallback is narrower and worth knowing precisely: count the VMs running Oracle software, then license that same number of physical servers, starting with the largest by core count, up to the total number of physical servers in the cluster. That last clause is the ceiling, and it is the reason large clusters with a handful of Oracle VMs are less catastrophic than the VMware equivalent, and why estates with many Oracle VMs hit the full-cluster wall anyway.

Work the numbers. Three Oracle Database VMs on that cluster, cap voided, produces an 88 processor license claim against a properly capped design that might have needed 8 or 12. Push to eight Oracle VMs and the count stops at 144 because you have run out of servers, not because Oracle stopped counting. At Enterprise Edition list of roughly 47,500 per processor, the gap between the capped design and the eight-VM fallback is not a rounding error, it is a nine-figure list-price exposure before support. Your action: pull the OLVM cluster policy configuration and the migration logs today, confirm no scheduling policy is set, confirm live migration is disabled for Oracle-bearing VMs, and put both under change control with a named owner. If either is on, you are not capped, and you should price the fallback before Oracle does.

Generic KVM, RHV, and Proxmox: Same Bracket as VMware and Hyper-V

Everything else in the KVM world gets nothing. Red Hat KVM, RHV, Red Hat OpenShift Virtualization, Proxmox VE, and any community or third-party KVM distribution sit in exactly the same soft partitioning bracket as VMware ESXi and Microsoft Hyper-V. The policy names nine technologies and says no other technology or configuration qualifies, and generic KVM is not among them. This matters more than teams expect, because KVM is the same hypervisor Oracle itself blesses in Oracle Linux KVM. Buyers reasonably assume the technical mechanism is what earns the cap. It is not. The vendor's name on the distribution is what earns the cap, and Oracle has never wavered on that in 25 years of these conversations.

No configuration you apply rescues it. vCPU pinning, cgroups and cpuset constraints, NUMA affinity, libvirt CPU quotas, Proxmox resource limits, and RHV affinity groups are all invisible to Oracle's count. Not "weakly persuasive," invisible. The reason is that none of them are enforced by a boundary Oracle can verify as immutable, so Oracle falls back to the question it always asks: where could this workload run? On a shared-storage cluster with live migration available, the answer is every host, and the count follows.

Quantify the gap, because the intuitive number and the audit number are not close. Take a 4-vCPU Oracle Database Enterprise Edition VM on a three-node RHV cluster with 64 cores per node. The intuitive expectation is 4 vCPUs at a 0.5 Intel core factor, so 2 processor licenses. Oracle's position is 192 physical cores across the cluster at 0.5, which is 96 processor licenses. That is a 48x multiplier from one VM, and at Enterprise Edition list it converts a low-six-figure assumption into a mid-eight-figure claim before options and support. Add Real Application Clusters or Advanced Security on top and the multiplier applies to those too.

There are three fixes that hold up, and they are the same three whether you run RHV, Proxmox, or ESXi. Physical separation onto dedicated hosts with no shared storage path to the wider cluster is the cleanest and the only one that needs no Oracle cooperation. Migration to Oracle Linux KVM with correct capping works if you accept the configuration constraints above and the operational cost of losing scheduling policies. A licensed-to-cluster negotiation with an explicit contractual boundary clause is the commercial route: you pay for a defined host set, and the ordering document names the hosts, the cluster, and the cores so Oracle's audit team cannot reinterpret the perimeter later. Pinning is not on that list. Neither is a support ticket where someone at Oracle said it was fine, and neither is a policy PDF read that concludes the document is non-contractual, which is true and still loses the argument on its own. Decide which of the three you are funding, and decide before your next renewal cycle, because footprint reduction ahead of renewal is the only window where you hold real leverage.

Solaris Zones: Three Capping Methods Oracle Will Accept, and the ncpus Detail That Trips Estates

The rule is short enough to memorize: capped zones only. An uncapped zone licenses every core in the physical server, and Oracle's Server Partitioning policy names Solaris Zones with the parenthetical qualifier "capped Zones/Containers only" for exactly that reason. There is no partial credit for a zone that is usually small. Oracle's October 2014 white paper, "Hard Partitioning With Oracle Solaris Zones," sets out three configurations Oracle will accept: a zone with the capped-cpus resource control applied, a zone bound to a dedicated CPU set of a fixed size, and a resource pool created with a set number of CPUs to which one or more zones are added. That third method is the one most SPARC estates actually run and the one most frequently misdocumented, because the constraint lives in the pool definition rather than in the zone configuration, and an auditor reading only zonecfg output will not see it. In my experience across SPARC and x86 Solaris estates, the capping is present but the evidence trail is not, which produces the same audit outcome as no capping at all.

The detail that trips estates is the unit. The upper limit set by capped-cpus is expressed in hardware threads via the ncpus value, not in cores and not in sockets, and Oracle's white paper is explicit that ncpus need not be an integer and may include a fraction of a CPU. On a SPARC T-series part with eight threads per core, an ncpus of 16 is two cores, not sixteen. Get the thread-to-core arithmetic wrong in the direction of generosity and you have overlicensed for years; get it wrong the other way and Oracle will rebuild the count from the hardware, not from your intent. The second trap is the range rule: where a range is configured rather than a single value, the maximum value governs for licensing. A zone configured 2 to 12 is a 12 zone in every audit workbook Oracle will produce. If you are reviewing capacity headroom as part of a broader effort to optimize your Oracle footprint before renewal, ranges are the first thing to collapse to fixed ceilings.

Where a range is configured, the maximum value governs, so a zone set at 2 to 12 is a 12-core zone in every Oracle audit workbook.

Retention is the part buyers underinvest in. Oracle's reviewers ask for the configuration as of the audit date, but any competent negotiation over back maintenance turns on what the configuration looked like across the whole claim period, typically the trailing three to four years. Snapshot zonecfg, poolcfg, pooladm -c output, and prtdiag hardware inventory on a scheduled job, sign or hash the files, and store them outside the SPARC estate. Without that history, an uncapped week from 2023 becomes an uncapped four years in Oracle's model, and you will be arguing from memory against their spreadsheet.

IBM PowerVM: Capped Pools Qualify, Live Partition Mobility Doubles the Bill

Power is one of the few platforms where the partitioning policy actually helps you, provided you stay inside the lines. Dedicated LPARs and capped shared processor pools qualify as hard partitioning, and IBM Micro-Partitions appear on Oracle's approved list with the same "capped only" qualifier applied to Solaris Zones. Uncapped shared pools do not qualify, because an uncapped partition can consume entitlement beyond its allocation, and the policy's universal precondition is a capped or maximum number of cores for the partition. So far, so manageable. The trap sits one layer up, in mobility. Oracle's policy states directly that IBM PowerVM Live Partition Mobility is not an approved hard partitioning technology, and all cores on both the source and destination servers must be licensed. That is not an inference from the soft partitioning bracket; it is named text, which makes it one of the hardest positions to argue against in a review.

Quantify it before you argue it. Take two 32-core Power frames with LPM enabled between them and a single 4-core capped LPAR running Enterprise Edition. The capped LPAR alone is 4 cores. With LPM enabled, Oracle counts 64 cores across both frames. At the standard 0.5 Power core factor that is 32 processor licenses instead of 2, roughly a 16x multiplier on both license and support. Nothing in the estate changed except a mobility flag on the HMC.

Three actions. First, disable LPM on every frame that hosts an Oracle workload, and confirm it at the HMC partition profile level rather than trusting a change ticket. Second, capture the HMC setting as dated evidence on the same schedule you use for Solaris zone configuration, because "we never used it" loses to "it was enabled." Third, stop treating an LPM-enabled DR frame as free failover. It is a licensed-capacity decision, and if the business wants that mobility, price it, put the cost in front of the infrastructure owner, and decide deliberately. Where DR mobility is genuinely required, the negotiation move is to fix the counting basis in writing at renewal rather than rely on the policy PDF, which Oracle states may not be incorporated into any contract; the mechanics of that are covered in the Oracle partitioning policy breakdown.

Nutanix AHV: Where the Sources Conflict, and What to Assume

Here is the honest state of the record. Oracle's Server Partitioning policy PDF names nine technologies and says plainly that no other technology or configuration qualifies. Nutanix AHV does not appear anywhere in that document. The majority position across published analysis, and the only one consistent with the primary text, is that AHV is soft partitioning treated exactly the same way as VMware ESXi, Microsoft Hyper-V, and generic KVM: pinning, affinity rules, and host groups change nothing, and whether you run AHV or ESXi on the same Nutanix hardware makes no difference to the count. Against that sits a minority April 2026 claim asserting AHV qualifies as approved hard partitioning where sub-cluster isolation is documented and enforced, with drift collapsing the defense back to full cluster counting. We flag that claim as unverified against the Oracle PDF, because the PDF does not name AHV at any point, and Oracle's own text forecloses inference by exclusion. In 25 years of negotiating this vendor, I have never seen Oracle's LMS group concede an unnamed hypervisor as hard partitioning in a first-round finding. Budget on the soft-partitioning assumption. Treat any isolation argument as negotiation material you deploy after the finding lands, not as an entitlement you can rely on at design time or defend in a true-up model.

An unnamed hypervisor is negotiation material, never an entitlement.

There is one genuine carve-out worth naming, and it is architectural rather than argumentative. AHV storage-only nodes serve I/O and are structurally incapable of running virtual machines, so they do not require Oracle licenses. That is a real reduction in the licensable node count, and it is worth documenting node-by-node in your Oracle partitioning policy evidence file with cluster configuration exports showing which hosts cannot host a VM. What that carve-out is not is a compliance strategy. Storage segmentation is not a compliance requirement, because the Oracle contract is processor-centric and says nothing about storage layout. Do not let an architect sell you a storage redesign as an Oracle cost lever.

• Model AHV clusters at full cluster core count in every renewal and true-up scenario, then treat any isolation concession you win as upside rather than baseline.
• Separate Oracle workloads onto a dedicated, physically smaller AHV cluster; cluster size is the only variable Oracle's soft-partitioning math actually respects.
• Inventory storage-only nodes and hold the configuration evidence, because that exclusion survives scrutiny where sub-cluster isolation arguments do not.
• If a vendor or reseller tells you AHV is approved hard partitioning, ask them to point at the line in the Oracle PDF, in writing, on their letterhead.

Docker, Kubernetes, and the Registry-Presence Claim

Containers are the cleanest example of the policy's asymmetry. Docker and Kubernetes appear nowhere on the approved list, so a container capped to 2 CPUs earns exactly zero relief. Oracle's position is that all cores in the machine must be licensed, and the cgroup limit is treated as an operational preference rather than a licensing boundary. Buyers consistently misread this because the cap feels enforced: the container genuinely cannot exceed 2 CPUs, telemetry proves it, and the workload never touches the other 46 cores. None of that matters, because the policy conditions relief on named technology plus a capped partition, and containers fail the first test before the second is ever reached. Treat a Kubernetes CPU limit the way you would treat a VMware CPU reservation, as evidence of good hygiene that does nothing to your entitlement math.

Scope, however, does vary by orchestration, and that is where the real money sits. Standalone Docker is host-scoped. In a single-daemon deployment the licensable boundary is the physical host running the daemon, meaning all physical processors on that host, not a cluster. That is a defensible, bounded exposure you can size and budget. Swarm and Kubernetes reintroduce cluster scope. If an Oracle container can be scheduled onto any node in the Swarm, Oracle requires licenses across all nodes; for Kubernetes, Oracle asserts that every node where the Oracle software could be scheduled must be fully licensed. Read that sentence carefully, because the difference between a three-node Oracle namespace and a forty-node shared platform cluster is a low-single-digit license count versus a seven-figure claim on the same technical workload.

Standalone Docker costs you a host; Kubernetes without taints costs you the cluster.

Then there is Oracle's most aggressive claim, and it deserves to be labeled precisely. Oracle's audit position is that nodes are licensable if the Oracle image merely exists in an accessible shared registry, including nodes where the container has never run. That is not policy text. It appears nowhere in the partitioning PDF, and it rests on the same "could be scheduled" theory that Oracle uses against DRS-enabled VMware clusters. It is an audit posture, and postures are negotiable when you can produce enforcement evidence rather than intent. In practice, the estates that beat this argument are the ones that made scheduling technically impossible, not merely unlikely, and had the artifacts to prove it on the day the audit letter arrived.

• Apply node taints and matching tolerations so Oracle pods can only land on a named, minimal node pool, and export the node specs as evidence.
• Run a dedicated Oracle node pool with the lowest practical core count per node, sized separately from your general platform capacity.
• Host Oracle images in a separate private registry with credentials scoped to the Oracle namespace only, so the registry-presence claim has no factual reach into the wider cluster.
• Enforce placement with admission-control policy (OPA Gatekeeper, Kyverno, or equivalent) that rejects Oracle images outside the approved namespace, and retain the policy definitions plus denial logs.
• Keep dated exports of taints, RBAC, registry access lists, and admission policies; the same discipline that supports an Oracle footprint review before renewal is what converts an Oracle assertion into a discussion about facts.

Serverless Containers: Fargate and the Unlicensable Estate

ECS Fargate, EKS Fargate, and equivalent serverless container runtimes on other clouds share a property that makes Oracle licensing structurally impossible: there is no dedicated, controllable, countable piece of hardware to point at. You do not know the socket count, you do not know the core count, you cannot pin, you cannot cap in a way Oracle recognizes, and you cannot produce the physical inventory an LMS reviewer will ask for. Oracle has published no explicit guidance on serverless container runtimes, and in 25 years of watching this vendor, absence of guidance has never once resolved in the customer's favor during an audit. It resolves as "tell us how many cores are underneath, and if you cannot, we will assume the worst." Since the Oracle partitioning policy already refuses to accept a 2 vCPU container cap as a licensing boundary on hardware you own and can inventory, expecting relief on hardware you cannot see is not a negotiating position, it is a hope. The practical consequence: Oracle Database or Oracle middleware running on Fargate cannot be brought into a defensible compliant state at any price, because you cannot prove the denominator. Write the prohibition into your internal cloud standard rather than leaving it to engineering judgment, and back it with a detective control that scans task definitions, ECR image manifests, and Dockerfiles for Oracle database and middleware binaries. One carve-out matters and gets misapplied constantly: Oracle client drivers, OCI client libraries, and thin JDBC connections are not the licensable component. A Fargate task that connects to a licensed database elsewhere is fine. Target the ban at the engine, not at connectivity, or you will spend six months fighting an internal policy that blocks half your application tier for no compliance benefit.

Public Cloud and OCI: ACE Counting, No Core Factor, and Where the Math Flips

Oracle's Licensing Oracle Software in the Cloud Computing Environment policy governs Authorized Cloud Environments, which in practice means AWS, Azure, and (through separate treatment) OCI. Verify the revision date on the PDF before you cite it in any negotiation; the version previously in effect carried a June 12, 2024 date, and Oracle changes this document without notice exactly as it does the partitioning policy. The single most consequential clause is that the Processor Core Factor Table does not apply in an Authorized Cloud Environment. That is the sentence that flips lift-and-shift arithmetic, because the 0.5 factor that halves your x86 core count on premises simply disappears the moment the workload lands in ACE. The counting rules then diverge: on AWS and Azure, two vCPUs with hyperthreading enabled count as one Oracle Processor license (one vCPU where hyperthreading is off). On OCI, an OCPU is a full physical core with both threads, and Oracle counts it one to one against an on-premises core, with no 0.5 factor applied. Read that carefully, because the naming causes real money to be lost: an AWS vCPU is a thread, an OCI OCPU is a core, and they are not the same unit.

The rule for when a move to OCI reduces the count: it reduces only when you shrink the actual compute you provision. Sizing 32 OCPUs to replace 32 on-premises cores doubles your license requirement from 16 to 32, because the disapplied core factor is a straight 2x penalty on Intel and AMD estates. Sizing 16 OCPUs to replace those same 32 threaded cores holds you flat. The trap sits in bare metal shapes, where teams provision the whole box out of habit and quietly buy 64 processor licenses to run a workload that was consuming 16 on premises. OCI VM shapes let you provision in OCPU increments and are the correct default for BYOL. Where Oracle's cloud discounting genuinely helps, it helps through Universal Credits and the OCI-specific concessions you extract at renewal, not through the counting rules, and the same disapplied-core-factor math applies when you evaluate Oracle Database on Azure under BYOL versus license-included. Before any cloud migration business case leaves your desk, rebuild the license count under ACE rules rather than carrying the on-premises number across, and make the migration team justify every provisioned OCPU above the current utilized core equivalent. In our experience, that single review recovers more money than any discount negotiated afterward, because it changes the quantity rather than the unit price.

Building the Evidence File: What LMS Asks For and What Actually Wins

Architecture without evidence produces exactly the same audit claim as no architecture at all. This is not a theoretical risk: in roughly one in three estates we have reviewed running Oracle Linux KVM or Solaris Zones, the capping was not configured the way the policy requires, which voided the benefit entirely and reverted the count to the full server or, with shared storage and scheduling enabled, the full cluster. The pattern is consistent. Someone capped a zone correctly in 2022, a platform team rebuilt the host in 2024, and nobody re-applied the capped-cpu setting. Oracle's auditors do not have to prove the cap was ever absent; they ask you to prove it was continuously present across the entire lookback period, typically three years or the full term of the current agreement, whichever is longer. If you can produce a screenshot from last Tuesday and nothing else, you have a screenshot, not a defense. The burden of proof sits with you, which is the practical reason the non-contractual argument covered elsewhere in this guide fails on its own. Build the file before the audit letter arrives, because reconstructing 36 months of configuration history under a 45-day response clock is not achievable at any realistic staffing level.

What actually carries weight, ranked by how much resistance it removes from an Oracle partitioning policy dispute:

• Dated configuration exports, generated on a schedule and archived immutably: zonecfg -z zonename export and poolcfg -c info for Solaris, OLVM cluster policy and VM pinning exports for Oracle Linux KVM, HMC LPAR profile exports showing dedicated or capped shared processor pools for Power. Monthly is defensible, quarterly is arguable, ad hoc is not.
• Change-control records that prove continuity, not just current state. Ticket IDs, approver names, and timestamps that tie each configuration change to a dated export. This is the single artifact most estates cannot produce, and it is the one that decides borderline cases.
• Explicit disabled-feature confirmations: no OLVM scheduling policy on any cluster with shared storage, Live Partition Mobility disabled on Power frames hosting Oracle, DRS or equivalent automation off. Prove the absence of the feature, not merely the absence of its use, because Oracle counts capability, not observed behavior.
• Network and storage isolation diagrams, treated as corroboration only. They support a story about intent and boundaries; they are not evidence of a core cap and should never be offered as the primary artifact.

Equally important is what you do not hand over. Do not volunteer output from Oracle's scripts and collection tools beyond what your contractual audit clause actually obliges you to provide, and read that clause before the first call, not after. Do not grant read access to orchestration control planes: OLVM, vCenter, an HMC, or a Kubernetes API server. Access to a control plane lets an auditor enumerate every node on which an Oracle workload could theoretically be scheduled, which converts your architecture into their evidence. Provide scoped, dated exports that answer the question asked, delivered through counsel or your advisor, with a written statement of what each artifact covers and the period it spans.

What to Do First: A 30-Day Exposure Reduction Sequence

Week one is measurement, and it has to be done twice. Inventory every physical host, cluster, node pool, container registry, and cloud shape where Oracle binaries exist or could be scheduled. Then compute two numbers: the intuitive count (the cores your team believes are in scope) and the Oracle-position count (full server for uncapped zones and standalone Docker hosts, full cluster wherever shared storage plus any scheduling or migration capability exists, every node in a Kubernetes cluster where an Oracle image sits in an accessible shared registry, ACE-based counting on public cloud with no Core Factor discount). Express the gap in processor licenses and at list price plus 22 percent annual support. That single figure determines everything that follows, because a 4-license gap is an engineering ticket and a 60-license gap is a board-level negotiation.

Week two is the cheap voids, all of which are configuration changes rather than projects. Disable every OLVM scheduling policy on clusters with shared storage. Disable Live Partition Mobility on Power frames hosting Oracle. Convert uncapped zones to capped, using the maximum value if a range is configured, since Oracle licenses the ceiling. Taint and label Kubernetes nodes so Oracle pods cannot be scheduled outside a named subset, and remove Oracle images from shared registries that unrestricted nodes can pull from. Each of these takes hours and can remove tens of licenses of claimed exposure.

Weeks three and four are strategy and paper. Decide the platform direction against the sized gap: consolidate onto capped, evidenced boundaries, move specific workloads to a licensing model that prices predictably, or accept the count and reduce the footprint before renewal. Capture the evidence file described above from day one of the new configuration, not retroactively. And if the gap exceeds roughly 20 processor licenses, stop relying on policy interpretation and open a commercial conversation with a specific objective: a contractual partitioning clause or a licensed-capacity cap written into an amendment. Policy is revocable without notice. A negotiated contract term is not.

Related reading: Oracle Licensing on KVM and Oracle Linux Virtualization Manager: How Many Cores Count, Oracle Solaris Zones as Hard Partitioning: Capped vs Uncapped and What Oracle Accepts, and Oracle Database in Docker and Kubernetes: Does the Whole Node License?.

Frequently asked questions

Does CPU pinning reduce the Oracle license count?

On its own, no. Oracle recognizes pinning as a cap only inside a technology already named in the partitioning policy, such as Oracle Linux KVM configured under its stated constraints or a capped Solaris Zone. Pinning a VMware, Hyper-V, generic KVM, or Nutanix AHV guest to specific cores does not change the count, and Oracle's audit position remains the full host or full cluster.

Is generic KVM treated the same as Oracle Linux KVM?

No, and this is the single most expensive misunderstanding in the KVM space. Only Oracle Linux KVM and Oracle VM Server appear in the policy, and only under specified configuration constraints. Red Hat RHV, Proxmox, and other KVM distributions are treated as soft partitioning alongside VMware ESXi and Hyper-V, meaning all physical cores in scope must be licensed.

Do Oracle containers on Kubernetes require licensing every node in the cluster?

Oracle's audit position is that every node where the Oracle container could be scheduled must be licensed, and in aggressive engagements Oracle has argued that the image merely being present in an accessible shared registry is enough. That claim exceeds the written policy, but you defeat it with evidence, not argument: dedicated node pools, taints and tolerations, admission control, and a separate private registry restricted to the licensed nodes.

Does moving to OCI reduce my Oracle processor count?

Sometimes, and sometimes it quietly increases it. OCI counts OCPUs against on-premises cores one to one, while AWS and Azure count two hyperthreaded vCPUs as one processor license. Critically, the Processor Core Factor Table does not apply in any Authorized Cloud Environment, so a workload that benefited from the 0.5 Intel core factor on premises can require twice the licenses in cloud for the same core count.

Are uncapped Solaris Zones ever acceptable as hard partitioning?

No. Only capped zones qualify, and an uncapped zone licenses the entire server it runs on. Oracle accepts three capping methods, including a resource pool with a fixed CPU count holding one or more zones, and where a range is configured the maximum value governs the license count. Keep dated zonecfg and pool exports across the full audit lookback period, because a correct configuration today does not prove a correct configuration two years ago.

Can I refuse Oracle's partitioning policy on the grounds that it is not contractual?

You can raise it, and the legal reading is defensible: the policy carries an explicit disclaimer that it may not be incorporated into any contract, and the license agreement's counting language does not incorporate it. In practice the argument alone rarely lowers a claim, because Oracle holds the audit position and the burden of rebuttal falls on you. Use it as settlement leverage alongside architectural isolation and documented evidence, not as your primary defense.