IBM Cloud Paks meter containerised software by the Virtual Processor Core. This guide explains how the VPC pool works, why container density drives cost, how entitlements interchange inside a pack, and the conversion ratios a buyer must check before migrating off legacy PVU licences.
An IBM Cloud Pak is a curated bundle of IBM software, containerised and packaged to run on Red Hat OpenShift, sold against a single pool of entitlement rather than as a row of separate product licences. Admodum is an independent, buyer-side software licensing advisory firm, and this page explains how Cloud Pak licensing and the VPC metric work so a buyer can size and negotiate the commitment correctly.
The Cloud Pak families, Cloud Pak for Data, for Integration, for Business Automation, for Watson AIOps and others, each gather a set of related capabilities behind one entitlement. The intention is flexibility: rather than buy fixed quantities of a dozen separate products, the buyer holds a quantity of VPC and draws the individual capabilities it needs from the pack as projects demand. This is a genuine commercial improvement over the rigid, per-product world of traditional PVU licensing, but the flexibility has a precise boundary and a precise meter, and both must be understood before the model can be judged a good deal.
This page sits within the IBM contract negotiation and renewal pillar, and the move toward Cloud Paks is increasingly the form that an IBM Enterprise Licence Agreement takes when it is renewed, which makes understanding the metric a negotiation prerequisite rather than a technical footnote.
VPC stands for Virtual Processor Core. It is the unit by which IBM meters software running in containers, and it differs from older metrics in a way that has direct cost consequences.
Where the legacy PVU (Processor Value Unit) metric weighted physical processor cores by a per-chip factor, the VPC metric counts the virtual cores made available to IBM's software inside a Kubernetes or OpenShift cluster. One VPC corresponds, broadly, to one virtual core allocated to a container running the licensed capability. The shift from physical to virtual measurement matters because containers do not map one-to-one onto hardware: many containers share a host, and the licensable quantity is the virtual allocation, not the metal underneath.
The practical consequence is that deployment architecture is now a licensing decision. The number of VPCs a buyer consumes depends on how many virtual cores its platform schedules to IBM workloads, which depends in turn on replica counts, resource requests and limits, autoscaling policy and the headroom engineers leave for peaks. Two organisations running the same logical workload can consume materially different VPC counts purely because of how their clusters are configured. Cost control therefore moves partly into the hands of the platform team, and a buyer that does not connect its FinOps and procurement functions will pay for slack it never needed.
The defining commercial feature of a Cloud Pak is that its entitlement is a shared pool. Understanding exactly how far that pool stretches is where buyers most often misjudge value.
Within a single Cloud Pak, the VPC entitlement can be allocated across the bundled capabilities according to per-product conversion ratios published by IBM. A capability that is processing-intensive may consume entitlement at one rate; a lighter capability at another. The buyer holds, in effect, a currency, and the conversion ratios are the exchange rates that decide how much of each capability that currency buys. A pool that looks generous in raw VPC terms can be modest once the conversion ratios for the specific capabilities a buyer actually intends to run are applied.
The boundary of this flexibility is the Cloud Pak itself. Entitlement is interchangeable inside a pack but does not move between different Cloud Paks, so an organisation that buys Cloud Pak for Integration cannot redirect that entitlement to Cloud Pak for Data. A buyer should therefore size each pack against a realistic, capability-level plan rather than a headline VPC number, and should be sceptical of any sizing exercise that does not model the actual conversion ratios for the capabilities it will run. The supporting-program and bundling subtleties that surround these packs are covered in IBM part numbers, supporting programs and bundling traps.
Cloud Paks are not measured by the tool a buyer may already run for its traditional estate. Knowing which tool governs, and keeping it correct, is what makes a compliance position defensible.
Traditional sub-capacity PVU licensing is evidenced by ILMT (IBM Licence Metric Tool), the subject of ILMT deployment and the 90-day sub-capacity rule. Cloud Paks instead rely on the IBM Licence Service, a component deployed into the OpenShift or Kubernetes cluster that records peak VPC consumption per product and generates the audit-grade reports IBM uses to assess entitlement. The Licence Service must be installed, kept running and its reports retained; a gap in its records is, from IBM's perspective, a gap in the buyer's evidence.
The discipline mirrors the older world even though the tooling differs. Just as a lapse in ILMT can collapse a sub-capacity claim back to full-capacity pricing, a missing or misconfigured Licence Service deprives a buyer of the measured peak that justifies its VPC purchase. A buyer moving to Cloud Paks should treat the Licence Service as part of its compliance infrastructure from day one, retain its reports, and reconcile measured peaks against entitlement on a regular cadence rather than discovering a shortfall during a software licence review.
The most consequential moment in Cloud Pak licensing is the conversion of existing entitlement into VPC. The ratio applied, not the published price, decides whether the move helps the buyer.
When an organisation migrates a product it already owns under PVU into a Cloud Pak, IBM converts the legacy entitlement into VPC at a defined ratio. A generous ratio can make the migration cost-neutral or better, carrying the value of prior investment forward. An unfavourable ratio quietly increases the buyer's effective commitment while appearing to be a simple modernisation. Because these ratios are negotiable and because IBM controls the published starting point, the conversion is precisely where buyer-side advice earns its place.
The buyer-side checklist is specific: benchmark the proposed conversion ratio against comparable deals, model the post-conversion VPC requirement using real cluster sizing rather than IBM's assumptions, confirm that the pooled entitlement covers the actual mix of capabilities at their true conversion rates, and secure the Licence Service and reporting obligations in writing. Where the move is bundled into a renewal, the conversion should be negotiated alongside the wider renewal timing and leverage rather than accepted as a technical given. The aggregated reading sits at the IBM knowledge hub, the wider engagement at the IBM practice, and to have an advisor model your Cloud Pak conversion before you commit, get in touch.
IBM Cloud Paks are licensed by the Virtual Processor Core, or VPC, metric. A buyer holds a pool of VPC entitlements that can be allocated across the products inside that Cloud Pak, and consumption is measured by the virtual cores made available to the containerised software running on the cluster. The pooled, interchangeable nature of Cloud Pak entitlement is its main commercial difference from older per-product PVU licensing.
VPC stands for Virtual Processor Core. It is the unit by which IBM meters containerised software, counting the virtual cores assigned to the software on a Kubernetes or OpenShift cluster rather than the physical cores of the host. Because containers can be densely packed, the VPC count depends heavily on how workloads are sized and scheduled, which is why deployment architecture directly drives Cloud Pak cost.
Yes, within a single Cloud Pak. The defining feature of a Cloud Pak is that its VPC entitlement is a shared pool that can be allocated across the capabilities bundled in that pack, subject to per-product conversion ratios. Entitlements do not move freely between different Cloud Paks, so the boundary of flexibility is the pack itself, and the conversion ratios decide how far a given pool actually stretches.
Cloud Paks are measured by the IBM Licence Service deployed into the OpenShift or Kubernetes cluster rather than by ILMT, the tool used for traditional sub-capacity PVU licensing. The Licence Service records peak VPC consumption per product and produces the audit-grade reports IBM relies on, so a buyer must deploy and retain it correctly to evidence compliance, in the same spirit that ILMT governs older estates.
Moving an existing product into a Cloud Pak usually involves a conversion of legacy PVU entitlement into VPC entitlement at a defined ratio set by IBM. The ratio is decisive: a generous conversion can make the move cost-neutral, while an unfavourable one quietly increases the buyer's commitment. The conversion terms should be benchmarked and negotiated before any migration is agreed, not accepted as a fixed published rate.
Our white paper sets out the IBM and Red Hat subscription model, the VPC mechanics and the conversion ratios that decide whether a Cloud Pak move helps the buyer. A senior Admodum IBM advisor will then model your conversion before you commit. Renewal moments route to the Renewal Programme; the newsletter carries vendor-policy alerts.