VM resettet sich

  • Hallo zusammen,


    mein RS 2000 G9 resettet sich alle paar Stunden bis alle paar Tage.


    Darauf laufend: Proxmox, Debian 10 ohne Gäste.

    Kernel: 5.4.73-1-pve #1 SMP PVE 5.4.73-1 (Mon, 16 Nov 2020 10:52:16 +0100) x86_64 GNU/Linux

    (auch mit vorheriger Kernelversion gab es Probleme)


    ZFS ist im Einsatz, aber nicht als Root System.

    Support hat mit die VM schon auf einen anderen Host umgezogen, dennoch besteht das Problem.

    Journal schreibt persistent auf die Platte, allerdings gibt es keinen ersichtlichen Grund für die Resets.


    Hat da jemand noch Ideen?

  • Kannst du mal beschreiben, was du genau mit dem Reset meinst?


    Falls du auch ein eigenes System Zuhause haben solltest, welches virtuelle Maschinen unter KVM ausführt, so würde ich an deiner Stelle diese problematische virtuelle Maschine auf das eigene System mal spiegeln, um dessen Verhalten zu beobachten.

  • Er bootet einfach neu. Sehr gut zu sehen an der Uptime.

    Das hatte ich bei meinem RS Rentier (auf Intel Basis) auch schon einige male. Laut Support liegt das an meinem Betriebssystem, auch wenn ich das ganz klar ausschließen kann und auch bewiesen habe. Trotz Nutzung des Beschwerdeformulars kam keine Einsicht seitens des Supports.


    Ich habe das System mittlerweile gekündigt und zu einem anderen Hoster umgezogen.

  • Wie kann man denn so was zweifelsfrei beweisen?

    Wenn das OS crasht, dann kann das nicht einfach passieren, ohne dass irgendwo etwas geloggt wird. Selbst bei Kernelpanic muss etwas in der kern.log stehen... das war aber alles nicht der Fall, ich habe einen harten Logabriss mitten im Betrieb vorgefunden. Das Monitoring hat zu keinem Zeitpunkt Auffälligkeiten gezeigt, die auf einen derartigen Absturz des Systems o.Ä. hingedeutet hätten. Der Server war auch nicht unter großer Last oder so, der hat mit recht wenig Last seine normalen Aufgaben erfüllt. Eine Interaktion von einem Dritten hat nicht stattgefunden, sonst hätte dies in den SCP Logs gestanden bzw. stehen müssen.


    Und da das ganze in der Form wie gesagt in unregelmäßigen (wenn auch recht großen) Abständen mehrfach passiert ist, muss da am Hypervisor etwas faul sein.


    Zudem hatte ich 1:1 das selbe Szenario neulich mal bei einem Mitbewerber und ganz rein Zufällig meinte der Support dort, dass es deren Schuld sei, man sich entschuldige und analysieren würde, warum ich keine Benachrichtigung erhalten habe.


    Und an der Stelle habe ich dann zu 100% keine Zweifel mehr, dass da nicht irgendetwas am Hostsystem ausgehakt haben muss.



    Für mich ist es auch nicht die Sache, dass es passiert ist (das war eigentlich gar nicht mal soooo schlimm), sondern, wie vom Support damit umgegangen wird.

    Und da der Netcup Support, wie auch in einigen anderen Situationen (und nicht nur bei mir), solche und andere Probleme, die noch eindeutiger deren Schuld sind, eiskalt abstreitet, anstatt sich darum zu kümmern, habe ich dann für mich meine Konsequenzen gezogen und gehandelt.

  • Well look at that. Gerade über Stunden die SSH Sitzung aufgehabt nebenbei - stderr zeigt da etwas.


    Message from syslogd@beta at Nov 23 22:40:53 ... kernel:[26517.537956] watchdog: BUG: soft lockup - CPU#0 stuck for 21s! [kworker/u8:2:8097]


    dmesg hat sogar einen Stacktrace - das Ereignis führte aber nicht zum Absturz. Festplattenzugriff.

    Code
    1. [26517.538111] ata_scsi_queuecmd+0x124/0x350
    2. [26517.538121] scsi_queue_rq+0x696/0xa00


    Die Logs der letzten Tage haben allerdings keinen Treffer, wenn ich nach dem Sprungaddressregister suche.


    Oder ist es eher so als würde man den Stromstecker ziehen?

    Dies. Letzte Logzeilen kommen nur von sshd mit einem gescheiterten Login.


    Eigentlich sollte die Maschine sich nicht zurücksetzen, wenn der SCSI Stack klemmt, oder?

  • Kann es sein, dass Du ein AMD-Wirtssystem mit einem nicht unbekannten Soft-Lockup-Bug hast? Die Ryzen-Kerne der ersten Generation haben das gerne auf verschiedenen Boards gemacht, wenn die Stromsparfunktionen aktiviert waren. Das müsste dann auch die anderen Kunden betreffen.

  • Kann es sein, dass Du ein AMD-Wirtssystem mit einem nicht unbekannten Soft-Lockup-Bug hast? Die Ryzen-Kerne der ersten Generation haben das gerne auf verschiedenen Boards gemacht, wenn die Stromsparfunktionen aktiviert waren. Das müsste dann auch die anderen Kunden betreffen.

    Der Bug ist ja schon paar Tage älter (2017 / 2018) und die Epyc Reihe scheint davon nicht betroffen zu sein.

    Es gibt da ein paar Maßnahmen, die getroffen werden können: z.B. rcu_nocbs, was aber nach einigen Quellen Kernel selber bauen bedeutet.


    Die C States des Prozessors kann ich unmöglich einschränken, oder?

  • Die C States des Prozessors kann ich unmöglich einschränken, oder?

    Eventuell hilft dir das Paket tuned weiter. Denn mit Hilfe dieses Pakets kannst du folgende Einstellungen vornehmen:

  • Siehe auch https://forum.netcup.de/admini…312-cpu-softlock-mit-pve/ und https://forum.proxmox.com/thre…on-nested-kvm-host.77273/ Das liegt an Netcup unter AMD. Die betreiben 'ne alte/komischen Kernel bei dem es diese Fehler für nested-virt definitiv noch gibt. (Erst gestern wieder neu gestartet) Immerhin startet dein System von selbst neu.

    Danke für deine Antwort. Ich betreibe allerdings kein Nested KVM und hab auch nicht die VMX Flag auf dm System.


  • Ich würde ja fast vermuten, dass dieser "watchdog" hier selbst das Problem ist. Der kann das System nämlich tatsächlich neu starten, wenn er glaubt, es würde etwas hängen. Keine Ahnug, wie er das feststellen will. Bei einer VM ist es ja normal, das dem System nicht 100% der CPU-Zeit zur Verfügung steht.

  • Keine Ahnug, wie er das feststellen will. Bei einer VM ist es ja normal, das dem System nicht 100% der CPU-Zeit zur Verfügung steht.

    Bei einem Root Server mit garantierten CPU Resourcen und einer garantierten CPU Steal von unter 3% sollte kein Prozess 21s verhungern müssen.