A.0 Troubleshooting

This section provide solutions to the issues you might encounter when using Novell PlateSpin Recon:

Refresh Inventory or Monitoring fails for a machine whose operating system has been reformatted

Source: PlateSpin Recon; Inventory and Monitoring.
Explanation: If you reformat the operating system of a machine after it has been inventoried, the Refresh Inventory or Monitoring for the machine fails.
Possible Cause: The credentials and the monitoring plug-in associated with the machine correspond to the original operating system.
Action: Perform the following tasks in the Data Center Explorer of the PlateSpin Recon Client:
  1. Delete the existing object of the machine whose operating system has been reformatted.

  2. Inventory or monitor the machine.

    For more information on how to inventory or monitor a machine, see Section 3.2, Discovering and Inventorying Data Center Resources.

Disk partitions for Citrix XenServer are not displayed

Source: PlateSpin Recon; Inventory.
Explanation: The disk partitions of an inventoried Citrix XenServer are not displayed in the Storage tab of the Properties page of the server.
Possible Cause: Citrix XenServer is formatted in to logical volumes by default and not in to partitions. PlateSpin Recon currently does not have LVM inventorying and reporting capability.
Action: None.

PlateSpin Recon fails to inventory the FC SAN disk connected to a Citrix XenServer 4.0 machine

Source: PlateSpin Recon; Inventory.
Explanation: PlateSpin Recon does not inventory the FC SAN disk attached to a Citrix XenServer 4.0 machine. Consequently, the disk is not displayed in the Storage tab of the Properties page of Citrix XenServer.
Possible Cause: PlateSpin Recon does not have supported operating system commands and Xen APIs to identify FC SAN Disk.
Action: None.

Inventory of Solaris or Linux machines might fail with an error

Source: PlateSpin Recon; Inventory.
Explanation: The inventory of a Solaris or Linux machine might fail with an error
Possible Cause: The /tmp directory on the Solaris or Linux machine does not have sufficient free space.
Action: Before inventorying a Solaris or Linux machine, ensure that the /tmp directory on the machine has a minimum of 50 MB of free space.

Disk IO metrics are not available for ESX 3.0

Source: PlateSpin Recon.
Explanation: The Disk IO% counter is not displayed for ESX 3.0 in the Chart Viewer.
Possible Cause: ESX 3.0 does not support the required counters used in the calculation of Disk IO%.
Action: None.

The Queue Length metrics are not collected for Virtual Center and ESX

Source: PlateSpin Recon; Monitoring.
Explanation: The QueueLength metrics are not collected for any type of storage volumes (local or shared) for ESX monitored directly or through vCenter.
Possible Cause: Virtual Center and ESX do not support the required counters for the QueueLength metrics.
Action: None.

Monitoring a Windows machine fails with an error related to access to the registry keys

Source: PlateSpin Recon; Monitoring.
Explanation: When monitoring a Windows machine fails, the monitor log contains the following error:
Access to the registry key key_number is denied.
Possible Cause: The registry key is being read by some other application at the same time.
Action: Ignore the errors. PlateSpin Recon automatically collects the data after the registry key is released by the other application.

Disk partition counters report errors for the AIX machines

Source: PlateSpin Recon; Monitoring.
Explanation: The data is not collected for the following counters for the AIX machines:
  • PhysicalDisk_PartitionedSpaceGB

  • PhysicalDisk_UnpartitionedSpaceGB

  • PhysicalDisk_PercentPartitionedSpace

  • PhysicalDisk_PercentUnpartitionedSpace counters

Additionally, a warning message is displayed in the logs. The warning message also includes the solution for the issue.

Possible Cause: PlateSpin Recon internally uses the lspv command to fetch the disk partition counters for AIX. When the command is run on an AIX machine, the machine might hang or slow down. This is a known issue with AIX.
Action: Perform the tasks as suggested in the warning message.

The loop7 partitions of Citrix XenServer are inventoried and monitored as a new disk

Source: PlateSpin Recon; Inventory and Monitoring
Explanation: When you mount the XenServer tools ISO to the DVD drive at /dev/xvd on a VM of a Citrix XenServer host to install the XenServer tools, the Citrix XenServer host creates a disk partition with the same size as that of the mounted ISO. When you inventory or monitor the Citrix XenServer, PlateSpin Recon considers the disk partition as a new disk, and reports it as loop7 in the machine properties and charts.
Action: None.

Unable to detect the processor model for a Windows operating system installed on Connoi hardware

Source: PlateSpin Recon; Inventory and Monitoring.
Action: None.

Issues when attempting to add servers to the PlateSpin Recon Inventory

Source: PlateSpin Recon; Inventory.
Explanation: You might encounter issues when attempting to add servers to the PlateSpin Recon Inventory, including the following error messages:
Network Path Not found 
Access Denied
The RPC Server is unavailable
Failed. The Network location cannot be reached
Action: Refer to Knowledge Base article Q7920525: Troubleshooting problems when adding servers to the PlateSpin Recon Inventory.

Importing a machine from PlateSpin Recon snapshot fails

Source: PlateSpin Recon; Snapshots.
Explanation: When attempting to import a machine from a PlateSpin Recon snapshot, you might encounter the following error message:
Cannot import MachineObject 'MACHINE-NAME [MACHINE-NAME]' 
Action: Refer to Knowledge Base article Q7920900: Cannot import MachineObject error when importing a machine from a snapshot.

A warning message is logged in the monitoring log while monitoring the Windows XP machines

Source: PlateSpin Recon; Monitoring.
Explanation: While monitoring a Windows XP machine, the following warning is logged in the monitoring log:
The interface is unknown counter_name.
Possible Cause: The Remote Registry service is in the Stop state on the target Windows machine that is being monitored.

Monitoring of data collection for the newly added disks or volumes is delayed for Windows machines

Source: PlateSpin Recon; Monitoring.
Explanation: If you add a new disk or a volume to a Windows machine that is being monitored, the data of the new disk or volume is not immediately collected and reflected in the PlateSpin Recon charts.
Possible Cause: PlateSpin Recon reports the data for only the disks and volumes that exists on the target Windows machine when you perform Start Monitoring on the machine.
Action: Stop and restart the monitoring of the Windows machine to which you have added a new disk or volume:
  1. In the Data Center Explorer, navigate to target Windows machine.

  2. Right-click the target machine, then click Stop Monitoring.

  3. Right-click the target machine again, then click Start Monitoring.

The data for the counters related to disk utilization might not be collected for Solaris servers

Source: PlateSpin Recon; Monitoring.
Possible Cause: The external disks connected to the Solaris machine are not labeled.
Action: Assign a label to the connected disks on the Solaris machine.

The data of a few disk counters for the disconnected disks on Solaris is incorrectly displayed

Source: PlateSpin Recon; Monitoring.
Explanation: The data of the following counters for the disconnected disks on a Solaris machine is incorrectly displayed as zero (0):
  • DiskBytesPerSecond

  • DiskAverageQueueLength

  • DiskTransfersPerSecond

  • DiskPercentIdleTime

  • Disk IO%

Possible Cause: The external disks are not properly disconnected.
Action: Clean the file system on the Solaris machine in one of the following ways:
  • Run the devfsadm -C command.

  • Reboot the machine.

Monitoring of a Windows machine might fail

Source: PlateSpin Recon; Monitoring.
Explanation: When monitoring of a Windows machine fails, the following error message is logged in the monitoring logs:
The network path was not found
Possible Cause: Unable to access the Windows machine as a network-shared resource.
Action: Enable the network shared resource on the Windows machine.
Possible Cause: The Remote Registry service is not running on the target Windows machine.
Action: Manually start the Remote Registry service on the Windows machine.

Generating of the Disk Analysis report or the raters based on disk usage for Windows machines might fail

Source: PlateSpin Recon; Monitoring.
Explanation: Generating of the Disk Analysis report or the raters based on disk usage for Windows machines might fail with the following message that is logged in the monitoring logs:
The component Disk Space Used(GB) does not have enough hourly summary data for the machine IP_address. 
Possible Cause: The target Windows machine does not have the Disk Utilization add-on deployed.
Action: Do the following:
  1. Deploy the Disk Utilization add-on on the target Windows machine.

    For more information about deploying the Disk Utilization add-on, see Section 3.12, Collecting Disk Utilization Counters for Windows Machines.

  2. Monitor the Windows machine for a minimum duration of one hour.

  3. Generate the Disk Analysis report or the rater.

Monitoring of a Windows machine displays the “Category does not exist” error in the monitoring log

Source: PlateSpin Recon; Monitoring.
Possible Cause: After performing the Undeploy Add-On task on the Windows machine, you did not restart monitoring on the machine by performing Stop Monitoring and Start Monitoring actions.
Action: Restart monitoring on the Windows machine by first performing the Stop Monitoring action, and subsequently the Start Monitoring action.
Possible Cause: The Windows Disk Counters Add-On is manually undeployed from the machine and not through the Undeploy Add-On option in the Recon PlateSpin Client.
Action: Do the following in the PlateSpin Recon Client:
  1. Right-click the Windows machine object on which you have manually undeployed the Windows Disk Counters Add-On.

  2. Click Undeploy Add-On.

  3. Right-click the Windows machine object.

  4. Click Stop Monitoring.

  5. Right-click the Windows machine object.

  6. Click Start Monitoring.

Possible Cause: When you run the following command on the PlateSpin Recon server, it results in system errors.

net view \\IPaddress_of_remote_machine

Action: To troubleshoot the system errors, see the Microsoft Knowledge Base articles appropriate to the system error code.
Possible Cause: Data collection from the PlateSpin Recon option, Windows Disk Counters Add-On, has been disabled by perfmon.
Action: Do the following on the Windows machine:
  1. In the Registry Editor, navigate to HKLM\SYSTEM\CurrentControlSet\Services\ReconWinMonitoring\Performance.

  2. Change the value of the registry key Disable Performance Counters to 0.

  3. Restart the Remote Registry service.

Possible Cause: Perfmon of the target Windows machine is corrupted.
Possible Cause: The event logs of the target windows machine show Perflib errors with event id 1015.
Event ID 1015 Source Perflib
Event ID 1015 
Source Perflib 
Type Error 
Description The timeout waiting for the performance data collection function"<function name>" in the "<dll name>" Library to finish has expired. There may be a problem with this extensible counter or the service it is collecting data from or the system may have been very busy when this call was attempted.
Action: By default, the system uses the same collect timeout period of 10 seconds for all services. Override the period for an failing service:
  1. In the Registry Editor, navigate to HKLM\SYSTEM\CurrentControlSet\Services\<service-name>\Performance.

  2. Increase the value of Collect Timeout.

  3. Restart the Remote Registry service.

Possible Cause: You do not have sufficient privileges to read the perfmon counters on the remote Windows machine.
Action: Request the administrator of the remote machine to grant you sufficient privileges to read the perfmon counters through the following User Rights policies: Profile System Performance and Profile a Single Process.
Possible Cause: While configuring the deployment of the Windows Disk Counters add-on, you chose not to select the Automatically restart the services which are dependent on the Remote Registry Service check box but you did not manually restart the Remote Registry service and the services that are dependent on the Remote Registry service after the add-on was deployed.
Action: On the target Windows machine where you deployed the Windows Disk Counters add-on, manually restart the Remote Registry service and its dependent services.

W3P Service consumes high memory or is terminated with system memory out of exception

Source: PlateSpin Recon.
Possible Cause: If the PlateSpin Recon Client is open without being used for more than 48 hours, the W3P service caches data for the Recon client session and this results in the W3P Service out of memory.
Action: If the W3P service is terminated, close the PlateSpin Recon Client, start the W3P service, then launch the PlateSpin Recon Client.
Action: If the W3P service is not terminated but the W3P service memory consumption is high, relaunch the PlateSpin Recon Client.

Disk Space % in scenarios is shown as 0 even though Disk Space (GB) has a value when you view the chart for a workload

Source: PlateSpin Recon.
Explanation: If you select a server template that has unlimited total disk space to create a scenario, the following are the known behaviors:
  • The chart for the Disk Space (%) utilization, viewed on the server template and the assigned workloads to that template, always shows zero (0) for y.

  • The workload assignment report on the server template shows empty (--) values for the Disk Used (%) column.

Action: None.

Monitoring of a virtual machine that runs on a Windows 2008 SP1 Hyper-V displays an error for the % Total Run Time counter

Source: PlateSpin Recon; Monitoring.
Explanation: Monitoring of a virtual machine that runs on a Windows 2008 SP1 Hyper-V reports the following error message for the % Total Run Time counter in the monitoring logs for the node:
Cannot get instance information for counter % Total Run Time in category Hyper-V Hypervisor Virtual Processor on computer w2k8vm204
Possible Cause: The data collection for the % Total Run Time counter, which is listed in the Hyper-VHypervisor Virtual Processor counter category, causes the error because the Microsoft Performance Library API does not work as expected.
Action: None.

Monitoring of a Windows virtual machine that runs on a Citrix XEN server might displays an error for the Xen_NetworkInterface_BytesTotalPerSecond and Xen_PhysicalDisk_DiskBytesPerSecond counters

Source: PlateSpin Recon; Monitoring.
Explanation: When you monitor a Windows virtual machine that runs on a Citrix XEN server, you might encounter the following issues:
  • The HANDLE_INVALID exception when monitoring the following counters:

    • Xen_NetworkInterface_BytesTotalPerSecond

    • Xen_PhysicalDisk_DiskBytesPerSecond.

  • The data is not collected for the Xen_Processor_PercentProcessorTime counter even though there is no exception.

Possible Cause: The XEN API does not work as expected.
Action: None.

Deploying or undeploying of the Windows Disk Counters add-on fails if you select to perform it on Windows Server 2008 SP2 Hyper-V host and its guest virtual machine

Source: PlateSpin Recon; Deploying or Undeploying of Windows Disk Counters.
Possible Cause: The deployment or undeployment of the Windows Disk Counters add-on on a Windows host internally triggers the deployment or undeployment action for its Windows virtual machines also. When you simultaneously select Windows host and its Windows virtual machines as deployment or undeployment candidates, two deployment or undeployment jobs are triggered for the Windows virtual machines and this might result in an error.
Action: Deployment or undeployment of the Windows Disk Counters add-on must be performed separately for the host machine and the guest virtual machine.

Unable to generate Cost allocation report with Allocation rater

Source: PlateSpin Recon; Reports.
Possible Cause: For Allocation rater, charge represents the total cost of a virtual machine server resource. It requires the host machine of the virtual machine to be inventoried and monitored. If the host machine is not inventoried and monitored, the Cost Allocation report displays the following generic error message:
Error was encountered during calculation for chargeback.

All the appropriate warning messages are logged in the Cost Allocation report’s job log file located in the Recon_server_installation_directory\logs\workflow directory.

Action: Inventory and monitor the host machine of the virtual machine.

Monitoring of a Linux machine by using sudo user credentials might fail

Source: PlateSpin Recon; Monitoring.
Explanation: Monitoring of a Linux machine by using sudo user credentials might fail with the following error message:
sudo: sorry, you must have a tty to run sudo
Possible Cause: The /etc/sudoers configuration file on the target machine contains the Defaults requiretty setting.
Action: Do the following:
  1. At the Linux console prompt, execute visudo.

    This opens the /etc/sudoers configuration file in the vi editor.

  2. Comment out the following line:

    Defaults requiretty
    
  3. In the Data Center Explorer view of Recon PlateSpin Client, right click the Linux machine, then click Stop Monitoring.

  4. Right-click the Linux machine, then click Start Monitoring.

The value of HyperV_NetworkInterface_BytesTotalPerSecond is incorrect for virtual machines that are configured to a legacy network adapter and run on Windows Server 2008 SP1/SP2/R2 Hyper-V host

Source: PlateSpin Recon; Monitoring.
Explanation: If a virtual machine is configured with a legacy network adapter and runs on Windows Server 2008 SP1/SP2/R2 Hyper-V host, the data for the HyperV_NetworkInterface_BytesTotalPerSecond counters is incorrectly displayed as zero (0).
Possible Cause: The Microsoft Performance Library API does not work as expected for the Bytes Received/sec or Bytes Sent/sec counters of the HyperV_NetworkInterface_BytesTotalPerSecond category on HyperV servers.
Action: None.

Restarting of Remote Registry service after deployment or undeployment of the Windows Disk Counters Add-On fails with errors

Source: PlateSpin Recon; Deployment or undeployment of Windows Disk Counters Add-On.
Explanation: When you deploy or undeploy the Windows Disk Counters add-on, the Remote Registry service is automatically restarted on the target machine. The service restart process might fail with errors. The error messages are displayed in the job.log.
Action: If any error is reported while restarting Remote Registry service after deploying or undeploying the Windows Disk Counters add-on, you must undeploy the Disk Performance counters DLL from the target machine perfmon:
  1. On the target machine, open the Registry Editor.

  2. Navigate to the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ReconWinMonitoring key. If the key exists, it indicates that the %SystemRoot%\PlateSpinRecon-DiskUtil directory exists. Do the following:

    1. From the command prompt of the target machine, go to %systemroot%\PlateSpinRecon-DiskUtil.

    2. Execute the following command:

      HWInputMon.exe -Uninstall false

    3. Delete the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ReconWinMonitoring key.

    4. Delete the %SystemRoot%\PlateSpinRecon-DiskUtil directory.

The deployment or undeployment of the Windows Disk Counters add-on might result in the error, “The process cannot access the file because it is being used by another process”

Source: PlateSpin Recon; Deployment or undeployment of Windows Disk Counters Add-On.
Explanation: If the Windows virtual machines are directly listed in the group and are as well as listed under the Citrix XenServer or Virtual Center host machines included in the same group, deployment or undeployment of the Windows Disk Counters add-on on a group might result in the following error:
The process cannot access the file because it is being used by another process
Possible Cause: The Windows virtual machines directly receive the Windows Disk Counters add-on deployment or undeployment job from the group and also from the Citrix XenServer or Virtual Center host. In this scenario, one of the jobs succeed and the other one fails.
Action: Ignore the error because the Windows Disk Counters add-on is successfully deployed or undeployed on the Windows virtual machine through the job that has succeeded.

Refresh Inventory and Monitoring of machines inventoried by using the CSV file might fail

Source: PlateSpin Recon; Inventory.
Possible Cause: If you inventory and monitor machines by using a CSV file, the credential description that you specify in the file must be unique for the machines that contain username and password. If the credential description is not unique, then incorrect credentials might be assigned to a few machines and consequently refresh inventory and monitoring actions on those machines fail.
Action: Before you inventory and monitor machines by using a CSV file, ensure that the credential description specified in the CSV file is unique for the machines that contain username and password.
Action: If you have already inventoried machines by using an incorrect CSV file, do one of the following:
  • Delete the problematic machines from the PlateSpin Recon Client, specify a unique credential description for the machines listed in the CSV file, then inventory the machines again.

  • Attach the correct credentials to the problematic machines.

    1. In the Data Center Explorer, right-click the problematic machine, then click Attach Credentials.

      The Attach Credentials dialog box is displayed.

    2. Specify the credentials for the machine, then click OK.

Performing Stop Monitoring and Start Monitoring jobs in immediate successions on a large set of UNIX machines might result in an error

Source: PlateSpin Recon; Monitoring.
Explanation: If you perform Stop Monitoring and Start Monitoring in immediate successions on a large set of UNIX machines, the monitoring scripts (*.sh) might not exist on the target UNIX machines and the following error message is displayed in the Job Explorer:
/bin/sh: ./lininfo.shSLESPlateSpinRecon_server_name: No such file or directory counter_name
Possible Cause: When you initiate the Stop Monitoring job on a large set of UNIX machines, the job might take considerable time to remove the monitoring scripts (*.sh) from the target machines even though the status of the job is displayed as completed in the Job Explorer. If you immediately initiate the Start Monitoring job for these machines, the monitoring data collection might fail because the monitoring scripts (*.sh) required to monitor the machines might also be incorrectly removed by the previous Stop Monitoring job.
Action: Stop and start monitoring the problematic machines.

PlateSpin Recon Client might incorrectly display the status of a job as running even after the job has been completed

Source: PlateSpin Recon; Inventory and Monitoring.
Explanation: PlateSpin Recon Client might fail to update the status of a job and would constantly display the status as Running even after the job is completed.
Action: Close the PlateSpin Recon Client, and relaunch it.

Stopping of the PlateSpin Recon Monitoring service might take considerable time or restarting of the PlateSpin Recon Monitoring service might fail

Source: PlateSpin Recon
Possible Cause: When you try to stop the PlateSpin Recon Monitoring service, the service commits all cached data in to the database. This process might take 10 to 15 minutes. During this period, the Stop action for the service might appear to be unresponsive.

When you try to restart the PlateSpin Recon Monitoring service, the service might fail to restart because the restart process first tries to stop the service, which takes considerable time to complete.

Action: If you had initiated the stop action for the PlateSpin Recon Monitoring service, you do not need to do anything because the service becomes responsive after 10 to 15 minutes and is subsequently stopped.

If you had initiated the restart action for the PlateSpin Recon Monitoring service, you must start the service after it becomes responsive (the service actions are available for selection).

WARNING:You must not try to terminate the PlateSpin Recon Monitoring Service process because it might lead to data inconsistency.

Logs Explorer might display the warning, “Client data may be out of date”

Source: PlateSpin Recon Client.
Explanation: If the PlateSpin Recon Client is open for a considerable time, the following warning is displayed in the Logs Explorer of the PlateSpin Recon Client:
Client data may be out of date.
Possible Cause: The Web service session that is established on launching the PlateSpin Recon client has expired.
Action: Close the current instance of the PlateSpin Recon Client and relaunch the client.

The PlateSpin Recon Monitoring service is terminated because of the out of memory exception

Source: PlateSpin Recon.
Possible Cause: PlateSpin Recon is monitoring a large number of unresponsive or unreachable machines.
Action: Stop monitoring the unresponsive or unreachable machines.

Loading of the PlateSpin Recon job from the Portability Suite might display a credential-specific error

Source: PlateSpin Recon; Portability Suite.
Explanation: Loading of the PlateSpin Recon job might fail with the following credential-specific error:
Unable to login to VMware Virtual Infrastructure
web... Please ensure that the username and password are correct.

The error is displayed in the PlateSpin Portability Suite.

Possible Cause: The password required to access the target ESX server has not been specified.
Action: Specify the password of the target ESX server by using the Portability Suite:
  1. In the Peer-to-Peer Conversion Job window, click the Job Configuration panel > the Credentials link.

  2. Specify the password.

  3. Click OK.

Inventory of Solaris machine fails

Source: PlateSpin Recon; Inventory
Possible Cause: The password of the Solaris machine contains special characters such as (
Action: Remove the special characters from the password of the Solaris machine.

Creating scenarios for forecasted projects might fail with the out of memory exception

Source: PlateSpin Recon; Scenarios and Projects.
Explanation: If you try to create a scenario from a project that consists of a large number of machines with a large number of forecast days, the process might fail with the out of memory exception.
Action: Reduce the number of machines or the forecast days in the project. For more information about the project and scenarios recommendations, see Section E.0, Best Practices.

Generating Analysis reports from the PostgreSQL database might take a considerable time

Source: PlateSpin Recon; Reports.
Action: Before generating Analysis reports from the PostgreSQL database, do the following:
  1. Open the PlateSpin.PowerRecon.Monitoring.Database.config file using a Text editor.

    The PlateSpin.PowerRecon.Monitoring.Database.config file is located in the PlateSpin_Recon_installation_directory\configs\ directory on the PlateSpin Recon Server.

  2. Change the value of Pooling to True.

  3. Restart the PlateSpin Recon Monitoring Service.

The storage type for disks attached to AIX machines is displayed as Unknown

Source: PlateSpin Recon.
Possible Cause: PlateSpin Recon currently does not support collecting of the storage type data for the disks attached to AIX machines. Hence, the storage type for disks attached to AIX machines is displayed as Unknown in the Properties page of the AIX machine (in the Storage tab > View by Disk view) and in the Reports.
Action: None.

Importing of a snapshot that contains Citrix Xen virtual machines fails

Source: PlateSpin Recon; Snapshots.
Explanation: If you try to import a snapshot that contains Citrix Xen virtual machines, the import operation might fail with the Stealthiest exception.
Possible Cause: You have inventoried first the Citrix Xen virtual machines and subsequently the Citrix Xen host before creating the snapshot of the machines.
Action: Before creating a snapshot with Citrix Xen virtual machines, you must follow one of the following inventory process:
  • Inventory the Citrix Xen virtual machines only without inventorying the host machine.

  • Inventory first the Citrix Xen host machine and subsequently the Citrix Xen virtual machines.

The operating system type for Windows 2003 R2 and Windows 2008 R2 devices is displayed as Unknown

Source: PlateSpin Recon.
Explanation: When you perform an inventory of Windows 2003 R2 and Windows 2008 R2 devices, the Inventory Summary report displays the Operating System type for these devices as Unknown.
Action: In the PlateSpin Recon Report Explorer, do the following:
  1. In Consolidation Project Samples, right-click Inventory Summary and select Edit Report Template.

    The Edit Report Template window is displayed.

  2. Navigate to the Views panel, select OS Summary view and click Edit.

    The Create View window is displayed.

  3. Click Customize.

    The Settings window is displayed.

  4. Add the required operating system to the list of operating systems and click OK.

    NOTE:Ensure that the Internal name you give to the operating system is either Windows 2003 R2 or Windows 2008 R2.

Monitoring Linux machines that are inventoried by using sudo user credentials throws a warning message

Source: PlateSpin Recon; Monitoring.
Explanation: When you monitor Linux machines (RHEL, SLES) that are inventoried by using sudo user credentials, a warning status indicator might overlay the machine icon and the following warning message is logged in the monitoring log:
root'''s password: Memory_AvailableBytes
Possible Cause: The impersonation context is not yet set.
Action: Ignore the warning message. The warning status indicator disappears as soon as the impersonation context is set.

Inventorying a host machine with VMs that are either migrated from other host machines or cloned across multiple host machines throws a warning message

Source: PlateSpin Recon; Monitoring.
Explanation: If you choose to inventory a host machine with VMs that have either been migrated from other host machines or are cloned across multiple host machines, then the inventory does not list the VMs that have duplicate SMBIOS UUID and logs a warning message. However, the machine icon does not display the warning status indicator. To view the following logged message, right-click the host machine and then click Logs > > View Logs:
Machine with HostName: [HostName] and MachineID: [MachineID] Skipped due to duplicate SMBIOSUUID of [SMBIOSUUID] is already present in the Host with HostName: [HostName] and HostMachineID: [HostMachineID]If the machine is Moved/Migrated from other Host to this Host then please do a refresh inventory on Host: [HostName] and then Refresh Inventory this Host again to identify/discover the VM associated with the present host. And if the machine is cloned across various host then please change the SMBIOSUUID in order to identify/discover the VM associated with the present host
 
Action: To enable the discovery of a VM during the inventory of its current host, do one of the following depending on whether the VM has been migrated or cloned:

Inventorying a VM that is cloned across multiple host machines might incorrectly associate the VM with a host machine to which it does not belong

Source: PlateSpin Recon; Monitoring.
Explanation: If you inventory a host machine (host1) having a VM that is cloned across multiple host machines and has a duplicate SMBIOS UUID, then inventory the cloned VM of a different host (host2) by IP address, the inventory incorrectly associates the cloned VM of host2 with host1.
Action: You must ensure that the cloned VMs have a unique SMBIOS UUID.

Refresh Inventorying a host machine having a cloned VM with a duplicate SMBIOS UUID throws a warning message

Source: PlateSpin Recon; Monitoring.
Explanation: If you inventory a host machine (host1) having a VM that is cloned across the same host machine or multiple host machines and has a duplicate SMBIOS UUID, then inventory the cloned VM by its IP address, followed by a refresh inventory of the host machine (host1), the refresh inventory continues by skipping the VM that has duplicate SMBIOS UUID and logs a warning message.
Action: You must ensure that the cloned VMs have a unique SMBIOS UUID.

Generating cost allocation report with allocation rater throws a warning message when VMs with duplicate SMBIOS UUID are inventoried before Inventorying the host machine

Source: PlateSpin Recon; Monitoring.
Explanation: Consider a host machine having VMs that are cloned across the same host machine or multiple host machines and have duplicate SMBIOS UUID. If you first inventory the cloned VMs by using its IP address followed by the inventory of the host machine, the cost Allocation report with Allocation rater displays the following warning message because it is unable to locate the respective cloned VM’s parent machine:
The rater [rater name] cannot be evaluated - could not find the
parent virtual server for the machine.
 
Action: You must ensure that the cloned virtual machines have a unique SMBIOS UUID.

Inventorying a host machine with VMs cloned within the same host machine throws a warning message

Source: PlateSpin Recon; Monitoring.
Explanation: If you choose to inventory a host machine (host1) with VMs that are cloned within the same host machine, the inventory of host1 does not list the cloned VMs and logs a warning message. However, the machine icon does not display the warning status indicator. To view the following logged message, right-click the host machine and then click Logs > > View Logs:
The machine with id:[MachineID] has been skipped because there are two or more virtual machines with the same SMBIOSUUID:[SMBIOSUUID] in the container. To discover all the virtual machines within the container, you must ensure that the virtual machines have unique SMBIOSUUID
 
Action: You must ensure that the cloned VMs have a unique SMBIOS UUID.

Inventorying a host machine with VMs shared across multiple host machines throws a warning message

Source: PlateSpin Recon; Monitoring.
Explanation: If you choose to inventory a host machine (host1) with VMs that are shared across one or more host machines that have already been inventoried, the inventory of host1 does not list the shared VMs (because the shared VMs were already listed during the inventory of the other host machines) and logs a warning message. However, the machine icon does not display the warning status indicator. To view the following logged message, right-click the host machine and then click Logs > > View Logs:
Machine with HostName: [HostName] and MachineID: [MachineId] Skipped due to duplicate SMBIOSUUID of [SMBIOSUUID] is already present in Recon DB. Possible Reason might be it is shared VM across Host.If it is a shared VM it will only be associated with a single Host.
 
Action: None.

Generating Virtual Infrastructure report for a group generates reports for all the nodes in the Data Center Explorer of the Recon server

Source: PlateSpin Recon; Monitoring.
Explanation: If you choose to generate Virtual Infrastructure report for a group, the report is actually generated for all the nodes in the Data Center Explorer of the Recon server.
Action: Modify the group to associate it with a custom bin and then generate the report for this group. Based on the specified bin, the report is created in segments and you can use the report segment associated with this group. For more information on modifying the group to associate it with a bin, see Adding or Modifying Groups.

The operating system type for OES VM is incorrectly displayed in the VM Details Report

Source: PlateSpin Recon.
Explanation: When you inventory an ESX server that has OES VMs, the VM Details report displays the Operating System type for OES VMs as follows:
  • For 32-bit OES VM: SUSE

  • For 64-bit OES VM: Unknown

Action: None.