IBM sub-capacity licensing cuts PVU cost by 60 to 80 percent against full capacity on a virtualized estate, but the saving only applies when the IBM License Metric Tool is deployed and producing clean quarterly reports, and defaults back to full capacity the moment that condition fails. The choice between the two is therefore not really a choice. Sub-capacity is the right answer for almost every virtualized IBM deployment, and full capacity is the penalty for not meeting the conditions. This comparison sets out how each counts, what the cost difference looks like, the exact ILMT requirement, and the cases where full capacity is genuinely unavoidable.
Inside This Guide
Full versus sub-capacity defined
Full capacity licensing means you license every physical processor core in the server where an IBM product is installed, regardless of how much of that capacity the product actually uses. On a virtualized host, full capacity can extend further, to every core in every host the workload can run on across a cluster. Sub-capacity licensing means you license only the virtual cores made available to the product, which on a consolidated estate is a small fraction of the physical total. Both use the same Processor Value Unit metric and the same per-PVU price; the difference is entirely in how many cores you are required to count.
That difference is the single largest variable in most IBM bills. The same WebSphere or Db2 deployment can be licensed at a handful of virtual cores or at an entire physical cluster, a swing of ten times or more, decided only by which counting basis applies. This page sits under our complete IBM licensing guide; the sub-capacity mechanics in full are in our IBM sub-capacity licensing guide.
IBM built this two-tier structure deliberately as virtualization spread. When most servers were physical, the full-capacity count matched real use closely enough. Once a single large host could run many lightly loaded workloads, full capacity overstated consumption by an order of magnitude, and IBM introduced sub-capacity to keep its software economically viable on virtualized hardware, in exchange for the measurement discipline that ILMT provides. Understanding that history explains why the burden of proof sits with the customer: sub-capacity is a concession from the default, and IBM conditions it on evidence it can audit.
How each counts PVUs
Under full capacity, the count is mechanical: total the physical cores in scope, multiply each by its PVU rating from the IBM processor table, and that is your licensable PVU figure. A common x86 core rates at 70 PVUs, so a 64-core physical environment is 4,480 PVUs whether the IBM product uses all of it or one core of it. Under sub-capacity, the count is the peak virtual cores allocated to the product over the measurement period, rated the same way, so the same product confined to four virtual cores is 280 PVUs. The PVU rate and the per-PVU price are identical; only the core base changes.
The reason sub-capacity is conditional is that IBM cannot take your word for the virtual figure. It requires an auditable, automated measurement, which is the role of ILMT. Full capacity needs no tool because it assumes the maximum, so it is always available as the fallback. Sub-capacity needs the tool because it claims less than the maximum, and the tool is the proof.
Side-by-side matrix
| Factor | Full capacity | Sub-capacity |
|---|---|---|
| Cores counted | All physical cores in scope | Virtual cores allocated to the product |
| Typical relative cost | Baseline (highest) | 60% to 80% lower |
| Tooling required | None | ILMT, deployed and maintained |
| Reporting | Not required | Quarterly reports, retained 2 years |
| Default if conditions fail | This is the default | Reverts to full capacity |
| Best for | Physical servers, no virtualization | Virtualized and consolidated estates |
The cost difference
The cost gap is the whole point of the comparison. On a virtualized estate where IBM products run on a few virtual cores within large physical hosts, sub-capacity routinely reduces the licensable PVUs by 60 to 80 percent, and on heavily consolidated clusters the reduction can exceed 90 percent. The table models a single product across the two bases at a representative $200 per PVU before discount.
| Scenario | Cores counted | PVUs | Cost before discount |
|---|---|---|---|
| Full capacity, 4-host cluster, 2x16-core | 128 | 8,960 | $1,792,000 |
| Sub-capacity, product on 8 vCores | 8 | 560 | $112,000 |
| Full capacity, single 32-core host | 32 | 2,240 | $448,000 |
| Sub-capacity, product on 4 vCores | 4 | 280 | $56,000 |
The saving is real but conditional: Sub-capacity is not a discount IBM grants out of goodwill. It is an entitlement you qualify for by running ILMT correctly. The 60 to 80 percent reduction is yours only as long as the quarterly reports exist. Let ILMT lapse and the same deployment reverts to the full-capacity figure, retroactively, in an audit.
The 90-day rule deserves particular attention because it is where new deployments most often fall out of compliance. The clock starts at the first eligible sub-capacity deployment, not at the next audit or the next renewal, so a team that stands up a new virtualized IBM workload and plans to sort out ILMT later has already started a countdown it may not know about. Building ILMT coverage into the standard provisioning process for any IBM product removes the risk, because the tool is then in place before the deployment that needs it goes live.
The ILMT condition
Sub-capacity eligibility rests on four requirements, and all must hold. ILMT must be installed within 90 days of the first sub-capacity deployment. It must cover every eligible server in scope, with no gaps. It must generate quarterly reports. And those reports must be retained for at least two years and reconciled to your entitlement. Miss any one and IBM is entitled to bill the affected servers at full capacity for the period the condition was not met. The setup and operational detail is in our IBM ILMT guide.
The practical failure modes are mundane and common: ILMT installed but not covering a newly added cluster, an upgrade that breaks the data collection, or reports generated but never reviewed or retained. Each converts a sub-capacity entitlement into a full-capacity liability without anyone noticing until the audit. Treating ILMT as a quarterly operational discipline, not a one-time install, is what protects the saving.
When full capacity applies
Full capacity is the correct, and sometimes only, basis in a few situations. A product running directly on physical hardware with no virtualization has no virtual core figure to claim, so full capacity is simply the count. A virtualization technology that IBM does not recognize as eligible for sub-capacity also forces full capacity, which is why the eligible-technology list matters when choosing a hypervisor. And an estate that cannot or will not run ILMT has no way to prove sub-capacity, so full capacity is the default it has accepted by omission.
The first case is legitimate and unavoidable. The second is a planning input: choosing an IBM-eligible virtualization platform preserves the sub-capacity option. The third is almost always a mistake, because the cost of running ILMT is trivial against the full-capacity penalty it avoids. For estates weighing this, our IBM optimization practice sizes the gap.
When a full-capacity recalculation does land in an audit, the same separation of past and future that governs any settlement applies. The back-claim is computed at full capacity for the unproven period, but a buyer who can demonstrate that the deployment was always virtualized and eligible, and that the only failure was a reporting gap rather than genuine over-deployment, has a strong argument to settle below the headline recalculation. The aim is to fix the proof going forward and to limit the backward claim to the narrowest defensible window, which is core to our audit defense work.
Audit implications
The full-versus-sub-capacity question is where most IBM audit value is found, because the auditor default is full capacity. If you claim sub-capacity but cannot produce clean ILMT reports for the period, the auditor recalculates at full capacity and the difference, often a multiple of the expected figure, becomes the claim. The defense is entirely preventive: maintain the reports so the sub-capacity position is provable on demand. The audit process is in our IBM audit defense practice and the wider software audit defense playbook.
This is why the two bases cannot be treated as an open commercial choice. You do not negotiate full versus sub-capacity at the audit; you either have the proof or you do not. The work that determines the outcome happens quarters before the notice arrives.
It is worth stating plainly that there is almost no scenario where a virtualized estate is better off on full capacity. The ILMT overhead is a small, fixed operational cost, while the full-capacity premium scales with the size of the estate and recurs every year. Even a mid-size virtualized environment saves multiples of the ILMT cost in the first quarter of correct reporting. The decision is therefore less a comparison of equals than a checklist: confirm eligibility, run the tool, keep the reports, and the cheaper basis follows automatically.
The verdict: which when
Choose sub-capacity when any IBM product runs on a supported virtualization platform, which is the large majority of modern estates. The saving is 60 to 80 percent or more, and the only cost is the operational discipline of running ILMT correctly. For virtualized WebSphere, Db2, MQ, and similar PVU-licensed products, sub-capacity is the default correct answer and full capacity is money left on the table.
Accept full capacity when the product runs on physical hardware with no virtualization, when the virtualization technology is not on the IBM sub-capacity eligible list, or as a deliberate, costed fallback for a small environment where the ILMT overhead genuinely outweighs the saving, which is rare. In every other case, full capacity is not a choice but a penalty for missing the sub-capacity conditions.
The practical rule: If your IBM products are virtualized, the question is not whether to use sub-capacity but whether your ILMT proves it. Fix the proof, and the cheaper basis is automatically yours. The only estates that should plan for full capacity are genuinely non-virtualized ones.
Action steps
The sequence is short. Confirm whether each IBM product is virtualized and on a sub-capacity-eligible platform. Verify ILMT is installed, covers every eligible server, and is producing and retaining clean quarterly reports. Reconcile the sub-capacity figure to your entitlement and resolve any gap. And for any product genuinely stuck on full capacity, decide whether a platform change to recover sub-capacity eligibility pays for itself, which on a large estate it usually does.
For the full IBM picture, start with the complete IBM licensing guide, the sub-capacity guide, and the ILMT guide. For engagement help, our IBM practice validates the position and our software licensing advisory service handles the optimization end to end.