vmware (VMware Monitoring) Release Notes

This section contains the Release Notes for all versions of the VMware Monitoring (vmware) probe.
This section contains the Release Notes for all versions of the VMware Monitoring (vmware) probe.
Revision History
This section describes the history of the probe updates.
What's New:
  • Certified the probe to monitor VMware vSphere 7.0 environment.
November 2020
What's New:
  • Added custom properties to the VMware probe inventory elements to support publishing of Inventory Topology and relationships between VMware objects: Resource Pools to Datacenters
  • Added a key in Raw Configuration to define the DNS Name or short name as the device name.
  • Introduced the Auto Filter section for the datastore component in the new and default factory templates in Administration Console. For more information about how to use Auto Filter for older templates of the datastore component, see the
    (Optional) Using Filters
    topic in vmware AC Apply Monitoring with Templates.
Fixed Defects:
  • Fixed an issue where after upgrading to vmware 7.11 the discovery queue was growing continuously. (
    Support Case 01188309
  • Fixed an issue where after upgrading to vmware 7.11 the
    Monitors Included in Template
    section is blank and a large number of
    failed to collect data for...
    errors were generated.
    Support Case 01184595
  • Fixed an issue where the vmware probe was unable to monitor a vCenter version 6.7.0. (
    Support Cases: 01204155, 01239412, 01193497, 01254703)
  • Fixed an issue where the probe was sending
    Attempt to add vertex that already exist
    errors. (
    Support Cases: 01229015, 01244295, 01292418)
March 2019
What's New:
Added custom properties to the VMware probe inventory elements to support publishing of Inventory Topology and relationships between VMware objects:
  • Resource Pools to Clusters
  • Resource Pools to Hosts
January 2019
What's New:
  • Added support for vSphere 6.7 suite.
  • Probe supports TLS 1.2/1.1/1.0 for communicating with vCenter. By default, the probe will start communicating with TLS 1.2 and try to connect with the vCenter, stepping down with each test until it finds a connection path it can use. For more information see Installation Considerations.
  • Supports suppression of alarms and QOS metrics publishing for hosts that are on maintenance mode. For more information, see Disable alarms and QoS from Host machines in maintenance mode.
  • The following enhancements are available with vmware v7.11 MCS template package. The template package is compatible only with CA UIM 9.0.2 release and above.
    For compatibility with CA UIM 8.51, where vmware probe is configured using MCS, we recommend that you upgrade only the vmware probe v7.11, and continue to use the vmware v6.82 MCS templates. For more information see known issue.
      • Enhanced profiles that enable you to configure metrics, baselines, alarm thresholds, alarms - including Time Over Threshold alarms - and custom alarm and close alarm messages, all within a single MCS profile.
      • Additional inventory parameters have been added to enhance and improve dynamic and static group creation in USM.
      • Ability to monitor a VCenter but exclude certain VMs to be discovered by vmware Probe.
  • The following metrics have been deprecated from their applicable monitors in 7.11.1 (Legacy) and 7.11.2 (Enhanced) MCS templates.
    Network Packets Received
    Network Packets Transmitted
    You can view the following metrics instead:
    Network Packet Receive Rate
    Network Packet Transmit Rate
Fixed Defect:
  • Fixed an issue in the UIM-Spectrum integration, where devices were not modeled in the correct hierarchical containers and the resource pools were empty. (
    Support Case 01104617
  • Fixed an issue where a new alarm message added to vmware probe but is not available in Template Editor. (
    Support Case: 00962935
    ) A new callback was added.
  • Fixed an issue where vmware probe configuration having issues pulling data from Virtual Center. (
    Support Case
  • Fixed an issue where QOS metrics was missing for VMware Probe (
    Support Case
  • Fixed an issue where vmware probe randomly stops collecting QoS (
    Support Case 00855918
August 2018
Fixed Defects:
  • A
    DataGridView Default Error Dialog
    appeared after navigating to a VM host within a cluster and selecting
    Support Cases 00754934, 00786235, and  00789071
  • A problem where queue files could back up and not process caused users to have to manually delete the queue files. (
    Support Case 00738661
  • The probe published partial graphs when monitors or events changed on a monitored system resulted in excessive graph publishing (
    Support Case 00799774
  • Alarm-only monitors failed to report QoS definitions.
September 2017
Fixed Defects:
  • Fixed an issue where the vmware probe would not respond to the Infrastructure Management thick client when certain probe configurations were enabled.
  • Fixed an issue where the vmware probe did not publish QoS for some metrics when configured using MCS (
    Support Case 00783809
  • Fixed an issue where the vmware probe sometimes crashed when configured using MCS.
  • Fixed an issue where probe data collection is interrupted when VCenter presents an IPv6 address with a scope ID.
July 2017
Enhanced the documentation on the vmware AC Apply Monitoring with Templates page:
  • Added an FAQ
  • Improved the workflow diagram
  • Expanded the explanation of how template filters work
May 2017
What's New:
  • Added support for vSphere 6.5.
  • Partial graph publishing is enabled by default.
Fixed Defects:
  • Fixed an issue in which the probe generated false alarms related to disk latency.
    Support Case number
  • Fixed an issue in which the probe generated false self-monitoring alarms when an element was removed from the monitoring environment.
    For example, if you removed a CPU from a VM, then the VMWare API returned a "-1 (data not available)" performance metric for about an hour. When this happened, the vmware probe monitor, Computed Aggregated CPU monitors, reported incorrect values and then null values. The incorrect and null values resulted in the auto monitors configured on the Computed Aggregated CPU monitors to send self-monitoring alarms.
  • Fixed an issue where a monitor created against a string metric with no alarming enabled caused an issue with Capacity Manager.
March 2017
What's New:
  • Improved support of MCS templates.
February 2017
What's New:
  • Added support for metric configuration through Monitoring Configuration Service (MCS).
  • Added support for Microsoft .NET 4.X for the Infrastructure Manager UI.
  • Significantly reduced the volume of data in environments with frequent vMotion events. When you enable partial graph publishing for v6.8, the amount of data published in support of capturing vMotions is reduced to only what is necessary. 
Fixed Defects:
  • Fixed a defect in which the probe did not correctly update snapshotCount and snapshotSize metrics.
    Support Case numbers 00505053, 453749
  • Fixed a defect in which the Provisioned Space monitor failed without an alarm.
  • Fixed a defect in which the HostCpuUsage metric used MHz as a unit of measure instead of percentage as it was labeled.
  • Fixed a defect in which the capman_da (Capacity Management Data Adapter) probe was unable to read messages from the vmware probe v6.72 and later.
    Support Case number 00426964
  • Fixed an issue in which the Unified Dashboards version 3.05 included incorrect versions of the VMWare Unified Dashboards, which caused the Vblock Unified Dashboard to fail because the QoS targets were not correctly defined.
  • Fixed an issue in which the probe improperly categorized the published measurements displayed in USM. The fix eliminates both potential gaps in USM, and incorrectly cataloged measurements. These fixes are also observable in CABI.
    Support Case number
January 2017
What's New:
  • Added reporting of all secondary MAC and IP addresses for a VM that has VMware Tools installed.
  • Added documentation describing a work-around for a known issue. When you reconfigure a static monitor, the static monitor cache does not clear unless you deactivate and activate the probe.
    Support Case 00157751
  • Added documentation describing a work-around for a VMware known issue that causes the probe log file to display a performance metric collection error message.
  • Added support for vCenter 6.0u2.
Fixed Defects:
  • Fixed a document defect in the Software Requirements section, which stated incorrectly that Microsoft .NET framework must be installed on the same system as the probe. Install Microsoft .NET only if you are using Infrastructure Manager. Install Microsoft .NET only on the system that runs the Infrastructure Manager GUI. 
  • Fixed a defect in which the probe self-monitoring alarms did not clear when the cause of the alarm was resolved or when the probe was restarted.  
  • Fixed a defect in which template configuration changes made by the user in the Admin Console UI were not persisted by the probe.
    Support Case 00355985
  • Fixed a defect in which the probe returned null data for a VM hostname and host CPU usage.
May 2016
What's New:
  • Supports VMware vCenter and ESXi 6.0 Update 1.
  • Target strings are changed for host metrics of type HOST_SYSTEM. Target strings for HOST_SYSTEM are found under the System node on hosts and are named "host/system/kernel."  For example, the old target string was: "Resource CPU Usage in MHz (% of MHz*NumCpuCores)". The new target string is "host/system/kernel/Resource CPU Usage in MHz (% of MHz*NumCpuCores)." 
Fixed Defects:
  • Fixed an issue in which, if a message pool identification name included an underscore, the high and low threshold status display order was reversed.
    Salesforce case 00168994
  • Fixed an issue in which, if a metric was disabled in Infrastructure Manager, it was not disabled in Admin Console.
    Salesforce case 00169165
  • Fixed an issue in which the probe was inconsistent in which name it used to identify the source for a QoS message.
    Salesforce case 00170267
  • Fixed an issue in which, for certain alarms, the device ID incorrectly displayed as the default connector.
    Salesforce 00170025
  • Fixed an issue in which, for users with CA UIM v8.0-8.1, the Unified Dashboards for VMware were missing QoS that were collected by the probe
    . Salesforce case 00154590
  • Fixed an issue in which the probe did not send device ID in alerts through the CA UIM Connector for CA SOI.
    Salesforce case 00170025
  • Fixed an issue in which the template editor in Admin Console offered a superfluous option to apply a log level filter.
  • Fixed an issue in which the probe stopped generating QoS messages after running continuously for one day.
  • Fixed an issue in which a MissingTargetException occurred.
  • Fixed an issue in which, when running on a Windows 2008 server with a socket leak, the probe displayed the following error message: "Java.net.SocketException: No buffer space available."
  • Fixed an issue in which, when the user was using Japanese characters, the QoS source and target were garbled when they were stored in the database.
October 2015
What's New:
  • Added support to configure and apply all monitoring, manually or with templates, in Admin Console
  • Added documentation about how to format IPv6 addresses when used for a Uniform Resource Identifier (URI); use the Java convention of enclosing an IPv6 address in square brackets.
For more information, see the v6.5 vmware AC Configuration and v6.5 vmware IM Configuration Guides.
  • Added new monitors to the datastore resource:
    • number read averaged
    • number write averaged
    • number read rate
    • number write rate
  • Added the ability to monitor a datastore disk, including the following monitors:
    • number read averaged
    • number write averaged
    • number read rate
    • number write rate
  • Added the ability to monitor a datastore under a host, including the following monitors:
    • number read averaged
    • number write averaged
    • number read rate
    • number write rate
    • total read latency
    • total write latency
  • Added the ability to monitor a datastore under a VM, including the following monitors:
    • number read averaged
    • number write averaged
    • number read rate
    • number write rate
    • total read latency
    • total write latency
For more information about these metrics, see vmware Metrics.
Fixed Defects:
  • Fixed an issue in which QoS monitoring configurations were lost when the user password changed.
    Salesforce case 00162857
  • Fixed an issue in which delta values were incorrectly calculated.
  • Fixed an issue in which the numeric sensor monitor was not updating the power supply status.
    Salesforce case 00155626
  • Fixed an issue in which automonitors using the value average*n did not work.
    Salesforce case
    : Monitors of the enumerator type only support current values and cannot calculate delta values.
August 2015
What's New:
  • Added Admin Console GUI element: the Detached Configuration folder in the left-hand navigation tree for the probe displays resources that have been deleted in the VMware vSphere and which still have configuration in the probe.
  • Added monitoring of Distributed Virtual Port Groups and Switch.
  • Added support for monitoring the same vCenter with multiple credentials.
  • Added support for using non-English characters in the following fields: template name, template description, message name, message error text, message OK text, and alarm thresholds.
  • Enabled the probe to indicate to baseline_engine (or other probes performing a similar computational function) to compute baselines, publish QoS data to the message bus, and publish alarms when configured alarm threshold criteria is met.
  • Improved discovery time and HEAP memory usage.
Fixed Defects:
  • Fixed an issue in which, when using two user profiles with different permissions on the same ESXi host, incorrect credentials were set on both resources and both resources monitored the same set of objects from the vCenter.
    Salesforce case 00152061
  • Fixed an issue in which, when monitoring numeric sensors on ESXi hosts, the profile did not work and the tooltip displayed an "unable to connect" error message.
  • Fixed an issue in which, when monitoring QoS metric for host service availability, the service description was missing from the CI naming.
  • Fixed an issue in which internationalization (translation from English) caused the QoS source/target text to be garbled when it was stored in the database.
March 2015
Corrected an issue with value updates for HOST_SERVICE metrics.
Improved the loading time of All Monitors and Auto-monitors content in Infrastructure Manager GUI.
Improved monitor processing logic to reduce polling intervals.
Performance metrics are now visible in the GUI whether monitoring is enabled.
Reduced memory footprint by modifying internal representation of objects.
Reduced polling interval time by creating thread calls to collect vCenter performance metrics.
December 2014
Added support for migration to current release from 4.01 and forward.
All group names are localized in Probe Configuration.
Corrected an issue where non-clustered VMware server instances are falsely reported as a vCenter.
Fixed default messages that reported "memory" instead of "network."
Fixed incorrect QoS target name format for Guest Disks: QOS_DISK_FREE //Free (in % of Capacity) is correct; QOS_DISK_FREE GuestDisk///Free (in % of Capacity) was incorrect.
July 2014
Added requirements for VMware VirtualCenter 5.5 and VMware ESX/ESXi 5.5
Described appearance of VMs in USM.
Support for IPv6 environments.
Restored VMwareApiAvailable metric
March 2014
Fixed: Monitoring alarms on multiple vCenters could cause a collection failure.
December 2013
Performance enhancements
Support for VMware 5.5
Fixed: Provisioning VMs could cause spurious duplicate UUID alarms
Fixed: Expiration of the probe’s session with vCenter triggers spurious duplicate UUID alarms.
December 2013
Probe fails to detect new VMs on 5.1 update 1
Provisioning VMs trigger false duplicate UUID alarms
Monitors of 'average of last n' do not display values in 'All Monitors'
October 2013
Reintroduce source_is_ip support
Use a new method of event collection that works for all ESXi hosts.
Fix API response time calculation
Improve displayed error message when communication with the controller fails.
June 2013
Mouseover tool-tips on resource nodes to provide additional context
Fixed creation of devices visible to USM
May 2013
Rewritten backend and GUI
Alarm forwarding support
Storage Pod and Virtual App monitoring
Cluster VMotion monitoring
March 2013
Probe help button now accessing online help.
Performance metric auto-monitors are no longer created for entities missing the performance metric.
Memory and CPU performance metrics added to Resource Pools.
Corrections around the creation of Remote Device details for SOC niscache content.
Host Virtual Switch ports and available ports metrics added to Hosts entity.
Added (optional) support for including DataStore containing folders in the QoS Target.
Active Template highlighting during drag-and-drop fixed.
Template copy operation is now supported.
June 2012
Corrected Resource Pool QoS target strings for uniqueness.
Corrected Auto-Monitor wildcard instance QoS target strings.
Corrected QoS target string for Auto to Static Monitor conversions.
March 2012
Polling interval alarms are now cleared when the collection cycle takes less time than the configured interval.
Target string corrected for DS, Cluster, and Network auto-monitors created from static monitors.
Target string corrected to contain topology path for Resource Pools and Networks.
Corrected the robot dependencies setting in the VMware probe package.
Restored missing VM Memory usage metric in the inventory tree.
Corrected reported FM snapshot size.
Added supported for tracking VMs by instanceUUIDs for environment with duplicated UUIDs (e.g., Lab Manager & vCloud)
January 2012
Updated the UMP Metrics template to match the latest Dashboard content.
December 2011
Augment QoS source to optionally include origin for multi-tenant setups.
Fixed missing scenarios around converting auto monitor to static monitors.
Any static monitor now takes precedence over Auto-monitors.
November 2011
Added support for SOC management of Hosts, and VMs with VMTools installed.
Corrected target naming for Datastores contained within folders.
Fixed enabling of static monitors for the Top Level API monitors
October 2011
Fixed failures around calculation process for missing Network Metrics.
June 2011
Adjusted QoS entries in support OOB Dashboards.
June 2011
Fixed millisecond to percentage calculations for CPU performance metrics
June 2011
Fixed auto-monitor behavior around wildcarded monitors (e.g., Services, CPUs, CpuStatusInfo, Disks, etc.).
StorageStatusInfo, CpuStatusInfo, MemoryStatusInfo and NumericSensorInfo monitors how support wildcarding in auto-monitors and templates.
Probe allows for ESX hosts vNIC property to not be set.
May 2011
Status monitor supported for Network Switches.
Summary level monitors are supported for Clusters.
Top level disk latency is now reported as an average.
Booleans are converted to integers to enable QoS submittal.
Correcting CPU performance metrics to report in terms of per CPU Average
May 2011
Maintenance release that includes additional message types and QoS entries.
March 2011
Corrected target resolution process for submitted QoS and Alarm messages
March 2011
Probe start up process has been migrated to the standard controller mechanism.
Resource alarms are now sent for unavailable resources.
Additional CPU and Memory metrics.
Configuration UI and probe performance improvements.
Corrected the source for Resource Pool AutoMonitors.
Updated the UMP metrics template monitor Memory Grants.
Deleting all monitors via Applying Templates is no longer supported. Use the "all Monitors" section to select and delete all monitors. (e.g., select the first monitor, then use the CTL+SHIFT+END shortcut to select all, then finally use the context menu's delete to perform the delete).
Warning level Alarm is now emitted when the data collection time for a resource is greater than the polling interval.
The probe now substitutes calculated values for Network Metrics missing/unavailable on some ESX servers (e.g., latest EXSi 4.1 Servers). When substitute values are used, the probe logs a warning message in the log file.
Correct Source As IP behavior with Template deployed monitors.
March 2011
Fixed Event Monitors.
Updated the defaults for the VM Guest Memory Monitor.
Updated the UMP Metrics template monitors around Datastores and Guest Memory.
February 2011
Added support for pulling PowerState metric from Hosts.
Incorporated best match processing for handling name changes occurring with StorageStatusInfo, CpuStatusInfo, MemoryStatusInfo and NumericSensorInfo monitors. In cases where the probe has to perform a best match, the probe logs a warning message in the log file.
February 2011
Fixed enabling Datastore Monitors from Config UI's List View.
Templates can be used with Datastores with both Auto-Monitors and Monitors.
Enabled Drag-and-Drop of Templates to Datastores directly.
VMware API Auto-Monitors at the Resource level now work.
Corrected error recovery / handling around VMware session timeouts.
Config UI's browse hierarchy properly reflects the state of performance-based Auto-Monitors.
NumericSensorInfo reporting is now disabled by default.
Fixes Memory percent-based metrics errors.
Metrics added for reporting VM Template state and tallying the count of Non-Template VMs
December 2010
Corrected behavior around disabled monitors.
November 2010
Corrected behavior around sending clear alarms for monitors.
Fixed target for datastore Auto-monitors.
Fixed check box for host monitors.
November 2010
Handle error when some hosts have a null datastore.
October 2010
Fixed metrics that did not display properly in the GUI when a host name was not resolvable.
October 2010
Fixed auto configuration matching defect that caused Auto-monitors to match non-running VMs.
Fixed session timeout defect that caused null data when long intervals were used.
Retry queryAvailablePerfMetrics because it sometimes fails.
September 2010
Allow IP address as source for Auto-monitors.
Fixed string threshold editing defect.
September 2010
Added VMware API availability and response time metrics.
Added SnapshotCount and SnapshotSize metrics for VMs.
Added default auto configurations for new resources.
Made performance improvements
August 2010
Made scale improvements.
NIS2 enabled.
April 2010
Removed limitation on number of resources.
Added login-only check for resources without monitors.
Added support for language-independent exception handling.
Fixed NullPointerException when the array of objects returned by the server (by one of the getArrayOf methods) is null.
November 2009
Fixed problems with VMWARE subject detection and reconnection after connection to server is lost.
September 2009
Added support for additional measurement points for vSphere 4.
Added support $ip tag in messages.
Added support for automatic upgrade to vSphere 4 (if possible) using Ctrl-U.
June 2009
Fixed CPU key in default template.
February 2009
Corrected error when connecting to VC/ESX.
February 2009
Added support for CPU, Disk and Network instance performance monitoring.
Added the possibility to average a monitor point over the 2-5 last measurements.
Optimized start-up time for configurations with many active resources.
Added sortable column of alarm severities.
Fixed deployment of templates in clustered environments.
Fixed potential GUI issues when probe is about to restart.
December 2008
Added support for resource alarms to queue.
October 2008
Added fixed connect timeout.
October 2008
Removed possible performance collection error after a monitored VM is removed.
October 2008
Removed sending alarms when only QoS active.
October 2008
Removed hang when a resource was unavailable.
October 2008
Added support for two alarm levels.
Added support for auto configuration.
September 2008
Added the possibility to route alarms to logmon queue.
Added the possibility to add the DNS name (if available) to an alarm ($dns tag).
Added possibility to define Datastore, GuestDisk and Service checkpoints in Templates.
Added possibility to delete all existing checkpoints when a template is deployed.
Added "Add to template..." menu option.
Added "Deploying templates" status window.
Java 1.6 is supported.
June 2008
A number of new measurement points are added.
Improved GUI performance.
Automatic refresh of GUI might be turned off (use F5 for manual refresh).
A number of icons are changed.
The VM icons reflect the run-state and configuration-state of the VM.
A template might be dropped at any level (supports VM, Host and Resource Pool checkpoints).
Removed "Create Template" / "Apply Template" menu options on VM's.
Added support for Events in templates.
Removed list of checkpoints in template creation process (only drag-and-drop is supported).
Java 1.5 is supported.
Technical upgrade.
April 2008
Upgrade libraries
October 2007
Fixed login.
August 2007
Changed handling of monitor IDs.
August 2007
Fixed templates.
June 2007
Fixed QoS target and source.
April 2007
Added support for infrastructure 3 (VirtualCenter 2.x and ESX 3.x).
Added template support.
Changed GUI icons.
March 2007
Changed start up script to support Solaris.
December 2006
Improved certificate handling.
November 2006
Initial version
September 2006
Probe Specific Application Requirements
The probe requires user account access to the following applications:
  • User access to the VMware vCenter or ESX server.
  • Successful distribution of the probe package relies on the Java package installed with the
    CA Unified Infrastructure Management
Probe Specific Environment Requirements
The probe supports monitoring for the following vSphere environments:
  • v7.15: vSphere vCenter/ESXi 5.1U2 – 7.0
  • v7.11 to 7.14: vSphere vCenter/ESXi 5.1U2 - 6.7
  • v6.82 to 6.87: vSphere vCenter/ESXi 5.1U2 - 6.5
  • v6.72: vSphere vCenter/ESXi 5.1U2 - 6.0U2
  • v6.60: vSphere vCenter/ESXi 5.1U2 - 6.0U1
  • v6.00 to v6.53: vSphere vCenter/ESXi 5.1U2 - 5.5
  • v5.X: vSphere vCenter/ESXi 4.1U2 - 5.1U2
The probe requires targeted vSphere environments to use unique UUIDs. This means that when cloning virtual machines (VMs), each clone must have a distinct UUID in order for proper monitoring to occur. If each VM does not have a unique UUID, incorrect data will be reported for the VMs.
: The probe supports vCenter Server Appliance (VCSA) for compatible versions of VMware that support VCSA.
Probe Specific Hardware Requirements
The probe should be installed on systems with the following minimum resources:
  • Memory: 2-4 GB of RAM. The probe as shipped requires 512 MB of RAM.
  • CPU: 3 GHz dual-core processor, 32-bit or 64-bit
Sizing Recommendations for vmware probe
  • Launch the probe with no VMs configured using 1GB RAM. i.e 1 GB for base probe with no devices
  • Get a count of the number of VM's on the vCenter you want to monitor.
  • Based on the count of VMs in the vCenter, add 330 MB per 1000 VM's.
    For example, if you have 3000 VMs in your vCenter, then you need 1 GB + 1GB (i.e. 330MB*3) .That is your maximum memory you need for the VMware probe per vCenter.The thumb-rule to be followed is:
    (1 GB + 330 MB, per 1000 VM = Maximum RAM needed.)
Probe Specific Software Requirements
To use all of the features available for v6.41 and later, including configuration of the probe in the Unified Management Portal (UMP) and the Admin Console (AC) portlet,
CA Unified Infrastructure Management
v8.2 or later is recommended.
The probe requires the following
software environment:
  • CA Unified Infrastructure Management
    server 7.1 or later.
We recommend that the
CA Unified Infrastructure Management
server and CA Unified Management Portal (UMP) are the same version. To verify the version number for Unified Management Portal (UMP), enter “html/version.txt ” in your browser address bar, after the UMP “IP/” or “hostname/.” For example:http://<UMP_Server_name_or_IP_adress>:/html/version.txt. When you do this, a page displays the Version, Build Label, Build Date, and Build Number.
  • CA Unified Infrastructure Management
    Robot version 5.23 or later.
  • Java Virtual Machine
    • vmware versions 6.53 and later: Java Virtual Machine version 1.7 package or later (deployed as part of the probe package).
    • vmware versions up to 6.51: Java Virtual Machine version 1.6 package or later (deployed as part of the probe package).
CA Unified Infrastructure Management
server 7.0 or later version is required to use the Unified Service Management (USM) portlet, which most customers use. If you do not want to use USM, data collection and dashboards function with
CA Unified Infrastructure Management
5.1.1 or later.
Probe Specific Software Requirements for Infrastructure Manager users
The probe requires
CA Unified Infrastructure Management
4.08 or later.
Infrastructure Manager requires Microsoft .NET. Use the Microsoft. NET version that is compatible with the version of the probe that you are using.
vmware 6.7x and later
  • Microsoft .NET framework 3.5-4.X on the Windows system running the Infrastructure Manager GUI.
vmware v6.72 and earlier
Microsoft .NET framework 4.0 or later is not supported. To determine your version, go to the Microsoft documentation and search for "How to: Determine Which .NET Framework Versions Are Installed."
  • Microsoft .NET framework 3.5 on the Windows system running the Infrastructure Manager GUI.
Installation Considerations
The probe requires the following type of account access to the VMware environment:
  • Read access on all monitored entities
For TLS 1.2 support:
  • As the administrator of the target vCenter’s you may have enabled or disabled any version of TLS and the VMware probe will be able to communicate with the vCenter.
  • VMware probe will always initiate handshake with TLS 1.2 and if the target vCenter supports TLS 1.2, all further communication will use TLS 1.2 protocol. Otherwise, highest protocol supported by the vCenter will be used.
Upgrade Considerations
The following sections apply to users accessing the probe configuration GUI using
CA Unified Infrastructure Management
Infrastructure Manager or Admin Console.
Upgrading from v6.41 to v6.50
Versions 6.41 and later include support for configuring and applying monitoring with templates in Admin Console.
When you apply monitoring with templates in v6.41 and then upgrade the probe to v6.50, any Admin Console templates (and their filters, rules, and monitors) that you have configured are saved and included in the upgraded probe.
Any monitors that are new in v6.50 are added to all relevant Admin Console templates, including templates that were configured in v6.41. The new monitors are available but turned off by default.
Active default templates
are upgraded automatically when you upgrade the probe. Any new or deprecated
filters, rules, and monitors
, in the latest version of the active default template are applied automatically as part of the upgrade process. If you want to save the monitoring configuration of your current active default template and to prevent them from being overwritten when you upgrade the probe, copy the active default template, rename it, and apply this renamed copy before you upgrade the probe.
Upgrading from earlier versions to v6.41 or later
Configuring and applying monitoring with templates in Admin Console is possible for only v6.41 and later.
If you upgrade to v6.41 or v6.50 from an earlier version of the probe, and want to apply monitoring with templates, you must first delete any previous configuration. You can then enable bulk configuration, which enables configuration only through Admin Console and disables Infrastructure Manager. Because of this, we recommend that you delete probe versions earlier than 6.41 and deploy a new v6.41 or later probe.
If you want to configure the probe using
Infrastructure Manager, you can upgrade from an earlier version to v6.41 or later without deleting any previous configuration. However, not all features of v6.41 and later are supported in Infrastructure Manager.
: If you are upgrading from v4.23 and want to retain your configured monitors, we recommend upgrading to v6.50 because of its improved upgrading performance.
Unified Dashboards or Summary Views in UMP
The probe version 5.01 and later requires you to update to the default preconfigured VMware List Views provided under Unified Dashboards or Summary Views in UMP. Any existing VMware list views might show blank data in some list views.
See the following steps to resolve the dashboard or List Views issues:
  • Apply the UMP Template provided with the probe (or manually update your monitors to reflect the content in the UMP Template), and
  • Use the List Views provided with the latest version of UMP. Alternatively, you can go to the support site and obtain the updated List Views that are compatible with version 5.01 of the probe. Refer to the forums for information on obtaining this content.
Migration from 4.2x versions of the probe is supported, but with important caveats:
  • CPU Extra (% of available) and CPU Guaranteed (% of available) were both removed from the VMware API after ESX 3.5. They have been removed from the probe.
  • VMwareApiAvailable has been removed as a monitorable metric in versions 5.01 to 6.01. A self-monitoring alarm has replaced it.
    This functionality was restored in version 6.10 and might be used in addition to the self-monitoring alarm.
  • Reservation (vm) was a duplicate of the monitor CPUReservation. To avoid confusion, reservation has been removed.
  • Host metrics VMNonTemplateCount, VMNamesActive, and VMNames were all intended for an abandoned feature. They have been removed.
  • ToolsStatus (deprecated) was deprecated for a release and is now removed.
  • TemplateState has been removed in favor of having fully distinct type for VMs and templates. Static monitors that were created against entities reclassified from VM to template will need to be recreated.
  • Attempting to migrate any of these monitors will result in alarms for each during every polling cycle.
  • The original configuration file is automatically backed up in the probe installation directory.
  • Any of CpuStatusInfo, MemoryStatusInfo, or NumericSensorInfo that were manually enabled in the old probe will need to be enabled in the new probe by editing the 'mondef.cfg' file.
  • The 5.x versions of the probe use more memory. If you were close to the memory limit on the previous version of the probe, it is very likely you will need to increase the available memory.
Considerations for the VMware Web Services API
The probe relies on the VMware Web Services API for data collection. All data is collected using exclusively read-only operations (the probe never makes update or write requests to the environment).
Considerations for Viewing Information in USM
Additional steps are required to view VMware consumption metrics and information in USM. The the VMware-specific information displayed in USM varies depending on the VMware system--vCenter, host, or virtual machine.
CA Unified Infrastructure Management
  1. In Infrastructure Manager, apply the UMP Metrics template to the system.
    This step enables the majority of the monitors required for viewing VMware information in USM. However, to view all of the VMware specific information available, you must also perform the next step.
  2. Select the
    Publish Data
    check box for the following monitors:
Lists for Hosts and vCenters
Top 5 Resource Pools - CPU
Top 5 Resource Pools - Memory
Top 5 Data Stores - Capacity
Top 5 VMs - Memory
vCenter Properties
Storage vMotions
Num Storage VMotions
VM vMotions
Num VMotions
Total Memory
Total CPU
Lists for vCenters
Top 5 Hosts - CPU
Top 5 Hosts - Memory
Deprecated Metrics for the following monitors
For the following monitors/ resource entities, few metrics have been deprecated and replaced.
Applicable monitors
Metric in Legacy template
Metric in Enhanced template
Network Packets Received
Network Packet Receive Rate
Network Packets Transmitted
Network Packet Transmit Rate
Best Practices
This section contains general best practices for using the probe. See the documentation for your version and configuration interface for further best practices specific to your situation.
The default settings should be sufficient performance for most environments. The following items can affect performance:
  • The number of resources targeted
  • The API response time of the targeted environments
  • The number of monitors
  • Polling frequency
If the probe is not able to keep up, it will send an alarm indicating that the collection process is taking longer than the polling interval. In general CA recommends keeping the polling interval at 10 minutes or longer. If you are still seeing problems even with a higher polling interval, consider doing one or both of the following:
  • Increase the polling interval. If the probe is not experiencing memory issues, change the polling interval to allow for the fetching and processing of data from the targeted VMware environment.
  • Increase the amount of maximum memory. Do this only if you see evidence that the probe has insufficient memory (verify using either a JVM monitoring tool or through the info call-back).
When you configure monitoring for a new resource, the probe might take several minutes to start up depending on number of VMs in the vCenter.
Auto Monitors and Static Monitors
Because auto monitors automatically adjust to inventory changes in the vCenter, we recommend that you use auto monitors instead of static monitors.
If you use static monitors, and the monitor becomes unavailable in the vCenter, the probe issues an error message, such as: "The <monitor> cannot be configured on <workstation>. To see and to clear the static monitors that no longer apply to your inventory, click on the Detached Configuration folder in the Admin Console interface.
Optimizing Memory for the Probe
On large installations with many checkpoints, increase the memory for the probe if:
  • the log file contains out-of-memory errors, consider making an adjustment.
  • the process size is reaching the configured Java Virtual Machine memory limit, consider making an adjustment.
Use the Raw Configure tool to adjust the memory available to the probe. A good rule is to use 1000 Mbytes of memory for each 1,000 VMs that you are monitoring. For example, to set the start up heap size to 1000 Mbytes, proceed as follows:
  1. In Infrastructure Manager, press SHIFT, then right-click the probe.
  2. Select
    Raw Configure
    from the context menu.
  3. Add or change the following entry in the
    -Xms32m -Xmx1000m
    The value is case-sensitive.
    The Raw Configure tool has no error checking. Take care that any changes you make are valid before you continue.
Hardware Monitoring
This topic applies to users accessing the monitoring configuration GUI using
CA Unified Infrastructure Management
Infrastructure Manager or Admin Console.
The probe provides numerous virtualization monitoring metrics and alerts for performance and availability of the VMware environment through the VCenter and ESXi web services APIs. The VMware APIs also provide metrics for the underlying server hardware that runs the ESXi hypervisor. The probe collects most of these server hardware monitoring metrics. The metrics available are limited by the data provided by the VMware APIs. The metrics also differ in coverage and accuracy depending on the server hardware.
Therefore, we recommend using other
CA Unified Infrastructure Management
probes for server hardware monitoring, especially SNMP-based probes such as snmptd. As a best practice, use the snmptd probe to catch traps due to fault or damaging events from the underlying server hardware device that runs the ESXi hypervisor. Follow the instructions provided by VMware or the server hardware vendor to enable SNMP on the server hardware device. To configure the CA
CA Unified Infrastructure Management
snmptd probe, see the probe documentation or contact support for assistance.
Alternatively, the probe can forward alarms from the vCenter. Configure appropriate hardware alarms in the vCenter, and turn on alarm monitors for the related devices in the probe to forward any triggered alarms.
SOC Support for Hosts and VMs
This topic applies to users accessing the probe monitoring configuration GUI using Infrastructure Manager or Admin Console.
Starting with v4.0, the probe supports configuration through Service-Oriented Configuration (SOC). When using the probe with SOC:
  • Configuring a connection to a vSphere resource is performed through the Probe UI.
  • Template Groups for VMs or Hosts can be formed by using the dedicated setting. For VMs, the field is VirtualMachine; for hosts, its HostSystem.
  • The probe will do an initial discovery of manageable Hosts and VMs and populate this content to the local robots niscache for Discovery Server processing.
  • The probe will monitor its configuration file for changes. When a change has been noticed, the probe waits for a 5 minute quiet period before restarting.
  • Attempting to manage a probe through both the Probe UI or SOC can cause data collisions.
  • Only Virtual Machines with VMtools installed can be managed by SOC. All Hosts can be managed by SOC.
  • Upgrading or converting a previously configured probe to SOC might disrupt expected data collection. SOC configuration overwrites any other configuration.
Additional inventory attributes added for USM Group filtering:
Additional inventory parameters have been added in vmware v7.11, to enhance and improve dynamic and static group creation in USM, for better group filtering of vmware resources.
To filter groups by these attributes, follow these steps:
  1. In the Add Group dialog box, navigate to the Properties tab > Add filter> select Advanced from the filters drop-down.
  2. Click the Select advanced attribute field, and select one of the following:
    • vmware.BulkConfigurationMode
    • vmware.Cluster
    • vmware.Datacenter
    • vmware.esx
    • vmware.FolderPath
    • vmware.mcs_discovery_profileid
    • vmware.mcs_profile_name
    • vmware.mcs_profileid
    • vmware.mcs_template_name
    • vmware.mcs_template_version
    • vmware.ResourcePoolvAppPath
    • vmware.vCenter
  3. Enter the string to match the attribute you have selected.
  4. Click Apply Filters.
  5. Click OK.
    A new group is created with the filter.
We want to monitor a VCenter but want to filter certain VMs from being discovered by VMWare Probe.
You can filter the VMs that the vmware probe will consider for discovery by using a regular expression (regex) to filter VMs for matching names.
You need to upgrade to vmware probe version 7.11.
To filter VMs for discovery by label name via Config Key, follow these steps:
  1. Upgrade and start the vmware probe.
  2. Navigate to
    Admin Console
    Raw Configure
    , and add the config key
  3. Specify the value with 'VM name' of the VM(s) you want to exclude under the setup section via raw configure.
  4. Save the changes and restart the probe.
  5. Create a profile for the vcenter.
    Profile should be created and the VM name provided in the config key should not be added to the inventory.
To add the VM to the vcenter, rename the VM with a name other than the value specified as the config key
Disable alarms and QoS from Maintenance mode Hosts
As a Vmware administrator, I do not wish to see alarms or QoS data from host machines that are currently in maintenance mode.
Starting from vmware v7.11, a new configuration property
has been added in order to allow you to disable alarms and QoS from hosts that are in maintenance mode. The default value of this property is False.
To disable the alarms and QoS, follow these steps:
  1. Do one of the following:
    • Navigate to
      Admin Console
      Raw Configure
      , > config key
      and change the value to
      . OR
    • Navigate to vmware probe in
      > right-click and select
      , config key
      and change the value to
  2. Restart the probe.
    You will no longer receive alarms and QoS from host machines that are in maintenance mode.
  • All alarms from a host in Maintenance Mode will be supressed, except for the alarm for Host Monitor:
  • In the scenario where the ESX server hosting the VMs is in maintenance, no QoS data or alarms will be reported from the VMs.
Known Issues and Work-arounds
VMware probe 7.11 or above version is unable to connect to vCenter 6.7.
This is possible when the probe robot is running JRE 1.7. To resolve this, upgrade the JRE version to 1.8 on robot and restart the robot. For more information, see vmware probe 7.14 fails to connect ESXi 6.7 article.
After upgrading to vmware v7.11, the MCS profiles do not work on UIM 8.51
The vmware MCS 7.11 templates that are part of the vmware v7.11 release are NOT compatible with UIM 8.51.
If you are currently using vmware MCS v6.82 (part of UIM 8.51 installer) with vmware v6.87 or less to configure your vmware probe then you should not deploy or use the 7.11 MCS version until you have upgraded to UIM 9.01 or above. This way you can continue to use your existing (v6.82) MCS profiles with vmware probe 7.11 on UIM 8.51.
If you are NOT using MCS but are using only IM or Admin Console to configure your vmware probe on UIM 8.51, you can upgrade the vmware probe v7.11, (and not the MCS packages), as a normal probe upgrade.
New alarm message added to vmware probe (defined in vmware.cfg) is not available / displaying in Template Editor
When configuring monitoring template for vmware probe from Admin Console > Template Editor, we do not see the new messages defined in vmware.cfg.
A new callback
was added to fix this.
Follow these steps:
  1. Navigate to the vmware.cfg file.
  2. Add the message(s) in the vmware.cfg file, using a text editor.
  3. Run and execute the
    callback from the probe utility.The callback will sync the templateDefinitions.zip with the messages in the vmware.cfg file.
  4. Activate the probe and confirm that the message is now seen in Admin Console.
vmware probe configuration having issues pulling data from Virtual Center
vcenter is not able to read configuration and discover any information from the host even though that ESXi was reported as connected to the vcenter.
A warning alarm is generated to prompt the vcenter admin to verify whenever there were timeout issues while collecting data from the VCenter. The alarm provides information that something might be wrong in the vcenter and vcenter admin need to verify it.
QOS metrics was missing for VMware Probe
vmware probe randomly stops collecting QoS.
Follow these steps
  1. Do one of the following:
    • Apply the hotfix vmware-6.8.7-HF2 on your vmware probe v6.87.
    • Upgrade to vmware probe v7.11
  2. On the robot where vmware is installed, login to Admin Console> vmware, under Probes page, right click and select Raw Configure.
  3. Select
  4. On the right side pane, select Add New Key (+ icon).
  5. Enter
    as the config key.
  6. Provide appropriate value(in Bytes) in the
    field . For example 0.
  7. Click Create.
  8. Click Update on Raw Configure Window.
This value is used for uncommitted space if the VMWare API doesn't return any value. It is also used to calculate the provisioned space which is otherwise set to null due to its dependency on uncommitted space.
Verify that after setting this value, both uncommitted and provisioned space metrics are shown in the IM.
List Designer Dashboards do not work when using MCS
vmware 6.81
List Designer Dashboards do not work when the probe configuration is deployed using MCS profiles.
View the data in the CA Business Business Intelligence Dashboards.
Monitor values for datastores on the ESXi server differ from those reported by the vCenter
vmware 6.72
Monitor values for datastores on the ESXi server differ from the values that are reported by the vCenter when an ESXi server is configured as the probe target/resource. The difference is caused by a known issue with the VMware vCenter Server. The vCenter Server environment in vSphere (4.1 Update 1 and later) might show freespace of datastore values that are out of sync from the actual value.
Follow the instructions described in the VMware Knowledge Base article (2008367), which you can find on the VMware documentation site: https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2008367
Performance Metric Collection Error
vmware v6.6 or 6.72
By default VMware limits the "vpxd.stats.maxQueryMetrics" to 64. This will cause the probe metric collection to fail if a Resource Pool/vAPP or a cluster has more than 64 VMs or a Datastore has more than 64 VMs or disks. You will see an error massage such as:
Failed to execute single perf query for entity …….
Follow VMware KB 2107096 to resolve
:Follow the instructions in the VMware Knowledge Base article "Performance charts are empty" #2107096, on how to increase the "vpxd.stats.maxQueryMetrics." Increase the "vpxd.stats.maxQueryMetrics" to more than the maximum number of VMs that you have in a resource pool, cluster. Similarly, increase the "vpxd.stats.maxQueryMetrics" to more than the maximum number of VMs/Disks that you have in a Datastore.
Static Monitor Cache
After I make a change to a static monitor and restart it, I cannot fully clear the static monitor cache.
Deactivate and reactivate the probe.
QoS Collisions
I installed the xenserver probe on my CA UIM system on which I had the vmware probe already installed. Now, I observe: 1) data missing for my memory monitoring 2) the data_engine log has errors for QOS_MEMORY_PERC_USAGE.
If you install the xenserver probe on a CA UIM installation, on which the vmware probe is installed, QoS collisions occur. Collisions can occur because both probes have a QOS_MEMORY_PERC_USAGE monitor but the vmware probe has more fields for the monitor. To fix the problem, add these extra fields to the xenserver monitor configuration.
Follow these steps
  1. In Admin Console, select the
  2. Click
    Raw Configure
  3. Click
  4. Click
    Add key
    and add the key/value for each of the following pairs:
  5. Click
    You added the missing fields.
I installed the vmware probe on my CA UIM system on which I had the xenserver probe already installed. Now, I observe: 1) data missing for my memory monitoring 2) the data_engine log has errors for QOS_MEMORY_PERC_USAGE.
If you install the vmware probe on a CA UIM installation, on which the xenserver probe is installed, QoS collisions occur. Collisions can occur because both probes have a QOS_MEMORY_PERC_USAGE monitor but the vmware probe has extra fields for the monitor. To fix the problem, delete these extra fields from the vmware monitor configuration.
Follow these steps
  1. In Admin Console, select the
  2. Click
    Raw Configure
  3. Click
  4. Click
    Remove key
    and remove each of the following key/value pairs:
  5. Click
    You removed the extra fields.
Raw Configure In Place of IM
I launch the IM GUI, but get the Raw Configure dialog instead.
Install .NET 3.5 on the system. If you install .NET 3.5 after launching the GUI, you may also need to restart the robot.
Windows 2008 Socket Exception
I deployed the probe on a Windows 2008 server. And I see the following exception in the log file: " java.net.SocketException: No buffer space available (maximum connections reached?): connect".
Apply the hotfix for a socket leak on the Windows 2008 server.
Delay in QoS Data Publication
After I change the value definition for an alarm, the probe delays in sending QoS data to the Discovery Server.
You can expect a delay in QoS publishing to correspond with the value definition for the alarm. For example: If you set the value definition to an "average of n," the probe will wait n cycles before it sends any QoS data to the Discovery server. If you set the value definition to "delta," the probe will wait two cycles before it sends any QoS data to the Discovery server.
If you want to decrease the time it takes for the probe to publish QoS data, lower the value definition so that it results in a shorter interval.
Inconsistent Data for Memory Shared Metric
Probe returns inconsistent data for the Memory Shared (% of MemorySize) metric.
v6.21 and 6.30:
  1. Go to the vmware.cfg file.
  2. In the vmware.cfg file, search for:
    Memory Shared (% of Memory Size).
  3. Replace every instance of Memory Shared (% of Memory Size) with:
    Memory Shared (% of Memory)
    The Raw Configure tool has no error checking. Take care that any changes you make are valid before you continue.
    : If you have any templates configured to monitor Memory Shared (% of Memory Size), you must also change the metric within the template to read Memory Shared (% of Memory).
v6.4 and later:
In the probe configuration GUI, delete any auto and static monitors for Memory Shared (% of Memory Size). Recreate the monitors.
Passive Robot
When configuring a probe deployed on a passive robot, you see an error message:
Configuration was unable to be retrieved.
Message: Request Error: Probe vmware on robot...passivehub is busy.
Resolution: Wait and retry loading configuration later.
Error Code: PPM-023
You can ignore the message. The hub will retrieve configuration information from a probe deployed on a passive robot the next time that the hub_update_interval has elapsed.
Or, if you want to decrease the time it takes for a hub to retrieve configuration information from a probe deployed on a passive robot, decrease the hub_update_interval from the the default value (900). For more information about how to configure a hub with a passive robot, see the hub guide on the
CA Unified Infrastructure Management
IPv6 Support
When I configure a profile using an IPv6 address, I get a stack trace error that includes the exception: Caused by: java.lang.NumberFormatException: For input string: "f0d0:1002:0051:0000:0000:0000:0004:443".
Follow the Java standard of enclosing the IPv6 address in square brackets.
For example: The input string [f0d0:0:0:0:0:0:0:] works. But the input string f0d0:0:0:0:0:0:0: causes a stack trace error that includes the exception: Caused by: java.lang.NumberFormatException: For input string: "f0d0:0:0:0:0:0:0:".
When using probe v6.10 or later, IPv6 addresses are not shown in USM for
CA Unified Infrastructure Management
7.0 or 7.1.
Upgrade to
CA Unified Infrastructure Management
Infrastructure Manager UI fails for IPv6 only robot host
The Infrastructure Manager user interface for the probe will fail to display when the robot hosting the monitor is hosted on an IPv6 only network. The work-around is to provide IPv4 access to the robot host.
Trappable Stack Trace in Log File
When I turn on the VMWare API Available monitor, I get a null pointer exception and a stack trace in the log.
Mar 27 17:28:51:807 [pool-3-thread-1, vmware] Failed to build collection request for monitor "ESC:RESOURCE:"."VMwareApiAvailable"
Mar 27 17:28:51:807 [pool-3-thread-1, vmware] java.lang.NullPointerException
Ignore this error, data is still collected correctly.
Appearance of VMs in USM
This issue applies to probes prior to v6.0. Machines with VMtools installed will appear as independent VMs in USM. Machines without VMtools installed will appear as children of the containing hypervisor.
Either install or uninstall VMtools as needed from your machines to control your view of VMs in USM.
Errors with Polling Intervals under 20 Seconds
The probe configuration GUI allows polling intervals of less than twenty seconds to be requested. However, the VMware software only makes metrics available with a resolution of twenty seconds. Attempting to poll more frequently than twenty seconds will result in errors.
Collection Times are Extremely Slow
In any size environment, the total collection time is high, particularly the time to ‘Execute request for perf metrics’ (visible in the log file). The time to collect might drop overnight, or during times of light load on the vCenter.
This is generally due to a bottleneck accessing the vCenter database. You should investigate the source of the congestion, which could be memory, CPU, disk or database access, or another resource that is insufficient at peak load.
Users accessing the probe monitoring configuration UI via Infrastructure Manager can also disable collection of metrics that rely heavily on database operations. To do this, use Raw Configure to set the 'include_summary_perf_metrics' key to 'no'.
The Raw Configure tool has no error checking. Take care that any changes you make are valid before you continue.
Probe Values Don't Match the vSphere Client
Comparing values in the database or probe configuration GUI displays different values than appear in the vSphere Client.
Numerous data bugs in the API were fixed in the 4.1 updates. Therefore, if you're running ESXi 4.1 pre-update 1, update your ESXi version. Otherwise, investigate the VMware 'managed object browser'. It will allow you to view many of the values as VMware exposes them via its API.
The probe aggregates many values over the configured collection period. Therefore, the probe values may not match the most recent values displayed in vSphere.
For Event Monitors, All Events are Coming Across as Part of a Single Alarm
This behavior is as designed.
Limited Multibyte Character Support
Inventory items with multibyte names can be displayed, but static monitors cannot be created for these entities. Additionally, user input fields do not support multibyte characters.
QoS Data Fails to be Submitted into the SLM DB
The system is successfully submitting QoS messages (for example, observed via Dr Nimbus), but the data is not persisted in the SLM database. In addition, the data_engine log entries indicate that the message was rejected due to a conflict in the QoS definition (log level 3).
This occurs when there are discrepancies in how QoS definitions are defined. The probe has unique QoS definitions available for every metric. Select the appropriate unique QoS to avoid the conflict.
State of ESXi host services out of date
If I use the ESXi hypervisor console to manually shut down services instead of using the vSphere Client, VMware does not update the ESXi server status reported to the probe.
Do the following:
  1. Verify you have administrator privileges and a 6.12 or later release of the probe.
  2. Click
    Raw Configure
    on the context menu.
    The probe Raw Configure window opens.
  3. Click the
    The Keys and Values for the setup section are displayed in the right pane.
  4. Select
    Add key
    The Add key dialog opens.
  5. Enter "force_services_refresh" and click
  6. Click in the Value column for the "force_services_refresh" Key, enter "true" for the Value, and press Enter.
  7. Click
Known Issues and Work-arounds for Infrastructure Manager Users Only
This section describes some known issues and work-arounds that apply
to users of the Infrastructure Manager interface for configuring the probe.
No Value is Listed for a Monitor
When I click on a Resource component in the navigation pane, some monitors have no value listed in the Value column in the content pane.
This is expected behavior. Some monitors for the probe take a while to collect. For these monitors, the current value is not displayed unless the monitor is activated (the check box is selected). To see the current value for a monitor, select the check box. The value is collected during the next polling cycle, even if QoS and alarming are not enabled.
Out of Memory Errors
Out of memory or garbage collection errors in the log file.
If you have more than several thousand monitors (or entities) in the probe, you might need to increase the heap space for the probe. Heap space is allocated during probe start up. By default the heap space for the probe is 512 MB.
You can increase the heap space setting for the probe in the Raw Configure window for the probe.
Follow these steps:
  1. Shift + right-click on the probe in Infrastructure Manager.
  2. Choose
    Raw Configure
    from the menu.
  3. Click
    in the left pane.
  4. Select the
    key and open it for editing.
  5. Enter a value similar to the following:
    -Xms256m - Xmx<nnnn>m
    where <nnnn> is heap space up to 2048 MB or greater. For example, to increase the heap space to 1024 MB, enter the following:
    -Xms256m - Xmx1024m
    Ensure the machine where the robot and probe are deployed has enough RAM.
  6. Click OK and Apply.
Error When Closing the Configuration GUI
I get a Windows error dialog when I attempt to close the configuration GUI.
If the configuration GUI has been open for an extended time, the probe will not automatically release its lock on the configuration file (if configuration file locking is enabled). This will only occur if the GUI is left open for periods longer than controller-configured session expiration time and the 'Cancel' button or 'X' button are used to close the GUI.
The error is harmless and can safely be ignored.
UI Fails to Load Auto/All Monitors Nodes
In environments with many active monitors, the UI may fail to load the list of monitors into either the ‘Auto-monitors’ or ‘All Monitors’ nodes. The issue begins occurring when the monitor count is greater than 40,000 and the UI begins to exhaust memory.
There are no work-arounds for this problem. Avoid accessing these node in such environments. If you need to see and manage a particular set of monitors - you can temporarily disable other static and auto-monitors to reduce the monitor count, and then work from there.
UI Slowly Loads Nodes Within the Inventory Tree
This topic applies to users accessing the configuration GUI using
CA Unified Infrastructure Management
Infrastructure Manager. It does not apply to Admin Console users.
In environments with a large inventory, the UI might take several minutes to load content within the Inventory Tree. For example, for a vCenter with 10,000 VMs - loading the ‘VMs’ will take several minutes.
Where possible, avoid navigating to such nodes. In the example of the ‘VMs’ node, try finding the VMs under the hosting HyperVisor as opposed to relying on the ‘VMs’ node.