TL;DR · Key Takeaways
- VCF 9 is one per-core subscription, billed through VCF Operations, with a hard 16-core-per-CPU floor. Thin, low-core sockets waste licenses against that floor.
- Each VCF core includes 1.0 TiB of raw vSAN capacity (VVF includes far less). Count raw contributed capacity, not the usable datastore figure.
- The bundled vSAN TiB auto-pools across clusters and instances. Overage is bought as add-on TiB through the same license file.
- General-purpose and production application load balancing left the entitlement. That now means buying Avi as a separate license-key add-on.
- A new instance runs 90 days in evaluation, then must be licensed. Connected sites also report usage every 180 days.
The myth is that Broadcom made VCF licensing simple. The reality is narrower: it made the model simpler to administer (one license file, one per-core metric, a unified view in VCF Operations) while leaving it just as easy to get wrong at design time. The places it bites are not where teams look. They are baked into the hardware BOM and the network design, long before anyone opens the Business Services Console. Here are the five that cost real budget, with the numbers that explain each.
Mistake 1: forgetting the 16-core-per-CPU floor
You license the total physical cores across the hosts you intend to run, with one rule that quietly inflates the bill: every physical CPU is licensed for at least 16 cores, even if it ships with fewer. Broadcom’s own counting guidance makes it concrete. Three hosts, each with a single 8-core CPU, do not cost 24 core licenses. Each socket rounds up to the 16-core floor, so you pay for 48. A four-host, dual-socket, 20-core-per-CPU config is a clean 160 cores, because each socket already sits above the floor.
So the recommendation is blunt: model licensing before you spec the hardware, and on a server refresh favour fewer fat sockets (two 32-core) over many thin ones (four 8-core), because the thin layout burns paid-for cores against the minimum. When is that not the right call? When other per-core software in the stack (some database engines, certain security agents) also charges by core and pushes you the other way, or when very high-core CPUs strand your memory and IO ratios per host. Validate two things first: the real physical core count per socket, and that you are not assuming BIOS-disabled cores buy you out (verify your exact CPU against the counting KB, because physical cores are what get counted). This is trivial to get right on a spreadsheet and expensive to discover after the PO is signed. The sizing side of this is in the VCF 9 planning and prerequisites breakdown.
Mistake 2: misreading the vSAN TiB entitlement
VCF bundles vSAN at 1.0 TiB of raw capacity per VCF core purchased. That ratio is VCF-specific. vSphere Foundation (VVF) bundles far less, commonly cited at 0.25 TiB per core, so architects who carry a VVF mental model into a VCF design routinely mis-size this by a factor of four. Two details trip people up. First, the TiB figure is counted on raw physical capacity contributed to vSAN, not the usable datastore capacity the vSphere Client shows after RAID and slack. Second, the entitlement auto-pools: it aggregates across clusters and across VCF Operations instances, so a cluster that consumes less than its share lends headroom to one that consumes more. The reverse is where the cost hides. If total raw vSAN across the deployment exceeds the bundled TiB, you buy add-on vSAN TiB through the same license file, and that overage is easy to miss when each cluster is sized in isolation. Count at the deployment level, not the cluster level. The storage choices that drive raw consumption (ESA versus OSA, the storage policy, failures to tolerate) are covered in the vSAN ESA versus OSA breakdown.
Mistake 3: counting by hand instead of with the tool
Broadcom is explicit that hand-calculating vSAN TiB from the UI is neither recommended nor accurate, because the Capacity Overview reports usable datastore capacity rather than the raw figure licensing uses. Use the official PowerCLI License Counting Tool against your connected vCenter instead. It applies the 16-core floor for you and reports the raw vSAN TiB the deployment actually consumes.
# Broadcom's official PowerCLI License Counting Tool
# (download link and exact script name are in KB 313548)
Connect-VIServer vcenter.example.local
# Run the tool against the connected vCenter to report:
# - VCF cores, with the 16-core-per-CPU floor already applied
# - raw vSAN TiB consumed, the number licensing actually cares about
# Treat its output, not the vSphere Client capacity view, as the source of truth.In practice, the gap between the UI number and the tool number is exactly the gap that shows up as a surprise at true-up. Run the tool before every purchase and before every host add, and keep the output with the change record.
Mistake 4: assuming load balancing is still free
This is the silent line item that wrecks budgets. From VCF 9.0, general-purpose load balancing is no longer in the VCF entitlement. The built-in NSX load balancer is deprecated, and Broadcom directs you to Avi Load Balancer for production application and advanced (Layer-7) load balancing. Avi is an add-on bought with a separate license key, alongside the others that stayed on keys (vDefend Firewall, Tanzu Platform, Data Services Manager). What you do still get inside the entitlement is load balancing for the VCF infrastructure components themselves, plus Layer-4 load balancing for the vSphere Supervisor (VM Service, vSphere Pods, VKS). So you do not need Avi merely to stand the platform up.
My take
Budget Avi the moment a production app needs real L7 or advanced load balancing, and do not architect new production apps on the deprecated NSX LB, because you are designing on a feature that is on its way out. When can you skip it? Infrastructure-only or dev and test footprints that genuinely live within the included Supervisor L4 do not need it. Validate one thing with your account team before you assume anything about timing: whether any transition entitlement applies to you (see Mistake 5 on the grace-period caveat). The full trade-off is in the Avi versus NSX native load balancer comparison.
Mistake 5: losing track of the licensing clocks
A new VCF instance deploys fully functional in evaluation mode. You can add hosts, clusters and workload domains. What you cannot do is forget the clocks. The evaluation window is 90 days in VCF 9 (up from 60 in prior releases), after which the instance must be licensed via a license file applied through VCF Operations and the Broadcom Business Services Console. There is a second clock people miss: connected sites report license usage to Broadcom every 180 days (one button in VCF Operations), and disconnected, air-gapped sites must manually upload the usage file and re-import the license file on the same 180-day cadence to stay compliant. Put both dates on the calendar the day you deploy. One more dependency that bites during upgrades: licensing now requires a VCF Operations instance and a vCenter instance to license ESX hosts and vSAN clusters. You cannot license hosts in isolation anymore.
A worked example, end to end
Put the rules together on a real shape. Take four hosts, each with two 20-core CPUs, contributing 60 TiB of raw vSAN in total. Cores are straightforward: every socket is already above the 16-core floor, so it is 4 x 2 x 20, which is 160 VCF core licenses. The bundled vSAN entitlement is 1.0 TiB per core, so those 160 cores include 160 TiB of raw capacity, comfortably above the 60 TiB consumed, with the surplus free to pool to other clusters. Now change one variable: make those hosts single-socket 12-core instead. Each 12-core CPU rounds up to the 16-core floor, so each host costs 16 rather than 12, and the apparent saving on thinner CPUs evaporates against the minimum. That single comparison is why you model licensing before you finalize the server BOM, not after.
| Mistake | Why it bites | What to do |
|---|---|---|
| 16-core floor | Thin sockets round up; you pay for cores you do not have | Favour fewer fat sockets; model cores before the BOM |
| vSAN TiB entitlement | Counted on raw, not usable; VVF ratio is far lower | Count raw at deployment level; budget add-on TiB for overage |
| Hand counting | UI shows usable capacity, not the licensed raw figure | Use the PowerCLI License Counting Tool, keep its output |
| Load balancing | NSX LB deprecated; production L7 LB left the bundle | Budget Avi as a key add-on; do not design on NSX LB |
| The clocks | 90-day eval and 180-day usage reporting slip past teams | Calendar both dates at deploy; license via VCF Ops + vCenter |
The Bottom Line
The two mistakes that cost the most are structural, not clerical: the 16-core floor that punishes thin hosts, and the load-balancing change that turns a once-free feature into a separate Avi purchase. Both are invisible until the invoice arrives, and both are decided at design time. So decide them on purpose: model your core and raw-TiB counts with the PowerCLI tool before the server BOM is locked, and put Avi in the budget the day a production app needs real load balancing. One honest caveat: community sources mention a transition window for customers moving off the NSX load balancer, but I have not been able to confirm a specific date against a Broadcom source, so treat any date you hear as a planning rumour and confirm it with your account team. Which of these five is most likely to surprise your finance team this cycle?
References
- Broadcom KB: Counting Cores for VMware Cloud Foundation
- VCF Blog: Licensing in VMware Cloud Foundation 9.0
- Broadcom TechDocs: VCF 9.0 Licensing
- Broadcom KB: NSX Load Balancer Entitlement Change
About The Author
