License Consulting Cluster

IBM Container Licensing.

The container licensing rules sit between the older sub capacity world and the modern Cloud Pak world. This article is the buyer side reading on the IBM License Service, VPC accounting on containers, the Cloud Pak entitlement boundary, and the operational discipline an enterprise needs.

Read time 12 min Updated May 2026 By IBM Licensing Experts
Container orchestration view representing IBM software running on Kubernetes
Independence statement. IBM Licensing Experts is an independent advisory firm. We are not an IBM Business Partner, reseller, or affiliate. We have no resell margin tied to our recommendations and we do not earn revenue from any IBM product line. Read more on why independence matters.

Why container licensing matters.

Most enterprise IBM workload is now running on Red Hat OpenShift or another Kubernetes distribution. The licensing rules for containers are different from the legacy virtual machine rules and the buyer side discipline is different. A misread of the rules produces full capacity exposure on a cluster that was assumed to be sub capacity, and an over commit on Cloud Pak entitlement that was assumed to be sized correctly. The two errors typically run six figures each on a mid sized estate. See sub capacity explained and Cloud Pak strategy for the adjacent reading.

This article is the operational reference. It covers the License Service, the VPC counting rule, the Cloud Pak entitlement boundary, the standalone OpenShift case, the sizing limits, the ILMT interaction, and the audit posture. Each section is the buyer side view.

1. The container licensing model.

Container based IBM software is licensed by Virtual Processor Core (VPC) under the Container Licensing terms attachment. One VPC equals one vCPU consumed by the licensed software on the container, with rounding rules that favour the buyer at the small end. The counting is per container, not per cluster. The Container Licensing terms attachment is signed once and inherits across the Cloud Pak and standalone product set.

The container model replaces the PVU based sub capacity model for products licensed under VPC. It does not replace the PVU model for products that have not migrated to VPC. A WebSphere Application Server traditional install on a container is still PVU based and still requires ILMT, not the License Service. See product licensing guide for the metric mapping per product.

2. The IBM License Service.

The IBM License Service is the lightweight metering component that runs inside the OpenShift cluster and reports the actual VPC consumption per licensed product. It is the container equivalent of ILMT for the VPC product set. The deployment is a single operator install. The reporting is a daily JSON export to the local file system, retained for the audit window.

The License Service is the audit evidence. A buyer without a healthy License Service deployment cannot evidence VPC consumption on containers and falls back to full cluster licensing on the affected products. This is the container equivalent of the ILMT fallback. The ILMT guide covers the parallel discipline. The Cloud Pak Licensing Guide white paper covers the deployment frame.

The License Service trapThe License Service is silently disabled or never deployed when a Cloud Pak is installed by an operator team unfamiliar with the licensing dependency. Six quarters later, the audit arrives and the customer cannot produce VPC reports. The full cluster fallback on a 40 node OpenShift cluster runs into seven figures. The remediation is a 60 minute install, completed before the next quarter close.

3. Cloud Paks on OpenShift.

The Cloud Paks are the primary VPC product set on containers. Each Cloud Pak bundles a defined set of IBM products and a sized entitlement of Red Hat OpenShift. The VPC entitlement covers the bundled products and the OpenShift entitlement covers the underlying platform. The two entitlements are separately measured but commercially bundled.

The conversion ratios from legacy PVU entitlement to Cloud Pak VPC entitlement are published per Cloud Pak. A buyer migrating WebSphere from a PVU footprint to Cloud Pak for Applications is converting PVU into VPC at a published ratio. The ratio is the negotiation lever at migration time. See Cloud Pak strategy for the conversion ratios and the bundling calculus. The Cloud Pak ROI Analysis white paper covers the financial frame.

4. Standalone OpenShift.

OpenShift sold outside a Cloud Pak is the standalone subscription. The metric is per node. The buyer side trap on the standalone is the duplication with bundled Cloud Pak OpenShift. A customer that runs 500 standalone OpenShift node subscriptions and two Cloud Paks with 200 bundled node entitlements is paying for 200 nodes twice. The retirement of the duplicate standalone subscriptions at the next renewal cycle is a routine seven figure saving. See OpenShift Licensing Deep Dive for the full position. The Red Hat expertise page covers the cross cluster frame.

5. Sizing and limits.

The VPC counting on containers is per pod resource limit when limits are set, and per node capacity when limits are not set. The buyer side discipline is to set the resource limit on every licensed container. An unlimited pod on a 32 vCPU node is counted as 32 VPC even if the workload uses 4 vCPU. The pod resource limit is the cheapest single line of YAML the buyer can write.

The same logic applies to the Java heap limit, the container CPU request, and the namespace quota. The License Service reads the pod limit. The audit follows the License Service. Setting the limit is the discipline that converts the headline cluster capacity into the actual chargeable consumption.

6. ILMT and containers.

ILMT is still required for the PVU product set running on containers. A traditional WebSphere install in a container still consumes PVU and still requires ILMT. The split estate (some containerised products on the License Service, some on ILMT) is operational reality in most enterprises. The buyer side action is to keep both tools healthy on the relevant scope. See ILMT best practices for the operational reading.

The container ILMT support relies on the scanner reaching the worker nodes and the container metadata. The scanner deployment in an OpenShift cluster requires a privileged scanner pod and a service account with the read scope on the cluster API. The deployment is documented and supported, but the operational handover is where most ILMT container deployments fail. See ILMT Deployment Playbook.

7. Audit posture on containers.

A container heavy estate inside an audit is asked for both the License Service exports (for the VPC product set) and the ILMT Audit Snapshot reports (for the residual PVU product set on containers). The auditor reconciles both against the entitlement record. Any gap on either side produces a finding. The container estate is therefore not a single audit conversation, it is two parallel conversations covering different products.

The buyer side defence is the readiness of both. A clean License Service deployment, two years of retained exports, a clean ILMT deployment on the residual PVU footprint, and a documented entitlement reconciliation per product. See audit defense playbook and the audit defense service for the engagement frame.

Ready to put this work into practice?

An independent senior advisor on your IBM estate. No resell margin, no IBM relationship to protect, no time pressure to push a product. Just the buyer side view.

Schedule a consultation All services