Live-Migration eines KVM-Gasts mit seinem Storage, Schritt für Schritt

Eine laufende virtuelle Maschine ohne gemeinsamen Storage zwischen Hosts zu verschieben klingt nach Zauberei, bis man es ein paar Mal gemacht hat. Dann ist es eine Checkliste: bestätigen, dass die Hosts kompatibel sind, das Ziel so vorbereiten, dass der Gast alles vorfindet, was er erwartet, einen Befehl ausführen, und wissen, wann man es nicht versuchen sollte. Hier ist diese Checkliste für reines KVM mit libvirt.

Was bei einer Live-Migration tatsächlich passiert

Mit --copy-storage-all bittet libvirt QEMU auf dem Ziel, den Gast anzulegen, und streamt dann die Platte hinüber, während der Gast weiterläuft und schreibt. Sobald die Platte gespiegelt ist, wird der Arbeitsspeicher in Runden kopiert: Jede Runde sendet die Seiten, die der Gast während der vorherigen verändert hat. Wenn die verbleibende Menge veränderter Seiten klein genug ist, um innerhalb der erlaubten Ausfallzeit gesendet zu werden, wird der Gast pausiert, die letzten Seiten und der Gerätezustand gehen hinüber, und er läuft auf dem Ziel weiter. Die Pause beträgt üblicherweise einige hundert Millisekunden. Netzwerkverbindungen überleben, weil der Gast seine MAC- und IP-Adresse behält und der Switch den neuen Standort aus den ersten Paketen des Gasts lernt.

Alles, was schiefgehen kann, ist eine Diskrepanz zwischen dem, was der Gast erwartet, und dem, was das Ziel bietet. Prüfen Sie das also zuerst.

Schritt eins: live oder cold entscheiden

Live-Migration ist das richtige Werkzeug, wenn Quelle und Ziel kompatibel sind und die Schreibrate des Gasts moderat ist. Sie ist das falsche Werkzeug, wenn sich alles auf einmal ändert: eine andere CPU-Generation, ein anderes Netzwerk-Layout und ein anderes Hypervisor-Release im selben Umzug. Dann ist der sichere Weg cold: den Gast sauber herunterfahren, die Platte kopieren, ihn auf dem Ziel definieren, starten, und die Quelle als Rollback unangetastet lassen.

Ein Datenbank-Primary mit sehr hoher Rate veränderter Seiten konvergiert möglicherweise auch nie. Messen Sie, bevor Sie es versuchen:

virsh domdirtyrate-calc <guest> --seconds 5
virsh domstats <guest> --dirtyrate

Schritt zwei: CPU-Kompatibilität prüfen

Das CPU-Modell des Gasts muss auf dem Ziel existieren. Wenn der Gast host-passthrough verwendet, müssen die CPUs der beiden Hosts praktisch übereinstimmen. Vergleichen Sie die Definition des Gasts mit dem Zielhost:

virsh dumpxml <guest> > guest.xml                       # on the source
xmllint --xpath '//cpu' guest.xml > guest-cpu.xml
virsh hypervisor-cpu-compare guest-cpu.xml              # on the destination

identical oder superset heißt: los. incompatible heißt entweder, den Gast auf ein benanntes CPU-Modell umzustellen, das beide Hosts unterstützen (bei seinem nächsten Neustart), oder ihn cold zu verschieben.

Schritt drei: das Zielnetzwerk vorbereiten

Jede Bridge, oder jedes VLAN auf einer Bridge, an die die Schnittstellen des Gasts angebunden sind, muss auf dem Ziel mit demselben Namen existieren und dieselben VLANs auf dem Uplink führen:

virsh domiflist <guest>      # on the source: which bridges
ip -br link show type bridge # on the destination: do they exist?

Eine fehlende Bridge lässt die Migration gleich am Anfang sauber scheitern. Eine Bridge, die existiert, aber auf einem Uplink ohne das VLAN sitzt, migriert erfolgreich und lässt den Gast unerreichbar zurück, was schlimmer ist. Prüfen Sie auch die Switch-Seite.

Schritt vier: den Ziel-Storage vorbereiten

Das Ziel braucht einen Ort, an dem die Platte landen kann, unter einem Pfad, den libvirt als Storage-Pool verwaltet:

virsh pool-define-as images dir --target /var/lib/libvirt/images
virsh pool-start images && virsh pool-autostart images

Für die meisten Layouts legt libvirt das Ziel-Image selbst an. Für ungewöhnliche legen Sie es vorab an, mit genau derselben virtuellen Größe und demselben Format wie die Quelle:

qemu-img info --output=json /var/lib/libvirt/images/<guest>.qcow2   # note virtual-size
qemu-img create -f qcow2 /var/lib/libvirt/images/<guest>.qcow2 <virtual-size>

Schritt fünf: migrieren

Vom Quellhost aus, mit SSH-Schlüsselzugang zum Ziel als libvirt-Benutzer:

virsh migrate --live --persistent --undefinesource \
  --copy-storage-all --auto-converge --verbose \
  <guest> qemu+ssh://<destination>/system

• --live hält den Gast am Laufen.
• --copy-storage-all spiegelt die gesamte Platte. (--copy-storage-inc existiert für Platten, deren Basis-Image bereits auf dem Ziel liegt.)
• --auto-converge drosselt die CPU des Gasts leicht, wenn der Arbeitsspeicher schneller verändert wird, als er gesendet werden kann, damit auch beschäftigte Gäste fertig werden.
• --persistent und --undefinesource nehmen die Definition mit dem Gast mit, damit er beim nächsten Neustart nicht wieder auf dem alten Host auftaucht.

Wir verwenden den direkten Migrationspfad statt --tunnelled, wenn Storage kopiert wird. Beobachten Sie währenddessen den Fortschritt in einem zweiten Terminal:

virsh domjobinfo <guest>

domjobinfo zeigt verbleibende Daten, die Rate veränderter Seiten und die erwartete Ausfallzeit. Wenn es offensichtlich nicht konvergiert, stoppt virsh domjobabort <guest> den Job und lässt den Gast auf der Quelle weiterlaufen, unangetastet.

Schritt sechs: bei Ankunft verifizieren

Prüfen Sie, von außerhalb des Gasts:

virsh list --all                      # running on the destination only
virsh domblklist <guest>              # disk at the expected path
virsh domifaddr <guest> --source arp  # address visible on the network

Wenn der Gast ein Load Balancer oder ein Datenbank-Replikat ist, bestätigen Sie, dass er seine Rolle wieder aufgenommen hat (VRRP-Zustand, Replikations-Threads), statt es anzunehmen.

Erst danach entfernen Sie das alte Platten-Image von der Quelle, oder besser: Behalten Sie es bis zum nächsten Wartungszyklus.

Ihre Checkliste

• Live oder cold bewusst entschieden, mit gemessener Rate veränderter Seiten bei beschäftigten Gästen.
• CPU-Modell mit dem Zielhost verglichen.
• Jede Bridge und jedes VLAN auf dem Ziel vorhanden, einschließlich der Switch-Uplinks.
• Ein Storage-Pool auf dem Ziel, genug freier Platz, und ein vorab angelegtes Image, wo das Layout eines braucht.
• Der Migrationsbefehl mit Storage-Kopie und Auto-Converge ausgeführt, mit domjobinfo beobachtet.
• Der Gast von außen verifiziert, und die Quellkopie behalten, bis Sie sicher sind.

Wenn Sie Gäste verschieben möchten, ohne sie herunterzufahren, oder einen Weg weg von Ihrem aktuellen Hypervisor brauchen, helfen wir gern.

CTA

Mit einem Ingenieur sprechen

Related

Verwandt: Live-Migration und Hypervisor-Ausstieg · Private Cloud auf KVM mit OLVM · Zu uns wechseln ohne Umnummerierung: Layer-2-Erweiterung