Migracja na żywo w Proxmox VE
(odpowiednik vMotion)

vMotion vs qm migrate

W panelu PVE: VM → Migrate → „Online”. Z CLI:

qm migrate <vmid> <target> --online

Flaga --online jest ignorowana, gdy VM stoi. Domyślny zakres vmid w man qm to 100–999999999. To nie jest produkt „vMotion” — to live migration QEMU/KVM, którą vSphere opakowuje inną marką.

W GUI widać pasek iteracji pamięci: QEMU kopiuje brudne strony, aż delta zmieści się w oknie przełączenia. Im więcej zapisu w gościu, tym dłużej trwa „ostatnia” iteracja. Dlatego sieć migracji i limit --bwlimit są częścią projektu, nie ozdobą CLI. Maszyna z ogromnym cache bazy na lokalnym ZFS bez shared storage będzie wędrować minutami — to nie awaria, to kopia wolumenu.

Shared storage i dyski lokalne

Podręcznik pvesm: na storage współdzielonym (NFS, RBD, iSCSI) węzły widzą ten sam obraz, więc live migration jest szybka — bez kopii dysku. Na ZFS/LVM-thin lokalnym włączasz --with-local-disks (live storage migration). --targetstorage mapuje źródło na cel; wartość 1 mapuje każdy storage na siebie.

--force pozwala migrować VM z urządzeniami lokalnymi (np. passthrough). Tylko root. Bez tego zadanie się wyłoży na local device.

Sieć, szyfrowanie, limity

• --migration_network — CIDR sieci używanej do migracji.
• --migration_type — domyślnie ruch idzie tunelem SSH (szyfrowany). Na całkowicie prywatnej sieci można wyłączyć dla wydajności.
• --bwlimit — limit KiB/s; domyślnie z datacenter albo storage.
• --with-conntrack-state — czy migrować wpisy conntrack (domyślnie 0).

Sieć migracji oddzielamy od Corosync i od Ceph. Zatkanie linku klastra live migration’em to klasyczny sposób na utratę kworum w trakcie „niewinnego” vMotion.

Typ CPU i kompatybilność

Live migration wymaga, by cel umiał wykonać ten sam model vCPU. Typ host przykleja flagi fizycznego CPU — między różnymi generacjami Intel/AMD migracja pada. Bezpieczniejszy wspólny mianownik: x86-64-v2 / x86-64-v3 albo jawny model QEMU. Szczegóły: Wybór typu CPU w Proxmox.

Kontenery, HA i load balancer

Działającego LXC nie zmigrujesz na żywo — PVE robi migrację z restartem. HA klastra to inny mechanizm: po fencingu gość startuje na innym węźle (wymaga kworum i dostępnego dysku). Dynamic Load Balancer w PVE 9.2 sam odpala live migration, by wyrównać CPU/RAM — z poszanowaniem affinity. To odpowiednik DRS, nie vMotion w izolacji.

Odpowiednik Storage vMotion to właśnie --with-local-disks / zmiana --targetstorage przy włączonej VM. Odpowiednik vMotion sieciowego (zmiana portgroup w locie) to zmiana mostka/VLAN w konfiguracji — nie zawsze bez krótkiej utraty linku; nie obiecujemy „zero” tam, gdzie QEMU musi przepiąć NIC.

Co psuje migrację na żywo

• Passthrough PCI/USB i lokalne urządzenia bez --force (tylko root) — zadanie pada na local device.
• Typ CPU host między różnymi generacjami Intel/AMD — cel nie umie wykonać tych samych flag.
• LXC: brak live migrate; PVE robi migrację z restartem. To nie jest vMotion kontenera.
• Shared storage + wspólny mianownik CPU (x86-64-v2 / x86-64-v3) + osobny CIDR migracji — to jest ścieżka, którą projektujemy jako domyślną.

Dynamic Load Balancer w PVE 9.2 sam odpala live migration z poszanowaniem affinity — to odpowiednik DRS, nie osobny produkt. HA nadal jest innym mechanizmem (restart po fencingu). Kworum: klaster i quorum.

Datacenter: sieć i typ migracji

Man qm: --migration_type domyślnie idzie tunelem SSH (szyfrowany). Na całkowicie prywatnej sieci da się przełączyć dla wydajności — to decyzja ryzyka, nie „zawsze wyłączamy”. --bwlimit w KiB/s bierze domyślną wartość z datacenter albo storage. --with-conntrack-state domyślnie 0. --targetstorage 1 mapuje każdy storage na siebie.

Offline, HA i kolejność w projekcie

Migracja offline (VM wyłączona) kopiuje dysk bez iteracji pamięci — to zwykły transfer wolumenu. --online jest wtedy ignorowane (man qm). HA to nadal inny mechanizm: po fencingu gość startuje na innym węźle, jeśli kworum jest i dysk tam widać. Live migration nie zastępuje HA, HA nie zastępuje live migration.

W projekcie kolejność jest stała: najpierw wspólny mianownik CPU i osobny CIDR migracji, potem shared storage albo świadoma kopia lokalnych dysków, na końcu Dynamic Load Balancer. Affinity i tryb konserwacji HA są w osobnych artykułach — nie mieszamy ich z paskiem vMotion w GUI.