Posts by WassdSchoBassdScho

    Hier noch die XML der VM:

    Ich versuche nur eine zu starten.
    Die VM hat testweise:

    1 CPU

    1024MB RAM


    Dazu wird ein virtuelles CD Laufwerk gemounted, welches auf die debian-netinst.iso (liegt auf dem Server) zugreift.


    Es wird auf dem Server (Host) ein qcow2 Image mit einer Größe von 20 GB angelegt.

    (das ganze natürlich 12x - aber ich darf nur 10.000 Zeichen posten)


    Ich sehe auch das VMX aktiv ist, aber trotzdem ist das Ergebnis (egal welche Distribution, egal welcher Kernel etc) immer das selbe gewesen.

    Ich kann mir nicht vorstellen, dass /dev/shm das Problem war.

    Denn diese Werte passen ja nun.


    Was mir eben auffällt, ist das wenn ich eine VM starte der qemu-Prozess sofort 100% CPU frisst.
    Im SCP (Statistik) ist dann eine CPU ebenfalls komplett auf 100% Auslastung.


    Und damit bekomme ich wieder die "CPU stuck" Meldungen und der Server friert ein.


    Gruß

    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..

    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"....

    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 ~]#

    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

    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.

    ->


    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:~#