BYOSL Licensing Considerations

FlexNet Manager Suite 2020 R1 (On-Premises)
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 have some third-party tool (such as Microsoft SCCM) collecting inventory from your Azure instances, and these results are then being imported into FlexNet Manager Suite.
Whatever the method, when inventory is returned from a running Microsoft Azure instance, it has an inventory device record in FlexNet Manager Suite. 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.

However, there are a few special adjustments for inventory from Microsoft Azure instances.

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 FlexNet Manager Suite 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 BYOSL for instances that you terminate, you should check your license terms carefully and make appropriate provision. The working assumption in FlexNet Manager Suite 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 (BYOSL), 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 FlexNet Manager Suite as the source for sub-capacity licensing calculations, for which see the Sub-Capacity Licensing with IBM PVU chapter of the FlexNet Manager Suite System Reference PDF, available through the title page of online help).

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 FlexNet Manager Suite, these two default schedules conveniently satisfy both requirements within Azure. However, be aware of the following requirements:
  • IBM PVU licenses in the BYOSL model are not appropriate for short-lived instances that are then terminated (see previous section about the pitfalls of terminating instances with BOYSL). 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 BOYSL 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 BYOSL 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.

FlexNet Manager Suite (On-Premises)

2020 R1