Hardware inventory problems

Edit online

Find the solution to the issues that you have encountered while working with virtual machine managers and hardware inventory.

Update of the VM Manager Tool fails - applicable for central and distributed VM Manager Tool.
When you run the Update VM Manager Tool to version fixlet, the update fails. When you view the details of the action on a particular computer, the script can fail on various lines, for example:
waithidden cmd /c "rmdir "{parameter "homefolder"}" /s /q"
continue if {exit code of action = 0}
To solve the problem, perform the following steps:
  1. Go to the computer on which the update of the VM Manager Tool failed and open the <BES_Client>/LMT folder.
  2. If the folder does not contain the VMMAN_copy folder, create it.
  3. Copy the config and keydb folders from the <BES_Client>/LMT/VMMAN folder to the <BES_Client>/LMT/VMMAN_copy folder.
  4. Remove the VMMAN folder.
  5. Run one of the following fixlets to complete the update. It might take some time before the fixlet becomes relevant.
    • Run the Install VM Manager Tool version number fixlet, if the update failed on the computer where the main instance of the VM Manager Tool is installed.
    • Run the Install Additional VM Manager Tool (OPTIONAL) version number fixlet if the update failed on the computer where an additional instance of the VM Manager Tool is installed.
Server is running, but an exception in traces appears. The exception is related to the connection with the specified ESX with the following message: javax.net.ssl.SSLException: Unrecognized SSL message, plaintext connection?
  1. Add the following lines to file /etc/vmware/hostd/config.xml: 
    ..
    <ssl>
       <doVersionCheck> false </doVersionCheck>
       <handshakeTimeoutMs>30000</handshakeTimeoutMs>
    </ssl>
    <http>
        <readTimeoutMs>45000</readTimeoutMs>
        <writeTimeoutMs>45000</writeTimeoutMs>
        <blacklistPeriodMs>3000</blacklistPeriodMs>
    </http>
    <vmdb>
      ...
  2. Restart the hostd service using service mgmt-vmware restart.
  3. Verify that the exception does not occur.
Server is running, but an org.xml.sax.SAXParseException exception in traces appears. The exception is related to the connection with the specified ESX.
Make sure that you have the latest patches to your problematic ESX server installed.
Upgrade of vCenter server from v5.0 to v5.1 causing server connection failure.
The following message is displayed CODVM0003E The VM manager denied access because of invalid credentials. To solve this issue, perform the following steps:
  1. In vCenter, stop all sessions under a user name that is defined as a user credential in VM manager for specific vCenter.
  2. Remove this user name.
  3. From vCenter, add the user name back with read-only or propagation authorities.
  4. Redefine the VM manager entry for this specific vCenter using the same user name credential.
Specification of the domain for the user name for VM Managers is inconsistent.
Different definitions of users are used for each type of VM manager:
  • 9.2.12 For Citrix Hypervisor (formerly XenServer), the user is defined as user_name, for example root.
  • For Microsoft Hyper-V or Azure Stack HCI, you must use the Administrator account. The user is defined as user_name\domain or user_name@domain. For example, test\cluster.com or test@cluster.com.
  • 9.2.17 For Nutanix, the user is defined as user_name, for example: test.
  • 9.2.25 For Oracle Linux Virtualization Manager the user is defined as user_name@domain, for example: test@cluster.com.
  • For RHV-M, the user is defined as user_name@domain, for example: test@cluster.com.
  • For VMware, the user is defined as domain\user_name, for example: cluster.com\test.
Changes to the VM managers are not updated on the BigFix® server - applicable for central VM Manager Tool.
Changes to the VM managers are not updated on the BigFix server and the following error message is displayed in the VM Managers panel: The last modification of VM managers was not processed correctly on the BigFix server. The data is not synchronized with the VM Manager Tool.
To solve the problem, make sure that the VM Manager Tool is installed. You can also check the history of the Configure VM Manager Tool action in the BigFix console to investigate the failed step. Additional information can also be found in the BigFix console log files that are in one of the following directories:
  • /var/opt/BES Client/__BESData/__Global/Logs
  • C:\Program Files (x86)\BigFix Enterprise\BES Client\__BESData\__Global\Logs
The connection test does not finish - applicable for central VM Manager Tool
See the solution for: Data from VM managers is not updated on the BigFix server.
Connection to Hyper-V fails with the following error: The RPC server is unavailable.
Ensure that port 135 as well as all Windows dynamic ports are open for communication.
Data from VM managers is not updated on the BigFix server - applicable for central VM Manager Tool.
If you run a connection test for a VM manager and it does not finish, it might indicate a problem with the BigFix client that is installed on the BigFix server. If the client is stopped, actions that you perform in License Metric Tool are sent to the BigFix server but the status is marked as Not reported. To determine further actions, investigate the BigFix client that is installed on the BigFix server.

For the same reason, data from VM managers might not be uploaded to the BigFix server. Check the value in the Last Successful Operation column to verify if the data was recently sent to the server.

Actions that are performed in the VM Managers panel, such as testing the connection or adding a new VM manager, fail - applicable for central VM Manager Tool
If actions that you perform in the VM Managers panel fail, you can log in to the BigFix console that is linked to your primary data source and check the history of recent actions, such as Configure VM Manager Tool or VM Manager Tool - connection test. By doing so, you can investigate details of the failed step and determine the solution. If you are not sure which data source to connect to, log in to License Metric Tool and click Management > Data Sources.
To check the history of recent actions, complete the following steps:
  1. Log in to the BigFix console that is linked to your primary data source.
  2. In the navigation tree, click Computers.
  3. In the upper-right pane, select the computer that is defined as your primary data source.
  4. In the lower-right pane, click the Action History tab.
  5. Double-click on one of the recent actions that failed:
    • If the connection test was unsuccessful, check the VM Manager Tool - connection test action.
    • If modification of VM managers failed, check the Configure VM Manager Tool action.
  6. In the new window, click the Computers tab.
  7. Double-click on the action.
  8. Locate the failed step and check the details.
The VM Managers panel is blocked or contains error messages - applicable for central VM Manager Tool
The VM Managers panel is either blocked completely, with no possibility of performing any actions, or it contains one of the error messages that instruct you to install the VM Manager Tool or the BigFix services.
To solve the problem, complete the following steps:
  • Ensure that the BigFix server and client are installed on the target endpoint.
  • Install and start Web Reports on the BigFix server. For more information, see: Installing the Web Reports.
  • Subscribe the BigFix server to the IBM License Reporting (ILMT) v9 site.
  • Make sure that the content of the IBM License Reporting (ILMT) v9 site is up-to-date. If your computer does not have access to the Internet, see: Downloading files in an air-gapped environment.
  • Subscribe the target endpoint to the IBM License Reporting (ILMT) v9 site.
  • Make sure that the VM Manager Tool is installed. For more information, see: Installing the VM Manager Tool.
CPU frequency that is displayed on the Hardware Inventory report equals zero
CPU frequency is an additional parameter. It is retrieved only from computers that are not managed by VM managers or from virtual machines that are not in the OK status. CPU frequency values do not influence PVU calculations.
Virtual machines that are managed by the VMware vCloud Director have duplicate BIOS UUIDs.
The problem occurs when virtual machines are deployed from catalog templates. To work around the problem, see: BIOS UUIDs in vCloud Director are not unique when virtual machines are deployed from catalog templates (2002506).
The Hardware Inventory report in License Metric Tool displays No Scan Data after capacity scans were run on VMware guest operating systems.
The import log contains multiple occurrences of the following errors.
Some error occured during importing the capacity scan from file : 
capacity_scan_file_name.xml for endpoint : 
endpoint_number.
getNodeInfo Error: VMWare VirtualMachine UUID (06XZXA0) do not match with the UUID pattern!
In the scan files uploaded by the clients, the UUID tag contains the hosts serial number instead of the virtual machine UUID. Example:
<VirtualMachineGuest version="1">
           <UUID>06CZFCV</UUID>
           <HypervisorType>VMware</HypervisorType>
</VirtualMachineGuest>
License Metric Tool requires unique virtual machine UUID numbers to properly calculate the capacity for all virtual machines. This error might be caused by the host serial number appearing in the place where virtual machine UUID is normally recorded. If you install an operating system with the so-called Reseller Option Kit (ROK) media, some data might be obtained from the server BIOS, instead of from the virtual machine.
To enable the correct retrieval of UUID data from operating systems installed with the ROK media, edit the virtual machine's .vmx file and set the reflectHost parameter to false. Example:
SMBIOS.reflectHost = "false"
If the problem persists, force the upload of capacity scan data. To do this, perform the following steps.
  1. Log in to the BigFix console.
  2. In the navigation tree, go to Fixlets and Tasks and select the Run Capacity Scan and Upload Results fixlet.
  3. In the lower pane, click Take Action, and choose Click here to run a single capacity scan and force upload of results.
  4. Open the Target tab and select the computers that you want to scan. Then, click OK.
  5. Wait for the scheduled import, or run it manually.
Data on the Hardware Inventory report is outdated.
The problem might occur when the import of capacity scan data fails. To solve the problem, perform the following steps:
  1. Log in to the BigFix console.
  2. In the navigation tree, go to Fixlets and Tasks and select the Run Capacity Scan and Upload Results fixlet.
  3. In the lower pane, click Take Action, and choose Click here to run a single capacity scan and force upload of results.
  4. Open the Target tab and select the computers that you want to scan. Then, click OK.
  5. Wait for the scheduled import, or run it manually.
When the scan finishes, its results are uploaded to the BigFix server. After the data is imported to License Metric Tool, the Hardware Inventory report should be up-to-date.

In case of computers on which the disconnected scanner is installed, ensure that capacity scans are running and that their results are uploaded to the disconnected data source. For more information, see: Running software scans and gathering scan results (disconnected scenario), and Setting up daily transfer of scan results to the License Metric Tool server (disconnected scenario).

The Hardware Inventory report displays no Processor Brand String data.
The problem might occur after the migration, or upgrade. To see the Processor Brand String data on the report, force the upload of capacity data by completing the following steps.
  1. Log in to the BigFix console.
  2. In the navigation tree, go to Fixlets and Tasks and select the Run Capacity Scan and Upload Results fixlet.
  3. In the lower pane, click Take Action, and choose Click here to run a single capacity scan and force upload of results.
  4. Open the Target tab and select the computers that you want to scan. Then, click OK.
  5. Wait for the scheduled import, or run it manually.

In case of computers on which the disconnected scanner is installed, ensure that capacity scans are running and that their results are uploaded to the disconnected data source. For more information, see: Running software scans and gathering scan results (disconnected scenario), and Setting up daily transfer of scan results to the License Metric Tool server (disconnected scenario).

Type of the public cloud cannot be set to None from the License Metric Tool user interface.
The problem occurs on x86 public clouds when the same type of the public cloud is marked both by using the fixlet and from the user interface. To solve the problem, perform the following steps.
  1. Ensure that you have the latest version of the IBM License Reporting (ILMT) v9 fixlet site available in your BigFix console. For more information, see: Updating the fixlet site.
  2. Stop the Run Capacity Scan and Upload Results (<site_number>) action that is currently running.
    1. In the BigFix console, go to Actions.
    2. Right-click the action Run Capacity Scan and Upload Results (<site_number>), and click Stop Action. Then, click OK.
  3. Start the Run Capacity Scan and Upload Results (<site_number>) action by using the latest version of the fixlet.
    1. In the BigFix console, go to Sites > External Sites > IBM License Reporting (ILMT) v9 > Fixlets and Tasks.
    2. In the upper-right pane, select Run Capacity Scan and Upload Results, and click Take Action. Then, click Click here to schedule regular capacity scans and uploads of results.
    3. Select all computers on which you want to run this action, and click OK.
After new scan results are uploaded to License Metric Tool, you can mark the public cloud as None from the License Metric Tool user interface.