Oracle on VMware. After Broadcom.

Oracle still treats VMware as soft partitioning, and that claim still lives in policy rather than your contract. What changed is the VMware side: per core subscriptions and order minimums have repriced the containment decision underneath it.

What did Broadcom actually change, and why does it reach Oracle?

Broadcom replaced VMware's per socket perpetual licensing with per core subscription bundles, and that single change made the core count the shared unit of both bills. Oracle already counted cores. Now Broadcom does too.

The portfolio collapsed into a small number of bundles built on VMware Cloud Foundation and vSphere Foundation, with the smaller vSphere editions retained for entry estates.

The four structural changes that matter for an Oracle estate

• Subscription only. Perpetual licensing ended for new purchases, so the VMware line item became an annual operating cost with a renewal you cannot skip.
• Per core, not per socket. Dense servers that used to be a bargain under socket pricing are now the expensive option on both the VMware and the Oracle side.
• Minimums. A minimum core count applies per CPU, and a minimum quantity applies per subscription order. Small clusters do not buy small.
• Bundling. Buying vSphere alone became harder, so many estates now pay for storage and networking capability the Oracle cluster will never use.

There is a fifth change that is commercial rather than structural. Support renewal enforcement tightened sharply, and disputes over support for existing perpetual licenses became public litigation during 2024.

Why Oracle account teams enjoy this

Oracle sales has used the Broadcom disruption as a reason to bring you onto Oracle's own stack. The pitch is that Oracle Linux KVM, Exadata or OCI remove both the VMware bill and the partitioning argument in one move.

Half of that is true. The partitioning argument really does disappear on Oracle's approved platforms, and it really does not disappear on any competing hypervisor. What the pitch omits is the switching cost and the lock in it creates.

Broadcom repriced the platform. Oracle repriced nothing, and collected the benefit of the confusion anyway.

Why does Oracle still treat VMware as soft partitioning?

Because VMware is not on Oracle's named list of approved hard partitioning technologies, and membership of that list is the only test Oracle applies. Nothing Broadcom did changed that, and nothing Broadcom could do would change it.

The rule does not appear in your ordering document or master agreement. It lives in a separate Oracle Partitioning Policy that Oracle itself labels as educational and expressly states may not be incorporated into any contract.

• Contract: defines the metric, the core factor, and the programs you actually bought.
• Policy: states how Oracle would like to count virtualized environments.
• Gap: the policy is an opening position, and opening positions are negotiable.

Read that footer honestly in both directions. It is not binding on you, and Oracle's audit teams apply it uniformly regardless, so the practical question is what evidence you can put in front of it.

Where the rule comes from

The conversion from physical cores to licenses sits in the Oracle Processor Core Factor Table, which applies on premises and gives current x86 server parts a 0.5 factor. The processor metric itself is defined in the Oracle pricing and licensing documents.

That 0.5 factor is worth naming, because it does not travel. Move the same workload to AWS or Azure and the core factor stops applying entirely, which is covered in Oracle Database licensing on AWS.

How does the cluster math work when both vendors count cores?

Start from the cores actually running Oracle, then price the same cores twice: once as a Broadcom subscription, once as Oracle processor licenses. The second number is one to two orders of magnitude larger, and that ratio drives every decision on this page.

The vCenter expansion argument

From vSphere 6.0 onward, vMotion can move a virtual machine across linked vCenters. Oracle uses that capability to argue the whole estate is in scope, even where no Oracle machine has ever run on a given host.

• Capability is not usage, and placement logs prove where workloads actually ran.
• Storage visibility on its own does not create a license liability.
• Documented affinity rules and a separate vCenter narrow the realistic boundary.
• Broadcom's bundle consolidation encourages fewer, larger clusters, which widens the argument. Resist that default for Oracle.

That last point is the quiet Broadcom effect on audit risk. Consolidating to fewer, denser clusters improves your Broadcom economics and worsens your Oracle exposure, and nobody in the platform team is measured on the second one.

Does a dedicated Oracle cluster still pay after Broadcom repricing?

Yes, and the margin is not close. The VMware subscription on an isolated Oracle cluster is a rounding error against the Oracle exposure it removes, even at the top bundle price.

The arithmetic on a real sized cluster

Take three hosts, two sockets each, 16 cores per socket. That is 96 physical cores, licensed on the Broadcom side per core and counted on the Oracle side at the 0.5 x86 core factor.

The VMware subscription on 96 cores lands in the low tens of thousands of dollars a year at published bundle rates. The Oracle support line alone on the same cores is roughly ten to forty times that number.

The comparison that matters is the right hand column. Isolation removes about 6.8 million dollars of list exposure and about 1.5 million dollars a year of support, for a VMware cost that does not change the sign of the answer.

What the Broadcom change actually costs you

The cost of containment after Broadcom is not the license fee, it is the stranded capacity. A dedicated Oracle cluster must be sized for peak with a failover node, and you can no longer backfill the spare headroom with anything else.

• Under per socket perpetual licensing, that idle headroom was close to free. Under per core subscription you now pay an annual fee on every core you cannot use.
• Order minimums make small clusters inefficient. A two host cluster with 64 cores buys the order minimum anyway, so the marginal cores are already paid for.
• The answer is not to shrink the cluster below the minimum. It is to size the cluster to the minimum and put every Oracle workload you own inside it.
• Consolidating all Oracle onto one deliberately sized cluster is now the cheapest configuration on both bills at once, which was not true before 2024.

The failover node rule that changes the cluster design

Oracle allows one unlicensed failover node in a clustered environment with shared storage, provided only one node is active at a time and the total does not exceed 10 separate days in a calendar year. The rule sits in Oracle's data recovery licensing policy, not in the partitioning document.

Read the limit precisely before you design around it. Ten separate days is a testing and incident allowance, not a running standby, and a node that carries load routinely is a licensed node.

It also does not rescue a VMware cluster. The allowance covers a failover node in a cluster, and it does not turn a shared vSphere estate into a set of individually counted hosts.

Does leaving VMware fix the Oracle problem?

No. Every mainstream VMware alternative is soft partitioning to Oracle, so a migration driven by Broadcom pricing leaves your Oracle exposure exactly where it was. This is the most expensive misunderstanding in the current market.

Generic KVM is the trap in that table. Oracle Linux KVM qualifies and open source KVM under another distribution does not, even though the underlying technology is the same, because the policy names products rather than capabilities.

If the Oracle answer is what you are optimizing, the exits worth costing are the last three rows. See how to implement Oracle hard partitioning for the configuration detail, Nutanix Oracle licensing and the Hyper V guide for those platforms specifically.

Where the common advice on Oracle after Broadcom is wrong

The advice circulating since 2024 is that Broadcom pricing makes VMware untenable, so you should migrate the estate to a cheaper hypervisor and solve the Oracle problem on the way. We disagree, and the second half of that sentence is simply false. Moving from vSphere to Nutanix AHV or Proxmox changes your infrastructure bill and leaves your Oracle position identical, because Oracle's list names products, not architectures. In the disputes we reviewed, the buyers who had migrated hypervisors for cost reasons arrived at the audit with the same exposure and a smaller evidence trail, because the migration broke their historical placement logs. Decide the VMware question on VMware economics. Decide the Oracle question on Oracle's named list. Solving them with one project usually solves neither well.

How do you defend an Oracle on VMware position?

Defense is architecture plus dated evidence, in that order. The buyer who can show deliberate isolation, recorded before any Oracle contact, negotiates from a materially stronger seat than one arguing policy interpretation alone.

• Isolate: run Oracle on a dedicated cluster, ideally under its own vCenter and its own storage.
• Document: keep a dated architecture memo describing the boundary and the reason for it.
• Log: retain vMotion and DRS placement logs that show where workloads actually ran.
• Separate: treat the policy claim and the contract metric as two different things in every written reply.
• Version: record the cluster composition at each change, so a host added in year three does not look like a host that was always there.

What to hand the auditor, and what to withhold

Give the measured count from where Oracle actually runs, with the logs that support it. Do not volunteer the whole vCenter inventory, because the scope of that inventory is precisely what the argument is about.

Answer the question asked, in writing, and nothing wider. Every unforced disclosure in this dispute becomes an input to Oracle's opening number.

What the Broadcom transition did to your evidence

Platform migrations and vCenter consolidations during 2024 and 2025 destroyed placement history in several estates we reviewed. Log retention is the cheapest insurance you can buy before a partitioning conversation starts.

• Export vMotion and DRS history before any vCenter consolidation, and store it outside the platform.
• Keep the cluster inventory as a dated series, not a current state view.
• Capture the architecture memo again after every material change, so the record is continuous rather than a single old document.

What should a buyer do next?

1. Map placement, not capability. Pull vMotion and DRS logs for the last 12 months and list every host an Oracle machine has actually run on.
2. Draw the smallest defensible boundary. One dedicated cluster, ideally its own vCenter and its own datastores, sized to hold every Oracle workload you own.
3. Write the architecture memo and date it. One page: the boundary, the reason, the controls that keep workloads inside it, and who approved it.
4. Reconcile the measured count against entitlements. Price the gap at list and at your discounted rate, because Oracle will open at list.
5. Model the Broadcom renewal against the Oracle exposure. Put both numbers on one page. In most estates the Oracle line dwarfs the VMware line and should drive the architecture.
6. Decide the hypervisor question separately. If you leave VMware, only Oracle Linux KVM, bare metal or an authorized cloud change the Oracle answer.
7. Preserve evidence before you migrate anything. Export placement history and cluster inventories to storage the platform team does not control.
8. Prepare the written response template now. Narrow answers, contract language, no volunteered inventory, reviewed by someone who does not report to the platform owner.

Related reading: the Oracle partitioning policy guide for the document itself, the Oracle virtualization licensing guide for the platform decision, Oracle licensing in virtualized environments for the wider estate view, and Oracle cloud negotiations if the answer is to move the workload.

White Paper · Oracle

Oracle & VMware Licensing

Bound Oracle licensing on VMware. Read it free.

Read the white paper

Frequently asked questions

Does Broadcom's VMware pricing change Oracle licensing rules?

No. Oracle's partitioning position is unchanged and applies to vSphere exactly as before. What changed is the cost of the cores underneath, because Broadcom now charges per core by subscription rather than per socket perpetually.

Does Oracle require licensing all VMware hosts?

Oracle's policy claims it, and your contract does not say it. The all hosts position lives in the Oracle Partitioning Policy, which Oracle labels educational and states may not be incorporated into any contract, so it is a negotiating claim rather than an enforceable term.

Does a dedicated Oracle cluster still make financial sense after Broadcom repricing?

Yes, by a wide margin in every estate we have modeled. The VMware subscription on a 96 core dedicated cluster runs to the low tens of thousands of dollars a year, against Oracle exposure measured in millions of list value and hundreds of thousands of annual support.

What are the VMware order minimums and why do they matter for an Oracle cluster?

Broadcom applies a minimum core count per CPU and a minimum quantity per subscription order, so a small cluster buys more cores than it physically holds. For Oracle isolation the practical consequence is to size the dedicated cluster at the minimum rather than below it, and then put every Oracle workload inside it.

If I migrate off VMware to Nutanix or Proxmox, does the Oracle problem go away?

No. Nutanix AHV, Microsoft Hyper V, Proxmox and OpenShift Virtualization are all soft partitioning to Oracle, so the counting argument follows you. Only Oracle Linux KVM configured to Oracle's document, bare metal, or an authorized cloud changes the Oracle answer.

Can I license only the cores where Oracle runs?

Yes, when you isolate the workload and can evidence it. A dedicated cluster, documented affinity rules and retained placement logs support counting only those cores, and the evidence has to be dated rather than reconstructed after the request arrives.

How did vSphere 6.0 change Oracle audit risk?

vSphere 6.0 added cross vCenter vMotion, which Oracle uses to argue that a machine could move anywhere in the estate. The counter is that capability is not usage, and placement logs show the real boundary.

Should I send Oracle my full vCenter inventory?

No. Answer audit questions narrowly and in writing, and provide the measured count from where Oracle runs. Volunteering the full inventory hands Oracle the data it needs to argue the widest possible scope.

Does moving Oracle to the cloud avoid the VMware problem?

It replaces the VMware counting argument with the vCPU rules in Oracle's cloud licensing policy, where the core factor no longer applies. That can simplify counting, but you must model the new metric, the support impact and the contract terms before committing.