Most buyers know sub-capacity requires ILMT. Fewer know that the tooling is only half the test. The other half is the technology itself. IBM publishes lists of eligible virtualization technologies and eligible public clouds, and sub-capacity is available only when the IBM software runs on a configuration that appears on those lists. Run it anywhere else and IBM treats the deployment as full-capacity, regardless of how clean your ILMT reports are. This is one of the quietest and most expensive traps in an audit.
What "eligible" actually means.
Eligibility is specific to the combination of processor, virtualization technology and, in some cases, operating system. A given hypervisor is eligible only at supported versions and only when partitioning is done by a method IBM recognizes. The eligible public cloud list works the same way for AWS, Azure, Google Cloud and IBM Cloud. The principle is simple: IBM will only accept a reduced core count when it can trust the technology to enforce and report the partition. Where it cannot, it defaults to counting every physical core.
The configurations that void the claim.
The recurring offenders are rarely exotic. They are ordinary infrastructure decisions made without the licensing implication in view:
- Unsupported hypervisor versions. An eligible virtualization technology running at a version IBM has not certified can fall outside the eligible list entirely.
- Legacy operating systems. Older releases, such as out of support Windows Server versions, can render an otherwise eligible stack ineligible for sub-capacity.
- Manual or unsupported partitioning. Capping methods that IBM does not recognize as enforceable do not qualify, even if they limit cores in practice.
- Mixed eligibility within a cluster. One ineligible host in a shared pool can expose the IBM software that moves onto it through live migration.
Why the cost swing is so severe.
When technology is ruled ineligible, IBM does not meet you halfway. It charges full-capacity, which means every physical core on the host counts at the PVU per core rate, not just the cores the software used. On a large host that is the difference between licensing a handful of cores and licensing the entire socket count. Multiplied across a lookback that can run 2 to 5 years, an ineligibility finding on a single product can dwarf the rest of an audit.
Eligibility is a precondition, not a detail. Before an audit, confirm that every host running IBM software sits on a configuration IBM recognizes, at a supported version, with an approved partitioning method. If a host is ineligible, the fix is to remediate the configuration or move the workload, not to argue the ILMT report. Clean tooling cannot rescue an ineligible platform, and IBM knows it.
The buyer side response.
Defending an ineligibility finding starts by checking IBM's claim against the actual deployment and the eligible technology lists in force during the lookback, because those lists change over time and a host that is ineligible today may have been eligible when the software ran. Where a genuine ineligibility exists, the goal is to confine full-capacity charging to the affected host and period rather than letting it spread across the estate, and to negotiate a remediation path that restores sub-capacity going forward. The same review feeds a forward plan so the next audit does not surface the same gap.