Difference between revisions of "ZenPack:VMware vSphere"

From Zenoss Wiki
Jump to: navigation, search
Line 8: Line 8:
 
|Version=3.2.1
 
|Version=3.2.1
 
|Release date=2015/07/17
 
|Release date=2015/07/17
|Compatible with=Zenoss Resource Manager 4.2.x
+
|Compatible with=Zenoss Resource Manager 4.2.x, Zenoss Resource Manager 5.0.x
 
|Incompatible with=Zenoss Resource Manager 4.1.x
 
|Incompatible with=Zenoss Resource Manager 4.1.x
 
|Requires=PropertyMonitor, Enterprise Reports,
 
|Requires=PropertyMonitor, Enterprise Reports,

Revision as of 19:50, 3 August 2015


Note: This ZenPack is available in commercial versions of Zenoss. Click here to request more information about this commercial ZenPack. Click here to see all commercial ZenPacks.

Organization
Zenoss, Inc.
ZenPack name
ZenPacks.zenoss.vSphere
More Information
GitHub page/HomePage


Applications Monitored: 



VMware vSphere ZenPack

Monitoring for VMware vSphere environments.

Warning

The ZenPack Catalog has moved to its new home at https://www.zenoss.com/product/zenpacks as of January 17, 2017. The following information may be out of date, and this page will eventually be removed.

Support

This ZenPack is included with commercial versions of Zenoss and enterprise support for this ZenPack is provided to Zenoss customers with an active subscription.

Releases

Version 3.2.1- Download
Released on 2015/07/17
Requires PropertyMonitor ZenPack,Enterprise Reports ZenPack
Compatible with Zenoss Resource Manager 4.2.x, Zenoss Resource Manager 5.0.x
Incompatible with Zenoss Resource Manager 4.1.x
Version 3.1.2- Download
Released on 2015/05/28
Requires PropertyMonitor ZenPack,Enterprise Reports ZenPack
Compatible with Zenoss Resource Manager 4.2.x, Zenoss Resource Manager 5.0.x
Incompatible with Zenoss Resource Manager 4.1.x
Version 3.0.4- Download
Released on 2014/04/07
Compatible with Zenoss Resource Manager 4.2.x
Incompatible with Zenoss Resource Manager 4.1.x

Background

This ZenPack provides support for monitoring VMware vSphere. Monitoring is performed through a vCenter server using the vSphere API.

Bulbgraph.png Note: This ZenPack supersedes an earlier ZenPack named ZenPacks.zenoss.ZenVMware. If you have ZenPacks.zenoss.ZenVMware installed on your system, please read the #Transitioning from ZenVMware section below.

Gallery

Features

The features added by this ZenPack be summarized as follows. They are each detailed further below.

  • Initial discovery and continual synchronization of relevant components.
  • Performance monitoring.
  • Event management.
  • Service impact and root cause analysis. (Requires Zenoss Service Dynamics)
  • Operational reports.

Discovery

The following components will be automatically discovered through the vCenter address, username and password you provide. The properties and relationships will be continually maintained by way of a persistent subscription to vSphere's updates API.

Datacenters
Clusters
Resource Pools
Datacenters
Attributes: None
Relationships: Clusters and Standalone Compute Resources, Resource Pools, vApps, VMs, Hosts, Networks, dvSwitches, dvPortgroups, Datastores.
Clusters and Standalone Compute Resources
Attributes: Total Hosts, Effective Hosts, CPU Cores, CPU Threads, Total CPU, Effective CPU, Total Memory, Overall Status
Relationships: Datacenter, Host(s), Resource Pools
Resource Pools
Attributes: CPU Limit, CPU Reservation, Memory Limit, Memory Reservation, Overall Status
Relationships: Datacenter, Cluster or Standalone Compute Resource, Parent Resource Pool, Child Resource Pools, vApps, VMs.
vApps
Attributes: CPU Limit, CPU Reservation, Memory Limit, Memory Reservation, Overall Status
Relationships: Datacenter, Cluster or Standalone Compute Resource, Resource Pool, VMs
VMs
Attributes: OS Type, Guest Name, Memory, CPUs, Template?, Connection State, Power State, Overall Status
Relationships: Datacenter, Resource Pool or vApp, vNICs, Host, Datastores
vNICs
Attributes: MAC Address
Relationships: VM, Network or dvPortgroup
Hosts
Attributes: Hostname, Total Memory, In Maintenance Mode?, Connection State, Power State, Overall Status
Relationships: Datacenter, Cluster or Standalone Compute Resource, VMs, Host NICs, Datastores, LUNs
Host NICs
Attributes: MAC Address
Relationships: Host
Networks
Attributes: Accessible?, IP Pool Name
Relationships: Datacenter, Attached vNICs
dvSwitches
Attributes: None
Relationships: Datacenter, dvPortgroups
dvPortgroups
Attributes: Accessible?, IP Pool Name, Key UUID
Relationships: Datacenter, dvSwitch, Attached vNICs
Datastores
Attributes: Type, Capacity, Free Space, Uncommitted, URL, NAS Host, NAS Path, NAS Username, Local Path
Relationships: Datacenter, LUNs, Attached Hosts, Attached VMs
LUNs
Attributes: Disk Name, Disk Key, Device Name, Type, Vendor, Model, UUID, Operational Status
Relationships: Host, Datastores

Performance Monitoring

The following metrics will be collected every 5 minutes by default. Any other vSphere metrics can also be collected by adding them to the appropriate monitoring template.

VMs
Host NICs
Clusters
effectiveCPU: clusterServices / effectivecpu (AVERAGE)
effectiveMem: clusterServices / effectivemem (AVERAGE)
Hosts
cpuReservedcapacity: cpu / reservedCapacity (AVERAGE)
cpuUsage: cpu / usage (MAXIMUM)
cpuUsagemhz: cpu / usagemhz (MAXIMUM)
diskUsage: disk / usage (MAXIMUM)
memActive: mem / active (MAXIMUM)
memConsumed: mem / consumed (AVERAGE)
memGranted: mem / granted (MAXIMUM)
memSwapused: mem / swapused (MAXIMUM)
sysUpTime: sys / uptime (LATEST)
LUNs
diskRead: disk / read (AVERAGE)
diskReadRequests: disk / numberRead (SUMMATION)
diskWrite: disk / write (AVERAGE)
diskWriteRequests: disk / numberWrite (SUMMATION)
Host NICs
nicRx: net / received (AVERAGE)
nicTx: net / transmitted (AVERAGE)
Resource Pools
cpuUsagemhz: cpu / usagemhz (AVERAGE)
memActive: mem / active (AVERAGE)
memGranted: mem / granted (AVERAGE)
VMs
cpuUsage: cpu / usagemhz (AVERAGE)
cpuUsageAvg: cpu / usage (AVERAGE)
cpuUsageMax: cpu / usage (MAXIMUM)
cpuUsageMin: cpu / usage (MINIMUM)
diskUsage: disk / usage (AVERAGE)
memConsumed: mem / consumed (MINIMUM)
memOverhead: mem / overhead (MINIMUM)
memUsage: mem / usage (MINIMUM)


In addition, any other metric exposed by vSphere may be added to a Zenoss monitoring template. This must be done cautiously, however. It is critical to only add metrics that are applicable to the component that the template is bound to, and which are supported by the VMware instances you are monitoring.

Because Zenoss batches multiple performance queries together, adding an unsupported metric may cause unrelated performance graphs to break. The 'Test' function must be used to verify that any newly added datasource will work correctly.


Event Management

The following event classes and their subclasses will be continually collected and passed into the Zenoss event management system.

Events
  • Alarm
  • Event
  • ExtendedEvent
  • EventEx

Various information encoded in these event classes will be used to automatically determine as best as possible the following Zenoss event fields.

Standard Zenoss Event Fields
  • device (set to VMware vSphere Endpoint device in the /vSphere device class)
  • component
  • summary
  • severity
  • eventClassKey (for mapping specific event types)
  • eventKey (for de-duplication and auto-clear fingerprinting)
Additional Event Fields
  • description


Events collected through this mechanism will be timestamped based on the time they occurred within vCenter. Not by the time at which they were collected.

Service Impact and Root Cause Analysis

When combined with the Zenoss Service Dynamics product, this ZenPack adds built-in service impact and root cause analysis capabilities for services running on VMware vSphere. The service impact relationships shown in the diagram and described below are automatically added. These will be included in any services that contain one or more of the explicitly mentioned components.

Impact Relationship Diagram
Internal Impact Relationships
  • vCenter access failure impacts all datacenters.
  • Datacenter failure impacts all related hosts, networks, dvSwitches, dvPortgroups and datastores.
  • Host failure impacts the related cluster or standalone compute resource, and resident VMs.
  • Host NIC failure impacts the related host.
  • Network failure impacts related vNICs.
  • dvSwitch failure impacts related dvPortgroups.
  • dvPortgroup failure impacts related vNICs.
  • Datastore failure impacts attached VMs.
  • Cluster or standalone compute resource failure impacts related resource pools and vApps.
  • Resource pool failure impacts child resource pools, related vApps and related VMs.
  • vApp failure impacts related VMs.
  • vNIC failure impacts the related VM.
External Impact Relationships
  • vNIC failure impacts guest operating system device's related NIC.
  • VM failure impacts guest operating system device.
  • NAS file storage providers impact related datastores.
  • SAN block storage providers impact related datastores.
  • Resource pool failure impacts related vCloud provider and organizational VDCs.
  • VM failure impacts related vCloud VM.
  • Cisco UCS vNIC failure impacts related host NIC.
  • Cisco UCS service profile failure impacts related host.
  • VM failure impacts Cisco Nexus 1000V VSM running as guest.
  • Host failure impacts related Cisco Nexus 1000V VEM.
  • Host NIC failure impacts related Cisco Nexus 1000V ethernet uplink.
  • Cisco Nexus 1000V vEthernet impacts related vNIC.


Most of the impacts described above follow the default policy of a node being in the worst state of the nodes that impact it. For example, a datacenter failure will imply that all related hosts are also failed. In some cases this is not appropriate and custom policies are used.

VM in Example Service
Custom Impact Policies
  • vCenter access failure will only cause related datacenters to be ATRISK because they're probably still functioning, but may be unmanageable.
  • Host NIC failure will only imply a host DOWN if all of the host's NICs have failed. If a subset have failed the host will be implicitly ATRISK.
  • Host failure will only imply a cluster DOWN if all of the cluster's hosts have failed. If a subset have failed the cluster will be implicitly ATRISK.
  • vNIC failure will only imply a VM DOWN if all of the VM's vNICs have failed. If a subset have failed the VM will be implicitly ATRISK.
  • Datastore failure will only imply a VM DOWN if all of the VM's datastores have failed. If a subset have failed the VM will be implicitely DEGRADED.


Operational Reports

The following operational reports are included with this ZenPack. They can be found in the vSphere report organizer.

VMs Report
Operational Reports
  • Clusters
Shows all clusters, with the count of VMs (total and powered on), hosts, and CPU/Memory utilization within each cluster.
  • Datastores
Shows all datastores, with the number of connected VMs (total and powered on) and the disk space available and consumed on each datastore.
  • Hosts
Shows all hosts, with the count of VMs (total and powered on), hosts, and CPU/Memory reservation and utilization on each host
  • VMs
Shows all VMs, their operating system, CPU and memory utilization, and which host/cluster they reside within.
  • VMware Utilization
Provides an summary of VMs, cpu, memory, and disk utilization over a specified time interval, broken down by host.


Usage

Adding vSphere Endpoint

Use the following steps to start monitoring vSphere using the Zenoss web interface.

  1. Navigate to the Infrastructure page.
    Add Menu Item
  2. Choose Add VMware vSphere Endpoint from the add device button.
  3. Fill out the form.
    Add Dialog
    • Name can be anything you want.
    • Hostname or IP must be resolvable and accessible from the collector server chosen in the Collector field.
    • Username and Password are the same as what you'd use in the vSphere client.
    • SSL should almost certainly be left enabled.
  4. Click ADD.



Alternatively you can use zenbatchload to add vSphere endpoints from the command line. To do this, you must create a file with contents similar to the following. Replace all values in angle brackets with your values minus the brackets. Multiple endpoints can be added under the same /Devices/vSphere section.

/Devices/vSphere loader='VMware vSphere', loader_arg_keys=['title', 'hostname', 'username', 'password', 'ssl', 'collector']
vcenter1 hostname='<address>', username='<username>', password='<password>'

You can then load the endpoint(s) with the following command.

zenbatchload <filename>

Transitioning from ZenVMware

If you are installing this ZenPack on an existing Zenoss system or upgrading from an earlier Zenoss version you may have a ZenPack named ZenPacks.zenoss.ZenVMware already installed on your system. You can check this by navigating to Advanced -> ZenPacks.

This ZenPack functionally supersedes ZenPacks.zenoss.ZenVMware, but does not automatically migrate monitoring of your VMware vSphere resources when installed. The ZenPacks can coexist gracefully to allow you time to manually transition monitoring to the newer ZenPack with better capabilities.

Depending on how heavily loaded your vCenter and Zenoss server(s) are you may wish to avoid monitoring the same vSphere resources twice in parallel. If this is the case, you should use the following instructions to first remove the existing vSphere monitoring before adding the new monitoring.

  1. Navigate to the Infrastructure page.
  2. Expand the VMware device class.
  3. Single-click to select a vCenter.
  4. Click the delete (-) button in the bottom-left.
  5. Click OK to confirm deleting the vCenter.
  6. Add the vCenter back using the #Adding vSphere Endpoint instructions above. Be sure to select Add VMware vSphere Endpoint and not Add VMware Infrastructure.
  7. Repeat steps 3-6 for each vCenter.

If you're comfortable monitoring the vCenters twice in parallel for a time, you can simply follow the instructions under #Adding vSphere Endpoint then delete the old vCenters from the /VMware device class once you're satisfied with the new monitoring.

Installed Items

Installing this ZenPack will add the following items to your Zenoss system.

Configuration Properties
  • zVSphereEndpointHost
  • zVSphereEndpointUser
  • zVSphereEndpointPassword
  • zVSphereEndpointUseSsl
  • zVSpherePerfQueryChunkSize: How many performance requests to make at a time. Defaults to 50.
  • zVSpherePerfWindowSize: How many intervals of data to ask for in each performance request. Defaults to 2.
  • zVSpherePerfDelayCollectionMinutes: How long to lag performance data collection. Defaults to 0.
  • zVSphereModelIgnore: (See "Tuning Modeling" below)
  • zVSphereModelCache
Device Classes
  • /vSphere
Modeler Plugins
  • vmware.vSphere
Datasource Types
  • VMware vSphere
Monitoring Templates
  • vSphereCluster (in /vSphere)
  • vSphereHostSystem (in /vSphere)
  • vSphereLUN (in /vSphere)
  • vSpherePnic (in /vSphere)
  • vSphereResourcePool (in /vSphere)
  • vSphereVirtualMachine (in /vSphere)
Collector Daemons
  • zenvsphere

Troubleshooting

If any issues are encountered with the functionality offered by this ZenPack, the following checklist should be followed to verify that all configurations are correct.

Configuration Checklist

  1. Verify that Zenoss has been fully restarted after the ZenPack was installed.
  2. Verify that the endpoint's address, username and password are correct. Check the zVSphereEndpointHost, zVSphereEndpointUser and zVSphereEndpointPassword configuration properties for the endpoint device. Specifically make sure that you can use the vSphere client with this same information.
  3. Verify that the Zenoss collector server to which the endpoint device is assigned has network connectivity through any firewalls to the endpoint address on port 443/tcp (https).
  4. Verify that the zenvsphere daemon is running on the collector to which the endpoint device is assigned.
  5. Check the logs. See #Logging below.
  6. Kill zenvmware-client subprocess. See #Java Subprocess below.
  7. Tune configuration properties according to #Collection Performance Tuning instructions below if necessary.

NTP

An often-overlooked Zenoss deployment issue is the synchronization of time between data sources and data collectors, especially when the collected data is timestamped at the source. It is not unusual for the hardware clocks in computers to drift by seconds per day, accumulating to significant error in just a week or two.

The Zenoss data collector for vSphere will adjust for time zone and clock skew differences every 2 hours (by comparing the server current time with the collector's) so even without NTP, events and graphs will have correct timestamps in Zenoss. If the clocks are not synchrhonized, however, the timestamps shown in zenoss and vSphere for the same event will not match, and this can cause considerable confusion.

  • Be sure that both Zenoss collector and ESX endpoint are configured for automatic time correction using NTP.
  • To further reduce confusion, it is recommended that the collector and endpoint be configured for the same time zone.

Logging

Logs can be found in $ZENHOME/log/<collectorname>/zenvsphere.log. By default only INFO and higher priority messages will be logged. To temporarily increase the logging level to include DEBUG messages you can run zenvsphere debug as the zenoss user without restarting the daemon. The next time it restarts, logging will resume at the preconfigured level. Alternatively you can run zenvsphere debug again to return logging to the preconfigured level.

Java Subprocess

The zenvsphere daemon spawns a java process named zenvmware-client as needed to communicate with vSphere endpoints. It may be possible that this java process encounter a problem that zenvsphere is unable to detect or recover from. If you're experiencing issues you can run pkill -9 -f zenvmware-client as the zenoss user to kill the java process. It will be automatically restarted.

Collection Performance Tuning

The zVSpherePerfQueryChunkSize, zVSpherePerfDelayCollectionMinutes and zVSpherePerfWindowSize configuration properties can be used to tune the collection of performance data from the vSphere endpoint.

In cases where a vCenter server is overloaded it may have trouble keeping up with the performance data aggregation it is supposed to perform. This can result in inaccurate data being collected by Zenoss and can represent as gaps in graphs or graphing of 0 values where 0 is not correct. The zVSpherePerfDelayCollectionMinutes property can be used to ask for data that is older and therefore more likely to have finished aggregation. If the default value of 0 is not working it is recommended to increase this value in 5 minute increments.

Some vSphere endpoints have been observed to not have up to date information available for some types of resources unless a larger window of data is asked for. In testing this seems to happen most frequently for resource pools. If you find that all component graphs are populated except for resource pools, it is recommended to increase zVSpherePerfWindowSize to 6. This causes Zenoss to collect 6 values for each datasource every cycle instead of 2 which will be a performance impact. So it is only recommended to increase zVSpherePerfWindowSize if necessary.

NOTE: When using a non-default zVSpherePerfWindowSize or zVSpherePerfDelayCollectionMinutes setting against a large vCenter instance, the guideline is to ensure that 5 * zVSpherePerfWindowSize + zVSpherePerfDelayCollectionMinutes is less than 30. This keeps the queries against vCenter within the last 30 minutes, which allows it to use cached values rather than querying its database. We have also observed that when this number is exceeded, datastore related metrics (such as datastore.numberReadAveraged.AVERAGE) can stop working altogether. This has been observed on vCenter 5.0.0, but it may impact more recent versions as well.

Tuning Modeling

Normally, the set of objects and attributes to be modeled and how they should be processed is predefined in this ZenPack. However, a limited amount of tuning is possible via the properties zVSphereModelIgnore and zVSphereModelCache.

zVSphereModelIgnore is used to suppress collection of an attribute or attributes, perhaps because it changes too frequently or is not of interest in a particular environment. Its value is a list of regular expressions which must match against a string of the format "<vmware managed resource class>:<vmware property name>" For example, "VirtualMachine:summary.guest.toolsStatus" would be matched by "toolsStatus" or "VirtualMachine.*toolsStatus".

NOTE: These are values are VMware classes and properties, not Zenoss classes and properties. They are generally similar, but there are exceptions. For a list of allowed values, consult $ZENHOME/ZenPacks/ZenPacks.zenoss.vSphere*/ZenPacks/zenoss/vSphere/gather_config.json

zVSphereModelCache is used to configure caching (change detection) for a specific set of properties. This is also defined as a set of regular expressions, only this time, the value is "<zenoss class name>:<zenoss property/method name>". It is especially rare that you would need to use this configuration option. It is specifically intended for situations where issues with the vSphere data model or API cause use to be repeatedly notified about an property which has not actually changed its value. When caching is turned on for the affected attribute, the collector will keep track of the prior value of the property, and will only notify zenhub if the value actually changes. This saves unnecessary load on zenhub. A list of properties that need this functionality are built into the collector, and this configuration option is only used to add additional properties to the list, should a new one be found. There is generally no benefit to using this caching feature where it is not needed, but no major downside either, other than increased memory usage on the collector. Should you find a property where this caching is needed, please notify Zenoss so that we may make this behavior the default in future versions of this ZenPack.

Zenoss Analytics

This ZenPack provides additional support for Zenoss Analytics. Perform the following steps to install extra reporting resources into Zenoss Analytics after installing the ZenPack.

  1. Copy vsphere-analytics.zip from $ZENHOME/ZenPacks/ZenPacks.zenoss.vSphere*/ZenPacks/zenoss/vSphere/analytics/ on your Zenoss server.
  2. Navigate to Zenoss Analytics in your browser.
  3. Login as superuser.
  4. Remove any existing vSphere ZenPack folder.
    1. Choose Repository from the View menu at the top of the page.
    2. Expand Public in the list of folders.
    3. Right-click on vSphere ZenPack folder and choose Delete.
    4. Confirm deletion by clicking OK.
  5. Add the new vSphere ZenPack folder.
    1. Choose Server Settings from the Manage' menu at the top of the page.
    2. Choose Import in the left page.
    3. Remove checks from all check boxes.
    4. Click Choose File to import a data file.
    5. Choose the vsphere-analytics.zip file copied from your Zenoss server.
    6. Click Import.

You can now navigate back to the vSphere ZenPack folder in the repository to see the resources added by the bundle.

The vSphere Domain can be used to create ad hoc views using the following steps.

  1. Choose Ad Hoc View from the Create menu.
  2. Click Domains at the top of the data chooser dialog.
  3. Expand Public then vSphere ZenPack.
  4. Choose the vSphere Domain domain


Changes

3.2.1
  • Fix for CiscoUCS startup issue (ZEN-18814)
3.2.0
  • Improve reliability of modeling of vSphere alarm events (model pre-existing alarms at startup and apply updates to alarms based on change events).
  • Make alarm events more easily filtered, with an eventGroup of 'vim.event.AlarmEvent' and an eventClassKey of the vSphere alarm systemName for vmware's predefined events, or 'userdefined.<id> for user defined alarms.
  • Remove 'overall status' column and stop collecting this value from vSphere. Compute equivalent value based upon most severe active alarm on the element.
  • Impact now relies upon active events (alarms) and ignores the 'overall status'. Undesired alarms may now be more easily suppressed or transformed to improve impact view, and root cause will reflect the responsible alarms. (ZEN-16728)
  • Add model collection tuning options (zVSphereModelIgnore, zVSphereModelCache)
  • Reduce zenhub load by suppressing duplicate (unnecessary) setDiskNames calls on datastores
  • Add several predefined thresholds (disabled by default)
  • Improved logging and idle connection cleanup in java txvsphere process
  • Improved connection performance and FD leak in java txvsphere process when an endpoint is unresponsive
  • Add support for Layer2 ZenPack and network map
  • Fix time zone handling for event collection
  • Add link from LUN to underlying storage device (ZEN-18029)
  • Increase default all vSphere API calls. Lowered timeout during login, and raised during performance querying.
  • Collect host hardware vendor/model and management IP addresses
  • Fix error encountered when a vApp contains child resource pools (ZEN-17670)
3.1.3
  • Fix potential missed linkage of UCS service profiles to vSphere hosts. (ZEN-18631)
3.1.2
  • Fix ConnectionStateError. (ZEN-16924)
3.1.1
  • Fix bug that halted data collection that after a single TimeoutError (ZEN-10927)
  • Fix handling of broken standalone resources in vSphere (ZEN-16382)
  • Background java process exits when zenvsphere is shut down (ZEN-15431)
  • Ensure java process is restarted automatically if zenpack is upgraded
  • Restart java process with proper settings if it is started with default memory settings by zenmodeler (ZEN-16833)
  • Fixes to VMware Utilization report (ZEN-15523)
  • Add hypervisor version to UI (ZEN-15901)
  • Model optimization on Zenoss >= 4.2.4 SP728, 4.2.5 SP316 and 5.0.0. (ZEN-17058)
3.1.0
  • Add support for Zenoss Analytics
  • Add support for VMware vSphere 5.5
  • Improvements to impact model
  • This zenpack now depends upon ZenPacks.zenoss.PropertyMonitor.
  • Corrected handling of errors in performance data collection (ZEN-11086)
  • Improved vsphere_queryperf and added interactive testing of data sources in monitoring templates
  • Fix traceback that can occur after a connection has been lost and reconnected (ZEN-11033)
  • Fix datastore-released performance data collection under vmware 4.1 (ZEN-11110)
  • Fixed file descriptor leak that would result in an endless cycle of TimeoutErrors under certain conditions (ZEN-10927)
  • Avoid "pool exhaustion" errors by terminating the oldest connection to vsphere when the session limit is exceeded, rather than immediately failing. (ZEN-10325)
  • Model linkSpeed on physical NICs and compute bandwidth utilization.
  • Model used and uncommitted percentages on datastores, and add graphs of capacity utilization over time (ZEN-11256)
  • Add graphs of VM state (ZEN-11255)
  • Add total memory to Cluster and Host graphs (ZEN-10890)
  • Add VMWare tools, VM Hardware, and ESX software versions. (ZEN-13442)
  • Correct units for storageCommitted and storageUncommitted (ZEN-15233)
  • Separate vApp and Pool counts on Datacenter grid (ZEN-15272)
  • Fix potential exception in default event mapping for vSphere (ZEN-12410)
  • Improve error reporting when invalid or duplicate hostnames or IPs are specified while adding an endpoint (ZEN-11907, ZEN-14272)
  • Properly indicate if there are open events for VMs and DistributedVirtualSwitches (ZEN-12434)
  • Ignore invalid NICs with no mac address (ZEN-10154)
  • Calculate vm_count for ResourcePools recursively. (ZEN-14262)
  • Correct issue where relationships between Datastore and LUN could be missed during initial model (ZEN-13124)
  • Add support for performance counters on vNICs (ZEN-12106)
3.0.4
  • Reduction of invalidations caused by vSphere model changes. (ZEN-10838)
  • Remove modeling of guestHeartbeatStatus. (ZEN-10838)
  • Ignore pNICs with empty MAC addresses. (ZEN-10836)
3.0.2
  • Disable modeling optimization that led to POSKeyError errors.
  • Multiple improvements in vSphere API error recovery and session management.
  • Reduce pool exhaustion issues. Add related tuning options.
  • Continue collecting data when /Status/Ping events exist for endpoints.
  • Fix error caused by /usr/bin/java being non-existent or the wrong JRE.
  • Fix error caused by noexec option on /tmp filesystem. (ZEN-10076)
  • Notify user of attempt to add duplicate endpoint. (ZEN-10741)
  • More detailed logging.
3.0.1
  • Add vsphere_gather and vsphere_queryperf command line troubleshooting tools.
  • Add power state to VM component display panel.
  • Add LUN ID to LUN component display panel.
  • Add proper counting of VMs for licensing purposes.
  • Fix bug that would prevent editing of VMware vSphere datasources on Zenoss 4.1.
  • Fix SAN storage impact relationships.
  • Fix modeling bug on some vSphere endpoints.
3.0.0
  • Initial release.

Installation

Normal Installation (packaged egg)

  1. Download the appropriate egg file for the version of Zenoss you are running.
  2. Ensure you are logged in as the zenoss user:
    $ sudo su - zenoss
  3. Install the ZenPack:
    $ zenpack --install ZenPacks.zenoss.vSphere-*.egg
  4. Restart these services:
    $ zenoss restart


Discuss

Purplemarker.png New: Don't forget to add yourself to the Zenoss User Map!

blog comments powered by Disqus