56a338f80b
The qm-set I/O caps were previously only applied by manual one-shot runs of apply-mbps-caps.sh, so any config drift (manual `qm set`, config restored from /mnt/backup/pve-config like we did on 2026-05-26, fresh VM clone) would leave the affected VM uncapped until someone remembered to re-run the script. Adds apply-mbps-caps.service (Type=oneshot) + apply-mbps-caps.timer firing: - OnBootSec=5min — catches PVE host reboots & restored configs - OnCalendar=hourly — catches manual qm-set drift / fresh clones - Persistent=true — runs missed schedule after PVE downtime - RandomizedDelaySec=2min Same install pattern as the other PVE operational scripts (nfs-mirror, daily-backup, offsite-sync-backup, lvm-pvc-snapshot — memory id=609 + id=542). Source in this repo, deployed to /usr/local/bin + /etc/ systemd/system/ on the PVE host. Script hardening: kept `set -uo pipefail` but dropped `-e` so one missing VM doesn't abort the rest; each VM is gated on `qm status` existence; added a fast-path "already at target" no-op log line for quiet hourly runs. Installed on PVE (192.168.1.127) and smoke-tested: all 8 VMs caps re-applied successfully, next run 12:00 EEST. Journal: `journalctl -u apply-mbps-caps -f` on the PVE host.
18 lines
553 B
SYSTEMD
18 lines
553 B
SYSTEMD
[Unit]
|
|
Description=Re-apply per-VM I/O caps periodically + after PVE boot
|
|
|
|
[Timer]
|
|
# After every PVE host reboot — caps survive in /etc/pve/qemu-server/<vmid>.conf
|
|
# normally, but a config restore from backup can drop them (see 2026-05-26
|
|
# incident where we restored 202.conf + 203.conf from /mnt/backup/pve-config/).
|
|
OnBootSec=5min
|
|
|
|
# Hourly during normal operation — catches manual `qm set` drift or fresh
|
|
# VM clones that haven't had caps applied yet.
|
|
OnCalendar=hourly
|
|
|
|
Persistent=true
|
|
RandomizedDelaySec=2min
|
|
|
|
[Install]
|
|
WantedBy=timers.target
|