Broadcom's VCF subscription economics reward fewer, larger clusters, and Oracle's soft partitioning rule turns every added host into more licensable cores. This analysis shows the mechanism, runs the before and after core math, and tells you where to draw the containment line before your next renewal.
Broadcom's VCF subscription economics reward fewer, larger clusters, and Oracle's soft partitioning rule turns every added host into more licensable cores. This analysis shows the mechanism, runs the before and after core math, and tells you where to draw the containment line before your next renewal.
There are two independent policy machines running against one physical estate, and they are pulling your infrastructure design in opposite directions. On the Broadcom side, VMware moved to a subscription-only model anchored on VMware Cloud Foundation, priced per core with a sixteen-core-per-CPU minimum, and opening quotes have run several times the old perpetual cost. On the Oracle side, nothing changed: Oracle still licenses its database on the physical core capacity that could run it, not the vCPU actually assigned to a virtual machine. Broadcom raised list prices through 2024 and 2025; Oracle left the partition policy exactly where it was. The two vendors run separate audit cycles on the same servers.
The friction is this. Broadcom's per-core economics reward consolidation onto fewer, larger, denser clusters, because that is how you flatten the subscription bill. Oracle's soft partitioning position penalizes exactly that move, because the license boundary is the cluster, not the individual host. Every host you fold into a DRS-enabled cluster is a host Oracle can claim your database could migrate to. When you optimize for the Broadcom invoice without redrawing the Oracle boundary, you cut one bill and quietly multiply the other. Our 2026 Oracle-on-VMware exposure map lays out the full estate view; this page isolates the consolidation mechanism specifically.
Broadcom rewards fewer, larger clusters. Oracle punishes exactly that. Optimize one bill without redrawing the other boundary and you multiply your exposure.
On April 10, 2025, Broadcom set a 72-core minimum per license instance across every VMware product, from vSphere Foundation to VMware Cloud Foundation. The familiar sixteen-core-per-CPU rule still applies, and you pay whichever total is higher. The stated design incentive is explicit: deploy servers with 32 to 64 cores per socket so each host clears the 72-core threshold with fewer wasted licenses. That guidance points buyers directly at high-core-count hosts, which is the worst possible shape for an Oracle estate governed by soft partitioning.
There is a second trap inside the VCF product description. Each core on the server where the software is installed must be licensed, including cores deactivated in the BIOS. So the deactivate-cores tactic that some teams used to trim VMware counts does not help, and it does nothing for Oracle either, because Oracle counts physical cores present in the hardware. Broadcom also introduced a 20 percent penalty for late renewals if a subscription is not renewed by its anniversary date, which compresses the timeline and pressures teams into fast consolidation decisions without a parallel Oracle impact review. If you are working the Broadcom side of this, our guidance on the vSphere Foundation negotiation levers and the broader Broadcom VMware reset covers where Broadcom concedes.
Oracle licenses on the physical hardware capacity that could run the software, not the virtual hardware actually assigned to it. VMware is the flashpoint because Oracle treats it as soft partitioning, and Oracle's position is that it may claim every host a virtual machine could migrate to. In a cluster with vMotion or DRS enabled, a conservative reading of that position licenses all hosts the workload can reach. The database sits on two hosts; Oracle counts thirty. We cover the migration-reachability argument in detail in why Oracle says the whole cluster could run the database.
The controls buyers reach for do not work under Oracle's stated policy. Oracle explicitly disallows software- or OS-based controls to reduce licensing, and it names them: VMware DRS rules, CPU affinity settings, vSphere CPU pinning, and similar configuration. In Oracle's reading, those are all soft partitioning techniques, and none of them shrink the licensable core count. If you are relying on host affinity to hold your position, read the real answer on partial-cluster licensing before your next audit letter arrives. One nuance is your leverage: the partitioning policy is a stated position, not the contract. Your agreement defines the licensable processor, and the policy document is not automatically incorporated into it. That distinction is where audit defense lives.
The database runs on two hosts. Oracle counts thirty. The license boundary is the cluster, and vMotion is what draws it.
Here is the mechanism in numbers. Take a typical x86 host with 2 sockets and 16 cores per socket, so 32 physical cores. Intel x86 carries an Oracle core factor of 0.5, so each host is 32 x 0.5 = 16 processor licenses. On a single host that is your obligation. On a 10-host DRS cluster of the same specification, the cluster-wide obligation is 160 processor licenses under Oracle's soft partitioning rules. Now consolidate. An organisation that expanded from a 10-host to a 30-host DRS cluster as part of VCF consolidation tripled its Oracle licensing obligation on that cluster, from 160 to 480 processor licenses, without adding a single Oracle database instance.
| Cluster configuration | Physical cores | Core factor | Processor licenses | EE list ($47,500 each) | Annual support (22%) |
|---|---|---|---|---|---|
| Single 2-socket, 32-core host | 32 | 0.5 | 16 | $760,000 | $167,200 |
| 10-host cluster (32 cores each) | 320 | 0.5 | 160 | $7,600,000 | $1,672,000 |
| 30-host cluster after VCF consolidation | 960 | 0.5 | 480 | $22,800,000 | $5,016,000 |
| 2-socket AMD EPYC 9754 (128 cores each) | 256 | 0.5 | 128 | $6,080,000 | $1,337,600 |
The AMD EPYC 9754 row is the consolidation trap in one line. A single dense two-socket host carries 256 physical cores, which at a 0.5 factor is 128 processor licenses, or $6,080,000 at Enterprise Edition list before support. That is the exact server shape Broadcom's 72-core floor pushes you to buy. The January 2026 core-factor table update added multiple Intel Xeon 69xx, 67xx, 65xx, and 63xx variants and several legacy series, all at 0.5. Oracle did not raise the factor to blunt the density trend, so the dense-chip strategy that saves VMware money multiplies Oracle exposure at the same rate the core count climbs.
Some buyers assume Named User Plus (NUP) licensing sidesteps the core inflation. It does not, because the NUP minimum scales with the same physical core count. The minimum is 25 NUP per processor for Enterprise Edition. A 16-core Intel server requires a minimum of 16 x 0.5 x 25 = 200 NUP, roughly $190,000 at list, regardless of how few named users you actually have. Apply that minimum across a consolidated 30-host cluster and the NUP floor tracks the same inflated processor count, so switching metrics moves the number sideways, not down. NUP helps only where genuine user counts are low relative to cores, which is rarely true in a consolidated general-purpose cluster.
The audit data confirms the exposure is real and quantified. Across roughly 30 to 40 Oracle virtualization engagements between 2024 and 2025, soft-partitioned estates faced license claims a median 3.5 times the cores actually running Oracle. In a representative case, an enterprise that believed it was licensed for 8 processors faced an Oracle claim of 120, a $15 to $20 million back-license claim plus 22 percent annual support going forward. The average Oracle audit claim in VMware environments runs 3 to 5 times what the customer believed it owed. Consolidation does not create that multiplier, but it enlarges the base the multiplier is applied to. A 30-host cluster gives Oracle three times the surface area of a 10-host cluster to build a claim on.
The Broadcom pricing pressure is real, and consolidation is a legitimate response to it. The failure mode is consolidating first and discovering the Oracle scope expansion in an audit notice eighteen months later. Treat the two as one decision. The pre-Broadcom perpetual model at least created a fixed VMware estate that gave you a definable Oracle boundary. The subscription model removes that natural fence, so you have to build the fence deliberately. Handled right, the VMware redesign is an Oracle containment opportunity rather than a cost event.
If a renewal is on the horizon, the containment redesign should happen before the Oracle true-up conversation, not during it. Retiring shelfware and rebalancing editions ahead of renewal, covered in optimizing your Oracle footprint before renewal, works far better when your cluster boundary is already tight. For teams that need Oracle to license only the cores actually running the database, the approved hard partitioning route is the structural fix, but it is a different architecture and needs its own audit evidence.
Consolidation is a core-count multiplier for Oracle, and the multiplier is linear with cluster size. Ten hosts to thirty hosts is 160 processor licenses to 480 at 0.5 factor, or roughly $15 million more at Enterprise Edition list before support. That is not a modeling artifact; it is the direct output of Oracle's soft partitioning position applied to a larger cluster. Broadcom's 72-core floor and per-core pricing actively push you toward the dense, consolidated shape that maximizes that exposure. The right move is to treat the VMware redesign and the Oracle boundary as a single decision, keep Oracle on an isolated dedicated cluster, verify whether the partitioning policy is even in your contract, and build the evidence pack before an auditor requests it. Do that and the Broadcom pressure becomes the reason you finally capped your Oracle count. Skip it and you have cut one invoice while writing a much larger one.
Yes, mechanically. Under Oracle's soft partitioning position, every host a database VM can migrate to via vMotion or DRS is licensable. Expanding a 10-host cluster to 30 hosts of the same spec triples the processor licenses claimed, from 160 to 480 at a 0.5 core factor, with no new database instances added.
Not under Oracle's stated policy. Oracle explicitly disallows software- or OS-based controls, naming DRS rules, CPU affinity, and vSphere CPU pinning as soft partitioning techniques that do not reduce the licensable core count. The reliable containment method is a physically isolated, dedicated Oracle cluster with no vMotion path to other hosts.
Broadcom's April 2025 policy set a 72-core minimum per license instance and guides buyers toward 32 to 64 cores per socket so hosts clear that floor with fewer licenses. Those dense hosts carry far more physical cores, and Oracle counts physical cores, so the VMware cost fix directly inflates the Oracle count on any host running a database.
No. The NUP minimum is 25 per processor for Enterprise Edition and scales with the same physical core count. A 16-core Intel server needs a minimum of 200 NUP regardless of actual users. Across a consolidated cluster the NUP floor tracks the inflated processor count, so the metric change moves the number sideways rather than down.
The partitioning policy is a stated position, not automatically part of your contract. Your license agreement defines the licensable processor. Where the policy is not incorporated into your agreement, your negotiation and audit-defense position is materially stronger, so confirming this before consolidating is a priority.
Not automatically. Migrating Oracle workloads off VMware does not by itself eliminate exposure, and destinations like OCI may or may not be cheaper depending on your metric and workload. Run the cost comparison and the containment-design option side by side before committing, because a dedicated cluster often caps the count at lower cost than a full migration.
How to cut VMware vSphere Foundation cost: the per core subscription math, when VVF beats VCF, and the Tanzu add on traps to avoid before you sign.
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.
