VMware Cloud Foundation 9.1 Licensing by Core: How to Count Cores and Avoid Over-Buying

    Consult Circle28 min readVMware
    VMware Cloud Foundation 9.1 Licensing by Core: How to Count Cores and Avoid Over-Buying

    VCF 9.1 licensing guide

    VMware Cloud Foundation (VCF) 9.1 and VMware vSphere Foundation (VVF) are sold as subscriptions licensed per physical CPU core, with a minimum of 16 cores counted for every physical processor. To work out what you need, count the physical cores in every CPU on every ESX host you will run, raise any CPU with fewer than 16 cores to 16, and add the totals together; VCF then gives you 1 TiB of vSAN capacity for each licensed core.

    The arithmetic is simple. Most over-buying comes from counting the wrong things: hosts that have already been retired, low-core CPUs that cost more than they look, vSAN capacity bought per cluster when it can be pooled, and DR hosts nobody checked. This guide sets out the counting rules from Broadcom's own documents, works through a hypothetical estate, and lists the checks we run with clients before a renewal.

    Key points

    • VCF is licensed per core, with a minimum of 16 cores per processor. Every core on a server where the software is installed counts, including cores switched off in the BIOS.
    • Hyperthreads are not counted. Broadcom defines a core as a single physical computational unit of the processor.
    • Each VCF core includes 1 TiB of vSAN capacity, pooled across your VCF cores. VVF includes 0.25 TiB per core, rounded up. Extra raw capacity is a vSAN add-on.
    • Broadcom publishes a PowerCLI script in KB 313548 (formerly KB 95927) that counts cores and vSAN TiB from vCenter.
    • VCF 9.x uses a single licence file managed in VCF Operations. In 9.1 licences live in a local license server and connected sites refresh automatically every 24 hours.
    Important: This article is practical guidance on counting and planning. It is not legal advice and not an interpretation of your licensing contract. Your entitlement is set by your order, the Specific Program Documentation (SPD) in force when Broadcom accepted it, and any terms you agreed. Confirm quantities with Broadcom or your reseller before you buy or renew.

    How does VCF per-core licensing work?

    Broadcom's VCF Specific Program Documentation (May 2025 edition) says VCF is "subscription software licensed on a per Core license metric" with a minimum of 16 cores per processor. The same document says each core on the server where the software is installed must be licensed, including cores deactivated by the BIOS, and that the number of core licences equals the number of cores on the server, subject to that 16-core floor.

    Three definitions in the SPD decide most counting questions. A core is "a single physical computational unit of the Processor". A processor is a single physical chip with at least one core. A server is a hardware system able to run the software, and a hardware partition or blade counts as a separate server. Logical threads from Hyper-Threading or SMT are not physical cores, so they do not add to the count.

    VCF is sold as one product. The SPD says its components "can only be utilized on, or for the same physical Cores where the vSphere in VCF Core license is deployed." You cannot license a small VCF footprint and then use VCF Operations or NSX to run a larger estate licensed some other way. The VCF Operations and VCF Automation entitlement is also per core and covers managing VCF cores only.

    16

    Minimum cores counted per physical CPU

    1 TiB

    vSAN capacity included per VCF core

    0.25 TiB

    vSAN capacity included per VVF core

    180

    Days between compliance reports (disconnected mode)

    The 16-core minimum per CPU

    The 16-core minimum applies to each physical processor, not to each host or order. Broadcom KB 313548 puts it plainly: you must license a minimum of 16 physical cores for each CPU, and a CPU with fewer than 16 cores is counted as 16. Its own example has two hosts. Host A has 2 CPUs with 8 cores each and Host B has 2 CPUs with 24 cores each. Host A counts as 32 cores and Host B as 48, so the subscription needed is 80 cores.

    How VCF counts licensed cores on a host Formula: for each CPU take the larger of its physical core count and 16, then add all CPUs on all hosts. Three example hosts: one CPU with 8 cores counts as 16; two CPUs with 12 cores count as 32; two CPUs with 32 cores count as 64. Licensed cores per host = sum over each CPU of max(physical cores in that CPU, 16) Host A 1 CPU × 8 cores 8 physical cores Below minimum counted as 16 16 cores 8 paid but unused Host B 2 CPUs × 12 cores 24 physical cores Each CPU raised to 16: 2 × 16 32 cores 8 paid but unused Host C 2 CPUs × 32 cores 64 physical cores Above minimum counted as is 64 cores no unused cores
    Figure 1. The per-CPU counting rule from Broadcom KB 313548 and the VCF SPD, shown on three hypothetical hosts. Hyperthreads are never part of the count.
    CPU configuration per hostPhysical coresLicensed coresCores paid but unused
    1 CPU × 8 cores8168
    2 CPUs × 12 cores24328
    2 CPUs × 16 cores32320
    2 CPUs × 24 cores48480
    2 CPUs × 32 cores64640

    Table 1. How the 16-core minimum per CPU changes the licensed count. Configurations are examples, not recommendations.

    What happened to the 72-core minimum?

    In March and April 2025, several trade outlets, including heise, reported that Broadcom would introduce a minimum purchase of 72 cores per order for new and renewal transactions from 10 April 2025. A few days later, iX (as reported by it-daily) said the change had been withdrawn, and quoted a Broadcom spokesperson saying Broadcom had never announced a price change and that the 16-core minimum from December 2023 still applied.

    The Broadcom documents we read for this guide, KB 313548 and the May 2025 VCF SPD, state the 16-core per processor minimum and say nothing about a 72-core order minimum. Broadcom has not published a KB on a per-order minimum that we could find. Commercial rules such as minimum order quantities can sit in price lists and quotes rather than in KBs, so if your quote shows a minimum quantity, ask your reseller to show you where it comes from.

    How much vSAN capacity is included per core?

    The VCF SPD says the customer "is entitled to 1 TiB of vSAN capacity for each Core licensed for VCF," and that vSAN capacity can only be aggregated and used across cores where vSphere in VCF is deployed. The SPD defines a TiB as 240 bytes of physical storage. KB 313548 gives VVF 0.25 TiB per core, rounded up to the next whole TiB.

    The figure you compare against the entitlement is raw physical capacity contributed to vSAN, not usable datastore capacity after RAID or erasure coding. KB 313548 warns that the vSphere Client capacity overview shows available datastore capacity, which is not the licensing figure, and recommends the PowerCLI script for any environment with vCenter.

    If a cluster needs more raw TiB than your entitlement covers, you buy the difference as vSAN add-on capacity. If the result is zero or negative, you need nothing extra. KB 313548 also says entitled TiB can be distributed across clusters in different ratios from the core licences, and excess can be aggregated. In practice that means a compute-heavy cluster with little vSAN can donate its unused entitlement to a storage-heavy cluster, as long as both run VCF cores.

    ItemVCFVVF
    Licence metricPer physical corePer physical core
    Minimum per CPU16 cores16 cores
    vSAN included1 TiB per core0.25 TiB per core, rounded up
    Capacity measured asRaw TiB claimed by vSANRaw TiB claimed by vSAN
    Extra capacityvSAN add-on per TiBvSAN add-on per TiB

    Table 2. Core and vSAN rules for VCF and VVF, from Broadcom KB 313548 and the VCF SPD.

    Renewal coming up?

    Get an independent core and vSAN count before you sign

    Consult Circle designs, upgrades and runs VMware Cloud Foundation estates. We can run the counting script with you, clean up inventory and give you a quantity you can defend to finance and to Broadcom.

    See our VCF services

    What is included in a VCF core licence, and what is an add-on?

    A VCF core licence covers the private cloud platform: vSphere, vCenter, vSAN (up to the included capacity), NSX networking, VCF Operations, VCF Operations for Networks and VCF Automation. The SPD lists vSAN, VCF Operations, VCF Automation, VCF Operations for Networks and vCenter in its component table, and its export section covers the NSX software inside VCF. HCX ships with VCF 9.1 as VCF Operations HCX and appears in the VCF 9.1 release notes; see our HCX 9.1 guide for what it does.

    Broadcom's VCF 9.0 licensing blog (June 2025) listed the add-ons and how each one is licensed. Private AI Foundation and extra vSAN capacity sat in the licence file. vDefend Firewall, Avi Load Balancer, Tanzu Platform and Data Services Manager still used licence keys. Live Recovery was delivered as SaaS. In August 2025 Broadcom announced that VMware Private AI Services would become a standard part of the VCF 9.0 subscription, with no extra purchase, and SiliconANGLE reported the services would launch in early 2026. Check your own entitlement in the VCF Business Services console, because what you hold depends on when and what you bought.

    What a VCF core licence includes and what is sold separately Left: included with each VCF core, namely vSphere and vCenter, vSAN at 1 TiB per core, NSX networking, VCF Operations and VCF Automation, VCF Operations for Networks, VCF Operations HCX, and Private AI Services as announced in August 2025. Right: sold separately, namely extra vSAN TiB, vDefend Firewall, Avi Load Balancer, Tanzu Platform, Data Services Manager and Live Recovery. Included per VCF core Sold separately vSphere and vCenter vSAN, 1 TiB per core, pooled NSX networking VCF Operations and VCF Automation VCF Operations for Networks VCF Operations HCX Private AI Services(announced August 2025) Extra vSAN capacity (per TiB) vDefend Firewall Avi Load Balancer Tanzu Platform Data Services Manager Live Recovery (SaaS) Check your order: add-onmetrics vary by product
    Figure 2. Inclusions and add-ons as described in the VCF SPD, the VCF 9.0 licensing blog and Broadcom's August 2025 Private AI announcement. Your contract is the final word.

    If you are planning to bring firewall or load balancer services into VCF, budget for them on top of the core count. Our guides to Cisco ASA to NSX Distributed Firewall migration and F5 BIG-IP to Avi migration cover the technical side, and our Live Site Recovery comparison covers DR options.

    How do licence files work in VCF 9.x?

    VCF 9.0 replaced the old per-product, per-version licence keys with a single licence file. Broadcom's VCF 9.0 licensing blog says one file covers VCF cores, vSAN TiB, Private AI Foundation, VVF cores and VCF Edge cores, and that you do not need a new key to upgrade from 8.x to 9.0. Subscriptions for the same product are pooled into one capacity automatically, so there is no more merging or splitting keys.

    You assign licence capacity to one or more vCenter instances in VCF Operations, and the ESX hosts those vCenters manage are licensed from it. After a fresh install, VCF runs in evaluation mode, which the same blog says is now 90 days. You register the VCF Operations instance with the VCF Business Services console at vcf.broadcom.com and either let it report usage over the internet (connected mode) or exchange files by hand (disconnected mode, for air-gapped sites).

    What changed in VCF 9.1

    The VCF 9.1 release notes say licences are now stored in a license server instead of in VCF Operations, and that the license server installs automatically with VCF Operations 9.1. VCF Operations is still where you manage licences. In connected mode, a new licence file is downloaded to VCF Operations every 24 hours; you can turn this off and update by hand. Broadcom's VCF 9.1 licensing blog adds that one vCenter can now hold several primary licence types, such as VCF and VCF Edge, that licensing APIs are open to all customers, and that the Business Services console has new roles for licence refresh, tenant licence management and read-only access.

    The release notes also describe override licences: you can assign a licence directly to an ESX host or vSAN cluster that is connected to a licensed vCenter, for example a VCF licence on the vCenter and VCF Edge licences on some hosts. Licence usage for ESX 8.x and 9.x hosts is now reported in one view.

    VCF 9.1 licence reporting flow vCenter instances and their ESX hosts and vSAN clusters consume licence capacity assigned in VCF Operations, whose licences are held in the local license server. VCF Operations exchanges usage data and licence files with the VCF Business Services console, automatically every 24 hours in connected mode, or by manual upload and download at least every 180 days in disconnected mode. vCenter instances ESX hosts vSAN clusters consume capacity VCF Operations assign and monitor License server new in 9.1 VCF Business Services console vcf.broadcom.com entitlements Connected mode Usage sent and new licence file applied every 24 hours (9.1) can be switched to manual Disconnected mode Upload usage file, download and import licence file by hand at least every 180 days
    Figure 3. How licence capacity and usage reporting flow in VCF 9.1, based on the VCF 9.1 release notes and Broadcom's 9.0 and 9.1 licensing blogs.
    Do not miss the 180-day report. The VCF SPD makes compliance reporting mandatory for version 9 and above: a report 180 days from the start of the subscription and every 180 days after that. If a timely, unaltered report is not transmitted or uploaded, the SPD says management plane features will be degraded or blocked and support entitlements, including access to updates and upgrades, will be suspended. Disconnected sites need a named owner and a calendar reminder.

    How to count cores with Broadcom's PowerCLI script

    Broadcom KB 313548, "Counting Cores for VMware Cloud Foundation and vSphere Foundation and TiBs for vSAN", attaches a PowerCLI module that reads your inventory from vCenter and reports the core and vSAN TiB licences you need. William Lam's January 2024 post on the script refers to the same KB by its older number, 95927. The KB says it needs PowerCLI 13.3 or later and Windows PowerShell 7.4.6 or later. KB 400416 has an updated script for vSphere 8.0 Update 3.

    1. Download the module

      Get FoundationCoreAndTiBUsage.psm1 from KB 313548. For several vCenters, the KB also attaches MultiVcCoreAbdTiBUsage.psm1.

    2. Check every core is enabled

      The KB says results may be wrong if cores are disabled in the BIOS, and the SPD says disabled cores still need licences. Enable all physical cores before you run it.

    3. Connect and import

      Connect to vCenter with Connect-VIServer, then import the module.

    4. Run it for VCF or VVF

      Use -DeploymentType VCF or VVF. Add -ClusterName for one cluster and -CSV to export.

    5. Read both CSV files

      The export writes two files. The one with -vsan in its name holds the TiB figures.

    These are the commands as given in KB 313548:

    Connect-VIServer -Server vCenter_Server
    Import-Module .\FoundationCoreAndTiBUsage.psm1
    Get-FoundationCoreAndTiBUsage -DeploymentType VCF
    Get-FoundationCoreAndTiBUsage -DeploymentType VVF

    If PowerShell's execution policy blocks the module, the KB gives Set-ExecutionPolicy -Scope Process -ExecutionPolicy Bypass, which only applies to the current session.

    Output fieldWhat it tells you
    NUM_CPU_SOCKETSPhysical processors in the host
    NUM_CPU_CORES_PER_SOCKETPhysical cores in each processor
    FOUNDATION_LICENSE_CORE_COUNTLicensed cores after the 16-core minimum
    vSAN_LICENSE_TIB_COUNTvSAN TiB entitlement from those cores
    REQUIRED_VSAN_TIB_CAPACITYRaw vSAN TiB the host contributes

    Table 3. Main per-host fields in the KB 313548 script output. The script also prints "Total Required Licenses" and "Total Required vSAN Add-on Licenses".

    For a host with no vCenter, KB 313548 says you can read "Cores per socket" under the host's Hardware, CPU Processors view, but you cannot get raw vSAN capacity from the UI. Nested ESX labs are a special case: KB 431120 explains that a nested host built with many single-core virtual sockets is counted at 16 cores per socket, and fixes it by changing the VM's topology to fewer sockets with more cores each.

    A worked example: counting a hypothetical estate

    The numbers below are invented to show the method. They are not a sizing recommendation and do not describe any real client.

    The estate has three clusters. A workload cluster of 6 hosts, each with 2 CPUs of 32 cores. A management cluster of 4 older hosts, each with 2 CPUs of 12 cores. A small branch cluster of 3 hosts, each with 1 CPU of 8 cores. All three run vSAN and all will be licensed for VCF.

    Worked example: licensed cores and vSAN add-on for three clusters Hypothetical estate. Workload cluster, 6 hosts with 2 CPUs of 32 cores, 384 licensed cores. Management cluster, 4 hosts with 2 CPUs of 12 cores raised to 16, 128 licensed cores. Branch cluster, 3 hosts with 1 CPU of 8 cores raised to 16, 48 licensed cores. Total 560 licensed cores from 504 physical cores. vSAN entitlement 560 TiB against 574 TiB raw, so 14 TiB add-on. Hypothetical estate: three VCF clusters Workload cluster 6 hosts × 2 CPUs × 32 cores, 480 TiB raw vSAN 384 cores Management cluster 4 hosts × 2 CPUs × 12 cores, raised to 16, 64 TiB raw 128 cores Branch cluster 3 hosts × 1 CPU × 8 cores, raised to 16, 30 TiB raw 48 cores Total licensed: 560 cores 504 physical cores plus 56 added by the 16-core minimum vSAN: 574 TiB raw needed, 560 TiB included Entitlement is pooled across clusters, so the add-on is 14 TiB
    Figure 4. Worked example with invented numbers, using the counting and pooling rules in Broadcom KB 313548.

    Step by step

    The workload cluster is simple: 6 × 2 × 32 = 384 cores, all physical. The management cluster has 96 physical cores, but each 12-core CPU is counted as 16, so it needs 4 × 2 × 16 = 128 core licences. The branch cluster has 24 physical cores and is counted as 3 × 1 × 16 = 48. The estate needs 560 core licences for 504 physical cores, so 56 licences pay for cores that do not exist.

    For vSAN, 560 VCF cores bring 560 TiB of entitlement. The three clusters contribute 480, 64 and 30 TiB of raw capacity, 574 TiB in total. Because entitlement can be spread across clusters and excess aggregated, the shortfall is 574 minus 560, so 14 TiB of vSAN add-on. If you worked cluster by cluster without pooling, the workload cluster alone would look 96 TiB short (480 raw against 384 entitled), and you could be quoted far more add-on capacity than you need.

    Now suppose the management cluster is due for a hardware refresh. Replacing those four hosts with three hosts of 2 × 16-core CPUs would drop the cluster from 128 to 96 licensed cores, provided three hosts still meet your availability design. Our recommendation is to run this sum before you choose CPUs for any refresh. Whether it saves money overall depends on hardware cost and your renewal terms, so take the numbers to your reseller.

    Common over-buying mistakes

    Mistake 1

    Counting hosts, not cores

    Quoting "per host" or per socket with an assumed core count. Count actual cores per CPU with the script, then apply the 16-core floor.

    Mistake 2

    Forgetting the minimum

    CPUs with fewer than 16 cores cost more than they look. Factor the floor into hardware choices at refresh time.

    Mistake 3

    Retired hosts still in vCenter

    Capacity is assigned to vCenter and its managed hosts are licensed from it. Remove decommissioned hosts before you count or report.

    Mistake 4

    vSAN shortfall per cluster

    Entitlement can be pooled across VCF clusters. Work out the add-on against the total, using raw TiB.

    Mistake 5

    DR hosts nobody counted

    Standby hosts with the software installed have cores. Size them for what you will recover and agree their licensing.

    Mistake 6

    Nested labs at full rate

    Single-core virtual sockets in nested ESX count as 16 each. Fix the VM topology as KB 431120 describes.

    Retired and idle hosts

    In VCF 9.x you assign capacity to a vCenter, and the hosts that vCenter manages are licensed from that pool. A host that has been powered off for a year but is still in the inventory is still a host under that vCenter. Our recommendation is to reconcile the vCenter inventory against your CMDB and remove anything retired before you run the counting script or send a usage report. The same goes for test clusters someone built and forgot.

    DR site cores

    The SPD says each core on a server where the software is installed must be licensed, and we found no carve-out for standby hosts in the documents we read. The SPD does allow recovery and testing activities for up to 15 days per year per environment in aggregate, using the embedded evaluation mode, and it allows use as a Migration License through evaluation mode. Those allowances cover short recovery, test and migration windows. A DR site that runs all year is outside them. If you keep warm hosts at a second site, size them for the workloads you will actually recover, and agree their licensing with Broadcom or your reseller in writing. Our disaster recovery services team can help you work out what the recovery site really needs to run.

    Do

    • Run the KB 313548 script against every vCenter and keep the CSVs
    • Enable all physical cores before counting
    • Compare raw vSAN TiB against pooled entitlement
    • Clean retired hosts out of vCenter first
    • Ask for written confirmation of any minimum order quantity

    Avoid

    • Counting logical processors or hyperthreads
    • Using usable datastore capacity as the vSAN figure
    • Turning cores off in the BIOS to cut the count
    • Assuming DR hosts are free
    • Renewing last year's quantity without a fresh count

    How to right-size before a VCF renewal

    We start this work at least three months before the renewal date, which leaves time for hardware changes and for the reseller to requote. On a single vCenter estate the count itself takes an afternoon. The clean-up and the decisions around it take longer.

    Right-sizing flow before a VCF renewal Six steps in order: run the counting script on every vCenter; remove retired and test hosts; find CPUs under 16 cores; pool vSAN raw TiB against entitlement; decide DR and standby hosts; agree the final quantity with Broadcom or your reseller. 1. Count Run the KB 313548 script on every vCenter 2. Clean up Remove retired, idle and forgotten test hosts 3. Low-core CPUs List CPUs under 16 cores; plan refreshes 4. vSAN Pool raw TiB against 1 TiB per VCF core 5. DR and standby Size recovery hosts and agree licensing 6. Agree quantity Confirm with Broadcom or your reseller
    Figure 5. The right-sizing sequence we use before a VCF or VVF renewal.
    • Counting script run against every vCenter, CSVs saved with the date
    • All physical cores enabled in the BIOS before counting
    • Retired, powered-off and test hosts removed from vCenter inventory
    • CPUs with fewer than 16 cores listed with their extra licence cost
    • Raw vSAN TiB compared with pooled entitlement, add-on worked out once
    • DR and standby hosts sized and their licensing agreed in writing
    • Add-ons (vDefend, Avi, Live Recovery, extra vSAN) listed separately
    • Owner and reminder set for the 180-day compliance report

    If the renewal is tied to an upgrade, read our guides to upgrading VCF 5.2 to VCF 9.1 and vSphere to VCF migration and upgrade paths. The VCF 5.x vs 9.x comparison explains the wider platform changes, including why VCF Operations now sits at the centre of licensing.

    VMware Cloud Foundation consultancy

    Want a second opinion on your VCF quote?

    We count cores and vSAN capacity across your vCenters, clean up inventory, and give you a written summary to take to Broadcom or your reseller. We do not sell licences, so the count is independent.

    Book a licensing review

    Frequently Asked Questions about VCF core licensing

    Is VMware Cloud Foundation 9.1 licensed per core or per CPU?

    Per core. Broadcom's VCF SPD says VCF is subscription software licensed per core, with a minimum of 16 cores counted for each physical processor.

    Do hyperthreads count towards VCF core licences?

    No. The SPD defines a core as a single physical computational unit of the processor, so logical threads from Hyper-Threading or SMT are not counted. The KB 313548 script reports physical cores per socket.

    Can I disable cores in the BIOS to need fewer licences?

    No. The SPD says every core on the server must be licensed, including cores deactivated by the BIOS. KB 313548 also asks you to enable all physical cores before running the counting script.

    Is there a 72-core minimum for VMware orders?

    Not in the Broadcom documents we checked. A 72-core per-order minimum was reported in March 2025, then reported as withdrawn in April 2025, and KB 313548 and the May 2025 SPD state only the 16-core per processor minimum. Ask your reseller to confirm any minimum quantity on your quote.

    How much vSAN capacity comes with VCF?

    VCF includes 1 TiB of raw vSAN capacity per licensed core, pooled across the cores where vSphere in VCF runs. VVF includes 0.25 TiB per core, rounded up, and extra capacity is bought as a vSAN add-on per TiB.

    Where do I get the official core counting script?

    Broadcom KB 313548, which was KB 95927 before the move to the Broadcom knowledge base, attaches the FoundationCoreAndTiBUsage PowerCLI module. It needs PowerCLI 13.3 or later.

    Does VCF 9.1 still use licence keys?

    Mostly no. VCF 9.x uses a single licence file managed in VCF Operations and, in 9.1, stored in a local license server. Broadcom's VCF 9.0 licensing blog said some add-ons, such as vDefend Firewall and Avi Load Balancer, still used keys.

    What happens if I miss the 180-day usage report?

    Management features can be degraded or blocked. The VCF SPD says failure to send a timely, unaltered compliance report leads to degraded or blocked management plane functions and suspended support, including access to updates and upgrades.

    Sources

    Written by the Consult Circle VMware HCX migration team. Last reviewed 3 November 2026.

    Share this article: