V-Server wiederholt nicht erreichbar

  • Guten Tag,



    in einigen Qemu-Versionen herrscht aktuell ein Bug vor, der zu Hung-Tasks führt. Einige unserer Kunden, die eigenständig Qemu nutzen, sind zum Teil von diesem Bug betroffen. Siehe dazu z.B. qemu-kvm guests panic due to hung task time-out caused by a missing memory barrier in QEMU's AIO code - Red Hat Customer Portal


    Aus dem Grund setzen wir eine eigens kompilierte Version von Qemu ein, die stabil arbeitet. Diese arbeitet unabhängig von der genutzten Distribution und Kernel.



    Mit freundlichen Grüßen


    Felix Preuß

  • Einige unserer Kunden, die eigenständig Qemu nutzen, sind zum Teil von diesem Bug betroffen.


    Vor einiger Zeit hatte KB19 mal hier berichtet, dass er sich das benötigte Flak zur Vollvirtualisierung vom Support auf seinen Root-Server hat durchreichen lassen. Von daher gehe ich mal davon aus, dass er anstelle des Emulators qemu eher kvm, welcher direkt mit im Kernel integriert ist, zur Virtualisierung nehmen wird. Von daher wäre es schon interessant, ob zur Virtualisierung auf Ihren Hostsystemen der Standardkernel 3.X oder ein neuerer Kernel z.B. 4.X oder höher verwendet wird.


    Aus dem Grund setzen wir eine eigens kompilierte Version von Qemu ein, die stabil arbeitet. Diese arbeitet unabhängig von der genutzten Distribution und Kernel.


    Virtualisieren Sie die vermieteten VPS / Root-Server mit Hilfe des Emulators QEMU oder doch eher mit KVM? Denn der QEMU ist ja ein eigenständiger Emulator und wird meines Wissens für KVM, um damit eine virtuelle Maschine unter KVM laufen zu lassen, nicht benötigt.

  • KB19
    Vielen Dank für den Link und die Info.


    Da habe ich mich durch das Auswählen zwischen QEMU und KVM in der jeweiligen Konfigurationsdatei zu jeder VM ein wenig zu sehr beeinflussen lassen und aufgrunddessen tatsächlich angenommen, es seien von daher auch unterschiedliche Emulatoren.
    Also QEMU für Systeme wie z.B. VPS- und Root-Server ohne benötigten Flak und KVM für Systeme mit benötigten Flak, auf dem VMs laufen sollen..

  • Bisher keine weiteren Software Probleme. Dafür hat es vorhin alle VMs gecrasht, weil es einen Ausfall am Node von netcup gab. Ich muss erst schauen, welchen Datenverlust ich dieses Mal verkraften muss, einige VMs fahren auf jeden Fall nicht mehr hoch... :(


    Edit: Offenbar hatte ich Glück. Das FS-Journal hat offenbar alles abgefangen, ich musste nur das Relay-Log von einem MySQL-Slave erneut vom Master laden, da es mittendrin abgebrochen ist.



    MfG Christian

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)

  • Einer meiner Server hat sich heute Nacht ebenfalls aufgehängt. Ich konnte keinerlei Anzeichen dafür in den gängigen Logs finden. Gegen 01:00 stoppte einfach jegliche Aktivität.


    Gibt es noch Möglichkeiten, diese Art von Abstürzen zu debuggen?


    Viele Grüße!

    Kommt in die inoffizielle Netcup Support-Gruppe auf Telegram: https://t.me/nc_chat :*

  • Gibt es noch Möglichkeiten, diese Art von Abstürzen zu debuggen?


    Ist nur eine Idee von mir: Eventuell kann es schon helfen, wenn du z.B. mit sar permanent Daten sammelst, um nach einen ungewollten Ausfall noch schauen zu können, ob es am Ausfalltag zu großen Abweichungen bezüglich der Iowait- und Stealwerte zu den Tagen davor gab.


    Mich würde mal interessieren, ob es einen Server mit dem kostenpflichtigem VMX-Flag betraf oder einen sehr kleinen Server für < 1 Euro?

    Einmal editiert, zuletzt von Exmember01 ()

  • Gibt es hier eigentlich neue Erkenntnisse?


    Ich war leider am Wochenende wieder davon betroffen, regulärer VServer der über das im Backend vorhandene Debian-Iso installiert wurde. Gleiches Verhalten, hung_task, keine Reaktion. :-/ Ich bin da inzwischen ein wenig ratlos.


    Grüße

    [WH 4000 SE Ost. 19] – [3x 2x VPS 200 G8] – [VPS 10 G7] – [RS M Xmas 15][WH Exp. Spezial 16]

    [Adv15 RS SL A+] – [Failover IPv6-Subnet Ost. 18] – [Cloud vLAN]

  • Ich trau mich schon gar nichts mehr hier schreiben. Immer wenn ich Entwarnung gebe, passiert etwas… :D


    Was solls: Keine besonderen Vorkommnisse! Das Ding läuft seit einigen Wochen zufriedenstellend, immer noch mit dem 4.9 Kernel aus Backports.



    MfG Christian

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)

  • Ich trau mich schon gar nichts mehr hier schreiben. Immer wenn ich Entwarnung gebe, passiert etwas… :D


    Ein KVM-Gast hängt wieder (über mein eigenes VNC sehe ich nur die Loginmaske von Linux); der Prozess am Host hängt nach dem KILL-Signal im Status "D" fest und andere Gäste können nicht mehr richtig auf das Speichermedium zugreifen: BUG: unable to handle kernel paging request at <…>


    Code
    # virsh destroy <X>
    error: Failed to destroy domain <X>
    error: Failed to terminate process 2139 with SIGKILL: Das Gerät oder die Ressource ist belegt


    Somit scheint auch der neuere Kernel langfristig nichts zu bringen… ;(



    MfG Christian

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)

  • Ich habe gestern nun Proxmox VE5 Beta auf Basis von Debian Stretch installiert auf einen neuen root mit VMX, heute früh wieder das bekannte "HungTask Problem" ...


    Kernel: Linux 4.10.8-1-pve #1 SMP PVE 4.10.8-6 (Thu, 13 Apr 2017 11:24:12 +0200)


    Ich werde mir wohl einen "echten" Server mieten müssen.....

  • Ich trau mich schon gar nichts mehr hier schreiben. Immer wenn ich Entwarnung gebe, passiert etwas… :D

    Seit meinem letzten Beitrag ist übrigens Ruhe und alles läuft einwandfrei. Eventuell lag es doch am Online-Discard, das habe ich nämlich erst vor einigen Wochen endgültig für alle Gäste deaktiviert. Oder eines der letzten Kernelupgrades hat etwas gebracht. Mal schauen, ich beobachte es weiter…

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)