IBM sub-capacity licensing lets you license IBM software for the virtual capacity a product can use rather than every physical core in the server, but only if the IBM License Metric Tool is deployed and reporting within ninety days. The buyer-side read on the PVU metric, ILMT and Passport Advantage.
IBM sub-capacity licensing lets an enterprise license an IBM product for the virtual processing capacity it can actually use, rather than for every physical core in the machine it happens to run on. Admodum is an independent, buyer-side software licensing advisory firm; we represent the customer and never the vendor, and this page sets out what sub-capacity is, what it requires, and where it most often goes wrong.
The default in IBM's processor-based licensing is full capacity: you license every activated core in the physical server. Sub-capacity is the concession that, on eligible virtualisation technologies and for eligible products, you may instead license the smaller virtual allocation a workload is given, for example four virtual cores carved out of a thirty-two core host. The commercial difference is enormous, but the concession is conditional. It is granted under the Passport Advantage agreement and is contingent on the customer running the IBM License Metric Tool (ILMT) and keeping it reporting. Treat sub-capacity as a default and you will discover, usually at audit, that you owe full capacity.
The financial stakes are why this matters more than most licensing topics. IBM's processor-based products, WebSphere Application Server, MQ, Db2, the Cognos and InfoSphere families, and dozens more, sit at the heart of enterprise transaction systems, so the deployments are large and the per-unit pricing is high. An estate that has drifted into a full-capacity exposure can carry a compliance gap measured in millions, and because the gap accrues quietly over years of unmanaged infrastructure change, it is usually invisible until IBM initiates a review. The buyer-side objective is therefore not merely to "be compliant" in the abstract, but to hold, at all times, the specific evidence that converts an IBM assertion of full capacity into a defensible sub-capacity position.
This is the pillar page for IBM's processor-based compliance model. It links down to five focused companions: how the PVU metric works and how IBM counts cores, ILMT deployment and the 90-day sub-capacity rule, the structure of the Passport Advantage agreement, surviving an IBM software licence review, and IBM part numbers, supporting programs and bundling traps. The wider editorial context sits in the IBM licensing hub and the IBM knowledge hub.
A PVU, or Processor Value Unit, is the unit in which IBM prices most of its processor-based software, including WebSphere, MQ, Db2 and Cognos. The principle is simple: not all processor cores are equal, so IBM assigns each core a per-core PVU rating and you license the number of cores a product can use multiplied by that rating.
The per-core rating comes from IBM's published Processor Value Unit table, which maps chip families to a value, almost always between 50 and 120 PVUs per core. A commodity x86 core is typically rated at 70 PVUs; certain IBM Power cores carry 100 or 120; some older or constrained chips sit at 50. So a product that needs four cores on a 70-PVU processor requires 280 PVUs of entitlement, while the same four cores on a 120-PVU processor require 480. The metric rewards no one for buying faster silicon; it simply scales the licence to the processing power exposed to the software.
Two things make PVUs treacherous in practice. First, the rating is per core, and modern servers carry a great many cores, so small-looking deployments generate large PVU requirements. Second, the question of which cores count is exactly where full capacity and sub-capacity diverge. For the full treatment of the table and the counting rules, see IBM PVU licensing explained.
It helps to understand why IBM built the metric this way. Before PVUs, IBM priced per processor, but the rise of multi-core chips meant a single socket could deliver many times the throughput of an earlier one at the same nominal price. The PVU table re-based pricing onto a unit that tracks delivered processing power, so a sixteen-core socket costs proportionally more to license than a four-core socket of the same family. The consequence for buyers is that hardware refresh decisions are licensing decisions: moving an IBM workload onto a denser, higher-core-count server can raise the PVU requirement even if utilisation is unchanged, and a refresh business case that ignores the IBM PVU impact will understate true cost.
A worked figure makes the stakes concrete. Take a mid-sized WebSphere estate of ten hosts, each with two sockets of sixteen cores, all rated at 70 PVUs. Full capacity is 10 × 32 × 70 = 22,400 PVUs. If WebSphere actually runs in virtual machines totalling forty virtual cores across the estate, the defensible sub-capacity figure is 40 × 70 = 2,800 PVUs. The gap between those two numbers, roughly nineteen and a half thousand PVUs, is the difference a single missing ILMT deployment can put on an audit finding, and at IBM list pricing that is a multi-million-pound exposure on one product family.
The whole compliance question turns on a single boundary: which cores does IBM get to count? Under full capacity, the answer is every activated core in the physical server. Under sub-capacity, the answer is only the virtual cores available to the IBM product, subject to a cap of the physical capacity.
Consider a thirty-two-core host rated at 70 PVUs per core. Full capacity is 32 × 70 = 2,240 PVUs for any eligible product installed on that host. If the product runs in a virtual machine pinned to four virtual cores, sub-capacity is 4 × 70 = 280 PVUs. That is an eight-fold difference on a single host, and real estates contain dozens or hundreds of hosts. This is why the question of eligibility is not academic; it is usually the largest single line in an IBM exposure.
Crucially, sub-capacity is not automatic. You do not earn the lower figure by simply running in a VM. You earn it by being on an eligible technology, deploying an eligible product, and proving the virtual allocation with ILMT data. Absent any of those, IBM is contractually entitled to the full-capacity number. The pull-quote below states the rule that catches the most organisations.
The asymmetry of this arrangement is the heart of the buyer-side problem. The technical default in a virtualised data centre is that a workload sees a small allocation, so engineers reasonably assume the licensing follows the technology. It does not. The contractual default is full capacity, and the burden of proof for the lower figure sits entirely with the customer. IBM does not have to demonstrate that you owe full capacity; you have to demonstrate, with retained evidence, that you qualify for sub-capacity. That reversal of the burden of proof is what makes IBM compliance unlike most other vendors, and it is why an estate can be perfectly well-architected and still carry a large exposure simply because nobody produced the paperwork.
The IBM License Metric Tool (ILMT) is the free software IBM provides to discover eligible products, identify the virtual and physical capacity available to each, and produce the audit reports that substantiate a sub-capacity claim. For almost every customer, running it is not optional; it is the price of admission to sub-capacity terms.
ILMT works by deploying an agent or using agentless scanning across the estate, building an inventory of installed IBM software, mapping each installation to the virtual machine and physical host that bound its capacity, and computing the peak PVU consumption over a rolling period. The output is the quarterly audit report that demonstrates a customer licensed correctly. IBM's contractual expectation is that the tool is installed within ninety days of the first eligible deployment, configured to scan every relevant host, run at least every thirty minutes for capacity discovery and generate reports at least quarterly, with those reports retained for a minimum of two years.
The practical failure modes are mundane and costly: a newly built cluster never added to ILMT, an agent that silently stopped reporting, a version of ILMT too old to recognise a current product, or reports generated but never retained. Each of these converts a defensible sub-capacity position into a full-capacity exposure for the affected period. The full deployment discipline, including the precise scope of the ninety-day window, is covered in ILMT deployment and the 90-day sub-capacity rule.
It is worth being precise about what ILMT is and is not. It is the tool IBM accepts as the standard evidence for sub-capacity, built on the same technology lineage as IBM's wider asset-management products, and it is provided at no licence charge to Passport Advantage customers. It is not, however, a set-and-forget appliance. ILMT needs an owner who treats its coverage as a live control: every new host, every new IBM product, and every infrastructure change is a potential gap in the scan. Many organisations run ILMT but cannot, when asked, demonstrate that it covered the whole estate for the whole period, and that gap between "we have ILMT" and "we have complete, retained ILMT reports" is precisely where audit findings live.
IBM also recognises a small number of approved alternatives to ILMT in defined circumstances, such as certain Flexera and other software-asset-management tools that IBM has verified for sub-capacity reporting, and the container-native metering built into IBM's own licensing service for Cloud Paks. These do not remove the underlying obligation; they change the tool that satisfies it. The governing principle is unchanged: the customer must hold complete, retained, accurate capacity evidence for every eligible product, by some IBM-accepted means, or accept full-capacity pricing.
Sub-capacity eligibility rests on a small set of conditions that must all hold. Fail any one and the affected products revert to full capacity for the period of the failure.
The conditions, in plain terms, are these. The product must appear on IBM's Eligible Sub-Capacity Products list. The virtualisation technology must be an Eligible Virtualisation Technology on a supported processor. ILMT must be installed and collecting data within 90 days of the first eligible deployment in that environment, the 90-day rule. ILMT reports must be generated at least quarterly and retained for two years. And the customer must not be using a virtualisation configuration that allows unbounded mobility without the corresponding licensing, because where a workload can migrate freely across an unrestricted cluster, IBM may count the whole cluster.
The ninety-day rule is the one most often missed. It does not start when you first think about ILMT; it starts the day the first sub-capacity-eligible product goes live in a virtual environment. New estates, acquisitions, and lift-and-shift cloud projects routinely breach it because nobody owned the clock. Where the window is genuinely unworkable, very small enterprises, broadly those under about a thousand employees, may use a documented manual calculation instead, but the evidentiary burden does not go away.
A subtlety that catches even diligent teams is that the conditions are continuous, not one-off. Passing them at deployment is necessary but not sufficient; they must hold for every quarter you wish to claim sub-capacity. A product that was correctly licensed and reported for three years but then dropped out of ILMT coverage for two quarters has, on IBM's reading, a two-quarter full-capacity exposure regardless of the earlier good record. This is why Admodum treats sub-capacity compliance as an operational control with an owner and a calendar, rather than a project that is "done" once ILMT is installed.
The other subtlety is acquisitions. When an enterprise buys another business, it inherits that business's IBM deployments and its ILMT gaps, and the ninety-day clock on any newly virtualised or newly migrated workloads runs from the operational change, not from the legal close. Integration programmes that move acquired IBM workloads onto the parent's virtual infrastructure without extending ILMT coverage are a recurring and expensive source of exposure, precisely because the licensing question is rarely on the integration checklist.
Passport Advantage is IBM's standard volume licensing and Subscription & Support framework, and it is the contract under which sub-capacity actually lives. The right to license at sub-capacity, and the obligations that accompany it, are set out in the Sub-Capacity Licensing attachment and the associated terms, not in any technical manual.
Understanding the agreement matters because the leverage and the risk both originate there. Passport Advantage defines the Subscription & Support (S&S) stream, the renewal mechanics, the audit clause, the site and enterprise structure, and the attachments that govern sub-capacity. When IBM asserts a full-capacity position, it is invoking these terms; when a customer defends a sub-capacity position, it is relying on the same terms plus its ILMT evidence. The agreement is examined in detail at the IBM Passport Advantage agreement structure.
Two structural points are worth flagging here. First, sub-capacity is a privilege the agreement grants and can effectively withdraw through non-compliance, which is why the tooling obligation is taken so seriously. Second, the agreement's audit clause gives IBM the right to verify, and the quality of your ILMT records is what determines whether that verification is a formality or a negotiation about a seven-figure shortfall.
Passport Advantage also shapes the economics of the relationship through Subscription & Support (S&S), the annual stream that funds version upgrades and IBM support and that, in practice, is where most ongoing IBM spend sits. S&S renews against the entitlements on record, so an estate carrying entitlements it no longer deploys is paying support on shelfware year after year, while an estate that is under-licensed is accruing a liability that an audit will crystallise. Reconciling deployed capacity to entitlements is therefore both the compliance task and the cost-optimisation task, and the two are inseparable. The renewal mechanics, the reinstatement penalties for letting S&S lapse, and the leverage available at quarter-end are addressed across the contract negotiation pillar and its companions.
For organisations consolidating spend, IBM offers enterprise constructs above the standard Passport Advantage transaction, including the Enterprise Licence Agreement and Cloud Pak entitlements that re-express PVU products as containerised capacity. These can simplify management and unlock discount, but they also re-paper the compliance obligations rather than removing them, and they introduce new metrics such as the Virtual Processor Core. The structure of those agreements is examined at the Passport Advantage agreement structure and in the negotiation pillar.
The hardest sub-capacity question in modern estates is virtualisation mobility. Where a virtual machine can move across hosts, IBM's rules ask not where the workload is but where it could run, and that distinction can pull an entire cluster into scope.
On VMware specifically, IBM's sub-capacity rules permit licensing the virtual allocation only where mobility is constrained. If live migration is unrestricted across a large cluster, the conservative reading of IBM's terms is that every host the workload could reach must be licensed, because the product could consume capacity anywhere in that cluster. The mitigation is to constrain mobility deliberately: pin IBM workloads to defined host affinity groups, document the boundary, and ensure ILMT sees and reports the constrained topology. Done well, this keeps the licensable footprint small and defensible. Done carelessly, an unbounded vMotion domain converts a four-core allocation into a cluster-wide full-capacity bill.
Public cloud adds its own wrinkles. IBM publishes capacity counting rules for the major hyperscalers, and the virtual core count exposed by an instance type drives the PVU requirement, but ILMT, or an approved equivalent, must still report that capacity. Lift-and-shift projects are a frequent source of the ninety-day breach because the cloud deployment predates anyone configuring discovery. The cross-vendor overlap with VMware licensing is real; for the Broadcom-era VMware context see the Broadcom and VMware coverage.
The Broadcom acquisition of VMware has sharpened this question rather than settling it. As VMware licensing shifts toward subscription bundles and core-count minimums, organisations are re-architecting clusters, consolidating hosts, and in some cases migrating off VMware entirely, and every one of those moves changes the IBM sub-capacity footprint. A cluster consolidation that raises per-host core density raises the full-capacity exposure on any IBM product that loses its mobility constraint; a migration to a different hypervisor may change whether the technology is on IBM's Eligible Virtualisation Technology list at all. The discipline is to treat the IBM PVU position as a dependency of every infrastructure decision, and to model the licensing impact before the change, not after the auditor finds it.
Containerisation is the other direction of travel. IBM increasingly expresses its middleware as Cloud Paks licensed in Virtual Processor Cores rather than PVUs, with metering handled by the IBM Licensing Service inside the cluster rather than by ILMT. This can be a cleaner model for dynamic, container-native workloads, but it is a different metric with its own counting rules and its own evidence requirements, and a hybrid estate that runs both classic PVU products and Cloud Paks must satisfy both regimes at once. The container model is set out in the negotiation pillar's companion on IBM Cloud Paks and the Virtual Processor Core.
A large share of unexpected IBM exposure comes not from the headline product but from what travels with it: supporting programs, bundled components, and the part-number structure that determines what you are actually entitled to.
IBM products frequently include supporting programs, separately shippable components that are licensed under, and only with, the principal program. A common trap is using a bundled Db2 or WebSphere component for a workload beyond the principal program's scope, which converts a free supporting program into a full, separately licensable deployment. Equally, a single product family can be sold under many part numbers with different metrics, and buying the wrong part number, or assuming two part numbers are interchangeable, creates either over-spend or a compliance gap. These mechanics, and how to read an IBM quote and entitlement to avoid them, are set out in IBM part numbers, supporting programs and bundling traps.
The buyer-side discipline is to maintain a clean map from each deployed component to the entitlement and part number that authorises it, and to test, at every renewal, whether bundled components are being used within their supporting-program scope. This map is also the fastest way to spot shelfware, entitlements paid for and never deployed, which is leverage at renewal rather than a compliance risk.
A further trap sits in the distinction between a product's principal program and its restricted-use entitlements. IBM ships many products with components carrying limited-use rights, a Db2 instance licensed only to support a particular application, for example, or a WebSphere edition restricted to a defined role. Using such a component for a general-purpose workload steps outside the restriction and triggers a full, separate licence requirement. Because these restrictions are recorded in the licence information documents rather than on the invoice, they are easy to overlook, and they are a favourite line of enquiry in an IBM review precisely because so few customers track them. The clean component-to-entitlement map is the only reliable defence.
Across documented IBM engagements, the same findings recur. None of them is exotic; all of them are avoidable with ownership and evidence.
Each of these is a contractual exposure rather than a technical bug, which is why it is best addressed before IBM raises it. The defensive playbook, and how an IBM licence review actually unfolds, is covered in surviving an IBM software licence review. The renewal-side leverage that the same evidence creates sits in the IBM contract negotiation and renewal pillar.
A defensible IBM position is a small set of artefacts, kept current. Hold these and both an audit and a renewal become a negotiation you control rather than a discovery exercise IBM controls.
| Artefact | What it proves |
|---|---|
| ILMT report archive | Two years of quarterly reports covering every eligible host, substantiating the sub-capacity claim. |
| Eligibility map | Each deployed product checked against the Eligible Sub-Capacity Products and Eligible Virtualisation Technology lists. |
| Entitlement ledger | PVU entitlements held versus PVU consumed, per product, with part numbers reconciled. |
| Mobility topology | Documented host-affinity boundaries proving VMware clusters are constrained. |
| Shelfware list | Entitlements paid for and not deployed, the credit to recover or repurpose at renewal. |
This is where independence pays. A senior Admodum IBM advisor reads these artefacts against IBM's terms before IBM does, closes the gaps quietly, and turns the same evidence into renewal leverage. The wider engagement sits at the IBM practice and the aggregated reading at the IBM knowledge hub. The companion pillar on commercial strategy is IBM contract negotiation and renewal; engagement opens at contact.
IBM sub-capacity licensing lets an enterprise license an IBM product for the virtual processing capacity it can actually use, rather than for every physical core in the server it runs on. It applies to eligible products on eligible virtualisation technologies, and it is conditional on deploying the IBM License Metric Tool (ILMT) and keeping it reporting. Without eligible ILMT data, IBM licenses the software at full capacity, which is the count of every activated core in the physical machine or cluster.
A PVU, or Processor Value Unit, is IBM's pricing unit for processor-based software. Each processor core is assigned a per-core PVU rating from IBM's published table, typically between 50 and 120 PVUs per core depending on the chip family. The licence requirement is cores multiplied by the per-core rating, so a product needing one core on a 70-PVU chip requires 70 PVU entitlements.
Yes, for almost all customers. To qualify for sub-capacity terms, IBM requires the IBM License Metric Tool (ILMT) to be installed within 90 days of first eligible deployment, configured correctly, and generating audit reports at least quarterly with reports retained for two years. The only common exemption is enterprises below roughly 1,000 employees that may use a manual calculation, though the documentation burden remains.
The 90-day rule requires the IBM License Metric Tool to be installed and collecting data within 90 days of the first sub-capacity-eligible product being deployed in a virtualised environment. Miss the window, fail to scan a host, or let reporting lapse, and IBM is contractually entitled to charge that environment at full capacity rather than sub-capacity for the period the data is missing.
If ILMT is missing, incomplete, or not reporting, IBM defaults the affected products to full-capacity licensing. That means counting every activated core in the physical server, or in the entire cluster where unrestricted live migration is possible, instead of the smaller virtual allocation. In large VMware estates this routinely multiplies the required PVU count three to five times and is the single most common finding in an IBM licence review.
Passport Advantage is IBM's standard commercial framework for licence purchasing and Subscription & Support. Its terms, together with the Sub-Capacity Licensing attachment and the Eligible Sub-Capacity Products list, are what grant the right to license at sub-capacity and what impose the ILMT and reporting obligations. Sub-capacity is therefore a contractual entitlement under Passport Advantage, not an automatic technical default.
Installing and running the tool that proves sub-capacity.
Our white paper sets out the ILMT and sub-capacity compliance model in full, with the evidence checklist IBM auditors test against. A senior Admodum IBM advisor will then read your PVU position and ILMT records before IBM does. Renewal moments route to the Renewal Programme; audit moments to Audit Defence; sign up for the newsletter for vendor-policy alerts.