IBM MQ is messaging plumbing, quiet and pervasive, which is precisely why it surfaces in audits. It is one of the high-risk products IBM watches, it ends up on more hosts than anyone tracks, and its move into containers has changed the licensing math without changing the way most teams account for it. Defending MQ today means understanding how it is metered when it runs as a queue manager in a container, and what the container model does to exposure when something is out of place.
From PVU to VPC.
On traditional hosts MQ is licensed by Processor Value Unit, the core-based metric, with sub-capacity available on eligible technology and ILMT evidencing the count. In containers the relevant metric is Virtual Processor Core. Since Passport Advantage version 11, VPC metered products require sub-capacity reporting through ILMT or an approved tool, and manual counting is no longer permitted. An MQ estate that has migrated queue managers into a Kubernetes or OpenShift environment is now a VPC question, and the entitlement that governs it is measured against the virtual cores the containers are allocated, not against an older processor purchase.
The cluster wide charge.
The container rule that defines MQ risk is blunt: for container and Cloud Pak deployments, non-compliance can mean IBM charges for all cores in the cluster, not just the cores running MQ. A queue manager pinned to a few virtual cores looks small, but if the sub-capacity position cannot be evidenced, the fallback is the entire cluster capacity. On a large orchestration platform that is a dramatic jump. The defense is to keep the VPC entitlement and the tooling aligned continuously, so the claim can be held to the cores MQ actually uses and never defaults to the cluster.
Where MQ container audits find exposure.
- Untracked queue managers. MQ spun up in containers by application teams without a corresponding entitlement view.
- Tooling not capturing VPC. ILMT or the approved tool not measuring the container metric, so sub-capacity cannot be evidenced and the cluster charge looms.
- Pool consumed silently. VPC entitlement drawn down across products with no current reconciliation of what remains.
- Mixed estate confusion. Some MQ on PVU hosts, some on VPC containers, counted on a single basis that fits neither.
An MQ container finding is a VPC and cluster question. The buyer side response is to map every containerized queue manager to its VPC entitlement, confirm the tooling evidences the sub-capacity position, and keep the claim off the full cluster. Done before IBM finishes its count, that mapping is what turns a potential cluster wide charge into a contained, negotiable number.
The buyer side defense.
We contain the data request, then inventory every MQ queue manager across hosts and containers, mapping each to the metric that governs it: PVU on traditional servers, VPC in containers. We verify the tooling evidences the container sub-capacity position so the cluster wide charge has no basis, reconcile the VPC pool against consumption, and confine any genuine gap to the precise workload and period. The corrected position is written into the settlement with a forward plan that keeps MQ, on every platform, inside its entitlement.