A 32-core edge estate can be forced to license 72 cores, so an unnormalized VCF benchmark overstates your peer's per-core price by up to 125 percent
Broadcom's 16-core-per-CPU floor and residual minimum-order behaviour mean two estates running identical workloads can carry billable core counts that differ by more than 2x. Until you restate every data point as price per billable core and price per physical core, Broadcom will dismiss your benchmark by arguing your CPU geometry is unusual, and it will be partly right.
Prepared by Redress Compliance · September 10, 2026 · Broadcom VMware advisory. VCF renewal and benchmark engagements 2024 to 2026.
Executive summary
The 16-core-per-CPU minimum means a two-host estate with single 8-core sockets runs 32 physical cores but licenses at least 72, a 125 percent inflation that no dense estate ever experiences.
Dense clusters, for example 8 hosts at 2 sockets by 24 cores, license exactly 384 cores with zero rounding, so their per-core numbers are structurally lower and not comparable to yours.
Unnormalized benchmarks hand Broadcom a free rebuttal, and the cost of losing that argument runs 8 to 15 percent versus better-prepared peers on identical products.
Once the rep proves one data point in your set came from a geometry-immune estate, the whole comparison set is treated as anecdote and the discussion returns to their price list.
Report two numbers per data point: price per billable core and price per physical core, because the gap between them is where 200 to 350 percent cost increases in small and edge deployments hide.
A $119 per billable core VVF quote on 72 cores is really $268 per physical core if only 32 cores are running, and that is the number your CFO should be told.
Normalization is also a discount lever, not just hygiene, since opening quotes overstate real need by 20 to 40 percent and disciplined core measurement plus a costed alternative has cut final numbers 15 to 30 percent.
Target a phantom-core credit or a tier swap to VVF or VCF Edge at around $50 per core rather than arguing percentage discount on inflated volume.
How core minimums create two different denominators
The reason your peer benchmark keeps losing arguments is that the number you are comparing has two possible denominators and nobody at the table has agreed which one is in play.
Broadcom licenses per core with a floor of 16 cores per physical CPU, applied socket by socket, not averaged across the cluster. The June 2026 VCF Software Product Description confirms the floor and closes the obvious workaround: cores you have deactivated in BIOS still count.
Layer on the withdrawn April 2025 rule that set a 72-core minimum per license instance, and you have the residue that still causes trouble.
The rule itself was pulled after protest, and Broadcom's public pages as of August 2026 do not state a 72-core order minimum, but resellers continue to quote 72 cores as the smallest sellable line.
And the no-combining principle that came with it (40 VCF cores plus 32 VVF cores satisfying neither) still shapes how partners assemble quotes.
So a two-host edge site with one 8-core socket per host runs 32 physical cores and gets billed for 72. Your dense peer, 8 hosts at 2 sockets and 24 cores per socket, runs 384 physical cores and gets billed for exactly 384.
Same product, same tier, and a per-core price from one is arithmetically meaningless against the other.
| Estate geometry | Physical cores | Billable cores | Inflation factor | Effective $/physical core at $150/billable core |
|---|---|---|---|---|
| 2 hosts, 1 socket, 8 cores (edge) | 32 | 72 | 2.25x | $337.50 |
| 4 hosts, 2 sockets, 10 cores (aging cluster) | 80 | 128 | 1.60x | $240.00 |
| 8 hosts, 2 sockets, 16 cores (baseline) | 256 | 256 | 1.00x | $150.00 |
| 8 hosts, 2 sockets, 24 cores (dense) | 384 | 384 | 1.00x | $150.00 |
The table implies that scale buys immunity. It does not. Minimum behaviour attaches to the deal line, not the company.
A 20,000-core enterprise still pays inflated rates on every DR site, lab cluster, satellite branch, and partial renewal where the geometry is small and old, and those lines are precisely where teams expect right-sizing to cut spend.
In our experience, this is where a "consolidated" renewal quietly reprices 5 to 8 percent of the estate at edge economics while the headline per-core number looks fine.
That asymmetry cuts both ways at the table. If your estate is dense, a peer number from an edge-heavy estate flatters you and Broadcom will happily let you use it, because it makes your ask look aggressive against a distorted baseline.
If your estate carries legacy 8 and 10 core sockets, every raw per-core figure you produce understates your real position by 60 to 125 percent, and the account team knows it. Fix the denominator before you open the file, or you are negotiating against your own arithmetic.
The mechanics matter here only because they decide which number survives scrutiny, which is also why per-core benchmarks have to be read by spend tier rather than as a single market rate.
The normalization method: two numbers per data point
Every benchmark point carries two prices: price per billable core (what Broadcom charges and what the contract says) and price per physical core (what your workload actually costs you).
Publish both, always, and tag each point with seven attributes: socket count, cores per socket, host count, tier (VCF, VVF, or VCF Edge), term length, total billable cores, and whether vSAN add-on capacity was bought separately. Without those tags a number is an anecdote.
With them it is evidence Broadcom has to argue against on the merits.
Run it on the real 2026 quotes. The two VVF deals at 72 cores, $119.08 and $126.29 per core on three-year terms, are the classic ambiguous data point: 72 cores is exactly the old minimum-order figure, so until you know the geometry you cannot tell whether that estate physically runs 72 cores or 32.
If it runs 32, the true cost per physical core is $267.93 and $284.15, more than double the headline.
The VCF quote at 96 cores and $344.40 per core on a one-year term is a different animal: 96 cores is 6 sockets at 16, so it plausibly normalizes near 1.0x, and the price is high because it is a short-term, small-volume VCF line, not because the geometry is inflated.
Two of those three points are the same tier at roughly a third of the price. Comparing them raw produces nonsense.
This is why five clean, tagged points beat twenty untagged ones. Twenty anonymous per-core prices give Broadcom a menu of outliers to discredit, and the account team will pull the lowest one, name a reason it is not comparable, and use that to dismiss the set.
Five points with disclosed geometry, tier, and term force the conversation onto whether your geometry is genuinely unusual, which is a factual question you can win.
Present the pair in every exchange (per billable core and per physical core) and keep the source protected using the methods in proving a benchmark without revealing where it came from.
How to negotiate Broadcom VMware in 2026
How to negotiate a Broadcom VMware deal in 2026: VCF bundle economics, the core minimum mechanics, subscription conversion exposure, and the levers.
Get the white paper →Why Broadcom wants your estate to be unusual
The geometry objection is the cheapest anti-benchmark tool Broadcom has, and it works because it is not a lie. When you table a peer number of $185 per core and your rep answers that the comparison estate runs 24-core sockets while yours runs 8-core sockets, the rep is stating arithmetic.
Two hosts with one 8-core socket each hold 32 physical cores and, under the 16-core-per-CPU floor plus the residual minimum-order behaviour, can be pushed to 72 billable cores: a 125 percent inflation of the denominator. Every peer price you quote will be read through that gap.
The rep does not have to win the argument. He only has to make your number look unrepresentative for the two weeks that matter, and the deal desk uses that window to hold the line.
Watch the incentive structure behind the objection. A rep who concedes on price loses margin against quota.
A rep who reframes your inflated denominator as an architecture problem loses nothing and gains a second conversation, one about consolidation projects, hardware refresh timing, and professional services attach.
That reframe converts a pricing negotiation, where you have data and he has discretion, into a capability negotiation, where he has the reference architectures and you have a spreadsheet. It is a downgrade in your position dressed as helpfulness.
Note also that the remedy he proposes, denser sockets, typically lands after signature, so it reduces your billable cores on a future renewal while doing nothing for the paper in front of you.
The asymmetry is the real problem. Broadcom's deal desk sees thousands of CPU geometries a quarter and knows exactly where your estate sits in that distribution. You see one estate: your own.
You cannot disprove the claim that you are unusual without disclosing exactly the peer detail you are contractually and commercially unable to share, which is why the disclosure question deserves its own preparation, covered separately in how to prove a VCF benchmark without revealing your source.
So the objection is technically true, unfalsifiable from your side of the table, and free to deploy. That is a very good tool.
The 72-core minimum order makes stale-data attacks trivial in both directions. It was announced for 10 April 2025, protested, then withdrawn, and public Broadcom pages fetched in August 2026 do not state it.
Meanwhile the 16-core-per-CPU floor is live and confirmed in the June 2026 Software Product Description, including the detail that BIOS-deactivated cores still count. That leaves two live rules, one dead rule, and widespread confusion between per-CPU, per-order, and minimum-quote-size behaviour.
If your benchmark contains a 2025 data point priced against 72 billable cores, your rep can dismiss it as obsolete. If your rep quotes you a 72-core floor on a satellite cluster, you can dismiss that as withdrawn.
Both attacks are available, which means both parties should expect to be hit, and only one party has an incentive to clarify.
Normalization inverts the tool. Once every data point carries two numbers, price per billable core and price per physical core, the geometry objection stops being a defense and becomes an admission.
If your peer paid $185 per billable core on a dense estate where billable equals physical, and your quote is $185 per billable core on an estate where 72 billable covers 32 physical, then you are being asked to pay $416 per physical core for the same compute.
Broadcom has just conceded that the difference exists. The only remaining question is who absorbs it, and that is a discount conversation, not a capability one.
The strategic conclusion follows directly: raise geometry first, before the rep does. The party that names the distortion owns the remedy. If you open with the phantom-core arithmetic and a stated remedy, you set the frame and the rep is answering your proposal.
If you wait, he names it as your architecture problem and you spend the meeting defending the validity of your own data.
In our negotiation experience, that first-mover difference on the geometry point is worth more than any single line item in the discount schedule, because it decides whether the remaining sessions are about price or about your CPU choices.
The geometry objection is one of the few Broadcom arguments where the vendor's factual position and your commercial position point the same way. Broadcom is telling you that a core-minimum-inflated estate carries an artificially high denominator. That is your case.
The moment the rep says it out loud, the phantom cores stop being a technical footnote and become a named quantity that someone has to pay for.
Treat the objection as an opening bid, not a wall. Ask for it in writing: which floor applies, per CPU or per order, and what billable count Broadcom is using against your physical count. A written answer converts the argument into a number, and numbers can be discounted.
Pricing the phantom cores instead of arguing about them
Once the gap is named, stop debating whether it is fair and start pricing it. Three remedies work, and you should table all three in the same session so Broadcom picks the one that costs it least rather than refusing the category.
First, a phantom-core credit: you accept the billable count on paper but the discount is calculated so the effective spend matches your physical cores.
On the 32-versus-72 example, that is a 55 percent effective reduction, which sits at the top of the observed 30 to 55 percent below-list band rather than outside it. Second, tier reassignment: not every inflated cluster needs the full VCF stack.
Edge and satellite sites move to VVF at realised rates of $80 to $110 per core, or to VCF Edge, which Carahsoft has published at $50 per core, roughly one seventh of the $350 VCF list.
Third, consolidation before signature, not after: if you can land the same workload on 24-core sockets before the paper is signed, the floor stops binding and the argument disappears along with it.
Set the target numbers before the call. On committed multi-year enterprise estates, effective rates of $100 to $130 per core are achievable, and the reset against your prior perpetual-plus-SnS run rate should land at 1.8 to 2.6 times, not the 2.8 to 4.1 times median first quote.
Those two figures are your scorecard.
Also insist that the VCF-to-VVF ratio be visible in the quote: it has run about 2.7 to 1, and mixing an edge estate into the premium tier is where the largest single overpayment usually hides, a point developed further in pricing VMware bundles on your own numbers.
Expect Broadcom to counter by offering a term extension instead of a credit. Take the credit and price the extension separately.
If the credit is refused outright, move the inflated sites to a shorter term than the core estate. A one-year tail on 72 billable cores is a manageable mistake. A five-year tail is not.
Second distortion: vSAN entitlement and bundle tier
Normalizing to billable cores fixes the denominator. It does nothing for the numerator, because two estates with identical billable core counts can be buying materially different things. VCF carries 1 TiB of vSAN capacity per core; VVF carries 0.25 TiB.
That four-to-one entitlement gap is the real reason the VCF-to-VVF per-core ratio sits near 2.7x rather than at some arbitrary bundle premium, and it is why a peer's "cheap" VVF number is not automatically a win.
Take a 32-core edge server on VVF: 8 TiB of vSAN entitlement, which a modest all-flash node exhausts before you have finished the first tranche of VMs.
From that point the storage bill leaves the per-core line entirely and reappears as vSAN Capacity Add-On, invoiced separately, discounted separately, and conveniently absent from whatever per-core figure the account team quotes back to you.
A benchmark that ignores this rewards the buyer who shifted spend into add-ons and punishes the buyer who bought the inclusive tier.
The VCF 9.1 hardware floors decide whether the cheaper tier is even reachable. Three hosts minimum with vSAN, two with external storage, which means a two-node retail or plant site either buys external storage it did not want or moves up a tier it did not need.
Broadcom knows this and will price the edge estate as if the constraint were your architectural choice. Add a third column to every data point in your model: price per billable core, storage-inclusive, calculated as bundle spend plus twelve months of Capacity Add-On divided by billable cores.
In practice that column moves edge and DR line items by 20 to 40 percent against the headline rate, which is exactly the gap the vendor is relying on you not to close.
Run the same discipline across the rest of the bundle when you strip the bundle back to what you actually consume, because NSX and automation entitlements distort the numerator the same way vSAN does, just less visibly.
Evidence base and the patterns that repeat
VCF listing at $350 to $400 per core lands 30 to 55 percent below list once term length, core scale, ramp and a credible alternative are all on the table.
Buyers arriving without a costed alternative or advisory support consistently land in the upper quartile, paying 8 to 15 percent more than better-prepared peers for identical SKUs.
The spine of any defensible benchmark is a small number of dated, attributable figures. VCF list at $350 per core per year, itself halved from the $700 opening posture of January 2024, which tells you the list is a negotiating artifact rather than a floor.
VVF has no published list at all, with advisory market rates spread across $135 to $190 per core, a range wide enough that Broadcom can pick whichever end suits the argument.
Marketplace transaction data puts 500 to 1,500 core estates at $380 to $480 on three-year terms and 2,000-plus core estates at $320 to $400, while realized enterprise bands come in lower still at $185 to $275 for VCF and $80 to $110 for VVF.
Those two datasets do not contradict each other; they measure different populations, and the gap between them is precisely the value of preparation. The discount bands by core count tier are the right lens for deciding which population you belong to before you quote a number at anyone.
The pattern that recurs in engagement after engagement is that the core production cluster is rarely where the damage sits. Dense two-socket, 24-core hosts meet the per-CPU floor cleanly, get scale attention from the account team, and normalize well.
The pain concentrates in edge sites, DR targets, labs, and satellite clusters, where small-socket geometry inflates billable cores, minimum-order behavior resurfaces on expansions and partial renewals, and storage add-ons pile up outside the per-core figure.
On a blended estate view those lines look immaterial. On a normalized view they routinely carry the worst per-billable-core rates in the portfolio, often two to three times the production cluster. Isolate them, price them separately, and be disciplined about how you present the comparison.
The companion piece on proving a benchmark to Broadcom without leaking the source covers the mechanics of putting normalized numbers on the table while keeping your evidence chain intact.
- Percentile standing for your exact deal size and industry, from real closed transactions
- Scenario simulation before the call: test alternative terms and see the financial impact of each
- A negotiation playbook, talking points, and a two page executive brief on day one
Your first five moves
- Pull socket-level inventory before the quote lands, and compute an inflation factor per cluster (billable cores divided by physical cores), because a two-host estate with one 8-core socket each shows 32 physical cores against a 72-core order floor, a 2.25x multiplier that will silently sit inside your benchmark unless you find it first.
- Restate every comparable in dual form, price per billable core and price per physical core, so the 2026 evidence you carry (VVF at roughly $119 to $126 per core on 72 cores, VCF near $344 on 96 cores) is defensible when Broadcom's rep argues your CPU geometry is atypical, which is the standard rebuttal and often half-true.
- Open the geometry conversation yourself with a named remedy, asking either a socket-normalized rate or a credit line for phantom cores, rather than waiting for the account team to introduce it as a reason your per-core benchmark by spend tier does not apply to you.
- Price the VVF or VCF Edge swap on every site under three hosts, since the edge SKU has surfaced publicly around $50 per core and VCF has run roughly 2.7 times VVF per core; the tier decision moves more money at small sites than any discount percentage will.
- Put the normalized number in the board paper, approving spend against price per physical core and holding the mandate at 15 to 30 percent below the opening quote, the band buyers reach when they measure actual cores, right-size the bundle, and carry a costed alternative into the room. Build that alternative in parallel with the bundle right-sizing exercise, not after it.
Frequently asked questions
Does Broadcom still enforce a 72-core minimum order on VMware purchases?
The 72-core per-order minimum announced for 10 April 2025 was withdrawn after customer and partner protest, and public Broadcom pages checked in August 2026 do not state it. What survives is the 16-core-per-CPU floor and de facto minimum quote sizes that some resellers still apply.
Treat any claim in either direction as unverified until the reseller confirms it in writing on your quote, because forum consensus is contaminated by people describing three different minimums.
What is the difference between billable cores and physical cores in a VCF quote?
Physical cores are what your CPUs actually contain. Billable cores are what Broadcom charges for after applying the 16-core-per-CPU minimum, which rounds every socket up, and after counting cores that are deactivated in BIOS.
A two-host estate with one 8-core socket per host has 32 physical cores and at least 32 billable under the socket floor, rising to 72 if a minimum order applies.
Do BIOS-disabled cores still count toward VMware licensing?
Yes. The June 2026 VCF Software Product Description confirms that cores deactivated in BIOS still count for licensing purposes. Disabling cores to reduce billable count does not work, so the only physical remedies are removing sockets, consolidating onto fewer denser hosts, or changing product tier.
Why can I not compare my per-core price directly to a peer's?
Because the denominator differs. A dense cluster of 8 hosts with two 24-core sockets licenses exactly 384 cores with zero rounding, while a small-socket or edge estate can license more than twice its physical cores.
Comparing raw per-core prices across those two geometries measures CPU procurement history, not negotiation performance.
How do I stop Broadcom dismissing my benchmark as based on unusual estates?
Disclose geometry first. Present each data point tagged with sockets, cores per socket, host count, tier and term, and show both price per billable core and price per physical core.
When you name the distortion before the rep does, the conversation moves to a remedy such as a phantom-core credit rather than to whether your numbers are credible.
What per-core outcome should a normalized VCF benchmark target?
On VCF, credible outcomes land 30 to 55 percent below the $350 to $400 list once term, scale, ramp and a costed alternative are stacked, with committed multi-year enterprise estates reaching roughly $100 to $130 per core.
Realised enterprise bands of $185 to $275 for VCF and $80 to $110 for VVF are the reference points. Judge every one of those figures against billable cores, then restate against physical cores for the internal business case.
Is VCF Edge a real remedy for small-site core inflation?
It can be. A published Carahsoft entry shows VCF Edge 96 at $50 per core times months remaining, which is an order of magnitude below the VCF bundle rate, and Broadcom's own 9.1 documentation confirms an edge-tailored packaging line.
The constraint is the hardware floor: VCF 9.1 needs 3 hosts with vSAN or 2 with external storage, so single-host sites belong on VVF or standalone vSphere instead.
