Two pages, eleven technologies, and seven figure consequences
Oracle's partitioning policy names nine technologies as hard partitioning and points at two more held in separate documents, eleven in total, and VMware is on neither list: the file is two pages, it has never been part of your Oracle Master Agreement, and it routinely decides seven and eight figure numbers. Everything else is soft partitioning, licensed as if Oracle could run on the entire physical host, and on a modern cluster that host is one of many.
Prepared by Redress Compliance · August 8, 2026 · Oracle advisory. Based on 30 to 40 Oracle virtualization engagements run 2024 to 2025.
Executive summary
The policy disclaims itself, and the disclaimer wins the wrong fight.
Oracle's own file closes with the sentence that it may not be incorporated into any contract and does not constitute a contract or a commitment, printed in Oracle's own PDF and redated at each reissue: print it, highlight it, and file it.
Then understand what it does not do, because your ordering document already defines Processor as the processors where programs are installed and running.
And the policy is only Oracle's reading of what installed covers when a virtual machine can move: the contractual status and Oracle's reading of the signed term are two different fights, and buyers routinely pick the wrong one first.
The eleven, exactly: nine named, two admitted elsewhere, five only when capped.
The policy text names Physical Domains, capped Solaris Zones, IBM LPAR, capped Micro Partitions, capped vPar, nPar, capped Integrity VMs, capped Secure Resource Partitions, and Fujitsu PPAR, with five qualifying only when capped, an uncapped Solaris Zone counting as soft despite its name being on the list.
Separate Oracle documents admit Oracle VM Server for x86 with vCPUs pinned in vm.cfg and Oracle Linux KVM with cores set by the control utility.
Hyper V, Nutanix AHV, Proxmox, and Citrix are named nowhere, and absence is not approval, they count as soft.
The vSphere version ladder sets the boundary, and the boundary is the money.
Oracle's claimed scope runs the cluster up to ESXi 5.0, the whole vCenter from 5.1, and every linked vCenter from 6.0, and the worked estate prices the rungs: on a fourteen host estate, 48 Processors against 336, which is $2,280,000 against $15,960,000 at list, and every option the databases run.
RAC, Partitioning, Diagnostics, multiplies by the same count.
In our engagements the cores Oracle billed ran a median 3.5 times the cores actually running a database, and not one claim turned on the policy wording. Every one turned on a diagram.
The defense is machine generated records, and the trap is one signature.
In every case where the count came down, it came down because of a machine generated record, never an argument about intent: hard partitioning was available on the hardware in most estates and configured in almost none, the pinning being an afternoon of work nobody had been asked to do.
The trap runs the other way, boilerplate incorporating Oracle's then current policies into an amendment, ordering document, or ULA certification letter, because one signature converts the self disclaiming policy into a term you are bound by.
And the buyers who spent their first month debating bindingness conceded the core count and negotiated discount instead.
How Oracle sorts the technologies
| Treatment | What the policy names | What Oracle counts |
|---|---|---|
| Hard, in the policy text | Physical Domains, capped Solaris Zones, IBM LPAR, capped Micro Partitions, capped vPar and nPar, capped Integrity VMs, capped SRPs, Fujitsu PPAR | Only the cores inside the partition |
| Hard, by separate document | Oracle VM with cpus pinned in vm.cfg; Oracle Linux KVM with cores set by the control utility | Only the pinned cores |
| Soft, in the policy text | Resource containers, workload managers, affinity tools, Oracle VM unpinned, and VMware | Every core the workload can reach |
| Named nowhere | Hyper V, Nutanix AHV, Red Hat Virtualization, Proxmox, Citrix | Soft; absence is not approval |
| Authorized cloud | AWS EC2 and RDS, Microsoft Azure | vCPUs converted; the core factor table does not apply |
The capping condition is the detail that reclassifies estates.
Five of the nine named technologies qualify only when capped, so the product name on the approved list proves nothing about the deployment in front of you: an uncapped Solaris Zone or Micro Partition is soft partitioning wearing a hard partitioned name, and the audit reads the configuration.
Not the brochure.
Oracle VM sits on Oracle's own soft list until the vCPUs are pinned, the same afternoon of work that separates the two columns everywhere.
The vSphere ladder, and the worked count
- Up to ESXi 5.0: the claimed boundary is the cluster, the smallest rung and the oldest estates.
- From vSphere 5.1: the whole vCenter, because shared storage vMotion widened where a VM could move.
- From vSphere 6.0: every linked vCenter, the rung that turns forty hosts in an inventory export into forty hosts in a letter.
- The worked estate: fourteen hosts, 48 Processors pinned against 336 vCenter wide, $2,280,000 against $15,960,000 at list, before the options multiply.
- The options multiplier: every option and pack licenses at the same count, so the boundary decision reprices the entire stack at once.
The database licensing optimization playbook
The partitioning positions, the isolation architectures, and the audit artifacts that hold the count worked end to end.
Get the white paper →The defense, diagrams beaten by records
The engagement pattern is unambiguous: Oracle opened with a vCenter inventory export rather than a host list, the claim turned on the diagram of where a VM could move rather than any policy sentence, and the counts that came down came down on machine generated records, the pinning configurations.
The cluster definitions, and the DRS rules that proved where Oracle could and could not run.
Hard partitioning was available and unconfigured in most estates, which makes the afternoon of pinning work the cheapest license position in the file, and the five artifacts, the policy PDF with its disclaimer highlighted, the isolation architecture, the pinning configs, the change records.
And the dated inventory, are the audit binder.
The core factor arithmetic underneath runs in the core factor analysis, the cloud counting rules in the Oracle on Azure guide, the isolation platform comparison in the Nutanix analysis.
And the estate orientation in the Oracle licensing guide, where sizing to policy documents bought unowed license in six of ten estates.
- Percentile standing for your exact deal size and industry, from real closed transactions
- Scenario simulation before the call: test alternative terms and see the financial impact of each
- A negotiation playbook, talking points, and a two page executive brief on day one
What we saw across virtualization engagements, 2024 to 2025
Fredrik Filipsson ran roughly 30 to 40 Oracle virtualization engagements across 2024 and 2025, and in the soft partitioned estates the cores Oracle billed came out at a median 3.5 times the cores actually running a database:
Estates where hard partitioning was available on the hardware and pinning was never asked for.
Where the count came down, a machine generated record did it, never an argument about intent.
The month spent debating whether the policy binds is the month that loses the engagement, because the buyers who fought the bindingness fight conceded the core count and ended up negotiating discount on a number they should have contested: the two fights are separate, the policy's contractual status.
Already answered by Oracle's own disclaimer, and Oracle's reading of the installed and running term you did sign, answered only by records proving where the software could run.
The policy is two pages that decide seven and eight figures, the pinning is an afternoon, and the binder of machine generated artifacts is what stands between the 48 Processor position and the 336.
Your first five moves
- Read the two pages and file the disclaimer highlighted, before reading anyone's summary, including this one.
- Check the capping condition on every named technology, since five of nine qualify only when capped.
- Configure the pinning where the hardware supports it, the afternoon of work that reprices the estate.
- Build the binder of machine generated records, because diagrams beat arguments and records beat diagrams.
- Never sign then current policies boilerplate, the one signature that makes the disclaimer binding. The Oracle practice runs the position with you.
Frequently asked questions
What does the Oracle partitioning policy say?
It names the technologies Oracle accepts as hard partitioning, binding licenses to a subset of cores, and treats everything else as soft partitioning, licensed as if Oracle could run on the entire host: nine technologies in the policy text, five of them only when capped.
Plus Oracle VM with pinned vCPUs and Oracle Linux KVM admitted in separate documents, eleven in total.
VMware is on the soft list, and Hyper V, Nutanix, and Proxmox are named nowhere, which also means soft.
Is the Oracle partitioning policy legally binding?
No, by Oracle's own words: the file closes stating it is for educational purposes only, may not be incorporated into any contract, and does not constitute a commitment.
But the disclaimer only strips the policy's contractual status; it leaves Oracle's reading of the Processor definition you did sign intact, and those are two different fights.
The trap is boilerplate incorporating then current policies into any amendment or certification letter, where one signature makes it binding.
How does Oracle count VMware environments?
As soft partitioning, with the claimed boundary set by the vSphere version: the cluster up to ESXi 5.0, the whole vCenter from 5.1, and every linked vCenter from 6.0, which is how forty hosts in an inventory export become forty hosts in an audit letter.
On the worked fourteen host estate the difference is 48 Processors against 336, $2,280,000 against $15,960,000 at list, with every option multiplying by the same count.
What qualifies as hard partitioning for Oracle?
The configured state, not the product name: Physical Domains, IBM LPAR, and Fujitsu PPAR qualify as deployed, while Solaris Zones, Micro Partitions, vPar, Integrity VMs, and Secure Resource Partitions qualify only when capped.
And Oracle VM and Oracle Linux KVM only with vCPUs pinned through the documented mechanisms.
An uncapped instance of a listed technology is soft partitioning wearing an approved name.
How do you defend an Oracle virtualization position?
With machine generated records, never arguments: in every engagement where the count came down, pinning configurations, cluster definitions, DRS rules, and dated inventories did it, proving where Oracle could and could not run.
The audit binder holds five artifacts, the policy PDF with its disclaimer highlighted, the isolation architecture, the pinning configs, the change records, and the dated inventory, built before the first call rather than during the negotiation.
Should you configure hard partitioning for Oracle workloads?
In most estates, yes, and almost nobody had: hard partitioning was available on the hardware in most of our engagements and configured in almost none, with the pinning being an afternoon of work nobody had been asked to do.
Against a median billed to running ratio of 3.5 times in soft estates, that afternoon is the cheapest license position available, and it converts the audit conversation from a boundary dispute into a record review.
