BYOL Licensing Considerations

IT Asset Management (Cloud)
The Azure connector does not return full inventory from instances running in Azure, and so does not create inventory device records. There are two special cases to distinguish:
  1. If the import from the Azure connector is matched with another record of full software and hardware inventory, the matching process creates an inventory device record. Full software and hardware inventory may be returned from an Microsoft Azure instance when either:
    • FlexNet Inventory Agent is locally installed on the instance, usually because it is part of the Azure VM Image from which the instance was launched
    • You configure zero footprint inventory collection from an inventory beacon that has network access to your target instances, and credentials saved in its Password Manager store
    • You have some third-party tool, such as Microsoft Endpoint Configuration Manager (previously Microsoft SCCM), collecting inventory from your Azure instances, and these results are then being imported into IT Asset Management.
    As always for all inventory devices, the installations found in software inventory for that device consume entitlements from the licenses to which each software record is linked.
  2. A record may be created and displayed in the Cloud Service Provider Inventory page to show the cloud license model (BYOL or PAYG) discovered for instances that may benefit from the Azure Hybrid Benefit (AHB). AHB allows you to benefit from licenses originally purchased to cover on-premises installations of either Microsoft Windows Server, or Microsoft SQL Server, in either of two ways (subject to active Software Assurance): re-purposing them to cover cloud instances instead; or in the special case of Windows Server Datacenter edition, using them to simultaneously authorize both on-premises and cloud instances in Azure. However, in order to determine what software should be licensed (with or without AHB), and measure license consumption, you still need to arrange for inventory collection covering these instances, for example through:
    • The FlexNet Inventory Agent locally installed on the instance
    • Remote inventory collection by an inventory beacon with network access and appropriate credentials for the instance (called zero footprint inventory collection in the Gathering FlexNet Inventory reference)
    • A third-party inventory tool.

In those cases where inventory is received that matches your Microsoft Azure instance records, there are a few special consideration.

Beware of terminating instances

For some special purposes, instances in the Microsoft Azure cloud may be launched, run for a short period (from a few minutes to a few hours), and then shut down until needed again.

It is quite possible to configure the Azure VM Image from which instances are launched so that inventory is collected and uploaded through one or more inventory beacons to your IT Asset Management application server (for details, see Configuring an Azure VM Image for Instances).

However, the licensing implications are quite different when you stop an instance than when you terminate an instance:
  • The assumption is that a stopped instance may be restarted when required, and resume operation with (quite likely) the same software installed. It is therefore reasonable to calculate license consumption for such an instance, and, if you use the configuration described in Configuring an Azure VM Image for Instances, this happens as usual for virtual machines (whether those are VMs within your enterprise network or instances in the cloud).
  • A terminated instance cannot be restarted, and if you are choosing BYOL for instances that you terminate, you should check your license terms carefully and make appropriate provision. The working assumption in IT Asset Management is that a terminated instance should no longer consume from your software licenses, just as license consumption stops when you uninstall software from a device, or decommission a hardware asset. As described in Collecting Inventory from Instances, this is achieved by permanently deleting any inventory device record that may have previously been created for the instance that is now terminated. All resources attached to the terminated instance will remain and you can then manually delete these resources as desired. (See the same topic for a way of re-discovering the software load for a terminated instance, and hence its potential license implications.)

The complexity of managing licenses on transient instances is why it is more common to purchase these based on a fully-loaded image provided by (and licensed through) Microsoft Azure. However, if you need repeated runs of an instance for special purposes, and such an instance must include software for which you provide the license (BYOL), consider running such an instance as a stop/start instance, rather than terminating it and re-launching it, to simplify your license management.

Thirty-minute inventory and IBM PVU licenses

The default schedule for the Azure connector is to have it run every 30 minutes. Coincidentally, this happens to be the same interval that IBM requires for hardware checks of devices linked to IBM PVU licenses (when you have IBM's approval to use IT Asset Management as the source for sub-capacity licensing calculations, for which see the Sub-Capacity Licensing with IBM PVU topic in IT Asset Management System Reference).

However, each of these coincidental but distinct schedules has its own separate reasons:
  • The Azure connector should run every 30 minute to allow it to capture transient information that Azure keeps available for only an hour, so that you can track your terminated instances where required. This is the connector schedule, and the connector does not return sufficient inventory detail to satisfy the IBM requirements.
  • The hardware check for IBM PVU licenses must run every 30 minutes as part of your amended contractual agreement with IBM. This is an inventory schedule that controls operations of FlexNet Inventory Agent embedded on an operational instance.
If you are providing IBM PVU licenses for use in the Microsoft Azure cloud, and have the IBM amended agreement to allow sub-capacity calculations within IT Asset Management, these two default schedules conveniently satisfy both requirements within Azure. However, be aware of the following requirements:
  • IBM PVU licenses in the BYOL model are not appropriate for short-lived instances that are then terminated (see previous section about the pitfalls of terminating instances with BYOL). Start/stop operations can be used when necessary, as long as the instance is maintained and not terminated.
  • Persistent (unchanging) inventory device names and matching instance IDs are critical to this license model, allowing proper calculations of peak consumption values over time. For details about setting a unique but persistent device name for inventory, see Collecting Inventory from Instances.
  • As always, full hardware and software inventory (from the instance) is required for IBM PVU licensing. Compliance with your IBM license requires regular software inventory (daily is recommended best practice) as well as the 30-minute hardware check. Use of the FlexNet Inventory Agent is also mandated by your adjusted license agreement. The techniques in Collecting Inventory from Instances prepare an Azure VM Image from which you can launch instances with the operational FlexNet Inventory Agent embedded, satisfying those requirements.
  • As always, the first full software and hardware inventory must be uploaded and processed on the central application server before the 30-minute hardware checks take effect. (This allows the calculation of updated rule targets that identify all devices affected by IBM PVU licensing processes.) Typically the relevant compliance calculations take place overnight, after which the revised device policy must be distributed through the inventory beacon hierarchy to affected installations of FlexNet Inventory Agent, bringing with it the special schedule for the hardware check. All of this process means that in the normal course of events, IBM PVU operations typically are running effectively from the day after an instance is launched with PVU-licensed software in operation.

Uncapped calculations except on dedicated hosts

Some license types allow that, where the total license liabilities for many VMs on the same host theoretically exceed factors like the total number of cores available on the host, the summing process is 'capped' or given an upper limit by the actual capacity of the host. For example, if five VMs on a host are each allocated 2 cores, for a total of 10 allocated cores when the host actually only has 8 cores available, then, just as in reality the time-sharing between the VMs limits the cores in use at any moment, so also the license rules cap (or reduce) the calculated figure (10 cores) to the total capacity of the host (8 cores).

Obviously, capping of consumption calculations requires inventory not only of all the VMs on a host, but also of the host itself. However, in the case of Microsoft Azure instances, inventory details are not available for any host types other than 'dedicated hosts', over which you have full control. This means that on all other, non-dedicated hosts in Azure, capping of license calculations cannot occur.

All calculations for BYOL licensing of instances on non-dedicated Azure hosts are based entirely on the inventory taken from the instances themselves, without capping. This does not expose you to any risk of under-licensing (provided that all instances are returning inventory); the only risk is that you may perhaps be over-calculating the consumption that might apply on a known host with capping applied.

However, this may not be an issue at all. Carefully check your BYOL terms and use rights. You may find that software publishers already disallow capping in cloud environments, because of the impossibility of tracking instances that may pop up now on this host and now on another, depending on resource allocations within Azure.

IT Asset Management (Cloud)

Current