VM resettet sich

  • Also ich habe mal versucht die Maschine auf Debian11/PVE 7 hoch zu ziehen.

    Allerdings kommt dann keine VM weiter als bis zum ersten kernel-init, danach gibts sofort 'n hangup. Reproduzierbar sobald eine VM bootet, es liegt also definitiv am VMX support. Auch eine neue VM mit Debian 11 in Proxmox hat das Problem nicht gelöst, es liegt also nicht an komischen Guests o.ä. (Host shutdown ist dann natürlich auch blockiert.)


    Leider ist damit die Lösung für mich einfach weiterhin Debian 10 + Proxmox 6 und ein restart-bot auf'm VPS für dieses System. Laut NC wird das VMX Flag auch nicht mehr angeboten seit diesem Jahr (und Support beendet) und ein womöglicher Fix durch ein Upgrade des HVS wird i-wann nächstes Jahr stattfinden. Bis dahin also durchhalten - ich hoffe mein Setup fängt bis dahin nicht an die gleichen Symptome zu haben wie ein PVE 7. Ein Crash per Woche ist ok, aber wenn es nimmer bootet wäre halt nix mehr zu machen.

  • Kann ich leider bestätigen - hatte ich bei einem Kunden auch. Habe es aber auf den alten Gast geschoben.

    Unter Kernel 5.4 bootete der Gast, unter 5.10 hatte der Gast seine Probleme.

  • Ich verstehe es halt nicht. Hier mal ein Diff zwischen einer Kernel Config von Ubuntu (LXD läuft hier ja) und Proxmox (Netcup Server resettet sich ohne Gäste):


    Compiler kann es auch nicht sein, da PVE 7 wieder mit GCC 10 kompiliert wird, und da gibt es auch Haufen Probleme.


  • Unter Kernel 5.4 bootete der Gast, unter 5.10 hatte der Gast seine Probleme.

    Bei Kernel 5.10 scheint leider mit/nach v5.10.8 der Wurm 'drin zu sein, was Virtualisierung anbelangt… Auch mit LXD ließen sich auf arm64/aarch64-Hosts aufgrund von Änderungen keine VMs mehr starten. Wurde bei v5.10.56 auch nicht besser, sodass ich für diese Architektur nun leider auf Nicht-LTS-Kernel angewiesen bin (v5.13.16 läuft zusammen mit einem wenige Tage alten Patch). Auf v5.10.7 oder früher mag ich allerdings auch nicht zurückgehen, da das ja den LTS (langfristige Updates) konterkariert – ggf. wäre ein "früher v5.10-Kernel" allerdings hier eine Option für Proxmox, wenn noch älteren Kernel bestimmte Eigenschaften fehlen?

    VServer IOPS Comparison Sheet: https://docs.google.com/spreadsheets/d/1w38zM0Bwbd4VdDCQoi1buo2I-zpwg8e0wVzFGSPh3iE/edit?usp=sharing

  • Ich glaube es geht schon wieder los.

    Ich habe wieder resets, trotz neuerem Kernel...

    Hallo zusammen,

    nachdem ich immer mit Hoffnung auf Lösung auch schon eine Weile mitgelesen habe, hier mal meine Erfahrungen zum Thema.
    Vielleicht finden wir ja doch irgendwann einen Zusammenhang ...

    Ich betreue z.Z. 2 Cluster mit jeweils 3 Nodes mit Proxmox 6.4, ich nenn die jetzt mal "soft" und "netz" zur Unterscheidung.
    Verbunden sind die jeweils per cloudVlan M und CloudVlan free.
    Da ich nur container brauche, hab ich auch kein vmx Flag dazu gebucht. HA-setup mit Failover-IPs, was unterm Strich
    nicht viel Sinn macht, wenn jetzt mehr Reboots auftreten als bei normaler Nutzung (auch wenn's trotzdem flexibler ist).


    Bei "netz" sind 2x RS4000 G9 und ein VPS 100 -> da gab es bis zum 20.9. keine unvorhergesehenen Reboots. Gar keine.
    Bei "soft" sind 2x RS4000 G9 und ein RS2000 G8 (auch der hat sich, obwohl Intel, schon mal alleine rebootet).


    Hinzugekommen ist jetzt noch ein RS Superuser vom 21.9., dort hab ich Proxmox 7 aktuell vom iso installiert. Da ging es mit
    Reboots am 26.9. und 28.9. los - bin dort allerdings noch innerhalb der 30 Tage, würde den gern als PBS mit nur 1-2 container nutzen.

    Fragen:

    • hat jemand schon mal mit dem Hochsetzen von 'kernel.watchdog_thresh' per sysctl experimentiert?
    • das o.g. Script zum Ausschalten per CCP bzw. SCP/API ... was genau bringt das? Längere Uptime, weil dann nicht so schnell wieder ein Reboot passiert?
    • kann sich jemand erklären, warum bei dem "netz" Cluster s.o. die Reboots erst jetzt angefangen haben (nach 3 Monaten)? Bei m.E. gleicher Konfiguration.
    • Hat jemand Aussagen zum Support dazu (außer "Proxmox wird nicht unterstützt"), also z.B. "passiert nur mit zfs" oder "Debian 10 + proxmox manuell installieren"?
    • Ideen, wie man an die Kernel-Ausschriften kommt, rsyslog z.B. o.ä.?

    Vielen Dank schon mal für eure Antworten. :/

    Falko

  • Hat jemand Aussagen zum Support dazu (außer "Proxmox wird nicht unterstützt"), also z.B. "passiert nur mit zfs" oder "Debian 10 + proxmox manuell installieren"?

    Keine Aussage vom Support, aber eigene Erfahrung.

    Alle meine Proxmox Kisten sind Debian + Proxmox manuell installiert. Spielt also keine Rolle.

    Auch ZFS hatte ich schon auf den gleichen Systemen mit Ubuntu und LXD im Einsatz, ohne Probleme.



    Ideen, wie man an die Kernel-Ausschriften kommt, rsyslog z.B. o.ä.?

    Persistentes systemd journal auf die Festplatte schreiben. Das ganze führt aber zu nichts, weil der Kernel über den Absturz keinen Log schreibt. Es gibt auch keine Kernelpanik. Du kannst auch eine SSH Sitzung auflassen die dir dann wegbricht, wenn er abstürzt, mit den letzten Meldungen noch im Terminal.

  • das o.g. Script zum Ausschalten per CCP bzw. SCP/API ... was genau bringt das? Längere Uptime, weil dann nicht so schnell wieder ein Reboot passiert?

    Mit VMX Flag unter RS4000 G9 hast du keinen Reset, der betroffene CPU-"Kern" hängt sich vollständig auf, den siehst du nie wieder, auch der Host verliert diesen Kern (und alle darauf laufenden Prozess + VMs) vollständig. Es ist also völlig random ob du 1 bis alle CPU Kerne verlierst, früher oder später alle. In meinem Fall ist das Skript einfach nur dazu da den Host hart zu resetten sobald gewisse relevante Dienste nicht mehr verfügbar sind, ihm aber die Chance zu lassen andere Daten weg zu schreiben, da vielleicht nur diese VM betroffen ist, die restlichen Systeme also noch herunter fahren könnten.

  • Ok, verstehe, vielen Dank für eure Antworten.


    Bleibt für mich die Theorie, dass bei meinem "netz" Cluster bisher alle nodes auf neueren Hostsystemen waren/sind, und dann nur die eine Maschine auf einen älteren/anderen Host verschoben wurde, der die Reboots (= Ryzen-Bug?) hat ... Die anderen vom "soft" Cluster und der RS Superuser mit pve7 könnten entsprechend alle auf älteren sein. Klingt das plausibel? Wenn ja, müsste der Support das doch eigentlich zuordnen können ...


    Kernel sind bei mir alles 5.4.x, auf pve7 ist 5.11.22 - entsprechend aktuell. Demnach bringt upgrade auf 5.11 bei pve6 auch nix. Nur Wechsel auf G8 ... und den RS Superuser wieder zurückgeben, da noch innerhalb 30 Tage. Den nutze ich im Moment nur zum pve7-Experimentieren, weil ich dort das private network mit lxc noch nicht hinbekommen habe - anderes Thema.

  • So melde mich hier auch, da ich das gleiche Problem habe und auch im Proxmox Forum erst gemeldet hatte:

    https://forum.proxmox.com/thre…f-node.96503/#post-421128


    Seitdem ich den VPS 1337 21 neu hab und manuell neuestes proxmox mit bullseye und 5 lxc containern mit bullseye installiert hatte, habe ich einfach resets ohne dass im ccp was steht bzw. in den logs. (siehe proxmox thread)

    Mit meinem vorherigen VPS Ostern XL 21 hatte ich das Problem nicht auch mit proxmox bullseye aber buster lxc containern.

    Dateisystem jeweils ZFS

    Es ist wirklich nervig und ich weiß nicht was man machen kann. Einmal hatte ich sogar 9 Tage lang nichts, doch jetzt wieder alle paar Stunden plötzliche reboots/resets


    Update: Im kernel log steht nur: Poweron or device reset occurred

    Linux proxmox 5.11.22-4-pve #1 SMP PVE 5.11.22-9 (Wed, 22 Sep 2021 10:11:11 +0200)

    Nutze kein Luks

  • Weil ich es hier jetzt nicht nochmal explizit gelesen hatte: Aussage vom Support war nochmal dass man vil. nächstes Jahr was macht. Vorerst sei VMX nicht mehr buchbar.

    Hmm, also ich bin ja wirklich gespannt, ob auch Proxmox mit reinen Containern, sprich KEIN nested KVM und auch KEIN VMX flag betroffen ist. Denn sollte das der Fall sein wäre das für mich ein außerordentlicher Kündigungsgrund. Ohne Containervirtualisierung kann ich die Kiste leider nicht brauchen; wäre dann auch nicht bugfree seitens Netcup.


    Falls nur VMX + eigenes nested KVM betroffen ist, ist es natürlich in Ordnung wenn der Support da nix (rechtzeitig) macht, da es auch offiziell nicht angeboten wird.

  • Hmm, also ich bin ja wirklich gespannt, ob auch Proxmox mit reinen Containern, sprich KEIN nested KVM und auch KEIN VMX flag betroffen ist.

    Nein, LXC/LXD benötigen definitiv kein VMX-Flag.

    VServer IOPS Comparison Sheet: https://docs.google.com/spreadsheets/d/1w38zM0Bwbd4VdDCQoi1buo2I-zpwg8e0wVzFGSPh3iE/edit?usp=sharing

  • das nicht aber andere hatten ja ihre resets dann mit proxmox

    genau darum gings mir. Wenn das mit der aktuellen Proxmox VE 7.1-4 und kernel 5.13.19+ immer noch der Fall sein sollte und nicht als Problem seitens Support angesehen wird, werde ich wohl beim zuletzt gebuchten Server die Zufriedenheitsgarantie nutzen und den anderen einfach kündigen und zu einem anderen Hoster umziehen müssen, wo entsprechende Patches / Kernel updates eingespielt werden.

  • genau darum gings mir. Wenn das mit der aktuellen Proxmox VE 7.1-4 und kernel 5.13.19+ immer noch der Fall sein sollte

    Ich habe gestern meinen Node mit Proxmox 7 auf den Kernel 5.13.19-1-pve upgedated. Heute Morgen kam es wieder zu dem Reboot Problem. Das System läuft laut SCP seit über 200 Tagen. Es ist ein KVM Update ausstehend. Ich werde jetzt erstmal die Kiste runterfahren, damit das KVM Update sicher greift und dann nochmal beobachten. Ich habe das Reboot Problem nur auf dem Proxmox 7 Node, der Proxmox 6 Node läuft ohne Probleme.

  • Voja wird einfach nur die Benachrichtigung im CCP meinen, das hat nix mit dem Problem zu tun. Eher wie wenn dein linux dich auffordert mal neu zu starten weils ja kernel updates gab und du glaubst damit dein GPU treiber problem zufällig zu lösen.