On VMware the count follows reach, so your certified number rests on what you can prove about the boundary. The record set you assemble before the window decides whether your position holds.
By Daniel Voss · Ex Oracle LMS · 4 June 2026
Oracle counts Oracle on VMware by reach, not by residence, so your certification position depends on documentation that fixes a defensible boundary. The records that matter are cluster and host inventories, vCenter topology exports, version and configuration history covering the term, and any isolation controls that confined Oracle virtual machines to a defined set of hosts. Evidence that only describes the present day rarely holds, because the question is where Oracle could have run across the whole term, not where it sits now.
Oracle treats VMware as soft partitioning, which it does not accept as a way to limit licensing scope. The stance is that Oracle software must be licensed everywhere the virtual machines could run, not only where they run on the day you look. That single rule turns certification on a virtualized estate into a question about reach, and reach is something you have to demonstrate rather than describe. The deployed processors you declare are only as defensible as the records that show what the cluster could and could not do during the term.
This is why two organizations with identical hardware can end up with very different certified numbers. The one that built isolation and documented it can fix the boundary at the dedicated hosts. The one that ran Oracle in a large shared cluster, with no record of where the virtual machines were allowed to migrate, faces an argument it cannot win on assertion alone. The architecture sets the ceiling on what is possible. The evidence decides what is defensible inside it.
Oracle looks for proof of the reach of the environment across the term. In practice that breaks into four record sets, and each answers a different question a reviewer will raise. The aim is to make the boundary self evident from the documents, so the conversation is about what the records show rather than about what either side believes.
A complete list of every VMware cluster, the hosts inside each, and the physical processors and core counts on those hosts. This is the raw material of any processor count. Without it, neither side can agree what the universe of hardware is, and an incomplete inventory tends to be read against you because Oracle assumes reach where the record is silent.
Exports that show how clusters are structured, which hosts a virtual machine could move to, and whether any feature crossed cluster boundaries. The point of contention is almost always how far an Oracle virtual machine could migrate. Topology that shows a contained, dedicated cluster is the difference between counting a defined set of hosts and counting an entire data center.
If you rely on a dedicated cluster to hold the boundary, you need to show the isolation existed during the term, not just at the point of certification. Configuration records, change tickets, and host group definitions that date the isolation are what convert an architecture into a position. Isolation introduced the week before you certify carries far less weight than isolation that governed the deployment throughout.
Server lists tied to the Oracle databases and options actually running, with the versions and editions in place. These reconcile the virtualization picture to the licensing picture, so the processors you count map to genuine Oracle deployments rather than to empty capacity. They also feed the broader evidence file that defends the certified number after the letter is signed.
Build the evidence as you build the isolation, never afterward. A boundary you can prove is a position. A boundary you merely assert is an invitation to count wider. The strongest virtualization file is one assembled while the controls are live, dated, and reconciled to the deployments they govern.
It helps to see how each record set changes what is defensible. The table below shows an anonymized example where the same hardware produces very different counts depending on what the evidence supports. The figures are indicative and exist to show the logic, not to represent any real engagement, and the real outcome depends on the estate and the agreement.
| Evidence available | Defensible processors | Why |
|---|---|---|
| None beyond a host list | 880 | Silence is read as full cluster reach |
| Topology, no dated isolation | 560 | Migration scope narrowed but not fixed |
| Topology plus dated isolation | 240 | Boundary proven for the full term |
| Full file, maximization goal | 880 | Breadth captured deliberately as entitlement |
Indicative only. The reach of a virtualization count depends entirely on cluster topology, the isolation in place, and the wording of the specific agreement. The spread between the rows is the value of the evidence, which is why the file matters as much as the architecture.
The most defensible files are built in order, because each record depends on the one before it. A reasonable sequence runs: confirm the full cluster and host inventory; export vCenter topology and document migration scope; date the isolation controls with configuration and change records; reconcile the Oracle deployments and versions to the hosts; then test the whole file against the boundary you intend to certify. The test matters, because the file has to survive a reviewer who will read every silence as reach.
An anonymized example makes the value concrete. A mid sized insurer believed a dedicated cluster held its count at a narrow number. The architecture was sound, but the isolation had only been formalized late in the term and the early configuration was undocumented. Building the dated history of the host group, and showing the change records that confined the Oracle virtual machines, turned a contestable claim into a position that held. The hardware never changed. The evidence did.
On VMware your certified number is an evidence question before it is an architecture question, and the file has to be built while the controls are live and dated. Decide the boundary you intend to certify, then assemble the inventory, topology, isolation history, and deployment records that prove it. Understand how the count itself behaves in counting Oracle on VMware at certification, plan for life after the letter in virtualization after certification, the new rules, and ground the whole approach in our ULA exit strategy guide.
Book a ULA assessment and we will map your virtualized estate, identify the records Oracle will ask for, and assemble the evidence that fixes a defensible boundary at certification.