The IBM License Service, and what changes when ILMT stops being the tool that measures you. 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 twelve. Last time we counted the Cloud Pak pool. Today we deal with the thing that measures it, and with a problem that has caught a remarkable number of otherwise well run estates. Everything module two taught you about measurement still applies. Every obligation, every deadline, every retention duty. What changes is that the tool you spent three sessions learning does not reach the place your workloads are moving to. It cannot see inside a container. And the reports it produces carry on arriving, perfectly formatted, describing an estate that is emptying out. Three knowledge checks. Let's begin.
Five objectives. First, name the second tool, because ILMT cannot see inside Kubernetes, so containerised IBM software reports through the IBM License Service, which is a separate deployment with its own retention duty. Second, spot the blind spot, because estates that moved workloads onto OpenShift often kept ILMT running happily on the emptied virtual machines while nothing at all measured the containers. Third, treat resource limits as licensing, since without limits set VPC counts came in twenty to forty percent above the equivalent PVU footprint. Fourth, draw the boundary at the workload, because the audit boundary is the workload rather than the cluster, and mixed clusters without documented separation default to whole cluster exposure. And fifth, run both tools through a transition, for one full quarterly cycle, because the transition quarter either runs in parallel or gambles the gap.
Four numbers. One in two, the estates where OpenShift and Kubernetes hosted IBM workloads were under scanned, and container coverage is the fastest growing gap we see. One in three, the estates where missing or unarchived License Service reports defaulted the container position to full capacity, which is the same cliff the ninety day rule enforces on the PVU side. Twenty to forty percent, how far VPC counts ran above the equivalent PVU footprint where containers had no resource limits set. And forty to sixty percent, the share of the over deployment gap modelled at true up that came from non production and container based deployments together. And then the note, which is the sentence to carry out of this session. Moving a workload into a container does not escape the measurement obligation. It adds a second one, with its own tool, its own reports and its own archive.
Guest analyst clip. I want to describe the specific shape of this failure, because it is unusually elegant as failures go. An organisation modernises. Workloads move off virtual machines and onto OpenShift, which is a good decision made for good reasons. And the measurement tool stays exactly where it was, on the virtual machines, doing its job perfectly. It scans on schedule. It generates its quarterly report. Somebody signs it. Everything is green. And the report is increasingly a description of an estate that is emptying out, while the estate that is filling up is measured by nothing at all. Now what makes this worse than an ordinary gap is the false comfort. If nobody had ever deployed a measurement tool, somebody would eventually ask an awkward question about it. Here the awkward question never gets asked, because the honest answer to are we measured is yes, we have been for years, and everybody in the conversation is telling the truth. The gap is invisible precisely because the old control is healthy. So the diagnostic I would offer is a comparison rather than a check: take your PVU report and your container platform's inventory, and ask whether the products in one explain the workloads in the other. If your report is shrinking while your estate is growing, you have found it.
If the report is shrinking while the estate is growing, you have found it. The gap is invisible because the old control is healthy. So let us set the two tools side by side.
Two tools, four comparisons. What each measures: ILMT covers PVU products on hosts and hypervisors, while the License Service covers VPC consumed by containerised workloads, per cluster. Where each is blind: ILMT inside Kubernetes and OpenShift, the License Service outside the cluster on traditional hosts. What each produces: quarterly PVU reports signed and retained two years, against quarterly consumption reports with the Cloud Pak ratio mapping. And what each reports: peak PVU per product per host across the period, against peak VPC consumption rather than average, and that last point matters commercially because peak is the number that will be quoted at you. Then the note. The two do not integrate and the reports do not consolidate, so an audit response for a mixed estate is two evidence packages, produced by two owners, on the same cadence.
Knowledge check one. You migrate WebSphere from virtual machines onto OpenShift. ILMT is healthy and reporting. What is your container position? A, covered, because ILMT reports on the estate and it is current. B, unmeasured, because ILMT cannot see inside Kubernetes and the License Service is a separate deployment. C, covered, provided the OpenShift nodes have ILMT agents installed. D, not required until the migration completes. Pause here, and ask what ILMT is actually looking at on those nodes.
The answer is B, unmeasured. This is the modern trap in one question, because estates kept ILMT running happily on the emptied virtual machines while nothing measured the containers, and the reports kept arriving, which is exactly what made it invisible. Answer C is the most reasonable wrong answer and it is worth taking seriously, because putting an agent on the node feels like it should solve this. The agent still does not open the container. Standing up the License Service is a distinct piece of work, with its own quarterly report and its own two year archive, and no amount of ILMT health substitutes for it.
So what does deploying the License Service actually commit you to. It ships inside the Cloud Pak, so the metering component comes with the deployment, which makes this enablement and configuration rather than a procurement exercise, and that is genuinely good news. One deployment per cluster in scope, so coverage is per cluster and a new cluster is a new coverage question, exactly as a new host was in module two. Quarterly reports per cluster, carrying container VPC consumption with the Cloud Pak ratio mapping, generated on the same cadence as everything else in your close. Two years of retention, the same duty as the PVU reports and for the same reason, because reports generated and not kept prove nothing about a period that has passed. And it reports peak rather than average, which makes it the number to size against and the number that will be quoted at you, so read it before somebody else reads it to you.
Now resource limits, which is a one line manifest change with a price attached. The metric bills the assignment, meaning virtual cores assigned to the container rather than the cores the workload consumes, and that is the same rule that governed PVU appearing in a new setting. An unlimited assignment bills the node, because a container with no CPU limit can be scheduled against everything the node has, so that is what the count reflects. The measured cost of that is twenty to forty percent, which is how far VPC counts ran above the equivalent PVU footprint on platforms where limits were never set. Pods sharing CPU count once, at the container level, which is why the manifest rather than the node is where this conversation belongs. And so limits are a licensing control now rather than a platform hygiene item, which means the person who writes the manifest is making a purchasing decision, and usually does not know it.
Guest analyst clip. I find the resource limits point genuinely delightful, and I do not say that about much in licensing. Here is why. Almost everything else we discuss in this course is expensive to fix. Rebuilding a baseline takes a quarter. Remediating coverage across three thousand hosts takes fourteen weeks. Renegotiating a bundle takes a year and a lot of meetings. This one is a line in a YAML file. A developer adds a CPU limit to a container specification, it goes through the normal review, and it ships with the next deployment. The whole intervention is minutes of work and it is worth twenty to forty percent of the count on that workload. Now, the reason it does not happen is not difficulty, it is that nobody has told the person writing the file that they are making a purchasing decision. From where they sit, a resource limit is a reliability and scheduling question, and leaving it unset is often the path of least resistance. So the fix is a conversation rather than a project. Go and tell the platform team what the metric does. In my experience engineers find this immediately interesting, because it turns an abstract compliance topic into something they control precisely, and they will usually put it into the platform standard themselves before anybody asks.
Tell the platform team what the metric does. They control it precisely, and they will usually put it into the standard themselves once they know.
Knowledge check two. You run Cloud Pak workloads and your own applications on the same OpenShift cluster, with no documented separation. What is the exposure? A, none, the Cloud Pak entitlement covers the cluster it runs on. B, the restricted entitlement covers only the Cloud Pak workloads, and without documented separation the exposure defaults to the whole cluster. C, only the nodes running your own applications need a subscription, automatically. D, nothing until the cluster exceeds a core threshold. Pause here, and ask what the word restricted attaches to, the cluster or the workload.
The answer is B. The audit boundary is the workload rather than the cluster, so an in house application sitting beside a Cloud Pak needs its own OpenShift subscription. Answer C is interesting because it describes the outcome you actually want and skips the step that produces it. The separation has to be documented, by namespace and by node placement, before it is worth anything at all. Undocumented separation is indistinguishable from no separation, and it is indistinguishable in the direction that costs money, because the party doing the distinguishing is the one writing the claim.
So, namespace by namespace rather than cluster by cluster. Map the pool to the namespaces, because the VPC pool should map one to one to the virtual CPU the Cloud Pak components actually consume, namespace by namespace. A worked inventory is small, so MQ on twenty four virtual CPU, App Connect on twenty, API Connect on eighteen and DataPower on eighteen is eighty across four namespaces, and it fits on one page. Document the separation, meaning which namespaces carry Cloud Pak workloads, which carry your own, and how placement keeps them apart, because that document is the defence. Treat a new cluster as a new coverage question, with the same discipline as a new host, because a cluster stood up outside the reporting scope is exactly the old problem in new packaging. And keep the topology export per period alongside the reports, because a consumption number means nothing without the shape it was measured inside.
Guest analyst clip. The thing that surprises people about the container boundary is how small the document is. When I say you need documented separation, there is often a slight groan, because it sounds like a governance programme. It is not. For most estates it is one page. Here are the namespaces that run Cloud Pak components, here is what each consumes, here are the namespaces that run our own applications, and here is the placement rule that keeps them on separate nodes. That is the whole artefact. And what makes it valuable out of all proportion to its size is that it is the difference between an argument you win in ten minutes and an argument you lose over several months. Without it, an auditor looking at a mixed cluster has no basis to exclude anything, and quite reasonably prices the whole thing. With it, the conversation becomes narrow and factual. I would go further and say the page is worth writing even if your separation is currently imperfect, because writing it is how you discover that it is imperfect. Several times now a client has sat down to document the boundary and found within an hour that two workloads were sharing nodes nobody intended them to share, which is a much better way to learn that than the alternative.
One page, and writing it is how you discover whether the separation is real. Now, which nodes carry the count in the first place.
Five points on nodes. Worker nodes carry the count, so only nodes running your workloads count toward the Cloud Pak VPC number, which is the metric being consistent with itself. Control plane and infrastructure nodes do not, while they run a supported configuration, and that exclusion is worth a meaningful share of a large cluster. Until somebody schedules onto them, because the moment application workloads land on infrastructure nodes those cores become billable, and that is a scheduling decision rather than a purchase, made by somebody who is not thinking about licensing. OpenShift itself counts differently, since self managed OpenShift counts a core pair, meaning two physical cores or four virtual cores, on compute nodes only. And Red Hat is a separate paper trail entirely, because ILMT does not cover Red Hat at all, so a mixed estate now has two compliance tools, two report sets and two audit responses, which is next session's subject.
Now the transition itself, five rules. Run both tools for one full quarterly cycle, because the transition quarter either runs both metrics in parallel or gambles the gap between them, and the gap is where findings live. Stand up the License Service before you migrate rather than after, because the measurement has to exist before the workload arrives, which is the ninety day rule from session seven wearing container clothes. Do not decommission ILMT early, since the old estate is still being measured and still being audited and two years of history are still owed on it. Reconcile the two positions, because what left the PVU count should appear in the VPC count, and if it appears in neither then that is the finding and you found it first, which is worth ten to thirty percent rather than the alternative. And model the ratio effect before you move, because a migration changes the metric as well as the platform, and last session's conversion ratios are what decide whether it is actually cheaper.
Knowledge check three. Your quarterly close covers ILMT reports for the traditional estate. What else does a mixed estate owe? A, nothing, one signed report set covers the organisation. B, License Service reports per cluster with the ratio mapping, on the same cadence and the same two year retention. C, an annual container summary only. D, container reporting is IBM's responsibility, since the service ships with the product. Pause here, and ask how many evidence packages two tools that do not consolidate produce.
The answer is B. The tools do not integrate and the reports do not consolidate, so a mixed estate produces two evidence packages on the same rhythm. Answer D is worth naming because it is a genuinely understandable mistake. The service really does ship inside the product, IBM really did write it, and it starts working without you buying anything, all of which makes it feel like somebody else's responsibility. Generating the reports and retaining them is entirely yours. The obligation followed the workload into the cluster. The tooling changed, and nothing else did.
Guest analyst clip. Let me close on the organisational consequence, because I think it is the part that actually determines whether any of this works. A mixed estate has two measurement tools, and in almost every organisation I see, those two tools sit with two different groups. ILMT belongs to whoever has owned the traditional estate for years, often in software asset management. The License Service arrives with the platform, so it lands near the OpenShift team, who are usually a newer and more engineering focused group. Neither has any particular reason to talk to the other about this, and both are quite reasonably measuring what they can see. And the failure that follows is not that either half goes wrong. It is that nobody owns the seam. When a workload moves from one estate to the other, it leaves one measurement system and should join another, and the handover is nobody's job. So the recommendation is a single quarterly meeting, half an hour, both owners in the room, with one question on the agenda: what moved this quarter, and is it now measured in the place it landed. I know how unremarkable that sounds. It is also the entire control, and estates that do it stop generating this category of finding altogether.
So, one close, two tools, two archives. Add the container row to the quarterly close, meaning License Service reports per cluster, generated, reviewed, signed and archived alongside the PVU reports, on the same date with the same owner. Put resource limits in the platform standard so new workloads arrive limited rather than getting limited, which is the gold image lesson from module two expressed in a manifest. Document namespace separation once and then maintain it, covering which namespaces are entitled by the Pak and which are not, reviewed whenever either side changes. Treat cluster creation as a licensing event, because a new cluster raises the same question a new host did, is it measured, by which tool, and from what date. And name a container owner, who is often a different person to the ILMT owner, because the failure mode is identical, a tool that ships with the product and belongs to nobody.
Three sentences. ILMT cannot see inside Kubernetes, so containerised IBM software reports through the IBM License Service, a separate deployment with its own per cluster quarterly reports and its own two year retention, and the two tools neither integrate nor consolidate. The metric bills the assignment rather than the consumption, so containers without resource limits ran VPC counts twenty to forty percent above the equivalent PVU footprint, which makes a limit in a manifest a purchasing decision made by an engineer. And the audit boundary is the workload rather than the cluster, so a Cloud Pak beside your own applications needs documented namespace separation or the exposure defaults to the whole cluster, and container coverage is the fastest growing gap we see, under scanned on roughly half of estates.
Homework, about an hour. Ask whether the License Service is running, on which clusters, since when, and who generates the report, because if the answer is a shrug then you have found the fastest growing gap in your estate in under a minute. Read one manifest, finding a Cloud Pak workload and checking whether it has a CPU limit set, because that single line is worth twenty to forty percent of its count. Ask what else runs on the cluster, meaning Cloud Pak workloads and in house applications together, and whether the separation between them is written down anywhere at all. Check the infrastructure nodes, asking whether anything has been scheduled onto control plane or infrastructure nodes, because those cores are excluded right up until they are not. And reconcile one migration, taking a workload that moved to containers and confirming it left the PVU count and arrived in the VPC count, because anything in neither is a finding and you would much rather it was yours.
Five guides. The PVU to VPC transition guide covers what the License Service replaced, the container counting rules, and why the transition quarter runs both metrics or gambles the gap. The IBM and Red Hat integration guide covers the audit boundary at the workload, the two compliance tools that do not consolidate, and the doubled audit surface that comes with them. And the Cloud Pak strategy page covers cluster topology, peak VPC allocation, and why mixed clusters without documented separation default to whole cluster exposure.
The ILMT comprehensive pillar explains why container coverage is the fastest growing gap and the second largest finding category behind it. And the CIO playbook on the transition covers sizing on consumed rather than allocated cores, and the sequencing of a move that does not create a gap in the first place. Next time, Red Hat inside IBM: RHEL subscriptions, OpenShift core pairs, and where the two paper trails meet. See you there.