VMs werden einfach immer wieder gekillt, aber es gibt genug ram

[virtualizedapp]

Hallo,

ich stoße seit einiger zeit auf merkwürdige probleme, habe mich schon mit oomk usw auseinandergesetzt, schließe das aber eigentlich mittlerweile aus.

Erstmal das Problem:

Ich habe so 1-2 VMs die wenn man sie startet regelmäßig einfach gekillt werden nach einer zeit (sieht man auch gut an den graphen, es waren keine shutdowns oder stops!)





in den stats der 2 vms sieht man das auf die woche gesehen nicht gut, da die vms nicht länger wie eine halbe stunden anbleiben und dann gekillt werden, es ist aber mittlerweile schon sehr oft aufgefallen, 10 mal oder mehr.

ich habe versucht nach oom logs zu suchen, mit einem einfachen `journalctl -x | grep *oom*`, dabei ist nichts rumgekommen. kein output, also kein match.
nebenbei versuche ich es wieder zu reproduzieren.

Ich möchte anmerken das ich kein problem mit RAM-Überbuchung usw habe, wie man sieht habe ich sehr viel ram frei, außerdem wird kein ZFS benutzt. ich benutze nur LVM-Thin für die VMs.



Das problem tritt erst nach migrationen auf, ich habe die vms vor ca. 2 wochen von einem node mit gleicher hardware auf diesen migriert, und davor hatte ich das gleiche spiel auch mal umgekehrt gemacht, da ich 2 von diesen servern 1 zu 1 habe und wartungen gemacht hatte. Das problem ist danach immer aufgetreten, egal auf welchem host die vms am ende waren. Anzumerken ist das nur Windows VMs bis jetzt das problem hatten (es sind wirklich nur diese, alle anderen haben bis jetzt keine probleme) und das ich kein Memory Balloning benutze, weil ich genug ram frei haben sollte (kein ZFS, sehr viel ram frei usw.). Das aktivieren von Memory Balloning hat nicht geholfen bei den betroffenen VMs. Dennoch denke ich nicht das es ein Windows Problem ist, der unterschied ist das Windows 100% des RAMs in jedem fall beanspruchen möchte, und linux das nur nach einer Zeit tut, und hier hatte ich glaube ich auch 1 mal einen Crash einer Debian VM, wo die RAM load der VM fast auf anschlag war.




falls einer weiß, was ich jetzt am besten zum lösen des problems machen soll, gerne her damit. gerne schaue ich mir weiter protokolle an.

Danke im vorraus!

 

[virtualizedapp]

Logs gefunden, sagt mir leider nicht viel :/

May 29 17:09:33 pve1 kernel: tap1092i0: left allmulticast mode
May 29 17:09:33 pve1 kernel: vmbr0: port 19(tap1092i0) entered disabled state
May 29 17:09:33 pve1 qmeventd[1315]: read: Connection reset by peer
May 29 17:09:34 pve1 systemd[1]: 1092.scope: Deactivated successfully.
░░ Subject: Unit succeeded
░░ Defined-By: systemd
░░ Support: https://www.debian.org/support
░░
░░ The unit 1092.scope has successfully entered the 'dead' state.
May 29 17:09:34 pve1 systemd[1]: 1092.scope: Consumed 12min 47.228s CPU time.
░░ Subject: Resources consumed by unit runtime
░░ Defined-By: systemd
░░ Support: https://www.debian.org/support
░░
░░ The unit 1092.scope completed and consumed the indicated resources.
May 29 17:09:34 pve1 kernel: tap1112i0: left allmulticast mode
May 29 17:09:34 pve1 kernel: vmbr0: port 16(tap1112i0) entered disabled state
May 29 17:09:34 pve1 qmeventd[1315]: read: Connection reset by peer
May 29 17:09:35 pve1 systemd[1]: 1112.scope: Deactivated successfully.
░░ Subject: Unit succeeded
░░ Defined-By: systemd
░░ Support: https://www.debian.org/support
░░
░░ The unit 1112.scope has successfully entered the 'dead' state.
May 29 17:09:35 pve1 systemd[1]: 1112.scope: Consumed 7min 43.250s CPU time.
░░ Subject: Resources consumed by unit runtime
░░ Defined-By: systemd
░░ Support: https://www.debian.org/support
░░
░░ The unit 1112.scope completed and consumed the indicated resources.
May 29 17:09:35 pve1 qmeventd[161278]: Starting cleanup for 1092
May 29 17:09:35 pve1 qmeventd[161278]: Finished cleanup for 1092
May 29 17:09:36 pve1 qmeventd[161314]: Starting cleanup for 1112
May 29 17:09:36 pve1 qmeventd[161314]: Finished cleanup for 1112

``

 

[devaux]

Sagt denn das Windows-Log irgendwas vor dem Absturz? Ich nehme an aktuellste Guest-Tools hast installiert und in den Options der VM aktiviert?
Bei Windows-VMs hatte ich schon ein paarmal (zwar in VMWare), dass sich Windows vor einem Backup gekillt hat, wenn darin starker IO war (z.B. Windows VSS oder Snapshot-Anforderungen) von den Guest-Tools.

ps. fuer Windows-VMs wird inzwischen "Virtio SCSI Single" fuer den Controller und "SCSI" (nicht virtio) als Festplatten empfohlen. Denke aber nicht, dass hier das Problem liegt.

 

[Dunuin]

Sagt denn das Windows-Log irgendwas vor dem Absturz? Ich nehme an aktuellste Guest-Tools hast installiert und in den Options der VM aktiviert?
Bei Windows-VMs hatte ich schon ein paarmal (zwar in VMWare), dass sich Windows vor einem Backup gekillt hat, wenn darin starker IO war (z.B. Windows VSS oder Snapshot-Anforderungen) von den Guest-Tools.

ps. fuer Windows-VMs wird inzwischen "Virtio SCSI Single" fuer den Controller und "SCSI" (nicht virtio) als Festplatten empfohlen. Denke aber nicht, dass hier das Problem liegt.

Laut Screenshots ist kein QEMU Guest Agent installiert (oder wenigstens nicht eingestellt, dass die VM den nutzen soll).

 

[cwt]

Wie sieht denn der SSD/HDD/NVME-Unterbau aus?

 

[virtualizedapp]

Sagt denn das Windows-Log irgendwas vor dem Absturz? Ich nehme an aktuellste Guest-Tools hast installiert und in den Options der VM aktiviert?
Bei Windows-VMs hatte ich schon ein paarmal (zwar in VMWare), dass sich Windows vor einem Backup gekillt hat, wenn darin starker IO war (z.B. Windows VSS oder Snapshot-Anforderungen) von den Guest-Tools.

ps. fuer Windows-VMs wird inzwischen "Virtio SCSI Single" fuer den Controller und "SCSI" (nicht virtio) als Festplatten empfohlen. Denke aber nicht, dass hier das Problem liegt.

Hallo,

Die Guest-Tools habe ich per se für alle vms aus, wird nicht gebraucht und ist auch i.d.r nur schnick schnack, eine vm kann auch ohne sowas laufen.

Die VMs die betroffen sind liefen vor der migration für wochen/monate ohne probleme, das ist anzumerken. Die Konfiguration hat sich nicht geändert.

Was Windows-Logs betrifft muss ich später mal nachschauen, aber ich denke das das hier keine relevanz hat (ich habe auch keinen direkten zugriff auf die vms), da der qemu prozess durch sowas einfach nicht stirbt wenn das os da drinn crasht.

 

[virtualizedapp]

Hallo,

Wie sieht denn der SSD/HDD/NVME-Unterbau aus?

Hier mal ein LSBLK:

root@pve1:~# lsblk | grep -v 'lvm'
NAME                                                             MAJ:MIN RM  SIZE RO TYPE  MOUNTPOINTS
sda                                                                8:0    0 14.6T  0 disk
├─sda1                                                             8:1    0 1007K  0 part
├─sda2                                                             8:2    0    1G  0 part
├─sda3                                                             8:3    0  255G  0 part
└─sda4                                                             8:4    0 14.3T  0 part
zram0                                                            251:0    0  1.5T  0 disk  [SWAP]
nvme0n1                                                          259:0    0  1.9T  0 disk
└─md0                                                              9:0    0  1.9T  0 raid1
nvme1n1                                                          259:1    0  1.9T  0 disk
└─md0                                                              9:0    0  1.9T  0 raid1

/dev/sda ist die os disk und ist ein HW-RAID6, wo die sda4 das lvm trägt und der rest zum OS gehört. das os selbst ist ein ext4-lvm konstrukt welches proxmox selbst bei der installation anlegt.

/dev/md0 ist ein raid1 über die beiden nvmes, welches auch nur ein lvm thin trägt.



ich hoffe das hilft so.

 

[Dunuin]

Die Guest-Tools habe ich per se für alle vms aus, wird nicht gebraucht und ist auch i.d.r nur schnick schnack, eine vm kann auch ohne sowas laufen.

Ohne diese kann PVE dem GastOS z.B. nicht sagen, dass es ein Fsfreeze machen soll. Du hast dann also keine konsistenten Snapshot-Mode Backups, da der flüchtige (und nicht mitgesicherte) Write-Cache vor dem Backup nicht geleer wird. Verlässliche Backups würde ich jetzt nicht gerade als Schnick Schnack bezeichnen

 

[virtualizedapp]

Ohne diese kann PVE dem GastOS nicht sagen, dass es ein Fsfreeze machen soll. Du hast dann also keine konsistenten Snapshot-Mode Backups, da der Write-Cache vor dem Backup nicht geleer wird. Verlässliche Backups würde ich jetzt nicht gerade als Schnick Schnack bezeichnen

Hallo, okay. bloß ich fahre ich nicht alle 30 minuten ein backup und auch nicht zum zeitpunkt des "vm kills". aber danke für die information aufjedenfall!

 

[Falk R.]

Hallo,

Die Guest-Tools habe ich per se für alle vms aus, wird nicht gebraucht und ist auch i.d.r nur schnick schnack, eine vm kann auch ohne sowas laufen.

Irgendwann wirst du deine Meinung schon noch ändern.

Die VMs die betroffen sind liefen vor der migration für wochen/monate ohne probleme, das ist anzumerken. Die Konfiguration hat sich nicht geändert.

Was Windows-Logs betrifft muss ich später mal nachschauen, aber ich denke das das hier keine relevanz hat (ich habe auch keinen direkten zugriff auf die vms), da der qemu prozess durch sowas einfach nicht stirbt wenn das os da drinn crasht.

Stimmt auch nicht. Ich habe genügend Crashes in VMs gesehen, welche den Host nicht interessieren, aber ich habe auch schon Hypervisoren sterben sehen, wenn eine VM mit ganz komischen Fehlern crasht. Das habe ich auch schon bei ESXi gesehen.

Hallo, okay. bloß ich fahre ich nicht alle 30 minuten ein backup und auch nicht zum zeitpunkt des "vm kills". aber danke für die information aufjedenfall!

Das mit dem Backup war ein Tipp für dich, damit du endlich konsistente Backups hast.

Hast du mal geschaut ob du I/O Delays siehst und wenn ja, gehen die zum Zeitpunkt eines Crash hoch?

 

[virtualizedapp]

Hallo,

Irgendwann wirst du deine Meinung schon noch ändern.

Stimmt auch nicht. Ich habe genügend Crashes in VMs gesehen, welche den Host nicht interessieren, aber ich habe auch schon Hypervisoren sterben sehen, wenn eine VM mit ganz komischen Fehlern crasht. Das habe ich auch schon bei ESXi gesehen.


Das mit dem Backup war ein Tipp für dich, damit du endlich konsistente Backups hast.

Hast du mal geschaut ob du I/O Delays siehst und wenn ja, gehen die zum Zeitpunkt eines Crash hoch?

"Stimmt auch nicht. Ich habe genügend Crashes in VMs gesehen, welche den Host nicht interessieren, aber ich habe auch schon Hypervisoren sterben sehen, wenn eine VM mit ganz komischen Fehlern crasht. Das habe ich auch schon bei ESXi gesehen."

Alles klar. Kann sein, ich werde in die logs schauen, die warscheinlich nicht mehr melden außer unerwarteter crash.

"Das mit dem Backup war ein Tipp für dich, damit du endlich konsistente Backups hast. "

Wenn daten wichtig sind, werden sie nicht in einem schreib-cache behalten, das wäre bei stromausfällen sonst genauso tragisch, daher ist das kein KO argument für mich, zumal ich so wenig einfluss wie möglich auf fremde VMs die ich nicht benutze haben möchte. allerdings kann man sich es mal überlegen die funktion an zu machen und zu schauen ob es so wie von geisterhand wieder funktioniert (was es vorher auch ohne guest-tools gemacht hat.).

"Hast du mal geschaut ob du I/O Delays siehst und wenn ja, gehen die zum Zeitpunkt eines Crash hoch?"

Ich habe immer I/O Delay auch wegen den HDDs und weil es ja irgendwie auch normal ist, i.d.r zwischen 0-0,2%. Einen spike konnte ich nicht verzeichnen mit den VMs beim crash sowie davor.

Danke für die Antwort!

Ich schaue mal nach wegen den guest-tools und logs und teste damit, erhoffe mir aber nichts bei dem thema.