What does the worked example start with?
The worked example starts with a common setup: a VMware cluster of four physical hosts, each with two processors of sixteen cores, where Oracle runs on virtual machines that in practice live on only two of the four hosts. The cluster also runs many non Oracle workloads, which is why it was sized at four hosts in the first place. The buyer believes its Oracle footprint is two hosts, because that is where Oracle has always run, and it has never licensed beyond that.
Then the audit letter arrives. Oracle requests the cluster configuration, the buyer provides it, and the preliminary finding treats the whole cluster as in scope. This is the cluster wide claim, and it rests on Oracle's partitioning policy, which does not recognise VMware as hard partitioning. The figures below are indicative and anonymized, used to show the mechanics rather than to quote any real client, because the exact outcome is contract dependent.
How does the cluster wide claim inflate the number?
The cluster wide claim inflates the number by counting every core in the cluster as licensable, including the cores Oracle never ran on. With the core factor table applied, the maths is straightforward and steep. The defense reverses it by confining the count to Oracle's real footprint.
| Basis | Cores counted | Processor licenses |
|---|---|---|
| Cluster wide claim, 4 hosts | 128 cores | 64 at 0.5 core factor |
| Oracle footprint, 2 hosts | 64 cores | 32 at 0.5 core factor |
| Difference removed | 64 cores | 32 licenses |
The claim doubles the licensable processors against the buyer's real use. At list price, with options and support layered on top, the gap between the two rows is the difference between a routine true up and a finding large enough to reshape a budget. Nothing in the buyer's actual deployment changed; only the assumption about where Oracle could run.
What is the buyer move?
The buyer move is to confine Oracle to its real footprint and prove it, so the licensable count falls to the cores Oracle actually used rather than every core it could theoretically reach. There are two clean ways to do this. The first is a dedicated cluster, where Oracle runs on physically separated hosts and the licensable scope is simply that cluster's cores. The second is required host affinity rules that bind Oracle to named hosts inside a shared cluster, backed by migration logs showing Oracle never moved off them.
Either way, the defense pairs facts with the contract. The policy document is not the contract, so even where Oracle asserts a cluster wide reading, the signed agreement often does not support it. In the worked example, the buyer shows migration history confirming Oracle lived on two hosts for the entire audit period, points to the contract language, and the finding falls from the cluster wide figure to the real footprint. That is the 60 to 80 percent kind of reduction a line by line review produces when the evidence is ready.
What is the lesson from the example?
The lesson is that the inflation lives in an assumption, not in the buyer's actual use, so the defense is evidence rather than argument. The cluster wide claim is an opening position dressed up as a measurement, and it collapses the moment the buyer can prove where Oracle ran. The buyers who pay the inflated figure are usually the ones who had no contemporaneous record and could not rebut the assumption inside the 30 to 45 day response window.
So the move is preventive as much as defensive. Decide the Oracle footprint deliberately, enforce it with a dedicated cluster or required affinity rules, and retain the logs that prove it held. A buyer who does this turns a potential doubling of the bill into a non event, because the cluster wide claim never gets traction. The worked example is simple, but the same logic scales to any cluster size, and the larger the cluster, the larger the gap the buyer move closes.
How does the example change at larger scale?
At larger scale the gap the buyer move closes grows faster than the cluster, because the cluster wide claim counts every added host while the real footprint stays roughly fixed. In the four host example the claim doubled the count. In an eight host cluster where Oracle still genuinely runs on two hosts, the cluster wide claim would count four times the real footprint, and in larger shared estates the multiple climbs further. The inflation is a function of how much non Oracle capacity shares the cluster, not of how much Oracle the buyer actually runs.
This is why virtualization findings are among the largest Oracle produces and why they reward defense so heavily. The same evidence based move applies at any size: confine Oracle, prove it with migration logs and configuration records, and pair the facts with the contract, since the policy document is not the contract. A buyer with a large shared estate and a small Oracle footprint has the most to gain, because the cluster wide assumption inflates its number the most, and a clean record collapses that number back to the cores Oracle actually used.
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. If you have a virtualization finding on the table, our virtualization and cloud licensing service can run the numbers, or reach us through contact.