Oracle treats soft partitioning as no limit on licensing scope, so where the named product can run anywhere in a VMware cluster, Oracle's position is that the whole cluster is in scope. That sweep is an audit risk in normal operation, but inside a certification window the same rule can be turned into defensible entitlement.
By the Meridian advisory team, former Oracle LMS and GLAS licensing analysts. Updated 4 June 2026.
Under Oracle's partitioning policy, virtualization technologies such as VMware are treated as soft partitioning, which Oracle does not accept as a way to limit licensing scope. The practical consequence is that if an Oracle product can run on any host in a cluster, Oracle's position is that every physical processor in that cluster is in scope, not just the hosts the product happens to run on today. Because virtual machines can move between hosts by live migration, the scope extends further: clusters connected by shared storage and migration boundaries can be swept in together. So a single database virtual machine on one host can, in Oracle's view, put the processors of an entire cluster, and connected clusters, in scope. The boundary that matters is not where the product runs but where it could run.
Oracle scopes virtualization by where a product can run, not where it does. Soft partitioning does not contain it. Hard isolation, dedicated clusters, and documented boundaries are what limit the count, in either direction.
For most of a ULA term, the cluster sweep is a latent audit risk. After certification, audit attention rises, and an organisation that cannot show where its virtualized Oracle could and could not run is exposed to a finding that counts whole clusters against it. That is the defensive side, and isolation is the answer: dedicated clusters for Oracle, controlled migration boundaries, and documentation that proves the limits.
Inside the certification window the same rule flips. If a whole cluster is genuinely in scope and running the named product, those processors can be counted toward the certified number, and because support stays flat and certification carries no fee, they are free perpetual entitlement. A risk in normal operation becomes a lever during the exit. The discipline is the same in both directions: know exactly which clusters are in scope, prove it, and decide deliberately whether to isolate or to count. We connect this to the broader economics in the maximization context, and the worked numbers sit in the virtualization counting worked example.
The first question is reach. Which hosts can the Oracle virtual machine run on, by configuration and by live migration? Every host within that reach is, in Oracle's position, in scope. Mapping reach precisely is the foundation of any count or defence.
Clusters joined by shared storage or live migration can extend scope beyond a single cluster. Knowing where those boundaries actually stop, and controlling them, is what keeps scope from expanding silently across a virtual estate.
Hard isolation, running Oracle on dedicated hosts or clusters with controlled migration, is the recognised way to limit scope. The same isolation that defends against an over broad sweep also defines, cleanly, the cluster you choose to count when maximization is the goal. Different hypervisors handle this differently, which we cover in Hyper V and other hypervisors at certification.
Take an indicative case. An organisation runs a single Oracle database virtual machine on a VMware cluster of eight hosts, each with two processors, all reachable by live migration. Under Oracle's position, the cluster in scope is not the one host the database sits on but all eight, which is 16 processors before the core factor. If a second cluster of four hosts shares storage and migration with the first, scope can extend to 24 processors. In a defensive setting that is exposure to manage with isolation. In a certification setting, where the organisation genuinely uses that capacity, those 24 processors can be counted toward the number at no marginal cost. The figures are indicative, and the actual scope depends on configuration and contract, but the point is that the cluster, not the host, is the unit Oracle counts.
| Scope question | Defensive answer | Maximization answer |
|---|---|---|
| Whole cluster in scope | Isolate to limit it | Count it if genuinely used |
| Connected clusters | Control migration boundaries | Count where in scope and used |
| Evidence | Prove the limits | Prove the count |
Whether a cluster is in scope, and whether counting or isolating is the right move, depends on your configuration and contract language, so treat this as the framework to apply rather than a fixed answer.
The VMware cluster rule is one of the most consequential mechanics in a ULA exit, because it can move a count by whole clusters in either direction. The work is to map scope precisely, document it, and decide deliberately whether each cluster is isolated to limit exposure or counted to build entitlement. Both decisions rest on the same evidence. The full method, with the rest of the virtualization cluster, lives in our pillar, the ULA exit strategy guide.
Oracle scopes virtualization by where a product can run, so a whole VMware cluster, and connected clusters, can count, not just the host the database sits on. That sweep is an audit risk in operation and a lever at certification. Map the reach, control the migration boundaries, document everything, and decide cluster by cluster whether to isolate or to count. The rule is the same. The intent is what changes.
Under Oracle's partitioning policy, soft partitioning does not limit licensing scope, so where an Oracle product can run on any host in a cluster, Oracle's position is that every processor in that cluster, and connected clusters reachable by live migration, is in scope. Isolation and dedicated clusters are what limit it.
Yes. The same rule that creates audit exposure can lift a certified count. If a whole cluster is genuinely in scope and running the named product, those processors can be counted toward certification at no marginal cost, turning a risk into defensible perpetual entitlement when handled with evidence.
Book a confidential assessment and we will map your virtualized estate so you can isolate to limit risk or count to build entitlement.