A dedicated Oracle cluster with separate vCenter, storage, and network trades some consolidation efficiency for a fixed, defensible license footprint. This is the step-by-step containment architecture, the numbers that justify it, and the documentation that makes it hold at audit.
A dedicated Oracle cluster with separate vCenter, storage, and network trades some consolidation efficiency for a fixed, defensible license footprint. This is the step-by-step containment architecture, the numbers that justify it, and the documentation that makes it hold at audit.
Oracle classifies VMware as soft partitioning. That single classification means Oracle can, and routinely does, demand a license for every physical core in a VMware cluster where an Oracle database runs, not just the cores you assigned to the Oracle VMs. Oracle's Licensing Management Services (LMS) has held this position since roughly 2007, and the argument rests on vMotion: because a VM can, in principle, migrate to any host reachable through vCenter, shared storage, or a stretched network, Oracle asserts the software is installed and/or running on all of those hosts. You do not have to agree with the logic to be exposed to it.
The exposure is not academic. Across roughly 30 to 40 Oracle virtualization engagements our practice tracked between 2024 and 2025, soft-partitioned estates faced license claims a median 3.5 times the cores actually running Oracle. Opening audit claims that priced every host in every reachable cluster ran 4 to 10 times higher than a contained architecture would have justified. The reason to build a dedicated cluster is not to win a debate with Oracle about partitioning theory. It is to shrink the surface Oracle can lawfully argue over, so that even Oracle's most aggressive reading lands on a footprint you have already sized and budgeted.
Containment does not defeat the soft-partitioning rule. It accepts the rule and confines it to a footprint you sized on purpose.
The mechanics of the soft-partitioning position, and why vMotion and DRS let Oracle claim the whole cluster, are covered in the linked analysis. This page assumes you have accepted that Oracle will count the full physical core count of the cluster, and focuses on making that cluster as small, isolated, and documented as physically possible.
Understand the number before you design the architecture. Oracle Database Enterprise Edition lists at $47,500 per processor plus 22 percent annual support. On modern x86 hardware a core factor of 0.5 applies, and Oracle's January 2026 core-factor update pulled the entire current Intel Xeon server portfolio (69xxP, 67xxE, 67xxP, 65xxP, 63xxP and related series) into the 0.5 bucket. So the containment question is really: how many physical cores sit inside the boundary Oracle can reach?
| Cluster scope | Physical cores | Oracle processor licenses (0.5) | EE list value | Post-discount range (35-65% off) |
|---|---|---|---|---|
| 1 host, 2 x 16-core | 32 | 16 | $760,000 | $266K-$494K |
| 2 hosts, 2 x 16-core | 64 | 32 | $1,520,000 | $532K-$988K |
| 5 hosts, 2 x 20-core | 200 | 100 | $95,000,000 | $35M-$65M |
| 10 hosts, 2 x 32-core (shared estate) | 640 | 320 | $304,000,000 | $106M-$198M |
The five-host, 200-core example is the one Oracle's own worked examples use, and it is instructive: whether Oracle runs on one VM or fifty inside that cluster, the license requirement is 100 processor licenses. That is the whole point of containment. If you can hold the Oracle footprint to two hosts instead of letting it float across a ten-host shared estate, you are moving from a low seven-figure exposure to a nine-figure one. The gap between a contained and an uncontained architecture is not a rounding error. It is the difference between a manageable renewal and a bet-the-budget audit finding.
Options make it worse, because every option licenses on the same processor count. Partitioning lists at $11,500 per processor, Advanced Security at $15,000, Advanced Compression at $11,500, RAC at $23,000, In-Memory at $23,000, Active Data Guard at $11,500, Multitenant at $17,500, and Real Application Testing at $11,500. A fully optioned EE processor stack lists at $122,000 per processor with $26,840 in annual support. Multiply that by the core count Oracle can reach and the containment decision pays for itself many times over.
A defensible containment design requires triple separation: a dedicated cluster, a dedicated vCenter, and dedicated storage. Anything less leaves Oracle a technical argument that the boundary is porous. The definitive posture we recommend is physical and logical separation with no enhanced linked mode between the Oracle vCenter and the rest of the estate.
Build a cluster containing only Oracle database servers, sized to the smallest physical core count that meets performance and high-availability requirements. Every physical core in this cluster is fully licensed by design, so the cluster is a budget line, not an accident. Disable vMotion, DRS, and HA between this cluster and any non-Oracle infrastructure. Note that consolidating onto fewer, higher-core hosts under vSphere 8 can quietly inflate the count: a 64-core host licenses more than two 16-core hosts even if utilization is lower. See how vSphere 8 cluster consolidation widens the license count before you finalize host specifications.
The license boundary is version-dependent and has widened over time. On VMware 5.0 and earlier, the boundary was the cluster. On 5.1 through 5.5, it became every host under a given vCenter. On 6.0 and above, Oracle's argument extends to every host running that version of ESXi irrespective of vCenter. Because of this, a dedicated vCenter is necessary but not sufficient on modern versions. The practical countermeasure is to ensure the Oracle vCenter is not joined in enhanced linked mode, runs on separately-versioned hosts where feasible, and shares no management plane that would let a VM be migrated or cloned into unlicensed capacity.
Oracle treats storage visibility as a vMotion enabler. Shared datastores extend the boundary, and Layer 2 stretched networks across data centers extend it to every host on the stretched fabric. The isolation is therefore only real if the Oracle cluster has dedicated SAN LUNs or datastores that no other host can see, and its own network segment with no stretched Layer 2 reaching non-Oracle hosts. Strict network and storage boundaries are what actually prevent an Oracle VM from ever migrating to unlicensed capacity, which is the substance behind the containment claim. For the specific storage traps, review how storage vMotion and shared datastores silently expand scope.
Oracle does not recognize CPU pinning, host affinity rules, or DRS host groups as a license boundary. Physical storage and network separation is the only isolation Oracle cannot argue around.
Be precise about the failure modes. The Oracle Partitioning Policy does not recognize vSphere CPU pinning, host affinity rules, or DRS host groups as a license boundary. Teams that believe a DRS "must-run-on" rule protects them are usually wrong, and the belief is expensive. The policy document itself is explicit that it is for educational purposes only, is current as of February 14, 2022, and may not be incorporated into any contract. That cuts both ways: the policy is not contractual, but neither are the informal reassurances Oracle sales staff sometimes give. The only artefacts that matter at audit are your contract and your demonstrable technical configuration.
For a fuller treatment of what soft versus hard partitioning actually decides, and which technologies Oracle genuinely accepts (Oracle VM Server for x86, Oracle VM Server for SPARC LDoms, and Solaris Zones on Solaris 10 and later), see the Oracle Partitioning Policy explainer. VMware is not on that list, which is exactly why containment, rather than partitioning, is the VMware strategy.
There is a stronger path than the policy alone. A growing number of organizations add non-standard language to the Oracle Master Agreement through an amendment that formally ring-fences the Oracle-on-VMware environment. Oracle can also, in some cases, be persuaded to ascribe approved status to a segregation design using network and disk separation, though Oracle reserves the right to approve or not and will expect detailed architectural and technical submissions. If you are negotiating a renewal, a purchase, or an audit settlement, a contractual ring-fence is worth far more than a policy PDF, because it converts a contested technical position into an agreed contract term.
Oracle does not accept verbal assurances that vMotion is disabled. It requires technical evidence, and its audit scripts now harvest VMware topology automatically: LMS scripts read VMware Tools metadata, and the cluster map flows into the audit response by default. If your configuration is not documented and demonstrable, Oracle's automated topology view will define the boundary, and it will be the widest possible one.
Documentation is not a one-time deliverable. It must be refreshed quarterly and at every patch level change, because a single host added to the wrong cluster, or a datastore accidentally presented to a non-Oracle host, reopens the entire boundary. The complete artefact set is detailed in the evidence pack that defends a contained Oracle VMware estate at audit. The payoff is quantified: estates with dedicated Oracle clusters and documented migration boundaries settled the VMware question at 10 to 25 percent of Oracle's opening claim, while uncontained estates paid multiples of that. With average LMS audit findings running $4.2M per enterprise engagement, the documentation effort is among the highest-return work a licensing team can do.
Containment is not free. A dedicated cluster runs at lower average utilization than a shared estate because you cannot pack Oracle workloads alongside everything else. You buy dedicated hosts, dedicated storage, and a dedicated vCenter, and you accept some stranded capacity as the cost of a fixed license boundary. In our experience the operational overhead is real but modest relative to the license exposure it caps, typically a single-digit percentage of infrastructure cost against a license exposure that can run into the tens of millions.
| Dimension | Shared estate | Dedicated Oracle cluster |
|---|---|---|
| License scope | Every reachable host, often 4-10x actual usage | Fixed to the dedicated cluster's cores |
| Hardware utilization | High (mixed workloads) | Lower (Oracle only) |
| Audit settlement (observed) | Opening claim, 3.5x median inflation | 10-25% of opening claim |
| Documentation burden | Low until audited, then unwinnable | Quarterly, but decisive |
| Flexibility | vMotion anywhere | Migration confined by design |
The right comparison is not dedicated cluster versus shared estate. It is dedicated cluster versus the licensing bill Oracle will present when it maps your shared estate. Where the containment cost still feels high, the alternative worth pricing is leaving VMware entirely: see the 2026 cost comparison between staying on VMware and moving Oracle to OCI. And before anyone proposes licensing only some hosts as a shortcut, read the real answer on partial-cluster licensing, because that shortcut almost never survives contact with LMS.
Start from the number, not the diagram. Baseline the physical core count Oracle can currently reach across your estate, apply the 0.5 core factor, and price it at your negotiated discount to see the exposure you are carrying today. Then design the minimum-core dedicated cluster that meets your performance and HA needs, and model the contained exposure against it. The delta is your business case.
The strategic context, including how Broadcom's VMware pricing changes interact with all of this, sits in the Oracle Database on VMware after Broadcom exposure map. Read it alongside the general Oracle-on-VMware licensing guide before you commit hardware, because the cheapest containment architecture is the one you design before Oracle has your topology, not after.
Yes, but only the count within the boundary Oracle can reach. Oracle still licenses every physical core in the dedicated cluster, so the reduction comes from confining Oracle to a small, fixed cluster instead of a large shared estate. In observed audits, contained estates settled the VMware question at 10 to 25 percent of Oracle's opening claim.
No. The Oracle Partitioning Policy does not recognize vSphere CPU pinning, host affinity rules, or DRS host groups as a license boundary. Only physical separation of compute, storage, and network, with vMotion disabled across the boundary, holds up. Software-based pinning gives Oracle an easy argument that the boundary is porous.
On vSphere 6.0 and above, Oracle's argument can extend to every host running that ESXi version irrespective of vCenter, so a dedicated cluster alone is not sufficient. Use a dedicated vCenter with no enhanced linked mode, plus dedicated storage and network isolation. All three layers together are what make the containment defensible.
It depends on core count. A five-host cluster with two 20-core CPUs per host is 200 physical cores, or 100 Oracle processor licenses at the 0.5 core factor, with a list value near $95M before discounts of roughly $35M to $65M. A two-host, 64-core cluster is 32 licenses at a far smaller list value. The design goal is the minimum core count that meets your needs.
Sometimes. Some organizations add non-standard ring-fencing language to the Oracle Master Agreement through an amendment, and Oracle can occasionally approve a segregation design using network and disk separation. Oracle reserves the right to approve or not and expects detailed architectural evidence. A contractual amendment is worth far more than the policy PDF, which is explicitly non-contractual.
Oracle does not accept verbal assurances and requires technical evidence: exported vMotion, DRS, and HA settings, storage mapping showing dedicated LUNs, network topology, and a SAM record of the boundary. This must be refreshed quarterly and at every VMware patch change, because Oracle's audit scripts now harvest VMware topology automatically.
Oracle Exadata can lock you into full core licensing across X9M, X10M, and Cloud at Customer. The buyer side strategy to size the platform and cut the bill.
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.
