The VMware Sweep Defense Guide

VMware is the single most expensive misunderstanding in an Oracle Unlimited License Agreement exit. Most teams assume a virtual machine boundary, or a cluster boundary, limits what Oracle can count toward a certification. Oracle's stated position is the opposite, and the distance between those two views is measured in processor licenses. In a certification that distance is the difference between a count you can defend and a remediation demand that arrives after the letter is signed.

We are an independent advisory. We hold no Oracle quota, we are not a reseller, and we sit on the buyer side of the table. This guide sets out the partitioning rule in plain terms, the architecture that contains it, the evidence file that makes your number hold, and the way the same mechanics can work for you when you are maximizing a count rather than defending one. Every figure here is indicative and the answer in any real estate depends on the exact wording of your agreement and the shape of your architecture.

What is Oracle's partitioning stance, and why does it matter at certification?

Oracle divides partitioning into two categories. Hard partitioning is a method Oracle recognises as limiting the number of processors that must be licensed. Soft partitioning is a method Oracle does not recognise for that purpose, so it does not limit the scope of what must be licensed. VMware vSphere sits in the soft partitioning category under Oracle's policy. The practical effect is that the unit of counting can become every physical host where an Oracle database could be made to run, not only the host or the virtual machine where it does run today.

At certification this stance turns a quiet architectural choice into a commercial one. You certify the quantity of each named product deployed during the term. If Oracle's reading of your VMware estate is that the database could run across a whole cluster, the argument it brings to the table is that the whole cluster is the deployment. The reach can extend further still, because vMotion and shared storage can connect clusters, and a permissive design can let Oracle argue that several clusters form one large pool. The rule is the same in every version of the policy: soft partitioning does not cap scope, so the architecture and the evidence are what set the boundary.

How far can a VMware cluster sweep reach?

The reach is set by where Oracle can argue the database is able to run, not by where it is running on the day of the count. A single licensed virtual machine on a shared cluster invites the argument that every host in that cluster is in scope. Shared storage and live migration between clusters invite the argument that the connected clusters are in scope as well. The worked example below shows how quickly a small intended footprint becomes a large claimed one.

The figures are indicative and use a representative 0.5 core factor for current Intel and AMD server processors. The point is the multiple, not the exact number. An unisolated design can turn a 16 processor expectation into a 256 or 512 processor argument. Whether that argument helps you or hurts you depends entirely on which side of the certification you sit. During the term, when you are building the largest defensible certified count, breadth that you genuinely run is value you keep for free. After certification, in an audit, breadth that you cannot evidence is exposure that turns into a license purchase demand.

What is the difference between soft and hard partitioning?

The distinction is the whole game. Soft partitioning is any method that, in Oracle's view, can be reconfigured to let the software run on more processors than were allocated to it. Hard partitioning is a method Oracle accepts as physically fixing the processors available to the software, so only those processors need to be licensed. The table below sets out where common methods fall under Oracle's policy. Treat it as a map of the terrain, not as a substitute for reading your own contract, because some agreements vary the treatment and the policy is a document Oracle can revise.

The lesson the table teaches is that you do not beat the soft partitioning rule by arguing about it. You beat it by removing the ability for the database to run anywhere you have not chosen, and by holding the evidence that proves it. For the deeper mechanics, read hard partitioning versus soft partitioning, which sets out exactly which methods Oracle accepts and how each must be configured.

How do you defend against a cluster sweep?

The defense is architectural first and evidential second. The aim is to make it factually true, and provable, that the database can only run on the processors you intend to license. Four moves carry most of the weight, and they compound: the more of them you can show together, the harder the sweep argument becomes to sustain.

Isolate the Oracle estate

Place every Oracle database on hosts that are reserved for Oracle workloads and separated from the general virtual estate. Isolation removes the foundation of the sweep, because a host that has no path to run the database cannot be argued into the count. The separation has to be real and continuous, not a setting that was applied for the audit and removed afterward.

Build dedicated clusters

A cluster used only for Oracle, with no shared storage path and no live migration route to non Oracle hosts, confines the countable estate to that cluster. The dedicated cluster is the most widely accepted boundary in practice because it is simple to describe, simple to evidence, and hard to argue around. Read dedicated clusters as a defense for the build pattern and the configuration that holds up.

Use hard partitioning where it fits

Where the platform supports a method Oracle recognises as hard partitioning, and it is configured exactly to Oracle's published rules, the scope is fixed to the bound cores. Hard partitioning is powerful but exacting. A configuration that is almost right is treated as no partitioning at all, so it has to be documented precisely and maintained.

Hold the documentation

Architecture without evidence is an assertion, and an assertion does not survive an audit. The documentation is the cluster topology, the host inventory, the storage and migration boundaries, the configuration that enforces the isolation, and a record that the design was in place throughout the relevant period. The evidence file is what converts a sound architecture into a defensible number.

When does the VMware rule work in your favour?

The same partitioning stance that creates audit exposure becomes an opportunity during the term. Because a ULA grants unlimited deployment, the breadth of a cluster that genuinely runs Oracle can support a larger certified count, and a larger certified count is free perpetual entitlement. There is no fee to certify, and support does not rise with the certified number, so a defensible high count is value retained rather than cost incurred.

The discipline is that the breadth must be genuine and must be deployed within the term. Maximization is not inventing deployment that was never there. It is making sure that every host where Oracle was actually running during the agreement is measured, evidenced, and counted, including the clusters where soft partitioning means Oracle would otherwise count them against you. The same evidence file that defends against a sweep in an audit supports a larger legitimate number at certification. The rule does not change; the side of the table does.

What changes after certification?

Once the certification letter is signed, the unlimited right ends and your entitlement is fixed at the certified count. The VMware question does not retire with it. Audit risk rises in the first two years after certification, and virtualization is one of the first places an Oracle review looks, because the soft partitioning argument is well rehearsed and the estate is often the same one that was just measured. Growth beyond the certified count that lands on a shared cluster reopens every sweep argument, this time with no unlimited right to absorb it.

The defense after exit is the same architecture and the same evidence file, maintained rather than rebuilt. Keep the isolation continuous. Keep the documentation current as hosts are refreshed and clusters are rebalanced. Buy new licenses deliberately when you grow, and place that growth on the isolated estate so it does not drag a wider cluster into scope. The certification is the start of the discipline, not the end of it. For the full runway from notice to a defensible exit, read the ULA exit strategy guide.

A worked defense, step by step

The following sequence is how we run a VMware position in a certification, whether the goal is to defend a number or to maximize one. The order matters, because the architecture has to be settled and evidenced before the count is built.

1. Map the estate. Inventory every host, cluster, datastore, and migration boundary, and mark every place an Oracle database runs or could run.
2. Read the contract. Confirm how your specific agreement treats virtualization, partitioning, and the definition of deployment, because some agreements vary the policy.
3. Decide the posture. Choose, product by product, whether you are confining the estate to defend a count or accepting breadth to maximize one.
4. Isolate and configure. Build dedicated clusters or apply recognised hard partitioning so the database can run only where you intend, and apply the change well before the count.
5. Evidence the boundary. Capture the topology, configuration, and a record that the design held throughout the period, so the boundary is provable and not merely asserted.
6. Build the count. Measure the in scope processors with the correct core factors and assemble the methodology behind the number.
7. Document for the file. Hold everything together as the evidence file that supports the certified count and defends it in any audit that follows.

The pre certification VMware checklist

Use this as the cover sheet for your own VMware position before you certify. Each item is a place where the sweep is won or lost, and each one should be evidenced rather than assumed.

1. Host and cluster inventory complete, with cores and core factors recorded.
2. Migration and storage boundaries mapped, so every path the database could take is known.
3. Oracle estate isolated onto dedicated hosts with no route to the general estate.
4. Dedicated clusters or hard partitioning in place and configured to the recognised rules.
5. Isolation continuity evidenced across the relevant period, not just on the day of the count.
6. Contract treatment of virtualization read and reconciled against the architecture.
7. Posture decided per product, defend or maximize, with the reasoning recorded.
8. Evidence file assembled so the boundary and the count are both provable.

The next step

The VMware position is decided by architecture and proven by evidence, and both have to be settled before the certification window closes. If you would like your cluster exposure mapped and your defense or maximization built with you, on your estate and your contract, that is the work we do. For the wider exit in context, read the ULA exit strategy guide, and for the partitioning mechanics in depth, read hard partitioning versus soft partitioning and dedicated clusters as a defense.