github a-schild/Zabbix-HyperV-Templates v2.0.6
v2.0.6 - Checkpoint monitoring, VM details, and fixes for non-replicated VMs

4 hours ago

Checkpoint monitoring, the VM detail items that were never wired up, and three long standing errors on the host template.

Upgrading — please read

  1. Deploy the updated hyper-v-monitoring2.ps1 to every Hyper-V host. It reports new checkpoint fields the templates depend on. Re-sign it afterwards if your hosts run under AllSigned/RemoteSigned.
  2. Re-import both templates. This release adds 38 items and 4 triggers to the VM Guest template; without the import you get the script changes but none of the monitoring.
  3. One history reset. Five disk counters (latency, read/write bytes/sec, read/write operations/sec) changed their averaging window and therefore their item key, so Zabbix treats them as new items and their graphs start fresh. Everything else keeps its history.

Checkpoint monitoring (#47)

The script had always collected checkpoint data and nothing ever used it. The VM Guest template now exposes count, type, the oldest and newest checkpoint with name, creation time and age, and the raw list.

Two new triggers, both tunable:

Macro Default Fires when
{$VM.CHECKPOINT.COUNT.MAX} 3 a VM carries more checkpoints than this
{$VM.CHECKPOINT.AGE.MAX} 7d the oldest checkpoint has been left behind

The age check is the one that matters operationally — a forgotten checkpoint keeps growing its avhdx chain until the volume fills, and merging it back gets slower the longer it lives. Ages are computed on the Hyper-V host, because the creation timestamp carries no timezone and the Zabbix server would otherwise have to guess the host's offset.

All the VM detail that was being thrown away (#45)

The VM Guest template only ever read the disk and network parts of the data it collected. The entire VM information block — around 35 fields per VM — was fetched every poll and discarded, which is why "I dont see any informations about the VMs like memory, CPU only Disks and NICs".

It is now monitored: run state, health status, uptime, generation, configuration version, virtual CPU count / reserve / limit / weight, startup / minimum / maximum memory, dynamic memory settings, autostart and autostop behaviour, configuration, checkpoint and smart paging paths, notes, adapter / disk / dvd counts, and the integration services. Plus triggers for a VM whose status is not "Operating normally", and for a VM that is not running (informational, since VMs are legitimately switched off).

All of it hangs off the existing master item, so it costs no additional agent or script calls.

Three errors fixed on the Hyper-V host template (#45)

  • Replication Data failed on every discovered VM with Value of type "string" is not suitable for value type "Numeric (unsigned)". It was a dependent item with no preprocessing and no declared type, so it defaulted to numeric and received the entire VM array. It is now a text item holding just its own VM's record.
  • Every non-replicated VM had three permanently unsupported items. A VM without replication legitimately has no primary server, no replica server and no last sync time, and the template treated empty as an error: ZBX_UNSUPPORTED: Field {#VM.REPLICATION.PRIMARY.SERVER} not found or empty. Empty values are now accepted; the items only fail if the VM itself is missing.
  • Cannot evaluate function: item "vm.memory.size[total]" does not exist — the host memory items are calculated from values a Windows agent template provides, not this one. Link e.g. "Windows by Zabbix agent" to the same host. This requirement is now documented in the item, the template description and the readme instead of being folklore.

Performance (#40)

On a host with 20 VMs, the VM details poll is one powershell.exe start plus a Hyper-V module import plus a Get-VHD per disk every 30 seconds — which matches the reported CPU spikes.

  • The poll interval is now the {$VM.DETAILS.INTERVAL} macro. The default stays 10m so nothing changes on upgrade; raise it to 30m or 60m on busy hosts.
  • Disk performance counters moved from 1m to 5m. Sixteen of the twenty-one are queried on demand, so that is five times fewer agent queries per disk per VM.
  • The five counters that keep a moving average now average over the full 5 minutes instead of 30 seconds, so the value represents the whole interval. (These are sampled by the agent once a second regardless of polling, so this is about data quality rather than load.)
  • Network counters are unchanged at 1m.

Thanks

@jtrott for #47 and for spotting that the checkpoint data was present but unused, @alfista-sk and @seniorza for the detailed error output in #45, and @drewbroc for the CPU profile in #40 that made the every-30-seconds pattern identifiable.

Don't miss a new Zabbix-HyperV-Templates release

NewReleases is sending notifications on new releases.