VMware audit checklist for the Broadcom era. Where the exposure sits and how to close it.

Most VMware audit exposure after Broadcom came from a metric change applied to hosts that were sized correctly at the time. Count cores per host with dates, close the non production gaps, and take the contract floor to the renewal.

What belongs on a VMware audit checklist after Broadcom?

Five checks cover most of the exposure we find. Run them in this order, because the first two produce the evidence every later step relies on.

1. Build a dated core inventory per host. Record sockets, physical cores per CPU, cluster, purpose and the date each host went into service. Accurate dated records settle most disputes in your favor, and they cannot be reconstructed once the notice period starts.
2. Check the high density hosts first. The gap concentrates where consolidation onto fewer, larger processors was pursued hardest during the per socket years.
3. List disaster recovery and test environments by name. Their existence is never in dispute in an audit, only their entitlement, so find them before Broadcom does.
4. Compare the contracted floor with measured consumption. A floor set above what you use is a commercial term, and it needs a different remedy from a counting gap.
5. Validate inherited partner arrangements. Licenses bought through a partner under the old VMware channel are now read against different program rules from the ones in place when you bought them.

For the audit process itself across publishers, see our multi vendor audit response guide.

What did Broadcom change that created VMware audit exposure?

Four changes did it, and none of them required you to deploy anything new. Broadcom retired perpetual licensing, replaced sockets with cores as the unit, sold the products as bundles and restructured the partner channel. VMware announced the end of perpetual license sales on December 11, 2023.

Why does per core licensing penalize well consolidated hosts?

Under a per socket model, extra cores cost nothing in license fees, up to the 32 core cap per CPU license VMware added in April 2020. Packing workloads onto fewer, denser hosts was the correct engineering decision, and every serious infrastructure team pursued it. Moving from 16 core to 32 core processors doubled capacity at no licensing cost.

Broadcom now requires a core license for every physical core on each CPU running the software, with a minimum of 16 cores per CPU. The same consolidation that saved money in the per socket years now sets the size of your subscription. The core licensing guide covers the counting rule in detail.

Which exposures are compliance gaps and which are commercial terms?

A core count gap is a question of fact. It is settled by a dated inventory showing how many cores ran, on which hosts, at which point in the license period. A raised contracted floor is a term you signed, and no amount of inventory evidence changes it.

Buyers who mix the two up either argue entitlement when half the problem is commercial, or accept the floor when half the problem was a countable gap they could have closed. Fix what evidence can fix, and take the floor to the renewal. Our VMware licensing comparison for 2026 sets out how the metrics differ.

How do you count your VMware cores before Broadcom does?

Pull the physical core count per host from vCenter, date it, and reconcile it against your entitlements in the Broadcom Support Portal. Do it for every host that runs ESXi, including standby and lab hosts that never made it onto a finance register.

Which tools show the real core count?

• Broadcom's core counting PowerCLI script. Knowledge base article 313548 links a PowerCLI module (FoundationCoreAndTiBUsage) that reads vCenter. It reports sockets, cores per socket and the licensable core count for each host with the 16 core minimum applied, plus vSAN capacity per cluster. It follows the counting method Broadcom documents, so expect the account team's numbers to look like its output.
• RVTools. The vHost tab lists CPU sockets, cores per CPU and total cores for every host vCenter manages. Export it monthly and keep the files, because a series of dated exports is the history you will need.
• The vSphere Client. Each host's hardware details show the processor type, sockets and cores per socket, which is useful for spot checks on hosts outside the main vCenter.
• Your CMDB and purchase records. Server invoices and asset records give the in service date for each host, which vCenter does not keep reliably.

Run the Broadcom script yourself and read the output before anyone else sees it. When it disagrees with RVTools, find out why. The usual causes are hosts in a second vCenter, decommissioned hosts still registered, and CPUs with fewer than 16 cores being counted up to the minimum.

Why do the dates matter as much as the count?

An auditor who cannot see when a host went into service will assume it ran for the whole period under review. Your purchase records and dated exports are what limit a claim to the months a host actually ran. Because notice periods have tightened, this history has to exist before the letter arrives.

What should you do about disaster recovery and test hosts?

Treat them as in scope. Broadcom's counting rule applies to every CPU running the software, and it does not make an exception for standby or test use. Under the old arrangements these environments often had favorable treatment or informal tolerance, so no tracking habit was ever built for them.

For each disaster recovery and test host, decide now whether to license it, consolidate it onto fewer hosts or retire it. Record the decision and the date. These are the cheapest gaps to close before an audit and the most expensive to argue about afterwards.

How much does a dated inventory change a VMware audit claim?

It can cut the claim substantially, because much of the argument is about how long each gap existed. Take a hypothetical company 24 months into a 36 month VCF subscription for 768 cores. It sized that subscription from an inventory of 16 production hosts with two 24 core CPUs each.

Since then it has refreshed those hosts to two 32 core CPUs, giving 1,024 production cores. It also runs 6 disaster recovery hosts with two 16 core CPUs (192 cores) and 4 test hosts with two 12 core CPUs. The test hosts have 96 physical cores but are counted at the 16 core minimum, so 128 cores.

In this example the dates alone cut the claim from 1,152 to 608 core years, a reduction of 544 core years or 47 percent. None of the gaps disappeared, and the company still has to license 576 cores going forward or retire hosts to lower that number. What changed is that it pays for the months the cores actually ran.

The $300 rate is illustrative and not a Broadcom list price. Use your own contracted rate and our per core subscription calculator to size the forward cost.

What have we seen in Broadcom VMware audits in 2024 and 2025?

Across roughly 30 to 40 Broadcom VMware engagements between 2024 and 2025, audit exposure clustered in the same three places after the switch to subscription. The pattern held closely enough that we now plan against it from the first week.

• Inherited sizing. Core counts on high density hosts ran 20 to 40 percent above the licensed position, because the sizing logic was correct under the previous metric.
• Non production environments. Disaster recovery and test hosts were unlicensed or under licensed in roughly 6 of 10 reviews.
• The bundle floor. Bundle packaging lifted the contracted floor 25 to 50 percent above what the customer actually consumed.

The floor compounds the other two. A dispute over core counts is a dispute over quantity, while the floor sets a minimum below which the quantity no longer matters. Both need attention, and only the core count is negotiable at the audit table.

Running our own review before Broadcom arrived removed 30 to 50 percent of the exposure, mostly by producing dated core inventories in advance. The same work done calmly months ahead gives a much better result than the same work compressed into a response window.

A self audit is a measurement, and most of what it finds can be corrected.

Is the gap a failure of license management?

Mostly it is not. In most audits there is at least a suggestion that something was managed badly: a count drifted, a control lapsed, a deployment outran its entitlement. Here the largest gap came from the metric changing under designs that were correct when they were made.

That shapes how you run the conversation. Buyers who treat the gap as a governance failure tend to concede more than the facts require, so present it as a measured shortfall with dates attached.

Should you say as little as possible and make Broadcom prove the gap?

That is common advice for audits in general, and for VMware it usually backfires. If you hold back, the numbers from Broadcom's own script become the record, with no dates and no context.

We advise the opposite order. Count first, correct what you can, and then disclose a dated, scoped summary that you control. Staying quiet only helps when your own records are worse than Broadcom's, and in that case the records are what need work.

What will Broadcom say during a VMware audit, and how should you answer?

Expect requests for raw data, pressure to settle through a larger renewal, and tight deadlines. Each has a precise answer that keeps the discussion on facts you can prove.

• "Run our counting script and send us the full output." Reply that you will run it, review it, and send a dated summary for the products and period the contract allows. Raw vCenter exports carry hosts and clusters outside the scope of the review.
• "Your disaster recovery hosts need full VCF subscriptions." Reply with the list of those hosts, the dates they ran and your decision for each one. Ask that any hosts you keep be priced as a forward subscription at your contracted rate.
• "The simplest fix is to renew into VCF at your full core count." Reply that you will settle the counted gap on its own terms and discuss the renewal scope separately. Mixing them turns a compliance settlement into a larger bundle.
• "We need everything within the notice period." Acknowledge the notice in writing and propose a scope and timetable for each data request, so deadlines are agreed rather than imposed one by one.

If Broadcom has written to you about unsupported use rather than opening a formal audit, the timing works differently. Our guide to responding to a cease and desist letter covers that case.

Which contract terms limit future VMware audit exposure?

Ask for these at the next renewal, when you have the most room to negotiate. Our note on Broadcom contract red lines sets out which ones are worth holding out for.

• Audit notice and frequency. A stated minimum notice period and no more than one audit in a set period, so reviews cannot be stacked around your renewal date.
• A written counting method. Physical cores, the 16 core per CPU minimum and the date of measurement, so the count is agreed before anyone argues about it.
• Customer produced data. The right to supply your own dated inventory instead of giving direct access to vCenter or running unreviewed scripts.
• Shortfall pricing. Any gap settled as a subscription at your contracted rate from the date of use, without back dated list price or penalty uplifts.
• Reduction rights at renewal. The ability to lower the core quantity when you retire hosts, so the floor follows what you run.
• Named treatment for disaster recovery and test hosts. Written terms for standby and non production environments, so they stop depending on informal tolerance.

When should you start a VMware self audit?

At least a year before your subscription term ends, or the day an audit notice arrives if one comes first. The table below sets out what to have done at each point.

What mistakes make a VMware audit more expensive?

Each of these adds cost without any change in what you actually ran, and each is avoidable with a few hours of preparation.

• Sending raw exports. A full RVTools or script output from every vCenter hands over hosts outside the review and invites questions you did not need to answer.
• Reporting socket counts. Teams used to per CPU licenses still count sockets, which hides the refresh gap until the auditor finds it.
• Forgetting the 16 core minimum. Older and edge hosts with small CPUs are counted up, so a physical count understates the licensable one.
• Leaving retired hosts registered. Hosts that no longer run workloads but stay in vCenter appear in every count until they are removed and the removal is dated.
• Settling the floor as a compliance issue. Paying an audit settlement to cover a commercial term locks in the floor for another term.

If you want help running the review, our Broadcom audit defense service works from your data, and the wider library sits in the Broadcom VMware knowledge hub.

What to do next

1. This month. Export the host and core data from every vCenter and repeat the export monthly, keeping every file.
2. Before anyone asks. Run Broadcom's core counting script yourself and reconcile it with RVTools and your purchase records.
3. Start with density. Check the hosts refreshed to larger processors first, since that is where the shortfall concentrates.
4. Close the non production gaps. License, consolidate or retire each disaster recovery and test host, and date each decision.
5. Split the problem. Put the countable gaps in one list for the audit and the contracted floor in another for the renewal team.
6. Prepare the renewal terms. Table the audit, counting and reduction clauses before Broadcom sends the renewal quote.

Frequently asked questions