The VPC ratio map for Cloud Pak products.
Cloud Pak entitlements are sold in Virtual Processor Cores, but the capabilities inside them do not all consume VPC at the same rate. Each capability has a conversion ratio, and that ratio is where most VPC counting errors begin. Understanding the map turns an opaque consumption number into something you can check, and challenge.
One metric, many conversion rates
VPC is a single metric, but it does not map one to one onto every Cloud Pak capability. IBM assigns each capability a conversion ratio that translates its deployed footprint into VPC consumed. A lighter capability might draw a fraction of a VPC per core of work, while a heavier one draws more than its bare core count. The headline VPC entitlement is therefore not a core budget. It is a pool that different capabilities draw against at different rates, and the only way to know whether you are within entitlement is to apply the correct ratio to each capability actually running.
Where the ratio errors come from
Most VPC findings trace back to a small set of ratio mistakes:
- Sizing the entitlement against raw cores instead of against the capability ratios, so the pool looks adequate when it is not.
- Applying a ratio from one version of a Cloud Pak to a deployment running a different version, where the ratio changed.
- Counting a capability as the lighter of two ratios when the heavier one applies to how it is actually used.
- Ignoring capabilities that were switched on for evaluation and never turned off, each one quietly drawing against the same VPC pool.
None of these are visible from a core count alone. They surface only when the deployed capabilities are listed and the right ratio is attached to each one.
Versions move the ratios
Conversion ratios are tied to the Cloud Pak version and the part numbers in your entitlement, and they are not frozen. A ratio that was correct at the version you bought may differ at the version you are running, and an audit will reach for whichever interpretation produces the larger count. The defense is to pin every ratio to the version actually deployed and the entitlement actually held, then hold the count to that pairing rather than to a generic table.
Why the map is a defense, not just bookkeeping
Because Cloud Pak products run containerized, a VPC overrun does not stay local. Out of sub-capacity compliance, the count defaults to every core in the cluster. So a ratio error is not a rounding issue. It can be the difference between a workload sized count and a cluster sized one. Rebuilding the ratio map for each deployed capability, against the correct version and entitlement, is what keeps the finding tied to the work rather than to the whole environment.
A Cloud Pak VPC count is only as defensible as the ratio map behind it. Each capability converts to VPC at its own rate, those rates move with version, and a single wrong ratio can push the count from the workload to the entire cluster. Rebuild the map capability by capability, pin every ratio to the deployed version and held entitlement, and the VPC math becomes something you can defend line by line.
Does your Cloud Pak VPC count rest on the right ratios?
Our Sub-Capacity Defense engagement rebuilds the ratio map for each deployed capability, pins it to the version and entitlement in force, and challenges any count that defaults to the full cluster.
See Sub-Capacity Defense →The IBM Audit Brief
Audit triggers, ILMT pitfalls, and settlement tactics for IBM software buyers.
Independent, buyer side IBM software audit defense and negotiation. Not affiliated with IBM Corporation.