① Product · IBM
z/VM is priced per engine, not on the monthly MSU peak. Count the wrong engines and you overpay on every machine. Here is how the metric works and which levers move the number, from the buyer side.
Audit notice or renewal under 18 months out? We mobilize within 48 hours.
Get expert help →z/VM is IBM's mainframe hypervisor, the virtualization platform that hosts large numbers of guest operating systems on IBM Z, most commonly Linux on IFL engines and z/OS, z/VSE, or test systems on general purpose processors. It is the layer that lets one frame run many virtual machines, which is exactly why its licensing follows the engines rather than a workload peak. The engine types z/VM is allowed to run on, and the rule that you license all engines of a type on a machine once you use any, are what shape the bill.
z/VM is licensed under IBM's International Program License Agreement, or IPLA, on an engine basis rather than on a monthly MSU peak. The capacity measure is the number of engines z/VM and its related programs run on, converted to Value Units through the z/VM Value Unit Exhibit. General purpose processors, the CPs, and Integrated Facility for Linux engines, the IFLs, are counted separately. z/VM may run on IFLs only for Linux and similar workloads. Since 2017 IBM has offered sub-capacity terms for z/VM measured with the IBM License Metric Tool and the z/VM Hypervisor Proxy.
| Element | How z/VM is treated |
|---|---|
| Charge model | IPLA one time charge plus annual Subscription and Support |
| Metric | Engines, converted to Value Units |
| Engine types | CPs and IFLs, counted separately |
| Default basis | Full capacity on the engine type used, per machine |
| Sub-capacity | Available with ILMT and the z/VM Hypervisor Proxy |
Directional summary. The exact Value Unit Exhibit and engine counting depend on machine model and program.
Three drivers set the z/VM number. The engine count, because the charge follows how many CPs or IFLs z/VM is licensed on, and the all engines of a type on a machine rule means a single guest on a busy box can pull in every engine of that type. The z/VM based program stack, because many priced products that run under z/VM use the same VUE021 style engine counting, so the engine decision repeats across the layer above. And the full capacity default, because without ILMT measurement in place the basis is the full engine complement rather than the sub-capacity figure, which is usually the larger number.
The recurring traps follow the counting rules. Licensing a z/VM program on more engine types than it runs on, for instance counting CPs when the workload is Linux only on IFLs, or the reverse. Hardware refresh or capacity on demand that adds engines and quietly widens the entitlement without a rebaseline, an effect worth modeling alongside the broader capacity on demand impact. And running on a full capacity basis when sub-capacity terms were available but ILMT and the Hypervisor Proxy were never deployed, leaving the more expensive basis in force by default. Each is read on the expensive side in an audit.
The structural lever is engine truth: confirm z/VM and each z/VM based program is entitled only on the engine types and machines where it actually runs, and move eligible programs to a sub-capacity basis with ILMT and the Hypervisor Proxy. The operational lever is consolidating Linux guests onto a tighter IFL footprint so the engine count that drives the bill is the real one. The contract levers are capping the annual Subscription and Support uplift, aligning the engine entitlement with hardware refresh timing, and aligning the renewal term with the wider IBM negotiation so z/VM is a lever in a larger deal. That alignment is the buyer side work we do on IBM cost optimization.
z/VM is licensed under IBM's International Program License Agreement, or IPLA, on an engine basis rather than on a monthly MSU peak. The capacity measure is the number of engines z/VM and its related programs run on, converted to Value Units through the z/VM Value Unit Exhibit. General purpose processors and Integrated Facility for Linux engines are counted separately.
They are counted separately and per machine. If a z/VM program is used on any general purpose processors on a machine it must be licensed on all of them on that machine, and the same rule applies to IFL engines. If the program runs only on CPs you do not count IFLs, and if it runs only on IFLs you do not count CPs. Licensing scope is per machine, so engines on a box where the program is not deployed are not counted.
IBM introduced sub-capacity pricing terms for z/VM and selected z/VM based programs in 2017. Sub-capacity for z/VM requires running the IBM License Metric Tool together with the z/VM Hypervisor Proxy for ILMT to determine the licensing requirement. Without that measurement in place the default is full capacity on the eligible engines, which is the more expensive basis.
The structural lever is the engine count itself: confirm z/VM and each z/VM based program is licensed only on the engine types and machines where it actually runs, and move to sub-capacity with ILMT where eligible. The contract levers are capping the Subscription and Support uplift, aligning the engine entitlement with hardware refresh, and aligning the renewal term with the wider IBM negotiation.
Publisher hub: IBM mainframe licensing. Related products: z/OS licensing and zSecure licensing. Related metric: Capacity on Demand. Put it to work: IBM cost optimization.