VMware cost per VM: building a showback model for vSphere after Broadcom

How to calculate VMware cost per VM

VMware cost per VM is the yearly platform cost spread over what each VM takes. To calculate the cost of a virtual machine on VMware, add up the yearly cost of the platform, divide it by the capacity you can hand out in one allocation unit, and multiply the resulting rate by what each VM allocates or uses. The platform cost covers the VVF or VCF subscription on licensed cores, support where it is a separate line, hardware depreciation, storage, network, power and space, and the operating effort of the team that runs it. The allocation unit is a vCPU, a GB of memory, or measured demand in GHz and GB.

Showback reports that figure to departments and application owners without moving any internal budget; chargeback bills it. This article works the method in units and placeholders, since the rates are your own.

Cost categories, drivers and data sources

Collect the categories per cluster, because clusters differ in hardware generation, storage tier and licence tier, and VCF Operations also computes its base rates per cluster.

Categories follow the cost drivers in Broadcom’s VCF Operations 9.1 documentation (Overview of Cost Drivers, updated 21 September 2026), with the vSAN and backup rows added by us; core rule from Broadcom KB 313548.

Keep direct costs apart from the shared pool. A guest operating system licence or a backup line that belongs to one VM goes to that VM and is not spread over the cluster; VCF Operations treats OS labour, VM labour and certain desktop licences the same way and removes them from the compute cost before it computes base rates. Storage is also priced separately, per GB and per tier, so a VM on a fast datastore does not raise the rate of a VM on capacity disks.

Why per-core subscriptions change the result

Under perpetual licences, a cost model could leave the hypervisor out once the licence was paid for, because only support recurred. Since VVF and VCF are subscriptions, the licence is a yearly cost again. Broadcom’s KB 313548 states that “VCF and VVF core licensing is based on the total number of physical CPU cores across all ESXi hosts you intend to license”, with at least 16 cores per CPU even when a CPU has fewer. The same article requires “core licenses for all physical CPU cores on each CPU running the software” and asks for all cores to be activated when its counting script runs, since disabled cores can make the result inaccurate.

The licence is a cost of the host. A host with two 24-core CPUs carries 48 licensed cores whether it runs 20 VMs or 60, so the licence share per vCPU falls as the consolidation ratio rises and climbs when a cluster holds idle headroom. Hosts with low-core CPUs carry rounded-up cores they do not have, and that rounding lands in every VM’s rate. How the count is made and what it does to small clusters is in our article on VMware licensing after Broadcom; which tier the estate needs is covered in Standard, VVF or VCF at renewal.

Choosing the allocation unit

The unit decides who pays for spare capacity and how often a department’s figure moves. The model in this article uses two units at once, vCPU and GB of memory, and splits the compute pool between them with a ratio. VCF Operations does the same with a cluster cost ratio between CPU and memory, set from 1 to 10 for each in its cost settings.

Our comparison; demand behaviour from Broadcom’s VCF Operations 9.1 page Editing Cluster Cost Calculation Methods, updated 5 October 2026.

Allocation-based rates put the cost of a 16 GB VM on its owner even when it uses 4 GB, which gives owners a reason to accept right-sizing. That is where showback and the clean-up work in where the waste is in a vSphere estate support each other. Demand-based rates follow use but are harder to plan, since a department’s figure changes when other VMs go quiet.

Cost and showback in VCF Operations 9.1

VCF Operations computes cost from cost drivers. Broadcom’s 9.1 documentation lists server hardware (traditional and hyper-converged), storage, licence, maintenance, labour, network, facilities and additional costs, plus application cost. Broadcom writes that the reference costs VCF Operations fills in “might not be accurate”. Server hardware is entered per server as owned or leased, with purchase date and purchase cost per server. For ESX 8.0 and later the licence driver is charged per core, and the documentation says the total licence cost is divided across all hosts in the data centre, with a Customize License Assignment option to change the cost per host. Check that split when hosts differ in core count. Storage is entered as a monthly cost per GB per datastore, by storage tag and type.

Base rates are computed per cluster. The CPU and memory base rates divide the cluster’s CPU and memory cost by capacity, prorated by expected utilisation. Two cluster cost methods are documented. With Cluster Usable Capacity After HA and Buffer, base rates come from the cluster’s total cost and its usable capacity after HA and buffer. They do not change with utilisation, and the gap between usable capacity and use is computed as unallocated cost. With Cluster Actual Utilization, rates follow the month-to-date average utilisation, unallocated cost stays near zero and Broadcom notes that “Base rates and virtual machine costs can change frequently based on the utilization of the cluster.” With an allocation model, the VM cost is the allocated vCPU times the cluster’s vCPU base rate, plus allocated vRAM times the memory base rate, plus storage and direct cost, and the overcommit ratio can be set per cluster.

The cost settings also hold the depreciation of server hardware for all vCenter instances, with two models, “Straight line” and “Max of Double or Straight”. Broadcom’s 9.1 Cost Settings page gives two ranges for the period. Its procedure under Cost Settings for Financial Accounting Model says to “select the Depreciation Years between two and seven”, while its section Configuring Depreciation Preferences says “you can set the depreciation period from two to five years”. Check the range the field accepts in your installation. For showback, pricing cards turn cost into a price per VM.

1. Replace the reference costs in each cost driver with your own figures.
2. Choose the cluster cost method under Administration, Configurations, Cluster Cost and, for actual utilisation, set the Cluster Utilization Ceiling Factor under Global Settings, Cost/Price.
3. Set the cluster cost ratio between CPU and memory and the depreciation period and model, then run the cost calculation.
4. Create a pricing card under Policy Definitions, VC Pricing: cost-based (cost times a factor) or rate-based (a rate per vCPU, per GB of memory and per GB of storage), with a charging period from hourly to monthly.
5. Decide whether VMs are charged “Always” or “Only When Powered On”, and add guest OS rates, tag-based charges and setup charges where they apply.
6. Assign the card to vCenter instances or clusters; prices recalculate every 24 hours.

Cost Analysis then compares cost and price metrics across custom groups, so one group per department or application gives the showback view.

Worked example: 24 hosts in three clusters

The figures below describe an example estate for a company of about 1,500 staff, with placeholders for every rate. S is the yearly subscription per licensed core, H the purchase cost per host, F facilities per host and year, N the network share per host and year, and E the yearly operating effort of the team.

Example values, not a recommendation; HA deduction as in Broadcom’s VCF Operations 9.1 cluster cost methods, vCPU count as cores times overcommit ratio as in its allocation model page (8 October 2026); core rule from KB 313548.

The ratio of 4 vCPU per core is an example; check your own with CPU ready per vCPU, as our CPU ready guide explains. The yearly compute pool is C = 1,152 × S + 24 × H ÷ 5 + 24 × (F + N) + E, with the hardware written off over five years in a straight line, which both depreciation ranges allow. Storage and backup stay outside C and get their own rate per GB per tier. The example assumes a split of 40 to 60 between CPU and memory, a policy choice within the 1 to 10 range VCF Operations accepts for each. The monthly rate per vCPU is then 0.4 × C ÷ 12 ÷ 4,032 and the monthly rate per GB is 0.6 × C ÷ 12 ÷ 19,354. A VM with 4 vCPU, 16 GB and 200 GB on the first storage tier shows 4 times the vCPU rate, 16 times the GB rate and 200 times that tier’s storage rate, plus its direct costs such as a guest OS licence.

C covers all 24 hosts while the rates divide by usable capacity, so the HA host and the memory buffer are already in the rates. The allocated 3,300 vCPU and 15,800 GB take about 82% of what the clusters can hand out. No VM is charged for the remaining capacity, so report its cost as a separate IT line rather than raising every VM’s rate to absorb it.

Our technical assessment of a VMware estate ends with a report, a TCO and ROI model and an action plan ahead of renewal. Send us your host list, cluster layout and renewal date through the form below.

A three- to five-year horizon and renewal decisions

Build the model over three to five years, with the subscription term from your quote, the depreciation of each host batch and the demand forecast from vSphere capacity planning. Each year then has its own C, licensed core count and capacity.

The same rates answer the renewal questions. A tier change alters S, a host refresh alters H, the core count and the capacity, and host consolidation under per-core licensing alters the number of licensed cores. Where a hosted offer is quoted per vCPU, GB and storage tier, the model’s rates sit next to it in the same units; what a hosted VMware IaaS includes is covered in vSphere as a service in the EU.

Our infrastructure audit compares modernisation, cloud and hybrid scenarios over a 3 to 5 year horizon. Describe the scenarios you weigh before the renewal in the form below, with the host count and the term on your quote.

What we do

Our VMware optimisation service includes an estate and licence audit: versions, subscriptions, actual resource usage, risk profile and TCO, with an independent maturity assessment and options for action. It shows what you pay for now and how much of it is in use, the input a cost per VM needs. The technical assessment produces a report, a TCO and ROI model and an action plan ahead of renewal, and its price is fixed before work begins. Engineering is delivered by our engineering partner Vixen.UNO, with changes in agreed maintenance windows with a rollback plan. Where the decision reaches beyond VMware, our infrastructure audit covers the wider estate.

FAQ