Why do Oracle scripts overcount in virtualized estates?
Oracle scripts overcount in virtualized estates because they read every host the software could theoretically reach rather than the hosts that actually run it. In a shared hypervisor cluster, the collection tools gather data across layers, and the resulting count assumes the workload could move to any host, so every core in the cluster becomes licensable in the raw output. The number is large by design, and it lands before any human has reconciled it against your real deployment. This is the most common reason a virtualization finding arrives looking far worse than the truth. The full treatment is in the Oracle Virtualization Licensing Guide.
Does Oracle recognise VMware as hard partitioning?
No, Oracle's partitioning policy does not recognise VMware, Hyper V or KVM as hard partitioning, and that single fact is what lets the scripts assume a cluster wide boundary. Because the policy treats these hypervisors as soft partitioning, Oracle's position is that the software could run anywhere in the cluster and so must be licensed everywhere in it. The crucial point for buyers is that this is a policy stance, not a contract term, and contract language beats policy. The script output reflects the policy view, which is the widest possible reading, not necessarily the one your signed agreement supports.
Map the real boundary. Identify the hosts that genuinely run Oracle, document the controls that keep the workload there, and reconcile that against the contract before the cluster wide number becomes the agreed number.
How does counting across layers inflate the number?
Counting across layers inflates the number because the same physical capacity can be read more than once when the tools traverse the virtualization stack. A host counted at the cluster level, then again through a management layer, produces a total that exceeds the real hardware. Add the cluster wide assumption on top, and the raw figure can be a multiple of what the deployment actually consumes. None of this is malicious, it is what the tools do when pointed at a complex estate, but it is why the output is a draft and never a verdict.
| Source of overcount | What the script assumes | Buyer move |
|---|---|---|
| Cluster wide reach | Software could run on any host | Prove the real boundary |
| Layered counting | Same capacity seen twice | Deduplicate the hosts |
| Core factor ignored | Raw cores, not adjusted | Apply the core factor table |
| Policy as contract | Partitioning policy governs | Read the signed agreement |
How do you reconcile the script output?
You reconcile the script output by rebuilding the count from the real deployment up, host by host, and applying the contract and the core factor table at each step. Start from the hosts that actually run Oracle, remove the double counting introduced by the layers, apply the correct core factor, and test the boundary against what your agreement says rather than what the policy asserts. The gap between the raw figure and the reconciled figure is the heart of the negotiation, and in a virtualized estate it is often very large. For the data discipline behind this, see feature usage data, the DBA views that matter and counting processors correctly with core factors.
What is the next step?
The next step is to make sure no virtualization script output reaches Oracle until it has been reconciled against your real boundary and your contract. A cluster wide number submitted raw is the single most expensive mistake in a virtualized audit, and it is entirely avoidable. The Oracle Audit Defense Handbook gives you the boundary mapping framework and the reconciliation method to bring the figure back to the truth.
Download the Oracle Audit Defense Handbook for the virtualization boundary checklist and the script reconciliation method. Get it from the white paper library.