Oracle licensing in virtualized environments is where the largest audit findings come from — and the rule that decides most of them is partitioning. The part that surprises people the most is this: an architecture that is technically sound, even physically isolated, can still produce a six- or seven-figure finding if it was never approved by Oracle in writing.
In an Oracle audit, correct and approved are not the same thing. Understanding that difference is the single most valuable thing you can do before Oracle ever knocks.
The default: Oracle counts every physical core
Oracle Database and its options are licensed per physical processor — cores multiplied by a core factor. On bare metal this is simple: you license the cores in the server. In a virtualized environment the question becomes which cores you must count, and the answer is governed by Oracle’s partitioning policy — not by what your hypervisor happens to let you cap.
The default assumption Oracle starts from is full capacity: every physical core where the software is installed and/or running. Whether you can shrink that number depends entirely on which partitioning method you used.
Hard partitioning vs soft partitioning
Hard partitioning is a short list of Oracle-approved technologies that physically bind Oracle to specific, capped cores. Used strictly according to Oracle’s rules, these let you license only the partitioned cores (sub-capacity). The approved methods include technologies such as Physical Domains, capped Solaris Zones, properly capped IBM LPAR, Fujitsu PPAR, and Oracle’s own virtualization (Oracle VM Server / Oracle Linux KVM) when CPUs are pinned per policy. Every approved method must have a capped maximum number of cores — an uncapped “partition” is not a partition in Oracle’s eyes.
Soft partitioning is everything else. Oracle treats any setting in a non-approved hypervisor — vCPU limits, CPU affinity, host or DRS rules — as if it does not exist for licensing purposes. With soft partitioning you must license every physical core where Oracle could run, not just where it is running.
The biggest landmine here is VMware. Oracle classifies all VMware versions, including current vSphere, as soft partitioning regardless of how you pin CPUs. And because of vMotion and DRS, Oracle’s audit position is that every host a VM could migrate to counts — which can extend the licensing boundary to an entire cluster, or further. That position is contested, but it is the starting point you will face across the table.
Physical isolation is not the test — approval is
One of the most common and most expensive misconceptions sounds reasonable: “Our Oracle hardware is physically separate, so we’re fine.”
Oracle’s policy does not turn on physical separation. It turns on whether you used an approved method, configured to its rules. You can isolate a workload perfectly — separate hosts, separate storage, separate network — and still be counted at full capacity if the technology isn’t on Oracle’s approved list or isn’t capped the way Oracle requires. Engineering cleanliness is not the same as licensing compliance.
The policy is not your contract — which is exactly why approval matters
Here is the subtlety that drives most disputes. Oracle’s Partitioning Policy is a document published “for educational purposes,” and it states plainly that it may not be incorporated into any contract and does not constitute one. It is not a contractual term unless your own agreement references it. Yet Oracle enforces it aggressively in audits.
That gap cuts both ways. It is why some soft-partitioning claims can be challenged on contractual grounds. But it is also why you cannot rely on the policy, a friendly sales conversation, or common sense to protect you. The only thing that reliably limits your count is what is written into your agreement or approved by Oracle in writing. Verbal comfort from anyone — however senior — is not a defense.
”Correct” is not “approved” — the alpha and omega
This is the most important lesson, and it is worth stating bluntly: an architecture can be technically clean, even genuinely compliant in spirit, and still fail an audit — because it was never formally approved.
If you want a partitioning approach to limit your licensing, you have to:
- get it approved by Oracle, in writing, and ideally referenced into your agreement;
- have that approval in place before you deploy, not after; and
- keep the evidence — configuration files, console screenshots, command output showing the capped cores.
Audits happen years after the architecture is built. You will not remember the details, and “trust us, it was configured correctly” carries no weight. An exception that is agreed and documented up front is worth more than a perfect design no one signed off on.
An audit is a snapshot, not a story
An Oracle audit confirms your licensing position as of the date of the final report. It is a point-in-time snapshot. It does not credit what your environment looked like last year, what you fixed the week before, or what you plan to do next quarter. It does not reward good intentions or in-flight remediation.
Two practical consequences follow:
- Fixing an architecture after the measurement date does not erase a finding for that date. The snapshot already captured the non-compliant state.
- An environment that is compliant in practice but lacks documented, dated approval at the snapshot will still be flagged. The approval has to exist before the snapshot — retroactively making the architecture correct does not rewrite history.
This is why “we were about to request an exception” or “the design was always sound” rarely helps once the report is issued. The audit measures the documented, approved state on one specific day.
How to protect yourself
- Inventory exactly where Oracle is installed and where it can run — including every virtualized host and migration boundary.
- Confirm which of your technologies Oracle recognizes as hard partitioning, and verify each “partition” is actually capped per Oracle’s rules.
- For any sub-capacity approach, secure written Oracle approval before deployment, and reference it in your agreement where possible.
- Keep dated evidence of configuration and approvals in one place, indefinitely.
- Treat physical isolation and hypervisor settings as good engineering — not as a licensing defense on their own.
- Review your position before Oracle reviews it for you.
Common questions
Is VMware ever hard partitioning to Oracle? No. All versions, including current vSphere, are soft partitioning to Oracle, regardless of CPU affinity or DRS rules.
Does physically isolating my Oracle hardware limit my licenses? Not by itself. Only an approved, correctly capped method — or a written exception — limits the count.
Can I fix an issue before the audit closes and avoid a finding? Only if the compliant, approved state exists as of the final report date. Retroactive fixes don’t rewrite the snapshot.
The pattern behind almost every large partitioning finding is the same: the architecture was rarely the real problem — the missing approval was. If you run Oracle on virtualized infrastructure, the cheapest insurance you can buy is getting your architecture approved and documented before anyone asks to see it.
Nevdom helps companies review their Oracle estate and lock down an approved, defensible licensing position before an audit — not during one. Get in touch for an independent review.
Related reading: How to prepare for an Oracle LMS audit in 2026 · Oracle Licensing & OCI: the questions we hear most.
This article reflects Oracle’s published partitioning policy and common audit practice; it is general information, not legal advice.
