IBM Sub Capacity Licensing Explained.

Why sub capacity matters.

Sub capacity is the single largest cost lever in the distributed IBM software estate. A correctly licensed sub capacity environment runs at a fraction of the full capacity price of the same workload. The contractual mechanism is straightforward. The operational discipline that keeps the entitlement valid is where most enterprises lose ground. This pillar guide is the complete buyer side reading on sub capacity.

The starting position is the IBM Sub Capacity Licensing Terms. The buyer agrees to count entitlement against the virtual processor footprint rather than the underlying physical capacity. In return the buyer agrees to deploy IBM License Metric Tool (ILMT), scan eligible servers continuously, generate the quarterly Audit Snapshot reports, retain them for two years, and respond to IBM with the data on request. If any of those operational conditions fails, the buyer falls back to full capacity licensing on the affected servers. The full capacity fallback is the single largest avoidable cost in most enterprise IBM estates.

The complete buyer side reference set sits across this pillar, the IBM Licensing Complete Guide, the ILMT Guide, the sub capacity expertise page, and the Sub Capacity Licensing Guide white paper.

1. The sub capacity rules.

Sub capacity availability turns on three contractual conditions. The product must be on the IBM list of Sub Capacity eligible products. The deployment must run on an eligible virtualization technology. The customer must meet the operational requirements set out in the Sub Capacity Licensing Terms attachment. All three conditions must hold for every server every quarter. The omission of any one of them on any server returns that server to full capacity licensing.

Eligible products.

The eligible product list is published by IBM and updated periodically. Most PVU based middleware (WebSphere, MQ, DataPower, Tivoli monitoring family, Db2 enterprise editions, InfoSphere DataStage, the Cognos suite) is sub capacity eligible. Most VPC based modern products are sub capacity eligible by default. The mainframe stack and a small set of legacy server based products are not.

Eligible virtualization.

The recognised technologies include VMware vSphere, KVM, Microsoft Hyper V in specific configurations, IBM PowerVM LPAR and Workload Partitions, AIX WPAR, Solaris zones in specific configurations, z VM for distributed workloads on z hardware, and the public cloud hypervisors of AWS, Microsoft Azure, Google Cloud, and IBM Cloud through the IBM Cloud sub capacity terms. Container platforms are treated separately and the container licensing reference covers that case.

Operational requirements.

The operational frame is the deployment of ILMT, continuous scanning of the eligible servers, generation of the quarterly Audit Snapshot reports, retention of the reports for two years, and the readiness to respond to an IBM audit request with the data. The detail of each requirement is in the ILMT guide.

2. ILMT and the four reports.

ILMT is the IBM tool the customer deploys to make sub capacity work. The buyer side discipline around ILMT decides whether sub capacity stays valid. The four required reports are the Audit Snapshot for each licensed product family, the Software Inventory report for the discovered installations, the Hardware Inventory report for the underlying servers, and the operational scan logs that evidence the continuous coverage.

The Audit Snapshot is the report IBM auditors request first. It documents the high water mark virtual capacity for each licensed product across the quarter. The retention rule is two full years rolling. A buyer presenting a stale Audit Snapshot, or a missing quarter inside the two year window, has lost sub capacity eligibility on the affected products for that quarter. The ILMT best practices reference covers the operating model. The ILMT Deployment Playbook white paper documents the rollout.

3. Which products are eligible.

The IBM Sub Capacity eligibility list is a moving document. The buyer side discipline is to verify eligibility per product per release at the deployment decision point, not to assume the inheritance of a prior eligibility decision.

4. The hypervisor matrix.

The hypervisor decides the counting rule. The same workload on VMware vSphere, IBM PowerVM, KVM, or Hyper V will be counted differently. The buyer side discipline is to verify the recognised configuration for the chosen hypervisor at the deployment design stage. A workload running on an unrecognised configuration of an otherwise recognised hypervisor is counted at full capacity.

The two hypervisors where this trip wire fires most often are VMware vSphere (the cluster level affinity rules) and Microsoft Hyper V (the recognised configurations are narrower than buyers expect). The virtualization rules reference walks through the operational positions per hypervisor. The sub capacity expertise page covers the broader frame.

5. Sub capacity in the cloud.

Sub capacity is available on AWS, Microsoft Azure, Google Cloud, and IBM Cloud through the IBM Cloud Sub Capacity terms attachment. The cloud sub capacity model counts entitlement against the provisioned virtual machine size. The same product moving from an on premise VMware footprint to an AWS EC2 footprint is typically counted on a comparable vCPU basis, with the BYOL bring your own licence assumption underpinning the move.

The buyer side trap in the cloud is the unmanaged scaling. An auto scaling group that briefly scales out to 80 vCPUs during a peak has consumed 80 vCPUs of entitlement at the peak. ILMT continues to track the peak. The renewal conversation is the conversation about the average usage, but the audit conversation is the conversation about the peak. The cloud sub capacity reference covers the operational rules per hyperscaler.

6. Cluster pricing rules.

The cluster pricing rule applies to a defined set of products on a defined set of virtualization platforms. The rule states that entitlement is counted against the union of the eligible hosts in the cluster, not against the virtual machine footprint. The cluster boundary matters more than the workload footprint. A vSphere cluster of 12 hosts with a 4 vCPU workload running on only 2 of those hosts may still consume entitlement against all 12 hosts if the affinity rules are not enforced.

The buyer side discipline is to enforce DRS affinity rules, document the affinity in the change record, and reconcile the ILMT report against the documented affinity each quarter. The cluster pricing rule is the single largest source of unexpected capacity in customers running PVU based middleware on shared vSphere clusters.

7. The 90 day evidence window.

The Sub Capacity Licensing Terms attachment defines a 90 day window for the customer to produce the ILMT data on request. The 90 day window is the operational deadline the customer commits to when accepting sub capacity. A customer that cannot produce the data within 90 days has not met the sub capacity operational requirements and the affected servers are subject to full capacity licensing for the period.

The 90 day evidence window is the metric the audit defence work measures against. The 90 day evidence reference covers the discipline. The audit defense service covers the engagement frame for the audit itself.

8. Sub capacity inside an audit.

When an IBM audit arrives, the sub capacity work is the first material work the auditor performs. The auditor requests the four reports for every product and every quarter inside the audit period. The auditor reconciles the reports against the entitlement record and the underlying hardware inventory. Any gap between the reports and the auditor expectation produces a finding.

The buyer side defence is preparation. A clean ILMT environment, a documented exception log for the known gaps, a settled position on cluster pricing affinity, and a clean hardware inventory are the four conditions for a successful sub capacity defence inside an audit. The audit defense playbook walks through the engagement frame. The IBM Audit Defense Playbook white paper covers the formal process.

9. Ten common pitfalls.

1. ILMT deployed, then allowed to drift. Scan coverage drops below 100 percent on the eligible servers.
2. Audit Snapshot reports retained for less than the required two year window.
3. Cluster pricing affinity not enforced. Entitlement counts against the full cluster, not the workload footprint.
4. Hardware inventory in ILMT out of sync with the actual server inventory. Decommissioned servers still consuming entitlement.
5. Tivoli monitoring agents propagated without an inventory. Agent count is many multiples of the licensed entitlement.
6. MQ Advanced workloads running on MQ Standard entitlement. The edition gap is invisible without ILMT validation.
7. Cloud workload auto scaling unmonitored. ILMT captures peak, the buyer is unaware of the peak.
8. BigFix or BigFix Inventory used as the scan source without the matching ILMT entitlement. Sub capacity is not honoured.
9. ILMT version out of support. IBM does not accept the data from an unsupported version.
10. The team that owns ILMT rotated out and no successor took ownership. ILMT decays for six quarters undetected.

Each is preventable with a small amount of disciplined operational work. The licence harvesting work picks up the unused entitlement. The licence consulting service covers the broader operational frame. The ILMT best practices reference covers the operating model.

10. Frequently asked questions.

Does sub capacity require ILMT for every IBM product?

For PVU based products yes. For VPC products under the modern licensing rules the IBM License Service plays the equivalent role and the deployment is typically inherited from the platform install. For RVU, UVU, and user based metrics, sub capacity is not the relevant concept and ILMT is not required.

Can sub capacity be applied retroactively?

No. The sub capacity treatment applies from the quarter the operational requirements are met forward. The unprotected period is licensed at full capacity. This is a frequent surprise in audits where ILMT was deployed mid period.

What if ILMT cannot scan a specific server?

The customer must either bring the server inside the scan coverage or accept full capacity licensing on that server. There is no manual workaround that preserves sub capacity for a server outside the scan.

How does sub capacity interact with Cloud Paks?

Cloud Paks are VPC based and the sub capacity treatment is automatic once the IBM License Service is deployed in the OpenShift cluster. The buyer side work is the verification that the License Service is healthy and the entitlement allocation is correct. The Cloud Pak strategy reference covers the detail.

What is the difference between sub capacity and the full capacity fallback?

Sub capacity counts the virtual processor footprint of the workload. Full capacity counts the entire physical capacity of the underlying server, regardless of how the workload is sized. On a typical 2 socket 64 core host running a 4 vCPU workload, the full capacity reckoning is roughly 16 times the sub capacity number.

Where to go next.

For the ILMT operational reading continue to the ILMT Guide and the ILMT Best Practices reference. For the product specific reading continue to the IBM Product Licensing Guide. For the audit reading continue to the audit pillar and the audit defense service. For the negotiation reading continue to the renewal pillar. The white paper library and the insights blog remain available for ongoing reference.

For a scoped advisory conversation, the contact page is the entry point. A senior advisor responds within 24 hours.