Oracle's partitioning policy never names Nutanix AHV, and that silence is precisely why every core in the cluster falls inside the license boundary. This page shows the exact mechanics that widen scope, which AHV configurations actually hold up, and what to do before an auditor reads your Prism Central policy export.
Oracle's partitioning policy never names Nutanix AHV, and that silence is precisely why every core in the cluster falls inside the license boundary. This page shows the exact mechanics that widen scope, which AHV configurations actually hold up, and what to do before an auditor reads your Prism Central policy export.
Start with what Oracle actually published, because the auditor will not. The Server Partitioning document (partitioning-070609.pdf) carries a policy date of February 14, 2022 and remains the current version. Read it end to end and you will not find the words "Nutanix" or "AHV" anywhere in it. That absence is the entire problem. The approved hard partitioning list is a closed enumeration, not a set of examples: Oracle Linux KVM with documented CPU pinning per the Oracle Linux documentation, Solaris capped zones (capped only, uncapped does not qualify), IBM LPAR configured as dedicated or capped shared processor pools, legacy Oracle VM Server with pinned vCPUs, and capped vCPU shapes in Oracle-authorized clouds. Anything outside that list is soft partitioning by default, and soft partitioning permits no reduction in license count for any given server or, in Oracle's own phrasing, a cluster of servers. So the accurate framing for your negotiation file is not that Oracle banned AHV. Oracle never considered it. AHV is unenumerated, and unenumerated defaults to full-cluster counting.
AHV is not blacklisted by Oracle, it is unenumerated, and unenumerated defaults to every core the VM can reach.
That distinction matters because of the second thing in the document that Oracle's auditors never volunteer. The same PDF states it is provided "for educational purposes only" and "may not be incorporated into any contract." Your Oracle Master Agreement and ordering documents do not reference it. In 25 years of negotiating this vendor, that single line has been worth more concessions than any technical argument about hypervisor architecture. When LMS or a partner audit team asserts a 384-core position on a six-node AHV cluster, they are asserting policy, not a contractual term you signed. Policy is negotiable in a way license grants are not. Treat the partitioning document as an opening position, not a finding, and require the auditor to point to the contract language that obligates full-cluster counting. They cannot, because it does not exist. Read the full analysis of how Oracle's partitioning policy decides your license count before you concede a number.
Here is the math an auditor runs, and it takes about four minutes. Take a six-node AHV cluster of dual-socket hosts at 32 cores per socket. That is 64 physical cores per node, 384 physical cores in the cluster. Apply the x86 core factor of 0.5 and you get 192 Processor licenses. The vCPU allocation of the Oracle VM is irrelevant to that calculation. Whether the database VM is configured with 8 vCPUs or 80, the number does not change, because soft partitioning counts every core the workload is capable of running on, not the cores it is currently consuming. The customer's internal view, built from the Prism VM inventory, usually looks like 8 vCPUs, so 4 cores, so 2 Processor licenses. The gap between those two positions is 190 Processor licenses, and that gap is the whole audit.
| Line item | Customer VM view (8 vCPU) | Oracle cluster view (6 nodes) |
|---|---|---|
| Cores in scope | 4 | 384 |
| Core factor (x86) | 0.5 | 0.5 |
| Processor licenses | 2 | 192 |
| DB Enterprise Edition at $47,500 | $95,000 | $9,120,000 |
| Real Application Clusters at $23,000 | $46,000 | $4,416,000 |
| Partitioning at $11,500 | $23,000 | $2,208,000 |
| Diagnostics Pack at $7,500 | $15,000 | $1,440,000 |
| Tuning Pack at $5,000 | $10,000 | $960,000 |
| Total license at list | $189,000 | $18,144,000 |
| Support at 22 percent per year | $41,580 | $3,991,680 |
Two points on that table. First, list prices are Oracle's published Technology Price List figures and no real customer pays them, but the auditor's opening claim is always calculated at list, so that is the number you are negotiating down from. Second, the recurring line is the one that matters. A one-time $18.1M claim gets settled. A $3.99M annual support stream, indexed and repriced at every renewal, is a permanent tax on the estate. Always model the 22 percent line, not just the license line, when you compute what a settlement is actually worth.
Then there is the compute-only node question, and buyers consistently get this wrong. Compute-only nodes in an AHV cluster run VMs. They contribute no storage, but they are valid placement targets for the AHV scheduler, so every core in them counts. Nutanix's own patented migration behavior moves workloads between compute-only and hyperconverged nodes as a design feature, which is precisely the evidence an auditor will cite to prove reachability. If you added two compute-only nodes to the six-node cluster above to boost CPU density, you did not reduce your Oracle exposure, you increased it by 64 Processor licenses. The same reachability logic that drives Oracle's cluster-wide position on VMware applies here without modification.
The most common defense I hear in AHV audit prep is that the Oracle VM "lives on node 3 and has never moved." That statement is almost always false, and more importantly, it is irrelevant. AHV is not a static hypervisor with occasional manual vMotions. Per the Nutanix Bible (Book of AHV Architecture, June 12, 2026), live migrations occur regularly across cluster nodes and are triggered by four distinct events: maintenance operations, ADS workload balancing, node expansion, and administrator action. Three of those four require no human decision at the moment they fire. Rolling AOS or hypervisor upgrades evacuate every host in sequence by design, which means a standard quarterly patch cycle deliberately places your Oracle workload on every node in the cluster. Node expansion rebalances automatically. The Acropolis Dynamic Scheduler is the clearest evidence of all: Nutanix Tech Center (October 13, 2025) describes ADS as continuously monitoring resources "across all of the hosts in the cluster." The scheduler's operating boundary is the cluster, so the license boundary follows the scheduler.
Then there is the precedent that forecloses the fallback argument entirely. Oracle's own Server Partitioning document (February 14, 2022) rules that IBM Power VM Live Partition Mobility is not approved hard partitioning, and that all cores on both the source server and the destination server must be licensed. Read what that means. IBM LPAR is on Oracle's approved list. Oracle still says that adding live mobility to an approved platform re-expands scope to both endpoints. If mobility widens the count on a hardware-enforced partition Oracle explicitly blesses, no auditor will accept that a software-defined AHV cluster escapes on the grounds that the VM "never actually ran there." Oracle's own hard partitioning guidance for Oracle Linux KVM confirms the trade in the other direction: sub-capacity requires giving up live migration and scheduling policies. You pick one.
Oracle has already ruled that live mobility widens the count on IBM LPAR, a platform it approves; AHV, which it never names, does not get a better outcome.
Grade every containment mechanism against a single test taken from Oracle's own definition: hard partitioning must definitively limit the number of accessible processors at the hardware or firmware level, and must not be overridable by software configuration. That test is fatal to AHV before you evaluate any individual feature, because every AHV containment control is software configuration by construction. But you still need the per-feature grading, because it determines how much technical credibility you carry into the negotiation and how badly a bad configuration hurts you. The asymmetry that decides most cases is this: VM-Host affinity is hard, VM-VM anti-affinity is advisory. Per the AHV 11.0 Admin Guide, a VM with a VM-Host affinity policy can only be migrated to the hosts named in that policy, and where a single host is named, the VM cannot migrate or start elsewhere even during an HA event. Compare the AHV 6.10 Admin Guide on anti-affinity: the system blocks no VM operation even when the policy is violated, and manual migration applies the policy on a "commercially reasonable effort only" basis. Expect an auditor to read that phrase out loud.
| Mechanism | What it actually enforces | Oracle grade | Audit value |
|---|---|---|---|
| VM-Host affinity, single host named | Blocks migration and blocks start on other hosts, including during HA | Soft partitioning. Software config, overridable | Best available evidence, still does not cut the count |
| VM-Host affinity, multiple hosts named | Restricts targets to the named subset only | Soft partitioning | Argues a smaller cluster subset, not a smaller license |
| VM-VM anti-affinity | Blocks nothing; "commercially reasonable effort only" | Soft partitioning, and self-defeating as evidence | Negative. Do not present it |
| ADS rejecting policy-violating migrations | Real runtime enforcement of your rules | Irrelevant to the approved list | Useful for showing operational discipline |
| Prism Element per-VM rules | Same effect, no central artifact | Soft partitioning | Drift risk, hard to evidence at scale |
| Prism Central category-based policies | Binds VM sets to host sets centrally | Soft partitioning | The exportable artifact to maintain |
Two operational traps sit underneath this. First, the configuration-level split: Prism Element defines affinity per VM at create or update time, while Prism Central binds categories of VMs to categories of hosts. Per-VM rules drift silently as VMs are rebuilt or cloned; category policies are the only thing you can export cleanly for an auditor. Second, the delay problem. Nutanix Community guidance confirms that policies applied to running VMs do not take effect immediately, because ADS migrates VMs into compliance over time. Any placement snapshot taken inside that window shows non-compliance, and Oracle's tooling captures point-in-time state. Configure affinity for operational reasons and for your position on Oracle's partitioning policy, but budget as if every core counts.
Assume you have done everything right on the production cluster: VM-Host affinity binding every Oracle VM to two named hosts, category-based policies in Prism Central, exports filed. Then you run your annual DR test. On failover and failback, the system clears CLI-defined and Prism Central-defined anti-affinity policies, because protection-domain based protection is only locally significant, and guest VMs can start using any host at the recovery site. Your carefully constructed boundary does not travel with the workload. Worse, the recovery cluster is usually the one nobody licensed, because it is "only for DR" and never ran production. Oracle's ten-day rule covers unlicensed failover in a limited way, but a scheduled annual test with VMs landing on arbitrary hosts is exactly the evidence an auditor wants: dated, logged in Prism, and produced by your own change process. In roughly one audit in three where a customer had a documented DR runbook, the recovery site produced a larger claim than production. There are three controls, and you need all three. First, license the DR cluster to the same core count as production, or accept that it is in scope. Second, if that is unaffordable, size the recovery cluster deliberately small, three or four VM-capable hosts, and record that constraint as a design decision. Third, capture placement evidence (VM-to-host mapping, affinity policy state) immediately before and immediately after every failover exercise, so the gap is minutes rather than a year of unexplained drift. The same discipline applies on Hyper-V clusters, where DR replication widens scope identically.
There is exactly one AHV configuration that reduces the count, and it works because it is not a configuration at all. Storage-only nodes serve I/O to the distributed storage fabric and are architecturally incapable of running guest VMs. No hypervisor scheduling path exists to place an Oracle workload on them, so they require no Oracle licenses. That is the same logic class Oracle accepts for approved hard partitioning technologies: the limit is enforced below the software layer and cannot be reversed by an administrator changing a policy. Contrast this with compute-only nodes, which are the exact opposite. They run VMs, they participate in ADS balancing, and they are unambiguously in scope. Naming conventions confuse people here, so be precise in your documentation. The practical design move follows directly: build the Oracle cluster from the smallest possible set of VM-capable hosts, size those hosts for the actual database workload rather than for headroom, and push raw capacity into storage-only nodes where it costs nothing in Oracle terms. A four-node compute footprint with six storage-only nodes licenses four nodes, not ten. Then protect the distinction. Record node roles in a signed architecture document, keep the Prism node-role export alongside it, and treat any conversion of a storage-only node to a hyperconverged node as a licensing change requiring approval, not a capacity task. In market experience, the single most common way this saving evaporates is an infrastructure team converting a storage node during a growth project without telling anyone, then an auditor finding a hypervisor version stamp on it eighteen months later.
Rank your leverage honestly, strongest first, because Oracle's audit team will test each argument in the same order. One: the partitioning document states on its face that it is "for educational purposes only" and "may not be incorporated into any contract." It is not an ordering document term, and unless your OMA or an amendment pulls it in by reference, it is policy, not obligation. Two: Oracle has never named Nutanix AHV as prohibited. The policy is silent, and silence defaults you into the same galaxy-licensing posture as VMware rather than into an express violation. Three: Nutanix Acropolis Dynamic Scheduling actually enforces VM-Host affinity, rejecting remediation plans that would violate a policy, and VMs bound to a single host cannot start or migrate elsewhere even during HA. That is real technical enforcement, and it is worth putting in front of an auditor as a fact. Four: storage-only nodes cannot run VMs at all, so they sit outside the license boundary on architecture, not on configuration. Now the honest limit. No credible practitioner, House of Brick included, tells clients to stake an audit outcome on AHV pinning, and the vendor-neutral position remains that you license every core on every physical host capable of running the VM. Treat the four points above as negotiation leverage on price and scope, not as a technical defense you would take to litigation. Realistic landing zones are a dedicated minimum-node Oracle cluster sized to entitlement, a term ULA that makes core counting irrelevant for three to five years, or a migration to Oracle Linux KVM with documented hard partitioning, accepting the mobility restrictions Oracle's own data sheet spells out.
Treat AHV affinity as negotiation leverage on price, not as a technical defense you would take to litigation.
Work in a fixed order over the next 30 to 90 days, and do the evidence collection before anyone at Oracle asks for it. Start with export, not remediation, because remediation without a baseline destroys the timestamped record you may need later. Then move to the structural changes, which is where the actual savings sit.
Oracle's Server Partitioning document does not name Nutanix AHV at all. Because the approved hard partitioning list is closed and AHV is not on it, AHV defaults to soft partitioning in Oracle's reading. The practical effect is identical to being named: every core in every host the VM can run on must be licensed.
Not in Oracle's stated position. VM-Host affinity genuinely restricts migration targets, and ADS will reject remediation plans that violate it, but the constraint is software configuration and can be changed by an administrator, so it fails Oracle's hardware-or-firmware enforcement test. It is worth configuring and documenting as negotiation evidence, but do not build a license position on it.
No. Storage-only nodes serve I/O and cannot run virtual machines at all, so there is no host on which the Oracle binary could execute. This is architectural incapability rather than a policy setting, which is the same category of argument Oracle accepts for approved technologies. Compute-only nodes are different: they run VMs and are fully in scope.
384 physical cores at the 0.5 x86 core factor equals 192 Processor licenses per Oracle product deployed, irrespective of the VM's vCPU allocation. At Database Enterprise Edition list pricing plus 22 percent annual support, that is a multi-million dollar exposure before options such as RAC or Partitioning are added.
Yes, and it is one of the most commonly missed risks. Failover and failback clear CLI-defined and Prism Central-defined anti-affinity policies because that protection is only locally significant, after which VMs can start on any host at the recovery site. A single annual DR test can therefore put the entire recovery cluster in scope.
Sometimes, but the trade is explicit. Oracle Linux KVM hard partitioning is approved, yet Oracle's own data sheet confirms it restricts live migration and scheduling policies, so you buy sub-capacity by giving up mobility. Compare that operational cost against a dedicated minimum-node AHV cluster or a term ULA before assuming migration is the cheaper answer.
Oracle Exadata can lock you into full core licensing across X9M, X10M, and Cloud at Customer. The buyer side strategy to size the platform and cut the bill.
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.
