VM Freez nach Migration

[Winet.maier]

Wir haben heute eine Bulk Migration durchgeführt und praktisch alle VM sind hängen geblieben. Über 100% CPU und Guest Agent war weg auf der VM. Ist mir schon mal passiert und wir mussten jede VM von Hand mit Stop runterfahren und dann wieder hochfahren. waren über 120 VM's. Nicht lustig.
Wir haben von 8.2.2 auf 8.2.7 upgedatet und können zwar von 8.2.2 auf 8.2.7 VM's migrieren. Sind aber danach gefreezt. Zurück geht nicht mehr.
3 x Supermicro AMD Epic Rome 64 core und 1 TB Memory mit Ceph Cluster und Jovian Storage. Alles SSD. 40 Gbit Storage Network.

PVE01
6.8.12-2-pve #1 SMP PREEMPT_DYNAMIC PMX 6.8.12-2 (2024-09-05T10:03Z) x86_64 GNU/Linux

PVE02
6.8.4-2-pve #1 SMP PREEMPT_DYNAMIC PMX 6.8.4-2 (2024-04-10T17:36Z) x86_64 GNU/Linux

PVE01
proxmox-ve: 8.2.0 (running kernel: 6.8.4-2-pve)
pve-manager: 8.2.2 (running version: 8.2.2/9355359cd7afbae4)
proxmox-kernel-helper: 8.1.0
proxmox-kernel-6.8: 6.8.4-2
proxmox-kernel-6.8.4-2-pve-signed: 6.8.4-2
proxmox-kernel-6.5.13-5-pve-signed: 6.5.13-5
proxmox-kernel-6.5: 6.5.13-5
ceph: 17.2.7-pve3
ceph-fuse: 17.2.7-pve3
corosync: 3.1.7-pve3
criu: 3.17.1-2
frr-pythontools: 8.5.2-1+pve1
glusterfs-client: 10.3-5
ifupdown: residual config
ifupdown2: 3.2.0-1+pmx8
ksm-control-daemon: 1.5-1
libjs-extjs: 7.0.0-4
libknet1: 1.28-pve1
libproxmox-acme-perl: 1.5.0
libproxmox-backup-qemu0: 1.4.1
libproxmox-rs-perl: 0.3.3
libpve-access-control: 8.1.4
libpve-apiclient-perl: 3.3.2
libpve-cluster-api-perl: 8.0.6
libpve-cluster-perl: 8.0.6
libpve-common-perl: 8.2.1
libpve-guest-common-perl: 5.1.1
libpve-http-server-perl: 5.1.0
libpve-network-perl: 0.9.8
libpve-rs-perl: 0.8.8
libpve-storage-perl: 8.2.1
libqb0: 1.0.5-1
libspice-server1: 0.15.1-1
lvm2: 2.03.16-2
lxc-pve: 6.0.0-1
lxcfs: 6.0.0-pve2
novnc-pve: 1.4.0-3
proxmox-backup-client: 3.2.0-1
proxmox-backup-file-restore: 3.2.0-1
proxmox-kernel-helper: 8.1.0
proxmox-mail-forward: 0.2.3
proxmox-mini-journalreader: 1.4.0
proxmox-offline-mirror-helper: 0.6.6
proxmox-widget-toolkit: 4.2.1
pve-cluster: 8.0.6
pve-container: 5.0.11
pve-docs: 8.2.1
pve-edk2-firmware: 4.2023.08-4
pve-esxi-import-tools: 0.7.0
pve-firewall: 5.0.5
pve-firmware: 3.11-1
pve-ha-manager: 4.0.4
pve-i18n: 3.2.2
pve-qemu-kvm: 8.1.5-5
pve-xtermjs: 5.3.0-3
qemu-server: 8.2.1
smartmontools: 7.3-pve1
spiceterm: 3.3.0
swtpm: 0.8.0+pve1
vncterm: 1.8.0
zfsutils-linux: 2.2.3-pve2

und PVE02
proxmox-ve: 8.2.0 (running kernel: 6.8.12-2-pve)
pve-manager: 8.2.7 (running version: 8.2.7/3e0176e6bb2ade3b)
proxmox-kernel-helper: 8.1.0
proxmox-kernel-6.8: 6.8.12-2
proxmox-kernel-6.8.12-2-pve-signed: 6.8.12-2
proxmox-kernel-6.8.4-2-pve-signed: 6.8.4-2
proxmox-kernel-6.5.13-6-pve-signed: 6.5.13-6
proxmox-kernel-6.5: 6.5.13-6
proxmox-kernel-6.5.13-5-pve-signed: 6.5.13-5
ceph: 17.2.7-pve3
ceph-fuse: 17.2.7-pve3
corosync: 3.1.7-pve3
criu: 3.17.1-2
frr-pythontools: 8.5.2-1+pve1
glusterfs-client: 10.3-5
ifupdown: residual config
ifupdown2: 3.2.0-1+pmx9
ksm-control-daemon: 1.5-1
libjs-extjs: 7.0.0-4
libknet1: 1.28-pve1
libproxmox-acme-perl: 1.5.1
libproxmox-backup-qemu0: 1.4.1
libproxmox-rs-perl: 0.3.4
libpve-access-control: 8.1.4
libpve-apiclient-perl: 3.3.2
libpve-cluster-api-perl: 8.0.7
libpve-cluster-perl: 8.0.7
libpve-common-perl: 8.2.3
libpve-guest-common-perl: 5.1.4
libpve-http-server-perl: 5.1.1
libpve-network-perl: 0.9.8
libpve-rs-perl: 0.8.10
libpve-storage-perl: 8.2.5
libqb0: 1.0.5-1
libspice-server1: 0.15.1-1
lvm2: 2.03.16-2
lxc-pve: 6.0.0-1
lxcfs: 6.0.0-pve2
novnc-pve: 1.4.0-4
proxmox-backup-client: 3.2.7-1
proxmox-backup-file-restore: 3.2.7-1
proxmox-firewall: 0.5.0
proxmox-kernel-helper: 8.1.0
proxmox-mail-forward: 0.2.3
proxmox-mini-journalreader: 1.4.0
proxmox-offline-mirror-helper: 0.6.7
proxmox-widget-toolkit: 4.2.3
pve-cluster: 8.0.7
pve-container: 5.2.0
pve-docs: 8.2.3
pve-edk2-firmware: 4.2023.08-4
pve-esxi-import-tools: 0.7.2
pve-firewall: 5.0.7
pve-firmware: 3.13-2
pve-ha-manager: 4.0.5
pve-i18n: 3.2.3
pve-qemu-kvm: 9.0.2-3
pve-xtermjs: 5.3.0-3
qemu-server: 8.2.4
smartmontools: 7.3-pve1
spiceterm: 3.3.0
swtpm: 0.8.0+pve1
vncterm: 1.8.0
zfsutils-linux: 2.2.6-pve1

 

[Falk R.]

Hi, soewtas habe ich noch nie gesehen. Wie viele VMs hast du parallel migriert? Wie sieht das Netzwerksetup aus, macht ihr etwa die Migration über das Ceph Netzwerk?

 

[Winet.maier]

Hi, soewtas habe ich noch nie gesehen. Wie viele VMs hast du parallel migriert? Wie sieht das Netzwerksetup aus, macht ihr etwa die Migration über das Ceph Netzwerk?

Wir haben drei Netzwerke und bis jetzt war das noch nie ein Problem. Ich konnte Bulkmigration machen mit 10 gleichzeitigen Task - kein Problem. Ich habe aber herausgefunden, dass die VM's mit Centos 7.x kein Problme haben und dies nur die älteren Systeme mit Centos 6.x

Jetzt wird es richtig schräg. Wir haben gerade noch ein wenig getestet. Es gibt VM's mit Centos 6.x und guest Agent Version 0.12 die sich problemlos hin und her migrieren lassen. Dann gibt es identische VM's die vom Host mit Version 8.2.2 auf den Host 8.2.7 crashen. Die lassen sich nur noch mit Stop und danach Start wieder zum Laufen bewegen. VM's die dieses Verhalten aufweisen, lassen sich NICHT mehr zurück auf 8.2.2 migrieren. VM's mit gleicher Version System und Guest Agent die von 8.2.2 auf 8.2.7 migrieren ohne Crash können auch wieder zurück migriert werden auf 8.2.2 Host.
Alle VM's mit Centos 7.x und Guest Agent 2.12 machen keine Probleme. Mein Problem ist, dass das Telefonisystme sind und die Kunden keinen Grund haben auf ein neueres System zu wechseln. Das sind auf drei Host ca. 450 VM's wobei mindestens 280 noch mit Centos 6.x laufen.

 

[Falk R.]

Was hast du für Hosts? Welche CPUs sind verbaut und sind die Bios Einstellungen identisch?
Klingt nach einem Problem mit maskierten CPU Features.

 

[Winet.maier]

Was hast du für Hosts? Welche CPUs sind verbaut und sind die Bios Einstellungen identisch?
Klingt nach einem Problem mit maskierten CPU Features.

Die BIOS Einstellungen für PVE01 und PVE02 sind identisch sowie auch das Blech. PVE03 hat eine neueres Motherboard ist ansonnsten jedoch identisch.
3 x Supermicro AMD Epic Rome 64 core und 1 TB Memory mit Ceph Cluster und Jovian Storage. Alles SSD. 40 Gbit Storage Network.

Interessant ist, dass das früher problemlos ging. Hin und her und rauf und runter. Einige Centos 6.x lassen sich nicht mehr auf die alte (8.2.2) Maschine migrieren. Jedoch haben wir, eigentlich identische VM's bei denen geht es. Diese crashen. auch nicht, wenn ich von PVE01 auf PVE02 migriere. Alle VM's, die auf Centos 6.x basieren sind aus unserem Repo und müssten identisch sein.

 

[Falk R.]

Die BIOS Einstellungen für PVE01 und PVE02 sind identisch sowie auch das Blech. PVE03 hat eine neueres Motherboard ist ansonnsten jedoch identisch.
3 x Supermicro AMD Epic Rome 64 core und 1 TB Memory mit Ceph Cluster und Jovian Storage. Alles SSD. 40 Gbit Storage Network.

Allein ein anderes Board oder auch eine andere BIOS Version kann zu unterschliedlich durchgereichten oder maskierte Features führen. Es wurden ja auch immer wieder CPU features deaktiviert wegen Securityissues.

Interessant ist, dass das früher problemlos ging. Hin und her und rauf und runter. Einige Centos 6.x lassen sich nicht mehr auf die alte (8.2.2) Maschine migrieren. Jedoch haben wir, eigentlich identische VM's bei denen geht es. Diese crashen. auch nicht, wenn ich von PVE01 auf PVE02 migriere. Alle VM's, die auf Centos 6.x basieren sind aus unserem Repo und müssten identisch sein.

Das kann man leider nicht so pauschalisieren. Manchmal nutzen installierte Applikationen andere CPU Features als die Applikation einer anderen VM.
Unter Umständen sind mit dem neueren Kernel noch AMD Features aktiviert worden, welche vorher nicht genutzt wurden.

 

[Winet.maier]

Allein ein anderes Board oder auch eine andere BIOS Version kann zu unterschliedlich durchgereichten oder maskierte Features führen. Es wurden ja auch immer wieder CPU features deaktiviert wegen Securityissues.

Das kann man leider nicht so pauschalisieren. Manchmal nutzen installierte Applikationen andere CPU Features als die Applikation einer anderen VM.
Unter Umständen sind mit dem neueren Kernel noch AMD Features aktiviert worden, welche vorher nicht genutzt wurden.

Das erklärt aber nicht, dass identische VM's ein völlig anderes Verhalten an den Tag legen. Und falls ich das Problem nicht in den Griff bekomme, ist Proxmox für uns ein Schuss in den Ofen.

 

[Falk R.]

Das erklärt aber nicht, dass identische VM's ein völlig anderes Verhalten an den Tag legen. Und falls ich das Problem nicht in den Griff bekomme, ist Proxmox für uns ein Schuss in den Ofen.

Vermutlich hast du mit den identischen VMs und einem anderen Hypervisor genau das gleiche Problem. KVM virtualisiert wie jer andere Hypervisor einfach und reicht Ressourcen durch.
Mit solchen Aussagen kommst du nicht weiter und verschreckst eventuell andere Leute die dir helfen könnten.

Wir nehmen mal an die VMs sind tatsächlich auch Applikationsseitig 100% identisch. Passiert der Crash nur zwischen bestimmten Hosts? Welche Fehlermeldungen stehen denn zum Zeitpunkt des Crashs in den Logs?

 

[Winet.maier]

Mich macht nur stutzig, weshalb das einfach so aus blauem Himmel nicht mehr gehen sollte, was vorher über Monate und Jahre funktioniert hat. Es gibt keine Logeinträge zu den VM's die Migrieren und dann ist der Guest Agent weg und das wars. Wir haben heute sogar zwei VM's verglichen, und die installierten Komponenten verglichen. Praktisch kein Unterschied. Was die Crash der VM's mit den verschiedenen Hosts betrifft, schau Dir bitte die Posts von mir weiter oben an.
Eine Umgebung die von einem Tag auf den anderen plötzlich Probleme macht stört das Tagesgeschäft enorm. Ich habe wirklich andere Dinge zu erledigen, als mich um neue Bugs im System Proxmox zu kümmern. wohl gemerkt in einer bezahlten Version, von der man ausgehen könnte, dass sie das tut was sie immer getan hat. Und von solchen Problemen war auch in der Releasenotes nichts zu lesen.

 

[Falk R.]

Hi, dann pin erst einmal den Vorgängerkernel an und wenn du Subscription hast mach ein Ticket auf. Dafür zahlst du ja. Bei vSphere habe ich vor Jahren genau die gleichen Probleme bei einigen Kunden gehabt. Lag damals an einem Mitigation Patch. Auch da waren nur manche VMs betroffen.

Ob die VMs gecrasht sind lag daran auf welchem Host die VMs gestartet waren. Ob einem schon mit oder ohne Patch.

Daher vermute ich hier etwas ähnliches.

 

[fiona]

Hi,

Einige Centos 6.x lassen sich nicht mehr auf die alte (8.2.2) Maschine migrieren. Jedoch haben wir, eigentlich identische VM's bei denen geht es. Diese crashen. auch nicht, wenn ich von PVE01 auf PVE02 migriere. Alle VM's, die auf Centos 6.x basieren sind aus unserem Repo und müssten identisch sein.

es ist generell stark empfohlen nur von Hosts mit älteren Versionen zu Hosts mit neueren Versionen zu migrieren. Es kann nicht immer garantiert werden, dass solche Rückwärtsmigrationen funktionieren. Aber da es ja laut erstem Post auch in die andere Richtung Probleme gab: Wie schauen die VM-Konfigurationen aus, qm config <ID>? Ist diese auch identisch zwischen den VMs bei denen es funktioniert und nicht funktioniert?