RHEL subscriptions, OpenShift core pairs, and where the two paper trails meet. 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 thirteen. Last time we ended on a sentence I want to pick up: Red Hat is a separate paper trail entirely. Today is that paper trail. And I want to be clear at the outset about why this belongs in an IBM course rather than in a course of its own. IBM closed the Red Hat acquisition in July 2019, at thirty four billion dollars. The products came together commercially. The compliance regimes did not, and they have not since. So if you run OpenShift under a Cloud Pak, you are operating inside two counting systems at once, and neither one can see the other. Three knowledge checks. Let's begin.
Five objectives. First, count a socket pair correctly, because RHEL counts up to two populated sockets regardless of core count, so an eight socket server needs four subscriptions and installed capacity is not the question. Second, count an OpenShift core pair, which is two physical cores or four virtual cores, on compute nodes only, with control plane and infrastructure nodes excluded while they stay clean. Third, separate the two compliance regimes, because ILMT does not cover Red Hat at all, so a mixed estate runs two tools, produces two report sets and answers with two evidence packages. Fourth, stop paying twice for the same cores, by reconciling Red Hat subscriptions against the OpenShift entitlement your Cloud Pak already carries. And fifth, know what the paper is worth, because direct Red Hat pricing runs twenty five to forty percent below list while the IBM master agreement path lands at twenty to thirty five.
Four numbers. Twenty two percent, the median share of running Red Hat instances carrying no matching entitlement, across roughly thirty estates reviewed. Twenty to forty percent, how far OpenShift core counts were overstated because subscriptions were sized to allocated cores rather than the cores actually in use. Two tools, ILMT for the PVU estate and Subscription Watch and Insights for Red Hat, which do not integrate and whose reports do not consolidate. And one in three, which is roughly where settlements land against the opening reconciliation figure, because that first number rests on contestable assumptions. Then the note, and it is the sentence that gets attention in a room. A customer can pass an ILMT audit and fail a Red Hat compliance check in the same year, and the two events will feel entirely unrelated to everybody involved.
Guest analyst clip. The sentence about passing one and failing the other in the same year is not a rhetorical flourish, I have watched it happen. And what makes it striking is the reaction inside the organisation, because the two events arrive at different people. The IBM audit goes to software asset management, who handle it well, produce their reports, and feel quite pleased. Some months later a Red Hat reconciliation lands, often with the platform team, and finds a meaningful number of running systems with nothing entitling them. And nobody in either conversation connects the two, because from where each of them sits, they are unrelated vendors with unrelated paperwork. Which is technically true and commercially nonsense, because it is one estate, one budget and one CFO. So the thing I would ask you to do is almost embarrassingly simple. Put both regimes on one page. Not one tool, that does not exist, but one page listing what is measured, by whom, on what cadence, with a gap column. The first time an organisation does that, somebody usually says out loud that they had no idea Red Hat was not covered by the tooling they had been funding for years. That sentence is worth the exercise on its own.
One page listing what is measured, by whom, on what cadence, with a gap column. Not one tool, because that does not exist. Now, the units themselves.
Five families, four different units, and none of them behave like an IBM metric. RHEL Server counts a socket pair, driven by populated sockets up to two per subscription, whatever the core count. OpenShift counts a core pair, which is two physical cores or four virtual cores, on compute nodes only. Ansible Automation Platform counts managed nodes, meaning the nodes under management, which is a number that grows precisely as your automation succeeds. JBoss EAP counts four core units on the cores running the application server. And Satellite counts managed systems, and it pays back above roughly three hundred subscribed hosts, which is a useful threshold to have in your head. Together these five make up over ninety percent of Red Hat enterprise revenue, and not one of them counts the way anything in modules one or two counts.
Knowledge check one. You run RHEL on a server with eight populated sockets and one hundred and twenty eight cores. How many subscriptions? A, one, because it is one server. B, four, because a subscription covers up to two populated sockets regardless of core count. C, sixty four, one per core pair. D, it depends on the number of cores, at two cores per subscription. Pause here, and ask what the RHEL unit actually counts.
The answer is B, four. Eight populated sockets is four socket pairs, and the one hundred and twenty eight cores do not enter the calculation at all. Answers C and D import the core based thinking that every IBM metric in this course has trained you into, and that is exactly the trap I want to set off deliberately here rather than out in the world. RHEL and OpenShift sit in the same estate, often on the same hardware, and count on completely different units. And confirm populated sockets rather than installed capacity, because an empty socket is not a populated one and people do routinely count the chassis.
So, RHEL in detail. The socket pair is the unit, up to two populated sockets per subscription with core count irrelevant, which makes dense servers unusually good value here, and that is the opposite of everything module two taught you. Guest subscriptions cover two virtual nodes, so a virtualised estate counts guests and the arithmetic changes completely from the physical case. Virtual Datacenter covers one host with unlimited guests, priced per host socket pair, and on a dense virtualisation host that is usually the cheaper shape by a distance. Simple Content Access removed the enforcement, becoming the default for new accounts from July 2022 and nearly universal by November 2024, so systems now entitle themselves without a check. And therefore absence of an error is not presence of compliance, which is the single change that explains why a median twenty two percent of running instances carried no matching entitlement with nothing anywhere reporting a problem.
Now OpenShift, five points. A core pair is two physical cores, or four virtual cores on a hyperscaler, and on bare metal the physical cores count regardless of hyperthreading. Compute nodes only, so control plane and infrastructure nodes are excluded while they run a supported configuration, exactly as in last session's Cloud Pak count. Size on the trailing ninety day average rather than on peak, because in roughly six of nine estates benchmarked, peak based sizing over committed by fourteen to twenty four percent. Allocated is not used, since core counts were overstated by twenty to forty percent where subscriptions were sized to allocated cores, and right sizing recovered a median nineteen percent. And Platform Plus is one SKU, so you cannot drop a component to lower the rate, which means it earns its premium only where a core genuinely uses at least two of the bundled tools.
Guest analyst clip. Allocated versus used is the single most recoverable number in a Red Hat estate, and I want to explain why it drifts, because it is not carelessness. When a platform is first sized, nobody knows what it will need, so it gets sized generously, which is correct engineering under uncertainty. Then the platform succeeds, and more workloads arrive, and the cluster grows again, still generously. And at no point does anybody go back and ask what the trailing ninety day usage actually was, because the platform is working and nothing is on fire. So you end up subscribed to the shape of an old worry rather than to the shape of your current estate. The number attached to that is not small. Core counts overstated by twenty to forty percent, and right sizing recovering a median of nineteen percent of the subscription. Now, the reason I like this as an intervention is that it requires no negotiation whatsoever. You are not asking Red Hat for anything. You are counting your own cores properly and buying that number instead of the other one. And unlike almost everything else in licensing, the people who can do it are already in the building and already have the data on a dashboard.
Subscribed to the shape of an old worry rather than to the current estate. No negotiation required, just counting your own cores properly.
Knowledge check two. Your ILMT position is clean and fully evidenced. What does that tell you about your Red Hat position? A, that it is also clean, since ILMT covers the platform the workloads run on. B, nothing at all, because ILMT does not cover Red Hat and the two regimes are separate. C, that Red Hat compliance is covered by the IBM master agreement. D, that Red Hat will not reconcile while an IBM audit is open. Pause here, and ask which tool has ever looked at a RHEL subscription.
The answer is B, nothing at all. Compliance tooling splits between ILMT and the Red Hat tools, the reports do not consolidate, and an audit response needs two evidence packages produced by two teams. Answer C is the one I want to dwell on, because it is the most common version of this mistake and it is a very natural one. Buying Red Hat through an IBM agreement changes who invoices you. It changes the discount you get, the term you sign and the renewal date you work to. It changes nothing whatsoever about how the subscriptions are counted or who reconciles them, and those are different departments at Red Hat from the people you negotiated with.
So what does a Red Hat compliance event actually look like. Red Hat reconciles rather than audits, comparing running instances against active subscriptions, which makes the unit of risk the unsubscribed system rather than a licence count. The maths is simpler, being subscription gap times list times the back period, with no sub capacity, no value units and no processor tables, and the process runs three to five months rather than six to twelve. The opening figure is a position rather than a settlement, landing near a third of the first number, because in roughly four of five reconciliations the opening rested on contestable assumptions. Two findings dominate, unentitled virtual guests at fifteen to thirty percent of the running estate, and Developer subscriptions running production workloads, seen in one estate in four. And the evidence is five documents, a subscription register, a host inventory, eight quarters of reconciliation, Developer scope, and a decommission log. Notice that eight quarters, because it is the same two years you have been keeping for IBM.
Guest analyst clip. The distinction between auditing and reconciling sounds like semantics and it changes how you should prepare, so let me draw it out. An IBM audit is an argument about interpretation. What does the metric mean, which cores were eligible, what did the tool prove, was the boundary this wide or that wide. There is a great deal of judgement in it, which is why evidence and framing matter so much. A Red Hat reconciliation is much more arithmetic. Here are the systems running our software. Here are the subscriptions you hold. The difference is the number. There is far less room for interpretation, and I would say that cuts both ways for a buyer. On the one hand you cannot argue your way out of an unsubscribed system, because it either was running or it was not. On the other hand, the entire exercise reduces to the accuracy of two lists, both of which are yours. So the preparation is different in kind. For IBM you build an evidence trail and a set of arguments. For Red Hat you keep two registers accurate and reconciled, quarterly, and if you do that honestly there is essentially nothing to find. It is a duller discipline and it is a more complete defence.
A duller discipline and a more complete defence. Two registers, kept accurate and reconciled quarterly. And one of the things that reconciliation finds is that you are paying twice.
So, where the two paper trails overlap and both get paid. The Cloud Pak already carries OpenShift, restricted, at roughly three VPC per one VPC of Pak, and about half of estates separately licensed the same platform anyway. Restricted still means restricted, so it covers the Cloud Pak workloads only and your own applications do need their own subscription, and those two facts get confused in both directions, which is how estates manage to be simultaneously over licensed and exposed. Reconcile subscriptions against VPC, node by node, asking which cores are covered by the Pak entitlement, which need a standalone subscription, and which are currently covered twice. Decommissioned systems keep their subscriptions, which is why a decommission log is one of the five documents and why renewal counts drift upward without anybody adding anything. And virtualisation drift inflates renewals, because counts sized on socket pairs and virtual cores that moved as the estate virtualised have inflated renewals by fifteen to thirty five percent.
Now the commercial picture, which is a genuine decision rather than a rule. Direct pricing runs deeper, with direct Red Hat producing twenty five to forty percent below list while the IBM master agreement path lands at twenty to thirty five, a difference of five to ten points. The counter argument is real, because consolidated benchmarking and co terminus renewal packaging across both vendors has produced a median twenty percent recovery on the combined renewal. So it is a genuine trade, deeper unit pricing on separate paper against negotiating leverage and a single renewal event, and my advice is to decide it deliberately rather than by default, because the default is whatever your IBM account team proposes. Terms move the number, with three year terms attracting three to five points more and a default renewal uplift of five to seven percent negotiating to three to four without much difficulty. And a documented alternative is worth five to ten points, because a benchmarked AlmaLinux, Rocky, SUSE or Ubuntu Pro comparison improves the band with no migration intent required.
Knowledge check three. A Red Hat renewal is twenty five percent larger than last year and nothing new was deployed. What is the likely cause? A, a price increase, so the response is a discount conversation. B, count drift, where virtualisation moved the socket and core basis and decommissioned systems kept their subscriptions. C, the IBM acquisition changed the metrics. D, nothing can be done, subscription counts only go up. Pause here, and ask whether the count changed or the price did.
The answer is B, count drift. Counts sized on socket pairs and virtual cores that drifted as the estate virtualised have inflated renewals by fifteen to thirty five percent, and that is a quantity problem wearing a price problem's clothes. Answer A is the reflex, and I want to name why it is the wrong reflex, because it is not obviously wrong. A discount on a drifted count is precisely the same mistake as a discount on a bloated baseline from session five. You will feel like you won, the number will be smaller than the ask, and you will have locked in an inflated quantity for the length of the term. Fix the count first, then discuss the rate.
Guest analyst clip. I am asked constantly whether Red Hat should sit inside the IBM agreement or on its own paper, and I want to give you both sides honestly, because I do not think there is a universal answer and I distrust advisers who claim there is. The case for separate paper is straightforward and it is about pricing power. Direct Red Hat pricing runs deeper than the IBM route, by something like five to ten points, and more importantly the negotiation stays about Red Hat products against Red Hat alternatives, where you have real substitutes to point at. Fold it into an ELA and it becomes one line among many, and lines in a bundle are notoriously hard to value. The case for the combined agreement is also real. One renewal event, one set of dates, consolidated benchmarking, and the ability to trade across a much larger surface, and we have seen that produce a median twenty percent recovery on combined renewals. So how do I actually advise. I ask which lever the organisation is capable of pulling. If you have the discipline to run two negotiations properly, separate paper usually wins. If your reality is that renewals get handled in a rush by people with too many vendors, the combined event with a serious benchmark behind it is the better trade, because a slightly worse structure executed well beats a better structure nobody has time to execute.
So, the operating model, three roles and one quarterly review. A SAM lead owns entitlement and audit response for both regimes, because the person who can produce the IBM pack should be the person who can produce the Red Hat one. A platform lead owns the tooling, meaning Subscription Manager and Satellite, keeping the register and the running inventory in agreement with each other. A FinOps partner owns cost visibility, which is what turns right sizing from an idea into a recovered number somebody actually reports. One quarterly review covering both estates, subscriptions against running systems, and Red Hat entitlement against Cloud Pak VPC on shared nodes, in the same hour rather than in two separate meetings that never compare notes. And a decommission log that is actually kept, which is the cheapest of the five documents and the one that stops a renewal growing while the estate shrinks.
Three sentences. Red Hat counts on its own units, a socket pair of up to two populated sockets for RHEL regardless of core count, and a core pair of two physical or four virtual cores on compute nodes only for OpenShift, so none of the IBM counting habits from this course transfer. ILMT does not cover Red Hat, which means a mixed estate runs two compliance tools whose reports never consolidate, and a customer can pass an ILMT audit and fail a Red Hat reconciliation in the same year without either event explaining the other. And Red Hat reconciles running instances against active subscriptions rather than auditing licences, the opening figure lands near a third once contestable assumptions are tested, and the recurring findings are unentitled guests at fifteen to thirty percent of the estate and count drift that has inflated renewals by fifteen to thirty five percent.
Homework, about an hour. Count your populated sockets, for your largest RHEL hosts, populated rather than installed, and check the subscription count matches the socket pairs. Compare running systems to the register, asking how many running instances have no matching entitlement, and holding in mind that the median answer elsewhere was twenty two percent. Check OpenShift sizing, asking whether the subscription was sized on allocated cores or on the trailing ninety day average of cores in use, because that gap has run twenty to forty percent. Look for the double payment, asking whether any node running Cloud Pak workloads also carries a standalone OpenShift subscription covering the same cores. And ask who owns the Red Hat evidence, because if the answer is the same person who owns ILMT then you are in good shape, and if the answer is nobody, that is your finding, and it is the same finding as session eight in different clothing.
Five guides. The Red Hat subscription pillar covers the five families and four metrics, the current list and negotiated bands, and where the saving on a combined renewal actually comes from. The subscription compliance guide covers socket pairs, guest and Virtual Datacenter subscriptions, and why Simple Content Access removed the signal that used to warn you. And the IBM and Red Hat integration guide covers the doubled audit surface, the two tools that do not consolidate, and the honest debate about own paper versus the IBM agreement.
The Red Hat audit defence guide explains reconciliation rather than audit, the unsubscribed system as the unit of risk, and where the opening figure usually lands once it is tested. And the RHEL negotiation guide covers the levers on a renewal, term structure, uplift caps, and what a documented alternative is worth at the table. Next time, IBM software on public cloud: bring your own software licence, the cloud policy, and how to run on AWS and Azure without losing sub capacity. See you there.