Contents
Key takeawaysHow AIOps is licensedILMT and License ServiceWhat it costs in practiceWhat we saw in 2024 and 2025Checking your own positionAnswering the account teamWhat to do nextFAQIBM Cloud Pak for AIOps is licensed by Managed Virtual Server or by Resource Unit, depending on the deployment. The managed node count and its conversion drive the bill, and that count is usually where overspend sits.
- Entitlement model. Cloud Pak for AIOps is sold on the IBM Cloud Pak entitlement model and priced by the scope it manages.
- Two metrics. The common metric is the Managed Virtual Server, with Resource Unit conversions in some editions and components.
- Managed nodes count. The requirement tracks the servers AIOps manages, so retired hosts left connected keep costing money.
- Evidence decides capacity. ILMT supports sub capacity on virtual machines and IBM License Service is mandatory in containers; without them IBM counts full capacity.
- Flex has limits. Cloud Pak entitlements can move across the bundle, but AIOps specific ratios and edition rules still apply.
- Where savings come from. Cutting inactive nodes from the managed scope and proving sub capacity are the two biggest sources of savings.
This guide is for IT operations and procurement leaders sizing or renewing IBM Cloud Pak for AIOps in 2026. It sits alongside our Cloud Pak licensing guide and the Cloud Pak for Data licensing guide, and the wider IBM Knowledge Hub covers the rest of the IBM catalog.
How does IBM Cloud Pak for AIOps licensing work?
Cloud Pak for AIOps is sold on the IBM Cloud Pak entitlement model, and you buy entitlements measured against the scope AIOps manages rather than the servers the AIOps platform runs on. IBM describes the product and its capabilities on its Cloud Pak for AIOps page.
The common metric is the Managed Virtual Server, and some editions and components convert to Resource Units. Which of the two applies to your contract matters more than the feature list, because it decides how the bill grows. Sizing AIOps by the cluster it runs on tracks the wrong number.
What is the Managed Virtual Server metric?
A Managed Virtual Server is a virtual server that AIOps observes and manages. The count follows the monitored environment, so every workload you connect for event correlation, anomaly detection or runbook automation adds to the license requirement.
The reverse is also true. Servers that were retired but still sit in the managed scope keep inflating the count until someone removes them, and that cleanup is rarely anyone's job by default.
How do Resource Units fit in?
Resource Units are a normalized capacity metric IBM uses across Cloud Paks, and some AIOps editions and components convert managed scope into them. The conversion ratio sets how many units each managed server consumes, so an error in the ratio flows straight into the entitlement you buy. IBM explains the entitlement model in its Passport Advantage documentation.
Take the ratio for each component from the License Information document for your edition. A ratio copied from an old quote or a partner spreadsheet may not match your edition, and conversion errors are one of the patterns we describe below.
Does the entitlement include Red Hat OpenShift?
Yes. Cloud Pak for AIOps runs on Red Hat OpenShift, and the Cloud Pak entitlement includes OpenShift for the supported scope. That OpenShift is there to run the Pak. If your platform team puts other applications on the same worker nodes, those need their own Red Hat subscriptions, and an IBM or Red Hat review will ask for them.
Do you need ILMT or IBM License Service for Cloud Pak for AIOps?
You need the tool that matches where each piece of software runs, and many buyers need both. ILMT, the IBM License Metric Tool, is the evidence for sub capacity licensing of IBM programs on virtual machines. IBM License Service is mandatory for IBM software deployed in containers, which is how AIOps runs on OpenShift.
| Question | ILMT | IBM License Service |
|---|---|---|
| Where it applies | IBM programs on virtual machines, licensed sub capacity | IBM programs deployed in containers, including Cloud Paks on OpenShift |
| Deployment deadline | Within 90 days of your first eligible sub capacity deployment | Within 90 days of your first eligible container deployment |
| If it is missing | Full capacity: every physical core activated and available on the server | IBM charges for all cores in the entire cluster |
| Records to keep | ILMT audit reports, with a reporting period no longer than a quarter | Quarterly usage reports, kept for two years |
Why does sub capacity licensing need ILMT?
To license sub capacity rather than full machine capacity, IBM requires ILMT installed and reporting. Without current ILMT reports, IBM defaults the count to full capacity, meaning every physical processor core activated on the host. The rules are in IBM's sub capacity licensing terms, and our ILMT sub capacity guide covers deployment and report hygiene.
What changes when AIOps runs in containers?
IBM's container licensing terms name IBM License Service as the only accepted tool for tracking container usage, with no exceptions. It ships with each Cloud Pak's services, so deploying it costs little more than the time to install and check it. Container usage is counted as 1 VPC per vCPU, based on the CPU limits set on each pod.
If any AIOps components or connected IBM products run on virtual machines, IBM expects both tools. In a hybrid deployment, agree which team owns each tool and which servers each one covers, because a gap between the two is easy to miss. The Cloud Pak VPC licensing overview explains how container cores are counted.
IBM Cloud Pak Negotiation Guide
Entitlement sizing, conversion ratios, sub capacity evidence and renewal terms for Cloud Pak buyers, in one download.
Get the white paper →What does Cloud Pak for AIOps cost in practice?
Model cost as managed scope multiplied by the metric rate, then adjusted for sub capacity. The managed node count changes the total more than anything else, and it is also the number you control. The scenarios below use the same 200 active virtual servers.
| Scenario | Managed scope | ILMT in place | Licensing basis |
|---|---|---|---|
| Sub capacity, accurate count | 200 managed virtual servers | Yes | Lowest exposure. You pay for what AIOps manages. |
| Full capacity default | 200 managed virtual servers | No | Higher exposure. Hosts count at full capacity. |
| Overstated scope | 260 counted, 200 active | Yes | You pay for 60 inactive nodes. |
| Resource Unit edition | Converted scope | Yes | The conversion ratio decides the requirement. |
A worked example: counted scope against active scope
Say AIOps is connected to 260 virtual servers, but only 200 of them are active. Assume, purely for illustration, that your edition converts each managed server at 4 Resource Units, while the order form was built at 5. These ratios are hypothetical. Use the ones in your own License Information document.
- What you need. 200 active servers at 4 units each is 800 Resource Units.
- What the order carries. 260 counted servers at 5 units each is 1,300 Resource Units.
- Scope error alone. Removing the 60 inactive servers at the order's ratio saves 300 units, and the counted scope was 30 percent above active scope.
- Ratio error alone. On 200 servers, the ratio gap is 1,000 units against 800, a 20 percent swing on the ordered figure.
- Both together. 1,300 units against 800 is 500 units of excess, about 38 percent of the order, paid again every year in subscription and support.
Can entitlements flex across the Cloud Pak bundle?
Partly. Entitlement can be moved within the bundle, within limits that rarely come up in the sales conversation:
- Shared entitlement pool. Some Cloud Pak entitlements move across the capabilities included in the bundle.
- AIOps specific ratios. Conversion ratios still bind the AIOps components, so moved entitlement does not always go as far as you expect.
- Edition limits. Not every capability is interchangeable, so confirm the rules for your edition before you reallocate anything.
If you expect to shift spend between Cloud Paks later, get that right in writing. Our note on Cloud Pak swap and substitution rights covers the wording.
Why we would not buy extra entitlement for flexibility
The standard IBM account pitch is that the Cloud Pak bundle gives you room to grow, so you should buy generously now. We disagree. In 30 to 50 percent of the environments we reviewed, missing ILMT meant buyers paid full capacity on scope they believed was sub capacity. Buying extra entitlement did not protect them.
Stand up ILMT and License Service first, prove the managed count, then size entitlements to active scope. Cover later growth with a price hold on additional units.
What have we seen in recent IBM Cloud Pak reviews?
Across roughly 15 to 25 Cloud Pak reviews we handled between 2024 and 2025, the recurring exposure was metric confusion and missing ILMT. The entitlement price was rarely the biggest problem. Three patterns came up again and again:
- Full capacity by default. Missing or stale ILMT pushed buyers to full capacity in 30 to 50 percent of the environments we saw.
- Overstated managed counts. Managed node counts ran 15 to 30 percent above active scope, which usually means inactive servers were still counted.
- Conversion errors. Wrong Resource Unit ratios moved the license requirement by 10 to 20 percent.
Cloud Pak for AIOps is priced on the environment it watches. Prove the managed count before you sign, and the bill follows reality.
How do you check your own AIOps license position?
Start with the records IBM would ask for in an audit, then compare them with what AIOps actually manages. Four sources cover most of it:
- ILMT audit snapshot. Confirms sub capacity reporting is current for every virtual machine running IBM software, with no gaps in the reporting period.
- IBM License Service audit snapshot. Shows container usage for each OpenShift cluster. Where you run several clusters, the License Service Reporter aggregates them in one place.
- AIOps resource inventory against the CMDB. List the servers AIOps manages and match them to live systems. Anything retired, duplicated or out of scope is a candidate for removal.
- Passport Advantage entitlement records. Check the part numbers, metrics and quantities you actually own against what the account team assumes you own.
Which mistakes cost the most?
- Onboarding everything on day one. Connecting every discovered server to AIOps before deciding which ones need it sets the count at its highest point.
- Treating License Service as optional. It is mandatory for container deployments, and a gap turns a sized AIOps footprint into a charge for the whole cluster.
- Letting two inventories drift apart. When the AIOps topology, the CMDB and the License Service data list different servers, an auditor starts from the highest and you have to explain every difference. Reconcile them before the account team asks.
- Reusing ratios from another Cloud Pak. Each Pak and edition has its own conversion rules.
What will the IBM account team say, and how should you answer?
Expect the conversation to center on bundle value and growth. These are the lines we hear most often on Cloud Pak renewals, with the replies that keep the discussion on your numbers.
| What the account team says | What to say back |
|---|---|
| "The bundle is flexible, so size for where you will be in three years." | We size to active scope today and want a price hold on additional units for the term. |
| "Your managed count is 260, per our records." | Our reconciled count is 200. Send us the data behind yours and we will compare them line by line. |
| "The ratio on the quote is the standard one." | Show us where it appears in the License Information document for our edition. |
| "ILMT gaps mean full capacity for the whole period." | We will show current reports now. Let us agree the period and scope of any review in writing first. |
Contract wording to ask for
- Stated conversion ratio. Write the Resource Unit ratio for each AIOps component into the order, so it cannot drift at renewal.
- Price hold on growth. Fix the unit price for additional managed scope for the term. See our note on IBM price hold clauses.
- Renewal uplift cap. Limit the increase on renewal, as covered in our renewal uplift cap language.
- Reduction rights. Keep the right to lower quantities when managed scope shrinks. Our guide to termination and reduction rights shows the wording.
- Audit notice and scope. Set a notice period and limit how far back any review can reach, using the approach in our IBM audit clause redlines.
For the wider negotiation, including timing and discount targets, see our Cloud Pak licensing negotiation guide.
What to do next
- Twelve months out. Confirm ILMT is installed, current and reporting, and that IBM License Service runs on every cluster, before any true up.
- Nine months out. Reconcile the managed virtual server count against active monitored scope.
- With the same count. Check the Resource Unit conversion ratio on every AIOps component against your License Information document.
- Six months out. Remove inactive or decommissioned nodes from the managed scope and keep a dated record of the cleanup.
- Before the quote arrives. Map which entitlements flex across the Cloud Pak bundle and which do not.
- Three months out. Benchmark your entitlement pricing against comparable IBM customers.
- At the table. Bring an independent benchmark to the renewal or audit conversation, along with your reconciled count.
Frequently asked questions
How is IBM Cloud Pak for AIOps licensed?
It is licensed against the scope it manages under the IBM Cloud Pak entitlement model, mostly by Managed Virtual Server, with Resource Unit conversions in some editions. Before you compare quotes, confirm which metric each part number on the order uses, because two quotes for the same environment can rest on different metrics.
What is a Managed Virtual Server in AIOps licensing?
It is a virtual server that Cloud Pak for AIOps observes and manages. The count rises as you connect more monitored workloads, so onboarding decisions made by operations teams are also licensing decisions. Agree a simple approval step before new server groups are connected.
Do I need ILMT for Cloud Pak for AIOps?
You need ILMT for any IBM programs on virtual machines that you license sub capacity, and IBM License Service for the containerized AIOps deployment on OpenShift. Without current ILMT reports IBM counts full capacity, which can multiply the requirement on large virtualization hosts.
What is the Resource Unit metric?
A Resource Unit is a normalized capacity metric IBM uses across Cloud Paks. Some AIOps editions convert managed scope into Resource Units at a defined ratio per component. Ask IBM to state that ratio in the order itself, so a renewal quote cannot apply a different one.
Can Cloud Pak entitlements move between products?
Some can move across the capabilities included in the bundle, but AIOps specific conversion ratios still apply and not every capability is interchangeable. Moving entitlement between different Cloud Paks usually needs a swap or substitution right written into the contract, so ask for it before signing.
How do I reduce Cloud Pak for AIOps cost?
Remove decommissioned and out of scope servers from AIOps, keep ILMT and License Service reporting current, and correct any wrong conversion ratios before renewal. Then buy to the reconciled active count and negotiate a fixed unit price for growth instead of prepaying for it.
Does Cloud Pak for AIOps run on OpenShift?
Yes. It runs on Red Hat OpenShift, which the Cloud Pak entitlement includes for the supported scope. Check that boundary with your platform team so you neither double count OpenShift you already own nor under license other applications placed on the same worker nodes.
What triggers an IBM audit on Cloud Pak?
Common triggers are missing or stale ILMT or License Service reporting, rapid growth in managed scope and entitlement records that do not match deployment. Keeping quarterly reports on file and reconciling managed scope twice a year is the best protection against a full capacity finding.