Wie verhält sich ein Proxmox Host als NUT Client wenn eine VM der NUT Server ist?

[jim_os]

Genau diese Frage stelle ich mir gerade. Mal angenommen auf dem Host läuft eine VM die dann auch der NUT Server ist. Also z.B. eine Home Assistant, OMV, DSM oder was auch immer VM. Bei dem NUT Server ist dann halt z.B. eingerichtet das die Clients - also auch der Proxmox Host - nach x Minuten herunterfahren sollen. Wie reagiert der Proxmox Host in so einem Fall? Weil eigentlich würde er dann ja zuerst die VM(s) herunterfahren und somit auch die NUT Server VM. Oder wie läuft das dann ab?

Ja mir ist schon klar das das eine eher theoretische Frage ist, aber trotzdem interessiert es mich. Schließlich probiert man mit einer USV und NUT nicht alle möglichen "Spielarten" durch. Zumindest ich nicht. Und ja eigentlich sollte man dann den Proxmox Host als NUT Server einrichten, aber ich "kenne" etliche User die z.B. eine HA VM unter Proxmox nutzen und dann dort HA als NUT Server eingerichtet haben.

VG Jim

 

[ThoSo]

Also, wenn deine NUT-Server VM feststellt "es gibt keinen Strom" und dann bsp. nach 5 Minuten dem PVE als NUT Client sagt, "Shutdown" , dann fährt der PVE die VMs runter und anschließend sich selbst. Würde jetzt nachdem die NUT Server VM heruntergefahren ist (außer es wäre die letzte zu beenden VM) der Strom wieder fliesen, dann könnte der NUT Server nicht mehr sagen können "Kommando zurück - alles wieder grün". Und selbst wenn, wären ja alle anderen VMs vor ihm schon down und der PVE mit der Abschaltung beschäftigt.
Wäre dann die Frage, was macht die USV nun - Poweroff / Reset / Warten auf Ende der Batterie-Restkapazität / Reboot?
Rein Theoretisch.
My2Cent

 

[jim_os]

Moin ThoSo

Danke für Deine Überlegungen/Hinweise. Ich habe festgestellt das ich mich wohl doch noch mal intensiver mit dem Thema NUT beschäftigen muss. In den letzten Jahren habe ich es mir da ziemlich einfach gemacht: Einfach ein Synology NAS als NUT Server genutzt, dort dann die Clients eingetragen


und bei den Clients dann einfach NUT als NUT Client einrichtet und aktiviert. Also im Prinzip nur MODE=netclient und fertig. Bei dem Proxmox Host sieht das dann halt so aus:

root@pve:~# upsc ups@192.168.1.165
Init SSL without certificate database
battery.charge: 99
battery.charge.warning: 20
battery.mfr.date: CPS
battery.runtime: 1511
battery.type: PbAcid
battery.voltage: 13.5
battery.voltage.nominal: 12
device.mfr: CPS
device.model: BR700ELCD
device.type: ups
driver.name: usbhid-ups
driver.parameter.pollfreq: 30
driver.parameter.pollinterval: 5
driver.parameter.port: auto
driver.parameter.synchronous: no
driver.version: DSM7-3-new-86004-251107
driver.version.data: CyberPower HID 0.4
driver.version.internal: 0.41
input.voltage: 231.0
input.voltage.nominal: 230
output.voltage: 230.0
ups.beeper.status: enabled
ups.delay.shutdown: 20
ups.delay.start: 30
ups.load: 25
ups.mfr: CPS
ups.model: BR700ELCD
ups.productid: 0501
ups.realpower.nominal: 420
ups.status: OL CHRG
ups.test.result: No test initiated
ups.timer.shutdown: -60

Was dann genau wie bei den Clients passiert und was ich da dann ggf. noch individuell einstellen könnte oder sogar müsste, war irgendwie noch nie so wirklich ein Thema für mich. Also eher nach dem Motto: Der NUT-Server auf dem Synology NAS wird die NUT Clients dann schon entsprechend steuern.

dann könnte der NUT Server nicht mehr sagen können "Kommando zurück - alles wieder grün".

Kann er das überhaupt sagen? In meinem Beispiel mit dem NUT Server auf dem Synology NAS habe ich über die NUT Server Funktion ja nicht wirklich Einstellmöglichkeiten was dann wie und wann bei den NUT Clients passiert. Hm .... wie gesagt muss ich mich doch noch mal intensiver mit dem Thema befassen und eben auch speziell in Bezug zu Proxmox und den darauf dann laufenden Dingen. Auch z.B. das Thema mit einer laufenden Home Assistant VM unter Proxmox, bei der aktuell ja auch der NUT Client eingerichtet ist.



Hier stellt sich für mich z.B. die Frage was für einen Sinn das ggf. macht, wenn der Proxmox Host ja auch schon als NUT Client eingerichtet ist und somit dann auch das Verhalten der VMs steuert. D.h. in diesem Fall würde der Proxmox Host ja von dem NUT Server Befehle erhalten und die HA VM auch noch.

Wie sich das Synology NAS verhält ist ja klar beschrieben:

Wenn Synology NAS den Standby-Modus aufruft, werden sämtliche Dienste gestoppt und Volumes entfernt, um einen Datenverlust zu verhindern und das Gerät sicher heruntergefahren, wenn das USV-Gerät keinen Strom mehr hat. Das System wechselt standardmäßig in den Standby-Modus, wenn das USV-Gerät nur noch wenig Strom hat. Sie können auch die Zeit angeben, bis Synology NAS im Falle eines Stromausfalls in den Standby-Modus wechselt. Wenn das USV-Gerät allerdings bereits vor der angegebenen Zeit nur noch wenig Strom hat, wechselt das System sofort in den Standby-Modus.
In Situationen, in denen das Synology NAS im Standby-Modus herunterfährt, wird das Gerät automatisch eingeschaltet, wenn die Stromversorgung wiederhergestellt ist, falls die Option Nach Stromausfall automatisch neu starten aktiviert ist (unter Systemsteuerung > Hardware & Energie > Allgemein).

Aber genau solche Infos fehlen mir halt noch in Verbindung mit Proxmox und den dann darauf laufenden Dingen wie z.B. der Home Assistant VM.

Mein primäres Ziel ist es ja eigentlich das die USV kurze Stromausfälle von z.B. 5 Minuten oder so überbrückt und bei längeren Stromausfällen halt alle NUT Clients, incl. all der Dinge die darauf laufen (bei Proxmox halt die VM/LXCs), sauber herunterfährt. In der NUT Doku https://networkupstools.org/documentation.html oder z.B. auch in dem immer mal wieder erwähnten Artikel zu dem Thema Proxmox + NUT https://www.kreaweb.be/diy-home-server-2021-software-proxmox-ups/ wird natürlich so gut wie alles beschrieben und dann eben auch anhand von Befehlszeilen dargestellt, aber mir pers. fehlen dann immer irgendwie die Zusammenhänge, also hier in dem Beispiel mit Proxmox als NUT Client und einer darauf laufenden VM bei der auch ein NUT Client aktiv ist. Also braucht es das überhaupt, oder wäre das "doppelt gemoppelt" und was passiert dann wo, wann und wie.

VG Jim

 

[ThoSo]

Mein primäres Ziel ist es ja eigentlich das die USV kurze Stromausfälle von z.B. 5 Minuten oder so überbrückt und bei längeren Stromausfällen halt alle NUT Clients, incl. all der Dinge die darauf laufen (bei Proxmox halt die VM/LXCs), sauber herunterfährt. In der NUT Doku https://networkupstools.org/documentation.html oder z.B. auch in dem immer mal wieder erwähnten Artikel zu dem Thema Proxmox + NUT https://www.kreaweb.be/diy-home-server-2021-software-proxmox-ups/ wird natürlich so gut wie alles beschrieben und dann eben auch anhand von Befehlszeilen dargestellt, aber mir pers. fehlen dann immer irgendwie die Zusammenhänge,

Die Doku ist interessant (habe ich mir mal verlinkt - THX) und ich denke das könntest Du für dich auch so übernehmen.

Die Software läuft auf dem PVE Server und er hat ein LXC für das Webmonitoring aufgesetzt.
Im Falle eines Stromausfalls fährt PVE dann die VMs/LXs und anschließend sich selbst runter.

Deine Synology NAS Software (werde andere auch so halten) beendet alle Dienste und hebt die Mounts auf, schaltet aber nicht ab im Stand-By, sondern lutsch so lange an der Batterie bis der Saft alle ist - kommt der Strom zurück wird gemountet und die Dienste gestartet.

Das sind dann halt Ablauforganisatorische Dinge, ob man die Anlagen ausschaltet und manuell anfährt, oder auf das beste hofft.

 

[jim_os]

Im Falle eines Stromausfalls fährt PVE dann die VMs/LXs und anschließend sich selbst runter.

Jepp das wäre halt der optimale Fall und das würde in meinem Beispiel ja eigentlich auch bedeuten das ich mir den laufenden NUT Client auf der HA VM sparen könnte, bzw. das das ggf. sogar kontraproduktiv ist. Der Proxmox Host selber sendet dann ja eine Shutdown-Befehl (qm shutdown) an die HA VM und da bei der HA VM auch der QEMU Guest Agent läuft sollte diese dann sauber herunterfahren. Zumindest meine ich das dazu der aktivierte QEMU Guest Agent notwendig ist.

Allerdings gibt es natürlich auch noch immer mal wieder irgendwelche "Problemfälle". A) Bei VMs bei denen - warum auch immer - kein QEMU Guest Agent installiert werden kann und somit nicht aktiv ist und B) VMs die auf einen qm shutdown Befehl - warum auch immer - nicht reagieren und die man nur per "harten ausschalten" (qm stop) zum beenden bringt. Den Fall B) hatte ich hier erst vor ein paar Tagen. Auch hier fehlt mir dann leider das notwendige Wissen wie der Proxmox Host dann als NUT Server oder als Client agiert. Sprich sendet er dann, falls qm shutdown nicht funktioniert, automatisch ein qm stop an die VM? Das meinte ich u.a. damit das mir irgendwie (noch) die Zusammenhänge fehlen. Auch das man sich dann mit unzähligen, möglichen NUT Befehlen in div. config-Dateien "zu Fuß" - sprich per CLI - auseinander setzen muss macht es auch nicht gerade einfacher. Da NUT auch kein Bestandteil von Proxmox ist, findet man dazu dann in der offiziellen Proxmox Doku https://pve.proxmox.com/pve-docs/pve-admin-guide.pdf verständlicherweise auch nichts.

ob man die Anlagen ausschaltet und manuell anfährt, oder auf das beste hofft.

Ja sinnvollerweise sollte man seine NUT-Einrichtung dann eigentlich auch noch testen, wobei auch das nicht unbedingt so einfach ist. Nur weil bei einem Test, oder eben Stromausfall, alle Kiste nach x Minuten "abschalten" und am Ende aus sind, heißt das ja noch nicht das sie auch wirklich sauber heruntergefahren wurden. Also heißt es danach dann auch erst wieder irgendwelche Logs wälzen, um zu schauen ob und was dort zu einem Shutdown ggf. erfasst wurde. Oder halt - wie Du ja auch schon geschrieben hast - einfach auf das Beste hoffen.

Ja hier spielen viele wenn's und aber eine Rolle und ja Theorie und Praxis muss auch nicht deckungsgleich sein, aber wie bereits zu Anfang geschrieben beschäftige ich mich gerade mit dem Thema USV/NUT etwas mehr als ich das bisher gemacht habe und stelle dann ein paar Dinge fest über die ich mir bisher überhaupt noch keine Gedanken gemacht hatte/habe.


Edit: Vielleicht noch als Erklärung dazu. Wie ich in einem anderen Posting schon mal erwähnt hatte will ich hier meine beiden Synology NAS außer Betrieb nehmen und stattdessen soll nur noch eine Lenovo Tiny Kiste hier "NAS" spielen. Somit entfällt also auch der NUT Server der bisher auf einem Synology NAS lief. Ergo muss ich mir überlegen wie und wo ich dann zukünftig einen NUT Server mitlaufen lasse und was dann am Ende die sinnvollere Entscheidung ist. Sprich irgendeine bare metal Installation von OMV, TrueNAS, DSM oder was auch immer auf der Lenovo Tiny Kiste, oder eben auch Proxmox + entsprechende VM(s).

VG Jim

 

[Bu66as]

Gute Frage, das Thema kommt immer wieder auf. Kurz gesagt: NUT Server direkt auf dem PVE Host laufen lassen, nicht in einer VM. Alles andere wird nur kompliziert und dein Henne-Ei-Problem bleibt. Die USV hängt per USB am Host, also gehört der NUT Server auch auf den Host. Ist auch nur apt install nut und die Config anpassen (nut.conf auf MODE=netserver).

Den NUT Client in der HA VM brauchst du nicht. PVE kümmert sich beim Shutdown um alle VMs/CTs, da braucht die HA VM nicht auch noch selber reagieren. Im blödesten Fall fährt die HA VM sich per NUT Client selber runter bevor PVE den sauberen qm shutdown schicken kann, das ist dann eher kontraproduktiv.

Was passiert, wenn eine VM auf qm shutdown nicht reagiert: PVE hat da ein Timeout, default 3 Minuten (180s). Wenn die VM danach immer noch läuft wird sie hart gestoppt. Das kannst du pro VM in der Config anpassen (startup: order=...,down=...). Der QEMU Guest Agent hilft für einen sauberen Shutdown, aber auch ohne GA schickt PVE erstmal ein ACPI Shutdown Signal, das reicht für die meisten.

Bei dir mit der Lenovo Tiny und Proxmox: USV per USB an die Kiste, NUT Server auf dem PVE Host, fertig. Wenn du noch andere Geräte im Netz hast die auch runterfahren sollen, können die sich als NUT Clients beim PVE Host melden. Viel simpler als über eine VM.

 

[elvito]

Hallo zusammen,

aus gegebenem Anlass sitze ich grade genau an diesem Thema. Ich hatte bis vor einigen Tagen den nut Server direkt auf dem PVE laufen. Das hat über ein Jahr super geklappt und auch bereits erfolgreich einen Stromausfall abgefangen. Seit einiger Zeit kam bei PVE immer wieder die Fehlermeldung:

usbhid-ups[1558]: libusb1: Could not open any HID devices: insufficient permissions on everything

die sich forlaufend wiederholt. lsusb hat die USV normal angezeigt, ein

systemctl restart nut-driver@xxx.service

hat nut Server sofort wieder zum Leben erweckt. Ich bin daher nicht unbedingt von einem USB Problem ausgegangen, hatte aber auch keinen Nerv/Zeit für die weitere Fehlersuche.

Die Verbindung zwischen nut Server und USV war jedenfalls weg, ohne dass ich oder nut es mitbekommen hätten und das hat letztlich zu einem harten Crash geführt, weil PVE wiederum nicht mitbekommen hat, dass der Akku leer gelaufen ist. Das mit der Fehlermeldung habe ich erst hinterher gesehen, ich habe leider den nut Dienst selbst nicht überwacht gehabt (Who watches the Watchmen?). Hier im Forum wurde über den obigen Fehler bereits diverse Male berichtet ein Muster war für mich nicht erkennbar, genauso wie die Ursache scheinbar nie identifiziert wurde.

Ich habe mich daraufhin nach Alternativen umgesehen und bin auf dieses Projekt gestoßen --> https://github.com/JuanCF/nutwatch Auf der Githubseite ist ein Einzeiler für Proxmox erwähnt, der zumindest bei mir nicht funktioniert hat. Man kann aber auch eine VM zb mit Debian aufsetzen (alles auf default gelassen) und dort mit dem allgemeinen Linuxeinzeiler alles recht bequem installieren. Es bietet Logging, Hooks, Notification uvm. Man muss/sollte vor der Installation das richtige USB Device (USV) an die VM mappen und zumindest in meinem Fall wurde daraufhin alles automatisch erkannt und eingerichtet.

Ich bin kein Entwickler, deswegen kann ich zum Code und der Qualität nicht viel sagen. Ich habe jedenfalls Claude und Mistral über den Code schauen lassen und es wurde kein Schadcode gefunden oder besonders kritsche Sicherheitsprobleme. Evtl hilft das ja jemandem hier.

 

[TErxleben]

Ich bin kein Entwickler, deswegen kann ich zum Code und der Qualität nicht viel sagen. Ich habe jedenfalls Claude und Mistral über den Code schauen lassen und es wurde kein Schadcode gefunden oder besonders kritsche Sicherheitsprobleme. Evtl hilft das ja jemandem hier.

Aber Claude und Mistral schon? Da werde ich schon übellaunig.
Die Steuerung gehört DIREKT auf den PVE-Host. Der regelt dann das geordnete Herunterfahren. In welcher Reihenfolge VMs heruntergefahren werden, kannst du sogar nach Gusto definieren. Dazu empfehle ich dir auf jeder VM qemu-guest Treiber zu installieren, falls nicht sowieso automatisch geschehen, um sauberes Herunterfahren zu gewährleisten.
Aber es steht jedem KI-Künstler völlig frei, seine willenlosen Gedanken umzusetzen.

 

[ThoSo]

Aber Claude und Mistral schon? Da werde ich schon übellaunig.
Die Steuerung gehört DIREKT auf den PVE-Host. Der regelt dann das geordnete Herunterfahren. In welcher Reihenfolge VMs heruntergefahren werden, kannst du sogar nach Gusto definieren. Dazu empfehle ich dir auf jeder VM qemu-guest Treiber zu installieren, falls nicht sowieso automatisch geschehen, um sauberes Herunterfahren zu gewährleisten.
Aber es steht jedem KI-Künstler völlig frei, seine willenlosen Gedanken umzusetzen.

Ich habe das so verstanden, das er den Code dieser USV Mangementlösung mit den beiden Tools analysiert hat. Wo ist da das Problem? Er hat das ja nicht verfasst bzw. gecodet. Und es stammt ja auch nicht aus seiner Feder.

Ich habe nur flüchtig heute Vormittag einen Blick auf das Projekt geworfen, aber das schaut interessant aus, insbesondere wenn man mehrere Host und USV managen will. Kommerzielle Lösungen dieser Art kosten eine ganze Stange Geld!

 

[elvito]

Aber Claude und Mistral schon? Da werde ich schon übellaunig.
Die Steuerung gehört DIREKT auf den PVE-Host. Der regelt dann das geordnete Herunterfahren. In welcher Reihenfolge VMs heruntergefahren werden, kannst du sogar nach Gusto definieren. Dazu empfehle ich dir auf jeder VM qemu-guest Treiber zu installieren, falls nicht sowieso automatisch geschehen, um sauberes Herunterfahren zu gewährleisten.
Aber es steht jedem KI-Künstler völlig frei, seine willenlosen Gedanken umzusetzen.

Si tacuisses, philosophus mansisses. --> https://networkupstools.org/projects.html#_a_href_https_github_com_juancf_nutwatch_nutwatch_a Du kannst deine Bedenken ja mal mit den Entwicklern von NUT teilen

Ich habe das so verstanden, das er den Code dieser USV Mangementlösung mit den beiden Tools analysiert hat. Wo ist da das Problem? Er hat das ja nicht verfasst bzw. gecodet. Und es stammt ja auch nicht aus seiner Feder.

Genau so ist es.

Ich habe nur flüchtig heute Vormittag einen Blick auf das Projekt geworfen, aber das schaut interessant aus, insbesondere wenn man mehrere Host und USV managen will. Kommerzielle Lösungen dieser Art kosten eine ganze Stange Geld!

Das hatte ich mir auch gedacht. Ich kenne keine vergleichbare Komplettlösung für nut/USV im opensource Bereich. Falls es da schon was besseres gibt, wäre ich für einen Tip dankbar. Aktuell muss man sich noch alle Funktionen die Nutwatch ootb bietet manuell zusammenstückeln. Es ist offenkundig auch ein Vibecoding Projekt (agents.md), aber bereits in erstaunlich gutem Zustand. Evtl kann man sich im Verlauf etwas austauschen, gerne hierfür per DM melden, falls Interesse besteht.

Schönen Gruß

 

[Bu66as]

@elvito das insufficient permissions on everything ist meist gar kein Rechteproblem, sondern ein USB-Reenumerations-Ding. Die USV meldet sich (oft nach nem Glitch am USB) mit neuer Bus-/Device-Nummer wieder an, der usbhid-ups hängt aber noch am alten Handle und kommt nicht von selbst zurück. Ein Restart vom nut-driver hilft da sofort. Manchmal kann man den Treiber per Vendorroduct-ID statt port=auto binden, aber ganz weg kriegt man das nicht immer.

Aber genau das ist der Punkt: du musst die Verbindung selbst überwachen, nicht nur ob der Dienst läuft. Bei mir läuft dafür ein Watchdog (systemd-timer/cron), der upsc ups@localhost pollt und bei ausbleibenden Daten nach x Versuchen den nut-driver neustartet plus Notify rausschickt. So fängst du den Fall ab, wo der Treiber abbricht und keiner mitkriegt dass der Akku leerläuft.

Zu nutwatch: das USB-Thema löst dir die VM leider nicht, per Passthrough hast du dieselbe Reenumerierung nur eine Ebene tiefer, und beim Stromausfall das gleiche Problem. Als Monitoring/Notify-Frontend neben NUT auf dem Host kann man es aber trotzdem laufen lassen.

 

[elvito]

@elvito das insufficient permissions on everything ist meist gar kein Rechteproblem, sondern ein USB-Reenumerations-Ding. Die USV meldet sich (oft nach nem Glitch am USB) mit neuer Bus-/Device-Nummer wieder an, der usbhid-ups hängt aber noch am alten Handle und kommt nicht von selbst zurück. Ein Restart vom nut-driver hilft da sofort. Manchmal kann man den Treiber per Vendorroduct-ID statt port=auto binden, aber ganz weg kriegt man das nicht immer.

Aber genau das ist der Punkt: du musst die Verbindung selbst überwachen, nicht nur ob der Dienst läuft. Bei mir läuft dafür ein Watchdog (systemd-timer/cron), der upsc ups@localhost pollt und bei ausbleibenden Daten nach x Versuchen den nut-driver neustartet plus Notify rausschickt. So fängst du den Fall ab, wo der Treiber abbricht und keiner mitkriegt dass der Akku leerläuft.

Zu nutwatch: das USB-Thema löst dir die VM leider nicht, per Passthrough hast du dieselbe Reenumerierung nur eine Ebene tiefer, und beim Stromausfall das gleiche Problem. Als Monitoring/Notify-Frontend neben NUT auf dem Host kann man es aber trotzdem laufen lassen.

Danke für den Hinweis, ich wollte den Thread aber nicht mit meinem Problem karpern.

Das mit vendor ist ein guter Punkt, das werde ich nochmal testen. Ich glaube ich hatte bei port auto drinnen, muss ich nochmal nachsehen, die Config Files sind noch alle auf PVE drauf. Seitdem ich die USV an die VM gemappt habe (explizit das Device nicht den Port), ist das Problem nicht mehr aufgetreten. Seltsam, dass es so lange problemlos funktioniert hat. Meine Wahl ist primär auf Nutwatch gefallen, weil es sich eben auch selbst überwachen kann. Das mit watchdog auf dem PVE zu erledigen ist natürlich auch sehr gut. Das werde ich mir mal ansehen.