I would like to share a little issue I am having when trying to have FNMS license an Oracle Cluster from multiple licenses. I would like to hear if anyone else is seeing similar behaviour.
The background: Multiple Oracle instances are running on mutliple VMs on multiple ESX-Hosts in one Cluster. There are multiple licenses for Oracle databases and this distinction is needed for organizational reasons. Also there are potential (minor) differences in the use rights.
What FNMS does: FNMS licenses the whole cluster via one license, "overusing" it and completely ignoring the second license.
My understanding: This might be related to the idea that on VMware, Oracle Database and attached features need to be licensed not only for the host, but the Cluster (and from ESX 6 on the whole vCenter). So it sounds like FNMS just applies that rule, but is not able to stop when one license is full and to continue on the next one, based on license priority.
The general behaviour has been confirmed by engineering, the root cause was not. Currently, the only workaround seems to be to manually allocate the hosts to both licenses and force some to consume from one and some from the other license, while have exemptions to avoid double consumption.
May 23, 2019 04:56 AM - edited May 23, 2019 04:59 AM
May 23, 2019 09:48 AM
Combining the entitltements into one license was my first reflex. Reason for the split is that the customer has part of their entitlements directly from Oracle and part from their parent company.
Regarding "control how many of each license were consumed by the cluster", if FNMS could do the split, it would just consider the license priority. I would do the same, fill up the license with the highest prio, then use the next one.
I guess this is a bit more complicated than the average device license, but wouldn't it be great if this worked ootb?
May 23, 2019 10:10 AM
May 23, 2019 10:24 AM
The downside of rationalising the processor entitlements into a single license is that you will lose the benefit of FNMS Contract management and the license relationships to that contract record.
If you use the Contract Module and create the relationships with the license records it enables an easy way to look for those cost optimisation opportunities at renewal/anniversary time.
Rationalizing the entitlement to force desired behavior loses that and creates additional manual effort which nobody wants.
If you have multiple license records linked to an application and there are no restrictions/scoping in place...then FNMS should recognise where spare entitlement is to draw upon and use.
Jun 18, 2019 03:05 AM
Hi @JensWalton ,
I don't think this is quite true - you can relate the distinct purchases to distinct contracts, without limiting the license itself to a single contract. You can also link a license to multiple contracts. Using the relationship contract -> purchase -> license, I think you can maintain the cost optimization visibility while at the same time allowing FNMS to take advantage of all your entitlements.
Jun 18, 2019 11:53 PM
The following line in the background writeup here is potentially significant: "Also there are potential (minor) differences in the use rights."
If there really are different use rights, then I imagine Oracle would not look too favorably on the deployment of Oracle Database on VMware as described here. When you start to think about needing to license all processors in the cluster, trying to say that some processors are going to be licensed according to one set of use rights and other processors are going to be licensed according to a different set of use rights quickly gets to be a nonsensical discussion.
So while I don't know Oracle's license terms and conditions deeply enough to speak with authority here, I would tread cautiously. You may find you really need to have the whole cluster licensed under a single set of terms and conditions, in which case a single license record in FlexNet is appropriate. Remember that first and foremost you use license records in FlexNet to model the entitlements granted by the vendor to the organization on a holistic basis; as soon as you start to try to split license records to model internal organizational considerations which are different from the vendor's view you will start to run into quirks like you describe here.
Jun 21, 2019 02:27 AM
I understand and agree, however, I think Flexera can make this simpler without the need for customers to create possibly onerous manual relationships which of course will need to be documented outside of the tool (attached as a note document to the contract or license record).
Where distinct relationships exist between a contract and a PO, and if multiple PO's make up a single license record to consolidate the entitlement (as suggested) once that license is assigned to a contract or multiple contracts, there is no breakdown to suggest that licenses linked to a contract may be sharing entitlements from another contract.
Detailed knowledge and history of any such association and relationship must be maintained. Which if not well documented and shared could lead to future reporting problems and inaccuracies.
Jun 25, 2019 01:56 AM - edited Jun 25, 2019 02:44 AM
Hi @JensWalton ,
I was able to make a report that shows what I think you want:
The way FNMS does the join, the first "Contracts" will be all contracts, but the second one will be an inner join with its predecessor item, Purchases.
While it's not possible to further filter this report in the FNMS UI to the exception items where the license contract doesn't match the purchase contract, the report has the data you need and could be further refined in Excel or, if you are on prem, via a SQL report.
Jun 30, 2019 03:35 PM