Don’t pay extra for middleware when upgrading hardware

There are lots of sayings about computer hardware. Some have to do with speed, size, or other factors like product lifespan. One of my favorites goes along the lines of no matter what you buy today, it will be obsolete tomorrow. The pace of change for technology moves at a blistering pace. If you can get 3-5 years of useful service from a laptop or server many will call you lucky. If you go over that timeframe you run the risk of getting looks with raised eyebrows and musings over your ability to keep up with the times.

So if we can take it as a given that hardware gets upgraded on a regular basis, should you expect to pay extra for your existing middleware when you upgrade the hardware? I don’t say no, I say hell no! But that is exactly what could happen if you work with some software vendors. In this article I am going to discuss specifically how you might find yourself paying more for IBM middleware when you upgrade your hardware. Here we go!

Not everyone offers pricing like Red Hat that is straightforward, allowing you to purchase subscriptions in 16- and 64-core increments. IBM, by comparison has a much more difficult pricing strategy to understand. It offers four different types of user-based licensing, four types of capacity-based licensing, and two types of “other licensing”.1 All IBM WebSphere software is priced using one or more of those metrics. Based on discussions with people who have interacted with IBM, it appears that the most common form of IBM pricing metric proposed for licensing terms is based on processor value unit. Commonly referred to as “PVU” pricing by IBM in documents.

In 2006 IBM introduced the PVU license metric to address multi-core processors and increasingly powerful hardware technologies. The PVU license metric is meant to align license requirements with hardware performance. Currently, IBM PVU calculations are based on processor vendor, brand, and model number. Basically, the more powerful a computing core is, the higher a PVU metric is assigned.

For example, Intel based servers can range from 50 PVUs per core to 120 PVUs per core. However, for Intel based servers, IBM PVU pricing gets even more complex. For Intel CPU makes and models, the number of sockets in a server chassis that CPUs can be plugged into also has an impact on the IBM PVU rating. For example, every Intel CPU that can’t be assigned a 50 PVU per core rating, can be assigned a 70, 100, or 120 PVU per core rating. The exact rating assigned by IBM depends on Intel model numbers, plus, the number of sockets in a server chassis. A rating of 70 PVU per core is possible when the Intel CPU is installed in 2 socket servers, 100 PVUs per core when installed in 4 socket server, and 120 PUVs per core when installed in any chassis with 5 or more sockets.

What about virtualized cores?

So far this article has covered physical servers and IBM PVUs. What about virtualized environments? In that case, IBM counts the total cores needed by the lessor of physical cores or virtual cores used on a server. So if you have 8 physical cores on a server, but only 4 virtual cores are running middleware, you only count the 4 virtual cores. In another scenario, if you have 4 physical cores but 8 virtual cores running middleware, then you only count the 4 physical cores.

What about the PVU rating per core within virtual environments? Is there a different method used to determine PVU rating? The answer is no. You still need to account for processor vendor, brand, model number, and potentially socket count to determine the proper PVU rating per core for each server. This can lead to a significant challenge counting cores to license compliance in environments with a mix of hardware with varying core counts and PVU ratings per server core.

It is challenging enough to count all the PVUs needed on a static collection of virtualized servers. What happens when the virtualized environment is not static and virtual machines can move from one piece of physical hardware to another? How much will it cost to keep an accurate count of the physical cores in place?

How much more will it cost to move core counts between PVU ratings?

When you change the hardware you are deploying IBM PVU licensed software to, you run the risk of changing CPUs being used, and therefore, the associated PVU rating per core. Depending on how big the change in PVU value is, the change can be significant. For example, as shown in Table A, you can move between 50, 70, 100, and 120 PVU per core ratings. Thus, a move from 50 PVUs per core to 100 PVUs per core, for the same amount of cores, is a 100% increase in total PVUs needed for licensing. A move from 70 PVUs to 100 PVUs per core is less dramatic of an increase, but sill substantial increase of almost 43% more PVUs to remain compliant with IBM licensing terms.

Table A

percent change in value moving from one PVU rating to another

Processor value unit moving to
50 70 100 120
Processor value unit moving from 50 40.00% 100.00% 140.00%
70 -28.57% 42.86% 71.43%
100 -50.00% -30.00% 20.00%
120 -58.33% -41.67% -16.67%


Can’t the PVU rating for a server move down over time?

Improvements in CPU capabilities and performance by manufacturers like, Global Foundries, Oracle, Intel, and others are a common occurrence. We have all likely heard the saying that what you buy today will be obsolete tomorrow. Fortunately the CPUs, and servers they are installed in, typically have a 5-7 year lifespan. If you were to track the IBM PVU table over time you would observe that ratings can change for CPUs and models as they age and new models are released. For example, in February 2015, the Intel Xeon processor model numbers rated by IBM at 50 PVU per core2 were almost all listed by Intel in an end of life stage.3,4,5 Yet from 2007-2009 when those same Intel Xeon processor model numbers were released, rated by IBM at more than 50 PVU per core.

Can decreasing PVU ratings mean increased IBM costs for licenses along with subscription and support?

It is reasonable to expect that the IBM PVU ratings for a server you deploy today will decrease over time. But should you use the increase in overall PVU count you get from aging servers with declining PVU values per core to deploy more IBM software? On the surface this might seem appealing since you would not have to pay IBM more existing pool of PVUs licensed and existing support fees are based on. However, at some point the servers with lower PVU per core rating will be retired and upgraded to servers with a higher PVU per core rating. If you increased your deployment server footprint of software based on the old server CPU PVU rating, you could find yourself having to pay IBM for more licenses and associated support to remain in license compliance.

How much? Well, if you upgrade all the cores rated at 50 PVU per core to ones rated at 100 PVU per core, you could double your license and support costs. However, that assumes that when you go to IBM to purchase more entitlements, you get the same discount you got with the original purchase of software. IBM product licenses and associated subscription and support pricing are based on the Passport Advantage (PPA) or Passport Advantage Express programs.6 Within that program, you will find RSVP levels that are adjusted up and down annually based on your purchasing history.7 The Passport Advantage RSVP level you are assigned will impact your IBM software subscription and support price. So there are two key questions you should consider asking in relation to subscription and support pricing:

  1. How will subscription and support pricing change in future years if your RSVP level changes?
  2. If IBM provides a special discount beyond your RSVP level, how long will that discounted S&S price remain in effect? What happens after that?

How is Red Hat pricing different?

As mentioned at the start of this article, Red Hat allows customers to purchase annual subscriptions in 16- and 64-core increments. Red Hat subscription core count can be used on any non-mainframe8 supported hardware, with any performance characteristics, or supported virtualized environment, without special rules related to CPU performance or socket considerations. Put in simple terms, different types of processor cores are treated the same. Therefore, you can upgrade servers to more powerful CPUs without having to renegotiate Red Hat subscriptions provided you do not exceed the cores in your existing subscription.

For virtual environments, Red Hat counts the lesser number of physical or deployed virtual cores on each machine for the purpose of counting cores. However, with Red Hat, your subscription costs will not vary as the CPU profile changes from server to server used in a hardware farm for virtualization. With IBM, as mentioned earlier, such a change in CPU profiles could impact the total PVU count.

1“Learn about Software Licensing.” IBM. IBM, n.d. Web. 08 Jan. 2015. <>.

2Intel Xeon processor model numbers 3000 to 3399, 5000 to 5499, and 7000 to 7499

3“Intel® Xeon® Processor 3000 Sequence.” ARK Product Launch. Intel, n.d. Web. 10 Feb. 2015. <>.

4 “Intel® Xeon® Processor 5000 Sequence.” ARK Product Launch. Intel, n.d. Web. 10 Feb. 2015. <>.

5 “Intel® Xeon® Processor 7000 Series.” ARK Product Launch. Intel, n.d. Web. 10 Feb. 2015. <>.

6 “Program Overview.” IBM Passport Advantage. IBM, n.d. Web. 08 Jan. 2015. <>.

7 “IBM.” International Passport Advantage Agreement (n.d.): n. pag. Web. 8 Jan. 2015. <>.

8 Red Hat mainframe pricing is base on IFLs which is beyond the scope of this article.

Leave a Reply

Your email address will not be published. Required fields are marked *