Background
IBM software is typically deployed on virtual machines (VMs) which in turn are deployed on a physical server (host). Two or more hosts can then form a cluster. Multiple servers make a server farm.
If there are few restriction on which server a VM is allowed to run it is at risk of “wandering”, moving from host to host. This level of flexibility can have benefits from a resilience point of view but comes with a significant compliance risk and potential license cost especially in relation to IBM sup-capacity licensing.
IBM sub capacity licensing and the impact of the high water mark rule
If you comply to IBM sub capacity rules you only need to licenses the number of cores assigned to a VM. If you increase the number of cores, even for a short period, you must pay for the higher number of cores. This is known as the licensing “high water mark” and is tracked in ILMT in the License Peak Value History. To minimise your license demand and ultimately the cost of IBM licensing you want to keep the “high water mark” as low as possible. If you ever see a change in this number you will want to investigate immediately.
What if a VM with IBM products moves to another server?
If a VM, running IBM products, moves (or migrates) to a different physical server ILMT will treat this as a new installation. This in turn will increase the high water mark and your license demand.
There may be a very good reason why the VM migrated (e.g. node crashed) but ILMT cannot automatically detect this and will always error on the side of IBM when it comes to counting licenses.
A more common reason a VM is moved is an administrator trying to grant more resources or improve performance for applications running on the host and the current host does not have enough.
Whatever the cause the result is the same, a significant increase in your IBM license costs.
How to fix a reporting error in ILMT
If the move/migration is due to a disaster and the VM is only running on one host then you can manually correct the reports in ILMT. It is best to make the update when the VM has returned to the original host and excluding it from the temporary host.
It is very important that you add a detailed note to ILMT explaining why you are made the update in case of audit. This should include a reference to the helpdesk ticket and any other information related to the cause. This applies to any exclusion or manual update made to ILMT.
Managing VM movement and compliance risk
There is no denying the resilience , scalability and flexibility virtualisation gives an organisation. This flexibility can come with a significant IBM licensing cost if not managed properly.
Some steps to reduce the license impact of virtual machines moving :
- Establish a Virtualisation Policy with clear rules where and how IBM products are deployed.
- Ensure ALL changes to VMs with IBM products go through rigorous Change Management, including a review by the SAM team.
- Provide your administrators with foundation training in IBM license so they understand the impact of the changes they are making.
- Configure your virtualisation rules for migration and affinity (where and when) with an understanding of the impact it will have on license costs.
Conclusion
Understand that there is a significant license cost if you don’t manage the movement of VM around your server farm.
