VM hängt nach Online-Migration

[rowa-hooge]

Hallo,

ich habe hier schon länger ein massives Problem mit der Online-Migration.
Nach dem Verschieben hängt die Maschine und ich bekomme sie nur mit Stop/Start wieder
zum Leben.
Ich habe jetzt auf dem Zielserver den neuesten Kernel 6.2 installiert, aber das
Problem besteht weiterhin.

CPU Quelle:
vendor_id : GenuineIntel
cpu family : 6
model : 85
model name : Intel(R) Xeon(R) Silver 4114 CPU @ 2.20GHz
stepping : 4
microcode : 0x2000057


CPU Ziel:
vendor_id : GenuineIntel
cpu family : 6
model : 63
model name : Intel(R) Xeon(R) CPU E5-2620 v3 @ 2.40GHz
stepping : 2
microcode : 0x35


Syslog-Auszug:
Apr 11 09:10:12 pve-10 kernel: [ 134.231232] ------------[ cut here ]------------ Apr 11 09:10:12 pve-10 kernel: [ 134.231239] WARNING: CPU: 0 PID: 3955 at arch/x86/kvm/x86.c:10853 kvm_arch_vcpu_ioctl_run+0x16b3/0x17f0 [k vm] Apr 11 09:10:12 pve-10 kernel: [ 134.231422] Modules linked in: ebtable_filter ebtables ip_set ip6table_raw iptable_raw ip6table_filter ip6 _tables sctp ip6_udp_tunnel udp_tunnel cmac nls_utf8 cifs cifs_arc4 cifs_md4 fscache netfs iptable_filter bpfilter softdog nfnetlink_log nfn etlink intel_rapl_msr intel_rapl_common ipmi_ssif sb_edac x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm irqbypass crct10dif_p clmul polyval_clmulni polyval_generic ghash_clmulni_intel mgag200 sha512_ssse3 aesni_intel drm_shmem_helper crypto_simd drm_kms_helper crypt d acpi_ipmi rapl intel_cstate pcspkr efi_pstore input_leds ioatdma ipmi_si i2c_algo_bit zfs(PO) syscopyarea sysfillrect sysimgblt hpilo ipmi _devintf acpi_tad ipmi_msghandler dca acpi_power_meter mac_hid zunicode(PO) zzstd(O) zlua(O) zavl(PO) icp(PO) zcommon(PO) znvpair(PO) spl(O) vhost_net vhost vhost_iotlb tap ib_iser rdma_cm iw_cm ib_cm ib_core iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi drm sunrpc ip_tabl es x_tables autofs4 btrfs blake2b_generic xor raid6_pq Apr 11 09:10:12 pve-10 kernel: [ 134.231559] libcrc32c hid_generic usbmouse usbkbd usbhid hid simplefb ses enclosure xhci_pci crc32_pclmul xhci_pci_renesas ahci i2c_i801 uhci_hcd ehci_pci lpc_ich libahci i2c_smbus xhci_hcd ehci_hcd i40e hpsa tg3 scsi_transport_sas wmi Apr 11 09:10:12 pve-10 kernel: [ 134.231599] CPU: 0 PID: 3955 Comm: CPU 1/KVM Tainted: P O 6.2.6-1-pve #1 Apr 11 09:10:12 pve-10 kernel: [ 134.231605] Hardware name: HP ProLiant DL380 Gen9, BIOS P89 07/20/2015 Apr 11 09:10:12 pve-10 kernel: [ 134.231608] RIP: 0010:kvm_arch_vcpu_ioctl_run+0x16b3/0x17f0 [kvm] Apr 11 09:10:12 pve-10 kernel: [ 134.231740] Code: 00 08 0f 84 d7 f8 ff ff e9 4b fe ff ff 49 8b 84 24 08 02 00 00 48 85 c0 0f 84 b1 f8 ff f f e9 8a fe ff ff 0f 0b e9 af fa ff ff <0f> 0b e9 8c fa ff ff 49 8b 44 24 38 a9 00 00 00 40 74 0f f0 41 80 Apr 11 09:10:12 pve-10 kernel: [ 134.231745] RSP: 0018:ffffa8fcb29dfd90 EFLAGS: 00010202 Apr 11 09:10:12 pve-10 kernel: [ 134.231750] RAX: 0000000000000001 RBX: ffff99b3f3c04000 RCX: 0000000000000000 Apr 11 09:10:12 pve-10 kernel: [ 134.231753] RDX: 00002f0a7fc17800 RSI: 00000000fffffe01 RDI: ffff99b3e846a400 Apr 11 09:10:12 pve-10 kernel: [ 134.231756] RBP: ffffa8fcb29dfe30 R08: 0000000000000001 R09: 0000000000000000 Apr 11 09:10:12 pve-10 kernel: [ 134.231759] R10: 0000000000000000 R11: 0000000000000000 R12: ffff99b3e846a400 Apr 11 09:10:12 pve-10 kernel: [ 134.231761] R13: ffff99b3e846a400 R14: ffff99b3e846a448 R15: ffff99b30ca7a900 Apr 11 09:10:12 pve-10 kernel: [ 134.231764] FS: 00007f2555ffb700(0000) GS:ffff99d1ffc00000(0000) knlGS:0000000000000000 Apr 11 09:10:12 pve-10 kernel: [ 134.231768] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 Apr 11 09:10:12 pve-10 kernel: [ 134.231771] CR2: 000056460e09c5c0 CR3: 00000001c7a76006 CR4: 00000000001726f0 Apr 11 09:10:12 pve-10 kernel: [ 134.231775] Call Trace: Apr 11 09:10:12 pve-10 kernel: [ 134.231778] <TASK> Apr 11 09:10:12 pve-10 kernel: [ 134.231783] ? wake_up_q+0x50/0x90 Apr 11 09:10:12 pve-10 kernel: [ 134.231794] ? futex_wake+0x157/0x190 Apr 11 09:10:12 pve-10 kernel: [ 134.231805] kvm_vcpu_ioctl+0x24f/0x6d0 [kvm] Apr 11 09:10:12 pve-10 kernel: [ 134.231903] ? do_futex+0xbd/0x1d0 Apr 11 09:10:12 pve-10 kernel: [ 134.231910] ? __x64_sys_futex+0x81/0x1d0 Apr 11 09:10:12 pve-10 kernel: [ 134.231916] ? __x64_sys_futex+0x81/0x1d0 Apr 11 09:10:12 pve-10 kernel: [ 134.231921] ? __fget_light.part.0+0x8c/0xd0 Apr 11 09:10:12 pve-10 kernel: [ 134.231930] __x64_sys_ioctl+0x95/0xd0 Apr 11 09:10:12 pve-10 kernel: [ 134.231938] do_syscall_64+0x5c/0x90 Apr 11 09:10:12 pve-10 kernel: [ 134.231947] entry_SYSCALL_64_after_hwframe+0x72/0xdc Apr 11 09:10:12 pve-10 kernel: [ 134.231959] RIP: 0033:0x7f25881d95f7 Apr 11 09:10:12 pve-10 kernel: [ 134.231963] Code: 00 00 00 48 8b 05 99 c8 0d 00 64 c7 00 26 00 00 00 48 c7 c0 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 b8 10 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 69 c8 0d 00 f7 d8 64 89 01 48 Apr 11 09:10:12 pve-10 kernel: [ 134.231967] RSP: 002b:00007f2555ff6288 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 Apr 11 09:10:12 pve-10 kernel: [ 134.231972] RAX: ffffffffffffffda RBX: 000000000000ae80 RCX: 00007f25881d95f7 Apr 11 09:10:12 pve-10 kernel: [ 134.231975] RDX: 0000000000000000 RSI: 000000000000ae80 RDI: 0000000000000031 Apr 11 09:10:12 pve-10 kernel: [ 134.231978] RBP: 000056460e5e4460 R08: 000056460d106240 R09: 000056460d80a940 Apr 11 09:10:12 pve-10 kernel: [ 134.231981] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000 Apr 11 09:10:12 pve-10 kernel: [ 134.231983] R13: 000056460d811020 R14: 00007f2555ff6540 R15: 0000000000802000 Apr 11 09:10:12 pve-10 kernel: [ 134.231991] </TASK> Apr 11 09:10:12 pve-10 kernel: [ 134.231993] ---[ end trace 0000000000000000 ]---

 

[Matthias.]

Aus unserer Dokumentation https://pve.proxmox.com/pve-docs/pve-admin-guide.html

This has a downside though. If you want to do a live migration of VMs between different hosts, your VM might end up on a new system with a different CPU type. If the CPU flags passed to the guest are missing, the qemu process will stop. To remedy this QEMU has also its own CPU type kvm64, that Proxmox VE uses by defaults. kvm64 is a Pentium 4 look a like CPU type, which has a reduced CPU flags set, but is guaranteed to work everywhere.

In short, if you care about live migration and moving VMs between nodes, leave the kvm64 default. If you don’t care about live migration or have a homogeneous cluster where all nodes have the same CPU, set the CPU type to host, as in theory this will give your guests maximum performance.

Also entweder nicht live migrieren oder CPU typ auf etwas stellen, das beide unterstützen (aus den vorgegebenen oder mit https://pve.proxmox.com/pve-docs/cpu-models.conf.5.html)

 

[rowa-hooge]

Die CPU der VMs ist immer "kvm64".
Die o.a. CPU ist die Hardware die im Host verbaut ist.

 

[Falk R.]

Die CPU der VMs ist immer "kvm64".
Die o.a. CPU ist die Hardware die im Host verbaut ist.

Mit kvm64 sollte es gehen, aber manche moderne VMs haben Probleme mit kvm64. Ich würde auf den CPU Typ der ältesten CPU gehen und dann noch einmal probieren.

 

[Neobin]

Ich habe jetzt auf dem Zielserver den neuesten Kernel 6.2 installiert

Und welcher läuft auf dem Quellserver?
5.15 hat Probleme mit Live-Migration (hauptsächlich) von neueren zu älteren CPUs, wenn ich mich recht erinnere. (Was hier ja ebenfalls der Fall ist.)

Sowohl auf dem Quell- als auch auf dem Zielserver muss also mindestens der 5.19er (ist EOL) oder besser halt der aktuelle opt-in 6.2 Kernel laufen.

 

[rowa-hooge]

Auf dem Quellserver läuft die neueste 5.15er Version.
Hatte eigentlich gehofft daß ein Update des Zielservers ausreicht.
Quellserver updaten bedeutet, daß ich einige VMs herunterfahren muß.
Geht natürlich nicht im Tagesgeschäft.

 

[Falk R.]

Dann Update erst einmal den Zielserver, eventuell läuft es dann schon.
Wenn du alles migriert bekommst, ist es ja einfacher den anderen zu updaten.

 

[Neobin]

Auf dem Quellserver läuft die neueste 5.15er Version.
Hatte eigentlich gehofft daß ein Update des Zielservers ausreicht.
Quellserver updaten bedeutet, daß ich einige VMs herunterfahren muß.
Geht natürlich nicht im Tagesgeschäft.

Ja, leider kommt man da in diesem Fall nicht drum herum.

Hier noch als Referenz zur Problematik:

1. https://forum.proxmox.com/threads/p...on-linux-freeze-on-windows.109645/post-511185
2. https://forum.proxmox.com/threads/p...on-linux-freeze-on-windows.109645/post-511210
3. Diverse andere Threads hier im (englischsprachigen Teil des) Forum(s).

Wie gesagt, mittlerweile definitiv den 6.2er Kernel nehmen, da der 5.19er EOL ist!

 

[rowa-hooge]

Ok, werde auch den Quellserver auf 6.2 hochziehen.
Werde berichten ob es geholfen hat.

 

[Falk R.]

Versuche mal mit einer VM ob es schon geht, wenn nur der Zielserver gepatcht ist.

 

[Neobin]

Versuche mal mit einer VM ob es schon geht, wenn nur der Zielserver gepatcht ist.

Ist er doch schon längst:

Ich habe jetzt auf dem Zielserver den neuesten Kernel 6.2 installiert, aber das
Problem besteht weiterhin.

 

[Falk R.]

Sorry, hab ich auf dem Handy überlesen.

 

[freshdomi]

konntet ihr das Problem bereits lösen? Wir haben das gleiche Probleme mit AMD CPUs
PVE: 7.4-3
Kernel: vmlinuz-5.15.107-1-pve

die VMs bleiben nach der Migration hängen wenn ich von einem Server mit der CPU AMD EPYC 7443P auf einen mit der CPU AMD EPYC 7452 migriere;

CPU Type steht auf default(kvm64) wir haben aber auch schon "EPYC" und "Host" ausprobiert.. selbes Ergebnis

 

[rowa-hooge]

Ich habe den zweiten Server auf 6.2 aktualisiert und jew. eine Linux- und eine Windows-Maschine
verschieben können.
Endgültiges OK wollte ich erst geben wenn ich mehr Verschiebungen erfolgreich machen konnte.
Es sieht nach aktuellem Stand aber vorläuftig gut aus

 

[freshdomi]

ok dann test ich das bei uns auch mal mit dem 6.2 Kernel!
Danke schonmal

EDIT: hat bisher alles funktioniert; Windows konnte ich nicht testen da wir keines im Einsatz haben...