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.
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.
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.
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.
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
Fixed: Monitoring alarms on multiple vCenters could cause a collection failure.
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.
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'
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.
Mouseover tool-tips on resource nodes to provide additional context
Fixed creation of devices visible to USM
Rewritten backend and GUI
Alarm forwarding support
Storage Pod and Virtual App monitoring
Cluster VMotion monitoring
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.
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.
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)
Updated the UMP Metrics template to match the latest Dashboard content.
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.
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
Fixed failures around calculation process for missing Network Metrics.
Adjusted QoS entries in support OOB Dashboards.
Fixed millisecond to percentage calculations for CPU performance metrics
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.
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
Maintenance release that includes additional message types and QoS entries.
Corrected target resolution process for submitted QoS and Alarm messages
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.
Fixed Event Monitors.
Updated the defaults for the VM Guest Memory Monitor.
Updated the UMP Metrics template monitors around Datastores and Guest Memory.
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.
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
Corrected behavior around disabled monitors.
Corrected behavior around sending clear alarms for monitors.
Fixed target for datastore Auto-monitors.
Fixed check box for host monitors.
Handle error when some hosts have a null datastore.
Fixed metrics that did not display properly in the GUI when a host name was not resolvable.
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.
Allow IP address as source for Auto-monitors.
Fixed string threshold editing defect.
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
Made scale improvements.
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.
Fixed problems with VMWARE subject detection and reconnection after connection to server is lost.
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.
Fixed CPU key in default template.
Corrected error when connecting to VC/ESX.
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.
Added support for resource alarms to queue.
Added fixed connect timeout.
Removed possible performance collection error after a monitored VM is removed.
Removed sending alarms when only QoS active.
Removed hang when a resource was unavailable.
Added support for two alarm levels.
Added support for auto configuration.
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.
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.
Changed handling of monitor IDs.
Fixed QoS target and source.
Added support for infrastructure 3 (VirtualCenter 2.x and ESX 3.x).
Added template support.
Changed GUI icons.
Changed start up script to support Solaris.
Improved certificate handling.
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 theCA Unified Infrastructure Managementserver.
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 Managementv8.2 or later is recommended.
The probe requires the following
- CA Unified Infrastructure Managementserver 7.1 or later.
We recommend that the
CA Unified Infrastructure Managementserver 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 ManagementRobot 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 Managementserver 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 Management5.1.1 or later.
Probe Specific Software Requirements for Infrastructure Manager users
The probe requires
CA Unified Infrastructure Management4.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.
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.
The following sections apply to users accessing the probe configuration GUI using
CA Unified Infrastructure ManagementInfrastructure 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 templatesare 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
onlyInfrastructure 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
- 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.
- Select thePublish Datacheck 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
Num Storage VMotions
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.
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:
- 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:
- In Infrastructure Manager, press SHIFT, then right-click the probe.
- SelectRaw Configurefrom the context menu.
- Add or change the following entry in thestartupsection:Key:optionsValue:-Xms32m -Xmx1000mThe value is case-sensitive.IMPORTANT!The Raw Configure tool has no error checking. Take care that any changes you make are valid before you continue.
This topic applies to users accessing the monitoring configuration GUI using
CA Unified Infrastructure ManagementInfrastructure 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 Managementprobes 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 Managementsnmptd 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:
- In the Add Group dialog box, navigate to the Properties tab > Add filter> select Advanced from the filters drop-down.
- Click the Select advanced attribute field, and select one of the following:
- Enter the string to match the attribute you have selected.
- Click Apply Filters.
- 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:
- Upgrade and start the vmware probe.
- Navigate toAdmin Console>Raw Configure>Setup, and add the config key'filter_out_vms_with_vm_name_matching_regex'
- Specify the value with 'VM name' of the VM(s) you want to exclude under the setup section via raw configure.
- Save the changes and restart the probe.
- 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
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
To disable the alarms and QoS, follow these steps:
- Do one of the following:
- Navigate toAdmin Console>Raw Configure>Setup, > config key'disable_qos_and_alarms_for_maintenance_mode_hosts'True. OR
- Navigate to vmware probe inIM> right-click and selectConfigure>Setup, config key'disable_qos_and_alarms_for_maintenance_mode_hosts'True.
- 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:'IsInMaintenanceMode'=True.
- 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
Solution: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
Symptom:When configuring monitoring template for vmware probe from Admin Console > Template Editor, we do not see the new messages defined in vmware.cfg.
Solution:A new callback
)was added to fix this.
Follow these steps:
- Navigate to the vmware.cfg file.
- Add the message(s) in the vmware.cfg file, using a text editor.
- Run and execute the'sync_template_definition'callback from the probe utility.The callback will sync the templateDefinitions.zip with the messages in the vmware.cfg file.
- 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
Symptom:vmware probe randomly stops collecting QoS.
Follow these steps
- 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
- On the robot where vmware is installed, login to Admin Console> vmware, under Probes page, right click and select Raw Configure.
- On the right side pane, select Add New Key (+ icon).
- Enter'value_if_datastore_uncommitted_space_is_unset'as the config key.
- Provide appropriate value(in Bytes) in the'value'field . For example 0.
- Click Create.
- 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
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
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
Symptom: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.
Solution: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.
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:
- In Admin Console, select thexenserverprobe.
- ClickRaw Configure.
- ClickAdd keyand add the key/value for each of the following pairs:KeyValueasynchnohasmax100isboolnounitpercent
- ClickApply.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:
- In Admin Console, select thevmwareprobe.
- ClickRaw Configure.
- ClickRemove keyand remove each of the following key/value pairs:KeyValueasynchnohasmax100isboolnounitpercent
- ClickApply.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.
Probe returns inconsistent data for the Memory Shared (% of MemorySize) metric.
v6.21 and 6.30:
- Go to the vmware.cfg file.
- In the vmware.cfg file, search for:Memory Shared (% of Memory Size).
- Replace every instance of Memory Shared (% of Memory Size) with:Memory Shared (% of Memory)IMPORTANT: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.
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 Managementwiki.
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 Management7.0 or 7.1.
CA Unified Infrastructure Management7.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.
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:22.214.171.124"."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'.
IMPORTANT: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:
- Verify you have administrator privileges and a 6.12 or later release of the probe.
- ClickRaw Configureon the context menu.The probe Raw Configure window opens.
- Click thesetupsection.The Keys and Values for the setup section are displayed in the right pane.
- SelectAdd key.The Add key dialog opens.
- Enter "force_services_refresh" and clickAdd.
- Click in the Value column for the "force_services_refresh" Key, enter "true" for the Value, and press Enter.
Known Issues and Work-arounds for Infrastructure Manager Users Only
This section describes some known issues and work-arounds that apply
onlyto 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:
- Shift + right-click on the probe in Infrastructure Manager.
- ChooseRaw Configurefrom the menu.
- Clickstartupin the left pane.
- Select theoptionskey and open it for editing.
- Enter a value similar to the following:-Xms256m - Xmx<nnnn>mwhere <nnnn> is heap space up to 2048 MB or greater. For example, to increase the heap space to 1024 MB, enter the following:-Xms256m - Xmx1024mEnsure the machine where the robot and probe are deployed has enough RAM.
- 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 ManagementInfrastructure 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.