a-schild/Zabbix-HyperV-Templates v2.1.0

v2.1.0 - Replication monitoring, replica-aware checkpoints, per-VM CPU and memory

on GitHub

Replication monitoring where it belongs, checkpoint alerting that understands Hyper-V Replica, and per-VM CPU and memory for the first time.

⚠️ Upgrading

Redeploy hyper-v-monitoring2.ps1 to every Hyper-V host. Re-importing the templates alone is not enough — most of what is below reads new fields in the script's output, and those items stay unsupported until the script on the host is the 2.1.0 one.

Import order is unchanged: Template_Windows_Hyper-V_VM_Guest_2.yaml first, then Template_Windows_Hyper-V_Host2.yaml.

Fixed

Checkpoint alerts no longer fire on replicated VMs. Get-VMSnapshot returns Hyper-V Replica's recovery points alongside real checkpoints, so a replica VM configured for additional hourly recovery points permanently carried one per covered hour — 24 of them on a VM with 24-hour coverage, the oldest a day old — and sat in alarm forever. Checkpoints are now classified by snapshot type, and the triggers watch only user checkpoints. Total counts remain available for graphing.

The heartbeat trigger no longer warns about guests that never had a heartbeat. An appliance, an unsupported OS or a Linux guest without hyperv-daemons is reported as NoContact permanently, because it never had contact to lose. The trigger now requires the guest to publish an OS name over KVP, and {$VM.HEARTBEAT.CHECK} switches the check off per VM for anything that filter does not catch.

Added

Replication on the VM hosts. Replication was only ever collected for the Hyper-V host, never for the Zabbix host representing the VM. The guest template now carries state, mode, health, frequency, primary and replica server, last sync and its age, configured recovery points, VSS interval, and throughput and reliability figures from Measure-VMReplication — pending, average and maximum size, average and maximum latency, successful, missed and errored cycles.

Alerting on a replication that stopped running, via {$VM.REPLICATION.LAG.MAX} (default 1h), in both templates. Hyper-V's own health field can read Normal while cycles are merely slow, so this watches the clock directly.

Per-VM CPU and memory usage. The guest template previously showed only configuration — vCPU count, startup memory — and no runtime figures at all. Now: CPU usage, memory assigned and demand, demand as a percentage of assigned, heartbeat, operational status, smart paging in use. Memory demand is populated even with dynamic memory off, so the pressure figure works for every VM.

Guest inventory without an agent, read from the KVP exchange service: OS name, version, build, FQDN, IPv4 and the guest-reported integration services version.

More configuration detail: VLAN operation mode, native VLAN and allowed list per adapter; virtual TPM, shielding, encrypted migration traffic, Secure Boot state and certificate template; VHD parent path, differencing flag and storage QoS limits per disk; mounted ISO images, which block live migration.

A reworked VM dashboard. The Overview page leads with twelve value tiles — state, uptime, CPU, memory pressure, guest OS, IPv4, heartbeat, checkpoints, replication mode, health, last sync age and mounted ISOs — and a second page graphs replication latency, size, cycles and recovery points.

Shipped switched off

Two things are disabled on purpose; the README explains where to enable them.

• VM vCPU Discovery creates the per-virtual-processor performance counters that are the only real source of per-VM CPU trending. Three counters per vCPU at 1m is 12 agent queries a minute for a 4-vCPU VM, multiplied by VM count, so it is off by default. The CPU usage item is a spot sample taken once per {$VM.DETAILS.INTERVAL} and is documented as unsuitable for CPU alerting.
• Secure boot disabled trigger, since plenty of VMs run without Secure Boot for good reasons.
• Resource metering items report 0 until Enable-VMResourceMetering is run per VM. Nothing is measured on hosts that never enable it.

New macros

The replication cycle counts are per measuring window, not lifetime totals, and Hyper-V resets that window on its own — never put a change()-based trigger on them.