IBM PVU Calculator & Licensing Assessment: 15-Point Checklist

IBM publishes PVU values by processor brand, family, and generation. A 4-core Intel Xeon Platinum 8380 carries a higher PVU-per-core value than a 4-core Xeon E5 from three generations earlier. Organisations that locked their PVU table at the time of initial ILMT deployment and never updated it run a systematic over- or under-licensing risk as hardware is refreshed. Run a PVU table audit whenever new server hardware is provisioned and whenever IBM publishes a table update, which typically occurs at major processor generation releases.

Not all IBM products support sub-capacity PVU licensing. Products running on hypervisors not on IBM's approved virtualisation list must be licensed at full capacity, covering the entire physical server's PVU count regardless of VM size. Deploying an IBM product on a VMware vSphere environment that meets sub-capacity requirements gives very different cost results than deploying on a non-approved hypervisor. Validate the virtualisation technology for each IBM product deployment against IBM's approved sub-capacity virtualisation list, which is updated periodically.

IBM's sub-capacity PVU calculation for virtual machines is based on the maximum number of vCPUs assigned to the VM at any point during the billing period, multiplied by the PVU value for the underlying physical processor. This is not a utilisation-based metric: a VM that runs at 5% CPU but has 8 vCPUs assigned is licensed for 8 vCPUs worth of PVUs. ILMT captures this maximum assignment value. Where VMs are over-provisioned relative to actual workload, rightsizing the vCPU assignment reduces PVU cost and is a legitimate and straightforward optimisation.

IBM's sub-capacity rules for public cloud are more restrictive than on-premises virtualisation. Most public cloud instance types do not qualify for sub-capacity PVU licensing. Organisations that assume their AWS or Azure deployments automatically qualify for sub-capacity pricing make a systematic compliance error. IBM's Passport Advantage sub-capacity eligibility documentation lists approved cloud configurations. For most cloud deployments, full-capacity PVU licensing applies, meaning the PVU count covers all the physical cores in the underlying host, not the vCPUs assigned to the instance.

ILMT's software catalogue determines how installed IBM software is discovered, mapped to licence metrics, and calculated. A stale catalogue causes products to be unrecognised (creating apparent non-compliance), misidentified (producing incorrect PVU calculations), or mapped to outdated metrics. IBM releases catalogue updates regularly. Assign a calendar alert for quarterly ILMT catalogue refresh, and validate that all IBM products in the environment appear correctly in the ILMT software inventory after each update.

ILMT calculates sub-capacity PVUs based on the hardware inventory it knows about. A physical host not in ILMT scope is not monitored for IBM software, which means IBM software on that host is outside the sub-capacity calculation. In an audit, IBM will cross-reference the ILMT hardware inventory against your actual server estate and will identify gaps. Any host with IBM software that was not in ILMT scope during the audit period will be charged at full capacity for that period. Review ILMT hardware coverage quarterly and at every infrastructure provisioning event.

IBM auditors request ILMT quarterly reports as the primary evidence of sub-capacity PVU compliance. ILMT retains historical data internally, but data can be lost in ILMT upgrades, database migrations, or server failures. The safe practice is to export quarterly reports as PDFs or CSV files, store them in a document management system with access controls, and retain them for a minimum of three years. Missing quarterly reports prompt IBM to default to full-capacity PVU billing for the periods not evidenced.

ILMT is IBM's free sub-capacity reporting tool but has scalability limitations at very large estates. IBM BigFix Inventory is a paid alternative that provides the same sub-capacity licensing compliance functionality with enhanced discovery, reporting, and software asset management capabilities. Both are IBM-approved for sub-capacity purposes. Organisations with 10,000-plus endpoints sometimes find that BigFix Inventory's discovery accuracy and reporting quality reduces audit risk sufficiently to justify the licence cost.

Sub-capacity PVU cost is determined by assigned vCPUs, not utilisation. VMs provisioned with more vCPUs than the workload requires generate avoidable PVU charges. A VM running an IBM middleware product with 16 assigned vCPUs but consistent CPU utilisation below 20% almost certainly can be reduced to 8 vCPUs with no performance impact, halving the PVU charge for that product. A targeted VM right-sizing review for IBM software VMs — distinct from a general infrastructure optimisation — typically surfaces 10 to 20% PVU reduction opportunities in most enterprise estates.

IBM's PVU table assigns different values to different processor architectures. Some processor families carry significantly lower PVU-per-core values than others for equivalent computational performance. While this is rarely the primary hardware selection driver, for very large IBM software deployments the PVU-per-core difference between processor choices can translate into substantial annual licensing cost differences. Architecture teams should include IBM PVU implications in the hardware selection criteria for any infrastructure that will run significant IBM software workloads.

Several IBM products — including Db2, WebSphere, and IBM MQ — are available under both Authorised User (per named user) and Processor Value Unit (per CPU) licensing. The optimal metric depends on the ratio of users to processors. High user counts on small infrastructure favour PVU licensing; small user counts on large infrastructure favour Authorised User licensing. The break-even ratio shifts with every infrastructure change. Model both scenarios at renewal and after any significant change to either user count or server estate.

The most common source of IBM audit findings is IBM software deployed without an entitlement check. Development teams install IBM middleware, databases, or tooling from freely downloadable packages — treating them as open source equivalents — without recognising that download does not imply licence. IBM's audit detection relies on ILMT discovery of installed software. Once deployed, IBM software creates a licence obligation from the date of installation, not the date of discovery. A pre-deployment IBM software entitlement check — requiring approval from the SAM team before any IBM product can be installed — is the most effective prevention control.

Third-party SAM tools provide valuable IBM PVU reporting capabilities but use their own discovery and calculation logic that does not always produce identical results to ILMT. IBM's audit position is that ILMT or BigFix Inventory is the authorised measurement tool. If ILMT and your SAM platform produce different PVU numbers, IBM will default to the higher value. Run parallel reporting from both platforms quarterly and investigate discrepancies of more than 5% before they become an audit issue.

IBM's licensing position on DR environments is nuanced. Some IBM products include DR entitlements within the production licence, permitting installation in standby configurations. Others require a separate DR licence. Running IBM software in a DR environment without the correct entitlement — even if the environment is powered off 99.9% of the time — creates a compliance gap. IBM auditors specifically examine DR environments. Document the DR licensing basis for every IBM product in standby configurations and ensure it aligns with the specific product's licence terms.

IBM software licences are generally portable across hardware, but the PVU count must be recalculated on the new hardware using the current PVU table. If new hardware has higher PVU-per-core values than the retired hardware, the same number of processors now requires more PVU licences. This is a common source of silent compliance exposure discovered at audit — organisations migrate software to new servers, ILMT updates the hardware inventory and PVU calculation, but no one reviews whether the existing entitlement count still covers the new PVU requirement. Trigger a PVU reconciliation at every hardware refresh event.