HA/Live-Migration funktioniert nicht (mehr)

[Tux-Stuttgart]

Hallo,

ich bin gerade dabei ein HCI-Cluster mit 3 Nodes einzurichten. Nachdem das Cluster zuerst einige Tage fehlerfrei funktioniert hatte, habe ich aktuell Probleme bei der HA/Live-Migration.

Die Migration startet zuerst ganz normal, nach kurzer Zeit ist die Memory-Migration aber extrem langsam. Lasse ich die Migration weiter laufen fällt auf, dass mehr Memory migriert wird, als der VM zugeordnet wurde.

Das Netzwerk ist mit 10G ausreichend schnell, die Hosts haben aktuelle Prozessoren (AMD EPYC 7443P) und RAM(512 GB). Als Ceph-Storage kommen SSDs zum Einsatz.

Die Nodes laufen seit 28 Tagen, die VMs wurden vor 8 Tagen neu gestartet.

Ein Neustart der VM hilft nicht, fahre ich die VM jedoch herunter (und lasse diese vom HA wieder starten oder starte Sie manuell wieder) funktioniert die Migration wie erwartet. Das Migration-Netzwerk habe ich testweise schon auf andere NICs geändert und auch schon auf insecure gesetzt.
Was auffällt ist, dass nach dem Shutdown der KVM-Prozess etwas andere Parameter hat:
Vorher: -machine type=pc-i440fx-7.2+pve0 -incoming unix:/run/qemu-server/135.migrate -Sgeht:
Nachher: -machine type=pc+pve0


Aktuell habe ich noch Version 7.4-16 installiert.

Im folgenden das Log der Migration:

2023-07-24 15:53:21 use dedicated network address for sending migration traffic (10.10.10.122)
2023-07-24 15:53:21 starting migration of VM 161 to node 'pve-03' (10.10.10.122)
2023-07-24 15:53:21 starting VM 161 on remote node 'pve-03'
2023-07-24 15:53:22 start remote tunnel
2023-07-24 15:53:23 ssh tunnel ver 1
2023-07-24 15:53:23 starting online/live migration on unix:/run/qemu-server/161.migrate
2023-07-24 15:53:23 set migration capabilities
2023-07-24 15:53:23 migration downtime limit: 0 ms
2023-07-24 15:53:23 migration cachesize: 256.0 MiB
2023-07-24 15:53:23 set migration parameters
2023-07-24 15:53:23 start migrate command to unix:/run/qemu-server/161.migrate
2023-07-24 15:53:24 migration active, transferred 824.4 MiB of 2.0 GiB VM-state, 1.1 GiB/s
2023-07-24 15:53:26 auto-increased downtime to continue migration: 0 ms
2023-07-24 15:53:26 migration active, transferred 1.6 GiB of 2.0 GiB VM-state, 0.0 B/s
2023-07-24 15:53:26 auto-increased downtime to continue migration: 0 ms
2023-07-24 15:53:27 auto-increased downtime to continue migration: 0 ms
2023-07-24 15:53:27 migration active, transferred 1.6 GiB of 2.0 GiB VM-state, 0.0 B/s
2023-07-24 15:53:27 auto-increased downtime to continue migration: 0 ms
2023-07-24 15:53:28 migration active, transferred 1.6 GiB of 2.0 GiB VM-state, 0.0 B/s
2023-07-24 15:53:28 auto-increased downtime to continue migration: 0 ms
2023-07-24 15:53:29 auto-increased downtime to continue migration: 0 ms
2023-07-24 15:53:29 migration active, transferred 1.6 GiB of 2.0 GiB VM-state, 0.0 B/s
2023-07-24 15:53:29 auto-increased downtime to continue migration: 0 ms
2023-07-24 15:53:30 auto-increased downtime to continue migration: 0 ms
2023-07-24 15:53:30 migration active, transferred 1.6 GiB of 2.0 GiB VM-state, 0.0 B/s
2023-07-24 15:53:30 auto-increased downtime to continue migration: 0 ms
2023-07-24 15:53:31 migration active, transferred 1.7 GiB of 2.0 GiB VM-state, 0.0 B/s
2023-07-24 15:53:31 auto-increased downtime to continue migration: 0 ms
2023-07-24 15:53:32 auto-increased downtime to continue migration: 0 ms
2023-07-24 15:53:32 migration active, transferred 1.7 GiB of 2.0 GiB VM-state, 0.0 B/s
2023-07-24 15:53:32 auto-increased downtime to continue migration: 0 ms
2023-07-24 15:53:33 auto-increased downtime to continue migration: 0 ms
[...]
2023-07-24 15:57:19 migration active, transferred 2.2 GiB of 2.0 GiB VM-state, 0.0 B/s
2023-07-24 15:57:20 auto-increased downtime to continue migration: 0 ms
2023-07-24 15:57:20 auto-increased downtime to continue migration: 0 ms
2023-07-24 15:57:20 migration active, transferred 2.2 GiB of 2.0 GiB VM-state, 0.0 B/s
2023-07-24 15:57:21 auto-increased downtime to continue migration: 0 ms
2023-07-24 15:57:21 migration active, transferred 2.2 GiB of 2.0 GiB VM-state, 0.0 B/s
2023-07-24 15:57:22 auto-increased downtime to continue migration: 0 ms
2023-07-24 15:57:22 auto-increased downtime to continue migration: 0 ms
2023-07-24 15:57:23 migration active, transferred 2.2 GiB of 2.0 GiB VM-state, 0.0 B/s
2023-07-24 15:57:23 auto-increased downtime to continue migration: 0 ms
2023-07-24 15:57:23 auto-increased downtime to continue migration: 0 ms
2023-07-24 15:57:24 migration active, transferred 2.2 GiB of 2.0 GiB VM-state, 0.0 B/s
2023-07-24 15:57:24 auto-increased downtime to continue migration: 0 ms
2023-07-24 15:57:24 ERROR: online migrate failure - interrupted by signal
2023-07-24 15:57:24 aborting phase 2 - cleanup resources
2023-07-24 15:57:24 migrate_cancel
2023-07-24 15:57:25 ERROR: writing to tunnel failed: broken pipe
2023-07-24 15:57:25 ERROR: migration finished with problems (duration 00:04:04)
TASK ERROR: migration problems

Ziel ist es die HA/Live-Migration wieder zum funktionieren zu bekommen ohne alle VMs manuell herunterfahren zu müssen.

Bin über jede Hilfe dankbar.

Tux

 

[Falk R.]

Hi was mir auffällt:

2023-07-24 15:53:23 starting online/live migration on unix:/run/qemu-server/161.migrate
2023-07-24 15:53:23 set migration capabilities
2023-07-24 15:53:23 migration downtime limit: 0 ms
2023-07-24 15:53:23 migration cachesize: 256.0 MiB
2023-07-24 15:53:23 set migration parameters
2023-07-24 15:53:23 start migrate command to unix:/run/qemu-server/161.migrate
2023-07-24 15:53:24 migration active, transferred 824.4 MiB of 2.0 GiB VM-state, 1.1 GiB/s
2023-07-24 15:53:26 auto-increased downtime to continue migration: 0 ms
2023-07-24 15:53:26 migration active, transferred 1.6 GiB of 2.0 GiB VM-state, 0.0 B/s
2023-07-24 15:53:26 auto-increased downtime to continue migration: 0 ms
2023-07-24 15:53:27 auto-increased downtime to continue migration: 0 ms

Bei dir ist das Downtime Limit bei 0ms und relativ kleiner Cache.
Die Meldung auto-increased downtime to continue migration: 0 ms spricht für einen zu kleinen Wert bei der migration downtime.
Ich weiß aber nicht wo man das verstellt.
Bei mir sieht das zuhause so aus:

task started by HA resource agent
2023-07-24 23:58:16 use dedicated network address for sending migration traffic (192.168.253.2)
2023-07-24 23:58:17 starting migration of VM 221 to node 'srv2' (192.168.253.2)
2023-07-24 23:58:17 starting VM 221 on remote node 'srv2'
2023-07-24 23:58:19 start remote tunnel
2023-07-24 23:58:20 ssh tunnel ver 1
2023-07-24 23:58:20 starting online/live migration on tcp:192.168.253.2:60000
2023-07-24 23:58:20 set migration capabilities
2023-07-24 23:58:20 migration downtime limit: 100 ms
2023-07-24 23:58:20 migration cachesize: 2.0 GiB
2023-07-24 23:58:20 set migration parameters
2023-07-24 23:58:20 start migrate command to tcp:192.168.253.2:60000
2023-07-24 23:58:21 migration active, transferred 1.2 GiB of 16.0 GiB VM-state, 1.5 GiB/s
2023-07-24 23:58:22 migration active, transferred 2.7 GiB of 16.0 GiB VM-state, 1.7 GiB/s
2023-07-24 23:58:23 migration active, transferred 4.0 GiB of 16.0 GiB VM-state, 9.4 GiB/s
2023-07-24 23:58:24 migration active, transferred 5.2 GiB of 16.0 GiB VM-state, 1.7 GiB/s
2023-07-24 23:58:26 average migration speed: 2.7 GiB/s - downtime 246 ms
2023-07-24 23:58:26 migration status: completed
2023-07-24 23:58:29 migration finished successfully (duration 00:00:13)
TASK OK

 

[Tux-Stuttgart]

Danke für den Hinweis.
Ich habe das soeben auf dem Cluster getestet, die Einstellung für migrate_downtime ist bei allen VMs 0. Auch nach einem Shutdown/Start, wenn die Migration dann funktioniert.

Nachdem gestern bei einigen VMs die Migration nach einem Shutdown/Start wieder funktioniert hatte, hat diese heute bei diesen VMs ebenfalls nicht mehr funktioniert. Das einzige was mir hierfür als mögliche Ursache eingefallen ist, ist das Backup über den PBS. Was mich zu weiteren Tests veranlasst hat.

Nach dem Shutdown/Start der VM lässt sich diese (auch mehrfach) migrieren, sobald der PBS ein Backup der VM durchführt, klappt die Migration jedoch nicht mehr. Mache ich dann wieder einen Shutdown/Start der VM funktioniert die Migration wieder, nach einem erneuten Backup dann wieder nicht mehr.

Bin für jede Idee dankbar, da ich aktuell keine Erklärungen oder Lösungsansätze habe

 

[Falk R.]

Danke für den Hinweis.
Ich habe das soeben auf dem Cluster getestet, die Einstellung für migrate_downtime ist bei allen VMs 0. Auch nach einem Shutdown/Start, wenn die Migration dann funktioniert.

Nachdem gestern bei einigen VMs die Migration nach einem Shutdown/Start wieder funktioniert hatte, hat diese heute bei diesen VMs ebenfalls nicht mehr funktioniert. Das einzige was mir hierfür als mögliche Ursache eingefallen ist, ist das Backup über den PBS. Was mich zu weiteren Tests veranlasst hat.

Nach dem Shutdown/Start der VM lässt sich diese (auch mehrfach) migrieren, sobald der PBS ein Backup der VM durchführt, klappt die Migration jedoch nicht mehr. Mache ich dann wieder einen Shutdown/Start der VM funktioniert die Migration wieder, nach einem erneuten Backup dann wieder nicht mehr.

Bin für jede Idee dankbar, da ich aktuell keine Erklärungen oder Lösungsansätze habe

Nach einem Shutdown und neu starten muss der PBS wieder einen Full Read beim Backup machen. Danach macht qemu ein Change Tracking. Diese Informationen müssen natürlich mit migriert werden und dann könnte die migrate downtime anschlagen.