A handful of ordinary VMware configurations can turn a modest Oracle footprint into a certification count many times larger. Each mistake has a clear cause and a defensible fix. Knowing them before the exit is the difference between a proportionate number and a painful one.
By the Meridian advisory team · Ex Oracle licensing analysts · Updated June 2026
Running Oracle on a shared cluster alongside non Oracle workloads. Under Oracle's soft partitioning stance, every host an Oracle workload can reach falls into scope, so a shared estate puts every host in the count even when Oracle uses a fraction of them. This single mistake produces the largest gaps between actual Oracle use and the number a buyer is asked to certify. The fix is a dedicated, isolated cluster with no migration path outward, settled well before the exit and supported by evidence. Everything else in this article is a variation on the same theme: the count follows reachability, not usage, and reachability is something you control.
Almost every virtualization mistake at a ULA exit shares one root cause. The boundary is set by where Oracle could run, not by where it does. Shrink the set of hosts Oracle can reach, prove the constraint, and the count falls to match real use. Leave the boundary wide and you certify hardware Oracle never touched.
These are the patterns we see inflate counts again and again. None is exotic. They are the normal output of an estate run for performance and availability rather than for a licensing event.
Oracle and non Oracle virtual machines share the same hosts. Because the Oracle workload can run on any host in the cluster, the whole cluster is in scope. A team often assumes the count tracks the few virtual machines actually running Oracle, when it tracks the hosts those machines could occupy. The fix is separation: Oracle on its own hosts, forming their own cluster, with nothing else sharing them.
Features that move workloads automatically or live across hosts are valuable for availability and a liability at certification. If an Oracle workload can be moved onto hosts outside its cluster, those hosts are treated as in scope. The fix is to remove any path by which Oracle could migrate beyond its dedicated cluster, and to evidence the removal rather than simply intend it.
Isolation is often undone below the hypervisor. Shared datastores, common management groupings, and overlapping fabrics can reconnect clusters that look separate on a diagram. A cluster labelled isolated but wired into shared storage that other clusters also use may not be isolated at all. The fix is to check the storage and network layers, not just the cluster membership, so the boundary is real end to end.
The final mistake is doing the right thing too late. Isolating Oracle in the closing weeks before certification can look staged purely to lower the count, which invites scrutiny in any audit after the exit. The fix is timing: isolate early, run the configuration as a steady state, and let the architecture reflect how Oracle is genuinely operated rather than a temporary shape built for the letter.
The figures below are indicative and shown only to illustrate the compounding effect of these mistakes.
| Configuration | Hosts in boundary | Indicative processors |
|---|---|---|
| Oracle isolated on a dedicated 8 host cluster, migration removed and evidenced | 8 | 64 |
| Same workload, but the cluster shares storage with two other clusters | 24 | 192 |
| Same again, with automatic placement enabled across the shared estate | 40 | 320 |
Actual Oracle use is identical in all three rows. Only the reachability changes. Shared storage alone lifts the indicative count from 64 to 192 processors, and leaving automatic placement enabled across the shared estate carries it to 320. The lesson is that these mistakes compound. Fix one and leave another in place and the count stays inflated. A defensible position closes every path at once, which is why isolation is judged on the whole configuration rather than on a single setting.
For each correction, capture the proof: dedicated cluster membership, the absence of any outward migration path, and storage and network separation, dated and retained. Oracle accepts a contained boundary when you can show it. An unevidenced fix is hard to defend, especially once the certification letter is signed and an audit follows.
It can, but only when the path is genuinely removed and the removal is evidenced. Oracle's stance treats the hosts an Oracle workload could move to as in scope, so a feature that allows automatic or live movement across clusters widens the boundary even if no move ever occurs. Disabling the feature, removing the cross cluster path, and documenting that the constraint is real will confine the boundary. A configuration you intend but do not enforce is not a defense, and a setting changed without a record of the change is hard to rely on when the position is tested. The discipline is the same throughout: make the constraint real, then make it provable.
Isolation is the right move, but doing it in the final weeks is risky. A late reorganisation can look staged purely to lower the count, which invites exactly the scrutiny a buyer is trying to avoid. Isolation that has run as a steady state for months is far more defensible, because it reflects how Oracle is genuinely operated rather than a temporary shape built for the certification letter. The practical answer is to plan the virtualization work as part of the exit roadmap, not as a closing task, so the configuration is settled, evidenced, and ordinary by the time the window opens.
Avoiding these mistakes starts with the rule behind them and the architecture that answers it. Read Oracle's partitioning stance explained for why reachability sets the count, and isolating Oracle workloads before exit for the configuration that contains it. Because most of these mistakes are operational, educating the virtualization team early is the program that prevents them. For the complete method, our Oracle ULA exit strategy guide is the pillar that sequences virtualization alongside counting and timing.
Running Oracle on a shared cluster alongside non Oracle workloads. Under Oracle's soft partitioning stance every host the Oracle workload can reach falls into scope, so a shared estate puts every host in the count even when Oracle uses a fraction of them. The fix is a dedicated, isolated cluster with no migration path outward, settled well before the exit and documented.
It can, but only when the path is genuinely removed and the removal is evidenced. Oracle's stance treats the hosts an Oracle workload could move to as in scope, so a feature that allows automatic or live movement across clusters widens the boundary even if no move ever occurs. Removing that path confines the boundary, but a configuration you intend rather than enforce is not a defense.
Isolation is right, but doing it in the final weeks is risky. A late reorganisation can look staged purely to lower the count, which invites scrutiny in any audit after the exit. Isolation that has run as a steady state for months is far more defensible, because it reflects how Oracle is genuinely operated rather than a temporary shape built for the certification letter.