Container licensing FAQs

Container licensing is focused on the licensing of software within containers running with Kubernetes orchestration. A container is a set of one or more processes that are isolated from the rest of the system where all the files necessary to run them are provided from a distinct image.

Sub-capacity licensing deals with licensing less than the full capacity of a server within an environment which employs virtualization technology (I.e., Virtual Machines)

If your deployment is making use of containers with Kubernetes orchestration, then Container Licensing will allow you to license only the available capacity of your containerized Products rather than being required to license the entire cluster where your containers may be operating.

Additionally, container licensing offers the ability to count fractional cores across the entire cluster rather than forcing each worker node or pod to be counted up to the next full integer.

IBM License Service also automates collection of license usage data to help customers identify their software’s resource usage across the cluster; allowing them to adjust licensed entitlements and stay in compliance.

Yes.

Customers are currently only able to opt into Container licensing terms on a transactional basis via a Container Licensing transaction addendum.

With the release of next version of the IPAA, Container licensing terms will be included in the Agreement.

Clients may deploy on any Kubernetes-based solution.

Notes:

• IBM Cloud Paks are limited to Red Hat OpenShift.
• If you are not employing Kubernetes orchestration, then you cannot take advantage of this licensing model.

Currently only Linux-based containers are supported.

This information is available in the Product documentation.

Container Licensing is based on the vCPU requirements of the Cloud Paks. Customers should license OpenShift to the number of vCPUs that are required for their Cloud Paks as well as any additional overhead.

IBM offers three types of licensing for private cloud (or on-premise) deployments:

1. Full Capacity – Licensing the total physical capacity of the server where software resides.
2. Sub-Capacity – Licensing the virtualized capacity in a VM environment where software resides
3. Container – Licensing the virtualized capacity in a containerized environment where software resides

Due to the nature of how Kubernetes deploys containers throughout a cluster, the use of sub-capacity with IBM License Metric Tool is not possible. Therefore, if you wish to make use of containers along with Kubernetes orchestration, you must either use Container Licensing or license the full capacity of every cluster on the server.

No, if you do not license on container licensing terms, you must license the full physical capacity where the cluster is deployed.

How you license your software depends on how your software is deployed.

• Container deployments which make use of Kubernetes orchestration use Container Licensing.
• Container deployments without orchestration use sub-capacity licensing at the VM layer Software deployed within VMs use sub-capacity licensing

All deployments may also license to the full capacity of the nodes where the software is (or may be) deployed. Therefore, if the you decide to deploy software in containers with orchestration via Container Licensing and then decide to migrate the entire or part of the environment back to VMs, the part that is now on VMs can be licensed on sub-capacity licensing.

Customers must maintain the IBM License Service rather than IBM License Metric Tool (note: IBM License Metric Tool still must be used for sub-capacity deployments). Beyond this, audit and compliance are no different than the sub-capacity licensing rules as stated in the International Passport Advantage Agreement.

The IBM License Service is capable of automatically tracking license usage of containerized software. Customers may utilize the use reports output by the IBM License Service that provide customers with daily peak available capacity for their licensed Programs (and solutions within Cloud Paks). This allows customers to verify their usage in relation to their licensed entitlements and proactively make adjustments.

The preset resources.limits.cpu settings that ship with each Program are used in all QA, performance testing, etc. While IBM does not recommend modifying these settings, if you should choose to do so, please first consult the product documentation to understand the acceptable documented ranges for your Programs.

Currently supported core-based metrics are as follows: Processor Value Units (PVU), Virtual Processor Cores (VPC). When any other metrics are supported, these webpages will be updated.

Products which have not been converted into a containerized image and hence do not support being run in a containerized environment are ineligible. Additionally, any Product that has not been enabled to run and be tracked by IBM License Service will not be eligible for Container Licensing.

The product and/or part number description will state the licensing metric. The following links are sources for Passport Advantage pricing/licensing:

• IBM License Information document database
• IBM Passport Advantage Licensing

As outlined on the IBM Container Licenses page, the required entitlements will be licensed as based on the total vCPU capacity of a program. That is, the total amount of vCPUs available to a Pod as defined by the counting methodology.

Please note: Any pod which contains a container without a CPU limit is considered to have vCPU capacity equal to the worker node capacity.

• The vCPU capacity of a pod is the sum of the CPU limits for all containers within that pod. Pods with vCPU capacity less than one core will be counted as fractions.
• Within a worker node, when the total vCPU capacity for all pods of an IBM Program exceeds the worker node capacity, the vCPU capacity is equal to the worker node capacity. vCPU capacity for an IBM Program will be aggregated at the cluster level and any fractional values rounded up to the nearest whole integer.

For typical licensing arrangements (including sub-capacity), customers licensing on the PVU metric are required to determine their PVU to core value based on the charts on the Processor Value Unit licensing webpage. This is not a requirement for containers, all PVU deployments will be rated at 70 PVUs to 1 core.

Generally, 1 VPC = 1 physical core or 1 virtual core.

This means that any group of Pods for a Program will have the count of their cores added together across the entire cluster of servers then added together. For example:

• Worker Node 1 -> 3 Pods @ 0.1 cores = 0.3 cores
• Worker Node 2 -> 8 Pods @ 0.2 cores = 1.6 cores

Total -> 1.9 cores -> 2.0 cores charged -> 2 VPCs or 140 PVUs

For Cloud Paks, cluster rounding is at the Bundled Solution level (not Cloud Pak).

IBM licenses containers based on their potential capacity rather than actual usage. If a container does not have a limit then the potential capacity for that container is the entire node capacity. Therefore, the container would be charged as such.

In any instance where total Pod capacity for a Program exceeds that of the worker node, the worker node capacity is used. For example:

Node Capacity = 8 cores

• Pod 1 -> 3 cores
• Pod 2 -> 3 cores
• Pod 3 -> 3 cores

Total = 3+3+3 = 9 cores -> 8 cores to be licensed due to capping.

For Cloud Pak deployments, capping is at the Bundled Solution level (not Cloud Pak).

IBM has traditionally charged for software based on peak capacity across the license period. For example: If on a full year license, a Program typically used 8 cores, but in November they used 12 cores, the license charge for the year would be 12 cores.

This does not change for containerization licensing. IBM License Service tracks license usage while frequently polling how many Pods (and cores) for an application are deployed. Therefore, the highest point is taken as the license requirement for the license period.

It should be noted that Cloud Paks (other than Cloud Pak for Data) take into account Cloud Pak ratios. Therefore, if at a single moment Program A with a 3:1 ratio and uses 9 cores, while Program B with a 1:1 ratio uses 4 cores, then 7 cores would be the high-water mark for the Cloud Pak (9/3 -> 3 + 4/1 -> 4 = 7)

Yes, the minimum licensing requirement is one core.

No, fractions of a core will be accounted for by adding all cores within the pods for each Program in the cluster and rounded up to the nearest full integer.

You can manually aggregate VPC based on documented procedures.

You can use License Service Reporter.

Yes, but you must use License Service version 1.18. If lower version of License Service are in use, there might be situations where a Rolling Upgrade could generate an overcounting. If such a condition occurs, please retain and archive systems logs and attach them to your license usage reports.

You can use License Service Reporter.

Customers must create quarterly reports as stated in the container licensing terms. They must maintain this documentation as evidence of on-going license compliance management of entitlements available to IBM middleware. As per the terms of the offering, customers must make these reports available upon IBM or independent auditor’s request (refer to the IBM Passport Advantage Agreement).

Yes, the use of the IBM License Service is required for containerization licensing.

No, only the IBM License Service may be used.

Like IBM License Metric Tool, IBM License Service is free.

Yes, you can take advantage of our Bring Your Own Software License (BYOSL) program. Available providers are listed on the BYOSL page

Customers who are not in compliance with using IBM License Service will be charged for all cores in the entire cluster. This is because when taking advantage of Kubernetes, containers can be spun up on any node throughout the cluster. Therefore, there is a potential that a single program could have containers which take advantage of the entire capacity of the cluster.

New container licensing customers are required to implement IBM License Service within 90 days of their first Eligible Container Product deployment.

Existing container customers should promptly upgrade to new versions, releases or modifications when they are made available per Container Licensing terms.

Due to the complexity and rapidly changing deployments in Kubernetes environments, manual reporting has been deemed unfeasible. As such, no exceptions are allowed; IBM License Service must be used when deploying containers with Kubernetes orchestration.

Yes, IBM License Service is mandatory

IBM License Service runs in a Pod within a worker node within the Cluster as determined by Kubernetes scheduler.

In the case of multiple clusters, License Service is installed in each cluster where containerized software is deployed (customer should verify installation and keep License Service healthy.

License Service will output data that can allow for this consolidation; however, this must be done manually. Customers can alternatively make use of License Service Reporter to automate this functionality.

IBM License Service Reporter collects and aggregates data from IBM License Service from multiple clusters and from IBM License Metric Tool. For more details consult IBM License Service documentation.

Within 90 days of installing any Eligible Program which takes advantage of Container Licensing, either i) verify whether IBM License Service is installed, properly configured (refer to Program documentation), is running and maintained or ii) if IBM License Service is not installed and properly configured, obtain, install, configure, and maintain IBM License Service, in accordance with the user guide.

Generate and maintain for two years, IBM Use Reports each quarter for the entire reporting period (i.e., the period which begins on the first day of the first month in a calendar quarter, or for purposes of the initial report upon installation of the tool, and ends on the last day of the last month in the calendar quarter) for each eligible container. Any Product deployment which occurs during the quarter will begin reporting as of the day of deployment.

Product licensing documents define the requirements for each Product.

The IBM License Service may come preinstalled when deploying containerized software via each IBM Cloud Pak’s services and within IBM Certified Containers. Please verify installation upon your first container deployment. If IBM License Service is not installed, contact product support or talk2sam@us.ibm.com

There is not a part number for IBM License Service.

No. IBM License Service does not come with a free OCP entitlement. License Service is included in the IBM Cloud Pak services and therefore leverages available OCP entitlements of the Cloud Pak or direct entitlements that the customer obtains from Red Hat.

When License Service is being utilized outside of Cloud Paks, the customer is responsible for any overhead that License Service may require.

License Service is a lightweight tool that consumes very little resources. Please refer to the knowledge center documentation for more information.

If you are only running a containerized environment, then IBM License Metric Tool is not required. However, IBM License Metric Tool is still a requirement for sub-capacity (virtual machine) environments. If you have a hybrid environment, then both tools must be installed.

Customers must maintain the IBM License Service rather than IBM License Metric Tool (note: IBM License Metric Tool still must be used for sub-capacity deployments). Beyond this, audit and compliance are no different than the sub-capacity licensing rules as stated in the International Passport Advantage Agreement.

The IBM License Service is capable of automatically tracking license usage of containerized software. Customers may utilize the use reports output by the IBM License Service that provide customers with daily peak available capacity for their licensed Programs (and solutions within Cloud Paks). This allows customers to verify their usage in relation to their licensed entitlements and proactively make adjustments.