Ein Serverschrank im Keller, ein Proxmox-Host, ein paar VMs – und eine USV, die brav die Überbrückung liefert. Nur: Was passiert, wenn der Akku nach zehn Minuten leer ist und niemand zu Hause ist? Ohne saubere Abschaltung endet der Stromausfall im schlimmsten Fall mit einem inkonsistenten ZFS-Pool, einer korrupten Datenbank in einer VM oder einem Host, der nach der Rückkehr des Stroms erst einmal einen Dateisystem-Check fährt.
Genau diese Lücke schließt eine automatische Shutdown-Logik: Die USV meldet „Netzausfall“, ein Watchdog beobachtet Ladestand und Restlaufzeit – und fährt die Proxmox-Hosts rechtzeitig geordnet herunter, bevor die Batterie leer ist.
In diesem Artikel zeige ich, wie sich eine USV an Proxmox VE anbinden lässt: mit PVE-UPS, einer kleinen Appliance, die komplett über einen Web-Wizard eingerichtet wird – ohne Konfigurationsdateien, ohne Agenten auf den Hosts und ohne Root-SSH. Dazu ohne den Aufwand, sich mit NUT beschäftigen zu müssen, wenn sich die USV per SNMP monitoren lässt.
Warum USV-Shutdown unter Proxmox VE nicht so einfach ist
Proxmox VE bringt von Haus aus keine USV-Anbindung mit. Wer eine USV überwachen will, landet üblicherweise bei einer von zwei Varianten – und beide haben ihre Kanten:
1. Herstellersoftware (z. B. APC PowerChute Network Shutdown) Funktioniert gut, ist aber an den Hersteller gebunden, benötigt eine unterstützte Plattform, Installation auf dem Host und ist mit Proxmox VE noch nicht so richtig warm. Bei gemischter USV-Landschaft wird es endgültig unschön.
Anleitungen von z.B. CyberPower für die Proxmox VE Anbindung gibt es, sind aber teils schwer nachzuvollziehen oder benötige eine vollständige VM und scripting.
Schlanke Lösungen wie unter VMware die APC VMA gibt es noch nicht. CyberPower hat für Herbst 2026 eine bessere Integration angekündigt.
2. NUT (Network UPS Tools) NUT ist das Schweizer Taschenmesser der USV-Welt und hat eine hervorragende Hardware-Unterstützung – insbesondere für USB- und seriell angebundene Geräte. Für den Standardfall „fahre meine Proxmox-Hosts herunter, wenn die USV zur Neige geht“ bedeutet es allerdings: upsd– und upsmon-Konfigurationsdateien, upssched, dazu eigene Shutdown-Skripte auf jedem Host. Das ist machbar, aber etwas zäher, wenn man ein GUI gewohnt ist – und man merkt erst beim echten Stromausfall, ob es wirklich funktioniert.
PVE-UPS geht einen dritten Weg: den Appliance-Ansatz. Ein LXC-Container, ein Installer, danach alles über die Weboberfläche. Wo NUTs Hardware-Unterstützung gebraucht wird um auch USB oder Serielle lokale Geräte anzubinden, nutzt PVE-UPS NUT als Treiber – die Entscheidungslogik bleibt aber in der Appliance, wo man sie auch sieht.
Was PVE-UPS macht
PVE-UPS überwacht eine oder mehrere USVs und fährt bei einem bestätigten Stromausfall einen oder mehrere Standalone-Proxmox-VE-Hosts geordnet herunter.
Die wichtigsten Eckpunkte:
- Ein unprivilegierter Debian-LXC, rund 256 MB RAM, angelegt mit einem einzigen Befehl auf dem PVE-Host.
- Alternative Bereitstellung per Docker – wenn LXC nicht gewünscht ist
- Keine Konfigurationsdateien – ein Web-Wizard mit Test-Buttons für jeden Schritt, Einstellungen greifen sofort.
- Keine Agenten auf den Hosts – der Shutdown läuft über die Proxmox-API mit einem dedizierten, jederzeit widerrufbaren API-Token, das nur das Recht
Sys.PowerMgmtbesitzt. - Zwei USV-Quellen, frei mischbar: SNMP (v1/v2c/v3) und NUT-Server.
- Dry-Run als Standard – nach der Installation wird erst einmal gar nichts heruntergefahren, nur protokolliert.
- REST/JSON-Status für die Einbindung in bestehendes Monitoring.
Lizenz ist MIT, der Quellcode liegt auf GitHub: https://github.com/ffind-dev/pve-ups
Voraussetzungen
Bevor es losgeht, kurz die Checkliste:
| Was | Anforderung |
|---|---|
| Proxmox VE | Standalone-Host(s) (noch kein Cluster-/HA-Manager-Eingriff, gibt es aber als Feature-Requests) |
| USV-Anbindung | SNMP-Netzwerkkarte oder erreichbarer NUT-Server |
| Netzwerk | Appliance muss USV und Proxmox-Host (Port 8006) erreichen |
| Ressourcen | ca. 256 MB RAM, ~2 GB Disk für den LXC |
| Zugang | Root-Shell auf dem Proxmox-Node für die Installation oder Docker Host |
Wichtig zur USV: Die Appliance selbst spricht kein USB und kein seriell. Eine lokal per USB angeschlossene USV wird über einen NUT-Server eingebunden – dazu weiter unten mehr.
Installation: ein Befehl in der Proxmox-Shell
Die Installation erfolgt in der Proxmox-Node-Shell (Webinterface → Node auswählen → >_ Shell, als root). Das Skript lädt das aktuelle Release, entpackt es und legt den LXC an:
bash -c "$(curl -fsSL https://github.com/ffind-dev/pve-ups/releases/latest/download/install.sh)"
Ohne weitere Angaben fragt der Installer interaktiv nach und bezieht die IP per DHCP. Wer den Container gleich mit fester IP-Adresse und definierter Container-ID anlegen möchte, gibt die Parameter direkt mit:
curl -fsSL https://github.com/ffind-dev/pve-ups/releases/latest/download/install.sh | bash -s -- \ --ctid 950 --ip 10.0.0.50/24 --gateway 10.0.0.1 --hostname pve-usv
Nach kurzer Zeit läuft der Container. Das Webinterface ist danach erreichbar unter:
http://<container-ip>:8080
Die Webverbindung ist unverschlüsselt – die Dienste sind für den Betrieb in einem internen Netz ausgelegt.
Konfiguration liegt im Container unter /etc/pve-usv/config.yaml, der Zustand unter /var/lib/pve-usv/.
Bei Bedarf kann die IP-Adresse für PVE-UPS in den ganz normalen Proxmox VE Containereinstellungen angepasst werden:
Alternative: Bereitstellung per Docker
Wer keinen LXC möchte – etwa weil die Appliance auf einem separaten Docker-Host oder in einer Docker VM laufen soll – kann das fertige Image nutzen:
curl -fsSLO https://raw.githubusercontent.com/ffind-dev/pve-ups/main/docker-compose.example.yml mv docker-compose.example.yml docker-compose.yml docker compose up -d
Die Compose-Datei bindet zwei benannte Volumes ein (/etc/pve-usv für die Konfiguration, /var/lib/pve-usv für Eventlog und Zustand), damit die Daten eine Neuerstellung des Containers überstehen.
Zwei Unterschiede zum LXC:
- Keine In-App-Updates über das Webinterface. Aktualisiert wird über ein neues Image (
docker compose pull && docker compose up -d) wie man es bei Docker kennt. - Keine NTP-/Zeitzonen-Verwaltung im Wizard. Die Variable
TZmuss am Container gesetzt werden, sonst läuft der Container in UTC.
Alles Weitere – SNMP-Polling, Proxmox-Shutdown, Schwellwerte, Webhook, Selbsttest – funktioniert identisch. Die LXC-Installation bleibt aber der primäre, vollständig selbst-aktualisierende Weg.
Beim ersten Aufruf von http://<container-ip>:8080 wird zunächst das UI-Passwort gesetzt. Danach führt der Wizard durch die vier Schritte:
- USVs anlegen
- Proxmox-Host(s) anlegen
- Schwellwerte festlegen
- Benachrichtigungen (optional)
Jeder Schritt hat einen Test-Button. Das ist der eigentliche Komfortgewinn gegenüber Konfigurationsdateien: Man sieht direkt, ob die USV antwortet und ob der Proxmox-Host den Token akzeptiert – und muss nicht auf den nächsten Stromausfall hoffen, um es herauszufinden.
USV per SNMP anbinden
Der Standardfall: Die USV hat eine SNMP-Netzwerkkarte (bei APC z. B. eine AP9630/AP9631/NMC3, bei Eaton eine Network-M2, bei CyberPower eine RMCard 205).
Benötigt werden:
- IP-Adresse der Managementkarte
- Port (Standard 161/UDP)
- SNMP-Version: v1, v2c oder v3
- bei v1/v2c: die Community (lesend genügt, z. B.
public) - bei v3: Benutzername, Auth-Verfahren + Passwort
Der Zugriff erfolgt ausschließlich lesend. Gelesen wird die Standard-RFC-1628-UPS-MIB – herstellerneutral, also unabhängig davon, wessen Logo auf dem Gerät klebt.
Sonderfall APC: Nicht jede APC-Karte implementiert RFC 1628 vollständig. Bei insbesondere älteren Karten oder Firmware-Versionen ist der Standard nur teilweise vorhanden, bei den älteren NMC1-Karten (AP9617, AP9618, AP9619) fehlt er komplett. Für diese Fälle liest PVE-UPS alternativ die APC-PowerNet-MIB. Die passende MIB wird je USV automatisch erkannt, lässt sich aber auch manuell festlegen.
Der USV-Test schlüsselt sein Ergebnis pro Objekt auf. Fehlt eine OID, stimmen die Zugangsdaten nicht oder ist der Port durch eine Firewall blockiert, ist das an der Ausgabe direkt unterscheidbar. Zusätzlich benennt der Test die Auslöser, die das Gerät gar nicht bedienen kann – so bleibt keine Schwelle stillschweigend wirkungslos, weil die USV z. B. keine Restlaufzeit meldet.
USV ohne Netzwerkkarte: über einen NUT-Server
Viele kleinere USVs haben nur einen USB-Anschluss. Auch die lassen sich anbinden – über einen vorhandenen NUT-Server, den PVE-UPS als rein lesender Client über TCP-Port 3493 abfragt.
Das funktioniert unter anderem mit:
- dem eingebauten USV-Server einer Synology, QNAP oder TrueNAS
- einem Raspberry Pi mit installiertem NUT
- OPNsense/pfSense
- einem NUT direkt auf einem Proxmox-Host
Im Wizard werden lediglich Host, Port (3493) und der USV-Name eingetragen, optional Benutzer und Passwort.
Wichtig ist das Verhältnis der beiden Werkzeuge zueinander: NUT Datenquelle, übernimmt keine Logik. PVE-UPS liest von upsd ausschließlich Variablen. Kein upsmon, kein upssched, keine Shutdown-Skripte – Schwellwerte, Host-Logik und die eigentliche Entscheidung bleiben in der Appliance.
Sicherheitshinweis: Das NUT-Protokoll ist unverschlüsselt. Es gehört in ein vertrauenswürdiges Netz – oder auf einen upsd, der nur auf dem Loopback-Interface derselben Maschine lauscht.
Proxmox-Host anbinden per API-Token
Der Shutdown läuft über die Proxmox-API. Kein Agent auf dem Host, kein SSH-Key, kein Root-Zugang. Jeder Host bekommt stattdessen einen dedizierten Benutzer mit genau einem Recht (Sys.PowerMgmt) und einen API-Token.
Einmalig je Host in der Node-Shell als root ausführen:
# 1) Dedizierten Benutzer anlegen (PVE-Realm) pveum user add ups@pve # 2) Rolle mit nur dem Power-Management-Recht pveum role add UpsShutdown -privs "Sys.PowerMgmt" # 3) Rolle auf /nodes vergeben (oder enger: /nodes/<name>) pveum acl modify /nodes -user ups@pve -role UpsShutdown # 4) API-Token erzeugen — Privilege Separation AUS, damit der Token das Recht erbt pveum user token add ups@pve shutdown --privsep 0
Der letzte Befehl gibt die Token-ID (ups@pve!shutdown) und das Secret aus – eine UUID, die nur dieses eine Mal angezeigt wird. Also direkt kopieren.
Beides trägt man im Wizard unter Proxmox-Hosts ein. Die API-URL lautet standardmäßig:
https://<host-ip>:8006
Zwei Punkte dazu:
- „TLS prüfen“ aus lassen, solange der Host das selbstsignierte Proxmox-Zertifikat nutzt. Mit eigenem, vertrauenswürdigem Zertifikat kann die Prüfung aktiviert bleiben.
- Der Token ist jederzeit widerrufbar:
pveum user token remove ups@pve shutdown
Abschließend die Verbindung mit Test prüfen – das Ergebnis kommt sofort.
Aktuell (Version 3.3.0) wird keine Anbindung von Proxmox Backupserver oder Proxmox Mailgateway unterstützt. Ausschließlich Proxmox VE.
Mehrere USVs, mehrere Hosts: UND/ODER-Logik
Interessant wird es, sobald mehr als ein Gerät im Spiel ist. PVE-UPS bildet die Versorgung als Zuordnung Host ↔ USV ab, mit einer Logik pro Host:
- UND – der Host hat redundante Netzteile an zwei verschiedenen USVs. Erst wenn beide USVs ausfallen, wird abgeschaltet. Fällt nur eine aus, läuft der Host weiter.
- ODER – die Last ist aufgeteilt (z. B. Host an USV A, Storage an USV B). Fällt eine der beiden aus, muss heruntergefahren werden.
Diese Zuordnung wird als Live-Schaubild dargestellt – hilfreich, um die eigene Verkabelung zu prüfen, bevor der Ernstfall sie prüft.
Wichtig, wenn der LXC auf einem der geschützten Hosts läuft – und das ist der Normalfall: Diesen Host in der Host-Liste als „Dieser Host“ markieren. Er wird dann garantiert zuletzt heruntergefahren. Andernfalls würde sich die Appliance selbst den Boden unter den Füßen wegziehen, bevor die anderen Hosts an der Reihe sind.
Schwellwerte: wann wird abgeschaltet?
Es genügt eine zutreffende Bedingung. Alle Werte sind im Wizard änderbar, ein leeres Feld schaltet die jeweilige Bedingung ab:
| Bedingung | Standardwert |
|---|---|
| Akkubetrieb länger als | 600 s |
| Restlaufzeit unter | 10 min |
| Ladestand unter | 30 % |
USV meldet battery low / depleted | an |
Das Poll-Intervall passt sich der Lage an: 30 Sekunden im Netzbetrieb, 8 Sekunden im Akkubetrieb. Zusätzlich lassen sich Overrides je USV setzen – sinnvoll, wenn eine kleine USV am Switch andere Reserven hat als die große am Host.
Praxistipp zur Dimensionierung: Man sollte messen, wie lange die eigenen Hosts tatsächlich zum Herunterfahren brauchen – inklusive aller VMs mit ihren Shutdown-Timeouts. Ein Host mit 15 VMs braucht schnell mehrere Minuten. Die Schwelle „Restlaufzeit unter X“ sollte großzügig über diesem Wert liegen, denn unter Last sinkt die tatsächliche Restlaufzeit meist schneller, als die USV es zu Beginn schätzt.
Sicherheitsmodell: fail-safe als Standard
Ein Shutdown-Tool, das aus Versehen abschaltet, ist schlimmer als gar keines. Deshalb gilt:
- Ein Kontaktverlust zur USV ist erstmal noch kein bestätigter Stromausfall. Er löst einen Alarm aus, fährt aber nichts herunter. Das gilt genauso für einen NUT-Server, der wegen eines abgestürzten Treibers veraltete Daten liefert – das zählt als „nicht erreichbar“, nie als „Netzbetrieb“.
- Zwei explizite Opt-ins verfeinern das Verhalten: einen bereits bestätigten Akkubetrieb-Countdown über einen Verbindungsverlust hinweg fortsetzen (Standard: an) und einen anhaltenden reinen Kommunikationsverlust doch als Ausfall behandeln (Standard: aus).
- Ein ausgelöster Trigger und der Countdown werden auf Platte persistiert und überstehen einen Dienst-Neustart.
- Die App läuft unprivilegiert; nur ein schmaler privilegierter Begleitprozess wendet Updates und NTP-/Zeitzonen-Änderungen an. Secrets verlassen die Appliance nie über die API.
Im Ereignisprotokoll ist stets nachvollziehbar was passiert ist und warum welche Entscheidung getroffen wurde:
Testen – und erst dann scharf schalten
Nach der Installation ist Dry-Run aktiv. Die Engine protokolliert in diesem Modus nur, was sie tun würde. Das ist die entscheidende Phase, um Vertrauen aufzubauen:
- USV-Test ausführen – antwortet das Gerät, sind alle benötigten Werte vorhanden?
- Host-Test ausführen – akzeptiert der Proxmox-Host das Token?
- Test-Shutdown starten – simuliert die komplette Abschaltreihenfolge ohne jede Wirkung. Hier zeigt sich, ob die Reihenfolge stimmt und „Dieser Host“ korrekt zuletzt kommt.
- Optional: den echten Stromausfall provozieren, indem man den Netzstecker der USV zieht, und im Eventlog verfolgen, was die Engine registriert – ohne Risiko, weil Dry-Run noch aktiv ist.
- Wenn alles passt: Dry-Run deaktivieren. Der Modus wechselt auf „SCHARF“.
Zusätzlich läuft ein regelmäßiger Proxmox-Selbsttest (Startzeit plus Intervall zwischen 15 Minuten und 24 Stunden). Er prüft im laufenden Betrieb, ob die Hosts noch erreichbar sind und der Token noch gültig ist. Ein stillschweigend abgelaufener oder gelöschter Token fällt so auf, bevor er gebraucht wird.
Solange der Test erfolgreich ist, wird er im Ereignis-Protokoll nur einmal täglich dokumentiert, auch wenn er häufiger läuft. Damit wird das Log nicht so vollgespammt.
Benachrichtigungen und Monitoring-Anbindung
Webhook: Bei wichtigen Ereignissen wird ein HTTP-POST mit einem JSON-Objekt (subject, body, status) abgesetzt. Damit lassen sich ntfy, Gotify, Home Assistant, Microsoft Teams oder ein eigener Endpunkt anbinden.
REST-Status: Zwei Endpunkte stehen lesend und ohne Authentifizierung bereit – ohne Secrets auszugeben:
GET http://<container-ip>:8080/api/status GET http://<container-ip>:8080/api/health
/api/status liefert den aktuellen Zustand aller USVs und Hosts inklusive des Ereignisprotokolls der letzten 48 Stunden.
{
"appliance": {
"version": "3.3.0",
"uptime_s": 885,
"engine_state": "ONLINE",
"dry_run": true,
"config_valid": true,
"alarm": false,
"last_selftest_at": "2026-08-07T16:24:02.838043+00:00",
"last_selftest_ok": true,
"next_selftest_at": "2026-08-08T09:00:00"
},
"ups": [
{
"id": "ups1",
"name": "USV1",
"type": "snmp",
"mib": "rfc1628",
"reachable": true,
"manufacturer": "APC",
"model": "SMT1500I",
"last_poll": "2026-08-07T16:27:04.707591+00:00",
"poll_interval_s": 30,
"power_source": "mains",
"battery_status": "normal",
"runtime_remaining_min": 65,
"battery_charge_pct": 100,
"seconds_on_battery": null,
"triggered": false,
"trigger_reason": null,
"countdown_remaining_s": null,
"comm_loss_remaining_s": null,
"alarm": false,
"error": null
},
{
...
}
],
"shutdown": {
"triggered": false,
"reason": null,
"triggered_at": null,
"countdown_remaining_s": null,
"comm_loss_remaining_s": null
},
"hosts": [
{
"name": "VMH01",
"this_host": true,
"order": 0,
"ups_ids": [
"ups1",
"ups2"
],
"ups_policy": "all",
"feeds": [
{
"id": "ups1",
"name": "USV1",
"triggered": false
},
{
"id": "ups2",
"name": "USV2",
"triggered": false
}
],
"eligible": false,
"pending_reason": null,
"reachable": null,
"shutdown_state": "idle",
"last_action_at": null,
"last_error": null
}
],
"events": [...],
"events_summary": {
"info": 3,
"warning": 0,
"critical": 0
}
}
/api/health eignet sich als schlanker Check für Uptime-Kuma, Checkmk, Zabbix oder Icinga. Die Ereignis- und Webhook-Texte sind einheitlich englisch, unabhängig von der eingestellten UI-Sprache.
{
"status": "ok",
"version": "3.3.0",
"engine_state": "ONLINE",
"ups_reachable": true,
"ups_reachable_count": 2,
"ups_total": 2
}
Updates
Im LXC läuft das Update direkt im Webinterface: Release-Paket (pve-usv-<version>.tar.gz) von der Release-Seite herunterladen und unter Update hochladen. Die Konfiguration bleibt erhalten, der Dienst startet automatisch neu.
Zusätzlich lässt sich die Konfiguration exportieren und importieren – praktisch vor größeren Umbauten oder zum Umzug auf einen anderen Host.
Im Docker-Betrieb erfolgt das Update über ein neues Image-Tag.
Typische Stolpersteine
Der USV-Test schlägt fehl, obwohl die IP stimmt. Bei vielen Managementkarten ist SNMP ab Werk deaktiviert oder auf bestimmte Quell-IPs beschränkt. In der Weboberfläche der Karte prüfen, ob SNMPv1/v3 aktiv ist und ob die Appliance-IP in der Zugriffsliste steht.
Restlaufzeit oder Ladestand bleiben leer. Nicht jede Karte liefert alle RFC-1628-Objekte. Der USV-Test benennt genau, welche Auslöser das Gerät nicht bedienen kann – diese Schwellen dann leeren und stattdessen auf battery low und Akkubetriebsdauer setzen.
Der Host-Test meldet einen Zertifikatsfehler. „TLS prüfen“ deaktivieren, solange das selbstsignierte Proxmox-Zertifikat im Einsatz ist.
Der Host-Test meldet fehlende Berechtigung. Meist wurde der Token mit aktivierter Privilege Separation angelegt. --privsep 0 ist notwendig, damit der Token das Recht des Benutzers erbt.
Nach dem Stromausfall bootet nichts wieder hoch. Das ist keine Aufgabe der Appliance, sondern des BIOS/UEFI: Dort muss „Restore on AC Power Loss“ bzw. „Power On“ gesetzt sein. Sonst bleiben die Hosts nach Rückkehr des Stroms aus.
Grenzen
Der Vollständigkeit halber, damit niemand über falsche Erwartungen stolpert:
- Nur Standalone-Hosts. Ein Eingriff in Cluster- oder HA-Manager findet nicht statt.
- Gelesen werden die RFC-1628-UPS-MIB, die APC-PowerNet-MIB oder die Variablen eines NUT-Servers. Weitere Hersteller-MIBs sind noch nicht umgesetzt – ein Gerät außerhalb davon braucht entweder RFC 1628 oder einen NUT-Treiber.
- Die Appliance selbst spricht kein USB und kein seriell – lokal angeschlossene USVs kommen über NUT herein.
- Im Docker-Betrieb entfallen In-App-Updates und NTP-/Zeitzonen-Verwaltung.
FAQ
Kann Proxmox VE eine USV von Haus aus überwachen? Nein. Proxmox VE bringt keine eigene USV-Anbindung mit. Es braucht immer eine zusätzliche Lösung – Herstellersoftware, NUT oder eine Appliance wie PVE-UPS.
Welche USV funktioniert mit Proxmox? Jede USV mit SNMP-Netzwerkkarte, die die RFC-1628-UPS-MIB unterstützt – also praktisch alle netzwerkfähigen Geräte von APC, Eaton, CyberPower, Riello und anderen. Bei APC-Karten ohne vollständiges RFC 1628 greift die PowerNet-MIB. USVs mit reinem USB-Anschluss werden über einen NUT-Server eingebunden.
Brauche ich einen Agenten auf jedem Proxmox-Host? Nein. Der Shutdown erfolgt über die Proxmox-API mit einem API-Token, das nur das Recht Sys.PowerMgmt besitzt. Auf den Hosts wird nichts installiert.
Kann ich meine Synology-USV für Proxmox nutzen? Ja. Die Synology stellt einen NUT-Server bereit (in der DSM-Systemsteuerung unter „Hardware & Energie“ → „USV-Server aktivieren“). PVE-UPS bindet diesen als lesenden Client über Port 3493 ein.
Was passiert, wenn die Verbindung zur USV abbricht? Ein Verbindungsverlust gilt nicht als bestätigter Stromausfall. Es wird ein Alarm ausgelöst, aber nichts heruntergefahren – fail-safe als Standard.
Funktioniert das auch im Proxmox-Cluster? Aktuell nicht. PVE-UPS ist auf Standalone-Hosts ausgelegt und greift nicht in Cluster- oder HA-Manager ein. Ein Shutdown kann trotzdem ausgelöst werden, es können jedoch dadurch ungewünschte automatische VM-Migrationen erfolgen.
Fazit
Eine USV ohne automatischen Shutdown ist eine halbe Absicherung: Sie überbrückt kurze Ausfälle, hilft beim langen aber nur, wenn jemand rechtzeitig eingreift. Mit PVE-UPS lässt sich diese Lücke in einer knappen halben Stunde schließen – ein Installer-Befehl, ein Wizard, ein API-Token je Host.
Besonders praktisch finde ich in der Praxis zwei Dinge: den Dry-Run-Modus, mit dem sich das gesamte Szenario gefahrlos durchspielen lässt, und die Test-Buttons, die jeden Schritt sofort verifizieren. Beides nimmt dem Thema genau die Unsicherheit, die man sonst erst beim echten Stromausfall auflöst – zum denkbar ungünstigsten Zeitpunkt.
Projektseite und Quellcode: https://github.com/ffind-dev/pve-ups
Deutsche Dokumentation: https://github.com/ffind-dev/pve-ups/blob/main/README.de.md
