Run the methodology with a senior advisor.
A senior Admodum advisor will walk the methodology through with your CIO, CFO, SAM or sourcing team on a private call. Engagements run as fixed fee, contingency or annual retainer.
Thirty pages on the IBM sub-capacity construct, ILMT health protocol, PVU computation, RVU and instance-based metrics, the audit notification response, evidence and counter-evidence, Passport Advantage anchoring, the settlement boundary and the Red Hat subscription overlap.
Sub-capacity is the IBM commercial concession that lets the buyer license PVU-based software against the virtual capacity each workload consumes rather than the full physical capacity of the host. The construct was introduced in the mid-2000s to bring IBM’s commercial model into alignment with virtualisation reality. It is, in 2026, the single most consequential entitlement category inside the IBM software portfolio for the buyer with a virtualised estate.
The construct is governed by a defined set of preconditions. The buyer must operate one of the eligible virtualisation technologies (VMware vSphere, Hyper-V, KVM, PowerVM, z/VM and a defined list of others). The buyer must run IBM License Metric Tool (ILMT) inside the estate. The ILMT must produce a quarterly Audit Snapshot Report. The deployment must comply with the IBM sub-capacity terms (cluster boundaries, snapshot retention, version currency, scan coverage). The buyer who meets all four preconditions licenses at virtual capacity; the buyer who does not licenses at full physical capacity of every host on which an eligible product is deployed.
The economic gap between virtual and physical capacity is, in most virtualised estates, a factor of three to ten. The sub-capacity construct is therefore not a compliance nicety. It is the single largest license-cost lever in the IBM portfolio.
The buyer’s IBM commercial posture rests on whether the preconditions are met. Where they are met, the buyer’s renewal and audit posture is materially stronger than the publisher would prefer. Where they are not met, every PVU-based product in the estate is exposed at full host capacity, and the audit risk is large enough that the buyer’s remediation programme must run before the next IBM audit notification, not after.
ILMT health is the operational discipline that keeps the sub-capacity preconditions met. The discipline is not a one-off implementation. It is a quarterly cycle of scan coverage, snapshot review, exception management and report archival that runs continuously across the buyer’s IBM PVU-eligible estate.
The first ILMT health discipline is scan coverage. Every eligible host inside the cluster boundary must be scanned by ILMT. Every PVU-eligible product on every eligible host must be inventoried by the scan. Where the scan agent is not deployed on a host, the host’s products are read at full physical capacity. The coverage report must be reconciled against the CMDB and the hypervisor inventory monthly.
The second ILMT health discipline is snapshot retention. The Audit Snapshot Report must be generated quarterly, archived for at least two years and reproducible at any future audit window. The buyer who generates the snapshot but does not archive it has not satisfied the IBM evidence requirement, even if the underlying scan was run.
The third ILMT health discipline is version currency. IBM publishes a supported-version matrix for ILMT and BigFix Inventory; an ILMT version outside the matrix is read as non-compliant. The buyer’s SAM function must therefore track the ILMT version, the underlying BigFix Inventory version and the catalogue currency, with a documented upgrade cycle that keeps each component inside the supported matrix.
The fourth ILMT health discipline is exception management. Hosts that cannot be scanned (PCI environments, isolated networks, regulatory boundaries), products that cannot be inventoried (closed-source distributions, container-embedded binaries), workloads that exceed the catalogue’s reading must each be documented as an exception with a justification trail. The exception register is the evidence the buyer presents at the audit window to defend the gaps that ILMT itself does not close.
The Processor Value Unit is the IBM metric that translates physical and virtual processor capacity into a license-counting denomination. The PVU value of a CPU is set by the PVU table IBM publishes; the PVU value of a workload is the PVU rate of the CPU multiplied by the core count consumed by the workload.
The PVU table assigns different PVU values to different CPU families and generations. A modern x86 core typically carries 70 PVUs per core. A historical IBM POWER core carries higher PVUs per core. The buyer’s PVU count therefore depends on the CPU mix in the estate as much as on the workload count.
Under sub-capacity, the PVU count is the virtual processor count consumed by the workload, multiplied by the PVU rate of the underlying CPU, subject to the high-water-mark rule (the workload’s peak consumption across the reporting period sets the PVU count for the period). Under full-capacity, the PVU count is the entire physical processor count of every host on which the workload is deployed, multiplied by the PVU rate, regardless of actual workload consumption.
The buyer’s license-count reconciliation runs against the ILMT Audit Snapshot Report’s PVU column, normalised against the Passport Advantage entitlement, with the high-water mark documented per product across the reporting period. Where the snapshot reports a PVU consumption that exceeds the entitlement, the buyer has a compliance gap; where it does not, the buyer has a defensible compliance posture.
Not every IBM product is licensed on PVUs. The Resource Value Unit, the Authorised User, the Concurrent User, the Floating User, the Managed Virtual Server, the Install, the Instance and a long tail of vertical metrics each carry their own counting logic. The buyer must read the metric on each entitlement line; the assumption that PVU governs the whole IBM estate is a common buyer-side reading error.
The RVU metric scales with the resource the product manages. A storage-management product might be RVU-priced against terabytes managed. A networking product might be RVU-priced against ports or endpoints. A backup product might be RVU-priced against protected nodes. The reconciliation must run against the same evidence ILMT provides for PVU products, but against an additional data source (the storage estate, the network inventory, the protected node count) that ILMT itself does not measure.
The instance metric is increasingly common across IBM’s newer SaaS and container-based products. An instance is, in IBM’s reading, a running deployment of the product; the count scales with the deployment topology rather than the resource consumed. Buyers running container-based deployments of IBM products must therefore reconcile the instance count against the container topology, with attention to how horizontal scaling, multi-tenant deployment and ephemeral workloads affect the count.
The IBM audit notification arrives as a formal letter from IBM Audit Services (or, increasingly, from a contracted third-party audit firm acting on IBM’s behalf). The notification names the audit scope, the audit window, the data-request list and the audit contact. The notification is the trigger for the buyer’s defence programme.
The first response to the notification is not the data submission. The first response is the scope contestation. The audit notification is, in most engagements, drafted with a scope that is broader than the buyer’s contractual exposure: it may name products outside the buyer’s entitlement, time periods outside the audit-right window, or affiliates outside the contracting entity. The buyer’s first letter back to IBM Audit Services should narrow each of those boundaries to the contracted scope.
The second response is the data-handling protocol. The audit data is not handed to IBM’s commercial team. It is held under attorney-client privilege where the jurisdiction permits, exchanged through a controlled data-room, redacted for personally identifiable information and confidential business data, and accompanied by a documented chain of custody. The casual data submission that is common in the first week after the notification is the single largest source of audit-defence leakage in IBM engagements.
The buyer who treats the audit as a compliance exercise runs the audit on IBM’s terms. The buyer who treats it as a negotiation runs it on the buyer’s.
The audit-defence evidence is the documented entitlement, the documented deployment, the documented reconciliation and the documented exception register. The counter-evidence is the analysis that contests IBM’s reading of the buyer’s deployment when the publisher’s reading exceeds the buyer’s.
The entitlement evidence is the Passport Advantage portfolio: every line, every metric, every quantity, every effective date, every entitlement transfer, every entitlement retirement. The portfolio must be reconstructed inside a single canonical view, reconciled across the buyer’s historical procurement records, IBM’s entitlement system and the buyer’s contracting history.
The deployment evidence is the ILMT Audit Snapshot Report, supplemented by the hypervisor inventory, the CMDB, the application inventory and (where ILMT does not measure the metric directly) the resource inventory for RVU products. The deployment evidence must be reproducible at any point inside the audit-right window.
The counter-evidence is the analysis that contests IBM’s reading line by line. Where IBM reads a product as deployed at full host capacity, the counter-evidence demonstrates the ILMT scan coverage, the cluster boundary, the workload-to-host mapping and the high-water mark that defends the sub-capacity reading. Where IBM reads a product as deployed without entitlement, the counter-evidence demonstrates the entitlement transfer history, the contract-of-record and the workload assignment.
Passport Advantage is the IBM commercial container inside which most software licenses and Subscription & Support are held. The Passport Advantage agreement defines the entitlement terms, the renewal cycle, the discount level (via the Suggested Volume Pricing tier) and the audit rights. The buyer’s commercial posture across IBM rests on the Passport Advantage anchor.
The SVP tier the buyer holds defines the discount level on new licence acquisition and on Subscription & Support renewal. The tier is set by historical purchase volume and is sticky downward; a buyer whose IBM portfolio is reducing in size will not see the SVP tier drop unless an active commercial reset is negotiated. The anchoring is therefore an asset the buyer should defend against any commercial restructure that puts the tier at risk.
The Subscription & Support renewal is the cyclical event around which the Passport Advantage anchor is reset or extended. The renewal letter, the price increase (typically four to seven percent absent negotiation), the entitlement reconciliation and the new-license bundle pitch sit inside this annual event. The buyer’s response must run as a structured negotiation, not as a renewal acceptance: the entitlement reconciliation in particular is the moment to retire shelfware, consolidate entitlements and reset the SVP tier upward where new acquisition is planned.
The settlement boundary at the close of an IBM audit is the negotiated commercial position that records the compliance findings, the settlement value and the forward-looking commercial commitment. The boundary is not the audit’s arithmetic. It is a commercial negotiation in which the arithmetic is one input.
The forward-looking commercial commitment is the lever the buyer should engage. IBM’s settlement narrative will often offer to convert the cash settlement into a forward-looking commitment (new licence acquisition, expanded Subscription & Support, Cloud Pak adoption, watsonx commitment). The conversion is, on the surface, a buyer-friendly framing. In practice, the buyer must reconcile the converted commitment against the buyer’s actual forward consumption plan; a converted commitment that does not align to the buyer’s plan is a forward shelfware position the buyer pays for twice.
The settlement letter is the closing instrument. The letter must record the compliance position settled, the entitlement position carried forward, the future-audit window covered (if a moratorium is negotiated, as it should be in most settlements) and the forward-looking commitment in scope. A settlement letter that leaves any of the four elements ambiguous is a future audit notification waiting for the next cycle to arrive.
IBM’s acquisition of Red Hat introduced an entitlement model into the IBM commercial relationship that overlaps with, but does not align to, the Passport Advantage construct. The buyer with both an IBM Passport Advantage estate and a Red Hat Enterprise Linux estate must therefore manage two adjacent commercial cycles that touch but do not consolidate.
The Red Hat subscription is a per-instance or per-socket-pair (per-CPU) commercial unit, with separate SKUs for OS, the OpenShift container platform, Ansible, the storage portfolio and the supporting products. The subscription is sold under Red Hat’s commercial terms, not under Passport Advantage; the renewal cycle, the discount logic, the audit framework and the SVP-equivalent tiering all run inside Red Hat’s commercial process rather than IBM’s.
Where IBM products are bundled inside Cloud Pak SKUs that include Red Hat OpenShift, the buyer must read carefully whether the Red Hat entitlement carried inside the Cloud Pak is sufficient for the deployment topology or whether incremental Red Hat subscription is required. The Cloud Pak entitlement scope and the Red Hat subscription scope are reconciled at the buyer’s deployment, not at the contract; the buyer who assumes the bundle is sufficient may discover at the next Red Hat renewal that the standalone subscription has expanded inside the bundle’s shadow.
The IBM ILMT and sub-capacity paper sits inside a broader infrastructure and platform reading list. The companion papers extend the methodology to adjacent commercial mechanics:
The methodology in this paper is the methodology Admodum has applied across fifty-two IBM audit-defence and renewal engagements inside the firm’s engagement history. Each engagement is structured as fixed fee, contingency / gainshare or annual retainer, depending on the buyer’s posture at the audit or renewal window.
A senior Admodum advisor will walk the methodology through with your CIO, CFO, SAM or sourcing team on a private call. Engagements run as fixed fee, contingency or annual retainer.