Monitoring oVirt with Vigilmon

oVirt is the upstream community project behind Red Hat Virtualization, giving you enterprise-grade VM lifecycle management, live migration, and storage management without a Red Hat subscription. But running oVirt in production means the oVirt Engine is your single management plane — if the web UI goes down, the REST API goes dark, or the PostgreSQL backend becomes unreachable, you lose control over every VM in your cluster. Vigilmon monitors the Engine web UI, REST API health, database TCP port, libvirt connectivity, and SSL certificates so you catch failures before they become incidents.

What You'll Set Up

• HTTP monitor for the oVirt Engine web UI (/ovirt-engine/)
• HTTP monitor for the oVirt REST API health endpoint
• TCP port monitor for PostgreSQL (port 5432)
• TCP port monitor for libvirt (port 16509)
• SSL certificate expiry alerts for the Engine domain
• Heartbeat monitoring for scheduled maintenance tasks

Prerequisites

• oVirt Engine 4.4+ installed and running
• At least one hypervisor host registered to the Engine
• A free Vigilmon account

Step 1: Monitor the oVirt Engine Web UI

The oVirt Administration Portal lives at /ovirt-engine/ on your Engine host. This is the first thing that disappears when the Engine application server crashes.

1. Log in to vigilmon.online and click Add Monitor.
2. Set Type to HTTP / HTTPS.
3. Enter the Engine URL: https://ovirt.yourdomain.com/ovirt-engine/
4. Set Check interval to 1 minute.
5. Set Expected HTTP status to 200.
6. Click Save.

The oVirt Engine runs on WildFly (formerly JBoss). If WildFly crashes or runs out of heap memory, the web UI returns errors or becomes unreachable even though the host OS is still up.

To verify the endpoint manually:

curl -I https://ovirt.yourdomain.com/ovirt-engine/
# HTTP/1.1 200 OK

Step 2: Monitor the oVirt REST API

The oVirt REST API powers all automation, Ansible integration, and the VM Portal. Monitor it independently from the web UI since they share the same WildFly instance but can have different failure modes:

1. Click Add Monitor → HTTP / HTTPS.
2. Enter the REST API URL: https://ovirt.yourdomain.com/ovirt-engine/api
3. Set Check interval to 1 minute.
4. Set Expected HTTP status to 200.
5. Click Save.

A healthy API response looks like:

curl -k -u admin@internal:password \
  https://ovirt.yourdomain.com/ovirt-engine/api
# Returns XML with <api> root element listing available endpoints

You can also check the Engine health endpoint which doesn't require authentication:

curl https://ovirt.yourdomain.com/ovirt-engine/services/health
# Returns: DB Up, ...

Add a separate monitor for this unauthenticated health endpoint as an additional signal:

1. Click Add Monitor → HTTP / HTTPS.
2. Enter: https://ovirt.yourdomain.com/ovirt-engine/services/health
3. Set Expected HTTP status to 200.
4. Click Save.

Step 3: TCP Port Monitor for PostgreSQL (Port 5432)

oVirt Engine uses PostgreSQL as its backend database. If the database becomes unreachable, the Engine will display errors and refuse to process VM operations even though WildFly is still running.

1. Click Add Monitor → TCP Port.
2. Enter Host: ovirt.yourdomain.com (or the separate DB host if you use an external PostgreSQL instance).
3. Enter Port: 5432.
4. Set Check interval to 1 minute.
5. Click Save.

A TCP check on port 5432 confirms PostgreSQL is listening. Combined with the Engine health endpoint monitor (which checks DB connectivity from the Engine's perspective), you can distinguish between "PostgreSQL is down" and "Engine can't reach PostgreSQL."

Step 4: TCP Port Monitor for libvirt (Port 16509)

oVirt hosts communicate with libvirt on each hypervisor node. Port 16509 is the unencrypted libvirt management port (16514 for TLS). The Engine uses this to manage VMs on each host.

For each hypervisor host you want to monitor:

1. Click Add Monitor → TCP Port.
2. Enter Host: your-hypervisor-host.local (or IP).
3. Enter Port: 16509.
4. Set Check interval to 1 minute.
5. Click Save.

If port 16509 is unreachable on a host, oVirt will mark that host as non-responsive and move its VMs, but you may not see the alert immediately in the UI if the Engine itself is under load.

To verify libvirt is listening:

# On the hypervisor host
ss -tlnp | grep 16509
# Should show: LISTEN 0 128 0.0.0.0:16509 ...

Step 5: SSL Certificate Alerts

oVirt Engine uses its own internal CA by default. If you've configured a trusted TLS certificate for the Engine web UI (required for browsers to trust the portal), monitor its expiry:

1. Open the HTTP / HTTPS monitor for https://ovirt.yourdomain.com/ovirt-engine/.
2. Enable Monitor SSL certificate.
3. Set Alert when certificate expires in less than 21 days.
4. Click Save.

Check what certificate oVirt is serving:

openssl s_client -connect ovirt.yourdomain.com:443 -showcerts </dev/null 2>/dev/null | \
  openssl x509 -noout -dates
# notBefore=...
# notAfter=...

oVirt's internal CA certificates have long expiry periods (often 10+ years) but externally-issued certificates for the Engine hostname follow standard 90-day or 1-year cycles. A 21-day alert gives you enough runway to renew and redeploy.

Step 6: Heartbeat Monitoring for Maintenance Tasks

oVirt scheduled tasks — host maintenance windows, storage domain sync jobs, and log rotation — run as cron jobs or Engine-scheduled tasks. Use Vigilmon heartbeats to confirm they complete successfully.

1. In Vigilmon, click Add Monitor → Cron Heartbeat.
2. Set the expected ping interval to match your task schedule (e.g. 1440 minutes for daily jobs).
3. Copy the heartbeat URL (e.g. https://vigilmon.online/heartbeat/abc123).

For tasks triggered via the oVirt REST API or Ansible:

#!/bin/bash
# /usr/local/bin/ovirt-maintenance-check.sh
# Run after scheduled maintenance completes

# Check that all hosts are back in 'up' state after maintenance window
HOSTS_DOWN=$(ovirt-shell -c -E 'list hosts' | grep -c "status.*maintenance")

if [ "$HOSTS_DOWN" -eq 0 ]; then
    curl -s --max-time 10 https://vigilmon.online/heartbeat/abc123
else
    echo "WARNING: $HOSTS_DOWN hosts still in maintenance state"
fi

For Engine backup jobs (using engine-backup):

#!/bin/bash
# /usr/local/bin/ovirt-backup.sh

engine-backup --mode=backup \
  --file=/var/lib/ovirt-engine/backup/engine-$(date +%Y%m%d).tar.gz \
  --log=/var/log/ovirt-engine-backup.log && \
    curl -s --max-time 10 https://vigilmon.online/heartbeat/abc123

Add to root crontab:

0 3 * * * /usr/local/bin/ovirt-backup.sh >> /var/log/ovirt-backup-cron.log 2>&1

Step 7: Configure Alert Channels

1. Go to Alert Channels in Vigilmon and add email, Slack, or PagerDuty.
2. For Engine web UI and REST API monitors, set Consecutive failures before alert to 2 — WildFly restarts can cause brief unavailability.
3. For PostgreSQL and libvirt TCP monitors, set Consecutive failures to 1 — database and daemon failures are rarely transient.

Summary

| Monitor | Target | What It Catches | |---|---|---| | HTTP (Engine UI) | https://host/ovirt-engine/ | WildFly crash, Engine app failure | | HTTP (REST API) | https://host/ovirt-engine/api | API unavailable, WildFly errors | | HTTP (health) | /ovirt-engine/services/health | DB connectivity from Engine | | TCP port (PostgreSQL) | host:5432 | Database down or unreachable | | TCP port (libvirt) | host:16509 | Libvirt daemon failure on hypervisor | | SSL certificate | Engine domain cert | Certificate expiry before renewal | | Cron heartbeat | Heartbeat URL | Missed Engine backup or maintenance job |

oVirt gives you Red Hat Virtualization-class infrastructure on community support — but that means monitoring is your responsibility. With Vigilmon covering the Engine web UI, REST API, PostgreSQL, libvirt, SSL certificates, and backup heartbeats, you have the observability layer that keeps your virtualization platform from going dark without warning.