Oracle treats VMware as soft partitioning, so it counts every core a database could ever reach rather than the cores it runs on today. What the policy says, what it is worth in a negotiation, and the cluster design that removes the argument.
Oracle counts every core an Oracle database could reach in your VMware estate, not the cores it runs on. That one rule produces most of the cost surprise on virtualized Oracle, and it is the reason a two core database can carry a claim against a hundred cores.
VMware is soft partitioning in Oracle's view. The database does not have to run on a host for Oracle to count that host. The ability to migrate to it is enough.
This guide walks the counting rule, why the boundary moved as vSphere matured, which containment moves survive an audit, what the partitioning policy is and is not, and how the arithmetic changes in cloud. Read it with the Oracle Database licensing guide.
By counting every physical core where an Oracle database could run, not where it runs today. Because VMware allows live migration, Oracle treats the whole reachable estate as licensable.
Oracle sets out the technologies it accepts in its server partitioning policy. Understanding exactly what that document says, and what status it has, is the foundation of any defensible position.
Hard partitioning lets you license a subset of a server. Soft partitioning does not. Oracle's policy names both categories explicitly, and the lists are short.
Note that Oracle's own VM product sits in the soft list unless it is configured for hard partitioning. The category is about capping, not about the vendor logo.
Because the licensable boundary is defined by where a workload can go, and vMotion is exactly a statement about where a workload can go. Every host in scope for live migration is a host in scope for licensing.
That makes three infrastructure decisions into licensing decisions, whether or not anyone framed them that way at the time.
Apply the multipliers from the Processor Core Factor Table to that full pool, not to the hosts your database happens to sit on this morning.
Ask them in this order, and answer them with configuration exports rather than opinions.
Any host where the first answer is yes belongs in your count until you change the architecture. That is the uncomfortable part, and it is also the part you can fix.
Almost certainly not, and Oracle's document says as much on its own face. The partitioning policy states that it is for educational purposes only, that it provides guidelines regarding Oracle's policies, and that it may not be incorporated into any contract.
The version most buyers are shown carries policy guidance dated 14 February 2022. It is a statement of how Oracle intends to interpret licensing, not a term you signed.
Leverage, not immunity. A finding built on a document Oracle itself describes as non contractual is a weaker finding than one built on your ordering document, and it should be priced that way in a settlement.
Where each rule actually comes from
| Rule | Source | Status |
|---|---|---|
| You must license all processors on which the program is installed and running | Ordering document and master agreement | Contractual |
| Core factor multipliers by processor model | Processor Core Factor Table, referenced in the agreement | Contractual by reference |
| VMware is soft partitioning and cannot limit the count | Partitioning policy document | Policy, stated as not contractual |
| The reachable cluster defines the licensable pool | Oracle interpretation of the above | Position, not policy text |
| vCPU conversion in Authorized Cloud Environments | Cloud licensing policy document | Policy, stated as not contractual |
The practical reading is straightforward. Argue the status of the policy in a negotiation, and remove the exposure with architecture. Doing only the first leaves you renting the argument every three years.
Every release that extended live migration extended the boundary Oracle argues for. Oracle audit teams cite the version precisely because it supports the widest defensible reach.
The version is not the problem, and downgrading is not the answer. Shared scope is the problem, and a modern estate with one flat vCenter simply gives Oracle the largest possible claim.
The fix is separation. If the Oracle estate cannot technically reach the rest of the estate, the vSphere version stops mattering.
By cutting the reachable pool down to a boundary that exists in hardware and configuration, not in policy documents. Only physical and management separation survives contact with an audit.
Treat the Oracle cluster as a licensed appliance with a fixed core budget. That reframing is what turns a licensing problem into an infrastructure standard your platform team can actually own.
Three design rules make it work in practice. Size the cluster to entitlement rather than to peak demand. Keep failover capacity inside the licensed boundary. Make any host addition a change that requires a license check before it is racked.
Done properly, the containment holds without anybody remembering a rule. That is the test. A boundary that depends on discipline is a boundary that will fail during an incident at two in the morning.
Containment approaches and Oracle's stance
| Approach | Oracle stance | What Oracle counts |
|---|---|---|
| Shared cluster, host affinity rules only | Rejected | Every core in the management estate |
| Dedicated Oracle cluster inside a shared vCenter | Contested | Argued up to the full vCenter |
| Dedicated cluster, separate vCenter and SSO domain | Strongest soft boundary | Cores in the isolated estate |
| Physical isolation, capped sockets | Accepted | The capped sockets only |
| Approved hard partitioning technology | Accepted by policy | The capped partition only |
Containment you cannot evidence is containment you do not have. Build the pack while the estate is calm, and date everything.
Consider it, because cloud replaces an argument about reach with a published conversion. Oracle's cloud licensing policy names Amazon EC2 and RDS, Microsoft Azure and Google Cloud Platform as Authorized Cloud Environments.
Predictable is not the same as cheap. The core factor table does not apply in those environments, so a processor with a favorable factor loses that advantage on migration.
Run the numbers both ways before committing. Our Oracle licensing in cloud environments guide sets out the full rules, including the Named User Plus minimums that apply there.
The standard advice from many infrastructure teams is that DRS host affinity rules will pin Oracle to a few hosts and cap the license count. We disagree. In roughly 30 of the 50 virtualized estates we reviewed across 2024 and 2025, Oracle rejected affinity rules in the audit because the VM could still be moved by an administrator, so the reachable pool stood. The buyer side move is to build a physically separate Oracle cluster on capped sockets, in its own vCenter, and to treat configuration rules as convenience, not as a licensing boundary that Oracle will honor.
Source: Redress Compliance advisory engagement file, 2024 to 2025.
The Oracle number on a VMware estate is the size of the cluster Oracle can reach, not the size of the workload you run. Shrink the reach and you shrink the bill.
Under a narrow published allowance that most virtualized designs quietly exceed. Oracle's data recovery licensing policy permits running a licensed program on an unlicensed spare computer in a failover environment for up to a total of ten separate 24 hour periods in a calendar year.
The allowance is conditional. It applies where machines are arranged in a cluster sharing one logical disk array in a single data center. Once failover has exceeded those ten periods, the policy states the failover node must be licensed.
Two practical consequences follow. Keep failover capacity inside the licensed Oracle boundary rather than borrowing hosts from the general cluster. And log failover events, because the ten day allowance is only useful if you can evidence that you stayed inside it.
Less than one year of the exposure it removes, in every case we have modeled. That is the comparison to put in front of a CFO, and it is the reason isolation projects get funded when they are framed as license avoidance rather than as infrastructure work.
Price three scenarios side by side and let the numbers argue. Status quo with the reachable pool licensed in full, containment with a dedicated and isolated cluster, and migration to an authorized cloud with the vCPU conversion applied.
Include five years of support at 22 percent with annual escalation in every scenario. Support is where the difference compounds, and a comparison that shows only license cost will understate the case for containment.
Sequence the measurement before the isolation, and the isolation before the renewal or audit response.
White Paper · Advisory
Oracle Database Options & Management Packs Licensing
The separately licensed options and packs that ship enabled by default, trigger on one click, and drive most Oracle audit findings. How feature usage is detected, prevented and defended. Read it free.
Oracle counts every host a database virtual machine can reach through live migration, not only the hosts it runs on. VMware is treated as soft partitioning, so the reachable pool is the licensable boundary until you separate the estate physically and in management scope.
No. Oracle's partitioning policy names VMware in its soft partitioning list. The approved hard partitioning methods are physical domains, capped Solaris Zones, IBM LPAR and capped micro partitions, capped vPar, nPar, capped Integrity Virtual Machines and Fujitsu PPAR.
Not reliably, and you should not plan around them. Oracle commonly rejects affinity rules because an administrator can change them without a hardware change, and audit findings are built on what is technically possible. Only physical separation or a separate management domain holds up.
The document states that it is for educational purposes only and may not be incorporated into any contract. That gives you a real argument where the policy is not referenced in your ordering document. Treat it as negotiating leverage rather than as a defense you can rely on alone.
The difference between pinned hosts and the full reachable pool commonly runs 3 to 8 times on the estates we review. On a large shared management estate that gap reaches seven figures once five years of support is included, which is why isolation projects usually pay back inside a year.
Yes, materially. Isolating the Oracle estate in its own vCenter and SSO domain removes cross vCenter migration and cuts the reachable pool to that estate. It is the strongest boundary available short of fully separate hardware.
The unit changes from reachable cores to vCPUs. Two vCPUs count as one processor license where hyperthreading is enabled, one vCPU where it is not, and the Processor Core Factor Table does not apply. That removes the reachability argument but can raise the count on hardware with a favorable core factor.
Yes, in writing, at the right moment. A documented and dated containment design presented during scope discussion is far more effective than the same design produced after a finding. Ideally the acceptance is recorded in a contract amendment at your next purchase or renewal.
By mapping the reachable pool, designing the contained estate with your platform team, and running the renewal or audit response on the measured position. We do not resell Oracle or VMware and we do not implement either.
The work runs inside the Vendor Shield subscription, the Renewal Program, and the Benchmark Program, and it connects directly to the Oracle audit defense guide when a notice has already arrived.
Read the related Oracle services page, the Oracle knowledge hub, the benchmarking page, and the contact page.
The buyer side moves that keep your Oracle estate honest at renewal.
Independent. Buyer side. Built for Oracle customers running the next renewal cycle.
Open the white paper in your browser. Corporate email only.
Open the Paper →
Renewal in twelve months. Audit notice in the inbox. RFP on the desk. We start where you are.
VMware core counting rules, vMotion scope, containment moves, OCI and BYOL math, and audit defense intelligence from every Oracle engagement we run on the buyer side.
