MSSQL VM kann plötzlich nicht mehr auf Disk zugreifen

[devileye]

Hallo zusammen,

wir haben seit geraumer Zeit das Problem, dass eine VM mit Microsoft SQL Server nach ca. 3 - 4 Wochen Betriebszeit plötzlich nicht mehr auf die Disk zugreifen kann. Der genauen Ursache komme ich einfach nicht auf die Spur. Habe Die VM schon auch komplett frisch installiert. Auch neuere Versionen von OS und MSSQL verwendet (Windows Server 2019 statt 2016, SQL Server 2019 statt 2017).

Wenn ich die VM dann stoppe und wieder starten möchte bzw. resette, erscheint die Meldung

TASK ERROR: can't refresh LV '/dev/nvme02/vm-100-disk-0' for activation: received interrupt

Mittlerweile bin ich soweit gekommen, dass sich der Prozess anscheinend nicht "auflöst" bzw. killen kann man ihn auch nicht. Die PID finde ich hier:

root@proxmox:/var/run/qemu-server# more 100.pid
13392

Es wird eben auch die Disk nicht freigegeben, was man im lvs sehen kann:

  vm-100-disk-0 nvme02 -wi-ao----   50.00g

Dass es sich um ein generelles Hardware Problem handelt schließe ich eher aus, da weitere VMs auf den gleichen physischen Disks ohne Probleme (weiter-)laufen.

Die einzige Lösung ist jedes mal den Host zu rebooten, was mit 25 VMs nicht so schön ist...

Hat denn jemand eine Idee woran es liegen könnte?

Vielen Dank!

 

[aaron]

Schon mal geschaut was dmesg liefert? Wenns doch ein HW Problem ist, sollte der Kernel was loggen.

Hast du versucht die LV zu deaktivieren mit lvchange -an nvme02/vm-100-disk-0?

 

[devileye]

Hallo Aaron,

vielen Dank für deine Antwort.

dmesg liefert aktuell nichts womit ich was anfangen könnte. Das einzigste was mich etwas stutzig macht ist das hier:

[ 1347.797084] perf: interrupt took too long (2518 > 2500), lowering kernel.perf_event_max_sample_rate to 79250
[ 2087.977164] perf: interrupt took too long (3186 > 3147), lowering kernel.perf_event_max_sample_rate to 62750
[ 3078.655762] perf: interrupt took too long (3990 > 3982), lowering kernel.perf_event_max_sample_rate to 50000
[ 4812.127051] perf: interrupt took too long (5009 > 4987), lowering kernel.perf_event_max_sample_rate to 39750
[ 7185.105055] perf: interrupt took too long (6265 > 6261), lowering kernel.perf_event_max_sample_rate to 31750

Hat aber wohl mit der CPU zu tun?!

Hier das syslog zum reset:

Jul  2 13:18:28 proxmox pvedaemon[46913]: <root@pam> starting task UPID:proxmox:000007AC:0AA3C24E:60DEF604:qmreset:100:root@pam:
Jul  2 13:18:36 proxmox pvedaemon[1109]: VM 100 qmp command failed - received interrupt
Jul  2 13:18:36 proxmox pvedaemon[1109]: VM quit/powerdown failed
Jul  2 13:18:36 proxmox pvedaemon[44538]: <root@pam> end task UPID:proxmox:00000455:0AA36B17:60DEF525:qmreboot:100:root@pam: VM quit/powerdown failed
Jul  2 13:18:36 proxmox pvedaemon[46913]: <root@pam> end task UPID:proxmox:000007AC:0AA3C24E:60DEF604:qmreset:100:root@pam: OK
Jul  2 13:19:00 proxmox systemd[1]: Starting Proxmox VE replication runner...
Jul  2 13:19:01 proxmox systemd[1]: pvesr.service: Succeeded.
Jul  2 13:19:01 proxmox systemd[1]: Started Proxmox VE replication runner.
Jul  2 13:19:05 proxmox pvedaemon[44538]: <root@pam> end task UPID:proxmox:0000BD6B:0AA2A6B5:60DEF32E:vncproxy:100:root@pam: OK
Jul  2 13:19:06 proxmox pveproxy[48585]: worker exit
Jul  2 13:19:07 proxmox pvedaemon[2171]: starting vnc proxy UPID:proxmox:0000087B:0AA3D14D:60DEF62B:vncproxy:100:root@pam:
Jul  2 13:19:07 proxmox pvedaemon[46913]: <root@pam> starting task UPID:proxmox:0000087B:0AA3D14D:60DEF62B:vncproxy:100:root@pam:
Jul  2 13:19:22 proxmox pvedaemon[46913]: VM 100 qmp command failed - VM 100 qmp command 'guest-ping' failed - got timeout
Jul  2 13:19:34 proxmox pvedaemon[2251]: stop VM 100: UPID:proxmox:000008CB:0AA3DBF8:60DEF646:qmstop:100:root@pam:
Jul  2 13:19:34 proxmox pvedaemon[44538]: <root@pam> starting task UPID:proxmox:000008CB:0AA3DBF8:60DEF646:qmstop:100:root@pam:
Jul  2 13:19:37 proxmox pvedaemon[2251]: VM 100 qmp command failed - VM 100 qmp command 'quit' failed - unable to connect to VM 100 qmp socket - timeout after 31 retries
Jul  2 13:19:37 proxmox pvedaemon[2251]: VM quit/powerdown failed - terminating now with SIGTERM
Jul  2 13:19:41 proxmox pvedaemon[46913]: VM 100 qmp command failed - VM 100 qmp command 'guest-ping' failed - got timeout
Jul  2 13:19:47 proxmox pvedaemon[2251]: VM still running - terminating now with SIGKILL
Jul  2 13:19:53 proxmox pvedaemon[2251]: can't deactivate LV '/dev/nvme02/vm-100-disk-2':   Logical volume nvme02/vm-100-disk-2 in use.

Könnte der SIGKILL hier etwas kaputtmachen?

Die LV zu dekativieren hatte ich versucht:

root@proxmox:~# lvchange -an /dev/nvme02/vm-100-disk-0
 Logical volume nvme02/vm-100-disk-0 in use.

 

[devileye]

Hat niemand eine Idee?

 

[Stoiko Ivanov]

Logical volume nvme02/vm-100-disk-0 in use.

Auf einen Verdacht hin - mal sehen, was das system so über die disk denkt:
* `lsblk`
* `dmesetup ls --tree`
* `lsof -n |grep -E 'nvme02|dm'`
vl. zeigt sich da wie das LV/die vmdisk in Verwendung ist

Ich hoffe das hilft!

 

[devileye]

Hallo Stoiko,
leider halfen mir die Befehle nicht weiter.
Hab im Syslog diese Einträge gefunden:

Jul 12 23:30:55 proxmox kernel: [896532.371855] hptnvme:   0: bus 0x2F3E93E600 size 800 eot 1
Jul 12 23:30:55 proxmox kernel: [896532.371861] hptnvme:   NOW bus 0x2F3E93E600 size 800 eot 1
Jul 12 23:30:55 proxmox kernel: [896532.371865] hptnvme:   sum 600 overall sectors 4 (sz 800)
Jul 12 23:30:55 proxmox kernel: [896532.371868] hptnvme: Split 0: lba 0x649E1FD sectors 3 (sz 203)
Jul 12 23:30:55 proxmox kernel: [896532.371870] hptnvme:      bus 0x2F3E93E600 size 600 eot 1
Jul 12 23:30:55 proxmox kernel: [896532.371873] hptnvme: Split 1: lba 0x649E200 sectors 0 (sz 200)
Jul 12 23:30:55 proxmox kernel: [896532.371875] hptnvme:      bus 0x2F3E93EC00 size 0 eot 0

Es scheint als quittiere der HighPoint SSD7103 Controller / Treiber plötzlich den Dienst.
Verstehe aber nicht warum...

 

[Deleted member 116138]

Hast Du für den HighPoint manuell Treiber hinzugefügt? Ggf. die C-States/ACPI im BIOS überprüft? Ich hatte schon mit diversen NVME-Controllern und ACPI unter PVE 6/7 ähnliche Probleme. Vom Ausstieg der vdisks bis hin zum Freeze des Hosts.