Broadcom’s core count script for VVF and VCF: running KB 313548 step by step

What KB 313548 is, as read in September 2026

Broadcom’s knowledge base article 313548, “Counting Cores for VMware Cloud Foundation and vSphere Foundation and TiBs for vSAN”, is Broadcom’s own reference for the count. Its stated aim is to identify the core and TiB licences “required to properly license VMware vSphere Foundation, VMware Cloud Foundation, and VMware vSAN Add-on”. Its old VMware number, 95927, now redirects to it, its environment list covers ESXi 6.0, 7.0 and 8.0, with VCF 4.5 and 5.1, and this guide follows the page as we read it on 28 September 2026.

The KB offers two routes. For smaller estates, a manual one: each host’s cores per socket, read under Host, Hardware, CPU Processors. For “larger, vCenter-managed environments”, a PowerCLI tool that “collects and consolidates information on the quantity of core licenses (with a minimum of 16 cores per physical CPU) and TiB licenses required for each host connected to a vCenter instance”. The manual route stops at cores: the KB says the product UI cannot show the total raw capacity a vSAN cluster claims, and that manual calculation of vSAN TiB from the UI is “NOT recommended or accurate”.

Two modules are attached. FoundationCoreAndTiBUsage.psm1 is the one the KB documents and this guide uses; the second, MultiVcCoreAbdTiBUsage.psm1 (spelled so on the page), comes without instructions. For 8.0 Update 3 the KB points to KB 400416, which attaches a modified module: the original calls a vSAN API that “does not exist in vSAN 8.0 U3”. We found no separate script for VCF Edge or 9.x. For 9.x the KB notes that licensing hosts and vSAN clusters needs a VCF Operations instance and a vCenter instance, and VCF Operations 9.1 shows licence usage on its Usage Analytics page. The 9.x licence mechanics are in our renewal guide, the 8.x dates in our vSphere 8 end of support guide.

The rule it applies, and the VVF minimum core count

Broadcom’s current programme documents for VVF and VCF, both of June 2026, use the same words: the software is “licensed on a per Core license metric with a minimum licensing requirement of 16 Cores per Processor”, and “Each Core on the Server where Software is installed must be licensed, including Cores deactivated by the BIOS.” A core is “a single physical computational unit of the Processor”, so hyperthreads are not counted. The KB’s own example: a host with two 8-core CPUs and a host with two 24-core CPUs license as 2 × 16 plus 2 × 24, or 80 cores. vSphere Standard’s document of May 2026 sets the same minimum, with no vSAN capacity.

VCF Edge differs. Its own programme document (June 2026) sets a minimum of 8 cores per processor, at least 10 Edge Locations within the first year and no more than 256 cores per Edge Location. The KB documents only VCF and VVF as deployment types, with 16 per CPU, so recount Edge hosts from their socket and core columns.

Neither the KB nor the VVF and VCF programme documents set a minimum per order. The channel reported a 72-core minimum per order in March 2025, and distributors and the German magazine iX reported it withdrawn in April; yet Broadcom’s vmware.com site still hosts an undated video titled “Broadcom’s New 72-Core Order Minimum Explained”. Ask for the minimum applied to your quote in writing; the rules and that story in full are in our licensing guide.

Before you run it

The KB lists three prerequisites: VMware PowerCLI 13.3 or greater, PowerShell 7.4.6 or greater, and the attached script, downloaded and extracted. Since version 9.0 the tool is called VCF PowerCLI; Broadcom calls 9.0 “a continuation of VMware PowerCLI 13.3”, so the lower number is the newer release. KB 393240, written for a failure of the script on vSAN 8.x, asks for PowerShell 7.5.0 or higher, so 7.5.0 or later satisfies both articles.

Settle four things first. The KB names no vCenter role; Broadcom’s vSphere security guide says a user with No Access on an object “cannot view or change the object in any way”, so run it with an account whose permissions cover every host and cluster in that vCenter. The KB warns that if cores are disabled “in the BIOS settings or other means, the script may produce inaccurate results”, and asks for all physical cores to be active when it runs. Its troubleshooting section names “ESX servers disconnected from vCenter” and PDL devices among the causes of errors that may change the number of TiB licences, so reconnect hosts first. And if PowerShell refuses to load the module as not digitally signed, the KB’s fix is Set-ExecutionPolicy with -Scope Process and -ExecutionPolicy Bypass, a change that affects only the current PowerShell session.

Running it, step by step

The KB’s procedure has three steps. Replace the KB’s placeholders, vCenter_Server, Cluster_Name and name.csv, with your values.

First, connect to the vCenter: Connect-VIServer -Server vCenter_Server. Second, import the module from the folder you extracted it to: Import-Module followed by .\FoundationCoreAndTiBUsage.psm1 or, on 8.0 Update 3, the modified file from KB 400416 under its own file name. Third, run Get-FoundationCoreAndTiBUsage with -DeploymentType VCF or -DeploymentType VVF. By default, in the KB’s words, “the script will iterate through all vSphere Clusters”.

Three parameters change the run. -ClusterName "Cluster_Name" limits it to one cluster. -CSV writes the results to files, and -Filename "name.csv" sets the name. The KB notes that you then “receive two files”: the one with -vsan appended holds the TiB figures, the other the core figures.

In every example pair in the KB the core count is the same for both deployment types; what changes is the vSAN entitlement, 1 TiB per core for VCF and 0.25 TiB for VVF. Take the core count from a run without -ClusterName, because a run limited to one cluster leaves out hosts that belong to no cluster. If some clusters will be licensed as VCF and others as VVF, add one run per cluster with -ClusterName and its own type for the vSAN figures.

Reading the output

The output has three parts. Host Information has one row per host: CLUSTER, empty when the host is not part of a cluster; VMHOST, the host IP address per the KB; NUM_CPU_SOCKETS; NUM_CPU_CORES_PER_SOCKET; FOUNDATION_LICENSE_CORE_COUNT, the core licences the host needs with the 16-core minimum applied; and vSAN_LICENSE_TIB_COUNT, the TiB that those core licences bring. A host with two 8-core CPUs, for example, should show 2, 8 and 32. Cluster Information gives REQUIRED_VSAN_TIB_CAPACITY, the TiB each cluster needs to license. In the totals, Total Required Licenses is the sum of the core column. Total Required vSAN Add-on Licenses is the required TiB less the TiB from the Foundation offer: zero or a negative figure means no add-on and, the KB adds, “excess capacity can be aggregated”; a positive figure is the add-on to buy.

Two of the KB’s worked examples show the minimum and the vSAN arithmetic:

Broadcom KB 313548, example scenarios, read on 28 September 2026.

Raw capacity counts in whole TiB, rounded up: 184.32 TiB less 144 included leaves 41 to buy. Broadcom’s vSAN 8 licensing page rounds the same way, where 14.1 TiB “rounds up the license usage to 15 TiBs”, and the KB gives VVF’s 0.25 TiB per core as “rounded up to the next TiB”.

Several vCenters, and the total against the quote

The KB documents the module with a single vCenter connection and no procedure for several; the one below is ours. Run all three steps, and the policy bypass if you needed it, once per vCenter, in a new PowerShell session each time, with -CSV and a different file name. Then add up the core licences of every run, kept apart per product line if the estate will mix VVF and VCF, and the raw TiB of every vSAN cluster, and set the TiB against the entitlement of that product line’s cores. The KB’s own calculation also sums the raw storage of all hosts “in every cluster”, and Broadcom’s VVF 9.1 FAQ confirms that the “vSAN entitlement can be aggregated across clusters”; the programme documents allow this only across cores of the same product.

Then read the quote against your count. The core quantity of each product line should equal your total for the hosts it will cover; a higher figure needs an explanation in writing, whether a host you missed, a minimum missed in a manual count or an order minimum. The vSAN add-on line should equal the raw TiB of your vSAN clusters, rounded up to whole TiB (vSAN 8 rounds each cluster up), less the entitlement: 0.25 TiB per VVF core, rounded up to the next TiB, or 1 TiB per VCF core. Our quote checklist takes the rest of the document line by line.

If the count shows more hosts than the workloads need, see where the waste is. For a layout that does not exist yet, Broadcom’s KB 312202 offers a calculator, Get-VCFandVVFCalculator, which takes one CSV row per planned cluster and returns the core licences and vSAN TiB required. If this data is missing before the renewal window, our VMware optimisation service starts with an audit of the estate and its licences and then matches editions to the real workloads.

Checks that catch a wrong count

Six checks from the KB and Broadcom’s related articles, before the figure goes into a quote:

Broadcom KB 313548, 393240 and 400416; VVF and VCF programme documents of June 2026.

Two more KBs explain vSAN figures that look wrong: in KB 381817, a failed disk on a vSAN OSA host, unplugged but never removed, keeps counting towards capacity; in KB 387458, a cluster with disks set up under vSAN 7.x on all-flash hosts upgraded to ESXi 8.0 shows 0 TB of licence usage, and the script reports the stale PDL error. Both are fixed on the hosts before the count is repeated.

What we do

Eurokommerz supplies VMware / Broadcom licensing together with our engineering partner Vixen.UNO: audit, licensing and deployment under one European contract. In VMware optimisation the Vixen.UNO team audits the estate and its licences, matches editions and subscriptions to the real workloads within Broadcom’s current licensing logic, and sets out an action plan ahead of renewal and end of support, with dates. Modernisation of vSphere, vSAN, NSX and VCF follows in agreed maintenance windows with a rollback plan, then support under an agreed SLA. The first step is a free call; the technical assessment is paid, with its price fixed before work begins, and our infrastructure audit covers the estate beyond VMware.

FAQ