This section contains the Release Notes for all versions of the VMware Monitoring (vmware) probe.
This section describes the history of the probe updates.
Added custom properties to the VMware probe inventory elements to support publishing of Inventory Topology and relationships between VMware objects:
Enhanced the documentation on the vmware AC Apply Monitoring with Templates page:
For more information, see the v6.5 vmware AC Configuration and v6.5 vmware IM Configuration Guides.
For more information about these metrics, see vmware Metrics.
Corrected an issue with value updates for HOST_SERVICE metrics.
Added support for migration to current release from 4.01 and forward.
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.
|6.10||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
|6.01||Fixed: Monitoring alarms on multiple vCenters could cause a collection failure.||GA||December 2013|
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.
|5.10||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'
|5.03||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.
|5.02||Mouseover tool-tips on resource nodes to provide additional context
Fixed creation of devices visible to USM
|5.01||Rewritten backend and GUI
Alarm forwarding support
Storage Pod and Virtual App monitoring
Cluster VMotion monitoring
|4.20||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.
|4.11||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.
|4.03||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)
|4.02||Updated the UMP Metrics template to match the latest Dashboard content.||December 2011|
|4.01||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.
|4.00||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
|3.53||Fixed failures around calculation process for missing Network Metrics.||June 2011|
|3.52||Adjusted QoS entries in support OOB Dashboards.||June 2011|
|3.51||Fixed millisecond to percentage calculations for CPU performance metrics||June 2011|
|3.42||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.
|3.41||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
|3.40||Maintenance release that includes additional message types and QoS entries.||March 2011|
|3.31||Corrected target resolution process for submitted QoS and Alarm messages||March 2011|
|3.30||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.
|3.29||Fixed Event Monitors.
Updated the defaults for the VM Guest Memory Monitor.
Updated the UMP Metrics template monitors around Datastores and Guest Memory.
|3.28||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.
|3.27||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
|3.26||Corrected behavior around disabled monitors.||November 2010|
|3.25||Corrected behavior around sending clear alarms for monitors.
Fixed target for datastore Auto-monitors.
Fixed check box for host monitors.
|3.24||Handle error when some hosts have a null datastore.||October 2010|
|3.23||Fixed metrics that did not display properly in the GUI when a host name was not resolvable.||October 2010|
|3.22||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.
|3.21||Allow IP address as source for Auto-monitors.
Fixed string threshold editing defect.
|3.20||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
|3.10||Made scale improvements.
|3.02||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.
|3.01||Fixed problems with VMWARE subject detection and reconnection after connection to server is lost.||September 2009|
|3.00||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.
|2.73||Fixed CPU key in default template.||February 2009|
|2.71||Corrected error when connecting to VC/ESX.||February 2009|
|2.70||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.
|2.55||Added support for resource alarms to queue.||October 2008|
|2.54||Added fixed connect timeout.||October 2008|
|2.53||Removed possible performance collection error after a monitored VM is removed.||October 2008|
|2.52||Removed sending alarms when only QoS active.||October 2008|
|2.51||Removed hang when a resource was unavailable.||October 2008|
|2.50||Added support for two alarm levels.
Added support for auto configuration.
|2.20||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.
|2.10||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.
|2.08||Upgrade libraries||October 2007|
|2.07||Fixed login.||August 2007|
|2.06||Changed handling of monitor IDs.||August 2007|
|2.05||Fixed templates.||June 2007|
|2.01||Fixed QoS target and source.||April 2007|
|2.00||Added support for infrastructure 3 (VirtualCenter 2.x and ESX 3.x).
Added template support.
Changed GUI icons.
|1.16||Changed start up script to support Solaris.||December 2006|
|1.15||Improved certificate handling.||November 2006|
|1.00||Initial version||September 2006|
The probe requires user account access to the following applications:
The probe supports monitoring for the following vSphere environments:
Note: The probe supports vCenter Server Appliance (VCSA) for compatible versions of VMware that support VCSA.
The probe should be installed on systems with the following minimum resources:
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 minimum software environment:
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
vmware v6.72 and earlier
Microsoft .NET framework 3.5 on the Windows system running the Infrastructure Manager GUI.
The probe requires the following type of account access to the VMware environment:
For TLS 1.2 support:
The following sections apply to users accessing the probe configuration GUI using CA Unified Infrastructure Management Infrastructure Manager or Admin Console.
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.
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 only 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.
Note: 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.
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:
Migration from 4.2x versions of the probe is supported, but with important caveats:
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).
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.
For CA Unified Infrastructure Management
In Infrastructure Manager, apply the UMP Metrics template to the system.
|Lists for Hosts and vCenters|
|Top 5 Resource Pools - CPU||CPUOverallUsage|
|Top 5 Resource Pools - Memory||MemoryOverallUsage|
|Top 5 Data Stores - Capacity||Capacity|
|Top 5 VMs - Memory||GuestMemoryUsage|
|Storage vMotions||Num Storage VMotions|
|VM vMotions||Num VMotions|
|Lists for vCenters|
|Top 5 Hosts - CPU||TotalCPU|
|Top 5 Hosts - Memory||OverallMemoryUsage|
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|
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:
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:
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.
Because auto monitors automatically adjust to inventory changes in the vCenter, we recommend that you use auto monitors instead of static monitors.
Note: 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.
On large installations with many checkpoints, increase the memory for the probe if:
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:
Add or change the following entry in the startup section:
Value: -Xms32m -Xmx1000m
The value is case-sensitive.
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.
Starting with v4.0, the probe supports configuration through Service-Oriented Configuration (SOC). When using the probe with SOC:
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:
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:
Note: 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
Scenario: As a Vmware administrator, I do not wish to see alarms or QoS data from host machines that are currently in maintenance mode.
Resolution: Starting from vmware v7.11, a new configuration property 'disable_qos_and_alarms_for_maintenance_mode_hosts' 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:
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.
defined in vmware.cfg) is not available / displaying in Template EditorNew alarm message added to vmware probe (
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 ('sync_template_definition') was added to fix this.
Follow these steps:
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.
vmware probe randomly stops collecting QoS.
Follow these steps
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 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 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
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.
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.
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:
Click Add key and add the key/value for each of the following pairs:
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:
Click Remove key and remove each of the following key/value pairs:
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.
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.
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.
Probe returns inconsistent data for the Memory Shared (% of MemorySize) metric.
v6.21 and 6.30:
Replace every instance of Memory Shared (% of Memory Size) with:
Memory Shared (% of Memory)
Note: 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.
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 wiki.
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:10.0.00.0] works. But the input string f0d0:0:0:0:0:0:0:10.0.00.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:10.0.00.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 7.5.
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.
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:220.127.116.11"."VMwareApiAvailable"
Mar 27 17:28:51:807 [pool-3-thread-1, vmware] java.lang.NullPointerException
Ignore this error, data is still collected correctly.
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.
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.
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'.
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.
This behavior is as designed.
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.
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.
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:
This section describes some known issues and work-arounds that apply only to users of the Infrastructure Manager interface for configuring the probe.
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 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:
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.
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.
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.
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.