Oracle does not accept VMware as a way to limit scope. Whole clusters can be pulled into the count. Understood early, the same rule is a risk to contain or a lever to use, depending on your goal.
By Daniel Voss · Ex Oracle LMS · 4 June 2026
Oracle treats VMware as soft partitioning, which it does not accept as a way to limit licensing scope. Its position is that Oracle can run anywhere the virtual machines can move, so every physical processor a VMware environment can reach may be counted, not just the hosts where Oracle currently runs. At certification an unisolated cluster can pull far more processors into the count than the databases occupy. The boundary is set by isolation and evidence, and in a maximization context the same breadth can lift a defensible count rather than threaten it.
Oracle divides partitioning into hard and soft. Hard partitioning, using approved technologies, is accepted as a way to limit the processors that must be licensed. Soft partitioning, which includes VMware, is not. Oracle's stance is that software which can move across a virtualized environment must be licensed for everywhere it could run, not only where it happens to be running at a point in time. Because VMware clusters are built precisely so that virtual machines can move freely across hosts for resilience and balance, that mobility is exactly what Oracle points to when it counts.
The result at certification is that a single Oracle database on one virtual machine, sitting in a large unisolated cluster, can drag the processors of every host in that cluster into the count, and in some configurations the reach extends further across connected clusters. The count is no longer about where Oracle is. It is about where Oracle could go. This is the single most important thing to understand about virtualization at exit, because it can move the certified number, in either direction, by a very large margin.
It counts the reach of the environment, not the footprint of the database. When you certify, you declare deployed processors, and Oracle's interpretation of a soft partitioned VMware estate is that the deployment spans every physical processor the Oracle virtual machines can reach. If your clusters are large and interconnected, and nothing isolates Oracle to a defined boundary, the number Oracle expects can be far above the processors the databases actually use. The mechanics are the same whether this helps you or harms you. What changes is whether the breadth is something you want in the count or something you need to keep out of it.
On VMware, the count follows reach, not residence. Decide deliberately how wide you want that reach to be, then build the isolation and the evidence to match the decision. The boundary is an engineering and documentation choice you make before the window, not a debate you have at it.
The VMware rule cuts in opposite directions depending on your situation at exit, and the right move is the opposite in each.
Neither move is universally right. A heavily virtualized estate with growth ahead may benefit from a wide, well evidenced count that becomes permanent. An estate that is stable and wants a clean, narrow position may prefer strict isolation. The decision belongs to your goals and your roadmap, and it has to be made before the freeze and the measurement, because both isolation and a maximized footprint take time to put in place and evidence.
The table below shows how the boundary decision reshapes the count for an anonymized example. The figures are indicative and exist to show the logic, not to represent any real engagement, and the actual outcome depends entirely on the estate and the agreement.
| Configuration | Processors in scope | What drives it |
|---|---|---|
| Database footprint only | 120 | Hosts where Oracle actually runs |
| Unisolated cluster reach | 960 | Every host the VMs can move to |
| Isolated dedicated cluster | 240 | Defined, documented boundary |
| Maximized within term | 960 | Breadth captured as permanent entitlement |
Indicative only. The reach of a VMware count depends entirely on the cluster topology, the isolation in place, and the wording of the specific agreement. The point is the spread between the smallest and largest defensible numbers, which is why the boundary decision matters so much.
VMware is where the certified count can swing widest, and the boundary is decided by isolation and evidence set before the window, not by argument at it. Decide whether you are containing the reach or capturing it, then build the configuration and the documentation to match. See what records the position rests on in virtualization evidence Oracle will ask for, understand life after the letter in virtualization after certification, the new rules, and ground the approach in our ULA exit strategy guide.
Book a ULA assessment and we will map how your VMware estate counts, decide with you whether to isolate or maximize, and build the evidence that holds the boundary either way.