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?

 

[Winet.maier]

Die Migration funktioniert nach dem Update von PVE01 wieder in beide Richtungen. Das Problem ist nur, dass ich etwa 70% der VM vn Hand migrieren muss, da ich nur so sehe, ob die VM hängt. Die Konfigurationen zwischen den VM's sind identisch. Es gibt innerhalb des Centos 6.x kleine Unterschiede, die jedoch marginal sind.

Wir werden im Laufe dieser Woche den zweiten Hypervisor updaten. Das bedeutet, dass ich über 100 VM's von Hand migrieren muss und dann STOP und wieder Start ausführen muss.

Am Besten funktioniert es, wenn man keinen CPU Type auswählt. Also nicht mal KVM64 auswählen, sondern keinen.

Hier die Konfig einer VM die Probleme machte.

agent: 1
boot: order=scsi0
cores: 2
ide2: none,media=cdrom
memory: 512
name: J-B-Personal
net0: virtio=22:FD:6E:04:74:CA,bridge=vmbr1,firewall=1
numa: 0
ostype: l26
protection: 1
scsi0: JOVIAN_COMP:109001091/vm-109001091-disk-0.qcow2,size=8G
scsihw: virtio-scsi-pci
smbios1: uuid=04a18c04-9d10-4da7-bb51-6bd0e8bb371f
sockets: 1
vmgenid: 778db9a5-3cb1-40f2-8842-7adde748e202
root@pve02:~#

und das ist eine VM, die Centos 7.x hat und immer einwandfrei migriert werden kann.

agent: 1
balloon: 512
boot: order=scsi0
cores: 2
cpu: x86-64-v3
ide2: none,media=cdrom
memory: 1024
name: Graenicher-hAyrix
net0: virtio=1A:40:6D:FD:CA:86,bridge=vmbr1,firewall=1
numa: 0
ostype: l26
scsi0: JOVIAN_COMP:109000154/vm-109000154-disk-0.qcow2,size=8G
scsihw: virtio-scsi-pci
smbios1: uuid=ebcb2b78-c820-43c6-9b01-96c28af44faf
sockets: 1
vmgenid: 68d45a1b-8061-452e-b719-74a68d09e904

 

[Falk R.]

Hi, wie nutzt du den Jovian Storage? ZFS over iSCSI oder etwas anderes?

 

[Winet.maier]

Hi, wie nutzt du den Jovian Storage? ZFS over iSCSI oder etwas anderes?

NFS

 

[Winet.maier]

NFS

Der hat hat ein 40 Gbit Metronet und hat so die letzten zwei Jahre hervorragend funktioniert.

 

[fiona]

Die Migration funktioniert nach dem Update von PVE01 wieder in beide Richtungen. Das Problem ist nur, dass ich etwa 70% der VM vn Hand migrieren muss, da ich nur so sehe, ob die VM hängt. Die Konfigurationen zwischen den VM's sind identisch. Es gibt innerhalb des Centos 6.x kleine Unterschiede, die jedoch marginal sind.

Gab es innerhalb der Gäste oder auf dem Host irgendwelche interessanten Log-Einträge?

Am Besten funktioniert es, wenn man keinen CPU Type auswählt. Also nicht mal KVM64 auswählen, sondern keinen.

Da kvm64 der Default-Wert im Backend ist, ist die Kommandozeile, mit der QEMU gestartet wird, in beiden Fällen identisch. Allerdings ist das nur wegen Rückwärtskompatibilität der Default-Wert, die UI wählt daher beim Erstellen einer VM vorab x86-64-v2-AES aus.

agent: 1
balloon: 512
boot: order=scsi0
cores: 2
cpu: x86-64-v3
ide2: none,media=cdrom
memory: 1024
name: Graenicher-hAyrix
net0: virtio=1A:40:6D:FD:CA:86,bridge=vmbr1,firewall=1
numa: 0
ostype: l26
scsi0: JOVIAN_COMP:109000154/vm-109000154-disk-0.qcow2,size=8G
scsihw: virtio-scsi-pci
smbios1: uuid=ebcb2b78-c820-43c6-9b01-96c28af44faf
sockets: 1
vmgenid: 68d45a1b-8061-452e-b719-74a68d09e904

Haben andere CentOS 7 VMs auch x86-64-v3 als CPU-Typ?

Eine Vermutung ist, dass der alte Kernel innerhalb der CentOS 6 VMs irgendwie Probleme macht, i.e. im Zusammenhang mit KVM-Hardware-Virtualisierung und dem viel neueren Host-Kernel.

 

[Winet.maier]

Gab es innerhalb der Gäste oder auf dem Host irgendwelche interessanten Log-Einträge?

Habe dazu leider nichts gefunden. Die Migration läuft bis und mit dem Switch vom Host und dann ist ende mit der VM. auch der Guest Agent ist dann weg und die CPU geht hoch.
Interessanterweise lassen sich solche VM's ja killen und neu starten und alufen anschliessend wie gehabt. Zurückmigrieren geht dann jedoch nicht, weil die Fehlermeldung kommt: Hypervisor Version zu alt. Bitte updaten auf 8.2.7. Die VM's mit Centos 7.x lassen sich jedoch problemlos auch auf die ältere Hypervisor Version migrieren.

Da kvm64 der Default-Wert im Backend ist, ist die Kommandozeile, mit der QEMU gestartet wird, in beiden Fällen identisch. Allerdings ist das nur wegen Rückwärtskompatibilität der Default-Wert, die UI wählt daher beim Erstellen einer VM vorab x86-64-v2-AES aus.

Ahh interessant, wusste ich noch nicht

Haben andere CentOS 7 VMs auch x86-64-v3 als CPU-Typ?

Nicht unbedingt, wir haben am Anfang lange experimentiert und sind dann bei x86-64-v3 gelandet.

Eine Vermutung ist, dass der alte Kernel innerhalb der CentOS 6 VMs irgendwie Probleme macht, i.e. im Zusammenhang mit KVM-Hardware-Virtualisierung und dem viel neueren Host-Kernel.

Das hat jahrelang funktioniert. Und das Problem tritt auch nur auf, wenn wir von der Version 8.2.2 zu 8.2.7Verschieben. Wir hatten ein ähnliches Thema schon mal, Jetzt ist es aber extrem.
Leider ist es nicht möglich, die alten Centos 6.x auf eine neuere Version zu heben. Die Software, die darauf läuft, müsste kompl. neu kompiliert werden und dazu fehlen die Repo's

 

[Falk R.]

Habe dazu leider nichts gefunden. Die Migration läuft bis und mit dem Switch vom Host und dann ist ende mit der VM. auch der Guest Agent ist dann weg und die CPU geht hoch.
Interessanterweise lassen sich solche VM's ja killen und neu starten und alufen anschliessend wie gehabt. Zurückmigrieren geht dann jedoch nicht, weil die Fehlermeldung kommt: Hypervisor Version zu alt. Bitte updaten auf 8.2.7. Die VM's mit Centos 7.x lassen sich jedoch problemlos auch auf die ältere Hypervisor Version migrieren.

Ahh interessant, wusste ich noch nicht

Nicht unbedingt, wir haben am Anfang lange experimentiert und sind dann bei x86-64-v3 gelandet.

Das hat jahrelang funktioniert. Und das Problem tritt auch nur auf, wenn wir von der Version 8.2.2 zu 8.2.7Verschieben. Wir hatten ein ähnliches Thema schon mal, Jetzt ist es aber extrem.
Leider ist es nicht möglich, die alten Centos 6.x auf eine neuere Version zu heben. Die Software, die darauf läuft, müsste kompl. neu kompiliert werden und dazu fehlen die Repo's

HI, mir fällt da gerade noch etwas ein. Ich habe zwar noch nie mit Centos gearbeitet aber ich muste früher bei RedHat Servern die SCSI Timeouts hochstellen, da der Defaultwert recht knapp war und wenn man shared Storages genutzt hat und einen Controllerschwenk oder eine Migration gemacht hat, gingen die Dateisysteme sonst auf readonly.
Kannst du mal checken wie die SCSI Timeouts in den VMs sind und ob die eventuell unterschiedlich sind.

 

[Winet.maier]

Abschluss Kommentar:
Wir haben weiter Untersuchungen gemacht und sind uns inzwischen ziemlich sicher, dass es am Versionssprung von pve-qemu-kvm 8.1.5 auf 9.0.2 liegt. Wenn man da einer wenig genauer liest, findet man folgende Passage:

move compatibility flags for a new VirtIO-net feature to the correct machine type. The feature was introduced in QEMU 8.2, but the compatibility flags got added to machine version 8.0 instead of 8.1. This breaks backwards migration with machine version 8.1 from a 8.2/9.0 binary to an 8.1 binary, in cases where the guest kernel enables the feature (e.g. Ubuntu 23.10). While that breaks migration with machine version 8.1 from an unpatched to a patched binary, Proxmox VE only ever had 8.2 on the test repository and 9.0 not yet in any public repository.

Wir gehen davon aus, dass es hier bei ca. 45% der Centos 6.x VM's zu einem crash kam. Meistens hatten diese als CPU Microcode kvm64 ausgewählt gehabt.
Der ganze Update von 8.2.2 auf 8.2.7 war ein enormer Aufwand mit sehr unangenehmen Ereignissen.

 

[fiona]

Das betraf aber nur Rückwärtsmigration, i.e. von einer neueren Version zu einer älteren. Und es müsste QEMU 8.2 installiert gewesen sein, weil QEMU 9.0 hatte den Fix schon als es öffentlich ausgerollt wurde. Und das Feature muss im Gast aktiv sein und ist relativ neu in Linux, ich würde bezweifeln, dass es in CentOS 6 aktiv ist.