KVM Discovery

Full description

The KVM Discovery plugin brings the inventory and state of a KVM environment into Pandora FMS. On each run the plugin reads the state of every configured KVM host through the libvirt layer, over SSH or locally on the KVM host itself, and produces a two-level agent hierarchy: one agent per KVM host and one agent per virtual machine, created as a child of its host agent. Host agents report the status of libvirtd and, when server performance monitoring is enabled, the RAM and CPU usage of the KVM server, including its RAM consumption in bytes. Virtual machine agents report the power state of each VM and, for running VMs, the assigned vCPUs, the CPU usage per vCPU, and the memory usage and consumption of the guest. The plugin also resolves the IPv4 address of running VMs and uses it as the agent address when one is available. VM coverage can be limited with allow and deny filters, and every generated agent inherits the agent group and interval configured in the Discovery task. This is a monitoring integration: it reports state and resource usage, and it does not change the configuration or the state of the monitored hosts or virtual machines.

What it allows you to do

- Create agents for KVM hosts and their virtual machines through a Discovery task.
- Track the availability of each KVM host and the RAM and CPU usage of the KVM server.
- Track the number of virtual machines defined on each host.
- Track each virtual machine's power state and, for running VMs, their vCPU and memory usage.
- Limit which virtual machines are covered with allow and deny filters.

What it monitors

- KVM host availability: whether libvirtd is running on each monitored host.
- Server performance: RAM usage and consumption, and CPU usage of the KVM server.
- Virtual machine inventory: the number of virtual machines defined on each host.
- Virtual machine state: whether each virtual machine is running.
- Guest vCPUs: the number of assigned vCPUs and the CPU usage per vCPU of running virtual machines.
- Guest memory: memory usage in percent and memory consumption in bytes of running virtual machines.

How it works

- The plugin runs as a Discovery task: the console defines the task and the list of KVM hosts to monitor, and the task runs the plugin against each target.
- On every run the plugin checks whether libvirtd is running on each host, and reads the host state and the virtual machine inventory through the libvirt layer.
- Each run produces one agent per KVM host and one agent per virtual machine with their modules, for the Discovery task to create with the configured group and interval.
- Running virtual machines are sampled with a short measurement window for CPU usage, and their IPv4 address is resolved and used as the agent address when available.

Benefits

- Unified visibility: KVM host and virtual machine state join the rest of the infrastructure in Pandora FMS, so virtualization can be reviewed together with the systems that depend on it.
- Lower scope-maintenance effort: a single task covers several KVM hosts and their virtual machines instead of defining a monitor for each one.
- Coverage that follows the host inventory: new virtual machines are included in later task runs without reconfiguring the task.
- Earlier recognition of documented conditions: dedicated status modules distinguish a running from a stopped virtual machine, and an available from an unavailable KVM service.

Use cases

- Virtualization and infrastructure teams that need availability and resource visibility for KVM hosts and their guests.
- Environments with several KVM hosts where a single task covers every host and its virtual machines.
- Operations teams that need to know when a virtual machine stops or a KVM host becomes unavailable.

Requirements

- A Pandora FMS server with Discovery enabled to run the task, and a console to define it.
- On every monitored host: libvirt with the virsh command available, and the libvirtd daemon running.
- An SSH account on every remote host with permission to read the libvirt state, normally a member of the libvirt group or root.
- Remote authentication: an SSH private key readable by the user that runs the task, or credentials stored in the Pandora FMS credential manager.
- Network reachability to every remote host on the configured SSH port.
- A target agent group and a monitoring interval for the generated agents.

Compatibility

- Compatible with Pandora FMS NG 784 and later versions.

Limitations

- Virtual machine CPU and memory modules are produced only while the virtual machine is running.
- On a host where libvirtd is not running, the run produces only its host agent with a zero status: no server performance modules and no virtual machine agents are generated.