Buyer Side Briefing

The Oracle virtualization licensing guide

Oracle's partitioning policy does not recognise VMware, Hyper V or KVM as hard partitioning, so by that policy every physical core a cluster could run Oracle on is treated as licensable, even when Oracle runs on a single host. The buyer move is to remember that the policy document is not the contract, and to hold the evidence that proves the real footprint.

Does Oracle recognise VMware as hard partitioning?

Oracle does not recognise VMware as hard partitioning, and that single fact is the root of the largest source of audit inflation in virtualized estates. Oracle's partitioning policy divides technologies into hard partitioning, which limits licensing to a defined subset of cores, and soft partitioning, which does not. VMware, Hyper V and KVM all fall on the soft partitioning side of that policy. By Oracle's reading, that means a database running in a virtual machine can be claimed against every physical core the virtual machine could possibly run on, not just the cores it actually uses.

The consequence is the cluster wide claim. If Oracle runs in one virtual machine on one host, but that host sits in a cluster of ten servers that the virtual machine could migrate to, Oracle's policy treats all ten servers as licensable. The licensing requirement is calculated as though Oracle ran everywhere it could move, rather than where it actually runs. This is why a small Oracle footprint on a large VMware cluster can generate a finding far out of proportion to the real usage, and why virtualization is one of the most common audit triggers.

Is the Oracle partitioning policy part of the contract?

No, the partitioning policy is a policy document and not the contract, and the signed agreement governs where the two conflict. This distinction is the buyer's central point of leverage in any virtualization dispute. Oracle's partitioning rules live in a policy paper that Oracle publishes and can change, but the rights and obligations that actually bind the parties are in the Oracle Master Agreement and its ordering documents. A cluster wide claim built on the partitioning policy is only as strong as the policy's standing against the contract, and that standing is often weaker than the claim implies.

This means a virtualization finding is not a settled fact the moment Oracle asserts it. It is a position resting on a policy document, and the buyer is entitled to read that position against the signed agreement. Where the contract does not incorporate the partitioning policy, or where its terms define licensing differently, the policy based cluster wide claim can be contested at its foundation. The buyer move is to treat the partitioning policy as an opening argument, not a rule, and to ask what the contract actually says before conceding a single core.

Indicative virtualization licensing positions. Anonymized and contract dependent.
ScenarioOracle policy viewBuyer position
Oracle on one host, open clusterWhole cluster licensableContract beats policy
Host affinity rules in placeOften disputedEvidence limits the footprint
Dedicated Oracle clusterCluster cores onlyCleanest defensible position
Hard partitioning technologySubset of coresRecognised limit

How does a cluster wide claim get so large?

A cluster wide claim gets large because the count is driven by hardware the database never touches, multiplied by the core factor table. Oracle's policy counts every physical core in every host the virtual machine could reach, and modern clusters are built from many servers with high core counts. Multiply those cores by the applicable core factor and the licensing requirement balloons to a figure that reflects the cluster's total capacity rather than the database's real demand. The same Oracle database that needs a handful of cores can be claimed against hundreds.

Virtualization platforms make the reach even wider when clusters are linked or when management features allow a virtual machine to migrate across boundaries. Oracle has at times argued that connected clusters, or an entire virtual environment, are all in scope because the workload could in principle move anywhere within it. These broad readings push the count from one cluster to many, and they are where the most extreme findings come from. Because the figure is built from theoretical mobility rather than actual placement, it is also where careful evidence of the real footprint produces the largest reductions.

How do you limit virtualization exposure?

You limit virtualization exposure by containing Oracle to defined hosts and holding the evidence that proves it stayed there, which turns a cluster wide claim back into a count of the cores that actually run Oracle. The strongest technical control is a dedicated cluster: a set of hosts that runs Oracle and only Oracle, physically separated from the rest of the estate, so there is no larger cluster for a claim to reach into. With a dedicated cluster, the licensable cores are simply the cores in that cluster, which is a clean and defensible position.

Where a dedicated cluster is not practical, host affinity rules are the next control. These rules pin Oracle virtual machines to a named subset of hosts and prevent them migrating to the rest, and when combined with configuration that genuinely blocks movement, they define the real footprint. The defense depends on evidence: host affinity configuration, migration settings, and deployment records that show, with dated proof, where Oracle ran and where it could not go. That contemporaneous evidence is what reduces a policy based cluster wide claim to the hosts Oracle actually used.

How is a virtualization finding defended in an audit?

A virtualization finding is defended in an audit by attacking it on two fronts at once: the contract argument that policy does not override the agreement, and the evidence that shows the real Oracle footprint. The contract front asks whether the partitioning policy binds at all, since the policy document is not the contract and the signed agreement governs. The evidence front shows where Oracle actually ran, using host affinity rules, migration configuration and deployment records, so that even if some policy applies, the count reflects reality rather than the cluster's full capacity.

This matters because Oracle's collection scripts can overcount across virtualization layers, reading a whole cluster as licensable, and preliminary findings arrive inflated at list price. Submitting raw script output without review hands Oracle a number built on theoretical reach. The buyer move is to review that output before it leaves, replace it where it overstates the footprint, and contest the cluster wide assumption with both the contract point and the contemporaneous evidence. An independent line by line review of findings typically cuts claims by 60 to 80 percent, and virtualization claims, built as they are on mobility rather than actual use, are frequently where the largest single reduction is found.

The next step

This article is part of our Virtualization and VMware cluster. Read the pillar, the Oracle virtualization licensing guide, for the full picture, and these related reads: dedicated clusters as the standard defense, and host affinity rules and evidence.

Next step

Download guide

FAQ

Questions buyers ask first.

No. Oracle's partitioning policy does not recognise VMware, Hyper V or KVM as hard partitioning, so by that policy every physical core a VMware cluster could run Oracle on is treated as licensable, even if Oracle runs on only one host.
No. The partitioning policy is a policy document, not the contract, and the signed agreement governs where they conflict. Cluster wide claims often rest on policy that is weaker than the contract, which is the buyer's main point of leverage.
You limit exposure by containing Oracle to defined hosts with host affinity rules and dedicated clusters, and by holding the evidence that proves the real footprint. That evidence rebuts a cluster wide claim and reduces the count to the hosts that actually run Oracle.
The License Position

Read Oracle's next move before they make it.

A short weekly note on Oracle audits, Java, ULAs and negotiation, written for the buyer. One development, why it matters, and one move you can make this week.

No spam. Unsubscribe anytime.