Cloud Hub for VMware

GroundWork Cloud Hub Deployment for VMware

Initial Setup

To enable the Cloud Hub so that it monitors the virtual environment of your choice several simple setup steps are necessary. In order to create performance graphs for the virtual environment checks the performance data profile needs to be loaded into the configuration database.

The following steps only need to be executed once on initial setup

Log into GroundWork Monitor as an Administrator.
Select Configuration>Profiles, and navigate to Profile Importer>Import>VMware.
Select all service profiles for cloudhub as shown in the image below.
Click the Import button, an import status screen will be displayed, select Close.

Cloud Hub Configuration

To configure the cloud hub perform the following steps:

Log into GroundWork Monitor as an Administrator.
Select Administration>Cloud Hub for VMware.
Select Start new configuration.

You will need to provide the following values:

GroundWork Server Name - Enter the name of the GroundWork server that will integrate the Cloud Hub messages. The Cloud Hub is running on the same server as the portal, the name can be localhost or as preferred, the server name.
Is SSL enabled on GroundWork Server - Check this box if the GroundWork server is configured for secure HTTPS.

GroundWork Web Service Username/Password - This is the user and password configured to access the Web Service API. The default user is wsuser. These are the same credentials set in /usr/local/groundwork/config/ws_client.properties.

Important for LDAP enabled systems: Make sure that it matches with the entry in the ws_client.properties file and the user is member of the Authenticated group and the WSUser (or GWUser) group in LDAP.

ESX Server name - Enter the server that is hosting the VSphere server 5 or ESXi 5 instance that will be used to retrieve the data. The VSS/ESXi server needs to be configured for
- ESX Server URI - The default is sdk. Don't change this unless you have reconfigured the ESX/VSS API setup.
- ESX Username - This value is setup while configuring the account.
- ESX Server Password - This value is setup while configuring the account.
Check Interval: This is the polling interval for collecting monitoring data from the Virtual instance and sending it to the GroundWork server. The value is in minutes.
To validate the configuration entered select the Test Connection button which will check if the Virtual Instance is accessible with the given credentials. After the credentials have been validated click Next to select the Metrics that need to be monitored.

Monitoring Profiles for Virtual Environments

The master Monitoring profiles for Virtual Environments are stored on the GroundWork server. Each time the user goes into the configuration screens for Cloud Hub the Monitoring profile from the GroundWork server would be loaded into the Cloud Hub. This allows to you to manage and maintain the Monitoring Profiles for Cloud Hub in a central location.

The location for the Cloud Hub Monitoring profile is:

/usr/local/groundwork/core/vema/profiles/

And for the VMware Monitoring profile:

vmware_monitoring_profile.xml

Hypervisor Metrics

The metrics screen allows a user to define if a metric should be monitored and graphed. It allows you to define the thresholds for Warnings and Critical. It is recommended to use the synthetic metrics (computed percentages) since it helps to define the threshold values in a 0-100% range.

Virtual Machine Metrics

The metrics screen allows a user to define if a metric should be monitored and graphed. It allows you to define the thresholds for Warnings and Critical. It is recommended to use the synthetic metrics (computed percentages) since it helps to define the threshold values in a 0-100% range.

After saving the settings monitoring will start immediately synchronizing all Hypervisors and Guest found in the Management server or Hypervisor with the GroundWork server. The monitoring can be adjusted by returning to the Cloud Hub configuration screen and modifying metrics collected (check/un-check) or modifying threshold values.

VMware Metrics

The VMware API (application programming interface) defines a set of metrics (measurements regarding performance, resource utilization, bandwidth) that apply to hypervisors (physical machines), hosts (virtual machines), networks and datastores (disk partitions). The metrics gathered by CloudHub are of two kinds: native and synthetic. The strings that define the native metrics are exactly those supported by the VMware API, with certain restrictions, namely that the list must be from those metrics that result in values, and not lists of objects.

The majority of the metrics are numeric in nature - amounts of "MHz" (megahertz, in VMware parlance), amounts of memory (bytes, megabytes), amounts of disk space (bytes, megabytes, gigabytes). Again, they are taken in their native form, neither normalized nor adjusted.

Synthetic Utilization Statistics versus Native VMware Metrics

The native metrics lack a sense of normalization, as an example a host (VM/virtual machine) may have a metric for CPU utilization of "273". The ?VMware documentation indicates that this value is in MHz (megahertz). However, in ferreting out system issues, it is often more useful to know what proportion of the total resource in question is in use. In other words, "273 of what?"

The synthetic metrics are pairs of native metrics, cast into percentage-of-total form. The numerator (number "on top") is a performance metric, and the denominator (divisor "on the bottom") is the "sum of, or size of a resource". Synthetic metrics can be extremely helpful in deciphering performance and accessibility issues in real-time. The percentages are bounded in the [0..100] range, and they include the "%" character at the end.

Synthetic Performance and Resource Utilization Statistics

The following table lists the synthetic metrics that are supported at present in the VEMA CloudHub performance monitoring API. As a reminder - these are all percentages in the range of [0..100]. The metrics marked as critical are necessary for the general operation of the API, and should not be removed.

Statistic Accessor String	Notes and Comments	Host	VM	Critical
syn.host.cpu.unused	% of CPU that is unused	Y
syn.host.cpu.used	% of CPU that is in use	Y
syn.host.mem.unused	% of memory that is unused	Y
syn.host.mem.used	% of memory that is in use	Y
syn.vm.cpu.cpuToMax.unused	Similar to above, but for VMs		Y	Y
syn.vm.cpu.cpuToMax.used	Similar to above, but for VMs		Y
syn.vm.mem.balloonToConfigMemSize.unused	These compare the [balloonMemory] statistics against the [totalMemory] of the virtual machine. Again, represented as a PERCENTAGE between 0-100.		Y	Y
syn.vm.mem.balloonToConfigMemSize.used	Used quantity compared to total		Y
syn.vm.mem.compressedToConfigMemSize.unused	[compressedMemory] compared to [totalMemory] - amount unused		Y	Y
syn.vm.mem.compressedToConfigMemSize.used	[compressedMemory] compared to [totalMemory] - amount in use		Y
syn.vm.mem.guestToConfigMemSize.unused	[guestMemory] ... to [totalMemory]		Y	Y
syn.vm.mem.guestToConfigMemSize.used	[guestMemory] ... to [totalMemory]		Y
syn.vm.mem.sharedToConfigMemSize.unused	[sharedMemory] ... to [totalMemory]		Y	Y
syn.vm.mem.sharedToConfigMemSize.used	[sharedMemory] ... to [totalMemory]		Y
syn.vm.mem.swappedToConfigMemSize.unused	[swappedMemory] ... to [totalMemory]		Y	Y
syn.vm.mem.swappedToConfigMemSize.used	[swappedMemory] ... to [totalMemory]		Y

Native Metrics

At a high level the following VMware metrics are supported. Some are required for use within the module to compute either synthetic statistics, or, for populating key operational access fields (such as IP address, MAC address) and cannot be excluded. The following table documents known metric accessor strings that are known as accessible in the CloudHub system. Those marked "critical" cannot be excluded from collection, as they figure critically into other components of the auto-configuration and data gathering supported by the VEMA API.

Statistic Accessor String	Notes and Comments	Host	VM	Critical
summary.config.memorySizeMB	e.g. 4092		Y
summary.config.name	e.g. VM-1234		Y
summary.config.numCpu	e.g. 2		Y
summary.config.numEthernetCards	e.g. 2		Y
summary.config.numVirtualDisks	e.g. 3		Y
summary.guest.hostName	e.g. www-dev-platform-3		Y	Y
summary.guest.ipAddress	e.g. 123.45.74.103		Y	Y
summary.hardware.cpuMhz	e.g. 3102	Y		Y
summary.hardware.memorySize	e.g. 16400 (could be long bytes tho')	Y		Y
summary.hardware.model	e.g. “Dell PowerEdge 192B”	Y		Y
summary.hardware.numCpuCores	e.g. 2	Y
summary.hardware.numCpuPkgs	e.g. 2	Y
summary.hardware.numCpuThreads	e.g. 8	Y
summary.hardware.vendor	e.g. “Dell”	Y
summary.quickStats.balloonedMemory	See VMWARE documentation. Important		Y
summary.quickStats.compressedMemory	See VMWARE documentation. Important		Y
summary.quickStats.consumedOverheadMemory	See VMWARE documentation. Important		Y
summary.quickStats.guestMemoryUsage	See VMWARE documentation. Important		Y
summary.quickStats.hostMemoryUsage	See VMWARE documentation. Important		Y
summary.quickStats.overallCpuDemand	See VMWARE documentation. Important		Y
summary.quickStats.overallCpuUsage	See VMWARE documentation. Important	Y	Y	Y
summary.quickStats.overallMemoryUsage	See VMWARE documentation. Important	Y		Y
summary.quickStats.privateMemory	See VMWARE documentation. Important		Y
summary.quickStats.sharedMemory	See VMWARE documentation. Important		Y
summary.quickStats.ssdSwappedMemory	See VMWARE documentation. Important		Y	Y
summary.quickStats.swappedMemory	See VMWARE documentation. Important		Y
summary.quickStats.uptime	Uptime in seconds	Y		Y
summary.quickStats.uptimeSeconds	Uptime in seconds		Y
summary.runtime.bootTime	... since boot time	Y	Y	Y
summary.runtime.connectionState	See VMWARE documentation. Important	Y	Y
summary.runtime.host	VMware name of host e.g. HOST-1234		Y
summary.runtime.maxCpuUsage	e.g. 175		Y
summary.runtime.maxMemoryUsage	e.g. 2021		Y
summary.runtime.memoryOverhead	See VMWARE documentation. Important		Y
summary.runtime.powerState	e.g. POWERED_ON / POWERED_OFF	Y	Y	Y
summary.storage.committed	e.g. 17300000000		Y
summary.storage.uncommitted	e.g. 12000000000		Y

The CloudHub data acquisition subsystem actually supports all numeric metrics that are accessible through the VMware API. As an example, we have tested the following metric strings and found them to work. They are not included in the configuration page XML file though, so they don't show up for configuration.

Statistic Accessor String	Notes and Comments	Host	VM	Critical
guest.guestState	Up, down		Y
guest.hostName	Coded as [host-1234]		Y	Y
guest.ipAddress	First IP address, if multiple		Y
guest.net	Complex object, not directly useful		Y
hardware.cpuInfo.hz	e.g. 3143234432	Y
hardware.cpuInfo.numCpuThreads	e.g. 8	Y
hardware.memorySize	e.g. 16342123000	Y
hardware.systemInfo.model	e.g. “Dell PowerEdge 192B”	Y
hardware.systemInfo.vendor	e.g. “Dell”	Y
name	Name of the entity, in VMware format.	Y	Y
runtime.powerState	e.g. POWERED_ON / POWERED_OFF	Y
vm		Y		Y

If you wish, you may carefully edit vmware_monitoring_profile.xml to include additional numeric metrics.

PLEASE test immediately - any metric test that is slightly misspelled or otherwise rejected by the VMware API short-circuits ALL the metrics from reporting, silently and without raising flags. In general, we can't recommend adding additional numeric metrics as at the time of this writing all the useful ones have been included as part of the release XML file contents.