Hilfe!!! Vms starten immer mal wieder nicht, oder sehr langsam

[Thomas Stofer]

Hallo zusammen,

ich hab da ein Problem, bei dem ich es langsam aber sicher an die Nerven ....
Ich betreibe seit einiger Zeit zwei Proxmox Nodes, nicht im Cluster. Ich habe ausgibig getestet bevor ich produktive Server darauf installiert habe.
Jetzt sind die drauf und mir fliegt ständig was um die Ohren.
Auf den Maschinen laufen Terminalserver Domänencontroller und ein Exchange. Im Moment alle wirklich gentutzen auf dem ersten Server.
Der hat ordentlich rums und eingentlich wäre alles gut. Aber immer wieder starten die Maschinen sehr langsam, also wirklich langsam. Bis der Exchange hochgefahren war, waren teilweise mehrere Stunden (!) rum. Ein oder zwei mal musste ich mir schon mit Backup helfen. Die Smartwerte der Platten waren OK, aber weil mir nichts anderes eingefallen war und die nach vier jahren auch nicht mehr die jüngsten waren, hab ich sie getauscht. Auf beiden Servern, obwohl das Problem da nur auf dem ersten Server auftrat.
Dazu habe ich via backup und restore die Maschinen alle auf den zweiten gepackt. Heute habe ich sie wieder zurückgelesen und gestartet. Sie laufen auch. ABER:
Ich habe dann auf dem zweiten den Exchange noch mal hochfahren wollen, weil ich den Geschwindigikeitsunterschied zu den ssd auf dem ersten Server noch mal sehen wollte.
Aber der rödelt jetzt seit 1,5Std rum. CPU bei ca. 75%, ram bei 3GB auslastung und kommt nicht über den Bildschirm mit dem Balken hinaus....

Kann mir jemand beim Trubelshoting helfen?
Auf dem gleichen Pool liegt ein Terminalserver, der ist jetzt in ca. 5min gestartet. Das ging aber Gestern auch noch schneller....

Danke im Voraus!
Thomas

 

[loomes]

Ich habe ähnliches mit einer Windows 7 Maschine bei mir beobachtet.
Enorme CPU Load aber es tut sich nix. Die Farbige Ladeanimation von Win7 bewegt sich dann auch nicht (VNC Konsole).
Nach 20 min oder so kam dann der Anmelde Bildschirm und alles lief normal. Auch ein direkter Reboot verlief dann völlig normal.
Auch abschalten und neu anschalten, alles normal.
Ist die Maschine aber ein paar Tage aus passiert es in der Regel beim ersten booten wieder.

 

[Thomas Stofer]

Hm,
das ist bei mir anders. Die Maschine war nur aus um ein Offlinebackup zu machen. Also vielleicht ne std...

 

[Deleted member 34654]

Hi, für kostenlos Support könnt ihr mich heute Abend ab 20:30 anrufen oder per WhatsApp anschreiben. Könnt ihr Uns trotzdem mal die Konfiguration der Server hier schicken.

 

[Thomas Stofer]

Hi Markus,

kann ich machen, aber ich weiß nicht genau was Du mit Konfiguration herschicken genau meinst. Heute Morgen habe ich aus dem Pool die Compression herausgenommen. Jetzt startet sie wieder schnell, was ja aaber auch keinen Sinn macht, weil komprimierte Datein ja immer noch komprimiert wären, oder?

Hier die config der VM:
agent: 1
balloon: 0
boot: c
bootdisk: scsi0
cores: 2
cpu: host
ide2: none,media=cdrom
keyboard: de
memory: 16000
name: IFSBEX01
net0: e1000=22:FB:88:BF:A3:41,bridge=vmbr0,link_down=1
numa: 1
ostype: win7
scsi0: speicher:vm-10100-disk-1,size=200G
scsihw: virtio-scsi-pci
smbios1: uuid=ad8ee38e-4b9e-46a9-a1ec-cefae37491e1
sockets: 4

root@pve02:/etc/pve/nodes/pve02/qemu-server# pveversion -v
proxmox-ve: 5.2-2 (running kernel: 4.15.18-2-pve)
pve-manager: 5.2-7 (running version: 5.2-7/8d88e66a)
pve-kernel-4.15: 5.2-5
pve-kernel-4.15.18-2-pve: 4.15.18-20
pve-kernel-4.15.17-1-pve: 4.15.17-9
corosync: 2.4.2-pve5
criu: 2.11.1-1~bpo90
glusterfs-client: 3.8.8-1
ksm-control-daemon: 1.2-2
libjs-extjs: 6.0.1-2
libpve-access-control: 5.0-8
libpve-apiclient-perl: 2.0-5
libpve-common-perl: 5.0-38
libpve-guest-common-perl: 2.0-17
libpve-http-server-perl: 2.0-10
libpve-storage-perl: 5.0-24
libqb0: 1.0.1-1
lvm2: 2.02.168-pve6
lxc-pve: 3.0.2+pve1-1
lxcfs: 3.0.0-1
novnc-pve: 1.0.0-2
proxmox-widget-toolkit: 1.0-19
pve-cluster: 5.0-29
pve-container: 2.0-25
pve-docs: 5.2-8
pve-firewall: 3.0-13
pve-firmware: 2.0-5
pve-ha-manager: 2.0-5
pve-i18n: 1.0-6
pve-libspice-server1: 0.12.8-3
pve-qemu-kvm: 2.11.2-1
pve-xtermjs: 1.0-5
pve-zsync: 1.6-16
qemu-server: 5.0-32
smartmontools: 6.5+svn4324-1
spiceterm: 3.0-5
vncterm: 1.5-3
zfsutils-linux: 0.7.9-pve1~bpo9
root@pve02:/etc/pve/nodes/pve02/qemu-server#

Was könnte noch an Infos helfen?

LG
Thomas

 

[fireon]

1,5 Stunden, na da stimmt ja was gewaltig nicht. Wir haben dutzende Exchange auf PVE am laufen. Die benötigen maximal 5 Minuten zum Starten. Beschreibe bitte mal genauestens deine PHY Hardware. Vorallem den Teil mit den HDDs. Wieviele Controller. Was mit ein Storagesystem. Wo und wie sind die Festplatten angeschlossen. Hast du verschiedene Typen an Platten vermischt? usw.

Was passiert wenn du die gleiche VM auf der gleichen Maschine auf eine einzelne SSD mit Ext4 formatiert drauf spielst?

 

[Thomas Stofer]

Hi Fireon,

also zuerst madie Physische Hardware:
Ich habe zwei ProLiant DL380e Gen8
Dort sind jeweils 2x 1TB Festplatten, sas Seagate, auf denen läuft im Mirror der Proxmox.
Dann jeweils 6x Seagate 4,5 TB die 3x2 Mirror beherbergen. Das ganze System hat jeweils 196GB Ram.
Es ist ein
H220 Host Bus Adapter (6G SAS /
6G SATA)

Cotroller verbaut, der die Platten einzeln durchreicht:


Der erste Server hat darüber hinaus 2x INTEL SSD (Server) auf PCIE eingebaut. Der zweite nicht.
Die Pools:

config:

        NAME                              STATE     READ WRITE CKSUM
        rpool                             ONLINE       0     0     0
          mirror-0                        ONLINE       0     0     0
            wwn-0x5000c500a6a63c6b-part2  ONLINE       0     0     0
            wwn-0x5000c500a6a5bb77-part2  ONLINE       0     0     0

errors: No known data errors

  pool: speicher
 state: ONLINE
  scan: none requested
config:

        NAME                        STATE     READ WRITE CKSUM
        speicher                    ONLINE       0     0     0
          mirror-0                  ONLINE       0     0     0
            wwn-0x5000c500a6b51a73  ONLINE       0     0     0
            wwn-0x5000c500a6b5214f  ONLINE       0     0     0
          mirror-1                  ONLINE       0     0     0
            wwn-0x5000c500a6b51727  ONLINE       0     0     0
            wwn-0x5000c500a6b4894f  ONLINE       0     0     0
          mirror-2                  ONLINE       0     0     0
            wwn-0x5000c500a6b5113f  ONLINE       0     0     0
            wwn-0x5000c500a6b51b53  ONLINE       0     0     0

errors: No known data errors

  pool: ssdspeicher
 state: ONLINE
  scan: scrub repaired 0B in 0h25m with 0 errors on Sun Sep  9 00:49:44 2018
config:

        NAME                                                                                                   STATE     READ WRITE CKSUM
        ssdspeicher                                                                                            ONLINE       0     0     0
          nvme-nvme.8086-4356504637333236303035443150324a474e-494e54454c205353445045444d583031325437-00000001  ONLINE       0     0     0
          nvme-nvme.8086-4356504637333836303050343150324a474e-494e54454c205353445045444d583031325437-00000001  ONLINE       0     0     0

errors: No known data errors

Nun zu Deinen Vorschlägen:
Nach dem ich heute Morgen bei der betroffenen Maschine ( habe ich wegen Plattentausch auf dem ersten Server vorher via backup and restore auf den ersten Server kopiert, wollte wissen ob sie noch gut läuft) die Komprimierung raushab, ist die VM in unter einer min. hochgefahren. Das war auch die nächsten reboots so (allerdings ohne Netzwerk, damit sie nicht mit dem Produktiven Server läuft.
Das Problem ist wie gesagt schon vorher auf dem ersten Server aufgetaucht. Nach langer ergebnissloser suche habe ich dann die Notbremse gezogen, die VMs auf den zweiten Server umgezogen. Da war der Spuck vorbei. Ich dachte, dann waren es die Platten.... Nun habe ich auch auf dem ersten Server die Platten getauscht und die Maschinen zurückgespielt. Dann hab ich die getestet die ja noch auf dem zweiten Server rumlag, und die hat dann über 1,5 Std gebraucht, das habe ich zwei mal getestet. Nach der Zeit hab ich abgebrochen. Nun hab ich heute Morgen die Kompession auf dem zfs pool deaktiviert und sie läuft wieder schnell...

Nun kann ich es im Moment nicht reproduzieren. Auch mit wieder aktivierter kompression ist alles gut.

Mehr fällt mir nicht dazu ein...

LG
Thomas

 

[Da-Tex]

Wir hatten ein ähnliches Problem.
Der SWAP hat, vorallen bei Windoof-VMs, für einen extrem lang dauernden Start gesorgt.
swapoff /dev/zvol/rpool/swap
hat das Ganze behoben.

Muss gestehen, dass ich den Thread nur überflogen habe.

 

[Thomas Stofer]

Hallo Da-Tex,

Danke für die Antwort!
Zwei Fragen dazu:
Wie lange dauerten dann Eure Starts?
Dieses swapoff hast Du so in die Konsole getippt, oder ist das über die Eigenschaften des Pools einstellbar?
Eine dritte:
Um was für einen Swap handelt es sich dabei? Ist das der Swap der in der Übersicht des pve auftaucht:


LG
Thomas

 

[Da-Tex]

Extrem unterschiedlich.
Das Höchste waren 45 Minuten(!).

Den Befehl gebe ich auf der Konsole des Nodes ein. Wir haben 3 Stück davon und nach einem Neustart, muss ich es erneut eingeben.
Kann man bestimmt auch automatisieren, aber ich teste den Start der VMs immer nach einem Proxmox-Update und allzu oft, sollte man ein Node nicht neu starten müssen, von daher ist der Workflow für mich so okay.

Jap, genau dieser SWAP, also der Proxmox eigene SWAP. Ist, natürlich, etwas gefährlich, Sollte der RAM mal wirklich ausgelastet sein, dann hat man durchaus ein Problem, des wegen, RAM im Auge behalten!

Liebe Grüße,
Florian

EDIT:
Das ist auch etwas, was ich nicht verstehe. Wieso ist die SWAP-Nutzung so "hoch", obwohl der RAM kaum ausgelastet ist. Ist der SWAP nicht erst in Verwendung, wenn der RAM einen bestimmten Wert überschreitet, um ein voll laufen zu verhindern?
Den Wert kann man ja anpassen und wir haben ihn auf 95% gesetzt. Aber schon bei 60% RAM Auslastung, beginnt Proxmox zuswapen.

 

[fireon]

Das ist auch etwas, was ich nicht verstehe. Wieso ist die SWAP-Nutzung so "hoch", obwohl der RAM kaum ausgelastet ist. Ist der SWAP nicht erst in Verwendung, wenn der RAM einen bestimmten Wert überschreitet, um ein voll laufen zu verhindern?

Nein, geswappt werden Dinge die nicht gebraucht werden. Das ganze Verhältniss nennt sich swappiness und kann man... konnte man einstellen. Leider ist im aktuellen Ubuntukernel ein Bug (wurde hier im Forum schon einige male Diskutiert) das diese Einstellung leider nicht mehr wirkt. Für ZFS wird laut Wiki eine swappiness von 10 empfohlen. Default ist bei Linuxsystemen 60. Das heist der Kernel dentiert mehr zum Swappen. Ist/kann bei ZFS negative Auswirkungen haben. Also entweder Swap abschalten. Komplett deaktivieren einfach in der fstab den Eintrag auskommentieren. Und stattdessen wenn notwendig zram verwenden.

Trotzdem glaub ich nicht das der Swap diese langsamen Starts verursacht. Aber... am besten mal ausprobieren.

 

[Thomas Stofer]

Hallo,
Danke für die Antworten. Ich bin in der letzten Zeit nicht wirklich zum Testen gekommen. Und wenn war der Fehler nicht reproduzierbar.
Heute ist er aber wieder aufgetreten, sehr massiv. Ich habe dann mal ein swapoff /dev/zvol/rpool/swap abgesetzt. Seit dem ist der Spuck vorbei und auch die anderen Maschinen starten deutlich schneller.
Ich werde das aber noch ausgibiger testen und den Tread hier dann auf gelöst setzen!

Noch mal vielen Dank!!!!


LG
Thomas

 

[Da-Tex]

Intreressant!
Bitte melde dich unbedingt, wenn du etwas herausfindest!

Liebe Grüße,
Florian

 

[Thomas Stofer]

Hallo zusammen,

ich hatte leider keine zeit mich früher zu melden!
Aber jetzt mach ich das:
Ich habe das jetzt mit dem deaktivierten swap so gelassen und bis zum heutigen Tag war kein Problem mehr fest zu stellen. Alle Maschinen starten sehr schnell und auch andere Fehler habe ich nicht mehr feststellen können. Interessant finde ich, das die Belegung des Ramspeichers auf dem Host seither deutlich weniger geworden ist. Was ja eigentlich unlogisch ist.
Ich habe mittlerweile noch einen Thomas Krenn Server lauffen, da tritt das Problem auch bei aktiviertem Swap nicht auf. Ebenso auf meinen beiden Bastelkisten...

So weit dazu!

Gute Nacht!