Nested KVM crasht Server

    Moin,


    habe heute einen Root-Server "RS 2000 G7 SE" inklusive durchgereichtem VMX Flag für alle Kerne bestellt.
    Wenn ich auf dem Host nun eine KVM VM starten will, hängt sich der Server auf. Ist also nicht mehr per SSH zu erreichen und kann nur noch per SCP neu gestartet werden.


    Folgende Schritte habe ich unternommen:
    - Frisches ubuntu 16.04 installiert
    - sudo apt update
    - sudo apt full-upgrade
    - sudo reboot
    - sudo apt install kvm cloud-utils genisoimage libguestfs-tools


    # Image runterladen, uncompressen, resizen und delta disk erzeugen
    - wget Ubuntu Cloud Images -O disk.img.dist
    - qemu-img convert -O qcow2 disk.img.dist disk.img.orig
    - qemu-img resize disk.img.orig +10G
    - qemu-img create -f qcow2 -b disk.img.orig disk.img


    # kvm starten
    - sudo kvm -net nic -net user,hostfwd=tcp::10022-:22 -hda disk.img -curses -m 4096


    Hier crasht der Server dann komplett. SSH nicht mehr erreichbar. Kein anderer Port. VNC Konsole nicht mehr bedienbar, nimmt keine Eingaben mehr an. In den SCP Statistiken sieht man, dass ein Kern durchgehend auf 100% läuft.


    Hier noch ein paar Diagnose Ausgaben:
    - kvm-ok
    INFO: /dev/kvm exists
    KVM acceleration can be used


    - grep vmx /proc/cpuinfo
    Zeigt das Flag in allen 4 CPUs an


    - cat /etc/modprobe.d/qemu-system-x86.conf
    options kvm-intel nested=y


    Es scheint das gleiche Problem wie in diesem Thread zu sein: KVM auf KVM (Nested Virtualization)


    Jemand ne Idee? :rolleyes:

    phillu
    So wie du hier das Problem beschreibst, tippe ich mal darauf, dass deine Netzwerkkonfiguration so fehlerhaft ist, dass selbst der davor geschaltete Switch oder Router dir deine IP-Adresse deines Root-Servers RS2000 vorübergehend, solange dieser Fehler vorliegt, sperrt bzw. deaktiviert. Aufgrund der so gesperrten bzw. deaktivierten IP-Adresse ist es selbst nicht mehr möglich, den Server über VNC zu erreichen, da eventuell der VNC-Zugang aus Kostengründen auch über diese IP-Adresse realisiert wird.


    Vorschlag:
    Deaktiviere mal zur Eingrenzung des Fehlerbilds die virtuelle Netzwerkkarte deiner VM und starte sie erneut.

    Zitat von AndreasDe

    phillu
    So wie du hier das Problem beschreibst, tippe ich mal darauf, dass deine Netzwerkkonfiguration so fehlerhaft ist, dass selbst der davor geschaltete Switch oder Router dir deine IP-Adresse deines Root-Servers RS2000 vorübergehend, solange dieser Fehler vorliegt, sperrt bzw. deaktiviert. Aufgrund der so gesperrten bzw. deaktivierten IP-Adresse ist es selbst nicht mehr möglich, den Server über VNC zu erreichen, da eventuell der VNC-Zugang aus Kostengründen auch über diese IP-Adresse realisiert wird.


    Vorschlag:
    Deaktiviere mal zur Eingrenzung des Fehlerbilds die virtuelle Netzwerkkarte deiner VM und starte sie erneut.


    Habe die VM jetzt mal so gestartet:

    Code
    sudo kvm -net none -hda disk.img -curses -m 4096


    Das meinst du, oder? Sollte also kein Netzwerkzeug konfiguriert werden. Geändert hat sich leider nichts, Root-Server ist trotzdem nicht mehr erreichbar.


    Mir ist allerdings aufgefallen, dass die Maschine noch für ~10 Sekunden mehr oder weniger normal erreichbar ist. Danach komplett nicht mehr. Das Problem fühlt sich eher nach zu hoher CPU Last an, als ein Netzwerkproblem. Pingen kann ich den Root-Server auch noch.


    Außerdem hab ich gerade gesehen, dass im kern.log auch diese Zeilen auftauchen, sobald ich versuche die VM zu starten:

    Code
    NMI watchdog: BUG: soft lockup - CPU#1 stuck for 23s! [kvm:1902]


    Wenn ich die VM ohne -enable-kvm , also so:

    Code
    sudo qemu-system-x86_64 -net nic -hda disk.img -curses -m 4096


    funktioniert alles einwandfrei. Arsch langsam halt, weil kein KVM...


    Edit: Ich probiers heute Abend oder so, nochmal mit Centos und nem ubuntu 14.04 ... Hab leider keine Ideen wie ich das weiter debuggen könnte.

    phillu
    Wenn du zuhause über einen alten Rechner oder sogar einen dafür vorgesehenen Testrechner verfügst, würde ich an deiner Stelle es erst einmal darauf zum Laufen bringen und dann erst auf einen RS2000 nachbauen.


    Die besten Erfahrungen bezüglich der Stabilität und Zuverlässigkeit habe ich mit CentOS 7 gemacht.


    Ich selber habe mir fürs Testen von VMs auf Basis von CentOS 7 extra einen Testrechner zusammengebaut, in dem ein Intel Celeron CPU J1900 Prozessor und 16 GB RAM verbaut sind.
    Darauf laufen KVM-Server sehr geschmeidig. Auch wenn ich der einzelnen VM mal z.B. 48 virtuelle Kerne gebe, obwohl der Prozessor des Hostystems mit seinem Celeron-Prozessor nur 2 echte Kerne besitzt.


    Nebenbemerkung:
    Auf diesem Testrechner habe ich mal einen Root-Server RS6000 nachgebaut, so dass ich die Kerne und den RAM darauf gnadenlos überbucht hatte. Dennoch lief diese nachgebaute VM extrem geschmeidig darauf. Praktisch bezogen auf die gefühlte Performance kein Unterschied zum echten RS6000 bei Netcup.

    @AndreasDe


    Das Setup ist in exakt dieser Konfiguration auf echter Hardware getestet und lauffähig.


    Mir einen Server ins Wohnzimmer stellen ist nicht so mein Ding. Laut. Ich muss Strom bezahlen. Mein Upload ist nicht halb so geil wie in nem richtigen Rechenzentrum. Ich brauch ne öffentlich routbare IP, kein dyndns Kram. Ich hab kein Platz. Die Hardware die ich brauche ist mir zu teuer in der Anschaffung, vor dem Hintergrund, dass ich sie eventuell nach 6 Monaten nicht mehr brauche. Ich brauche mehrere Nodes um verschiedene Setups zu testen. Zum Server kommt auch noch Netzwerkhardware.


    Exakt aus diesen Gründen habe ich gehofft, dass die VMX Option der "Root"-Server bei netcup mir weiterhilft. So wie es bisher aussieht führt aber kein Weg an echter Hardware vorbei.


    Übrigens: Wenn du keine Last auf dem Hypervisor hast kannst du deiner VM auch 1000 vCPUs geben und sie wird immernoch geschmeidig laufen.

    Zitat von phillu

    Exakt aus diesen Gründen habe ich gehofft, dass die VMX Option der "Root"-Server bei netcup mir weiterhilft.


    Der Nutzer KB19 hat auch einen kleinen RS2000 mit SAS-Platten und dieser Option. Und so wie ich seinen Beitrag mal verstanden habe, hat er auf Basis von KVM unter Debian VMs darauf laufen.


    Hast du auch schon mal dem Support dein Problem mitgeteilt?


    Zitat von phillu

    So wie es bisher aussieht führt aber kein Weg an echter Hardware vorbei.


    Benötigst du unbedingt eine Vollvirtualisierung? Denn auf einem RS6000 habe ich schon seit monaten ohne irgendwelche Probleme OpenVZ 7 mit vier Containern drauf laufen.


    Zitat von phillu

    Mir einen Server ins Wohnzimmer stellen ist nicht so mein Ding. Laut. Ich muss Strom bezahlen. Mein Upload ist nicht halb so geil wie in nem richtigen Rechenzentrum.


    So einen Server habe ich auch nicht Zuhause stehen. Sondern nur einen alten Testrechner, über dem ich Zuhause bequem ohne Bandbreitenprobleme meine gewünschten Konfigurationen schon mal vorab schmerzfrei testen kann.

    @AndreasDe 
    Danke auf jeden Fall für deine Hilfe!


    Brauche leider Vollvirtualisierung. Habe vor eine kleine OpenStack Cloud aufzubauen und schaue gerade was die günstigste Option dafür ist. Perspektivisch würde ich dann auch mehrere Root-Server und noch VLANs dazukaufen... aber wenn der Testballoon schon nicht fliegt ;)


    Ich schreibe KB19 mal per PN. Mal schauen was er sagt.
    Dem Support habe ich schon geschrieben. Hat bisher nur mit "an unserem Hypervisor liegts nich" geantwortet. Aber auch erst heute morgen, also habe ich da noch ein wenig Geduld :)



    Habs gerade nochmal mit Centos 7 getestet. Gleiches Phänomen :( Ich hoffe ja es ist nur eine kleine KVM Option die ich noch setzen muss...

    Ja, ich nutze die VMX-Option auf einem RS2000+ bei netcup. Aber wie man meinen Beiträgen immer wieder entnehmen kann, läuft das auch nicht ganz sorgenfrei. Ob das jetzt reine Softwareprobleme in meinem Wirkungsbereich sind oder nicht, weiß ich leider noch immer nicht.


    Woran es liegt, dass es bei einigen Forennutzern gar nicht klappt, weiß ich leider auch nicht. Ich verfolge die Threads immer gespannt und halte mich bisher meistens dabei raus, weil mir keine Lösung einfällt, die nicht schon genannt wurde.


    Mein Setup läuft übrigens auf Basis von Debian 8 mit libvirt/KVM, aber mittlerweile mit einem Kernel aus Backports.



    MfG Christian

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

    Interessant. Ich probiers dann nochmal mit Debian 8 :D


    Vielleicht kann ja mal ein gewiefter netcup Admin mit uns auf Debug/Diagnose-Tour gehen?!


    Die VMX Option ist für mich das Killer-Feature von netcup! Wenn ich den Kram hier zum Laufen bekomme ist das definitiv nicht mein letzter Server den ich hier kaufe. :thumbup:

    Zitat von phillu

    Brauche leider Vollvirtualisierung. Habe vor eine kleine OpenStack Cloud aufzubauen und schaue gerade was die günstigste Option dafür ist. Perspektivisch würde ich dann auch mehrere Root-Server und noch VLANs dazukaufen... aber wenn der Testballoon schon nicht fliegt ;)


    Das liest sich ja so, als hast du doch schon etwas größeres vor.


    Was hast du denn vor, für diese Konfiguration im Monat auszugeben? Eventuell kannst du dir davon auch schon locker zwei große dedizierte Server bei einem Fremdanbieter anmieten.


    Wenn du solche Konfiguration gewerblich nutzen möchtest, wäre es eventuell wohl besser, wenn du es mit dedizierten Servern lösen würdest.

    Ok, dann doch noch mehr von mir... (oder halt soviel, wie ich meinem internen Wiki am Handy entlocken kann)


    Hätte ich die Kiste, würde ich mal ein frisches Debian Jessie drauf spielen, alle Pakete rund um libvirt/kvm/qemu installieren, eine Installations-CD als ISO irgendwo abspeichern und einmal folgende Befehle absetzen:



    Falls das Ding dann nicht einfriert, SSH-Tunnel für den oben eingetragenen VNC-Port öffnen und mittels VNC-Client am eigenen PC schauen, ob der Gast die CD gebootet hat.



    MfG Christian

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

    Zitat von phillu

    Interessant. Ich probiers dann nochmal mit Debian 8 :D


    Falls es auf deinem Server noch nicht funktionieren sollte, so könnte eventuell dir der Befehl virt-host-validate (muß mit Root-Rechten ausgeführt werden) weiterhelfen. Und wenn die Ausgabe in etwa wie folgt aussieht, so ist die Nested-Option für deinem Server noch nicht komplett freigeschaltet.


    Hallo zusammen,


    bei mir hat sich auch noch nichts weiter verändert, dank diesem Thread probiere ich es aber auch nochmal mit euren Tipps.
    Habe mich von netcup auch schon auf eine andere Node verlegen lassen, hat aber nichts geändert.


    Wenn hier wer von euch Erfolge verbucht, bitte immer posten - genauso werde ich das auch handhaben.



    Grüße

    Also es bleibt bisher immernoch der selbe Fehler:



    Code
    Message from syslogd@virt1 at May  4 12:20:21 ... kernel:[ 9900.084005] BUG: soft lockup - CPU#3 stuck for 23s! [kworker/3:1:167]
Message from syslogd@virt1 at May  4 12:20:21 ... kernel:[ 9900.112002] BUG: soft lockup - CPU#5 stuck for 23s! [qemu-system-x86:922]
Message from syslogd@virt1 at May  4 12:20:49 ... kernel:[ 9928.084004] BUG: soft lockup - CPU#3 stuck for 23s! [kworker/3:1:167]
Message from syslogd@virt1 at May  4 12:20:49 ... kernel:[ 9928.112004] BUG: soft lockup - CPU#5 stuck for 23s! [qemu-system-x86:922]

    Was gibt das von Andreas vorgeschlagene virt-host-validate aus?



    MfG Christian

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

    ->


    root@virt1:~# virt-host-validate
    QEMU: Checking for hardware virtualization : PASS
    QEMU: Checking for device /dev/kvm : PASS
    QEMU: Checking for device /dev/vhost-net : PASS
    QEMU: Checking for device /dev/net/tun : PASS
    LXC: Checking for Linux >= 2.6.26 : PASS
    root@virt1:~#

    Sorry, dass ich mich jetzt erst melde. Viel zu tun, wenig Zeit zum basteln :(


    Zitat von AndreasDe


    Das liest sich ja so, als hast du doch schon etwas größeres vor.


    Was hast du denn vor, für diese Konfiguration im Monat auszugeben? Eventuell kannst du dir davon auch schon locker zwei große dedizierte Server bei einem Fremdanbieter anmieten.


    Wenn du solche Konfiguration gewerblich nutzen möchtest, wäre es eventuell wohl besser, wenn du es mit dedizierten Servern lösen würdest.


    Habe ~150€/Monat für meine Konfiguration eingeplant. Allerdings ist meine geplante Konfiguration noch ein bisschen komplexer. Mit dedizierten Servern teuer/schwierig umzusetzen, weil ich gerne mindestens 3 Netze pro Server hätte.
    Mit netcup wäre das definitiv möglich und bezahlbar, wenn denn die nested VM Sache funktionieren würde.


    Gewerblich nutze ich es nur indirekt. Aber wenn Netcup hier gute Arbeit abliefert, kann daraus definitiv mehr werden.



    Friert damit leider auch ein. Gleiches Verhalten wie mit direktem kvm/qemu Aufruf


    Zitat von AndreasDe


    Falls es auf deinem Server noch nicht funktionieren sollte, so könnte eventuell dir der Befehl virt-host-validate (muß mit Root-Rechten ausgeführt werden) weiterhelfen. Und wenn die Ausgabe in etwa wie folgt aussieht, so ist die Nested-Option für deinem Server noch nicht komplett freigeschaltet.



    Hier die Ausgabe:



    Voll geiles Denglish.
    Sieht also gut aus. Brauche ich IOMMU support?

    phillu und WassdSchoBassdScho:
    Die virt-host-validate Ausgabe ohne IOMMU-Support sieht gut aus, da der IOMMU-Support nicht benötigt wird.


    Habt ihr es schon mal mit Hilfe des Tools virt-manager versucht, eine VM zu erstellen und über dieses Tool zu starten?


    Eventuell hilft euch auch folgender Erfahrungsbericht weiter:
    Gestern Abend, nachdem ich eure virt-host-validate Ausgaben hier gesehen habe, habe ich auch mal interessehalber von einem dedizierten Server eine schon vorhandene vollvirtualisierte VM plus dessen Konfigurationsdatei auf einem Root-Server mit durchgereichtem VMX Flag kopiert und darin erfolgreich gestartet.


    Die Installation des Betriebssystems CentOS 7 mit der Kernelversion 3.X auf dem Root-Server und der Kopiervorgang der vollvirtualisierten VM plus dessen Konfigurationsdatei vom dedizierten auf dem Root-Server war in ca. 20 Minuten abgeschlossen, da schon während des Installationsprozesses über dessen Installers die benötigten Pakete zur Vollvirtualisierung ausgewählt werden konnten.


    Der Installationsprozesses auf diesem Root-Server verlief genauso, wie auf einem dedizierten Server.


    Die VM auf dem Root-Server wurde gestern Abend mit dem Befehl virtsh gestartet, dessen Syntax virtsh start vm-name ist. Seitdem läuft diese VM darin ohne Probleme und zudem auch noch extrem performant und ressourcenschonend.


    Sobald man den Befehl virsh start ... in einer Shell als root absetzt, werden auch bei fehlerhafter Konfiguration detailliert Fehler angezeigt.