Enterprise Licensing – Watch out for Orphan VM’s

With most organizations having virtualized a significant portion of their server estate, it has become a necessity for the Software Asset Management (SAM) team to have a comprehensive knowledge of exactly what virtual machines (VMs) are running on which hosts and which hosts are in which clusters.

They must know what virtual machine is linked to what physical server and, in turn, what physical server is linked to which cluster, controller or SAN.

This gives rise to a new set of challenges for the SAM Team, the most notable being the Orphan VM.

So what causes the breaking of links and the creation of Orphan VMs, what are the risks and what can you do about it?

What is an Orphan VM

An Orphan VM is where you find and scan a virtualised server but cannot seem to find a physical host on which it is deployed. This is known as virtual to physical linkage. It is a serious risk to an organisation because most enterprise licenses are based on the number of cores of the physical (host) server, not the VM.

What Causes an Orphan VM?

There are a variety of causes but the most common ones are related to the time difference between when you scan the physical host and the virtual machines (VMs). Some examples are:

• You’ve missed scanning a physical host.
• The VM has been moved to another host in the middle of your scan.
• The VM has been backed up or decommissioned and not active on a host.
• The VM has been restored, renamed or reconfigured significantly so that it looks like a different server instance.
• Your SAM tool is not sophisticated enough to uniquely identify and link the VM to the Host.
• Your SAM tool does not support scanning of that virtualisation technology (IBM LPAR, Solaris Zones, etc.).

Whatever the cause you must resolve this problem as it can introduce a serious license compliance risk to your organisation.

What’s the risk of an Orphan VM

By not linking every VM in your network to a physical host you are basically saying you don’t really know how many cores should be licensed for your enterprise products.

• You could be over counting core licenses for products you no longer have deployed.
• A move of a VM to a larger host or cluster could require product licenses you have not budgeted for.
• In the event of a vendor true-up or review it generates doubt and increases the risk of an audit

What to do about Orphan VM

The first thing is to check if you have a problem with Orphan VMs:

• Get a list of all possible virtual hosts from your administrators.
• Cross checking each entry in your server scan and ensuring where the OS is a virtual machine that it is linked to a host.
• Check from the host side so you have accounted for all VMs. It is not unusual to miss all of the VMs on a particular host due to firewalls or VLAN configurations

If you do have a problem it is usually down to network access or credentials to scan the virtual host (e.g. IBM HMC or VMWare vCentre).

If it is not possible to automatically scan the hosts then you will have to ask your administrator to manually update a spreadsheet on a monthly or quarterly basis as the configuration frequently changes.

Conclusion

When the cost of miscalculating even one core of enterprise software is so high in an audit situation (e.g. $40K for Oracle Database EE), it is critical that all exceptions, in particular Orphan VMs, are removed or accounted for.

If your SAM tool is not up to the task then you either put the work in manually or get a tool that can accurately track your virtual hosts.