Nested KVM crasht Server

    Mit CentOS 7 kommen die Kernel Meldungen auch.
    Der Server läuft aber danach weiter, hat aber eine load avarage von >20.0

    Über VNC komme ich nicht auf meine VM (State running)

    VNC ist aber offen:

    [root@virt1 var]# netstat -tln|grep :59
    tcp 0 0 0.0.0.0:5900 0.0.0.0:* LISTEN


    Wenn ich über VNC verbinden möchte, erhalte ich einen Timeout.


    UPDATE: Jetzt - nach gut 10 Minuten - reagiert auch CentOS 7 nicht mehr auf Eingaben.

    Moin zusammen,

    ich melde mich nochmal, um die offizielle Antwort des Netcup Supports auf meine Anfrage hin zu posten:

    Zitat


    Sie besitzen bei uns einen virtuellen Server. Wir stellen Ihnen die Laufzeitumgebung bereit. Zu individueller Software und zur Einrichtung können wir keinen Support geben. Nach Einrichtung haben wir keinen Zugriff mehr auf Ihr System. Die Einrichtung und Konfiguration Ihrer Dienste und Pflege obliegt Ihrer Verantwortung.

    Ist aus meiner Sicht eine legitime Meinung. Allerdings steht ja im Raum, dass es sich eben um ein Problem mit der "Laufzeitumgebung" handelt und nicht nur ein Problem mit der Anwendersoftware.

    Von daher habe ich erwartet, dass zumindest im Ansatz das Interesse besteht, den Kunden bei dieser Problemstellung zu unterstützen.

    Wie auch immer. Ich schaue mich woanders um. Bei anderen Anbietern wird das VMX Flag (ohne Zusatzoption) durchgereicht und dort funktioniert mein Skript aus dem Eingangspost auch ohne weitere Anspassungen oder Probleme.

    Also nochmal für alle die auf diesen Thread stoßen:

    Durch die VMX Zusatzoption ist es NICHT ohne Probleme möglich eine KVM beschleunigte virtuelle Maschine auf den Root-Servern zu betreiben. Bei manchen Kunden scheint es zu funktionieren, bei vielen allerdings NICHT.

    WassdSchoBassdScho

    Ich weiß zwar nicht, ob du dein Vorhaben mit deinem Root-Server RS8000 schon aufgegeben hast. Aber da dein Root-Server den Lasttest erfolgreich durchlaufen hatte und das Ergebnis laut deinem Benchtest recht gut aussieht, gehe ich jetzt einfach mal davon aus, dass es auf deinem Root-Server softwareseitig noch Probleme geben wird.

    Eventuell mußt du nur noch die passenden Treiber nachinstallieren.


    Ob überhaupt Treiber installiert sind, kannst du mit folgenden Befehl feststellen:

    lsmod | grep vir


    Die Ausgabe danach sollte dann unter CentOS 7 in etwa wie folgt aussehen:

    Code
    virtio_balloon 13834  0
virtio_scsi    18361  1
virtio_pci     22913  0
virtio_ring    21524  4 virtio_pci,virtio_balloon,virtio_scsi
virtio         15008  4 virtio_pci,virtio_balloon,virtio_scsi

    Vor gut über 14 Tagen hatte ich geschrieben, dass ich interessehalber auch eine TestVM unter einem Root-Server mit durchgereichtem VMX Flag installiert habe. Siehe hier.


    Da diese TestVM bis heute noch ohne Probleme darauf läuft und nur mal zwischendurch von mir neu gestartet wurde, um damit deren Startverhalten zu beobachten, habe ich heute auch mal einen Belastungstest mit Hilfe eines Bench-Tests durchgeführt, dessen Ergebnis akzeptabler Weise wie folgt aussieht:

    Auch ein Schreibtest auf deren virtuellen Festplatte mit Hilfe des DD-Befehls war für diese TestVM kein Problem und sieht wie folgt aus:

    Ergebnis ohne Cache:

    dd if=/dev/zero bs=1M count=900 of=output oflag=direct

    943718400 Bytes (944 MB) kopiert, 4,90509 s, 192 MB/s

    Ergebnis mit Cache:

    dd if=/dev/zero bs=1M count=900 of=output

    943718400 Bytes (944 MB) kopiert, 0,791823 s, 1,2 GB/s


    Da ich in meiner TestVM die Home-Partion unter 1GB gehalten habe, konnte ich auch keine größere Testdatei erzeugen.

    Ja, ich habe es noch nicht aufgegeben.

    Das liegt daran, dass der Server für ganze 12 Monate gebucht ist.

    Da man VMX natürlich nur für alle Prozessoren nehmen kann, läuft das auch für volle 12 Monate.

    Und über die Zufriedenheitsgarantie ist netcup nicht bereit, die Kosten für das VMX-Flag zurückzuerstatten.


    Hier noch die Ausgabe des CMD:

    Code
    [root@virt1 ~]# lsmod | grep vir
virtio_balloon         20480  0
virtio_scsi            20480  2
virtio_pci             24576  0
virtio_ring            24576  3 virtio_scsi,virtio_balloon,virtio_pci
virtio                 16384  3 virtio_scsi,virtio_balloon,virtio_pci

    phillu und WassdSchoBassdScho:

    Interessehalber habe ich es heute auch mal mit dem Image, welches auch von phillu zum Testen verwendet wurde, probiert. Auch auf meinem Root-Server verhält es sich so wie von euch beschrieben. Denn es startet, aber friert danach ein.

    Betriebssysteme, die aber über eine eigene ISO-Dateien installiert wurden, funktionieren ohne Probleme auf dem Root-Server.

    Das wäre eine interessante Erklärung. Bei mir funktioniert es ja bekanntlich und ich installiere meine netcup Server ausschließlich mittels ISO. (Debian Netinstall / Expertenmodus)


    MfG Christian

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

    Wenn du es noch nicht aufgegeben haben solltest, so könntest du uns mal das erste bis dritte Ergebnis des folgenden Befehls hier posten. Eventuell liegt es auch am IO des RAM´s. Denn deine VM, die du auf deinem Root-Server startest, verhält sich wie ein zusätzlicher Prozeß (ein Prozeß pro Kern deiner VM) auf deinem Root-Server, der in RAM geladen wird. Ist dieser Ladevorgang aufgrund schlechtem IO des RAM´s zu träge, aber die Kerne deines Root-Servers bekommen die volle Leistung pro Kern vom Wirt-System durchgereicht, so steigt zwangsweise auch das Load Average an. Im ungünstigsten Fall friert dein Root-Server - wie auch schon von dir hier berichtet - dadurch ein.


    dd if=/dev/zero bs=1M count=10000 of=/dev/shm/output


    Im günstigsten Fall sollte der Durchsatz zwischen 1 bis 5 GB/s liegen, um eine virtuelle Maschine darin ohne Probleme starten zu können.

    Zitat von AndreasDe

    Wenn du es noch nicht aufgegeben haben solltest, so könntest du uns mal das erste bis dritte Ergebnis des folgenden Befehls hier posten. Eventuell liegt es auch am IO des RAM´s. Denn deine VM, die du auf deinem Root-Server startest, verhält sich wie ein zusätzlicher Prozeß (ein Prozeß pro Kern deiner VM) auf deinem Root-Server, der in RAM geladen wird. Ist dieser Ladevorgang aufgrund schlechtem IO des RAM´s zu träge, aber die Kerne deines Root-Servers bekommen die volle Leistung pro Kern vom Wirt-System durchgereicht, so steigt zwangsweise auch das Load Average an. Im ungünstigsten Fall friert dein Root-Server - wie auch schon von dir hier berichtet - dadurch ein.


    dd if=/dev/zero bs=1M count=10000 of=/dev/shm/output


    Im günstigsten Fall sollte der Durchsatz zwischen 1 bis 5 GB/s liegen, um eine virtuelle Maschine darin ohne Probleme starten zu können.

    Result:

    Code
    [root@virt1 ~]# dd if=/dev/zero bs=1M count=10000 of=/dev/shm/output
10000+0 records in
10000+0 records out
10485760000 bytes (10 GB) copied, 62.7238 s, 167 MB/s
[root@virt1 ~]#

    WassdSchoBassdScho

    167 MB/s ist einfach zu wenig. Hast du deswegen auch schon mal den Support bemüht?

    Heute habe ich auf einem RS 6000 G7 SE mit dem Betriebssystem OpenVZ 7 auch mal diesen Befehl abgesetzt und kam auf einen deutlich besseren Wert.


    dd if=/dev/zero bs=1M count=10000 of=/dev/shm/output

    10156507136 Bytes (10 GB) kopiert, 5,001496 s, 2,0 GB/s

    Erst wollte der Support mich auf eine neue Node migrieren, jetzt können sie den Fehler nicht mehr nachvollziehen.

    Wenn ich den CMD nun ausführe (3x):

    Mittlerweile bin ich echt etwas enttäuscht vom Support.

    Ich habe den größten Root-Server genommen mit maximaler Laufzeit und zusätzlich direkt das VMX Feature.

    Und bekomme nach ewigen Mailketten "wir können das nicht nachvollziehen"....

    Guten Tag,

    unser Support hat Sie gebeten, die Sache im Rettungssystem zu prüfen. Nach den mir vorliegen Informationen haben Sie dieses noch nicht getan.

    Da sowohl auf dem Node selbst als auch in einer VM die auf den gleichen Node liegt die Probleme nicht nachvollziehbar waren, können wir Fehler am Node selbst ausschließen. Gerne würden wir sicherstellen, dass an der Konfiguration Ihrer VM alles in Ordnung ist. Sollte das auch über das Rettungssystem verifiziert sein.

    Die von Ihnen genannten Werte deuten darauf hin, dass Ihr System /dev/shm auf die Festplatten schreibt, statt im RAM. Das ist z.B. der Fall, wenn Ihr System am swappen ist.


    Mit freundlichen Grüßen


    Felix Preuß

    Nunja, wie auch immer..

    Ich habe es nun öfters und mit mehreren Distributionen, verschiedenen Kernels, verschiedenen Lösungen probiert.

    Auch "Fertiglösungen" die mit KVM arbeiten (oVirt, Proxmox, Univention Corporate Server) hatten immer das selbe zur Folge: Server ist nicht mehr erreichbar.

    Ich werde das nun wahrscheinlich aufgeben..

    Zitat

    Ich lese nun immer wieder auf anderen Seiten, dass man evtl im BIOS etwas einstellen kann - da komm ich aber natürlich ja nicht hin.

    Was soll das sein? Wenn ich es richtig lese, haben Sie VMX bereits aktivieren lassen.

    Wenn Sie etliche Distributionen probiert haben, warum starten Sie nicht einmal ins Rettungssystem und prüfen hier die Performance von /dev/shm ? Mögliche Gründe für langsame Schreibraten auf /dev/shm habe ich ja bereits in #37 aufgeführt. Können Sie diese ausschließen?

    Mit freundlichen Grüßen


    Felix Preuß