Proxmox Virtual Environment bietet seit der letzten Version ein neues Feature: Cross-Cluster-Migration. Das ist aktuell im Zustand "experimentell" eingestuft. Ich habe das mal erfolgreich getestet. Ein Feature auf das ich lange gewartet habe! Das ist ein Feature, das z. B. XCP-NG Proxmox immer voraus hatte.
Was macht das?
Normalerweise kann man die Live-Migration von Proxmox nur innerhalb eines Clusters verwenden. Mit dieser Funktionalität geht das auch Cluster-übergreifend.
Wie geht das?
Die Doku ist in der Manpage zu qm. Der Unter-Befehl ist qm remote-migrate. Siehe z. B. hier: https://pve.proxmox.com/pve-docs/qm.1.html Hier ist auch noch die Ankündigung mit einem Beispiel auf der PVE-Devel-Liste: https://lists.proxmox.com/pipermail/pve ... 54156.html
Das Befehlsgerüst zur Ausführung auf dem Quell-VM-Host:
Code: Alles auswählen
qm remote-migrate ${local_vmid} ${remote_vmid} \
'host=${remote_host_or_ip},apitoken=PVEAPIToken=${token}=${token_secret},fingerprint=${fingerprint}' \
--target-bridge=${bridge} --target-storage ${local_storage}:${remote_storage} --online- ${local_vmid} : Die VMID auf dem Quellserver, eine 3- oder 4-stellige Zahl, z. B. 191
- ${remote_vmid}: Die VMID auf dem Zielserver. Die ID darf natürlich auf dem Zielserver noch nicht belegt sein. z. B. 191
- ${remote_host_or_ip}: Die IP-Adresse oder der voll qualifizierte Hostname des Zielsystems, z. B. pvetarget.dom.tld
- ${token}: Ein gültiger Tokenname. z. B. meinusername@pam!meintokenname
- ${token_secret}: Das zum Token zugehörige Tokenpasswort. Dieses wird nur beim anlegen einmal gezeigt. Ansonsten ist es nicht mehr sichtbar. z. B. : 444a7f17-41a5-4114-1140-f1a44410f714.
- ${fingerprint}: Der Zertifikats-Fingerprint des Zielservers, wie man diesen auf dem Zielserver mittels ... ... anzeigen lassen kann (Wichtig: Paket
Code: Alles auswählen
pvenode cert info --output-format json | jq -r '.[2]["fingerprint"]'
jq vorher installieren.). z. B. A9:53:31:55:90:52:54:B4:A4:42:31:53:44:45:35:AB:09:B9:A2:19:CC:C3:54:11:93:94:45:B4:94:BC:9A:41. - ${bridge}: Die Bridge, die auf dem Zielhost der Netzwerkschnittstelle zugewiesen werden soll. z. B. vmbr0
- ${local_storage} / ${remote_storage}: Das lokale und entfernte Storage, in der VM-Daten gespeichert werden. z. B. local für beide Werte.
- --online: Der Schalter, damit eine VM im hochgefahrenen Zustand migriert wird, d. h. mit Downtime im Millisekundenbereich.
Hier ist natürlich ein sehr einfacher Fall skizziert: Nur ein Storage und eine Netzwerk-Bridge. Im konkreten Fall müssen da evtl. noch einige Storages/Bridges mehr angegeben werden.
Zum Thema API-Token
API-Tokens legt man in der WebGUI (Unter Datacenter -> Permissions -> APITokens) oder mit einem der CLI-Tools an. Wenn man dabei die Privilege-Separation Option aktiviert - das ist empfohlen und per Vorgabe aktiviert, hat das Token keinerlei Rechte. Diese muss man dem Token für die Migration noch zuweisen (Unter Datacenter -> Permissions -> Add).
Der komplette Befehl mit den ausgefüllten Beispielwerten - Werte zwecks besserer Lesbarkeit teilweise in Variablen ausgelagert - lautet also:
Code: Alles auswählen
token="meinusername@pam!meintokenname"
token_secret="444a7f17-41a5-4114-1140-f1a44410f714"
fingerprint="A9:53:31:55:90:52:54:B4:A4:42:31:53:44:45:35:AB:09:B9:A2:19:CC:C3:54:11:93:94:45:B4:94:BC:9A:41"
qm remote-migrate 191 191 \
'host=pvetarget.dom.tld,apitoken=PVEAPIToken='"$token"'='"$token_secret"',fingerprint='"$fingerprint" \
--target-bridge=vmbr0 --target-storage local:local --onlineCode: Alles auswählen
# qm remote-migrate 191 191 \
'host=pvetarget.dom.tld,apitoken=PVEAPIToken=meinusername@pam!meintokenname=444a7f17-41a5-4114-1140-f1a44410f714,fingerprint=A9:53:31:55:90:52:54:B4:A4:42:31:53:44:45:35:AB:09:B9:A2:19:CC:C3:54:11:93:94:45:B4:94:BC:9A:41' \
--target-bridge=vmbr0 --target-storage local:local --online
Establishing API connection with remote at 'pvetarget.dom.tld'
2023-03-21 17:55:35 remote: started tunnel worker 'UPID:pvetarget:0006278B:0012A6EC:6419E187:qmtunnel:191:meinusername@pam!meintokenname:'
tunnel: -> sending command "version" to remote
tunnel: <- got reply
2023-03-21 17:55:35 local WS tunnel version: 2
2023-03-21 17:55:35 remote WS tunnel version: 2
2023-03-21 17:55:35 minimum required WS tunnel version: 2
websocket tunnel started
2023-03-21 17:55:35 starting migration of VM 191 to node 'pvetarget' (pvetarget.dom.tld)
tunnel: -> sending command "bwlimit" to remote
tunnel: <- got reply
2023-03-21 17:55:35 found local disk 'local:191/vm-191-disk-0.qcow2' (in current VM config)
2023-03-21 17:55:35 mapped: net0 from vmbr0 to vmbr0
2023-03-21 17:55:35 Allocating volume for drive 'scsi0' on remote storage 'local'..
tunnel: -> sending command "disk" to remote
tunnel: <- got reply
2023-03-21 17:55:36 volume 'local:191/vm-191-disk-0.qcow2' is 'local:191/vm-191-disk-0.qcow2' on the target
tunnel: -> sending command "config" to remote
tunnel: <- got reply
tunnel: -> sending command "start" to remote
tunnel: <- got reply
2023-03-21 17:55:38 Setting up tunnel for '/run/qemu-server/191.migrate'
2023-03-21 17:55:38 Setting up tunnel for '/run/qemu-server/191_nbd.migrate'
2023-03-21 17:55:38 starting storage migration
2023-03-21 17:55:38 scsi0: start migration to nbd:unix:/run/qemu-server/191_nbd.migrate:exportname=drive-scsi0
drive mirror is starting for drive-scsi0 with bandwidth limit: 71680 KB/s
tunnel: accepted new connection on '/run/qemu-server/191_nbd.migrate'
tunnel: requesting WS ticket via tunnel
tunnel: established new WS for forwarding '/run/qemu-server/191_nbd.migrate'
drive-scsi0: transferred 130.0 MiB of 27.7 GiB (0.46%) in 1s
drive-scsi0: transferred 528.0 MiB of 27.7 GiB (1.86%) in 2s
drive-scsi0: transferred 587.0 MiB of 27.7 GiB (2.07%) in 3s
drive-scsi0: transferred 715.0 MiB of 27.7 GiB (2.52%) in 4s
...
drive-scsi0: transferred 27.6 GiB of 27.7 GiB (99.57%) in 9m 25s
drive-scsi0: transferred 27.7 GiB of 27.7 GiB (99.65%) in 9m 27s
drive-scsi0: transferred 27.7 GiB of 27.7 GiB (99.70%) in 9m 28s
drive-scsi0: transferred 27.7 GiB of 27.7 GiB (99.76%) in 9m 29s
drive-scsi0: transferred 27.7 GiB of 27.7 GiB (99.83%) in 9m 30s
drive-scsi0: transferred 27.7 GiB of 27.7 GiB (100.00%) in 9m 31s, ready
all 'mirror' jobs are ready
2023-03-21 18:05:09 starting online/live migration on unix:/run/qemu-server/191.migrate
2023-03-21 18:05:09 set migration capabilities
tunnel: -> sending command "bwlimit" to remote
tunnel: <- got reply
2023-03-21 18:05:09 migration speed limit: 70.0 MiB/s
2023-03-21 18:05:09 migration downtime limit: 100 ms
2023-03-21 18:05:09 migration cachesize: 1.0 GiB
2023-03-21 18:05:09 set migration parameters
2023-03-21 18:05:09 start migrate command to unix:/run/qemu-server/191.migrate
tunnel: accepted new connection on '/run/qemu-server/191.migrate'
tunnel: requesting WS ticket via tunnel
tunnel: established new WS for forwarding '/run/qemu-server/191.migrate'
2023-03-21 18:05:10 migration active, transferred 71.5 MiB of 5.9 GiB VM-state, 84.7 MiB/s
2023-03-21 18:05:11 migration active, transferred 142.0 MiB of 5.9 GiB VM-state, 81.1 MiB/s
2023-03-21 18:05:12 migration active, transferred 214.1 MiB of 5.9 GiB VM-state, 84.5 MiB/s
2023-03-21 18:05:13 migration active, transferred 285.6 MiB of 5.9 GiB VM-state, 78.3 MiB/s
...
2023-03-21 18:06:18 migration active, transferred 4.7 GiB of 5.9 GiB VM-state, 78.6 MiB/s
2023-03-21 18:06:19 migration active, transferred 4.8 GiB of 5.9 GiB VM-state, 69.9 MiB/s
2023-03-21 18:06:20 migration active, transferred 4.9 GiB of 5.9 GiB VM-state, 69.9 MiB/s
tunnel: done handling forwarded connection from '/run/qemu-server/191.migrate'
2023-03-21 18:06:22 average migration speed: 82.4 MiB/s - downtime 88 ms
2023-03-21 18:06:22 migration status: completed
all 'mirror' jobs are ready
drive-scsi0: Completing block job_id...
drive-scsi0: Completed successfully.
tunnel: done handling forwarded connection from '/run/qemu-server/191_nbd.migrate'
drive-scsi0: mirror-job finished
2023-03-21 18:06:23 stopping NBD storage migration server on target.
tunnel: -> sending command "nbdstop" to remote
tunnel: <- got reply
tunnel: -> sending command "resume" to remote
tunnel: <- got reply
tunnel: -> sending command "unlock" to remote
tunnel: <- got reply
tunnel: -> sending command "quit" to remote
tunnel: <- got reply
2023-03-21 18:06:25 migration finished successfully (duration 00:10:50)
Ich habe hier eine vorhandene Ausgabe auf die verwendeten Beispieldaten hin abgeändert. Kann sein, dass ich da noch nicht alles erwischt habe.
Zur Erinnerung: Das ist noch experimentell. Fehler bei den ein oder anderen verschiedenen Speicher-Technologien(LVM-Thin, ZFS, Whatever, ...) wären also nichts ungewöhnliches.
Fehler, die mir unterlaufen sind
- Fehlermeldung 401 No Ticket Ursache: Das Token war nicht korrekt aufgebaut.
- Fehlermeldung fingerprint '69:53...' not verified, abort! Ursache: Ich habe den falschen Fingerprint vom Zielserver verwendet. Den von der CA, nicht den vom Server. Der Befehl pvenode cert info liefert 2 Fingerprints und der von der CA steht als erstes da.
