Oracle treats storage reachability as migration capability, so a shared SAN can drag unlicensed hosts into the claim even when compute is isolated. This page shows where the storage trap sits and the exact segregation steps that hold the boundary at audit.
Oracle treats storage reachability as migration capability, so a shared SAN can drag unlicensed hosts into the claim even when compute is isolated. This page shows where the storage trap sits and the exact segregation steps that hold the boundary at audit.
Most buyers who have fought an Oracle VMware claim understand the compute-side argument: enable vMotion and DRS in a cluster, and Oracle asserts the database could run on any host, so every physical core in the cluster must be licensed. That is the vMotion and DRS argument, and it is well documented. What far fewer buyers plan for is the storage layer, where Oracle runs a parallel and often broader claim. The vendor treats storage visibility as a vMotion enabler. If a datastore holding Oracle volumes is presented to a host, Oracle argues that host is a candidate to run the software, and therefore a candidate to be licensed.
This matters because storage zoning and datastore presentation are usually managed by a different team than the vSphere cluster configuration, and often by people with no knowledge of Oracle's licensing rules. You can build a tightly contained compute cluster and still leak the boundary through a SAN that a storage administrator mapped for convenience three years ago. The result is a claim priced against hosts you never intended to run Oracle on. In our engagements, soft-partitioned estates faced claims a median 3.5 times the cores actually running Oracle, and the storage boundary is one of the quiet drivers of that inflation.
Oracle treats storage visibility as a vMotion enabler. A datastore mapped for convenience becomes a licensing claim.
The history matters because Oracle's auditors still lean on both the old and the new version of the argument depending on which one produces the larger number. In older VMware releases (vSphere ESXi up to 5.0), shared storage was a hard requirement for VM mobility. Oracle software sat on shared storage, and the entire cluster or clusters connected to that shared storage had the technical ability to run it. Oracle's position was, and remains, that you must license all the physical cores of the ESXi hosts in the cluster connected to that shared storage. That was a storage-driven boundary in the literal sense: no shared storage, no migration.
Then vSphere 5.1 decoupled VM mobility from shared storage, and counterintuitively this made Oracle's claim more expansive, not less. Once movement no longer required shared storage, Oracle's argument became: if Oracle runs in a vCenter, any host in that vCenter that could receive the VM via vMotion must be licensed, regardless of storage. Shared storage stopped constraining movement, so Oracle simply assumed every host under the vCenter was in scope. The storage argument did not disappear. It became an additional reachability test layered on top of the compute test.
vSphere 6.0 and later pushed this further by extending the cluster boundary across data centers when Storage vMotion is enabled. Oracle's auditors treat that wider boundary as the licensable pool. vSphere 7 introduced enhanced cross vCenter vMotion without enhanced linked mode, and this is where the silent expansion lands: a network or DR administrator enables the feature for disaster recovery, with no Oracle infrastructure knowledge, and the license boundary quietly widens across vCenters. Nobody in the Oracle team touched anything, yet the audit surface grew.
Oracle's contractual hook for the storage argument is thin, and you should know exactly how thin. Recent versions of the Oracle Software Investment Guide introduced this paragraph: "When deploying on shared storage devices, standard-licensing policies applies. All processors where the Oracle programs are installed and/or running need to be licensed." The Software Investment Guide is a policy document, not a contract. It is not incorporated into your Oracle Master Agreement or Ordering Document unless you signed something that references it, which almost nobody has.
The two sentences sit deliberately close together, and the proximity is designed to imply full-cluster licensing even though the text does not actually say it. Read literally, the second sentence supports Oracle's own actual contractual metric: license processors where the programs are installed and running. That is the buyer-side reading, and it is the correct one. The auditor will read "shared storage devices" plus "all processors" and assert that every host with a path to the datastore is in scope. Your job is to refuse to concede that the policy language changes what your signed contract says. It does not.
The Software Investment Guide is policy, not contract. Do not let a proximity of two sentences rewrite your Ordering Document.
Across our audit-defense work, a small set of storage-specific findings account for a large share of the over-claim. These are the items an Oracle auditor asks for early, because they are easy to obtain and hard for an unprepared buyer to explain away.
The reason storage segregation deserves board-level attention is arithmetic. Consider a 5-host VMware cluster, each host with two 20-core Intel processors. That is 200 physical cores. At the Intel core factor of 0.5, Oracle counts 100 processor licenses for Oracle Database Enterprise Edition, whether Oracle runs on 1 VM or 50. At 2026 list pricing that is roughly $95M in list value. Even with typical enterprise discounting of 40 to 70 percent, the settled number lands somewhere between $35M and $65M, and that is before the option stack. Now imagine the storage argument dragging in a second five-host cluster that shares the SAN. You have just doubled the exposure with zero change to what actually runs Oracle.
| Component | 2026 list price per processor | Notes |
|---|---|---|
| Oracle Database Enterprise Edition | $47,500 | Base license; 22% annual support ($10,450) |
| Partitioning option | $11,500 | Added per processor on top of EE |
| Real Application Clusters (RAC) | $23,000 | Added per processor |
| Intel core factor | 0.5 | Each physical core counts as 0.5 processor license |
| Typical negotiated discount | 40% to 70% | Routine at volume; not contractual |
The claim inflation is well benchmarked. Opening claims that price every host in every reachable cluster typically inflate the position 4 to 10 times over a contained architecture. The good news for buyers who prepare: estates with dedicated Oracle clusters and documented migration boundaries settled the VMware question at 10 to 25 percent of the opening claim. Storage segregation is a direct input to which end of that range you land on. For the wider financial picture across compute and storage, see the 2026 licensing exposure map.
Storage isolation is a distinct engineering task from compute isolation, and both are required. A dedicated Oracle cluster that shares a SAN with the rest of the estate is not contained; it is a compute island floating on a shared storage sea, and Oracle will point at the sea. The principle is simple: hold Oracle data on dedicated storage so that Storage vMotion and datastore reachability cannot extend past the licensed hosts.
These steps are the storage half of a proper containment design. The compute half, cluster boundaries, DRS affinity, and cross-vCenter controls, is covered in the dedicated Oracle VMware cluster design. Do not treat these as alternatives. Attempting to license only some hosts while leaving the SAN shared is one of the more expensive mistakes we see, and we address why in the partial cluster licensing analysis.
Architecture without evidence loses at audit. Oracle's auditor will not take your word that the SAN is isolated; the burden falls on you to demonstrate it with contemporaneous records. The required storage artifacts are specific: storage zoning records showing datastores presented only to Oracle-dedicated hosts, LUN masking configuration, and a dated topology that ties each Oracle datastore to the licensed cluster only. These belong in a single, timestamped bundle you can hand over on day one of a review.
Assemble this before you are audited, not during. The full artifact set, covering storage zoning, cluster configuration, migration boundaries, and the topology file, is set out in the evidence pack for a contained Oracle VMware estate. If you cannot produce a storage zoning record on demand, Oracle will assume the worst-case reachability and price accordingly. The evidence is what converts a technical control into a negotiating position.
There is a cost tension buyers must plan around. Storage segregation often means building a smaller, dedicated Oracle cluster, and under Broadcom's VMware Cloud Foundation model that is now more expensive per host. VCF is licensed per physical core on subscription only, with a 16-core-per-CPU minimum, a 72-core minimum order since April 2025, and a 2026 list price near $350 per core per year (roughly $185 to $275 per core after discount). The 72-core minimum penalizes small dedicated Oracle clusters: a modest two-host isolation cluster can trip the minimum and you pay for cores you are not using.
Run the trade-off deliberately. The incremental VCF cost of a small dedicated Oracle cluster is almost always trivial against the Oracle over-claim it prevents (recall the tens of millions in the worked example above). Do not let a storage or VMware administrator reject segregation on VCF cost grounds without seeing the Oracle number it avoids. The broader Broadcom audit dynamics sit in the guide to audit risks under Broadcom VMware licensing, and if the numbers push you toward exit, weigh them against the VMware versus OCI cost comparison.
Treat storage as a first-class scope risk, equal to vMotion. Pull your datastore zoning and LUN masking configuration today and confirm no Oracle datastore is presented to a non-Oracle host. Remove Oracle templates and binaries from any shared array. Confirm cross-vCenter and cross-datacenter Storage vMotion is disabled unless it is deliberately confined to licensed hosts. Then bundle the zoning records into a dated evidence pack. If your review of the topology surfaces shared storage you cannot immediately remediate, get buyer-side advice before Oracle does, because the difference between a documented boundary and an assumed one is the difference between settling at 10 to 25 percent of the opening claim and paying the full inflated number.
Oracle's audit position treats storage reachability as equivalent to migration capability. If a datastore holding Oracle volumes is presented to a host, Oracle argues that host could run the software and must be licensed. Note this is Oracle's policy stance, not what your signed contract requires, which is to license processors where the programs are installed and running.
No. The Software Investment Guide is an Oracle policy document, not part of your Master Agreement or Ordering Document unless you signed something referencing it, which is rare. The line about shared storage devices does not override your contract's actual metric. Treat it as a negotiating tactic, not a binding rule.
No. A dedicated compute cluster on shared storage is not contained. Oracle will point at the shared SAN and argue reachability into the rest of the estate. Complete containment requires both compute isolation and dedicated, non-shared storage for Oracle VMs, templates, and binaries.
vSphere 6.0 and later extend the cluster boundary across data centers when Storage vMotion is enabled, and Oracle's auditors treat that wider boundary as the licensable pool. vSphere 7 enhanced cross vCenter vMotion can be switched on for disaster recovery by a network admin with no Oracle knowledge, silently widening the scope. Confirm these features are disabled or confined to licensed hosts.
You need storage zoning records and LUN masking configuration showing Oracle datastores are presented only to the Oracle-dedicated cluster, plus a dated topology tying each datastore to the licensed hosts. Assemble this before any audit, because the burden of proving isolation falls on you. Without it, Oracle assumes worst-case reachability.
Yes, marginally. Broadcom's VCF is per-core subscription with a 72-core minimum order since April 2025, so a small isolation cluster can trip the minimum. However, that incremental cost is trivial against the Oracle over-claim segregation prevents, which routinely runs into tens of millions. Run the trade-off with both numbers on the table.
Oracle GoldenGate is licensed per processor on source and target, doubling the count. List prices, the option stack, and the buyer side defense in one paper.
Gated with a work email on the download page. No sales follow up you did not ask for.
Get the White Paper →
500+ enterprise clients. 11 vendor practices. Industry recognized. One conversation can change what you pay for the next three years.
One buyer side briefing a week. Renewal signals, audit moves, and the levers that work. No vendor spin.
