PVU Sub-Capacity Traps with ILMT

All might not be as it seems - check this list of ILMT gotcha's

---

In order to get the benefit of PA sub-capacity licensing, running  IBM's free License Management Tool (or the enhanced, licensable version, BigFix Inventory - now owned by HCL) is mandatory...

... but could it be misleading and costing you money?

---

Here are out top five tips for trimming your PVU sub-capacity report counts:

1. Incomplete Vitualisation - the 'TVM' predicament

If your ILMT configuration is not fully or properly implemented you're likely to find incomplete virtualisation heirarchies in your VM Manager connections, which result in every affected VM being treated as a stand-alone physical machine at the highest PVU rating of 120 PVUs per core). This can quickly add up where you might otherwise be entitled to  the likes of 70 PVUs per core.

2. Missing Software Classifications

Central to the accuracy of ILMT reporting is the much dreaded 'Software Classification' process. If you choose to ignore this painstaking requirement you can be sure you'll pay the price either in real terms or in time-draining dispute at your next audit. Essentially, every exempt PVU count in your environment needs to be catagorised as such, meaning instances that are to be excluded from PVU counts (which depending on the License Terms are likely Developer, DR, or Test installs) need to be individually identified as such via this (ongoing) activity.

3. Unrecognised Bundling

As a follow-on to the Software Classification issue above, you'll then likely notice that where you have installed Supporting Programs on a different server - where entitled to do so under the License Terms - the program will magically form part of the PVU count, ie. bundling is not recognised across servers. So once again you'll need to identify these instances and exclude them from the relevant count, making sure you add comments to qualify the classification.

4. Reallocation High-Water Marks

So you dutifully maintain your vCPU's to your level of entitlement, which, as you're permitted to do, includes  the occasional reallocation across servers to match processing and performance needs. Given you've balanced the core counts out all is good - right? Well ... no, ILMT will track the high-water mark for each server in the 90-day reporting period, so for example a taking a core from a 4 vCPU server to assign to a 3 vCPU server will see both reporting as 4 vCPU servers for that period.

To be in a position to challenge this make sure you have or take - and keep - separate records that evidence the reassignment of cores to negate any double counting.

5. Ghost Decommissioning

Similar to the above, you might think that decommissioning one server to deploy another would be quite within your rights as long as you (as always) don't exceed your level of entitlements. Well ... no, the decommissioned server will also report within the same 90-day period as the new server - potentially a bigger problem than the issue with high-water marks. So again you'll need to either classify the server accordingly, or ensure you have the right artefacts to contest any double recognition, or both.

... a lot of overhead right? 

Yes.

And that's where a secondary source of truth can prove essential ...