IBM Virtual Processor Core (VPC) Licensing

Conversion warning: Cloud Pak for Data assigns a VPC ratio to each bundled component. A buyer migrating from standalone Db2 sized at 1,400 PVU found the equivalent Cloud Pak entitlement required 28 VPCs once the bundle ratio was applied, a 15% effective increase that was only visible after modeling the conversion line by line.

RVU, PVU, and the metric history

IBM has run several capacity metrics over the years, including Resource Value Units and Processor Value Units, and many estates still carry a mix. VPC is the direction of travel, but the older metrics persist on products that have not migrated, which means a single estate can be counting cores three different ways at once. Knowing which metric governs each product is the first step, because the conversion math and the sub-capacity rules differ, and a misclassified product is a misbudgeted one that surfaces as a surprise at the next true-up.

When IBM proposes consolidating mixed-metric products into a VPC-based Cloud Pak, the conversion is not just per product, it is across the whole portfolio at once. That is a larger modeling exercise and a larger risk. Model each product line separately, confirm the aggregate VPC requirement against your real footprint, and treat any line where the conversion raises the effective count as a point to renegotiate rather than accept. A portfolio conversion accepted on trust is where the largest hidden increases live.

Tooling and continuous monitoring

Controlling a VPC estate is a monitoring problem as much as a licensing one. The peak concurrent virtual cores assigned to IBM software is the number that drives cost, and it changes continuously in a container environment. ILMT captures the licensing view, but pairing it with your own observability tooling gives the operations team a live signal so a drift toward the entitlement ceiling is caught and corrected before it becomes a true-up. The two data sources together, reconciled monthly, are what keep a VPC estate honest over time.

Assign clear ownership for the VPC pool. In many organizations the platform team scales the infrastructure and the procurement team owns the contract, and neither watches the consumption against entitlement. A named owner who reconciles the two every month closes that gap. The cost of the role is trivial against the cost of a single full-capacity audit finding, which is the outcome the monitoring exists to prevent and the reason the role pays for itself many times over.

Negotiating the VPC conversion

The migration from PVU to VPC is a negotiation, not an administrative step, and the conversion ratio is the term that matters most. Demand the conversion math in writing, model it against your real core counts, and insist the migration be price-neutral or better. IBM wants the workload on the modern metric and the modern platform, which gives you room to require that the move does not raise your effective entitlement. Buyers who treat the conversion as fixed accept whatever ratio they are given; buyers who treat it as negotiable protect a tenth to a fifth of the entitlement value.

Time the conversion to a broader IBM negotiation rather than handling it in isolation. A conversion folded into a renewal or a new-product purchase carries more weight, because IBM is balancing it against a deal it wants to close. A conversion handled on its own, mid-term, gives you little to trade and lets IBM set the ratio with no countervailing pressure. The timing is as important as the modeling.

Cloud Pak pools as an active budget

Cloud Paks let you move entitlement between bundled products as long as total VPC consumption stays within the purchased pool. That flexibility is genuinely useful, but only if someone manages the pool as an active budget, reallocating capacity from products that have shrunk to products that have grown rather than buying more. Left unmanaged, the pool drifts toward its ceiling and the next conversation with IBM is a purchase rather than a reallocation, which is the more expensive of the two outcomes by a wide margin.

Common questions on VPC licensing

The first question is how VPC relates to the old PVU count. PVU assigned a point value to each physical core, typically 70 points; VPC counts virtual cores assigned to the software. When IBM migrates a product, it sets a conversion ratio, and that ratio decides whether the move is price-neutral or a quiet increase. Always model the conversion against your real core counts before agreeing, because the ratio is set per product and is not always in your favor.

The second question is whether sub-capacity applies to VPC. It does, and it is the largest cost control available: you license assigned virtual cores rather than every core in the host, but only with current ILMT reporting. Lapse the reporting and IBM counts the full host, which on dense hardware is a multiple of four or five. Continuous, retained reporting is what holds the lower count at audit across the whole contract period.

The third question is how to stop container autoscaling from breaching entitlement. Set resource limits on IBM-software pods so cores cannot scale without control, monitor peak assigned cores continuously, and manage the Cloud Pak pool as an active budget by reallocating rather than buying. Those three operational habits are what separate a VPC estate that holds its cost from one that climbs at every audit.

What a VPC modeling review delivers

A VPC review models the conversion before the migration is agreed. It takes every product moving from PVU or an older metric, applies the proposed conversion ratio to your real virtual-core counts, and produces the aggregate VPC requirement line by line. Any product where the conversion raises the effective count becomes a point to renegotiate rather than accept, and the buyer enters the migration with the math in hand rather than trusting the vendor headline that the move is price-neutral.

The review also establishes the sub-capacity position. It confirms ILMT is deployed, reporting is current and retained, and instances are pinned to defined virtual cores so the assigned-core count holds at audit. On dense hardware the difference between assigned-core and full-host counting is a multiple of four or five, so this single step protects the largest share of the entitlement value and removes the most common source of a seven-figure audit claim.

Lastly, the review sets up ongoing control: resource limits on IBM-software pods so autoscaling cannot breach entitlement, continuous monitoring of peak assigned cores against the purchased pool, and a named owner who reconciles the two every month and manages the Cloud Pak pool as an active budget. Together the conversion modeling, the sub-capacity position, and the monitoring keep a VPC estate at a stable, defensible cost across every audit cycle rather than ratcheting upward at each one.

The estates that hold VPC cost treat it like cloud committed spend: a number watched continuously, owned by a named person, and reconciled every month against entitlement. The estates that treat it as a figure set once at purchase are the ones that face true-ups and full-capacity claims. The instrumentation is inexpensive, and it pays for itself many times over against a single avoided audit finding on dense hardware.

Negotiation lever: When migrating from PVU to VPC, demand the conversion math in writing and model it against your real core counts before signing. Buyers who model the conversion catch unfavorable ratios and negotiate a price-neutral migration, typically protecting 10% to 20% of the entitlement value.