KVM monitoring

Full description

The KVM monitoring plugin brings the state of a KVM environment into Pandora FMS through the libvirt management layer. It is executed as an agent plugin, and every run produces the monitoring modules of the environment in the KVM module group. Server-level monitoring covers the availability of the KVM service, the RAM and CPU consumed by the server, and the total number of virtual machines that exist on the host. At virtual machine level, the plugin reports whether each machine is running, includes the libvirt state in the module description, and for running machines it tracks CPU usage, virtual CPU usage and virtual memory usage as a percentage. VM-level modules are generated from the inventory of each host, so coverage follows the virtual machines present in the environment. The plugin is designed for Linux-based KVM servers and for environments where virtual machine state and resource usage must be visible next to the rest of the infrastructure. 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

- Monitor the local instance or several remote KVM hosts from a single plugin deployment.
- Track the availability of the KVM server and the RAM and CPU it consumes.
- Track how many virtual machines exist on each monitored host.
- Track whether every virtual machine is running, with the libvirt state included in the module description.
- Track CPU, virtual CPU and virtual memory usage of running virtual machines.

What it monitors

- KVM server availability: whether the KVM service is running on each monitored node.
- Server resource consumption: RAM and CPU used by the KVM server.
- Virtual machine inventory: the number of virtual machines present on each host.
- Virtual machine state: whether each VM is running, with its libvirt state in the module description.
- Guest performance: CPU, virtual CPU and virtual memory usage of running virtual machines.

How it works

- The plugin runs as a Pandora FMS agent plugin on the endpoint.
- Every execution reads the list of KVM hosts to monitor. The default entry covers the local instance, and additional entries extend the same run to remote hosts.
- For each node, the plugin first checks whether the KVM service is running, and only then collects server and virtual machine data.
- The run produces the monitoring modules, which the agent ingests; all of them are assigned to the KVM module group.

Benefits

- Unified visibility: KVM server 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 deployment covers several KVM hosts, including remote hosts, in the same execution.
- Coverage that follows the inventory: virtual machine modules are generated from each host's inventory, so the VMs present on a host are covered without defining a monitor for each one.
- 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 monitoring deployment must cover all of them.
- Operations that need to know when a virtual machine stops or a KVM service becomes unavailable.

Requirements

- A Pandora FMS endpoint that executes the plugin.
- Perl 5.x or later.
- libvirt, installed from the libvirt-bin or libvirt package, with virsh available on the host that runs the plugin.
- Permission for the user that runs the plugin to execute virsh and connect to the libvirtd instance.
- Unattended SSH access from the host that runs the plugin to every monitored remote KVM server.

Compatibility

- Tested on CentOS, Ubuntu 24.04 and Rocky Linux 9, and expected to work on Linux-based systems.
- Pandora FMS NG 784 and later versions.

Limitations

- CPU, virtual CPU and virtual memory modules are generated only while the virtual machine is running.
- When libvirtd is not running on a monitored node, that node produces only its server status module; no virtual machine or resource modules are generated for it.