RaspberryMatic als Proxmox VM, keine Onlinemigration im Proxmox Cluster möglich

[wiwo]

Ich bin im Februar 2019 von einer CCU2 auf die Raspberrymatic als VM auf Proxmox VE Plattform umgestiegen und seit diesem Zeitpunkt absolut problemlos mit jedem neuen Release unterwegs. Alle HM/HM-IP Funk-Anbindungen sind zwischenzeitig ebenfalls via LAN realisiert, so dass kein direkter Hardwarebezug mehr zu der VM Plattform besteht.

Ich habe mich dann entschlossen, ein Proxmox VE Cluster mit zwei Knoten aufzubauen um die Hardwareverfügbarkeit zu verbessern. Ich habe beide Server(chen) mit Procmox VE 7.1-10 mit ZFS-Filesystem neu aufgesetzt und die bisher genutzten VMs (Raspberrymatic und ioBroker) sowie einen Container mit einer SQL Datenbank für das ioBroker Archiv auf einen der Server zurückgespielt, alles läuft so problemlos wie vorher.

Da jetzt beide Server ein ZFS-Filesystem haben konnte ich eine zyklische Replizierung auf den zweiten Clusterknoten für die VMs und den Container aufsetzten um bei Bedarf eine Online- oder auch Offline-Migration der VMs durchzuführen. Eine zyklische Replizierung zwischen den Servern dauert ca. 5 Sekunden pro VM, eine Migration benötigt ungefähr die gleiche Zeit.

Bei der ioBroker VM unter Debian sowie dem SQL-Container ebenfalls unter Debian ist die Migration der laufenden Maschinen auf den zweiten Knoten problemlos möglich, leider stürzt die RaspberryMatic VM dabei ab und muss auf dem Zielknoten manuell neu gestartet werden.
Dort läuft sie dann ebenfalls problemlos meldet lediglich eine Shutdown mit unsauberem Filesystem, was verständlich ist. Offline Migrationen sind für alle VMs problemlos möglich.

Ich verwende die RM Version 3.61.7.20220115 und habe zwecks Überprüfung auch eine neutrale leere zweite Instanz der RM mit der gleichen Version aufgesetzt aber ohne meine Homematic Konfiguration, das Verhalten ist leider gleich. Es scheint also bei der RM VM eine Besonderheit zu geben die ich aber leider bisher nicht ergründen konnte.

Ich gebe zu, mein Problem ist nicht ganz alltäglich aber ggf. hat ein Mitleser aus anderem Umfeld eine Idee dazu.

Gruss Wolfgang

[jmaus]

Das ist in der Tat eine interessante Feststellung die ich gerade hier selbst einmal nachstellen konnte in meinem eignen Proxmox-Cluster. Auch da schmiert eine vanilla RaspberryMatic ab wenn man diese zwischen den Knoten migrieren lässt.

Du könntest dazu allerdings bereits ein entsprechendes Issue-Ticket auf GitHub aufmachen. Vielleicht bekomm ich das ja repariert, auch wenn der nutzen sicherlich eingeschränkt ist und ich mir auch nicht sicher bin ob ohnehin nicht deine HB-RF-ETH verbindung über das migrieren hinweg dann stabil funktionieren wird.

[wiwo]

Hallo Jens,

herzlichen Dank für den schnellen "Gegentest". Das Ticket werde ich sehr gerne eröffnen.

Mein bisheriger Eindruck ist, dass die HB-RF-ETH Kommunikation recht stabil scheint. Wenn ich in dem Cluster eine HA Gruppe aktiviere und die RM VM nach der Migration auf dem 2ten Knoten nicht wieder startet wird sie durch die HA Einstellung wieder auf den 1ten Knoten zurück migriert und dann gestartet und die HB-RF-ETH Kommunikation läuft dann wieder, somit bin ich vorerst hoffnungsvoll, allerdings ist es ja ein RM boot.

Gruss Wolfgang

[jmaus]

herzlichen Dank für den schnellen "Gegentest". Das Ticket werde ich sehr gerne eröffnen.

Probier mal in den Memory Settings der RaspberryMatic VM explizit dort unter "Advanced" den Punkt "Ballooning Device" abzuschalten. In meinen Tests hat das bereits den Erfolg gebracht und ich konnte bei abgeschaltetem Ballooning die VM problemlos zwischen den Cluster Nodes online hin+her migrieren.

Warum das allerdings passiert kann ich noch nicht genau sagen bzw. hab ich noch nicht rausgefunden.

[wiwo]

Habe ich für die VM umgestellt, funktioniert soweit ich bisher feststellen konnte problemlos.

Auch das produktive System mit HB-RF-ETH, HM-LGW + HmIP-HAP läuft problemlos auf dem anderen Knoten weiter, es gibt lediglich zwei Einträge im Syslog und eine sich daraus ergebende Alarmmeldung im GUI die mir erst einmal plausibel erscheint

Der Umzug der VM dauert je nach Richtung zwischen 15 und 18 Sekunden, die echte Downtime wird mit ~28ms angegeben.

Frage: Soll ich noch ein Ticket einstellen damit du ggf. weiter suchst oder die Dokumentation anpasst?

Gruss und vielen Dank Wolfgang

Hier der Vollständigkeit halber noch der Syslog Eintrag:

Code: Alles auswählen

Jan 29 09:55:42 raspberrymatic user.err monit[989]: 'ntpOffsetCheck' status failed (20) -- -1.520694852
Jan 29 09:55:42 raspberrymatic user.info monit[989]: 'ntpOffsetCheck' exec: '/bin/triggerAlarm.tcl NTP offset > 1 second WatchDog: chronyd-highoffset true'

[jmaus]

Frage: Soll ich noch ein Ticket einstellen damit du ggf. weiter suchst oder die Dokumentation anpasst?

Bitte, ja.

[Ralli_]

Abonniert, für den Fall, dass hier noch einmal was passiert

[Xel66]

Abonniert...

Kann man auch mit dem Dropdown neben dem "Antworten"-Button machen. Und sogar ein persönliches Lesezeichen setzen. Damit findet man wichtige Threads noch schneller.

Gruß Xel66