A new Flexera Community experience is coming on November 25th. Click here for more information.
The Flexera agent doesn't appear to gather socket information from Inventory Devices. Being that IBM PVU calculations for many products (such as Filenet, websphere, etc.) require the sockets to determine if you consume 70 vs 100 vs 120 PVUs/core; how is FNMS able to accurately track consumption? Current behavior is to consume at the lowest level due to there being no socket value.
Nov 19, 2020 03:01 PM
My educated guess at the analysis that is being done here is:
If you manually set the number of sockets on the host to 4, I think that should change the PVU factor used.
The number of processors in the VM is 4 - as this is a virtual number of processors, the count does not have to be directly related to the number of physical processors on the host.
Nov 24, 2020 08:05 PM
I've never found any way to automatically gather the number of sockets on a physical machine. Do you know if that is actually possible? (The FlexNet agent obviously can't gather data that isn't available to be gathered.) Given that operating systems typically don't expose a socket count that is able to be gathered, FlexNet Manager Suite is able to use the number of processors as a proxy for the number of sockets where a socket count is required. This potentially under-counts PVUs in the situation where a computer has a fewer number of processors than there are sockets - although that would only be the case if the computer model information on its own is not sufficient to determine the PVU factor.
If you do have a source of data that can identify the number of sockets on individual devices, then this data can be recorded as an overridden value on the Sockets property on appropriate inventory device records:
This could be updated for a small number of devices directly in the UI, or using an automated import for a larger number of devices with a structured data source.
I haven't come across many situations where the difference between the number of processors and sockets (i.e. the number of unfilled/unused sockets) on servers is a concerning gap for organizations, but it would be interesting to hear if you do have a material % of sockets on your servers running PVU-licensed software that are unused (and therefore unrepresented in processor counts), and where the model information for servers in inventory is not sufficient to accurately determine the PVU factor to use.
Nov 19, 2020 06:16 PM - edited Nov 19, 2020 09:08 PM
Hello Chris, thanks for the quick reply.
As I was gathering data to see why this is happening (I have a 4 processor machine consuming at the 2 socket rate) I realized why. The host for this VM is showing to have only 2 processors in Flexera. Since the PVUs are consumed at a host level and capped its calculating at the 2 processor vs 4 processer level.
The processor type is an Intel Xeon E5, I will attach the PVU consumption rules.
I suppose this begs two questions:
1. In the case of a discrepancy like this, are the PVUs calculated based on the hosts sockets?
2. How would the host device have less processors than the VM on the host? Perhaps vCPUs being assigned to this VM, its still well within the Core maximum (40 cores on the host) but saying its within 4 CPUs when there are only 2 on the Host.
Nov 20, 2020 09:17 AM
My educated guess at the analysis that is being done here is:
If you manually set the number of sockets on the host to 4, I think that should change the PVU factor used.
The number of processors in the VM is 4 - as this is a virtual number of processors, the count does not have to be directly related to the number of physical processors on the host.
Nov 24, 2020 08:05 PM
I agree that is what I believe is also happening. I am in discussions with the application owner however I believe that the PVU/Core calculations are based on the sockets on the host and not the VM. So this would mean that Flexera is calculating correctly (unless somehow there are empty sockets on the host).
I will keep you updated to what I find out.
See below:
Dec 01, 2020 02:57 PM