Isolation is the practical answer to Oracle's soft partitioning stance. By confining Oracle to dedicated clusters with no migration path outward, you keep the certification boundary close to actual use instead of letting it sweep across the whole estate.
By the Meridian advisory team · Ex Oracle licensing analysts · Updated June 2026
Because Oracle treats VMware as soft partitioning, an Oracle workload on a shared cluster can pull the whole cluster, and sometimes linked clusters, into the certification count. The boundary is set by where Oracle could run, not only where it does. Isolation breaks that logic. By placing Oracle workloads on dedicated hosts that form their own cluster, with no path to migrate elsewhere, you confine the boundary to that cluster. It is the recognised, defensible way to keep a virtualised count proportionate to real use. During the unlimited term isolation matters little, but as certification approaches it becomes one of the highest leverage moves available, because it directly shrinks the number you will declare and defend.
Isolation only works if the workload genuinely cannot reach other hardware. A boundary you intend but do not enforce is not a boundary. The count Oracle accepts is the one you can prove was contained, not the one you meant to contain.
Isolation is an architecture, not a setting. Three things have to be true together, and all three have to be evidenced.
Oracle workloads sit on physical hosts that are theirs alone and that form a discrete cluster. Mixing Oracle and non Oracle virtual machines on shared hosts defeats the purpose, because the shared hosts are then in scope. A clean dedicated cluster is the foundation everything else rests on.
The features and configurations that let virtual machines move between clusters are the same ones that widen the boundary. Isolation requires removing any path by which an Oracle workload could migrate, live or otherwise, onto hosts outside the dedicated cluster. If the platform can move Oracle there, Oracle's stance treats those hosts as in scope whether or not a move ever happens.
Isolation is often undone quietly at the storage and network layer. Shared datastores, common management constructs, and overlapping fabrics can reconnect a cluster you thought was separate. True isolation checks these layers too, so the dedicated cluster is genuinely standalone and not merely labelled as one.
The figures below are indicative and shown only to illustrate the effect.
| Configuration | Hosts in boundary | Indicative processors |
|---|---|---|
| Oracle mixed across a 48 host shared estate | 48 | 384 |
| Oracle on a dedicated 10 host cluster, migration still possible | 48 | 384 |
| Oracle isolated on 10 hosts, migration removed and evidenced | 10 | 80 |
The middle row is the trap. Moving Oracle onto a dedicated cluster looks like isolation, but if the workload can still migrate out, the boundary is unchanged at all forty eight hosts. Only when the migration path is removed and the isolation is documented does the boundary fall to the ten host cluster, an indicative 80 processors against 384. The lesson is that isolation is judged on enforcement, not on the diagram. Half done isolation gives away the whole benefit.
Capture the cluster membership, the absence of any outward migration path, and the storage and network separation, dated and retained. Oracle accepts a contained boundary when you can show it. An unevidenced isolation is hard to defend, especially in an audit after the exit.
Well before the exit, and ideally as a steady state rather than a last minute change. Isolation that has been in place for months, running cleanly through the run up to certification, is far more defensible than a reorganisation completed in the final weeks. A late scramble can look like it was staged only to lower the count, which invites exactly the scrutiny you are trying to avoid. The same caution that applies to legitimate deployment applies here in reverse: the architecture should reflect how you genuinely run Oracle, settled early, not a temporary shape assembled for the certification letter and unwound afterwards.
Isolation is the response to a stance worth understanding first. Read Oracle's partitioning stance explained for the rule that makes isolation necessary, and read our Oracle and VMware licensing guide for the configurations that silently undo isolation. For the complete method, our Oracle ULA exit strategy guide is the pillar that sequences isolation alongside counting and timing.
Because Oracle treats VMware as soft partitioning, an Oracle workload on a shared cluster can pull the whole cluster into the certification count. Isolating Oracle onto a dedicated cluster, with no migration path to other hosts, confines the boundary to that cluster. It is the recognised way to keep a virtualised count proportionate to actual use.
Place Oracle workloads on dedicated hosts that form their own cluster, remove any feature or configuration that would let those workloads migrate to other clusters, and ensure shared storage and networking do not quietly reconnect the boundary. Then document the isolation so it can be evidenced. Intent is not enough. The constraint has to be real and shown.
Well before the exit, and ideally as a steady state rather than a last minute change. Isolation moved in place months ahead, running cleanly through the period leading to certification, is far more defensible than a reorganisation done in the final weeks, which can look like it was staged purely to lower the count.