Under Oracle's partitioning stance, VMware is soft partitioning and does not limit scope. Because vMotion can move an Oracle virtual machine across a cluster, Oracle treats every reachable host as in scope, sweeping whole clusters into the count. Isolation and documentation are the defense, and inside a ULA the same rule can lift a maximized count.
Virtualization is where Oracle licensing turns from a counting exercise into an argument, and vMotion is at the centre of it. The technical convenience that makes VMware powerful, the ability to move a running virtual machine to any host with no downtime, is exactly what Oracle's partitioning position uses to expand scope. The result is the scope sweep: a count that reaches far beyond the hosts actually running Oracle. Understanding how the sweep works is the first step, because the same mechanism that creates audit exposure outside a ULA can be turned to your advantage inside one, where deployment is unlimited and a real cluster can lift your certified count.
Under Oracle's partitioning stance, VMware is treated as soft partitioning, which does not limit licensing scope. Hard partitioning methods that Oracle recognises can pin licensing to a defined subset of processors, but soft partitioning, in Oracle's view, cannot. vMotion compounds this. Because an Oracle virtual machine can be moved to any host in a cluster, and across clusters joined by shared storage or management, Oracle's position is that every host the workload could reach is in scope, not merely the host it happens to run on. So a single Oracle virtual machine on a large cluster can, on Oracle's reading, put every host in that cluster, and connected clusters, into the count. That is the sweep: licensing follows the reach of the workload, not its current location, and the reach is as wide as your vMotion boundaries allow.
Oracle counts where a workload could run, not just where it does. Draw the vMotion boundary deliberately, document it, and you decide the scope rather than letting the cluster decide it for you.
Isolation and documentation. The defense is to make sure Oracle workloads cannot, in fact, reach hosts you do not intend to license, and to be able to prove it. In practice that means running Oracle on dedicated clusters whose hosts are physically and logically separated from non Oracle infrastructure, restricting vMotion and migration boundaries so an Oracle virtual machine cannot move onto unlicensed hosts, and avoiding shared storage and management arrangements that link an Oracle cluster to a wider estate. None of this matters at audit unless it is documented. Configuration records, host inventories, cluster definitions, and evidence of the migration boundaries are what turn an architectural decision into a defensible position. A clearly isolated and evidenced Oracle cluster limits the hosts in scope to those genuinely running the software, which is the whole point.
| Configuration | Oracle's likely scope position |
|---|---|
| Oracle on a shared mixed cluster, open vMotion | Whole cluster, and linked clusters, in scope |
| Oracle on a dedicated cluster, restricted boundaries | Limited to the isolated, documented hosts |
| No documentation of isolation | Sweep harder to rebut at audit |
| Documented isolation and boundaries | Defensible, scope held to real deployment |
Yes, and this is the part teams miss. The partitioning stance that creates exposure outside a ULA can support a higher count inside one. During the term, your right to deploy is unlimited, so a fully deployed Oracle cluster is entirely covered, and at certification each host genuinely running Oracle contributes to the defensible count. Where you have real Oracle clusters, counting them fully is legitimate maximization, not aggression, because the deployment is real and the unlimited right covered it. The discipline is the same as everywhere else in ULA work: count what is genuinely deployed, evidence each host, and do not claim hosts that were never running Oracle. The same rule that sweeps against you at audit can count for you at certification, provided the deployment is real and documented before the cutoff.
Consider an anonymized organisation running Oracle on a large shared VMware estate as a ULA neared its end. Left as it was, the configuration exposed the whole estate to Oracle's scope position. The organisation separated genuine Oracle workloads onto dedicated, documented clusters with restricted migration boundaries, which both contained the scope sweep and produced a clean, evidenced count of the hosts actually running Oracle. The figures are indicative and the outcome turned on the architecture and the contract, but the same move that defended against an inflated audit scope also delivered a defensible certified count of real Oracle deployment. Architecture and licensing were solved together.
Virtualization rewards deliberate architecture and good evidence. Read containers and Kubernetes in a ULA count for how modern platforms are treated, and turning the cluster rule to your advantage for using the partitioning stance inside a ULA. For the full exit picture, the ULA exit strategy guide places virtualization in the wider certification plan.
Under Oracle's partitioning stance, VMware is soft partitioning, which does not limit licensing scope. Because vMotion can move an Oracle virtual machine to any host in a cluster, and across linked clusters, Oracle's position treats every host the workload could reach as in scope, sweeping the whole cluster into the count rather than the few hosts actually running Oracle.
Isolation and documentation. Run Oracle on dedicated clusters whose hosts are separated from non Oracle infrastructure, restrict vMotion boundaries so workloads cannot reach unlicensed hosts, and document the configuration. A clearly isolated and evidenced cluster limits the hosts in scope to those genuinely running Oracle.
Yes. During the term deployment is unlimited, so a fully deployed Oracle cluster can legitimately raise the defensible certification count. The same partitioning stance that creates audit risk outside a ULA can support a higher maximized count inside one, provided the deployment is real and evidenced before the cutoff.
Book a confidential assessment and we will review your virtualization architecture, contain the scope sweep, and turn real Oracle clusters into a defensible certified count.