IBM's sub-capacity licensing model offers significant cost savings by allowing enterprises to license software based on virtual machine capacity rather than full physical servers. However, the benefit comes with strict compliance requirements — most importantly, the proper deployment and use of IBM's License Metric Tool (ILMT). This advisory explains how CIOs can navigate these requirements, avoid costly pitfalls, and maintain audit readiness.
Under full-capacity licensing, an organisation must license an IBM product for the entire capacity of the server — all CPU cores on the machine — regardless of actual usage. In contrast, IBM's virtualization capacity (sub-capacity) licensing allows you to license only the portion of server capacity that the IBM software uses, for example, the CPU cores allocated to a VM running the software.
This model can significantly reduce the number of Processor Value Units (PVUs) or Virtual Processor Cores (VPCs) required on large servers or cloud instances, yielding substantial cost savings. Sub-capacity licensing is especially beneficial in highly virtualised data centres and cloud deployments where workloads are consolidated.
IBM's Passport Advantage agreement specifies that new sub-capacity customers must install and begin using ILMT within 90 days of deploying any eligible IBM software in a virtualised (sub-capacity) environment. From the moment you first run an IBM product on an eligible hypervisor or cloud instance with the intent to license sub-capacity, the clock starts ticking. Failing to deploy ILMT within 90 days technically forfeits your sub-capacity rights for that period.
In the past, IBM allowed limited exceptions to the ILMT requirement — such as very small environments with fewer than 1,000 PVUs or unsupported platforms — where manual tracking was deemed sufficient. As of May 1, 2023, IBM no longer accepts most exceptions to the ILMT mandate. Virtually all customers are now required to use ILMT for sub-capacity licensing. IBM has tightened the rules: to receive the benefit of sub-capacity pricing, you must use ILMT (or an IBM-approved equivalent tool) and meet all associated requirements.
| Licensing Model | How It Works | ILMT Required? | Cost Impact |
|---|---|---|---|
| Full Capacity | License all CPU cores on the physical server | No | Highest cost — pays for unused capacity |
| Sub-Capacity (VMs) | License only the virtual cores assigned to IBM software | Yes — ILMT mandatory | Significant savings — often 60–80% less |
| Sub-Capacity (Containers) | License containerised workloads on Kubernetes/OpenShift | Yes — IBM License Service | Savings depends on cluster configuration |
The IBM License Metric Tool (ILMT) is a software asset management tool provided by IBM — at no charge to IBM Passport Advantage clients — that monitors IBM software deployments and calculates PVU/VPC consumption. ILMT is designed to automatically discover IBM software installed on servers, track the processor core capacity available to those products, and generate reports on your utilisation.
The tool must be configured with agents on all relevant servers or VMs, and it typically performs regular scans (e.g., weekly) to capture any changes in deployment. ILMT can be deployed via BigFix or as a standalone "Lite" agent scanner.
IBM's sub-capacity licensing terms explicitly require ILMT to be deployed and active for any PVU-based software running in a virtualised environment. This means ILMT (or HCL BigFix Inventory, an equivalent IBM-approved tool) needs to be installed, configured, and maintained if you license IBM software on VMs, cloud instances, or any scenario other than full physical isolation.
IBM expects ILMT to run continuously and stay up to date. A CIO should ensure that an ILMT implementation is not a one-time project, but an ongoing operational process — including regularly applying ILMT updates and software catalogue patches. Running an outdated version that fails to detect a new processor type or product could render your compliance data invalid.
Simply installing ILMT is not enough — you also need to use it to generate regular reports. IBM policy requires ILMT to produce audit snapshots at least once a quarter, and organisations should retain at least two years of these reports as evidence of continuous compliance.
Generate ILMT audit snapshots every quarter and review them internally for anomalies, such as unexpected spikes in PVU consumption.
Back up all ILMT reports to a secure repository and periodically test the retrieval process as part of audit readiness.
Align ILMT reporting with quarterly internal audits or ITSM routines. This ensures the critical requirement doesn't slip through the cracks.
A common mistake is deploying ILMT on most — but not all — servers where IBM software resides. IBM requires ILMT to monitor all eligible virtualisation environments where IBM software is installed. Any gap or omission can jeopardise eligibility for sub-capacity.
If one VMware cluster was left out of ILMT scanning, or a department stood up a new AWS VM with IBM software without installing the ILMT agent, that portion of your deployment would not be accounted for. In an audit, IBM can declare that sub-capacity terms do not apply to any untracked installations, resulting in full-capacity charges.
ILMT is the proof that you are respecting IBM's licensing rules. If sub-capacity licensing is a contractually granted privilege, then ILMT is the monitoring mechanism that IBM insists on to allow that privilege. IBM auditors heavily scrutinise ILMT data because without it, customers have little defence to justify sub-capacity calculations. One independent IBM licensing expert describes ILMT as not just a tool, but a "cornerstone" of IBM compliance in virtualised environments.
The most immediate risk of not complying with IBM's sub-capacity requirements is financial exposure. IBM's contracts make it clear that if you do not meet the conditions for sub-capacity, you lose the right to sub-capacity pricing and must pay for full capacity. In an audit, IBM will calculate your licence usage as if every processor core in each physical server is utilised by the IBM software — even if it's constrained to a small VM.
This can multiply licence requirements dramatically. For example, a single WebSphere instance using four cores on a 32-core host could be charged as if it were using all 32 cores. One company discovered that an IBM middleware product running on an unsupported Windows Server 2008 was not eligible for sub-capacity — IBM initially calculated a $16 million licence exposure at full capacity.
When IBM detects unlicensed use, it typically requires not only the purchase of licences to cover the shortfall, but also backdated Software Subscription & Support (S&S) — often up to two years. This means if ILMT non-compliance led to under-licensing 1,000 PVUs for two years, IBM might demand the cost of those PVUs plus 24 months of support. The lack of ILMT constitutes a double hit: loss of future sub-capacity savings and unexpected true-up costs for past periods.
Non-compliance with ILMT and sub-capacity rules doesn't just get discovered in audits — it can trigger audits. IBM knows which customers have agreed to sub-capacity terms and expects to see ILMT data or attestations. A failure to deploy or regularly use ILMT is viewed by IBM as "low-hanging fruit" for compliance issues. Missing or improper ILMT deployment ranks as a top reason for IBM to initiate an audit.
| Non-Compliance Scenario | IBM's Likely Response | Potential Cost Impact |
|---|---|---|
| ILMT not deployed at all | Full-capacity charges for entire environment | Millions in licence fees + back-maintenance |
| ILMT deployed late (beyond 90 days) | Full-capacity for the unmonitored period | Significant — depends on gap duration |
| Quarterly reports missing | Non-compliance claim for unreported periods | Back-charges at full capacity for those quarters |
| Incomplete server coverage | Full-capacity for unmonitored hosts/clusters | Proportional to uncovered environment size |
| Outdated ILMT version | May not recognise new CPUs/products | Compliance gaps treated as untracked usage |
Beyond raw licence fees, non-compliance can carry contractual consequences. Failure to adhere to licensing terms constitutes a breach of the Passport Advantage agreement, which may result in licence termination or legal action in extreme cases. More commonly, it severely weakens the customer's negotiating position. IBM now inserts clauses requiring customers to provide deployment documentation annually — even outside of audits.
From a CIO's viewpoint, an audit that goes poorly due to non-compliance can damage the IT department's reputation within the company. Surprise financial hits from an audit can erode the confidence that the CEO and CFO have in IT governance. Ensuring ILMT compliance is a relatively straightforward way to prevent such a scenario.
Need help assessing your IBM sub-capacity compliance posture?
IBM Licensing Assessment →Ensuring ILMT is properly deployed and managed is a multi-step exercise involving technology, process, and people. Below are best practices for CIOs to enforce a robust IBM sub-capacity compliance programme.
Install ILMT agents on all servers, VMs, or cloud instances running IBM software under PVU/VPC licensing. This includes production, development, testing, QA, and disaster recovery environments. VMware, Hyper-V, IBM PowerVM, and public cloud VMs (AWS, Azure, GCP) must all be in scope. If a particular environment cannot be covered by ILMT, review whether the deployment is sub-capacity eligible at all.
Bake ILMT deployment into the project plan of any new IBM software implementation in a virtual environment. Stand up the ILMT server early and push agents as part of the software rollout. Connect ILMT to vCenter or other hypervisor management interfaces so it gathers host capacity data. Treat the 90-day rule as a strict deadline — a one-time gap can have lasting repercussions.
Configure ILMT to perform regular scans (at least weekly) of all managed endpoints. Update the ILMT software catalogue whenever IBM provides new definitions. Review ILMT's inventory against expected entitlements — any unknown or unexpected installations should be investigated promptly as potential shadow IT.
Apply patches and version upgrades promptly. IBM periodically releases updates to add support for new operating systems, virtualisation technologies, processor chips, and product signatures. A lagging ILMT deployment could be viewed as non-compliant if it fails to capture required data.
Cross-check that products, versions, and VM host-guest relationships are accurately reflected. Review "audit snapshot" reports for anomalies such as sudden PVU spikes that may indicate unplanned VM moves. Catch and correct errors before an official audit finds them.
Whenever a new VM with IBM software is created or cloned, ILMT agent deployment should be part of that change. Mandate a compliance checkpoint for any cloud or virtual environment expansion involving IBM software. The change ticket cannot be closed until ILMT shows data from the new system.
ILMT isn't just a compliance tool — use it to identify over-licensing or under-utilisation. ILMT displays peak PVU usage which can be compared to entitlements to inform consolidation or right-sizing decisions.
Engage an independent IBM licensing expert — such as Redress Compliance — to periodically audit your ILMT reports and assess sub-capacity compliance. These experts can catch issues an internal team might overlook and provide confidence that you are audit-ready.
Good compliance hygiene goes hand in hand with cost optimisation. Organisations that excel in software licence management treat tools like ILMT as part of their IT operations DNA — not as an afterthought. This not only avoids financial landmines but positions IT as a well-managed, audit-ready function of the business.
Modern enterprises often run IBM software in public cloud and containerised platforms as well as traditional data centres. IBM's sub-capacity model and ILMT requirements extend to these environments with special considerations.
IBM permits customers to bring their licences to approved public cloud providers under the "Eligible Public Cloud BYOSL" policy. Major platforms — including AWS, Microsoft Azure, GCP, IBM Cloud, and Alibaba Cloud — are eligible environments.
When you deploy IBM software on cloud VMs (for example, IBM DB2 on an AWS EC2 instance), the same sub-capacity rules apply as on-premises: you must use ILMT to monitor PVU/VPC usage. This means installing ILMT agents on cloud VMs and ensuring connectivity between your ILMT server and cloud instances. Do not assume the cloud provider's native tools are a substitute — IBM explicitly requires ILMT for its sub-capacity calculations.
For containerised IBM software (e.g., IBM Cloud Paks on Red Hat OpenShift or Kubernetes), IBM's sub-capacity tool of choice is the IBM License Service (ILS), not ILMT. ILS is a small service that runs in the container cluster and tracks IBM product usage in real time.
As of the 2023 Passport Advantage updates, customers no longer need a separate contract addendum for container licensing — but they must deploy IBM License Service in their clusters. Without it, IBM will consider the entire physical cluster's capacity to determine licence needs.
| Environment Type | Required Tool | Key Requirement | Risk Without Tool |
|---|---|---|---|
| Traditional VMs (VMware, Hyper-V, PowerVM) | ILMT | Agents on all hosts; quarterly reports | Full-capacity charges on entire physical server |
| Public Cloud VMs (AWS, Azure, GCP) | ILMT | Agents on cloud instances; connectivity to ILMT server | Full-capacity charges on cloud host |
| Containers (Kubernetes/OpenShift) | IBM License Service (ILS) | Deploy in each cluster; report VPC usage | Full-capacity charges on entire cluster |
| Hybrid (VMs + Containers) | ILMT + ILS + License Service Reporter | Aggregate and consolidate usage from both | Incomplete picture; combined shortfalls |
Many organisations have hybrid deployments — some instances run on traditional VMs (monitored by ILMT) and others in containers (monitored by ILS). IBM provides a License Service Reporter tool to aggregate usage data from both in hybrid scenarios. CIOs should ensure teams capture and consolidate these reports to avoid overlooking combined licence counts.
IBM's Cloud Paks — bundles of IBM software licensed via Virtual Processor Core (VPC) metric, often deployed on OpenShift — come with their own licensing terms but still require ongoing monitoring through IBM License Service. The Passport Advantage agreement was updated in February 2023 to include new container licensing language and require customers to maintain deployment records.
Even with the best intentions, organisations can fall into common traps regarding sub-capacity licensing and ILMT. Here are the most frequent pitfalls and how to avoid them.
Assuming ILMT covers everything because it's installed "somewhere" without verifying that every host reports to ILMT. A satellite office setting up an ESXi host running an IBM application without ILMT creates an invisible compliance gap. In one case, a company failed to install ILMT on a DR cluster — IBM moved to count the entire DR server capacity during an audit.
Not all platforms are eligible for sub-capacity. Running IBM software on an unsupported environment — such as an end-of-life operating system — means ILMT may collect data but IBM can disallow sub-capacity entirely. The Windows Server 2008 case (where ILMT data was ignored and full capacity applied) is a cautionary tale. Always check IBM's Eligible Virtualisation Technologies list.
A surprising number of companies run ILMT but fail to save quarterly reports long-term. Without evidence, IBM can claim non-compliance even if ILMT was functioning. Automate the export and archival of ILMT reports every quarter to a secure repository.
Perhaps ILMT hasn't been upgraded to recognise a new CPU type, or VM manager credentials expired after a vCenter upgrade, causing data collection to fail silently. Treat ILMT like a compliance heartbeat — if an agent fails to report, an alert should be raised. Configuration drift should be promptly corrected.
DevOps teams deploying containerised IBM solutions may not involve the SAM team. The result: IBM License Service is not deployed and usage is untracked. CIOs should facilitate cross-team communication so that any use of IBM software in any form triggers compliance actions.
Organisations that only scramble to fix ILMT issues after receiving an audit notice face a stressful and less effective response. A proactive stance — conducting self-audits, fixing issues continuously, and involving independent licensing experts — significantly reduces anxiety when the audit letter arrives.
Consider running an internal "mock audit" where your team — or a third party — reviews your ILMT data and licensing as an auditor would. It is much better to find and fix a problem yourself than to have IBM find it.
For CIOs looking to strengthen their IBM licensing compliance and avoid costly mistakes, here are clear, actionable steps.
Verify that ILMT is fully deployed across all environments where IBM software runs in virtualised mode. Close any coverage gaps immediately. Make ILMT deployment a standard requirement for any new IBM software installation on VMs or cloud instances.
Establish a policy to generate and archive ILMT reports quarterly without fail. Maintain at least two years of historical reports. Consider integrating report reviews into quarterly IT governance meetings.
Task your IT asset management team with updating ILMT to the latest version and applying fix packs promptly. Ensure IBM License Service in container environments is updated alongside your container platform updates.
Treat compliance as an ongoing process. Set up alerts for ILMT data — get notified if a known server isn't reporting or if scan results show unexpected spikes. Track IBM's announcements about licensing rule changes and adjust accordingly.
Expand your compliance programme to cover cloud VMs and Kubernetes clusters. Ensure ILMT agents are installed on cloud hosts just as they would be on-premises. For containerised deployments, deploy IBM License Service in each cluster. Combine data from ILMT and ILS for a comprehensive view.
Conduct awareness sessions for infrastructure, cloud, and DevOps teams about IBM's sub-capacity rules. Assign a single owner or team for IBM licence compliance (e.g., a SAM manager) who has the mandate to enforce requirements across silos.
Consider hiring an independent IBM licensing advisor — such as Redress Compliance — to perform periodic compliance health checks or assist with complex scenarios. Independent experts are particularly useful for interpreting cloud licensing terms, handling legacy exceptions, and providing objective risk assessments.
Develop an IBM Audit Response Plan. Identify who will interface with auditors, organise all ILMT and License Service data, and have evidence of compliance readily available. Practice this through internal audits or drills — preparation is the best defence.
If you have a large IBM footprint, explore the IBM Authorised SAM Provider (IASP) programme. You work with an IBM-sanctioned third party to continuously report usage; in return, IBM agrees not to audit you while in good standing. Weigh the pros and cons — including costs and data sharing — with independent expert guidance.
By following these recommendations, CIOs can turn what is often seen as a burdensome requirement into a routine part of governance. Organisations that treat tools like ILMT as part of their IT operations DNA — not as an afterthought — avoid financial landmines and position IT as a well-managed, audit-ready function of the business.
Don't wait for an audit to discover compliance gaps. Redress Compliance provides independent, expert IBM licensing advisory — from ILMT health checks to full audit defence.