IBM License Metric Tool (ILMT)

Hello,

For a new ILMT deployment using BigFix the PVU metrics were working following the installation last year. Mid -December 2023 the PVU metrics were incorrectly reported for a few weeks due to an issue with database connectivity. After resolving the database issue and confirming the reporting was working as expected it was noticed that the PVU count per core had changed from 70 PVU to 120 PVU. This seems to have coincided with the update of ILMT to version 9.2.34.

The physical system hosting the VM with the (now) incorrect PVU count is model HPE ProLiant D380 Gen10 with an Intel (R) Xeon(R) Gold 6248R CPU which has 2 sockets per processor. According to the website IBM Processor Value Unit [PVU] licensing for Distributed Software and Processor value unit calculator this should be 7- PVU. The specific model isn't listed but it is classed as an Intel Xeon socket 1 or 2  at 70 PVU.

Do you know if this is an issue introduced with the 9.2.34 upgrade?

Thanks in advance for your help.

regards, 

Hello Pete,

You haven't provided the ILMT version which was used before an upgrade...

Anyhow, the blind guess is that scanner component has provided a different capacity scan results than in previous version.
Perhaps somehow that CPU was discovered with some more sockets per processor (>4 : 120 PVUs).

It would be difficult to unequivocally confirm what the issue is without looking into capacity scan result (tlm_hw_xxx.xml).
Either please upload the capacity scan result file or open a support ticket to us...

Hello,

For a new ILMT deployment using BigFix the PVU metrics were working following the installation last year. Mid -December 2023 the PVU metrics were incorrectly reported for a few weeks due to an issue with database connectivity. After resolving the database issue and confirming the reporting was working as expected it was noticed that the PVU count per core had changed from 70 PVU to 120 PVU. This seems to have coincided with the update of ILMT to version 9.2.34.

The physical system hosting the VM with the (now) incorrect PVU count is model HPE ProLiant D380 Gen10 with an Intel (R) Xeon(R) Gold 6248R CPU which has 2 sockets per processor. According to the website IBM Processor Value Unit [PVU] licensing for Distributed Software and Processor value unit calculator this should be 7- PVU. The specific model isn't listed but it is classed as an Intel Xeon socket 1 or 2  at 70 PVU.

Do you know if this is an issue introduced with the 9.2.34 upgrade?

Thanks in advance for your help.

regards, 

Hello Oktawian,

My apologies - the previous ILMT version was 9.2.33.

I will check the tlm_hw_xxx.html file from the latest scan and provide an update.

regards, 

Hello Pete,

You haven't provided the ILMT version which was used before an upgrade...

Anyhow, the blind guess is that scanner component has provided a different capacity scan results than in previous version.
Perhaps somehow that CPU was discovered with some more sockets per processor (>4 : 120 PVUs).

It would be difficult to unequivocally confirm what the issue is without looking into capacity scan result (tlm_hw_xxx.xml).
Either please upload the capacity scan result file or open a support ticket to us...

Hello,

For a new ILMT deployment using BigFix the PVU metrics were working following the installation last year. Mid -December 2023 the PVU metrics were incorrectly reported for a few weeks due to an issue with database connectivity. After resolving the database issue and confirming the reporting was working as expected it was noticed that the PVU count per core had changed from 70 PVU to 120 PVU. This seems to have coincided with the update of ILMT to version 9.2.34.

The physical system hosting the VM with the (now) incorrect PVU count is model HPE ProLiant D380 Gen10 with an Intel (R) Xeon(R) Gold 6248R CPU which has 2 sockets per processor. According to the website IBM Processor Value Unit [PVU] licensing for Distributed Software and Processor value unit calculator this should be 7- PVU. The specific model isn't listed but it is classed as an Intel Xeon socket 1 or 2  at 70 PVU.

Do you know if this is an issue introduced with the 9.2.34 upgrade?

Thanks in advance for your help.

regards, 

Hello Oktawian,

After checking the content of the tlm_hw_xxx.xml files for the 2 systems in question and, running a "diff" of the files from November 2023 and the most recent February 2024 copies of the files, there is no difference between the file contents.

Returning again to the ILMT console the systems in question are showing as "No VM Manager Data" so I have stepped through the troubleshooting documented here https://www.ibm.com/docs/en/license-metric-tool?topic=scshw-troubleshooting-outdated-vm-manager-data-no-vm-manager-data-statuses and cannot determine the reason why this status is shown. There are no obvious errors in the logs or configuration files etc. checked during the troubleshooting steps.

Could this be a factor in why the PVU is being reported incorrectly?

Maybe it is time for the customer to open a support ticket

regards,

Hello Oktawian,

My apologies - the previous ILMT version was 9.2.33.

I will check the tlm_hw_xxx.html file from the latest scan and provide an update.

regards, 

Hello Pete,

You haven't provided the ILMT version which was used before an upgrade...

Anyhow, the blind guess is that scanner component has provided a different capacity scan results than in previous version.
Perhaps somehow that CPU was discovered with some more sockets per processor (>4 : 120 PVUs).

It would be difficult to unequivocally confirm what the issue is without looking into capacity scan result (tlm_hw_xxx.xml).
Either please upload the capacity scan result file or open a support ticket to us...

Hello,

For a new ILMT deployment using BigFix the PVU metrics were working following the installation last year. Mid -December 2023 the PVU metrics were incorrectly reported for a few weeks due to an issue with database connectivity. After resolving the database issue and confirming the reporting was working as expected it was noticed that the PVU count per core had changed from 70 PVU to 120 PVU. This seems to have coincided with the update of ILMT to version 9.2.34.

The physical system hosting the VM with the (now) incorrect PVU count is model HPE ProLiant D380 Gen10 with an Intel (R) Xeon(R) Gold 6248R CPU which has 2 sockets per processor. According to the website IBM Processor Value Unit [PVU] licensing for Distributed Software and Processor value unit calculator this should be 7- PVU. The specific model isn't listed but it is classed as an Intel Xeon socket 1 or 2  at 70 PVU.

Do you know if this is an issue introduced with the 9.2.34 upgrade?

Thanks in advance for your help.

regards, 

Hello Pete,

Ok, if this is a VM with "No VM Manager Data" status that 120 PVU makes a perfect sense.
I was misguided by your initial post:
The physical system hosting the VM with the (now) incorrect PVU count....

To go further, you need to collect two things:

1. debugData.zip file generated by 'vmman.<sh/bat> -retrievedebugdata' command,
2. Hardware Inventory report showing that VM entry with 'TLM_VM_' prefix (to get the UUID value)
   

Next, check whether the UUID that you obtained in step 2 exists in one of the vmman_scan_xxx.xml files from debugData.zip package.

Again, we are happy to help you out through a support ticket...

Hello Oktawian,

After checking the content of the tlm_hw_xxx.xml files for the 2 systems in question and, running a "diff" of the files from November 2023 and the most recent February 2024 copies of the files, there is no difference between the file contents.

Returning again to the ILMT console the systems in question are showing as "No VM Manager Data" so I have stepped through the troubleshooting documented here https://www.ibm.com/docs/en/license-metric-tool?topic=scshw-troubleshooting-outdated-vm-manager-data-no-vm-manager-data-statuses and cannot determine the reason why this status is shown. There are no obvious errors in the logs or configuration files etc. checked during the troubleshooting steps.

Could this be a factor in why the PVU is being reported incorrectly?

Maybe it is time for the customer to open a support ticket

regards,

Hello Oktawian,

My apologies - the previous ILMT version was 9.2.33.

I will check the tlm_hw_xxx.html file from the latest scan and provide an update.

regards, 

Hello Pete,

You haven't provided the ILMT version which was used before an upgrade...

Anyhow, the blind guess is that scanner component has provided a different capacity scan results than in previous version.
Perhaps somehow that CPU was discovered with some more sockets per processor (>4 : 120 PVUs).

It would be difficult to unequivocally confirm what the issue is without looking into capacity scan result (tlm_hw_xxx.xml).
Either please upload the capacity scan result file or open a support ticket to us...

Hello,

For a new ILMT deployment using BigFix the PVU metrics were working following the installation last year. Mid -December 2023 the PVU metrics were incorrectly reported for a few weeks due to an issue with database connectivity. After resolving the database issue and confirming the reporting was working as expected it was noticed that the PVU count per core had changed from 70 PVU to 120 PVU. This seems to have coincided with the update of ILMT to version 9.2.34.

The physical system hosting the VM with the (now) incorrect PVU count is model HPE ProLiant D380 Gen10 with an Intel (R) Xeon(R) Gold 6248R CPU which has 2 sockets per processor. According to the website IBM Processor Value Unit [PVU] licensing for Distributed Software and Processor value unit calculator this should be 7- PVU. The specific model isn't listed but it is classed as an Intel Xeon socket 1 or 2  at 70 PVU.

Do you know if this is an issue introduced with the 9.2.34 upgrade?

Thanks in advance for your help.

regards, 

Hello Oktawian,

Thanks for the update. I have checked the tlm_vm_xxx files for the UUID values of the 2 systems in question and checked them against the (only) vmman_svcan_xx.xml file from the debug zip file data and cannot see any reference to UUID in the file.

Is there something else that  need to check to try to track down the issue?

regards, Pete

Hello Pete,

Ok, if this is a VM with "No VM Manager Data" status that 120 PVU makes a perfect sense.
I was misguided by your initial post:
The physical system hosting the VM with the (now) incorrect PVU count....

To go further, you need to collect two things:

1. debugData.zip file generated by 'vmman.<sh/bat> -retrievedebugdata' command,
2. Hardware Inventory report showing that VM entry with 'TLM_VM_' prefix (to get the UUID value)
   

Next, check whether the UUID that you obtained in step 2 exists in one of the vmman_scan_xxx.xml files from debugData.zip package.

Again, we are happy to help you out through a support ticket...

Hello Oktawian,

After checking the content of the tlm_hw_xxx.xml files for the 2 systems in question and, running a "diff" of the files from November 2023 and the most recent February 2024 copies of the files, there is no difference between the file contents.

Returning again to the ILMT console the systems in question are showing as "No VM Manager Data" so I have stepped through the troubleshooting documented here https://www.ibm.com/docs/en/license-metric-tool?topic=scshw-troubleshooting-outdated-vm-manager-data-no-vm-manager-data-statuses and cannot determine the reason why this status is shown. There are no obvious errors in the logs or configuration files etc. checked during the troubleshooting steps.

Could this be a factor in why the PVU is being reported incorrectly?

Maybe it is time for the customer to open a support ticket

regards,

Hello Oktawian,

My apologies - the previous ILMT version was 9.2.33.

I will check the tlm_hw_xxx.html file from the latest scan and provide an update.

regards, 

Hello Pete,

You haven't provided the ILMT version which was used before an upgrade...

Anyhow, the blind guess is that scanner component has provided a different capacity scan results than in previous version.
Perhaps somehow that CPU was discovered with some more sockets per processor (>4 : 120 PVUs).

It would be difficult to unequivocally confirm what the issue is without looking into capacity scan result (tlm_hw_xxx.xml).
Either please upload the capacity scan result file or open a support ticket to us...

Hello,

For a new ILMT deployment using BigFix the PVU metrics were working following the installation last year. Mid -December 2023 the PVU metrics were incorrectly reported for a few weeks due to an issue with database connectivity. After resolving the database issue and confirming the reporting was working as expected it was noticed that the PVU count per core had changed from 70 PVU to 120 PVU. This seems to have coincided with the update of ILMT to version 9.2.34.

The physical system hosting the VM with the (now) incorrect PVU count is model HPE ProLiant D380 Gen10 with an Intel (R) Xeon(R) Gold 6248R CPU which has 2 sockets per processor. According to the website IBM Processor Value Unit [PVU] licensing for Distributed Software and Processor value unit calculator this should be 7- PVU. The specific model isn't listed but it is classed as an Intel Xeon socket 1 or 2  at 70 PVU.

Do you know if this is an issue introduced with the 9.2.34 upgrade?

Thanks in advance for your help.

regards, 

Hello,

Right...so in such case I can see three possibilities:

1. The user who is connecting with the VM manager does not have required permissions to collect data about the virtual machine,
2. virtual machine is inactive/power off state,
3. UUID format is somehow screwed (what I mean by this is the UUID from capacity data collected by scanner component is processed slightly differently the UUID collected by VM manager...I've done some defect long time ago addressing such issue)

To go further, you need to look into 'debugData\debug' folder,
There is a bunch of .xml files under this folder you need to check out first.
You haven't specified which Hypervisor type you are dealing with so I'm not able to give you any specifics as .xml files is strictly Hypervisor dependent.
(In case of VMware (most popular) this would be retrieveProperties.xml file)
Look for the VM name under each '<obj type="VirtualMachine">vm-xxxx</obj>' entry or use some UUID fragment.
I guess that this is a kind of a guessing game...

If you still don't find anything in 'debug' folder the next step would be to get VM list (with corresponding UUIDs) directly from Hypervisor using the native API....again,  this whole thing is strictly Hypervisor dependent.

------------------------------
Thank you,
Oktawian

Oktawian Powązka, L3 Support
IBM License Metric Tool

Original Message:
Sent: Wed February 07, 2024 11:24 AM
From: Pete Meechan
Subject: Incorrect PVU per core value

Hello Oktawian,

Thanks for the update. I have checked the tlm_vm_xxx files for the UUID values of the 2 systems in question and checked them against the (only) vmman_svcan_xx.xml file from the debug zip file data and cannot see any reference to UUID in the file.

Is there something else that  need to check to try to track down the issue?

regards, Pete

------------------------------
Pete Meechan
Principal Consultant
Orb Data Limited

Original Message:
Sent: Wed February 07, 2024 11:11 AM
From: Oktawian Powązka
Subject: Incorrect PVU per core value

Hello Pete,

Ok, if this is a VM with "No VM Manager Data" status that 120 PVU makes a perfect sense.
I was misguided by your initial post:
The physical system hosting the VM with the (now) incorrect PVU count....

To go further, you need to collect two things:

1. debugData.zip file generated by 'vmman.<sh/bat> -retrievedebugdata' command,
2. Hardware Inventory report showing that VM entry with 'TLM_VM_' prefix (to get the UUID value)
   

Next, check whether the UUID that you obtained in step 2 exists in one of the vmman_scan_xxx.xml files from debugData.zip package.

Again, we are happy to help you out through a support ticket...

------------------------------
Thank you,
Oktawian

Oktawian Powązka, L3 Support
IBM License Metric Tool

Original Message:
Sent: Wed February 07, 2024 04:44 AM
From: Pete Meechan
Subject: Incorrect PVU per core value

Hello Oktawian,

After checking the content of the tlm_hw_xxx.xml files for the 2 systems in question and, running a "diff" of the files from November 2023 and the most recent February 2024 copies of the files, there is no difference between the file contents.

Returning again to the ILMT console the systems in question are showing as "No VM Manager Data" so I have stepped through the troubleshooting documented here https://www.ibm.com/docs/en/license-metric-tool?topic=scshw-troubleshooting-outdated-vm-manager-data-no-vm-manager-data-statuses and cannot determine the reason why this status is shown. There are no obvious errors in the logs or configuration files etc. checked during the troubleshooting steps.

Could this be a factor in why the PVU is being reported incorrectly?

Maybe it is time for the customer to open a support ticket

regards,

------------------------------
Pete Meechan
Principal Consultant
Orb Data Limited

Original Message:
Sent: Tue February 06, 2024 03:20 AM
From: Pete Meechan
Subject: Incorrect PVU per core value

Hello Oktawian,

My apologies - the previous ILMT version was 9.2.33.

I will check the tlm_hw_xxx.html file from the latest scan and provide an update.

regards, 

------------------------------
Pete Meechan
Principal Consultant
Orb Data Limited

Original Message:
Sent: Tue February 06, 2024 03:05 AM
From: Oktawian Powązka
Subject: Incorrect PVU per core value

Hello Pete,

You haven't provided the ILMT version which was used before an upgrade...

Anyhow, the blind guess is that scanner component has provided a different capacity scan results than in previous version.
Perhaps somehow that CPU was discovered with some more sockets per processor (>4 : 120 PVUs).

It would be difficult to unequivocally confirm what the issue is without looking into capacity scan result (tlm_hw_xxx.xml).
Either please upload the capacity scan result file or open a support ticket to us...

------------------------------
Thank you,
Oktawian

Oktawian Powązka, L3 Support
IBM License Metric Tool

Original Message:
Sent: Mon February 05, 2024 01:57 PM
From: Pete Meechan
Subject: Incorrect PVU per core value

Hello,

For a new ILMT deployment using BigFix the PVU metrics were working following the installation last year. Mid -December 2023 the PVU metrics were incorrectly reported for a few weeks due to an issue with database connectivity. After resolving the database issue and confirming the reporting was working as expected it was noticed that the PVU count per core had changed from 70 PVU to 120 PVU. This seems to have coincided with the update of ILMT to version 9.2.34.

The physical system hosting the VM with the (now) incorrect PVU count is model HPE ProLiant D380 Gen10 with an Intel (R) Xeon(R) Gold 6248R CPU which has 2 sockets per processor. According to the website IBM Processor Value Unit [PVU] licensing for Distributed Software and Processor value unit calculator this should be 7- PVU. The specific model isn't listed but it is classed as an Intel Xeon socket 1 or 2  at 70 PVU.

Do you know if this is an issue introduced with the 9.2.34 upgrade?

Thanks in advance for your help.

regards, 

------------------------------
Pete Meechan
Principal Consultant
Orb Data Limited
------------------------------

Hello Oktawian,

Thanks for your help with this. The hypervisor is VMWare.

Option 1 doesn't look likely as the customer did a test yesterday, reducing the cores on one of the systems and this morning ILMT correctly reported the reduced cores, but still showing a PVU count of 120

Option 2 is doesn't apply as both systems are actively being used

That leaves Option 3  so I checked the retrieveProperties.xml from the debug data for the corresponding UUID values and both of them are present in the file.

Do you have any other suggestions that I can check please?

The customer is using UUID-based virtual machine filtering - I don't know if that could be having an impact. I have checked the UUID configured for filtering match the UUID for the systems in question.

thanks, 

------------------------------
Pete Meechan
Principal Consultant
Orb Data Limited

Original Message:
Sent: Thu February 08, 2024 02:36 AM
From: Oktawian Powązka
Subject: Incorrect PVU per core value

Hello,

Right...so in such case I can see three possibilities:

1. The user who is connecting with the VM manager does not have required permissions to collect data about the virtual machine,
2. virtual machine is inactive/power off state,
3. UUID format is somehow screwed (what I mean by this is the UUID from capacity data collected by scanner component is processed slightly differently the UUID collected by VM manager...I've done some defect long time ago addressing such issue)

To go further, you need to look into 'debugData\debug' folder,
There is a bunch of .xml files under this folder you need to check out first.
You haven't specified which Hypervisor type you are dealing with so I'm not able to give you any specifics as .xml files is strictly Hypervisor dependent.
(In case of VMware (most popular) this would be retrieveProperties.xml file)
Look for the VM name under each '<obj type="VirtualMachine">vm-xxxx</obj>' entry or use some UUID fragment.
I guess that this is a kind of a guessing game...

If you still don't find anything in 'debug' folder the next step would be to get VM list (with corresponding UUIDs) directly from Hypervisor using the native API....again,  this whole thing is strictly Hypervisor dependent.

------------------------------
Thank you,
Oktawian

Oktawian Powązka, L3 Support
IBM License Metric Tool

Original Message:
Sent: Wed February 07, 2024 11:24 AM
From: Pete Meechan
Subject: Incorrect PVU per core value

Hello Oktawian,

Thanks for the update. I have checked the tlm_vm_xxx files for the UUID values of the 2 systems in question and checked them against the (only) vmman_svcan_xx.xml file from the debug zip file data and cannot see any reference to UUID in the file.

Is there something else that  need to check to try to track down the issue?

regards, Pete

------------------------------
Pete Meechan
Principal Consultant
Orb Data Limited

Original Message:
Sent: Wed February 07, 2024 11:11 AM
From: Oktawian Powązka
Subject: Incorrect PVU per core value

Hello Pete,

Ok, if this is a VM with "No VM Manager Data" status that 120 PVU makes a perfect sense.
I was misguided by your initial post:
The physical system hosting the VM with the (now) incorrect PVU count....

To go further, you need to collect two things:

1. debugData.zip file generated by 'vmman.<sh/bat> -retrievedebugdata' command,
2. Hardware Inventory report showing that VM entry with 'TLM_VM_' prefix (to get the UUID value)
   

Next, check whether the UUID that you obtained in step 2 exists in one of the vmman_scan_xxx.xml files from debugData.zip package.

Again, we are happy to help you out through a support ticket...

------------------------------
Thank you,
Oktawian

Oktawian Powązka, L3 Support
IBM License Metric Tool

Original Message:
Sent: Wed February 07, 2024 04:44 AM
From: Pete Meechan
Subject: Incorrect PVU per core value

Hello Oktawian,

After checking the content of the tlm_hw_xxx.xml files for the 2 systems in question and, running a "diff" of the files from November 2023 and the most recent February 2024 copies of the files, there is no difference between the file contents.

Returning again to the ILMT console the systems in question are showing as "No VM Manager Data" so I have stepped through the troubleshooting documented here https://www.ibm.com/docs/en/license-metric-tool?topic=scshw-troubleshooting-outdated-vm-manager-data-no-vm-manager-data-statuses and cannot determine the reason why this status is shown. There are no obvious errors in the logs or configuration files etc. checked during the troubleshooting steps.

Could this be a factor in why the PVU is being reported incorrectly?

Maybe it is time for the customer to open a support ticket

regards,

------------------------------
Pete Meechan
Principal Consultant
Orb Data Limited

Original Message:
Sent: Tue February 06, 2024 03:20 AM
From: Pete Meechan
Subject: Incorrect PVU per core value

Hello Oktawian,

My apologies - the previous ILMT version was 9.2.33.

I will check the tlm_hw_xxx.html file from the latest scan and provide an update.

regards, 

------------------------------
Pete Meechan
Principal Consultant
Orb Data Limited

Original Message:
Sent: Tue February 06, 2024 03:05 AM
From: Oktawian Powązka
Subject: Incorrect PVU per core value

Hello Pete,

You haven't provided the ILMT version which was used before an upgrade...

Anyhow, the blind guess is that scanner component has provided a different capacity scan results than in previous version.
Perhaps somehow that CPU was discovered with some more sockets per processor (>4 : 120 PVUs).

It would be difficult to unequivocally confirm what the issue is without looking into capacity scan result (tlm_hw_xxx.xml).
Either please upload the capacity scan result file or open a support ticket to us...

------------------------------
Thank you,
Oktawian

Oktawian Powązka, L3 Support
IBM License Metric Tool

Original Message:
Sent: Mon February 05, 2024 01:57 PM
From: Pete Meechan
Subject: Incorrect PVU per core value

Hello,

For a new ILMT deployment using BigFix the PVU metrics were working following the installation last year. Mid -December 2023 the PVU metrics were incorrectly reported for a few weeks due to an issue with database connectivity. After resolving the database issue and confirming the reporting was working as expected it was noticed that the PVU count per core had changed from 70 PVU to 120 PVU. This seems to have coincided with the update of ILMT to version 9.2.34.

The physical system hosting the VM with the (now) incorrect PVU count is model HPE ProLiant D380 Gen10 with an Intel (R) Xeon(R) Gold 6248R CPU which has 2 sockets per processor. According to the website IBM Processor Value Unit [PVU] licensing for Distributed Software and Processor value unit calculator this should be 7- PVU. The specific model isn't listed but it is classed as an Intel Xeon socket 1 or 2  at 70 PVU.

Do you know if this is an issue introduced with the 9.2.34 upgrade?

Thanks in advance for your help.

regards, 

------------------------------
Pete Meechan
Principal Consultant
Orb Data Limited
------------------------------

Hello Pete,

The customer is using UUID-based virtual machine filtering...
So, 'vmmfilterconf.properties' file contain that UUID in question, correct  ?

Well, I'd have to look into that DebugData.zip file...
Either pls. send me this by mail or open a support ticket to us...

Hello Oktawian,

Thanks for your help with this. The hypervisor is VMWare.

Option 1 doesn't look likely as the customer did a test yesterday, reducing the cores on one of the systems and this morning ILMT correctly reported the reduced cores, but still showing a PVU count of 120

Option 2 is doesn't apply as both systems are actively being used

That leaves Option 3  so I checked the retrieveProperties.xml from the debug data for the corresponding UUID values and both of them are present in the file.

Do you have any other suggestions that I can check please?

The customer is using UUID-based virtual machine filtering - I don't know if that could be having an impact. I have checked the UUID configured for filtering match the UUID for the systems in question.

thanks, 

------------------------------
Pete Meechan
Principal Consultant
Orb Data Limited

Original Message:
Sent: Thu February 08, 2024 02:36 AM
From: Oktawian Powązka
Subject: Incorrect PVU per core value

Hello,

Right...so in such case I can see three possibilities:

1. The user who is connecting with the VM manager does not have required permissions to collect data about the virtual machine,
2. virtual machine is inactive/power off state,
3. UUID format is somehow screwed (what I mean by this is the UUID from capacity data collected by scanner component is processed slightly differently the UUID collected by VM manager...I've done some defect long time ago addressing such issue)

To go further, you need to look into 'debugData\debug' folder,
There is a bunch of .xml files under this folder you need to check out first.
You haven't specified which Hypervisor type you are dealing with so I'm not able to give you any specifics as .xml files is strictly Hypervisor dependent.
(In case of VMware (most popular) this would be retrieveProperties.xml file)
Look for the VM name under each '<obj type="VirtualMachine">vm-xxxx</obj>' entry or use some UUID fragment.
I guess that this is a kind of a guessing game...

If you still don't find anything in 'debug' folder the next step would be to get VM list (with corresponding UUIDs) directly from Hypervisor using the native API....again,  this whole thing is strictly Hypervisor dependent.

------------------------------
Thank you,
Oktawian

Oktawian Powązka, L3 Support
IBM License Metric Tool

Original Message:
Sent: Wed February 07, 2024 11:24 AM
From: Pete Meechan
Subject: Incorrect PVU per core value

Hello Oktawian,

Thanks for the update. I have checked the tlm_vm_xxx files for the UUID values of the 2 systems in question and checked them against the (only) vmman_svcan_xx.xml file from the debug zip file data and cannot see any reference to UUID in the file.

Is there something else that  need to check to try to track down the issue?

regards, Pete

------------------------------
Pete Meechan
Principal Consultant
Orb Data Limited

Original Message:
Sent: Wed February 07, 2024 11:11 AM
From: Oktawian Powązka
Subject: Incorrect PVU per core value

Hello Pete,

Ok, if this is a VM with "No VM Manager Data" status that 120 PVU makes a perfect sense.
I was misguided by your initial post:
The physical system hosting the VM with the (now) incorrect PVU count....

To go further, you need to collect two things:

1. debugData.zip file generated by 'vmman.<sh/bat> -retrievedebugdata' command,
2. Hardware Inventory report showing that VM entry with 'TLM_VM_' prefix (to get the UUID value)
   

Next, check whether the UUID that you obtained in step 2 exists in one of the vmman_scan_xxx.xml files from debugData.zip package.

Again, we are happy to help you out through a support ticket...

------------------------------
Thank you,
Oktawian

Oktawian Powązka, L3 Support
IBM License Metric Tool

Original Message:
Sent: Wed February 07, 2024 04:44 AM
From: Pete Meechan
Subject: Incorrect PVU per core value

Hello Oktawian,

After checking the content of the tlm_hw_xxx.xml files for the 2 systems in question and, running a "diff" of the files from November 2023 and the most recent February 2024 copies of the files, there is no difference between the file contents.

Returning again to the ILMT console the systems in question are showing as "No VM Manager Data" so I have stepped through the troubleshooting documented here https://www.ibm.com/docs/en/license-metric-tool?topic=scshw-troubleshooting-outdated-vm-manager-data-no-vm-manager-data-statuses and cannot determine the reason why this status is shown. There are no obvious errors in the logs or configuration files etc. checked during the troubleshooting steps.

Could this be a factor in why the PVU is being reported incorrectly?

Maybe it is time for the customer to open a support ticket

regards,

------------------------------
Pete Meechan
Principal Consultant
Orb Data Limited

Original Message:
Sent: Tue February 06, 2024 03:20 AM
From: Pete Meechan
Subject: Incorrect PVU per core value

Hello Oktawian,

My apologies - the previous ILMT version was 9.2.33.

I will check the tlm_hw_xxx.html file from the latest scan and provide an update.

regards, 

------------------------------
Pete Meechan
Principal Consultant
Orb Data Limited

Original Message:
Sent: Tue February 06, 2024 03:05 AM
From: Oktawian Powązka
Subject: Incorrect PVU per core value

Hello Pete,

You haven't provided the ILMT version which was used before an upgrade...

Anyhow, the blind guess is that scanner component has provided a different capacity scan results than in previous version.
Perhaps somehow that CPU was discovered with some more sockets per processor (>4 : 120 PVUs).

It would be difficult to unequivocally confirm what the issue is without looking into capacity scan result (tlm_hw_xxx.xml).
Either please upload the capacity scan result file or open a support ticket to us...

------------------------------
Thank you,
Oktawian

Oktawian Powązka, L3 Support
IBM License Metric Tool

Original Message:
Sent: Mon February 05, 2024 01:57 PM
From: Pete Meechan
Subject: Incorrect PVU per core value

Hello,

For a new ILMT deployment using BigFix the PVU metrics were working following the installation last year. Mid -December 2023 the PVU metrics were incorrectly reported for a few weeks due to an issue with database connectivity. After resolving the database issue and confirming the reporting was working as expected it was noticed that the PVU count per core had changed from 70 PVU to 120 PVU. This seems to have coincided with the update of ILMT to version 9.2.34.

The physical system hosting the VM with the (now) incorrect PVU count is model HPE ProLiant D380 Gen10 with an Intel (R) Xeon(R) Gold 6248R CPU which has 2 sockets per processor. According to the website IBM Processor Value Unit [PVU] licensing for Distributed Software and Processor value unit calculator this should be 7- PVU. The specific model isn't listed but it is classed as an Intel Xeon socket 1 or 2  at 70 PVU.

Do you know if this is an issue introduced with the 9.2.34 upgrade?

Thanks in advance for your help.

regards, 

------------------------------
Pete Meechan
Principal Consultant
Orb Data Limited
------------------------------

Hello Oktawian,

The customer has given me the okay to email a copy of the debugData.zip file. What email address should I use?

regards, Pete

Hello Pete,

The customer is using UUID-based virtual machine filtering...
So, 'vmmfilterconf.properties' file contain that UUID in question, correct  ?

Well, I'd have to look into that DebugData.zip file...
Either pls. send me this by mail or open a support ticket to us...

Hello Oktawian,

Thanks for your help with this. The hypervisor is VMWare.

Option 1 doesn't look likely as the customer did a test yesterday, reducing the cores on one of the systems and this morning ILMT correctly reported the reduced cores, but still showing a PVU count of 120

Option 2 is doesn't apply as both systems are actively being used

That leaves Option 3  so I checked the retrieveProperties.xml from the debug data for the corresponding UUID values and both of them are present in the file.

Do you have any other suggestions that I can check please?

The customer is using UUID-based virtual machine filtering - I don't know if that could be having an impact. I have checked the UUID configured for filtering match the UUID for the systems in question.

thanks, 

------------------------------
Pete Meechan
Principal Consultant
Orb Data Limited

Original Message:
Sent: Thu February 08, 2024 02:36 AM
From: Oktawian Powązka
Subject: Incorrect PVU per core value

Hello,

Right...so in such case I can see three possibilities:

1. The user who is connecting with the VM manager does not have required permissions to collect data about the virtual machine,
2. virtual machine is inactive/power off state,
3. UUID format is somehow screwed (what I mean by this is the UUID from capacity data collected by scanner component is processed slightly differently the UUID collected by VM manager...I've done some defect long time ago addressing such issue)

To go further, you need to look into 'debugData\debug' folder,
There is a bunch of .xml files under this folder you need to check out first.
You haven't specified which Hypervisor type you are dealing with so I'm not able to give you any specifics as .xml files is strictly Hypervisor dependent.
(In case of VMware (most popular) this would be retrieveProperties.xml file)
Look for the VM name under each '<obj type="VirtualMachine">vm-xxxx</obj>' entry or use some UUID fragment.
I guess that this is a kind of a guessing game...

If you still don't find anything in 'debug' folder the next step would be to get VM list (with corresponding UUIDs) directly from Hypervisor using the native API....again,  this whole thing is strictly Hypervisor dependent.

------------------------------
Thank you,
Oktawian

Oktawian Powązka, L3 Support
IBM License Metric Tool

Original Message:
Sent: Wed February 07, 2024 11:24 AM
From: Pete Meechan
Subject: Incorrect PVU per core value

Hello Oktawian,

Thanks for the update. I have checked the tlm_vm_xxx files for the UUID values of the 2 systems in question and checked them against the (only) vmman_svcan_xx.xml file from the debug zip file data and cannot see any reference to UUID in the file.

Is there something else that  need to check to try to track down the issue?

regards, Pete

------------------------------
Pete Meechan
Principal Consultant
Orb Data Limited

Original Message:
Sent: Wed February 07, 2024 11:11 AM
From: Oktawian Powązka
Subject: Incorrect PVU per core value

Hello Pete,

Ok, if this is a VM with "No VM Manager Data" status that 120 PVU makes a perfect sense.
I was misguided by your initial post:
The physical system hosting the VM with the (now) incorrect PVU count....

To go further, you need to collect two things:

1. debugData.zip file generated by 'vmman.<sh/bat> -retrievedebugdata' command,
2. Hardware Inventory report showing that VM entry with 'TLM_VM_' prefix (to get the UUID value)
   

Next, check whether the UUID that you obtained in step 2 exists in one of the vmman_scan_xxx.xml files from debugData.zip package.

Again, we are happy to help you out through a support ticket...

------------------------------
Thank you,
Oktawian

Oktawian Powązka, L3 Support
IBM License Metric Tool

Original Message:
Sent: Wed February 07, 2024 04:44 AM
From: Pete Meechan
Subject: Incorrect PVU per core value

Hello Oktawian,

After checking the content of the tlm_hw_xxx.xml files for the 2 systems in question and, running a "diff" of the files from November 2023 and the most recent February 2024 copies of the files, there is no difference between the file contents.

Returning again to the ILMT console the systems in question are showing as "No VM Manager Data" so I have stepped through the troubleshooting documented here https://www.ibm.com/docs/en/license-metric-tool?topic=scshw-troubleshooting-outdated-vm-manager-data-no-vm-manager-data-statuses and cannot determine the reason why this status is shown. There are no obvious errors in the logs or configuration files etc. checked during the troubleshooting steps.

Could this be a factor in why the PVU is being reported incorrectly?

Maybe it is time for the customer to open a support ticket

regards,

------------------------------
Pete Meechan
Principal Consultant
Orb Data Limited

Original Message:
Sent: Tue February 06, 2024 03:20 AM
From: Pete Meechan
Subject: Incorrect PVU per core value

Hello Oktawian,

My apologies - the previous ILMT version was 9.2.33.

I will check the tlm_hw_xxx.html file from the latest scan and provide an update.

regards, 

------------------------------
Pete Meechan
Principal Consultant
Orb Data Limited

Original Message:
Sent: Tue February 06, 2024 03:05 AM
From: Oktawian Powązka
Subject: Incorrect PVU per core value

Hello Pete,

You haven't provided the ILMT version which was used before an upgrade...

Anyhow, the blind guess is that scanner component has provided a different capacity scan results than in previous version.
Perhaps somehow that CPU was discovered with some more sockets per processor (>4 : 120 PVUs).

It would be difficult to unequivocally confirm what the issue is without looking into capacity scan result (tlm_hw_xxx.xml).
Either please upload the capacity scan result file or open a support ticket to us...

------------------------------
Thank you,
Oktawian

Oktawian Powązka, L3 Support
IBM License Metric Tool

Original Message:
Sent: Mon February 05, 2024 01:57 PM
From: Pete Meechan
Subject: Incorrect PVU per core value

Hello,

For a new ILMT deployment using BigFix the PVU metrics were working following the installation last year. Mid -December 2023 the PVU metrics were incorrectly reported for a few weeks due to an issue with database connectivity. After resolving the database issue and confirming the reporting was working as expected it was noticed that the PVU count per core had changed from 70 PVU to 120 PVU. This seems to have coincided with the update of ILMT to version 9.2.34.

The physical system hosting the VM with the (now) incorrect PVU count is model HPE ProLiant D380 Gen10 with an Intel (R) Xeon(R) Gold 6248R CPU which has 2 sockets per processor. According to the website IBM Processor Value Unit [PVU] licensing for Distributed Software and Processor value unit calculator this should be 7- PVU. The specific model isn't listed but it is classed as an Intel Xeon socket 1 or 2  at 70 PVU.

Do you know if this is an issue introduced with the 9.2.34 upgrade?

Thanks in advance for your help.

regards, 

------------------------------
Pete Meechan
Principal Consultant
Orb Data Limited
------------------------------

<My first name>powazka@pl.ibm.com

Hello Oktawian,

The customer has given me the okay to email a copy of the debugData.zip file. What email address should I use?

regards, Pete

Hello Pete,

The customer is using UUID-based virtual machine filtering...
So, 'vmmfilterconf.properties' file contain that UUID in question, correct  ?

Well, I'd have to look into that DebugData.zip file...
Either pls. send me this by mail or open a support ticket to us...

Hello Oktawian,

Thanks for your help with this. The hypervisor is VMWare.

Option 1 doesn't look likely as the customer did a test yesterday, reducing the cores on one of the systems and this morning ILMT correctly reported the reduced cores, but still showing a PVU count of 120

Option 2 is doesn't apply as both systems are actively being used

That leaves Option 3  so I checked the retrieveProperties.xml from the debug data for the corresponding UUID values and both of them are present in the file.

Do you have any other suggestions that I can check please?

The customer is using UUID-based virtual machine filtering - I don't know if that could be having an impact. I have checked the UUID configured for filtering match the UUID for the systems in question.

thanks, 

------------------------------
Pete Meechan
Principal Consultant
Orb Data Limited

Original Message:
Sent: Thu February 08, 2024 02:36 AM
From: Oktawian Powązka
Subject: Incorrect PVU per core value

Hello,

Right...so in such case I can see three possibilities:

1. The user who is connecting with the VM manager does not have required permissions to collect data about the virtual machine,
2. virtual machine is inactive/power off state,
3. UUID format is somehow screwed (what I mean by this is the UUID from capacity data collected by scanner component is processed slightly differently the UUID collected by VM manager...I've done some defect long time ago addressing such issue)

To go further, you need to look into 'debugData\debug' folder,
There is a bunch of .xml files under this folder you need to check out first.
You haven't specified which Hypervisor type you are dealing with so I'm not able to give you any specifics as .xml files is strictly Hypervisor dependent.
(In case of VMware (most popular) this would be retrieveProperties.xml file)
Look for the VM name under each '<obj type="VirtualMachine">vm-xxxx</obj>' entry or use some UUID fragment.
I guess that this is a kind of a guessing game...

If you still don't find anything in 'debug' folder the next step would be to get VM list (with corresponding UUIDs) directly from Hypervisor using the native API....again,  this whole thing is strictly Hypervisor dependent.

------------------------------
Thank you,
Oktawian

Oktawian Powązka, L3 Support
IBM License Metric Tool

Original Message:
Sent: Wed February 07, 2024 11:24 AM
From: Pete Meechan
Subject: Incorrect PVU per core value

Hello Oktawian,

Thanks for the update. I have checked the tlm_vm_xxx files for the UUID values of the 2 systems in question and checked them against the (only) vmman_svcan_xx.xml file from the debug zip file data and cannot see any reference to UUID in the file.

Is there something else that  need to check to try to track down the issue?

regards, Pete

------------------------------
Pete Meechan
Principal Consultant
Orb Data Limited

Original Message:
Sent: Wed February 07, 2024 11:11 AM
From: Oktawian Powązka
Subject: Incorrect PVU per core value

Hello Pete,

Ok, if this is a VM with "No VM Manager Data" status that 120 PVU makes a perfect sense.
I was misguided by your initial post:
The physical system hosting the VM with the (now) incorrect PVU count....

To go further, you need to collect two things:

1. debugData.zip file generated by 'vmman.<sh/bat> -retrievedebugdata' command,
2. Hardware Inventory report showing that VM entry with 'TLM_VM_' prefix (to get the UUID value)
   

Next, check whether the UUID that you obtained in step 2 exists in one of the vmman_scan_xxx.xml files from debugData.zip package.

Again, we are happy to help you out through a support ticket...

------------------------------
Thank you,
Oktawian

Oktawian Powązka, L3 Support
IBM License Metric Tool

Original Message:
Sent: Wed February 07, 2024 04:44 AM
From: Pete Meechan
Subject: Incorrect PVU per core value

Hello Oktawian,

After checking the content of the tlm_hw_xxx.xml files for the 2 systems in question and, running a "diff" of the files from November 2023 and the most recent February 2024 copies of the files, there is no difference between the file contents.

Returning again to the ILMT console the systems in question are showing as "No VM Manager Data" so I have stepped through the troubleshooting documented here https://www.ibm.com/docs/en/license-metric-tool?topic=scshw-troubleshooting-outdated-vm-manager-data-no-vm-manager-data-statuses and cannot determine the reason why this status is shown. There are no obvious errors in the logs or configuration files etc. checked during the troubleshooting steps.

Could this be a factor in why the PVU is being reported incorrectly?

Maybe it is time for the customer to open a support ticket

regards,

------------------------------
Pete Meechan
Principal Consultant
Orb Data Limited

Original Message:
Sent: Tue February 06, 2024 03:20 AM
From: Pete Meechan
Subject: Incorrect PVU per core value

Hello Oktawian,

My apologies - the previous ILMT version was 9.2.33.

I will check the tlm_hw_xxx.html file from the latest scan and provide an update.

regards, 

------------------------------
Pete Meechan
Principal Consultant
Orb Data Limited

Original Message:
Sent: Tue February 06, 2024 03:05 AM
From: Oktawian Powązka
Subject: Incorrect PVU per core value

Hello Pete,

You haven't provided the ILMT version which was used before an upgrade...

Anyhow, the blind guess is that scanner component has provided a different capacity scan results than in previous version.
Perhaps somehow that CPU was discovered with some more sockets per processor (>4 : 120 PVUs).

It would be difficult to unequivocally confirm what the issue is without looking into capacity scan result (tlm_hw_xxx.xml).
Either please upload the capacity scan result file or open a support ticket to us...

------------------------------
Thank you,
Oktawian

Oktawian Powązka, L3 Support
IBM License Metric Tool

Original Message:
Sent: Mon February 05, 2024 01:57 PM
From: Pete Meechan
Subject: Incorrect PVU per core value

Hello,

For a new ILMT deployment using BigFix the PVU metrics were working following the installation last year. Mid -December 2023 the PVU metrics were incorrectly reported for a few weeks due to an issue with database connectivity. After resolving the database issue and confirming the reporting was working as expected it was noticed that the PVU count per core had changed from 70 PVU to 120 PVU. This seems to have coincided with the update of ILMT to version 9.2.34.

The physical system hosting the VM with the (now) incorrect PVU count is model HPE ProLiant D380 Gen10 with an Intel (R) Xeon(R) Gold 6248R CPU which has 2 sockets per processor. According to the website IBM Processor Value Unit [PVU] licensing for Distributed Software and Processor value unit calculator this should be 7- PVU. The specific model isn't listed but it is classed as an Intel Xeon socket 1 or 2  at 70 PVU.

Do you know if this is an issue introduced with the 9.2.34 upgrade?

Thanks in advance for your help.

regards, 

------------------------------
Pete Meechan
Principal Consultant
Orb Data Limited
------------------------------

Hello again,

vmman_scan_1_1707408370.xml is entirely empty...it means no clusters/no hosts/no VMs been selected upon final processing.

I can see two reasons for that :

1. Improper setup in 'vmmfilterconf.properties' file (I completely forgot to ask you about that file),
2. trace log shows up a lot of 'DUPLICATED GUEST' entries for some VMs...the question is if that UUID in question is indeed duplicated between two (or more) hosts.

So, pls. send me that 'vmmfilterconf.properties' file + let me know the UUID values for all those systems showing with "No VM Manager Data" status. 

<My first name>powazka@pl.ibm.com

Hello Oktawian,

The customer has given me the okay to email a copy of the debugData.zip file. What email address should I use?

regards, Pete

Hello Pete,

The customer is using UUID-based virtual machine filtering...
So, 'vmmfilterconf.properties' file contain that UUID in question, correct  ?

Well, I'd have to look into that DebugData.zip file...
Either pls. send me this by mail or open a support ticket to us...

Hello Oktawian,

Thanks for your help with this. The hypervisor is VMWare.

Option 1 doesn't look likely as the customer did a test yesterday, reducing the cores on one of the systems and this morning ILMT correctly reported the reduced cores, but still showing a PVU count of 120

Option 2 is doesn't apply as both systems are actively being used

That leaves Option 3  so I checked the retrieveProperties.xml from the debug data for the corresponding UUID values and both of them are present in the file.

Do you have any other suggestions that I can check please?

The customer is using UUID-based virtual machine filtering - I don't know if that could be having an impact. I have checked the UUID configured for filtering match the UUID for the systems in question.

thanks, 

------------------------------
Pete Meechan
Principal Consultant
Orb Data Limited

Original Message:
Sent: Thu February 08, 2024 02:36 AM
From: Oktawian Powązka
Subject: Incorrect PVU per core value

Hello,

Right...so in such case I can see three possibilities:

1. The user who is connecting with the VM manager does not have required permissions to collect data about the virtual machine,
2. virtual machine is inactive/power off state,
3. UUID format is somehow screwed (what I mean by this is the UUID from capacity data collected by scanner component is processed slightly differently the UUID collected by VM manager...I've done some defect long time ago addressing such issue)

To go further, you need to look into 'debugData\debug' folder,
There is a bunch of .xml files under this folder you need to check out first.
You haven't specified which Hypervisor type you are dealing with so I'm not able to give you any specifics as .xml files is strictly Hypervisor dependent.
(In case of VMware (most popular) this would be retrieveProperties.xml file)
Look for the VM name under each '<obj type="VirtualMachine">vm-xxxx</obj>' entry or use some UUID fragment.
I guess that this is a kind of a guessing game...

If you still don't find anything in 'debug' folder the next step would be to get VM list (with corresponding UUIDs) directly from Hypervisor using the native API....again,  this whole thing is strictly Hypervisor dependent.

------------------------------
Thank you,
Oktawian

Oktawian Powązka, L3 Support
IBM License Metric Tool

Original Message:
Sent: Wed February 07, 2024 11:24 AM
From: Pete Meechan
Subject: Incorrect PVU per core value

Hello Oktawian,

Thanks for the update. I have checked the tlm_vm_xxx files for the UUID values of the 2 systems in question and checked them against the (only) vmman_svcan_xx.xml file from the debug zip file data and cannot see any reference to UUID in the file.

Is there something else that  need to check to try to track down the issue?

regards, Pete

------------------------------
Pete Meechan
Principal Consultant
Orb Data Limited

Original Message:
Sent: Wed February 07, 2024 11:11 AM
From: Oktawian Powązka
Subject: Incorrect PVU per core value

Hello Pete,

Ok, if this is a VM with "No VM Manager Data" status that 120 PVU makes a perfect sense.
I was misguided by your initial post:
The physical system hosting the VM with the (now) incorrect PVU count....

To go further, you need to collect two things:

1. debugData.zip file generated by 'vmman.<sh/bat> -retrievedebugdata' command,
2. Hardware Inventory report showing that VM entry with 'TLM_VM_' prefix (to get the UUID value)
   

Next, check whether the UUID that you obtained in step 2 exists in one of the vmman_scan_xxx.xml files from debugData.zip package.

Again, we are happy to help you out through a support ticket...

------------------------------
Thank you,
Oktawian

Oktawian Powązka, L3 Support
IBM License Metric Tool

Original Message:
Sent: Wed February 07, 2024 04:44 AM
From: Pete Meechan
Subject: Incorrect PVU per core value

Hello Oktawian,

After checking the content of the tlm_hw_xxx.xml files for the 2 systems in question and, running a "diff" of the files from November 2023 and the most recent February 2024 copies of the files, there is no difference between the file contents.

Returning again to the ILMT console the systems in question are showing as "No VM Manager Data" so I have stepped through the troubleshooting documented here https://www.ibm.com/docs/en/license-metric-tool?topic=scshw-troubleshooting-outdated-vm-manager-data-no-vm-manager-data-statuses and cannot determine the reason why this status is shown. There are no obvious errors in the logs or configuration files etc. checked during the troubleshooting steps.

Could this be a factor in why the PVU is being reported incorrectly?

Maybe it is time for the customer to open a support ticket

regards,

------------------------------
Pete Meechan
Principal Consultant
Orb Data Limited

Original Message:
Sent: Tue February 06, 2024 03:20 AM
From: Pete Meechan
Subject: Incorrect PVU per core value

Hello Oktawian,

My apologies - the previous ILMT version was 9.2.33.

I will check the tlm_hw_xxx.html file from the latest scan and provide an update.

regards, 

------------------------------
Pete Meechan
Principal Consultant
Orb Data Limited

Original Message:
Sent: Tue February 06, 2024 03:05 AM
From: Oktawian Powązka
Subject: Incorrect PVU per core value

Hello Pete,

You haven't provided the ILMT version which was used before an upgrade...

Anyhow, the blind guess is that scanner component has provided a different capacity scan results than in previous version.
Perhaps somehow that CPU was discovered with some more sockets per processor (>4 : 120 PVUs).

It would be difficult to unequivocally confirm what the issue is without looking into capacity scan result (tlm_hw_xxx.xml).
Either please upload the capacity scan result file or open a support ticket to us...

------------------------------
Thank you,
Oktawian

Oktawian Powązka, L3 Support
IBM License Metric Tool

Original Message:
Sent: Mon February 05, 2024 01:57 PM
From: Pete Meechan
Subject: Incorrect PVU per core value

Hello,

For a new ILMT deployment using BigFix the PVU metrics were working following the installation last year. Mid -December 2023 the PVU metrics were incorrectly reported for a few weeks due to an issue with database connectivity. After resolving the database issue and confirming the reporting was working as expected it was noticed that the PVU count per core had changed from 70 PVU to 120 PVU. This seems to have coincided with the update of ILMT to version 9.2.34.

The physical system hosting the VM with the (now) incorrect PVU count is model HPE ProLiant D380 Gen10 with an Intel (R) Xeon(R) Gold 6248R CPU which has 2 sockets per processor. According to the website IBM Processor Value Unit [PVU] licensing for Distributed Software and Processor value unit calculator this should be 7- PVU. The specific model isn't listed but it is classed as an Intel Xeon socket 1 or 2  at 70 PVU.

Do you know if this is an issue introduced with the 9.2.34 upgrade?

Thanks in advance for your help.

regards, 

------------------------------
Pete Meechan
Principal Consultant
Orb Data Limited
------------------------------

Hello Oktawian,

I will send you a copy of the 'vmmfilterconf.properties' file along with the UUID values for all those systems showing with "No VM Manager Data" status.

As for the duplicated UUIDs - this was discussed with you on the forum here https://community.ibm.com/community/user/automation/discussion/ilmt-9233-vm-manager-status-ok-duplicated-uuids-discarded a few months ago and after following the steps discussed ILMT was functioning correctly with version 9.2.33 using the UUID filtering discussed therein. 

This worked without issues until with problems accessing the MS SQL server database occurred. This was fixed in early January and as part of the "fix" the customer upgraded ILMT from 9.2.33 to 9.2.34 to see if that would fix the incorrect PVU count. It didn't, which was when I was asked to take a look. I noticed there was a mixture of 9.2.33 and 9.2.34 fixlets active so I cleaned all of those up and ensured that the required fixlets e.g. capacity, software scan. etc were all running correctly at 9.2.34 but still the PVU count is showing at 120 rather than the expected 70 as was shown with the 9.2.33 version

I will send the other information now.

regards, Pete

Hello again,

vmman_scan_1_1707408370.xml is entirely empty...it means no clusters/no hosts/no VMs been selected upon final processing.

I can see two reasons for that :

1. Improper setup in 'vmmfilterconf.properties' file (I completely forgot to ask you about that file),
2. trace log shows up a lot of 'DUPLICATED GUEST' entries for some VMs...the question is if that UUID in question is indeed duplicated between two (or more) hosts.

So, pls. send me that 'vmmfilterconf.properties' file + let me know the UUID values for all those systems showing with "No VM Manager Data" status. 

<My first name>powazka@pl.ibm.com

Hello Oktawian,

The customer has given me the okay to email a copy of the debugData.zip file. What email address should I use?

regards, Pete

Hello Pete,

The customer is using UUID-based virtual machine filtering...
So, 'vmmfilterconf.properties' file contain that UUID in question, correct  ?

Well, I'd have to look into that DebugData.zip file...
Either pls. send me this by mail or open a support ticket to us...

Hello Oktawian,

Thanks for your help with this. The hypervisor is VMWare.

Option 1 doesn't look likely as the customer did a test yesterday, reducing the cores on one of the systems and this morning ILMT correctly reported the reduced cores, but still showing a PVU count of 120

Option 2 is doesn't apply as both systems are actively being used

That leaves Option 3  so I checked the retrieveProperties.xml from the debug data for the corresponding UUID values and both of them are present in the file.

Do you have any other suggestions that I can check please?

The customer is using UUID-based virtual machine filtering - I don't know if that could be having an impact. I have checked the UUID configured for filtering match the UUID for the systems in question.

thanks, 

------------------------------
Pete Meechan
Principal Consultant
Orb Data Limited

Original Message:
Sent: Thu February 08, 2024 02:36 AM
From: Oktawian Powązka
Subject: Incorrect PVU per core value

Hello,

Right...so in such case I can see three possibilities:

1. The user who is connecting with the VM manager does not have required permissions to collect data about the virtual machine,
2. virtual machine is inactive/power off state,
3. UUID format is somehow screwed (what I mean by this is the UUID from capacity data collected by scanner component is processed slightly differently the UUID collected by VM manager...I've done some defect long time ago addressing such issue)

To go further, you need to look into 'debugData\debug' folder,
There is a bunch of .xml files under this folder you need to check out first.
You haven't specified which Hypervisor type you are dealing with so I'm not able to give you any specifics as .xml files is strictly Hypervisor dependent.
(In case of VMware (most popular) this would be retrieveProperties.xml file)
Look for the VM name under each '<obj type="VirtualMachine">vm-xxxx</obj>' entry or use some UUID fragment.
I guess that this is a kind of a guessing game...

If you still don't find anything in 'debug' folder the next step would be to get VM list (with corresponding UUIDs) directly from Hypervisor using the native API....again,  this whole thing is strictly Hypervisor dependent.

------------------------------
Thank you,
Oktawian

Oktawian Powązka, L3 Support
IBM License Metric Tool

Original Message:
Sent: Wed February 07, 2024 11:24 AM
From: Pete Meechan
Subject: Incorrect PVU per core value

Hello Oktawian,

Thanks for the update. I have checked the tlm_vm_xxx files for the UUID values of the 2 systems in question and checked them against the (only) vmman_svcan_xx.xml file from the debug zip file data and cannot see any reference to UUID in the file.

Is there something else that  need to check to try to track down the issue?

regards, Pete

------------------------------
Pete Meechan
Principal Consultant
Orb Data Limited

Original Message:
Sent: Wed February 07, 2024 11:11 AM
From: Oktawian Powązka
Subject: Incorrect PVU per core value

Hello Pete,

Ok, if this is a VM with "No VM Manager Data" status that 120 PVU makes a perfect sense.
I was misguided by your initial post:
The physical system hosting the VM with the (now) incorrect PVU count....

To go further, you need to collect two things:

1. debugData.zip file generated by 'vmman.<sh/bat> -retrievedebugdata' command,
2. Hardware Inventory report showing that VM entry with 'TLM_VM_' prefix (to get the UUID value)
   

Next, check whether the UUID that you obtained in step 2 exists in one of the vmman_scan_xxx.xml files from debugData.zip package.

Again, we are happy to help you out through a support ticket...

------------------------------
Thank you,
Oktawian

Oktawian Powązka, L3 Support
IBM License Metric Tool

Original Message:
Sent: Wed February 07, 2024 04:44 AM
From: Pete Meechan
Subject: Incorrect PVU per core value

Hello Oktawian,

After checking the content of the tlm_hw_xxx.xml files for the 2 systems in question and, running a "diff" of the files from November 2023 and the most recent February 2024 copies of the files, there is no difference between the file contents.

Returning again to the ILMT console the systems in question are showing as "No VM Manager Data" so I have stepped through the troubleshooting documented here https://www.ibm.com/docs/en/license-metric-tool?topic=scshw-troubleshooting-outdated-vm-manager-data-no-vm-manager-data-statuses and cannot determine the reason why this status is shown. There are no obvious errors in the logs or configuration files etc. checked during the troubleshooting steps.

Could this be a factor in why the PVU is being reported incorrectly?

Maybe it is time for the customer to open a support ticket

regards,

------------------------------
Pete Meechan
Principal Consultant
Orb Data Limited

Original Message:
Sent: Tue February 06, 2024 03:20 AM
From: Pete Meechan
Subject: Incorrect PVU per core value

Hello Oktawian,

My apologies - the previous ILMT version was 9.2.33.

I will check the tlm_hw_xxx.html file from the latest scan and provide an update.

regards, 

------------------------------
Pete Meechan
Principal Consultant
Orb Data Limited

Original Message:
Sent: Tue February 06, 2024 03:05 AM
From: Oktawian Powązka
Subject: Incorrect PVU per core value

Hello Pete,

You haven't provided the ILMT version which was used before an upgrade...

Anyhow, the blind guess is that scanner component has provided a different capacity scan results than in previous version.
Perhaps somehow that CPU was discovered with some more sockets per processor (>4 : 120 PVUs).

It would be difficult to unequivocally confirm what the issue is without looking into capacity scan result (tlm_hw_xxx.xml).
Either please upload the capacity scan result file or open a support ticket to us...

------------------------------
Thank you,
Oktawian

Oktawian Powązka, L3 Support
IBM License Metric Tool

Original Message:
Sent: Mon February 05, 2024 01:57 PM
From: Pete Meechan
Subject: Incorrect PVU per core value

Hello,

For a new ILMT deployment using BigFix the PVU metrics were working following the installation last year. Mid -December 2023 the PVU metrics were incorrectly reported for a few weeks due to an issue with database connectivity. After resolving the database issue and confirming the reporting was working as expected it was noticed that the PVU count per core had changed from 70 PVU to 120 PVU. This seems to have coincided with the update of ILMT to version 9.2.34.

The physical system hosting the VM with the (now) incorrect PVU count is model HPE ProLiant D380 Gen10 with an Intel (R) Xeon(R) Gold 6248R CPU which has 2 sockets per processor. According to the website IBM Processor Value Unit [PVU] licensing for Distributed Software and Processor value unit calculator this should be 7- PVU. The specific model isn't listed but it is classed as an Intel Xeon socket 1 or 2  at 70 PVU.

Do you know if this is an issue introduced with the 9.2.34 upgrade?

Thanks in advance for your help.

regards, 

------------------------------
Pete Meechan
Principal Consultant
Orb Data Limited
------------------------------

Hello,

So the problem is....the third issue from the list: UUID format is somehow screwed

As you can see:

33333438-3437-5A43-4A38-313430565342 (collected by scanner component)
00212b02-60fb-e511-a1f0-3c18a0016dd2 (collected by scanner component)
vs
38343333-3734-435a-4a38-313430565342  (collected by VM manager)
022b2100-fb60-11e5-a1f0-3c18a0016dd2  (collected by VM manager)

only the last two pieces are properly ordered. The first three are 'rearranged'...
To be honest I'm not sure how have you previously checked the retrieveProperties.xml from the debugdata using that direct UUID value (collected by scanner component)...

To address that just add
38343333-3734-435a-4a38-313430565342
022b2100-fb60-11e5-a1f0-3c18a0016dd2 
into vmmfilterconf.properties file.

Hello Oktawian,

I will send you a copy of the 'vmmfilterconf.properties' file along with the UUID values for all those systems showing with "No VM Manager Data" status.

As for the duplicated UUIDs - this was discussed with you on the forum here https://community.ibm.com/community/user/automation/discussion/ilmt-9233-vm-manager-status-ok-duplicated-uuids-discarded a few months ago and after following the steps discussed ILMT was functioning correctly with version 9.2.33 using the UUID filtering discussed therein. 

This worked without issues until with problems accessing the MS SQL server database occurred. This was fixed in early January and as part of the "fix" the customer upgraded ILMT from 9.2.33 to 9.2.34 to see if that would fix the incorrect PVU count. It didn't, which was when I was asked to take a look. I noticed there was a mixture of 9.2.33 and 9.2.34 fixlets active so I cleaned all of those up and ensured that the required fixlets e.g. capacity, software scan. etc were all running correctly at 9.2.34 but still the PVU count is showing at 120 rather than the expected 70 as was shown with the 9.2.33 version

I will send the other information now.

regards, Pete

Hello again,

vmman_scan_1_1707408370.xml is entirely empty...it means no clusters/no hosts/no VMs been selected upon final processing.

I can see two reasons for that :

1. Improper setup in 'vmmfilterconf.properties' file (I completely forgot to ask you about that file),
2. trace log shows up a lot of 'DUPLICATED GUEST' entries for some VMs...the question is if that UUID in question is indeed duplicated between two (or more) hosts.

So, pls. send me that 'vmmfilterconf.properties' file + let me know the UUID values for all those systems showing with "No VM Manager Data" status. 

<My first name>powazka@pl.ibm.com

Hello Oktawian,

The customer has given me the okay to email a copy of the debugData.zip file. What email address should I use?

regards, Pete

Hello Pete,

The customer is using UUID-based virtual machine filtering...
So, 'vmmfilterconf.properties' file contain that UUID in question, correct  ?

Well, I'd have to look into that DebugData.zip file...
Either pls. send me this by mail or open a support ticket to us...

Hello Oktawian,

Thanks for your help with this. The hypervisor is VMWare.

Option 1 doesn't look likely as the customer did a test yesterday, reducing the cores on one of the systems and this morning ILMT correctly reported the reduced cores, but still showing a PVU count of 120

Option 2 is doesn't apply as both systems are actively being used

That leaves Option 3  so I checked the retrieveProperties.xml from the debug data for the corresponding UUID values and both of them are present in the file.

Do you have any other suggestions that I can check please?

The customer is using UUID-based virtual machine filtering - I don't know if that could be having an impact. I have checked the UUID configured for filtering match the UUID for the systems in question.

thanks, 

------------------------------
Pete Meechan
Principal Consultant
Orb Data Limited

Original Message:
Sent: Thu February 08, 2024 02:36 AM
From: Oktawian Powązka
Subject: Incorrect PVU per core value

Hello,

Right...so in such case I can see three possibilities:

1. The user who is connecting with the VM manager does not have required permissions to collect data about the virtual machine,
2. virtual machine is inactive/power off state,
3. UUID format is somehow screwed (what I mean by this is the UUID from capacity data collected by scanner component is processed slightly differently the UUID collected by VM manager...I've done some defect long time ago addressing such issue)

To go further, you need to look into 'debugData\debug' folder,
There is a bunch of .xml files under this folder you need to check out first.
You haven't specified which Hypervisor type you are dealing with so I'm not able to give you any specifics as .xml files is strictly Hypervisor dependent.
(In case of VMware (most popular) this would be retrieveProperties.xml file)
Look for the VM name under each '<obj type="VirtualMachine">vm-xxxx</obj>' entry or use some UUID fragment.
I guess that this is a kind of a guessing game...

If you still don't find anything in 'debug' folder the next step would be to get VM list (with corresponding UUIDs) directly from Hypervisor using the native API....again,  this whole thing is strictly Hypervisor dependent.

------------------------------
Thank you,
Oktawian

Oktawian Powązka, L3 Support
IBM License Metric Tool

Original Message:
Sent: Wed February 07, 2024 11:24 AM
From: Pete Meechan
Subject: Incorrect PVU per core value

Hello Oktawian,

Thanks for the update. I have checked the tlm_vm_xxx files for the UUID values of the 2 systems in question and checked them against the (only) vmman_svcan_xx.xml file from the debug zip file data and cannot see any reference to UUID in the file.

Is there something else that  need to check to try to track down the issue?

regards, Pete

------------------------------
Pete Meechan
Principal Consultant
Orb Data Limited

Original Message:
Sent: Wed February 07, 2024 11:11 AM
From: Oktawian Powązka
Subject: Incorrect PVU per core value

Hello Pete,

Ok, if this is a VM with "No VM Manager Data" status that 120 PVU makes a perfect sense.
I was misguided by your initial post:
The physical system hosting the VM with the (now) incorrect PVU count....

To go further, you need to collect two things:

1. debugData.zip file generated by 'vmman.<sh/bat> -retrievedebugdata' command,
2. Hardware Inventory report showing that VM entry with 'TLM_VM_' prefix (to get the UUID value)
   

Next, check whether the UUID that you obtained in step 2 exists in one of the vmman_scan_xxx.xml files from debugData.zip package.

Again, we are happy to help you out through a support ticket...

------------------------------
Thank you,
Oktawian

Oktawian Powązka, L3 Support
IBM License Metric Tool

Original Message:
Sent: Wed February 07, 2024 04:44 AM
From: Pete Meechan
Subject: Incorrect PVU per core value

Hello Oktawian,

After checking the content of the tlm_hw_xxx.xml files for the 2 systems in question and, running a "diff" of the files from November 2023 and the most recent February 2024 copies of the files, there is no difference between the file contents.

Returning again to the ILMT console the systems in question are showing as "No VM Manager Data" so I have stepped through the troubleshooting documented here https://www.ibm.com/docs/en/license-metric-tool?topic=scshw-troubleshooting-outdated-vm-manager-data-no-vm-manager-data-statuses and cannot determine the reason why this status is shown. There are no obvious errors in the logs or configuration files etc. checked during the troubleshooting steps.

Could this be a factor in why the PVU is being reported incorrectly?

Maybe it is time for the customer to open a support ticket

regards,

------------------------------
Pete Meechan
Principal Consultant
Orb Data Limited

Original Message:
Sent: Tue February 06, 2024 03:20 AM
From: Pete Meechan
Subject: Incorrect PVU per core value

Hello Oktawian,

My apologies - the previous ILMT version was 9.2.33.

I will check the tlm_hw_xxx.html file from the latest scan and provide an update.

regards, 

------------------------------
Pete Meechan
Principal Consultant
Orb Data Limited

Original Message:
Sent: Tue February 06, 2024 03:05 AM
From: Oktawian Powązka
Subject: Incorrect PVU per core value

Hello Pete,

You haven't provided the ILMT version which was used before an upgrade...

Anyhow, the blind guess is that scanner component has provided a different capacity scan results than in previous version.
Perhaps somehow that CPU was discovered with some more sockets per processor (>4 : 120 PVUs).

It would be difficult to unequivocally confirm what the issue is without looking into capacity scan result (tlm_hw_xxx.xml).
Either please upload the capacity scan result file or open a support ticket to us...

------------------------------
Thank you,
Oktawian

Oktawian Powązka, L3 Support
IBM License Metric Tool

Original Message:
Sent: Mon February 05, 2024 01:57 PM
From: Pete Meechan
Subject: Incorrect PVU per core value

Hello,

For a new ILMT deployment using BigFix the PVU metrics were working following the installation last year. Mid -December 2023 the PVU metrics were incorrectly reported for a few weeks due to an issue with database connectivity. After resolving the database issue and confirming the reporting was working as expected it was noticed that the PVU count per core had changed from 70 PVU to 120 PVU. This seems to have coincided with the update of ILMT to version 9.2.34.

The physical system hosting the VM with the (now) incorrect PVU count is model HPE ProLiant D380 Gen10 with an Intel (R) Xeon(R) Gold 6248R CPU which has 2 sockets per processor. According to the website IBM Processor Value Unit [PVU] licensing for Distributed Software and Processor value unit calculator this should be 7- PVU. The specific model isn't listed but it is classed as an Intel Xeon socket 1 or 2  at 70 PVU.

Do you know if this is an issue introduced with the 9.2.34 upgrade?

Thanks in advance for your help.

regards, 

------------------------------
Pete Meechan
Principal Consultant
Orb Data Limited
------------------------------