Oracle treats VMware as soft partitioning, which in its view does not limit licensing scope. At a ULA exit that single stance can sweep an entire cluster into the count, which is an opportunity during the unlimited term and an exposure in the years after certification.
No single topic decides more ULA exit value than how Oracle treats VMware. The partitioning stance behind that treatment can multiply a certified count or create an audit liability, and which one you get depends on how you manage the estate and document it. This article explains the stance in plain terms, shows how it behaves at certification, and sets out the choices that turn it to your advantage or against you.
Oracle classifies partitioning technologies as either hard or soft. Hard partitioning can bound the processors that must be licensed. VMware, in Oracle's published position, is soft partitioning, which does not bound scope. The practical effect is that Oracle counts the physical processors an Oracle virtual machine could run on, not only the cores it currently occupies. Because virtual machines migrate across hosts in a cluster, that reasoning can extend the licensable footprint to every host in the cluster, and in some configurations across connected clusters that share migration or storage boundaries. This is Oracle's interpretation rather than a clause most customers negotiated, and it is the starting point for everything that follows. For the underlying distinction, read hard partitioning versus soft partitioning.
During a ULA term, deployment is unlimited and free, so a broad VMware footprint carries no penalty. At certification, that footprint becomes a number. Where Oracle genuinely runs across a large cluster, the processors across that cluster are candidates to be counted, which can lift the certified entitlement well above the cores in the database virtual machines alone. The same rule that an auditor would use to inflate a finding can, inside the unlimited term, inflate the permanent entitlement you keep. This is why VMware is the clearest example of a trap that can be turned into a tool.
The decisive word remains genuine. The processors count because Oracle actually ran across that hardware within the term, with the mobility that makes the cluster a single boundary. A certified count built on cluster scope has to reflect the configuration as it truly stood, evidenced at the time, or it becomes the weakest part of your position rather than the strongest.
Both, and the difference is your goal. If you want the largest possible permanent entitlement and you are comfortable continuing to run Oracle broadly, the cluster sweep works for you, and you certify the wider footprint. If you intend to limit future Oracle exposure and keep a tight, predictable licensed boundary after the exit, the same breadth is a liability, because every host Oracle can reach is a host an auditor will count. Most estates sit somewhere between, and the right answer comes from your post exit plans, not from a general rule.
Consider an indicative insurer running Oracle databases in virtual machines totalling 120 cores on a shared VMware cluster of 32 dual socket hosts with vMotion enabled. A naive count applies the core factor to the 120 cores. A partitioning aware count recognises the reachable hosts and, with the standard core factor, produces a certified number several multiples higher. If the insurer instead isolates Oracle onto a small dedicated cluster before the exit, the count is smaller but the future audit surface is far tighter. The figures are indicative and the outcome turns on topology and contract language.
The VMware decision usually reduces to a choice between maximizing and isolating, and it is worth naming both clearly.
Where a larger entitlement serves you, you certify the genuine cluster footprint and bank a higher permanent number at no extra support cost. This suits organisations that will keep running Oracle widely and value the headroom. The cost is that you have certified a large footprint you must continue to evidence. The mechanics of building such a count are covered in maximization in virtualized estates.
Where future predictability matters more, you move Oracle onto dedicated clusters before the exit, certify the tighter footprint, and shrink the surface an auditor can later sweep. This suits organisations reducing Oracle dependence or wanting tight cost control afterward. The approach and its requirements are covered in dedicated clusters as a defense.
Whichever strategy you choose, the evidence file decides whether it holds. Audit risk rises in the first two years after certification, and a VMware position is exactly what an auditor probes. The 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 of what ran where within the term. A maximized count needs this to defend its size. An isolated count needs it to prove the isolation was real. There is no version of a VMware position that survives without documentation built at the time.
VMware is the highest leverage decision in many exits, and it is contract and topology specific, so it rewards early analysis. For the full exit framework, start with our ULA exit strategy guide. To pursue the larger number, read maximization in virtualized estates, and to pursue the tighter one, read dedicated clusters as a defense. Because the same rule can lift or sink your position, a virtualized estate is one of the strongest reasons to have your exit reviewed well before the window opens.
Oracle treats VMware as soft partitioning, which in its view does not limit licensing scope. The processors that must be licensed can extend across every host an Oracle virtual machine could run on, which can mean an entire cluster, not just the cores in use.
Both, depending on your goal. During the unlimited term a broad cluster footprint can lift the certified count for free. After certification the same breadth becomes audit exposure, so isolation and documentation matter for the position you want to hold.
We model your cluster footprint as both a maximized count and a defended one, so you choose with the numbers in front of you.