How a VMware estate is counted at a ULA exit is decided by the contract, not by intuition. A handful of clauses, plus whether Oracle's partitioning policy binds you, together set whether a cluster is swept into your number or kept out of it.
Most discussion of Oracle and VMware jumps straight to the partitioning policy and skips the document that actually governs you: your own agreement. The policy matters, but only to the extent your ULA gives it force, and the way your estate is counted depends on several clauses working together. This article walks the contract language that decides a virtualized count, so you can read your own agreement with a clear idea of where to look and what each part means.
Four areas of the contract do the work. The counting metric definition sets whether you count processors, Named User Plus, or both, and how cores convert to licensable processors. The installed and running or deployment language sets what state a workload must be in to count. The customer definition and territory clauses set which entities and locations are in scope, which matters because a cluster spanning sites or legal entities can cross those boundaries. And any cloud counting terms set how virtualized capacity outside your data centre is treated. The partitioning question sits across all of these, and whether Oracle's policy applies depends on whether your agreement incorporates it.
This is the question that changes everything and the one most often assumed rather than checked. Oracle publishes a partitioning document that classifies VMware as soft partitioning and asserts that it does not limit scope. That document is policy. It becomes binding on you only if your agreement incorporates it, references it, or uses language that imports it. Some ULAs do exactly that. Others define the counting metric in their own terms and never mention partitioning at all, which leaves more room to argue the count on the contract's own words. You cannot know which situation you are in without reading the metric definition and any referenced policies together. The distinction between the underlying technologies is set out in hard partitioning versus soft partitioning, but the contractual question is separate: not what soft partitioning is, but whether your ULA makes Oracle's view of it your obligation.
Once you know whether the policy binds you, the individual clauses tell you how a cluster is measured.
This clause names the unit and the conversion. For databases the usual unit is the processor, derived by applying a core factor to physical cores. In a virtualized estate the decisive subtlety is which cores the metric reaches: only the virtual machine, the host, or every host an Oracle virtual machine could migrate to. The wording here, read against any partitioning policy, sets the breadth of the count.
Some agreements count what is installed and running, others what is deployed. In a cluster where virtual machines move, the difference matters. Language that counts where a workload could run supports a broad sweep. Language tied to where it actually runs supports a narrower one. This is often the clause where a count is won or lost.
A cluster that spans data centres in different countries, or hosts serving different legal entities, can cross the territory and customer definition boundaries. Deployments outside those boundaries do not count and can trigger remediation rather than value. Where a virtualized estate is geographically or organisationally spread, these clauses interact with the partitioning question in ways that need reading together. Our notes on the territory clause and why it matters and the customer definition clause explained cover the scope side in detail.
Consider an indicative ULA that defines the processor metric in its own schedule and does not reference Oracle's partitioning policy. A VMware estate runs across two clusters in one country, all within the customer definition. Because the agreement is silent on partitioning, the count can be argued on the metric definition and the installed and running language rather than conceded to the broadest policy reading. The available position is materially different from an estate whose ULA incorporates the policy outright. The example is indicative and any real reading turns on the exact words.
The virtualization clauses are not something to interpret in the certification window. By then the estate is fixed and the only lever left is how you read the contract. Read the clauses 18 months out and you have options: isolate Oracle onto dedicated clusters to narrow the count, or deploy deliberately across clusters to widen it, depending on which serves you. The contract sets the rules of the game, and knowing the rules early is what lets you play the estate to your advantage. Where the clause is favourable, you can lean into a broad count, which is the subject of VMware and Oracle ULA certification. Where you want to limit exposure, isolation is the route, covered in dedicated clusters as a defense.
Your virtualization clauses are specific to your agreement, so the only reliable reading is of your own contract. For the full exit framework these clauses sit inside, start with our ULA exit strategy guide. To see how the count behaves once the clauses are understood, read VMware and Oracle ULA certification, and to weigh the defensive option, read dedicated clusters as a defense. Because the partitioning question turns entirely on your wording, having the clauses read early is the surest way to know your real position.
The counting metric definition, any partitioning or installed and running language, the territory and customer definition, and any cloud counting terms together decide how a virtualized estate is measured. Most ULAs lean on Oracle's general partitioning policy rather than spelling it out.
It depends on whether the agreement incorporates it. Oracle's partitioning document is policy, not automatically a contract term. Whether it binds you turns on the wording of your specific ULA, which is why the virtualization position has to be read clause by clause.
We work through the virtualization language in your ULA and tell you the count it actually supports.