The single largest unbudgeted compliance exposure in the Oracle install base sits on VMware. Oracle's auditing position is that vSphere is soft partitioning, that vMotion eligibility expands licence scope to every host the VM could run on, and that recent vSphere features expand scope further across linked vCenter instances. The disagreement is loud, the audit pressure is real, and the architecture decisions that defuse it are well understood.
Oracle's "Partitioning" policy document — referenced in audit settlements for over a decade — lists which virtualization technologies count as hard partitioning. VMware vSphere is not on that list. Oracle's auditing position follows directly: every physical core in every host where the Oracle VM is configured to run, or could be migrated to via vMotion, requires an Oracle Processor licence. The licensed quantum is the cluster, not the VM.
VMware and a number of major customers have publicly disputed this reading, citing the absence of contractual language in standard Oracle ordering documents that explicitly extends scope to a cluster. Oracle's response has been consistent: the contract grants a licence to run the program; the program is running on whichever physical host the hypervisor allocates; therefore every host capable of being allocated requires a licence.
In practice, customers running Oracle on shared VMware clusters either negotiate a commercial settlement that prices in the cluster scope, redesign their architecture to isolate Oracle workloads, or accept ongoing exposure. The audit dispute itself rarely resolves through technical or contractual argument alone. Oracle's leverage in audit is the threat of headline-grossing claim numbers driven by the cluster reading; the customer's leverage is the ability to commit to architectural remediation that bounds future exposure. Pairing that remediation with disciplined Oracle license optimization is how the settlement number comes down rather than simply moving.
The defensible architecture exists; the path from today's footprint to that architecture is where the value sits.
Three boundary readings have appeared in Oracle audits over recent years, each more expansive than the last.
The traditional reading scopes Oracle licensing to every physical host in the vSphere cluster where the Oracle VM is configured to run. A 12-host cluster with 32 cores each requires licensing on 384 cores (192 Processor licences after core factor). This is the audit position most customers prepare for.
An expanded reading scopes licensing to every host under the same vCenter Server, on the basis that vCenter could initiate migration across clusters. Recent audit demands have invoked this reading against customers running vSphere 6.x or higher with cross-cluster migration enabled.
The most aggressive reading invokes vSphere Enhanced Linked Mode, vCenter HA, and the live migration features in vSphere 7 and 8 to scope licensing across linked vCenter instances — potentially across an entire datacentre or even datacentres. Customers have received audit findings on this basis. The defensibility of this reading is highly contested; the commercial pressure it creates is not.
vCenter logs vMotion events. Oracle LMS, in recent audits, has requested those logs as evidence of where the Oracle VM has actually run. A vMotion record showing the Oracle VM ran on a non-cluster host during a maintenance event has been used to extend the licence scope to that host. Customers preparing for an Oracle audit should understand what their vMotion history actually shows.
The VMware boundary, the audit precedents and the defensible remediation paths.
The most reliable defence is a physically separate VMware cluster, with its own vCenter or vCenter folder, dedicated entirely to Oracle workloads. Licensing scope becomes the cluster — knowable, bounded, and defensible. The downside is the loss of efficiency that drove VMware adoption in the first place: dedicated clusters often run at lower utilisation than shared infrastructure.
DRS affinity rules ("must run on" constraints, not "should run on") can confine an Oracle VM to a specified host group. The defensibility depends on the rule being a hard constraint Oracle accepts as binding, the enforcement being demonstrable through vCenter configuration and audit logs, and the host group being smaller than the cluster. Oracle has historically been reluctant to accept this configuration on its own, but the position has shifted somewhat over recent years.
The third pattern is to move Oracle workloads off VMware entirely — to bare metal, OCI, OCI Dedicated Region, AWS RDS for Oracle (with attendant licensing implications), Azure with appropriate hard partitioning, or IBM Power with LPAR. Each comes with its own licensing rules, but each removes the VMware cluster ambiguity from the audit conversation.
Broadcom's restructuring of VMware licensing — the shift from perpetual to subscription, the bundling of features into VMware Cloud Foundation, and the consolidation of product lines — has increased the total cost of ownership of VMware itself. For customers running Oracle on VMware, the combined effect is meaningful: VMware costs are rising at the same time Oracle is increasing scrutiny on virtualization scope. The economic case for dedicated Oracle infrastructure, or for migrating Oracle off shared VMware estates, has strengthened materially. See our VMware/Broadcom guide for the full picture.
The architecture decisions are interlinked with the contract decisions. Both need to be modelled together.
If Oracle on VMware is part of your estate and you have not modelled the audit exposure under current Oracle positions, that exercise is the highest-priority piece of compliance work most enterprises can do.
Our Oracle practice builds defensible architectures and runs settlement modelling on the cluster question.
Weekly compliance intelligence for IT leaders.
