The processor value unit table, core factors, and what full capacity actually costs in money. Three knowledge checks along the way, and 4 clips from a senior licensing analyst.
This is a taught session, not a talking head. The instructor works through analyst grade slides, and three times the video stops on a question with four options on screen. Pause, commit to an answer, and the next slide explains which option is right and why each of the others is wrong. 4 times in the session the frame splits and a senior licensing analyst gives the view from inside real IBM negotiations, and the instructor picks the clip apart when the slides return.
The full narration of this session, section by section, for reading and reference. Guest analyst clips are marked.
Welcome to session six, and to module two, which is the signature IBM topic and the one people arrive at this course to understand. Processor value units. PVU is the metric that produces the largest single line in most IBM audit settlements, and it has an unusual property that I want you to hold onto for the next twenty minutes. It is completely computable in advance. There is no hidden coefficient, no proprietary formula, nothing that requires a vendor to tell you the answer. It is a published rating multiplied by a core count. Which means every unpleasant surprise in this area is a surprise somebody could have had privately, cheaply, months earlier. Three knowledge checks. Let's begin.
Five objectives. First, read the value unit table, because a rating is assigned per core by processor family, which means the same core count produces different licence requirements on different chips. Second, build the count yourself, because PVUs equal the rating multiplied by the eligible cores, and that is arithmetic anybody can check, and almost nobody does before the vendor does it for them. Third, state the default correctly, which is that full capacity is what you owe unless you have earned sub capacity, and earning it is an operational obligation rather than a purchasing choice. Fourth, find the eligible cores, and here is the whole session in one sentence, because eligibility is about where the software could run rather than where it happens to be running today. And fifth, price the gap before somebody else does, because a full capacity recalculation against a virtualised estate is a multiple, not a rounding error.
Four numbers. Seventy or one hundred, the typical per core rating for common x86 processors, set by processor family rather than by what you paid for the server. One thousand one hundred and twenty, the PVUs for a sixteen core server rated at seventy per core, which is one machine, one multiplication, and no mystery left. Six of ten, the share of estates where ILMT was missing, stale, or misconfigured, which means full capacity was the licensing position whether anybody intended it or not. And three to eight times, which is what full capacity recalculations ran against the sub capacity numbers those estates believed they were licensed at. The note underneath is about timing rather than arithmetic. Remediation started before an audit letter has settled at ten to thirty percent of the modelled exposure. After the letter, it is a negotiation about how much you pay, not whether.
Guest analyst clip. What strikes me about PVU, having watched it produce some genuinely large numbers over the years, is how ordinary the mathematics is. This is not a metric that hides anything. IBM publishes a rating per processor family, you count the cores, you multiply. A school child could do it. And yet I have sat opposite finance directors who found out their exposure for the first time from a vendor's spreadsheet, in a meeting they did not schedule, with a number they had no way to check in the room. Now, why does that happen. I do not think it is negligence, and I have stopped thinking of it that way. It is that nobody owns the multiplication. Infrastructure owns the cores, procurement owns the contract, and the calculation sits in between them, belonging to neither. So it never gets run until somebody outside the organisation runs it. And the thing I would most want a room to take away from this session is not the table, it is that this number is yours to compute. You can know it before anybody tells you. Almost nothing else in licensing is that clean, and it seems a shame to waste it.
Nobody owns the multiplication, so it never gets run until somebody outside the organisation runs it. Let's take the table, and then the count.
Four properties of the rating. It is a rating per core, published by IBM for each processor family, which means two servers with the same core count can carry different licence requirements. It is set by the chip and not the price, following the family and model rather than what the machine cost, so a hardware refresh can change your licence position without any software change at all. It is typically seventy or one hundred on common x86 volume processors, which keeps the arithmetic simple enough to run on a spreadsheet today. And it is published and versioned, meaning the table is a document IBM updates over time, so you record the rating you used and the date you used it, because the table you counted against matters when somebody disputes the count. And then the note, which is the honest framing of this whole session. Nothing here is secret or complicated. The reason PVU surprises people is not the table, it is which cores the table gets applied to.
Knowledge check one. You license a program on a sixteen core server whose processor family is rated at seventy PVU per core. What is the full capacity requirement? A, seventy PVUs, because the rating is per server. B, sixteen PVUs, one per core. C, one thousand one hundred and twenty PVUs, the rating multiplied by the eligible cores. D, it cannot be calculated without a price list. Pause here. The rating is per core, so ask what it gets multiplied by.
The answer is C. Sixteen cores at seventy PVU each is one thousand one hundred and twenty PVUs, and that is the entire calculation. Answer D is the one worth naming, because it is the instinct that keeps estates from ever checking their own position. The licence requirement is a quantity, and a quantity can be computed with no pricing information whatsoever. Price enters afterwards, when you decide what to do about the quantity. Conflating the two is how organisations end up believing they need a vendor conversation before they can know their own exposure.
So, five steps to build a count. Identify the processor family, because the rating comes from the family and model, so the first fact you need is what silicon the workload sits on. Look up the rating per core from the published table, and record which version of the table you used, since it changes. Count the eligible cores, and that is the hard step, which is why the next several slides are entirely about it. Multiply, and then repeat per program, because each licensed program carries its own count, so one server running four IBM programs produces four separate requirements rather than one. And keep the working, which sounds like advice from a maths teacher and is worth more than that. A count you can reproduce is a count you can defend, and a sound position with no working behind it loses arguments it should win.
Now the default, and this is the concept that costs the money. The rule is that full capacity means licensing every physical core in the machine or cluster where the program could run, regardless of how much of it the program actually uses. It is the starting position, so sub capacity is a concession you qualify for by meeting operational obligations, and nobody is on sub capacity simply by intending to be. Virtualisation is what makes it expensive, because a small virtual machine on a large host is licensed against the host, so the smaller the workload the worse the ratio looks, which inverts every instinct you have about efficiency. Clusters make it worse again, because where a workload can move across hosts, the capacity it could run on is the capacity in scope. And this is a real position rather than a threat, since it is the contractual default in the agreement you already signed, which is why an auditor can apply it without needing to prove anything further.
Guest analyst clip. There is something genuinely counterintuitive about full capacity that I think is worth sitting with, because it explains why intelligent people walk into it. Everything else in infrastructure rewards consolidation. You buy a bigger host, you pack more workloads onto it, you drive utilisation up, and you are congratulated for it. That is good engineering and it has been good engineering for twenty years. Full capacity licensing inverts it completely. Under full capacity, the two core workload sitting on your beautifully consolidated sixty four core host is a sixty four core licence position. The better you have done at consolidation, the worse the ratio. And the team that built it did nothing wrong by any standard they were measured against. Nobody in that project was asked about licensing, because it was a virtualisation project. So what you get is an exposure created entirely by good practice, discovered years later by somebody with no involvement in the original decision. I raise it because the instinct in the room, when this lands, is to look for who was careless. Usually nobody was. What was missing was a licensing voice in an infrastructure conversation, and that is a fixable thing rather than a blameworthy one.
An exposure created entirely by good practice. The better the consolidation, the worse the ratio, and the fix is a licensing voice in the infrastructure conversation rather than somebody to blame.
Knowledge check two. A two core virtual machine runs an IBM program on a sixty four core host, and ILMT has never been deployed. What is the licensable capacity? A, the sixty four cores of the host, because full capacity applies without sub capacity qualification. B, two cores, because that is what the workload uses. C, half the host, as a reasonable apportionment. D, nothing until IBM formally requests a measurement. Pause here, and ask what the estate has done to earn the smaller number.
The answer is A, the sixty four cores. Sub capacity has to be earned through the tooling obligations we cover in the next two sessions, and an estate that has never deployed ILMT has not earned it. Answer B is what most people in most organisations believe they are licensed at, which is exactly why the recalculation lands the way it does. And look at the scale of it. Two cores becoming sixty four is a factor of thirty two, on one machine, before the rest of the estate is added up. That is why the aggregate multiples on the previous slide were three to eight times rather than a few percent.
So what makes a core eligible. Eligibility follows possibility, meaning a core is in scope when the program is able to run on it, which is a configuration question rather than a performance one. Utilisation is not a defence, because a program using two percent of a host still sits on that host, and no measure of how lightly it runs changes the eligible core count. Mobility widens the boundary, so if a workload can move to another host, that host's cores can enter the calculation, which makes the cluster design a licensing decision. Dormant capacity still counts, because cores present and available to the program count even when nothing has scheduled onto them, and that catches oversized hosts and headroom bought for growth you have not had yet. And the boundary is technical, so it can be changed, since pinning, isolation and cluster boundaries are engineering choices with a direct price attached, which makes this a conversation with infrastructure rather than with procurement.
Guest analyst clip. Could run, not does run. If you take one phrase out of this session, take that one, because almost every argument I have watched an organisation lose on PVU was lost on the difference between those two verbs. And people fight it, understandably. They come armed with utilisation charts. They show that the workload never exceeds three percent of the host. All of it true, all of it carefully prepared, and none of it relevant, because the metric was never about consumption. It is about where the software is able to execute. Now here is the part that turns this from a complaint into a plan. Because eligibility is a technical boundary rather than a commercial one, it is something your own engineers can change. You can pin a workload. You can isolate a cluster. You can decide, deliberately, which hosts a program is permitted to move to, and every one of those decisions has a price attached that you can calculate in advance. So the conversation that reduces a PVU position is not with your IBM account manager at all. It is with the person who owns the hypervisor, and it is available to you today, without anybody's permission.
Could run, not does run. And because eligibility is a technical boundary, the conversation that reduces the position is with the person who owns the hypervisor rather than with an account manager.
Five traps, and every one of them is ordinary. The hardware refresh nobody told licensing about, where new processors carry a different rating, so a like for like server swap can move the requirement without a single software change. The cluster that grew, where hosts added for capacity quietly enlarge the boundary a program could run on, because nobody reads a capacity expansion as a licensing event. The test and development estate, which carries PVU requirements too, and which is precisely the environment that gets built quickly and reviewed rarely. The program installed and never removed, because installed counts, so a decommissioned application whose binaries are still sitting on the host is still a deployment in a discovery scan. And the spreadsheet from two years ago, because a PVU position is a point in time measurement, and anything older than the last infrastructure change is a historical document rather than a position.
Now the money, five points. The multiple rather than the percentage, because full capacity recalculations have run three to eight times the sub capacity numbers estates believed they were licensed at, and that is a different order of problem to a pricing dispute. It compounds through support, since a licence shortfall settled today usually carries subscription and support forward, so session four's annuity moves with it and keeps moving. Timing decides the price, because remediation started before an audit letter has settled at ten to thirty percent of the modelled exposure, while the same finding afterwards is a negotiation about how much. Most of it is fixable technically, through pinning, cluster boundaries, removing dormant installs and deploying the tooling, all of which reduce the number before anybody discusses a discount. And the calculation is not privileged information, so you can run the same arithmetic IBM will run, on your own estate, this quarter, which I would argue is the single most valuable hour in this module.
Knowledge check three. Infrastructure refreshes a host onto a newer processor family with no software change. What is the licensing consequence? A, none, the software did not change. B, the PVU requirement can change, because the rating follows the processor family. C, the entitlement is void and must be repurchased. D, the change only matters at the next anniversary. Pause here, and ask what the rating is attached to.
The answer is B. The rating is a property of the silicon, and core counts change on refresh as well, so a hardware project can move a licence position in both directions without anybody ever filing a software request. Answer A is the assumption that makes this a recurring finding rather than a one off, and I want to be clear that it is a reasonable sounding assumption, which is why it survives. The control is genuinely small. Put a licensing check into the hardware change process, and it takes minutes per change.
Guest analyst clip. I want to end on the cheapest control in this entire course, because it costs almost nothing and it prevents a category of finding rather than a single instance. Every organisation of any size has a change process for infrastructure. Somebody proposes a refresh, somebody approves it, it gets scheduled. That process already exists, it already has a form, and people already fill the form in. All I am suggesting is one more line on it: does this change the licence position, yes or no, and who checked. That is it. And the reason it works is that it catches the problem at the only moment when the problem is free to fix. Before the refresh, choosing a different processor family or a different cluster boundary costs nothing at all, it is simply a different choice among options you were already considering. Eighteen months later, in an audit, the same fact costs whatever the settlement costs. Same information, wildly different price, and the only variable is when somebody looked at it. I have seen organisations spend a great deal of money on licence management tooling while that one line on the change form remained unwritten, and I would do the line first.
So here is what good looks like on PVU, five things. A current PVU position per program, holding the rating, the eligible cores and the date, kept next to the entitlement from last session so the gap is visible in one place rather than in two documents nobody compares. A hardware change trigger, so any refresh, cluster expansion or host addition raises a licensing check, because those are the events that actually move the number. Cluster boundaries decided deliberately, because where a workload may move is an engineering choice with a price, so the boundary gets designed rather than inherited from whatever was convenient. Dormant installs removed on a schedule, which is the cheapest licence reduction available anywhere and needs no negotiation with anybody. And the tooling in place before you need it, because sub capacity is earned operationally, which is the whole of the next two sessions, and it cannot be applied retrospectively to a period you did not measure.
Three sentences. A PVU requirement is a published rating per core multiplied by the eligible cores, typically seventy or one hundred on common x86 processors, which puts a sixteen core server at one thousand one hundred and twenty PVUs and puts the arithmetic entirely within your reach. Full capacity is the contractual default and it licenses every core the program could run on rather than the cores it uses, which is why a two core virtual machine on a sixty four core host is a sixty four core position until sub capacity has been earned operationally. And full capacity recalculations have run three to eight times the numbers estates believed they were licensed at, while remediation started before an audit letter has settled at ten to thirty percent of the modelled exposure, so the value of running this calculation yourself is measured in multiples rather than in percentages.
Homework, about an hour, and this one is unusually concrete. Price one server, so pick a host running an IBM program, find its processor family rating, multiply by the physical cores, and write the number down. Find the biggest host, because the largest machine running the smallest IBM workload is your worst full capacity ratio, and it is usually identifiable by inspection rather than by analysis. Draw the cluster boundary, so for that workload, list every host it could move to, and that list is the capacity in scope, and it is usually larger than people expect. Ask when hardware last changed, meaning find the most recent refresh or cluster expansion and ask whether anybody checked the licence effect at the time. And ask the tooling question. Is ILMT deployed, current, and reporting? If you cannot get a clear yes, your position today is full capacity, and session seven is where that gets fixed.
Five guides. IBM PVU licensing explained covers the value unit table, how ratings are assigned by processor family, and worked examples of the calculation, which is the natural companion to today. The ILMT comprehensive pillar covers the tooling that turns full capacity into sub capacity and the obligations that come with it, and I would read that one before session seven rather than after. And the PVU sub capacity licensing guide sets out the eligibility rules, what qualifies, and the environments where sub capacity is not available at all.
The IBM audit defence playbook explains why the timing of a finding decides its price, and what remediation before a letter is actually worth in settlement terms. And IBM licensing explained gives you the estate view around the metric catalog, and where PVU sits among the other metrics you will meet later in the course. Next time, sub capacity licensing: the eligibility rules, and the four obligations you take on in exchange for the smaller number. See you there.