Why VMware drives the biggest findings
The Oracle VMware audit is the single most financially dangerous scenario in Oracle compliance, because the multiplier between what the customer believes it must license and what Oracle claims it must license is larger here than anywhere else. A customer running Oracle Database on a few hosts inside a large VMware environment may reasonably expect to license those hosts. Oracle, applying its soft partitioning policy, may instead assert that every host in the cluster, and sometimes every host in every cluster the virtualisation platform can reach, must be fully licensed. The difference can be an order of magnitude or more.
This is why virtualisation findings dominate the largest audit settlements. The technology makes Oracle workloads mobile, capable in principle of running on many hosts, and Oracle's policy seizes on that mobility to argue that potential runtime, not actual runtime, is the basis for licensing. A finding built on this argument can dwarf the customer's actual usage, and a customer that does not understand or contest the argument can face a demand wildly out of proportion to what it is genuinely running.
The good news is that the VMware argument, precisely because it is so aggressive, is also one of the most disputable. It rests on an Oracle policy document rather than on most customers' contract terms, and that distinction, policy versus contract, is the fulcrum of the defence. This article explains the policy, contrasts it with the contract, and sets out how to defend, drawing on the technical detail in the database VMware licensing guide and the soft partitioning guide.
Oracle's soft partitioning policy
Oracle classifies partitioning technologies as either hard or soft. Hard partitioning, in Oracle's view, physically limits the processors available to a workload in a way Oracle accepts as bounding the licence requirement. Soft partitioning, which in Oracle's classification includes VMware, does not, in Oracle's view, bound the requirement, because the workload could be moved to other processors. On that reasoning, Oracle's policy holds that all processors on which the Oracle software is installed or running, or could be installed or run, must be licensed.
Applied to VMware, this policy becomes expansive. Because features such as live migration allow a virtual machine to move between hosts, Oracle argues that every host the VM could migrate to is a host where Oracle could run, and therefore must be licensed. As VMware management constructs have evolved to allow workloads to move across larger boundaries, Oracle's claimed scope has expanded with them, sometimes reaching beyond a single cluster to any host the management layer connects. The result is the whole environment licensing demand that defines the VMware audit.
Oracle prices the VMware environment on what could run, not on what does run. The entire defence turns on insisting that the contract licenses installed and running software, not theoretical mobility.
It is essential to be precise about the status of this policy. It is set out in an Oracle document about partitioning, which Oracle treats as authoritative, but which is, in most cases, not incorporated as a term of the customer's signed agreement. That gap between an Oracle authored policy and the contract the customer actually signed is not a technicality; it is the legal heart of the dispute, as the next section explains.
Policy versus the contract
What the customer owes is determined by its contract, not by an Oracle policy document, and most Oracle agreements define the licence requirement in terms of the processors on which the programs are installed and or running. They do not, as a rule, contain language requiring the customer to license processors where the software might theoretically run in future. The soft partitioning policy supplies that expansive reading, but if the policy is not incorporated into the agreement, the customer has a strong basis to argue that the contract's own definition, installed and running, governs instead.
This is why the first step in any VMware defence is to read the governing agreement closely, exactly as the audit clause guide counsels for audits generally. The customer looks for how the metric is defined, whether the partitioning policy is referenced or incorporated, and what the agreement actually says about installed versus potential use. In many contracts the policy is conspicuously absent from the binding terms, which means Oracle is asserting a requirement the customer never agreed to. The dispute then becomes a contest between Oracle's policy assertion and the contract's plain definition, and the contract is the higher authority.
None of this means the VMware position is risk free, because outcomes depend on the specific wording and on the customer's willingness to hold its ground. But it does mean the whole cluster claim is contestable rather than settled, and customers who understand the policy versus contract distinction routinely resist demands that, taken at face value, would have been ruinous. The argument is strongest when paired with the architectural steps described below.
Defending a VMware audit
Defending a VMware finding combines the contractual argument with technical evidence and disciplined process. The table below sets out the layers of the defence and what each contributes.
| Layer | What it establishes | How it limits the claim |
|---|---|---|
| Contract definition | Licensing is by installed and running processors | Removes the policy based whole cluster argument |
| Architectural isolation | Oracle workloads confined to defined hosts | Eliminates the credible could run elsewhere claim |
| Configuration evidence | Proof of host affinity and boundaries | Demonstrates isolation as fact, not intention |
| Scope and data control | Audit limited to in scope hosts and data | Prevents the audit mapping the entire estate |
The contractual argument supplies the legal basis; the architectural and configuration evidence supplies the factual basis that there is no realistic way Oracle could run beyond the licensed hosts. Together they convert the dispute from Oracle's abstract could run anywhere claim into a concrete, bounded position the customer can prove. Scope and data control, drawn from the broader audit defence pillar, ensure the audit does not quietly map the whole virtual estate in the course of measuring the in scope hosts, since that map is exactly what fuels the expansive claim.
Process discipline matters as much here as anywhere. The customer should provide data only for the in scope hosts, resist requests that would expose the full virtualisation topology unless contractually required, and require Oracle to ground its claim in the agreement rather than the policy. Each of these is harder to do well under audit pressure than it sounds, which is why VMware findings are a frequent reason customers engage specialist support through the Oracle audit defence service, with the full method documented in the audit defence white paper.
How do you isolate Oracle on VMware?
The most durable protection against the VMware cluster claim is architectural isolation, designed in before any audit rather than retrofitted under pressure. The principle is to confine Oracle workloads to a defined, bounded set of hosts that are separated from the rest of the VMware estate, so that there is no credible technical argument that Oracle could migrate elsewhere. This can be achieved by running Oracle on dedicated physical hosts, on a dedicated cluster with no migration path to other clusters, or through enforced host affinity that demonstrably restricts where Oracle VMs can run.
The key word is demonstrably. Isolation that exists only as an intention or an informal practice is weak, because Oracle can argue the boundary is not real. Isolation that is enforced by configuration and evidenced by records, host affinity rules, network and storage separation, management boundaries, change controls, is strong, because the customer can prove that Oracle was confined to the licensed hosts as a matter of fact. The technical patterns for achieving this are set out in the database VMware licensing guide and the soft partitioning guide.
Isolation also has to keep pace with the virtualisation platform. As VMware management features evolve to allow workloads to move across wider boundaries, an isolation design that was sound under an older architecture can be undermined by a platform upgrade that quietly widens the migration domain. A customer relying on isolation should therefore review it whenever the virtualisation environment changes materially, treating the boundary as something to be maintained rather than set once and forgotten.
The buyer side view
The VMware audit is where the largest Oracle findings are born and also where the most ground can be recovered, because the demand rests on a policy stance rather than on most customers' contract terms. Oracle prices what could run; the contract licenses what is installed and running; and the space between those two is the entire battlefield. The customer who reads the agreement, insists that the contract governs over the policy document, and backs that argument with demonstrable architectural isolation can resist demands that, accepted uncritically, would have been catastrophic.
Treat virtualisation as the highest stakes issue in your Oracle estate. Architect Oracle workloads into bounded, evidenced isolation, keep that isolation current as the platform evolves, and meet the whole cluster claim with the contract rather than conceding to the policy. Build the technical foundation with the database VMware licensing guide and the soft partitioning guide, and place the defence inside the full process in the audit defence pillar.
Oracle's policy position is that VMware is soft partitioning and that all hosts where an Oracle workload could run, potentially across connected clusters, must be licensed. This is a policy stance, not a term in most contracts. Whether it is enforceable depends on the agreement; the contract, not the policy document, governs what the customer actually owes. Usually not directly. The soft partitioning policy is an Oracle document referenced in guidance rather than a clause in the signed agreement. Customers frequently dispute its application on the basis that their contract defines licensing by installed and running processors, not by where a workload could theoretically migrate. The strength of the position depends on the specific contract wording. The most robust approach is architectural: isolate Oracle workloads onto dedicated hosts or clusters that are physically or technically separated from the rest of the VMware estate, so there is no credible argument that Oracle could run elsewhere. Combined with clear evidence of that isolation, this removes the basis for Oracle's whole cluster claim.Oracle VMware audit: frequently asked questions
Does Oracle require licensing the whole VMware cluster?
Is Oracle's VMware partitioning policy contractually binding?
How do you limit Oracle licensing on VMware?