Oracle's partitioning stance treats a VMware cluster as a single licensable boundary, which is normally an audit risk. At certification the same rule runs the other way: where Oracle genuinely runs across a cluster, the processors across that cluster can count toward your number.
Virtualization is the part of a ULA exit where the rules feel most unfair, and where the most value is won or lost. Oracle's published position on partitioning means a VMware estate is rarely counted the way intuition suggests. The same stance that lets Oracle sweep a whole cluster into an audit finding also lets a well run customer carry a whole cluster into a certified count. This article is about using that symmetry deliberately, with the evidence that keeps it standing.
Oracle divides partitioning into hard and soft. Hard partitioning, by Oracle's definition, can bound the processors that must be licensed. Soft partitioning, which is how VMware is treated, does not bound scope in Oracle's view. The practical effect is that Oracle counts the physical processors where an Oracle workload could run, not only the virtual machine it happens to sit in. On a cluster where virtual machines move freely between hosts, that reasoning can extend the licensable footprint to every host in the cluster, and in some configurations to hosts in connected clusters that share storage or vMotion boundaries.
For a quick grounding in the distinction, read hard partitioning versus soft partitioning. The rest of this article assumes you accept the rule and want to understand how it behaves at certification rather than at audit.
Yes. Because soft partitioning does not limit scope, the processors that count toward certification can extend across a cluster wherever Oracle is genuinely deployed. During the term, when deployment is unlimited and free, that breadth is an asset rather than a liability. A database that runs on a large cluster can support a certified count built on the cluster's processors, not just the cores of one virtual machine. At certification you are converting that deployed reality into a permanent entitlement, and the partitioning rule that usually works against customers is now sizing the entitlement upward.
The critical qualifier is genuine deployment. The processors count because Oracle actually runs across that hardware, with the mobility and the configuration that make the cluster a single boundary. This is not a licensing trick laid over an empty estate. It is the honest counting of an estate that was virtualized for ordinary operational reasons and happens to sit inside the unlimited term.
Three estate patterns produce most of the upside, and each one is common in large enterprises.
Many platform teams run Oracle databases on the same general purpose VMware clusters that host the rest of the estate. Under the partitioning rule, the Oracle footprint on those clusters can be counted across the hosts that Oracle workloads can reach. An estate that was sized for consolidation can therefore certify a count far above the cores in the database virtual machines alone.
Where clusters are joined so that virtual machines can migrate between them, the reachable footprint can be wider than a single cluster. The detail is configuration specific and contract specific, and it cuts both ways, so it has to be evidenced carefully rather than assumed. But where the reach is real, it is countable.
Disaster recovery and non production environments running on virtualized infrastructure within the term are themselves candidates to count. When they sit on shared clusters, they compound the effect. We cover the broader non production point in the peak deployment question.
Consider an indicative financial services estate. Oracle databases run in virtual machines totalling 160 cores. A naive count applies a core factor to those 160 cores and stops. A partitioning aware count recognises that those databases run on two connected VMware clusters of 24 dual socket hosts each, with vMotion enabled across both. Counting the processors across the reachable hosts, with the standard core factor applied, produces a certified number several multiples higher. The exact figure depends entirely on host core counts, the core factor, and the cluster topology, and it must be backed by configuration evidence. The figures are indicative.
For a fuller numeric treatment of how a maximization count is assembled, see maximization case math, a worked example.
A certified count built on cluster scope is only as strong as the documentation behind it. Audit risk rises in the first two years after certification, and a virtualized count is exactly the kind of number an auditor will probe. The evidence file needs the cluster inventory, host specifications with socket and core counts, the vMotion and storage configuration that defines the boundary, the core factor applied, and dated proof that Oracle was running on that infrastructure within the term. Discovery tool output and configuration exports captured at the time are worth far more than reconstructions made later.
There is a discipline point that separates maximization from exposure. The boundary you certify should be the boundary that genuinely existed. If you certify a count across two clusters because vMotion was enabled between them, that configuration needs to be documented as it stood. Counting reach you cannot evidence is the fastest way to turn a strong position into a contested one.
Maximization is not always the goal in a virtualized estate. If you intend to keep running Oracle on shared clusters after certification and want to limit future audit exposure, isolating Oracle onto dedicated clusters is the defensive move, and it changes the count you would certify. The two strategies pull in opposite directions, and the right one depends on your post exit plans. Our note on dedicated clusters as a defense explains the trade. The point of this article is that, where a larger count serves you, the partitioning rule supports it, not just the auditor.
Virtualization is one lever among several in a maximization program. For the complete approach, start with our Oracle ULA deployment maximization guide. To see the arithmetic of an assembled count, read maximization case math, a worked example. And to weigh the defensive alternative, read dedicated clusters as a defense. Because the answer turns on cluster topology and contract language, a virtualized estate is one of the clearest cases for an early, specific review.
Yes. Under Oracle's partitioning stance soft partitioning does not limit scope, so the processors that count can extend across a cluster, and sometimes connected clusters, where Oracle is deployed. At certification this can lift the number, provided the deployments are real and evidenced.
It is safe when the Oracle deployments are genuine and documented and the counting method matches the contract. The same partitioning rule that creates audit exposure also supports a larger count, but only real, running, evidenced deployments hold up.
We map your VMware topology to the certified position it supports, and the evidence that protects it.