Virtual Environment Monitoring

Red Hat® Enterprise Virtualization (RHEV) is one of the most widely used technologies by companies based on the Red Hat operating system in their Data Center. Pandora FMS offers the possibility of monitoring RHEV-based virtual architectures through the RHEV Monitoring Plugin.

• Data Centers.
• Host Clusters.
• Storage Domains.
• Networks.
• Hosts.
• Virtual Machines.

Pandora FMS uses the official API provided by the RHEV virtualization system.

RHEV virtual environment monitoring is based on the following components:

1. An Agent plugin that performs autodiscovery and data collection tasks. The Agent plugin is responsible for sending the information to Pandora FMS.
2. A reconnaissance script that updates various values for the discovered entities, necessary for the correct operation of the plugin extensions.
3. RHEV Viewer and RHEV Manager: These are extensions that provide the operation of shutting down/starting virtual machines, all from the Pandora FMS web Console.

The RHEV Monitoring Plugin extracts information through the web API served by the RHEV virtualization environment.

If only monitoring information is needed, the only thing that needs to be configured is the Agent plugin that will perform this task. The plugin configuration allows choosing which elements will be monitored and the configuration of their Modules. Once the XML files are created, the Agent plugin sends the files, either using Tentacle or by copying them to a local directory, depending on the chosen transfer method.

If you are also going to use the RHEV Viewer and RHEV Manager extensions, you will need to use the reconnaissance script. The reconnaissance script is responsible for updating variables for each of the Agents detected in Pandora FMS according to the values configured in RHEV. These variables are necessary to correctly visualize the entities in the RHEV Viewer extension and properly manage virtual machines with the RHEV Manager extension.

The Agent plugin requires the following software:

• curl.
• perl-XML-Simple.
• EndPoint PFMS and tentacle_client from Pandora FMS.

On Red Hat® based systems, you can install the dependencies with the command:

dnf install perl-XML-Simple curl

On SUSE based systems, you can install the dependencies with the command:

zypper install perl-XML-Simple curl

On Debian/Ubuntu based systems, you can install the dependencies with the command:

apt-get install libxml-simple-perl curl

Before using the plugin, it will be necessary to download the certificate that allows the HTTPS connection to the RHEV API. To do this, run the following command:

curl -o rhevm.cer http://[RHEVM-HOST]:8080/ca.crt

Where [rhevm-host] is the name of the server serving the RHEV API.

Once the certificate is downloaded, you can verify that the connection to the API is correctly performed with the following command using line connectors \:

curl -X GET \
  -H "Accept: application/xml" \ 
  -u [USER:PASS] \ 
  --cacert [CERT] https://[RHEVM-HOST]:8443/api

With the following values:

• USER: user @domain to connect to the API.
• PASS: Password of the user connecting to the API.
• CERT: Path to the certificate downloaded in the previous step.
• RHEVM-HOST: Address of the host serving the API.

If the command execution is successful, it will return output in XML format with general information about the RHEV API.

In the RHEV virtualization environment, it is possible for several entities to have the same name. This poses a problem since, in Pandora FMS, those entities will be transformed into Agents where duplicate names are not allowed. Furthermore, it will also cause problems when parsing the result returned by the API in XML format, showing an error similar to the following:

Warning: 
<data_center> element has non-unique value in 'name' key attribute
Default at ./plugin-rhev.pl line 199

To solve this problem, it is only necessary to follow a naming convention for the RHEV virtualization environment entities where names are not repeated.

To install the Agent plugin, you only need to copy the rhev-plugin.pl script and the rhev-plugin.conf configuration file into a directory on the machine where the Pandora FMS Agent that will execute the plugin is installed. The plugin can be executed on an Agent installed on the same machine as the Pandora FMS server or on a different machine.

To execute the plugin, you must add the following line to the Agent configuration file (by default /etc/pandora/pandora_agent.conf):

module_plugin /root/rhev-plugin.pl /root/rhev-plugin.conf

By adding this line, the Agent plugin will perform its functions in each execution.

To see the result of the Agent plugin execution, use the menu Operation → Monitoring → Views → Agent Detail. By clicking on the name of an Agent, you will be able to see the monitoring Modules created by the plugin, in addition to other related data.

The plugin creates an Agent in Pandora FMS for each of the entities detected in the RHEV architecture discovery. For each type of entity, a series of specific Modules are automatically created, monitoring the important information of each one of them.

If the selected Agent corresponds to a host instead of a Virtual Machine, the monitoring modules would be different.

The RHEV plugin also monitors events occurred within the virtual architecture. The plugin will create a Module for each monitored event within each affected entity. The data for the Modules created from events are event data: event time, event description.

In addition to the Agents and Modules related to the RHEV architecture itself, a Module called, by default, RHEV Plugin is generated in the Agent that executes the .*plugin.

• Status: Data Center status.

• Available Space: Available space in the Storage Domain.
• Committed Space: Committed space in the Storage Domain.
• Used Space: Used space in the Storage Domain.
• Percent Free Space: Percentage of free space in the Storage Domain.

• Status: Virtual network status.
• STP Status: Spanning Tree Protocol functionality status.

• Overcommit Percent: Cluster overcommit percentage.
• Transparent HugePages: Transparent HugePages functionality status.
• High threshold: Upper limit in planning policies.
• Low threshold: Lower limit in planning policies.
• Threshold duration: Duration of limits in planning policies.

• Status: host status.
• Buffers size: Buffers size.
• Cache size: Cache size.
• Cached swap: Amount of Swap caching memory (in bytes).
• Free memory: Amount of free memory (in bytes).
• Percent free memory: Percentage of free memory.
• Swap cached percent: Percentage of Swap caching memory.
• Swap free: Amount of free Swap memory (in bytes).
• Swap free percent: Percentage of free Swap memory.
• Total Memory: Total amount of memory of the host (in bytes).
• Total Swap: Total amount of Swap memory (in bytes).
• Used memory: Total amount of used memory (in bytes).
• Used Swap: Total amount of used Swap memory (in bytes).
• Nic [x] TX and Nic [x] RX: Transfer ratio of network interface [x] (in bytes/second). One is generated for each network interface detected.
• Nic [x] errors TX and Nic [x] errors RX: Number of transmission errors of network interface [x]. One is generated for each network interface detected.
• User CPU: Percentage of CPU used by the user.
• System CPU: Percentage of CPU used by the system.
• CPU Idle: Percentage of idle CPU.
• CPU Load: Average CPU load for the last 5 minutes.
• KSM CPU: Percentage of CPU used by KSM.
• Active VM: Number of active virtual machines on the host.
• Migrating VM: Number of virtual machines migrating on the host.
• Total VM: Total number of virtual machines on the host.
• Fence Status: host fencing status.

• Status: Virtual machine status.
• Disk [x] read and Disk [x] write: Read and write rate of disk x (bytes/second). One is generated for each detected disk (storage).
• Disk [x] size: Size of disk x (in bytes). One is generated for each detected disk.
• Disk [x] status: Status of disk x. One is generated for each detected disk.
• Nic [x] TX and Nic [x] RX: Transfer and reception ratio for network interface [x] (in bytes/second). One is generated for each network interface detected.
• Nic [x] errors TX and Nic [x] errors RX: Number of transmission and reception errors for network interface [x]. One is generated for each network interface detected.
• Installed memory: Amount of installed memory (in bytes).
• Percent free memory: Percentage of free memory.
• Used memory: Amount of used memory (in bytes).
• Stateless: Stateless functionality status.
• HA Status: HA functionality status.
• Total CPU: Total percentage of CPU used by the virtual machine.
• Hypervisor CPU: Percentage of Hypervisor CPU used by the virtual machine.
• Guest CPU: Percentage of host CPU used by the virtual machine.

• Event [x]: Description of event x occurred in the system. One will be created for each event detected in the affected Agents.

There is a possibility to create custom reconnaissance tasks thanks to the Discovery server.

To install the extensions, simply copy the content of the extensions folder, which will be found when unzipping the plugin, into the corresponding extensions folder of the Pandora FMS Console. The command to execute is the following:

cp -R extensions/* <pandora_console_dir>/enterprise/extensions/

From that moment, the RHEV monitoring extensions will be available.

To use the RHEV View extension, simply click on the RHEV View option within the Monitoring submenu.

The extension will show a map with all the RHEV architecture components discovered by the plugin.

The RHEV Manager extension is available in the operation view of the Pandora FMS agents that correspond to virtual machines within the RHEV virtualization architecture.

To access the extension, click on the button with the Red Hat logo that you will find along with the other agent tabs.

The extension allows managing virtual machines (start, stop, and suspend) without opening the RHEV management console. The extension shows the current status of the virtual machine with a color code:

• Green = Running.
• Orange = Suspended.
• Gray = Stopped.

With a list of available statuses to which the virtual machine can be moved by clicking the Change Status button.

If you choose the Stop status to stop the virtual machine, the extension will connect with the RHEV API and send the command. The result will be the change of status in the virtual machine and the list options.

The transition between some statuses is not automatic, such as from Stop status to Start. In this case, the extension will show the virtual machine status as it changes in the virtualization architecture.

The configuration of the Agent plugin is performed through a configuration file whose default name is rhev-plugin.conf.

By default, the Agent plugin selects all entities and creates all corresponding Modules with default values for the name and description. All these aspects, as well as general plugin variables, can be configured through the configuration file.

The configuration file has two clearly differentiated areas: global variables and monitoring configuration.

The global variables section begins with the Configuration token and contains the plugin configuration information. The permitted parameters in this section are:

• module_name: Name of the Agent Module with the plugin execution status.
• server: Name of the host serving the RHEV API.
• user: User in user @domain format to connect to the API.
• pass: Password to connect to the API.
• cert: Certificate path to connect to the API.
• temporal: Temporary directory.
• logfile: Log file.
• transfer_mode: Transfer mode. It can take the values: local or tentacle.
• tentacle_ip: IP address of the Tentacle server to which information will be sent. Typically it will be located on the same machine as the Pandora FMS server. This option is only used if transfer_mode is set to tentacle.
• tentacle_port: Tentacle server port. This option is only used if transfer_mode is set to tentacle.
• tentacle_opts: Data sending options for Tentacle. This option is only used if transfer_mode is set to tentacle.

The monitoring configuration section is divided into several subsections. The first subsection has the Reject token and is used to list the virtualization environment entities that will be discarded from monitoring. To discard an entity, it will be necessary to put its name in this list:

#Dismissed entities
Reject
mv1
mv_Windows10
mv_WebServer1
…

It is possible to discard all entities of the same type, for example, all hosts, all virtual machines, etc. The tokens for each entity are: all_dc (Data Center), all_host (Hosts), all_network (Networks), all_storage (Storage Domain), all_cluster (Cluster), all_vm (Virtual Machines). Examples:

#Dismissed entities
Reject
all_dc
all_host
all_network
all_storage
all_cluster
all_vm

The second section has the Rename token and is used to change the names of the entities monitored through the plugin. This functionality is very useful if you want to combine EndPoint monitoring with data extracted from the API in the same Pandora FMS Agent. The configuration of this section is performed by placing the old name first and then the new one separated by a space:

#Rename entities
Rename
mv_WebServer1 WebServer1
mv_Windows10 Windows10 Test
…

The following subsections correspond to the monitoring configuration for each entity. Each entity has its own token, which are: DataCenter, StorageDomain, Network, Cluster, Host, VM. For each of these entities, it is possible to define the Modules that will be disabled or define custom values for the name, description, and the maximum and minimum ranges for the Warning and Critical statuses:

#VM Modules
VM
status disabled
errors_total_tx name = Errors TX Net [%s]; desc = Total network TX errors; limits = 60 70 71 100
memory_used name = Memory in use; desc = Memory used by the virtual machine; limits = 256 1024 1025 2048
…

Each configuration line of the monitoring modules corresponds to two available options:

• <module> disabled: The Module will NOT be created.
• <module> name = <name>; desc = <description>; limits = <min_warning> <max_warning> <min_critical> <max_critical>: The Module will be created with the provided name and description, and thresholds for the maximums and minimums of the Warning and Critical values will also be defined.

It is very important to keep in mind the structure of the configuration file lines and especially to see that the character ; is placed right next to the module name and description. These two lines are NOT equivalent (see the spaces before the ; character):

errors_total_tx name = Net TX Errors [%s]; desc = Total Network TX Errors; limits = 60 70 71 100 #Correct
errors_total_tx name = Net TX Errors [%s] ; desc = Total Network TX Errors ; limits = 60 70 71 100 #Incorrect

The Modules are referenced by their short name, an equivalent name that is easier to write in the command line. The mapping table between short and expanded names is in the following section.

Practical configuration case for virtual machines, VM section:

For the monitoring of virtual machines, a series of enabled or disabled Modules have been defined in the VM section of the configuration file. More specifically: the status Module has been disabled and for the errors_total_tx and memory_used Modules, custom values have been defined. The other Modules that do not appear in the list will be created with the default values. With this configuration, the memory_used Module will take the following values:

• Name: Memory in use.
• Description: Memory used by the virtual machine.
• Min Warning: 256.
• Max Warning: 1024.
• Min Critical: 1025.
• Max Critical: 2048.

Modules are generated dynamically, for example, two related to disks or interfaces where one is created for each detected element. They have a special syntax for the Module name, which is the following:

errors_total_tx name = Net TX Errors [%s]; desc = Total Network TX Errors; limits = 60 70 71 100

In these cases, as the name has a dynamic part, what is allowed is to use the %s macro which will be replaced by the plugin with the variable part of the Module name.

For example, the errors_total_tx Module has the default name:

Nic [nic1] errors TX

It will be renamed to

Errors TX Net [nic1]

Where nic1 is the dynamic part of the module name.

In addition to the sections specific to each element of the architecture, the configuration file has a common section for Events. This section is defined with the EventCodes token and in it, the codes of the events to be monitored will be listed; for example:

EventCodes
30
920
980
509
956

If you do not define this section, event monitoring will not be performed.

Through the Agent plugin configuration file, it is possible to split the monitoring load of the RHEV virtualization infrastructure.

To do this, the entities to be monitored will be distributed among the different Agents. Suppose you have the following architecture:

 DC1
  |
  |- Cluster 1.1
         |- c1.1mv1
         |- c1.1mv2
         |- c1.1mv3

  |- Cluster 1.2
         |- c1.2mv1
         |- c1.2mv2
         |- c1.2mv3

 DC2
  |
  |- Cluster 2.1
         |- c2.1mv1
         |- c2.1mv2
         |- c2.1mv3

  |- Cluster 2.2
         |- c2.2mv1
         |- c2.2mv2
         |- c2.2mv3

One way to split the load would be by assigning a Datacenter to each of the EndPoints; for this we would use the functionality to discard entities to monitor (token Reject).

The first EndPoint monitors Datacenter DC1 and discards the DC2 entities.

 Reject
 DC2
 Cluster 2.1
 Cluster 2.2
 c2.1mv1
 c2.1mv2
 c2.1mv3
 c2.2mv1
 c2.2mv2
 c2.2mv3

The second EndPoint monitors Datacenter DC2 and discards the DC1 entities.

 Reject
 DC1
 Cluster 1.1
 Cluster 1.2
 c1.1mv1
 c1.1mv2
 c1.1mv3
 c1.2mv1
 c1.2mv2
 c1.2mv3

The load could also be split based on the clusters. For example, for each cluster of the two Datacenters, one of the first four agents will be assigned.

EndPoint 1, monitor Cluster 1.1 and discards the other entities.

 Reject
 DC1
 Cluster 1.2
 c1.2mv1
 c1.2mv2
 c1.2mv3
 DC2
 Cluster 2.1
 Cluster 2.2
 c2.1mv1
 c2.1mv2
 c2.1mv3
 c2.2mv1
 c2.2mv2
 c2.2mv3

EndPoint 2, monitor Cluster 1.2 and discards the other entities.

 Reject
 DC1
 Cluster 1.1
 c1.1mv1
 c1.1mv2
 c1.1mv3
 DC2
 Cluster 2.1
 Cluster 2.2
 c2.1mv1
 c2.1mv2
 c2.1mv3
 c2.2mv1
 c2.2mv2
 c2.2mv3

EndPoint 3, monitor Cluster 2.1 and discards the other entities.

 Reject
 DC1
 Cluster 1.1
 Cluster 1.2
 c1.1mv1
 c1.1mv2
 c1.1mv3
 c1.2mv1
 c1.2mv2
 c1.2mv3
 DC2
 Cluster 2.2
 c2.2mv1
 c2.2mv2
 c2.2mv3

EndPoint 4, monitor Cluster 2.2 and discards the other entities.

 Reject
 DC1
 Cluster 1.1
 Cluster 1.2
 c1.1mv1
 c1.1mv2
 c1.1mv3
 c1.2mv1
 c1.2mv2
 c1.2mv3
 DC2
 Cluster 2.1
 c2.1mv1
 c2.1mv2
 c2.1mv3

The configuration of discarded entities is totally flexible and the load could even be split by assigning several entities to each EndPoint.

The Nutanix® plugin is a program written in Perl, which will connect to the Nutanix PRISM® REST API, retrieving the necessary metrics to monitor the following elements:

• Nutanix® clusters.
• Storage devices.
• Containers.
• Virtual Machines.
• hosts.
• Status of replication processes.

To retrieve information from the REST API you need:

• The portal IP address / FQDN.
• A user with read permissions on the API.
• The password of said user.

Regarding the communication of monitoring results to your Pandora FMS you need:

• The information transfer mode, either local or via Tentacle.
• In case of being local, the directory address where the XML files with results must be delivered, as well as write permissions in said directory.
• In case of communication via Tentacle, it will be necessary to connect against the Pandora FMS server IP address or FQDN, the port used by your Tentacle installation, the Tentacle client location as well as any extraordinary options you have defined.

Download the files required by the plugin from the Module library. Transfer the files to the remote computer from where you want to perform the monitoring of your Nutanix® infrastructure and extract the plugin files:

tar xvzf pandora_nutanix.tar.gz

The following fields are declared:

Nutanix API configuration

• nx_fqdn: Main Prism server address.
• nx_port: Port where the REST API is published (default 9440).
• nx_user: User with read privileges on the REST API.
• nx_pass: Password of said user.
• use_https: Use https (1) or not (0)
• nx_rest_version: Rest API version (default 'v1').

Nutanix agent configuration

• agent_interval: Interval of the Agents generated by the plugin (default 300).
• agent_group: Group to which the generated Agents will belong (if 'autocreate_group' is commented in your PandoraServer configuration), default Nutanix.
• module_interval: Interval of the generated agents' Modules (multiplication factor, default 1).
• module_tags: Tags associated with the new modules of the generated agents.
• module_group: Group to which the new Modules will belong.

Configuration of communication to the Pandora FMS server

• mode: Data transfer mode, “local” or “tentacle”.
• tentacle_ip: Pandora FMS server IP address, only applies in Tentacle mode.
• tentacle_port: Port where the Tentacle service is listening.
• tentacle_opts: Any extra options configured in your Tentacle service.
• tentacle_client: Full path to your Tentacle client.
• temp: Temporary working directory.
• local_folder: Delivery path for the “local” data transfer mode.

Filters

• cluster_monitoring: Enable (1) or not (0) cluster monitoring.
• storage_monitoring: Enable (1) or not (0) storage device monitoring.
• container_monitoring: Enable (1) or not (0) storage container monitoring.
• vm_monitoring: Enable (1) or not (0) virtual machine monitoring.
• host_monitoring: Enable (1) or not (0) virtual machine server monitoring (Nutanix nodes).
• pd_monitoring: Enable (1) or not (0) protection domain monitoring.

Customizations

• cluster_agent_header: Header for the Agent name of cluster type devices.
• storage_agent_header: Header for the Agent name of storage device type devices.
• host_agent_header: Header for the Agent name of virtual machine server type devices (Nutanix nodes).
• container_agent_header: Header for the Agent name of storage container type devices.
• vm_agent_header: Header for the Agent name of virtual machine type devices.
• pd_agent_header: Header for the Agent name of protection domain type devices

Module generation rules

• vm_stat: Rule for adding Modules for virtual machine monitoring, default hypervisor_cpu_usage_ppm|hypervisor_memory_usage_ppm|.*avg.*, this indicates the extraordinary Modules that will be generated, when the metric name matches the regular expressions indicated in this field. Add the value .* to monitor all available metrics.
• host_stat: Rule for adding Modules for virtual machine server monitoring (Nutanix nodes), default hypervisor_cpu_usage_ppm|hypervisor_memory_usage_ppm|.*avg.*, this indicates the extraordinary Modules that will be generated, when the metric name matches the regular expressions indicated in this field. Add the value .* to monitor all available metrics.
• pd_stat: Rule for adding Modules for protection domain monitoring, default replication_transmitted_bandwidth_kBps|replication_total_transmitted_bytes, this indicates the extraordinary Modules that will be generated, when the metric name matches the regular expressions indicated in this field. Add the value .* to monitor all available metrics.

Renaming of entities

• RENAME aaa TO bbb: Rule for renaming entities, you can define as many directives as elements you need to rename.

Exclusion of entities

• REJECT aaa: Rule for excluding entities from monitoring, you can define as many directives as elements you need to exclude.

It is recommended to run the plugin remotely from a computer with access to both the Pandora FMS server and your Nutanix® infrastructure to be monitored.

Manual execution:

./pandora_nutanix-linux-x64 pandora_nutanix.conf

You can automate the plugin execution in the system cron by adding the following line to /etc/crontab.

/5 * * * * root /path/to/plugin/pandora_nutanix-linux-x64 /path/to/plugin/pandora_nutanix.conf

See the use of DISCO Package for XenServer in Discovery PFMS.

The Pandora FMS plugin for monitoring OpenNebula environments is written in Perl. It runs locally on the OpenNebula server and will retrieve all necessary information using OpenNebula's own management commands. It allows the monitoring of the following types of elements:

• clusters.
• hosts.
• Virtual machines.
• Storage resources.

It is essential that the system executing the plugin has the following requirements:

• Perl available on the equipment
• User with privileges to execute the following commands:

1. onehost.
2. onecluster.
3. onedatastore.

Download your copy of the Pandora FMS plugin for OpenNebula from the module library. You must extract the file content into a non-volatile directory from where you can execute it, either using the Pandora FMS agent or the system cron.

unzip pandora_OpenNebula.zip

• mode: Data transfer mode, “local” or “tentacle”.
• tentacle_ip: Pandora FMS server IP address, only applies in tentacle mode.
• tentacle_port: Port where the Tentacle service is listening.
• tentacle_opts: Any extra options configured in your Tentacle service.
• tentacle_client: Full path to your Tentacle client.
• temp: Temporary working directory.
• local_folder: Delivery path for the “local” data transfer mode.

• agent_interval: Agent interval, default 300.
• agent_group: Agent group, default OpenNebula.

• MODULE_GROUP: Module group, default OpenNebula.
• MODULE_INTERVAL: Module interval (multiplier), default 1.
• MODULE_TAGS: Tags for Modules.

• cluster_agent_header: Header for the Agent name of cluster type devices.
• host_agent_header: Header for the Agent name of virtual machine server type devices.
• storage_agent_header: Header for the Agent name of storage device type devices.
• vm_agent_header: Header for the Agent name of virtual machine type devices.

• cluster_monitoring: Enable (1) or not (0) cluster monitoring.
• host_monitoring: Enable (1) or not (0) virtual machine server monitoring.
• storage_monitoring: Enable (1) or not (0) storage device monitoring.
• vm_monitoring: Enable (1) or not (0) virtual machine monitoring.

• RENAME aaa TO bbb: Rule for renaming entities, you can define as many directives as elements you need to rename.

• REJECT aaa: Rule for excluding entities from monitoring, you can define as many directives as elements you need to exclude.

To schedule it through the system cron, you can add the following line to /etc/crontab:

/5 * * * * root "<path>/pandora_opennebula" "<path>/pandora_opennebula.conf"> /dev/null 2>&1

If you run the plugin manually, the output should be similar to the following:

[root@valhalla ~]# ./pandora_opennebula pandora_opennebula.conf
[root@valhalla ~]# echo $?
0

This plugin allows monitoring IBM AIX virtualization equipment through the HMC hardware management console. This plugin will collect information from all logical partitions created in an AIX environment managed by an HMC system, creating an Agent for each managed server, each logical partition and each virtual IO server.

To collect information via SSH, the plugin can use three working modes:

1. Based on expect using the ssh_launcher.sh script.
2. Based on Net::SSH::Perl
3. Based on Net::SSH::Expect

To complement the captured information, queries will also be made against the REST API, by default at:

https://fqdn:12443/rest/api/{root_element}

The necessary parameters that the area requiring monitoring services must provide are:

• Username to authenticate on the HMC system (read-only).
• The user must have permission to connect to the REST API and to log into the HMC shell and execute the following commands (at minimum):

1. lssyscfg.
2. lshwres.

• Password of said user.
• Location (FQDN/IP) of the HMC (such as myhmc.mydomain).
• HMC REST API base URL, similar to:

https://myhmc.mydomain:12443

The parameters monitored by the plugin are (grouped by element type):

• Current logical partitions.
• Max logical partitions.
• Max memory available.
• Max memory installed.
• Proc pool DefaultPool current proc units.
• Proc pool DefaultPool max proc units.
• Proc pool DevelopmentPool current proc units.
• Proc pool DevelopmentPool max proc units.
• Proc pool ProductionPool current proc units.
• Proc pool ProductionPool max proc units.
• Proc pool TestPool current proc units.
• Proc pool TestPool max proc units.
• Proc pool VIOPool current proc units.
• Proc pool VIOPool max proc units.
• Processor pools configured.
• Processor units available.
• Processor units installed.
• State.
• UUID.
• Virtual proc units max.

LPAR:

• Auto start: Auto-start logical partition configuration.
• LPAR type: Logical partition type.
• LPAR UUID: Used to query HMC APIs.
• Max memory: Maximum memory.
• Max memory: Available memory.
• Processor units available: Available processing units.
• Processor units current: Installed processing units.
• RMC IP address: RMC IP address.
• RMC state: RMC status on LPAR.
• State: Logical partition status.
• Virtual proc units: Virtual processing units assigned to this LPAR.

Virtual IO:

• Auto start: Auto-start logical partition configuration.
• LPAR type: Logical partition type.
• LPAR UUID: Used to query HMC APIs.
• Max memory: Maximum memory.
• Max memory current: Available memory.
• Processor units available.: Available processing units
• Processor units current: Installed processing units.
• RMC IP address: RMC IP address.
• RMC state RMC: RMC status on LPAR.
• State: Logical partition status.
• Virtual proc units: Virtual processing units assigned to this LPAR.

• mode: Data transfer mode, “local” or “tentacle”.
• tentacle_ip: Pandora FMS server IP address, only applies in tentacle mode.
• tentacle_port: Port where the tentacle service is listening.
• tentacle_opts: Any extra options configured in the tentacle service.
• tentacle_client: Full path to your tentacle client.
• temp: Temporary working directory.
• local_folder: Delivery path for the “local” data transfer mode.

• hmc_host: HMC IP or FQDN.
• hmc_user: User with read permission.
• hmc_pass: Password.
• as_agent_plugin: The plugin output will be returned in XML format for executions scheduled with the Pandora FMS Agent (as_agent_plugin = 1). Or standard output (as_agent_plugin = 0 ) for executions scheduled with the system cron or performed as a server plugin.

• agent_name: Optional, indicate a name for the parent Agent, default `hostname`.
• agent_interval: Agent interval, default 300 seconds.
• agent_group: Agent group, default IBM.

• module_group: Module group, default IBM.
• module_interval: Module interval (multiplier), default 1.
• module_tags: Tags for modules.

For entity renaming, block renaming is used:

 rename
 MyLPAR_NAME TO my new name
 MyLPAR_NAME2 TO my second new name
 rename_end

The Pandora FMS plugin for monitoring IBM AIX systems through HMC is deployed as follows:

Setting the as_agent_plugin parameter to 1 (execution as agent plugin):

module_plugin /usr/bin/perl pandora_hmc.pl pandora_hmc.conf

Setting the as_agent_plugin parameter to 0 (execution as server plugin):

# /etc/crontab
*/5 * * * * root /usr/bin/perl /root/hmc/pandora_hmc.pl /root/vmware/pandora_hmc.conf

This plugin allows monitoring HPVM virtualization equipment. It is launched as an Agent plugin, generating in parallel one more agent for each virtualized computer hosted on the monitored system.

Local commands are used to collect information.

Check each of the following steps:

• Deploy a Pandora FMS Agent on the equipment you want to monitor.
• Have a user with permissions to execute the plugin.
• This user must have permissions to execute the hpvmstatus command to interpret the output:

1. hpvmstatus.
2. hpvmstatus -X.
3. hpvmstatus -r -X.

Download a copy of the Pandora FMS plugin for HPVM HP Virtualization Manager monitoring from the module library. You can schedule the execution using collections and the deployed Pandora FMS Agent, or extract the file content into a non-volatile directory from where you can run it via your system's cron.

unzip pandora_HPVM.zip

• mode: Data transfer mode, “local” or “tentacle”.
• tentacle_ip: Pandora FMS server IP address, only applies in tentacle mode.
• tentacle_port: Port where the Tentacle service is listening.
• tentacle_opts: Any extra options configured in your Tentacle service.
• tentacle_client: Full path to your Tentacle client.
• temp: Temporary working directory.
• local_folder: Delivery path for the “local” data transfer mode.

• agent_name: Optional, indicate a name for the parent Agent, default hostname.
• agent_interval: Agent interval, default 300.
• agent_group: Group to which the agents will belong, default HPVM.

• module_group: Module group.
• module_interval: Module interval (multiplier), default 1.
• module_tags: Tags for Modules.

Executing the plugin from the Pandora FMS Agent, it will appear in the Agent configuration file:

module_plugin /usr/bin/perl pandora_hpvm.pl pandora_hpvm.conf

For a manual test, configure the plugin following the described steps, and it can be executed as:

perl pandora_hpvm.pl pandora_hpvm.conf

←Back to Pandora FMS documentation index