The sub-capacity rules are often explained as if every environment behaved the same way. In a real enterprise estate they do not. A WebSphere instance on VMware, a Db2 node on Power, an MQ broker on Hyper-V and a workload running in a public cloud are each governed by their own counting method. ILMT can stitch a single inventory together, but the licensing logic underneath differs platform by platform. An audit does not test your average position. It tests each platform on its own terms and finds the one where coverage is thin.
Why the counting differs by platform.
The variation is not arbitrary. IBM ties the counting method to how each technology enforces and reports its partitions. A few of the distinctions that matter most:
- Power LPAR. Counts the cores allocated to the partition, and an idle allocated core still counts. Capacity assigned but unused is capacity you license.
- VMware. Counts the virtual cores assigned to the virtual machine, but unrestricted live migration across a cluster can expose more hosts than you expect.
- Hyper-V. Has its own eligibility and counting rules that must be matched to supported versions to qualify for sub-capacity at all.
- Public cloud. Counts vCPUs on the eligible cloud list, with elasticity and autoscaling adding their own coverage gaps.
The live migration trap.
The single most common surprise in a mixed estate is workload mobility. When a virtual machine running IBM software can migrate freely across a cluster, IBM may count every host the software could land on, not just the host it happens to sit on at scan time. The sub-capacity benefit narrows sharply if migration is not constrained, and a permissive cluster can convert a modest deployment into a cluster wide charge. Documented affinity rules and migration boundaries are part of the licensing position, not just an operations concern.
One inventory, many rule sets.
The practical risk in a mixed estate is inconsistent coverage. A team that has ILMT well configured on VMware may have gaps on Power, or a newly added Hyper-V cluster that no agent reached, or cloud instances outside the inventory tool entirely. Each gap is a platform where sub-capacity cannot be proven, and full-capacity charging follows. Continuous, complete coverage across every platform is what holds the whole position together. A single uncovered cluster is enough to anchor a finding.
An audit of a mixed estate is really several audits at once, one per platform, joined by a single inventory record. The buyer side defense is to prove the correct counting method on each platform, document migration boundaries where workloads are mobile, and close any platform where tooling coverage lapsed. The exposure lives on the weakest platform, so that is where the defense has to be strongest.
Building the cross platform position.
Defending a mixed estate means reconciling each platform against the rule that governs it, then assembling the result into one coherent sub-capacity claim. Where IBM has applied the wrong method to a platform, that is challenged with the configuration evidence. Where a genuine gap exists on one platform, it is confined to that platform and period rather than spread across the estate. The same review produces a forward plan that keeps coverage complete as workloads move between hypervisors and into the cloud.