qm Parameter --migrate_downtime

[Jack1967]

Hallo,

vom Proxmox Support wurde ich auf den Parameter --migrate_downtime hingewiesen, mit dem laut Manpage die "maximum tolerated downtime (in seconds)" eingestellt werden kann. Doch wenn ich diesen Parameter angebe, passiert folgendes:
qm migrate 112 pve1-03 --migration_network 192.168.2.0/24 --migration_type insecure --online true --migrate_downtime 0.001
Unknown option: migrate_downtime
400 unable to parse option
qm migrate <vmid> <target> [OPTIONS]

Weiß jemand, ab welcher Version dieser Parameter tatsächlich verfügbar ist?


Danke und Gruß,
Jack

P.S. Ein "qm help migrate" zeigt mir diesen Parameter auch nicht, nur die Manpage erwähnt ihn.

 

[Falk R.]

Ich höre von dem Parameter zum ersten mal, aber mir stellt sich die Frage, wofür benötigst du den Parameter und wenn du den Wert so niedrig setzt, dürfte die Migration auch nicht laufen.

 

[Der Harry]

Kurz gesagt. Gibt es nicht.

root@proxmox:~# pveversion -v | grep proxmox-ve
proxmox-ve: 8.2.0 (running kernel: 6.5.13-5-pve)
root@proxmox:~# qm help migrate | grep -i downtime
root@proxmox:~#

 

[fiona]

Hi,
der Parameter muss direkt bei der VM gesetzt werden, i.e. mit qm set 112 --migrate_downtime <Wert>. Falls die Migration aber nicht konvergieren kann (weil zu viel neuer RAM dirty wird und migriert werden muss), dann wird der Wert während der End-Phase der Migration automatisch nach und nach erhöht, bis die Migration konvergieren/abgeschlossen werden kann.

 

[Jack1967]

Hallo zusammen,

ich bin auf Umwegen auf diesen Parameter gekommen, weil ich bei verschiedenen Migrationen festgestellt habe, dass der Default-Wert von 100ms Downtime (was in meinen Augen schon ziemlich lang ist), laut Output teilweise um mehr als 50% überschritten wurde. Entsprechend den Anmerkungen von fiona - vielen Dank für den Hinweis! - kann es auch schlicht daran liegen, dass die Netzwerkverbindung zu langsam ist. Da muss ich vielleicht noch ein wenig experimentieren (habe auch ein schnelleres Interface, doch da darüber der NFS-Traffic für den Shared Storage läuft, wollte ich das eigentlich nicht nutzen).

@Falk R.: Mir ist schon klar, dass 1ms eine arg heftige Einstellung ist. War aber auch nur als erster Versuch gedacht, um die Downtime mal unter 100ms zu bekommen. Ich dachte außerdem, dass die Migration dann abbricht, wenn der vorgegebene Wert nicht erreichbar ist und eine iterative Annäherung an den niedrigst möglichen Schwellwert notwendig ist.

Und ich halte es für einen ziemlich groben Bug, wenn die Vorgabe u.U. schlicht ignoriert wird! Wenn es in der Endphase der Migration (in mehreren Anläufen) nicht möglich ist, innerhalb der gesetzten maximalen Downtime die Migration abzuschliessen, erwarte ich eine Fehlermeldung mit einer recht genauen Angabe, wie groß die Downtime für eine erfolgreiche Migration voraussichtlich sein muss!
Bei mir ist es zum Glück "nur" mein privater Test-Cluster, aber spinnen wir den Faden doch mal weiter: Ein produktives System in einer VM mit 128GB RAM auf dem auch einiges los ist, irgendeiner wirft ein "qm migrate" an und dann ist das System plötzlich für mehr als 3s nicht erreichbar ...

 

[Falk R.]

Und ich halte es für einen ziemlich groben Bug, wenn die Vorgabe u.U. schlicht ignoriert wird! Wenn es in der Endphase der Migration (in mehreren Anläufen) nicht möglich ist, innerhalb der gesetzten maximalen Downtime die Migration abzuschliessen, erwarte ich eine Fehlermeldung mit einer recht genauen Angabe, wie groß die Downtime für eine erfolgreiche Migration voraussichtlich sein muss!
Bei mir ist es zum Glück "nur" mein privater Test-Cluster, aber spinnen wir den Faden doch mal weiter: Ein produktives System in einer VM mit 128GB RAM auf dem auch einiges los ist, irgendeiner wirft ein "qm migrate" an und dann ist das System plötzlich für mehr als 3s nicht erreichbar ...

Es geht ja nur um den Final Sync, da ist der genutzte RAM egal. aber Heavy I/O könnte das schon etwas verzögern. Ich empfehle auch immer schnelleres Netzwerk, da du bei 25G und 100G deutlich bessere Latenzen als bei 10G/40G hast.

 

[fiona]

Hallo zusammen,

ich bin auf Umwegen auf diesen Parameter gekommen, weil ich bei verschiedenen Migrationen festgestellt habe, dass der Default-Wert von 100ms Downtime (was in meinen Augen schon ziemlich lang ist), laut Output teilweise um mehr als 50% überschritten wurde. Entsprechend den Anmerkungen von fiona - vielen Dank für den Hinweis! - kann es auch schlicht daran liegen, dass die Netzwerkverbindung zu langsam ist. Da muss ich vielleicht noch ein wenig experimentieren (habe auch ein schnelleres Interface, doch da darüber der NFS-Traffic für den Shared Storage läuft, wollte ich das eigentlich nicht nutzen).

@Falk R.: Mir ist schon klar, dass 1ms eine arg heftige Einstellung ist. War aber auch nur als erster Versuch gedacht, um die Downtime mal unter 100ms zu bekommen. Ich dachte außerdem, dass die Migration dann abbricht, wenn der vorgegebene Wert nicht erreichbar ist und eine iterative Annäherung an den niedrigst möglichen Schwellwert notwendig ist.

Und ich halte es für einen ziemlich groben Bug, wenn die Vorgabe u.U. schlicht ignoriert wird! Wenn es in der Endphase der Migration (in mehreren Anläufen) nicht möglich ist, innerhalb der gesetzten maximalen Downtime die Migration abzuschliessen, erwarte ich eine Fehlermeldung mit einer recht genauen Angabe, wie groß die Downtime für eine erfolgreiche Migration voraussichtlich sein muss!
Bei mir ist es zum Glück "nur" mein privater Test-Cluster, aber spinnen wir den Faden doch mal weiter: Ein produktives System in einer VM mit 128GB RAM auf dem auch einiges los ist, irgendeiner wirft ein "qm migrate" an und dann ist das System plötzlich für mehr als 3s nicht erreichbar ...

Ja, da gibt es Verbesserungspotenzial. In manchen Situationen kann das Limit wichtig sein. Allerdings ist das Verhalten seit Ende 2012 so. Wenn wir es also ändern würden, wären bestimmt einige Nutzer*innen unglücklich, dass ihre Migrationen plötzlich nicht mehr funktionieren würden. Und in sehr vielen Fällen ist eine funktionierende Migration wichtiger als ein hartes Downtime-Limit.

Eine Lösung wäre die Option zu erweitern z.B. mit einem enforce-Parameter, mit dem es nicht mehr automatisch erhöht wird, z.B. migrate_downtime: 0.1,enforce=true. Dazu gerne einen Feature-Request aufmachen: https://bugzilla.proxmox.com/

Die Beschreibung vom Parameter ist momentan auch irreführend, dazu habe ich einen Patch geschickt.

 

[Jack1967]

Ja, da gibt es Verbesserungspotenzial. In manchen Situationen kann das Limit wichtig sein. Allerdings ist das Verhalten seit Ende 2012 so.

Nun, dann hat jemand bereits 2012 einen groben Fehler gemacht
Ein Limit ist nämlich immer wichtig, dass ergibt sich für mich aus der Begriffsdefinition. Etwas anderes sind unverbindliche Empfehlungen - wie die StVO hier in Thailand ...

Eine Lösung wäre die Option zu erweitern z.B. mit einem enforce-Parameter, mit dem es nicht mehr automatisch erhöht wird, z.B. migrate_downtime: 0.1,enforce=true. Dazu gerne einen Feature-Request aufmachen: https://bugzilla.proxmox.com/

Das wäre ein wenig, wie "das Pferd vom Schwanz her aufzäumen". Wie zuvor schon geschrieben, ist ein Limit ein Limit (auf gut Deutsch: ein Grenzwert). Und ein Grenzwert ist immer ein Maximum (oder ein Minimum, was hier aber nicht in Betracht kommt).
Wem das nicht gefällt und wer seine Migration grundsätzlich erfolgreich durchlaufen lassen möchte, egal wie lang die Downtime für den "final sync" ist, der kann mit einem zusätzlichen Parameter wie: mir_doch_egal_wie_lange_das_System_nicht_verfuegbar_ist=true - gern auch in einer prägnanten englischen Übersetzung - seine nicht vorhandene Präferenz kundtun.
Mir ist klar, dass das eine Änderung ist, die erst in einem zukünftigen Major-Release implementiert werden kann/wird, aber dementsprechend kann sie angekündigt und in den Releasenotes auch nochmal prägnant hervorgehoben werden. Einen Feature-Request aufzumachen, für eine Option, das vorgebenene (bzw. Default-)Limit auch einzuhalten, erscheint mir ziemlich schizophren - sorry!
Im übrigen habe ich das bereits als Bug an Ihre Firma gemeldet (Ticket#: 1633929) und wäre Ihnen sehr verbunden, wenn Sie das auch entsprechend als Bug behandeln würden! Und damit meine ich nicht eine entsprechende Änderung der Dokumentation oder die Emfehlung von Workarounds, die letztlich dann das Problem doch nicht lösen.

Die Beschreibung vom Parameter ist momentan auch irreführend, dazu habe ich einen Patch geschickt.

Es müsste darüberhinaus die Ausgabe von "qm help migrate" angepasst sowie die notwendigen Voraussetzungen "qm set ..." an allen notwendigen Stellen erwähnt werden!
(Bzw. sollte ein "qm set <VMID> --migrate_downtime <Wert>" gar nicht notwendig sein, sondern der Defaultwert muss als Default für alles VMs gesetzt sein, so dass der Parameter beim "qm migrate" akzeptiert wird.)

Viel Grüße nach Wien,
Jack

 

[fiona]

Im übrigen habe ich das bereits als Bug an Ihre Firma gemeldet (Ticket#: 1633929) und wäre Ihnen sehr verbunden, wenn Sie das auch entsprechend als Bug behandeln würden! Und damit meine ich nicht eine entsprechende Änderung der Dokumentation oder die Emfehlung von Workarounds, die letztlich dann das Problem doch nicht lösen.

Wie gesagt, wenn wir das Verhalten jetzt für alle ändern, sind Migrationen von anderen Leuten plötzlich kaputt. Das ist keine Lösung.

 

[Jack1967]

Wie gesagt, wenn wir das Verhalten jetzt für alle ändern, sind Migrationen von anderen Leuten plötzlich kaputt. Das ist keine Lösung.

Ich habe nicht gefordert, das Verhalten jetzt sofort einfach zu ändern, sondern eine angekündigte Korrektur für ein folgendes Major-Release vorzunehmen, die das Verhalten (wieder) an die Definition des Parameters anpasst.
Im übrigen dachte ich auch, dass die Migration dann nicht einfach kommentarlos abbrechen sollte, sondern da ja bekannt sein sollte, wieviel Downtime voraussichtlich mindestens für eine erfolgreiche Migration benötigt wird und dass könnte in der Fehlermeldung ja gleich mit angegeben werden - sprich die Migration "fällt zwar erstmal auf die Nase", sagt dem Anwender aber auch gleich, welche Downtime erforderlich ist.
Das ist in meinen Augen dann auch sauber, denn dann kann der Anwender/Admin auch eine valide Entscheidung treffen, ob diese Migration "online" überhaupt erfolgen kann/sollte oder er eine entsprechende Downtime für die Anwendung beantragen muss.


Viel Grüße nach Wien,
Jack

 

[fiona]

Ich habe nicht gefordert, das Verhalten jetzt sofort einfach zu ändern, sondern eine angekündigte Korrektur für ein folgendes Major-Release vorzunehmen, die das Verhalten (wieder) an die Definition des Parameters anpasst.

Ich meine selbst bei einem Major-Release wäre die Verhaltensänderung für viele Nutzer*innen problematisch. Man müsste zusätzlich das Default-Verhalten bei "auto-increase" belassen. Nicht alle wollen ein hartes Limit und erst rumprobieren müssen, was sie setzten müssen.

Wenn die Dokumentation nicht der Realität entspricht, gehört sie angepasst.

Das aktuelle Verhalten wurde 11 Jahre lang von niemanden beanstandet und das mit dem Auto-Increase wurde wohl gemacht, weil es ohne dem Probleme gab. Um nicht auf einen Major-Release warten zu müssen und weniger Kopfschmerzen für bestehende Nutzer*innen zu haben, wäre mMn eine zusätzliche enforce=true oder auto-increase=false die sinnvollere Lösung ist. Das können Leute setzen, die auch wirklich ein hartes Limit brauchen und nicht nur Best-Effort.

 

[Falk R.]

Ich habe nicht gefordert, das Verhalten jetzt sofort einfach zu ändern, sondern eine angekündigte Korrektur für ein folgendes Major-Release vorzunehmen, die das Verhalten (wieder) an die Definition des Parameters anpasst.
Im übrigen dachte ich auch, dass die Migration dann nicht einfach kommentarlos abbrechen sollte, sondern da ja bekannt sein sollte, wieviel Downtime voraussichtlich mindestens für eine erfolgreiche Migration benötigt wird und dass könnte in der Fehlermeldung ja gleich mit angegeben werden - sprich die Migration "fällt zwar erstmal auf die Nase", sagt dem Anwender aber auch gleich, welche Downtime erforderlich ist.
Das ist in meinen Augen dann auch sauber, denn dann kann der Anwender/Admin auch eine valide Entscheidung treffen, ob diese Migration "online" überhaupt erfolgen kann/sollte oder er eine entsprechende Downtime für die Anwendung beantragen muss.


Viel Grüße nach Wien,
Jack

Was hast du denn vor Proxmox genutzt? Meinst du bei vSphere oder HyperV läuft das anders?

 

[Jack1967]

So, ich hatte endlich Zeit, mit dem Parameter ein wenig zu experimentieren.
Die schlechten Nachrichten vornweg: "qm migrate" kennt den Parameter nicht. Und der Parameter hat im Prinzip keinerlei Wirkung.

root@pve1-03:~# qm set 129 --migrate_downtime 0.05
update VM 129: -migrate_downtime 0.05
root@pve1-03:~# qm migrate 129 pve1-02 --migration_network 192.168.2.0/24 --migration_type insecure --online true --migrate_downtime 0.06
Unknown option: migrate_downtime
400 unable to parse option
qm migrate <vmid> <target> [OPTIONS]
root@pve1-03:~# qm migrate 129 pve1-02 --migration_network 192.168.2.0/24 --migration_type insecure --online true
2024-05-10 18:04:31 use dedicated network address for sending migration traffic (192.168.2.132)
2024-05-10 18:04:31 starting migration of VM 129 to node 'pve1-02' (192.168.2.132)
2024-05-10 18:04:31 starting VM 129 on remote node 'pve1-02'
2024-05-10 18:04:33 start remote tunnel
2024-05-10 18:04:34 ssh tunnel ver 1
2024-05-10 18:04:34 starting online/live migration on tcp:192.168.2.132:60000
2024-05-10 18:04:34 set migration capabilities
2024-05-10 18:04:34 migration downtime limit: 50 ms
2024-05-10 18:04:34 migration cachesize: 512.0 MiB
2024-05-10 18:04:34 set migration parameters
2024-05-10 18:04:34 start migrate command to tcp:192.168.2.132:60000
2024-05-10 18:04:35 migration active, transferred 110.4 MiB of 4.0 GiB VM-state, 147.1 MiB/s
2024-05-10 18:04:36 migration active, transferred 224.1 MiB of 4.0 GiB VM-state, 149.6 MiB/s
...
2024-05-10 18:04:52 migration active, transferred 2.0 GiB of 4.0 GiB VM-state, 144.7 MiB/s
2024-05-10 18:04:53 migration active, transferred 2.1 GiB of 4.0 GiB VM-state, 133.6 MiB/s
2024-05-10 18:04:54 migration active, transferred 2.2 GiB of 4.0 GiB VM-state, 132.4 MiB/s
2024-05-10 18:04:55 average migration speed: 195.9 MiB/s - downtime 106 ms
2024-05-10 18:04:55 migration status: completed
2024-05-10 18:04:59 migration finished successfully (duration 00:00:28)

Aber es kommt noch schlimmer. Ich habe für die Migration dann ein schnelleres Interface genutzt (mehr als die doppelte Bandbreite). Es wäre also zu erwarten, dass die Migration dann mit geringerer Downtime durchläuft, doch nope:
root@pve1-03:~# qm migrate 129 pve1-02 --migration_network 192.168.4.0/24 --migration_type insecure --online true
2024-05-10 19:20:57 use dedicated network address for sending migration traffic (192.168.4.132)
2024-05-10 19:20:57 starting migration of VM 129 to node 'pve1-02' (192.168.4.132)
2024-05-10 19:20:57 starting VM 129 on remote node 'pve1-02'
2024-05-10 19:20:59 start remote tunnel
2024-05-10 19:21:00 ssh tunnel ver 1
2024-05-10 19:21:00 starting online/live migration on tcp:192.168.4.132:60000
2024-05-10 19:21:00 set migration capabilities
2024-05-10 19:21:00 migration downtime limit: 10 ms
2024-05-10 19:21:00 migration cachesize: 512.0 MiB
2024-05-10 19:21:00 set migration parameters
2024-05-10 19:21:00 start migrate command to tcp:192.168.4.132:60000
2024-05-10 19:21:01 migration active, transferred 281.3 MiB of 4.0 GiB VM-state, 379.9 MiB/s
2024-05-10 19:21:02 migration active, transferred 563.0 MiB of 4.0 GiB VM-state, 470.0 MiB/s
2024-05-10 19:21:03 migration active, transferred 844.3 MiB of 4.0 GiB VM-state, 672.1 MiB/s
2024-05-10 19:21:04 migration active, transferred 1.1 GiB of 4.0 GiB VM-state, 656.6 MiB/s
2024-05-10 19:21:05 migration active, transferred 1.4 GiB of 4.0 GiB VM-state, 598.2 MiB/s
2024-05-10 19:21:06 migration active, transferred 1.7 GiB of 4.0 GiB VM-state, 328.6 MiB/s
2024-05-10 19:21:07 migration active, transferred 1.9 GiB of 4.0 GiB VM-state, 372.7 MiB/s
2024-05-10 19:21:08 migration active, transferred 2.3 GiB of 4.0 GiB VM-state, 293.8 MiB/s
2024-05-10 19:21:09 average migration speed: 457.0 MiB/s - downtime 113 ms
2024-05-10 19:21:09 migration status: completed
2024-05-10 19:21:12 migration finished successfully (duration 00:00:15)

Es sieht irgendwie danach aus, als kommt da irgendwann der Punkt, wo das System sagt: "Und nun rüber mit dem Rest!" und das gesetzte Downtime-Limit keinerlei Bedeutung mehr hat

Übrigens, wenn ich den Quelltext von QemuMigrate.pm richtig verstehe, wird das vorgegebene Limit nicht eingehalten, obwohl es zuvor gar nicht (intern) erhöht wurde, denn dann müsste im Output irgendwas von "auto-increased downtime to continue migration" enthalten sein ...
Sieht also doch ganz stark nach einem Bug aus und nicht im QemuMigrate.pm, sondern irgendwo in den Serverprozessen, die die Migration tatsächlich durchführen.

Ein paar Tests blieben auch unter 100ms Downtime (wenn migrate_downtime <= 50ms gesetzt), aber das Verhalten ist in dieser Hinsicht völlig undeterministisch und insbesondere hat kein einziger Test das eingestellte Limit auch nur annähernd erreicht.

 

[Jack1967]

Gab es kürzlich ein Update beim Migration-Code?
Ich habe gerade auf meinem Proxmox-Cluster Updates eingespielt und musste dabei natürlich auch einige VMs hin- und herschieben und plötzlich sehen die Zeiten viel besser aus:
2024-05-10 23:11:02 average migration speed: 128.5 MiB/s - downtime 20 ms
2024-05-10 23:11:31 average migration speed: 114.7 MiB/s - downtime 36 ms
2024-05-10 23:12:04 average migration speed: 187.0 MiB/s - downtime 51 ms

Also so gefällt mir das (wenn nicht nur der Output "optimiert" wurde)

Allerdings:
root@pve1-03:~# qm migrate 129 pve1-02 --migration_network 192.168.4.0/24 --migration_type insecure --online true
2024-05-10 23:36:34 use dedicated network address for sending migration traffic (192.168.4.132)
2024-05-10 23:36:34 starting migration of VM 129 to node 'pve1-02' (192.168.4.132)
2024-05-10 23:36:34 starting VM 129 on remote node 'pve1-02'
2024-05-10 23:36:36 start remote tunnel
2024-05-10 23:36:37 ssh tunnel ver 1
2024-05-10 23:36:37 starting online/live migration on tcp:192.168.4.132:60000
2024-05-10 23:36:37 set migration capabilities
2024-05-10 23:36:37 migration downtime limit: 30 ms
...
2024-05-10 23:36:45 migration active, transferred 2.3 GiB of 4.0 GiB VM-state, 313.8 MiB/s
2024-05-10 23:36:46 average migration speed: 457.0 MiB/s - downtime 59 ms
2024-05-10 23:36:46 migration status: completed
2024-05-10 23:36:49 migration finished successfully (duration 00:00:15)

Vorgegebene Limits sind also nach wie vor nur unverbindliche Empfehlungen ...

 

[Falk R.]

Das sieht bei anderen Hypervisoren genauso aus. Wenn du insecure migrierst sollte das die Downtime ebenfalls reduzieren. Ich kenne kein System was da hart limitiert, denn du willst ja migrieren und im besten Fall konsistent.
Willst du da optimieren, nutz lieber low latency Netzwerke wie 25 GBit oder 50 GBit, natürlich geht auch 100/200/400 GBit.

 

[Jack1967]

Das sieht bei anderen Hypervisoren genauso aus. Wenn du insecure migrierst sollte das die Downtime ebenfalls reduzieren. Ich kenne kein System was da hart limitiert, denn du willst ja migrieren und im besten Fall konsistent.

Wie andere Hypervisoren das behandeln, weiß ich nicht (VMware behauptet ja "Zero Downtime", was natürlich Unsinn ist) und es wäre mir bei Proxmox auch nicht aufgefallen, wenn es da nicht so prominent im Output stehen würde.
Aber ich bleibe dabei, wenn es ein Limit gibt, muss dieses auch eingehalten werden und dies um so mehr, als bei den Migrationen noch nicht einmal der Fall eingetreten ist, dass das Downtime-Limit von dem Programm, welches die Migration initiiert und überwacht, wie von Fiona beschrieben, erhöht wurde. Ich werde dafür also mal einen Bug-Report aufmachen.

Willst du da optimieren, nutz lieber low latency Netzwerke wie 25 GBit oder 50 GBit, natürlich geht auch 100/200/400 GBit.

Wäre eine Variante, ist aber für den Heimgebrauch dann wohl doch etwas übertrieben ...

 

[Falk R.]

Wäre eine Variante, ist aber für den Heimgebrauch dann wohl doch etwas übertrieben ...

Im Heimgebrauch merkt deine Anwendung eh nix davon. Viele Programme tollerieren bis zu 30 Sekunden und theoretisch manche auch 60 Sekunden. Das Zero bei VMware ist sehr ähnlich zu den Latenzen von Proxmox. Es gibt nur wenige Anwendungen die auf eine Migration reagieren. Das sind in der Regel Echtzeitdatenbanken mit viel Durchsatz oder schlecht programmierte Software.
Sei froh, dass Proxmox dir wenigstens mitteilt wie hoch die Latenz ist. Die meisten Hypervisoren verschweigen das Thema komplett.

 

[Jack1967]

Sei froh, dass Proxmox dir wenigstens mitteilt wie hoch die Latenz ist. Die meisten Hypervisoren verschweigen das Thema komplett.

Korrekt, deswegen kann man denen auch keine "auf die Mütze hauen".
Aber wenn explizit gesagt wird: "Es gibt ein Limit von 100ms", dann kann das System nicht sozusagen im nächsten Atemzug sagen: "Aber das ist mir schei... egal!"
Und ich wiederhole nochmal: Das Limit wurde vom Steuerungsprogramm nicht erhöht, damit die Migration erfolgreich abgeschlossen werden kann, sondern es wurde schlicht ignoriert.

 

[Falk R.]

Was mich auch nicht wundern würde, wenn der Wert vom QEMU Projekt schon mal aufgenommen wurde und erst in zukünftigen Releases ausgewertet wird. Hast du mal in der Offiziellen QEMU Dokumentation gesucht, ob es zu dem Thema etwas brauchbares gibt?

 

[fiona]

Gab es kürzlich ein Update beim Migration-Code?

Nein.

Vorgegebene Limits sind also nach wie vor nur unverbindliche Empfehlungen ...

Je nachdem wie das Netzwerk/Load im Gast ist, wie der geschätzte Durchsatz anhand der bisherigen Migration ist, kann das Limit, das bei QEMU gesetzt wurde, halt auch nicht eingehalten werden: https://gitlab.com/qemu-project/qemu/-/blob/master/migration/migration.h#L294

Wenn die Downtime so minimal sein soll, brauchst Du vermutlich etwas wie: https://wiki.qemu.org/Features/COLO