Збій живої міграції Proxmox: що перевірити для мережі, прапорців CPU та сховища

Швидкий план діагностики (що перевірити спочатку)

Збої живої міграції здаються випадковими, бо вони можуть статися на різних етапах: попередні перевірки, встановлення каналу міграції, передкопіювання ОЗП, переключення stop-and-copy та прибирання після міграції. Ваше завдання — швидко знайти фазу і вузьке місце.

По-перше: ідентифікуйте фазу й реальну помилку (не те, що каже UI)

• Перевірте лог задачі в UI, потім одразу дивіться журнали journal на обох вузлах.
• Рішення: Якщо ви не бачите конкретної помилки протягом 2 хвилин, ви читаєте не той лог.

По-друге: підтвердіть наявність робочого шляху мережі для міграції

• Перевірте зв’язність між вузлами за фактичними IP, що використовуються для міграції (не «управління», не «якийсь ping»).
• Перевірте MTU, втрати пакетів, затримку та правила брандмауера.
• Рішення: Якщо є невідповідність MTU або періодичні втрати, виправляйте мережу перед налаштуванням Proxmox. Міграція — це довготривала високопропускна передача; вона знайде кожну слабкість.

По-третє: підтвердіть сумісність моделі CPU та узгодженість типу QEMU-машини

• Порівняйте налаштування CPU VM із прапорцями CPU хоста.
• Рішення: Якщо CPU встановлено як host і вузли не ідентичні, зупиніться. Встановіть сумісну модель CPU (наприклад, x86-64-v2/v3) і протестуйте знову.

По-четверте: підтвердіть припущення щодо сховища (спільне проти локального і що має рухатися)

• Чи диск на спільному сховищі? Якщо ні — чи ввімкнено «with local disks» і чи є пропускна здатність і місце?
• Рішення: Якщо диск VM локальний і великий, жива міграція може «працювати», але фактично бути неможливою у вашому вікні. Плануйте холодну міграцію або реплікацію.

По-п’яте: перевірте здоров’я кластера та синхронізацію часу

• Corosync і кворум можуть блокувати операції, а дрейф часу створює дивні TLS та автентифікаційні симптоми.
• Рішення: Якщо кластер не здоровий, не робіть міграцію першим кроком. Це фіча, що передбачає стабільну основу.

Операційна істина: коли міграція падає, найшвидші перемоги дає перевірка мережевого шляху й припущень про модель CPU. Сховище зазвичай повільніше «горить», а не викликає миттєвий «connection closed».

Цікаві факти та контекст (чому це відбувається в реальному житті)

1. Жива міграція існувала задовго до більшості «хмарних» брендингів. Практична жива міграція віртуальних машин була темою досліджень на початку 2000-х; підхід pre-copy став стандартом, бо мінімізує час відключення шляхом ітераційного копіювання «брудних» сторінок пам’яті.
2. QEMU-міграція — це протокол, а не чарівництво. Воно стримує стан VM (сторінки RAM, стан CPU, стан пристроїв) через канал, який поводиться як будь-яке інше тривале з’єднання: втрата, проблеми з MTU чи брандмауер можуть його вбити.
3. «Сумісність CPU» — це контрактна обіцянка. Якщо CPU призначення не підтримує інструкцію, якою користувалась VM, QEMU не може безпечно відновити VM. Саме тому існують моделі CPU — щоб обіцяти менше і переміщувати більше.
4. Флаги Intel і AMD — це не лише маркетинг. Такі речі, як AVX/AVX2, AES-NI і розширення віртуалізації, з’являються як прапорці; невідповідність може блокувати міграцію, якщо модель CPU занадто специфічна.
5. Тип машини має значення. QEMU «machine types» (наприклад, i440fx vs q35 і версійні варіанти) визначають чіпсет і моделі пристроїв. Невідповідності можуть зламати міграцію, навіть коли CPU виглядають сумісними.
6. Невідповідність MTU — тихий вбивця потоків великої пропускної здатності. ICMP ping може проходити, тоді як великі пакети фрагментуються або губляться; трафік міграції великий і стійкий, тож він швидко виявляє проблему.
7. Ceph робить міграцію одночасно простішою й складнішою. Простішою, бо диски спільні; складнішою, бо якщо мережа Ceph хворіє, міграція стає непередбачуваним тестом навантаження.
8. Компресія та postcopy існують, бо pre-copy має межі. Якщо VM «забруднює» пам’ять швидше, ніж можна її скопіювати (наприклад, гарячі бази даних), pre-copy може зациклитися, доки не спливе тайм-аут або не буде примусове простої вимкнення.
9. Corosync — не канал передачі даних міграції. Corosync — це кластерне повідомлення і кворум; міграція використовує окремі канали (SSH-орchestration та сокети QEMU). Але зламаний кластер усе одно може блокувати операції.

Ментальна модель: що насправді робить «жива міграція»

Уявіть живу міграцію як два паралельні робочі потоки:

• План керування: Proxmox координує переїзд: перевіряє готовність цільового вузла, блокує VM, налаштовує тунелі/порти, запускає процес QEMU на приймаючому вузлі в режимі «incoming», а потім просить QEMU джерела мігрувати.
• План даних: QEMU передає стан виконання VM: сторінки пам’яті, стан vCPU, стан пристроїв. Стан диска передається тільки якщо ви явно мігруєте локальні диски (або робите storage migration). При спільному сховищі диски лишаються на місці; VM просто вказує на той самий блочний пристрій на іншому вузлі.

Більшість «таємничих» збоїв — це одне з наступного:

• Зриви зв’язності та переговорів (SSH, брандмауер, невірний IP, MTU, TLS/сертифікати, розв’язування імен).
• Помилки сумісності (модель CPU, прапорці, тип машини, розбіжності моделей пристроїв, відмінності прошивок/UEFI).
• Проблеми пропускної здатності/затримки (міграція не встигає; pre-copy не сходиться; storage migration зависає; VM «забруднює» ОЗП занадто швидко).
• Операційні обмеження (кластер без кворуму, на цільовому вузлі немає сховища, нестача пам’яті, HA-обмеження або зафіксовані ресурси).

Тепер ми діагностуватимемо це конкретними завданнями.

Практичні перевірки (команди, виводи, рішення)

Вам потрібні команди, які відповідають на одне питання кожна. Запускайте їх на джерелі і цілі, якщо не зазначено інакше. Не «виправляйте» нічого, поки не зможете пояснити збій одним реченням.

Завдання 1: Ідентифікуйте причину збою міграції в системних логах

cr0x@server:~$ journalctl -u pvedaemon -u pveproxy -u pvestatd -u pve-cluster --since "30 min ago" | tail -n 80
Dec 26 10:12:09 pve1 pvedaemon[2461]: VM 113 qmp command failed - unable to connect to VM 113 qmp socket
Dec 26 10:12:10 pve1 pvedaemon[2461]: start migration failed: command '/usr/bin/ssh -e none -o 'BatchMode=yes' root@10.10.10.12 ...' failed: exit code 255
Dec 26 10:12:10 pve1 pvedaemon[2461]: migration aborted (duration 00:00:03): can't connect to destination

Що це означає: Це збій плану керування. Exit code 255 від SSH зазвичай означає проблеми з автентифікацією/хост-ключами/брандмауером/маршрутом, а не сумісність QEMU.

Рішення: Перестаньте шукати CPU/сховище. Виправте SSH і зв’язність вузел-вузел перш ніж робити інші кроки.

Завдання 2: Перевірте конфігурацію виділеної мережі для міграції в Proxmox

cr0x@server:~$ cat /etc/pve/datacenter.cfg
keyboard: en-us
migration: secure,network=10.10.10.0/24

Що це означає: Proxmox віддасть перевагу 10.10.10.0/24 для трафіку міграції. Якщо ця мережа поламана або неправильно маршрутизована між вузлами, міграція не вдасться або буде тягнутися.

Рішення: Переконайтеся, що кожен вузол має стабільний IP в цій підмережі і маршрутизація правильна. Якщо у вас нема окремої мережі для міграції, видаліть налаштування або виправте мережу.

Завдання 3: Підтвердіть IP-адреси вузлів, які Proxmox вважає потрібними

cr0x@server:~$ cat /etc/pve/nodes/pve1/config | sed -n '1,120p'
# node config
acme: account=default

cr0x@server:~$ cat /etc/hosts
127.0.0.1 localhost
192.168.1.11 pve1
192.168.1.12 pve2
10.10.10.11 pve1-mig
10.10.10.12 pve2-mig

Що це означає: Багато кластерів покладаються на консистентне розв’язування імен. Якщо pve2 розв’язується в management IP, але міграція налаштована на іншу мережу, ви отримаєте асиметричні шляхи.

Рішення: Виберіть схему іменування, яка не вводить в оману. Переконайтеся, що хостнейм, що використовується для SSH, відповідає потрібній мережі, або використовуйте явну конфігурацію мережі для міграції.

Завдання 4: Підтвердіть безпарольний SSH root між вузлами (нудна передумова)

cr0x@server:~$ ssh -o BatchMode=yes -o ConnectTimeout=5 -e none root@10.10.10.12 "pveversion && hostname && true"
pve-manager/8.2.2/9355359cd (running kernel: 6.8.12-4-pve)
pve2

Що це означає: План керування може дістатися до цілі й запускати команди.

Рішення: Якщо це не працює — виправте SSH-ключі, проблеми з known_hosts, маршрути або брандмауер передусім.

Завдання 5: Перевірте невідповідність MTU і напівналаштовані jumbo frames

cr0x@server:~$ ip -d link show vmbr1
4: vmbr1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether 2c:fd:a1:11:22:33 brd ff:ff:ff:ff:ff:ff promiscuity 0
    bridge forward_delay 1500 hello_time 200 max_age 2000 ageing_time 30000 stp_state 0 priority 32768 vlan_filtering 0

cr0x@server:~$ ip -d link show vmbr1
4: vmbr1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether 2c:fd:a1:aa:bb:cc brd ff:ff:ff:ff:ff:ff promiscuity 0

Що це означає: На одному вузлі MTU 9000, на іншому 1500. Це не «майже нормально». Це майбутній збій міграції.

Рішення: Стандартизувати MTU скрізь (NIC, порти комутатора, VLAN, мости). Якщо не можете гарантувати jumbo повсюдно — працюйте на 1500 і заспокойтесь.

Жарт #1: Jumbo-фрейми як обіцянки керівництва — дивовижні, коли скрізь однаково, але один слабкий ланцюжок перетворює їх на дуже дорогий чутки.

Завдання 6: Перевірте шлях мережі для міграції великими пакетами (не довіряйте звичайному ping)

cr0x@server:~$ ping -M do -s 8972 -c 3 10.10.10.12
PING 10.10.10.12 (10.10.10.12) 8972(9000) bytes of data.
8972 bytes from 10.10.10.12: icmp_seq=1 ttl=64 time=0.391 ms
8972 bytes from 10.10.10.12: icmp_seq=2 ttl=64 time=0.402 ms
8972 bytes from 10.10.10.12: icmp_seq=3 ttl=64 time=0.388 ms

--- 10.10.10.12 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2046ms
rtt min/avg/max/mdev = 0.388/0.393/0.402/0.006 ms

Що це означає: Jumbo-пакети проходять з «do not fragment». Добрий знак для високопропускного потоку.

Рішення: Якщо отримуєте «Frag needed» або втрати пакетів — виправте MTU і/або налаштування комутатора перед повторним запуском міграції.

Завдання 7: Перевірте статус брандмауера й правила, пов’язані з міграцією

cr0x@server:~$ pve-firewall status
Status: running
Enabled: 1

cr0x@server:~$ iptables -S | grep -E 'DROP|REJECT' | head
-A INPUT -j PVEFW-INPUT
-A FORWARD -j PVEFW-FORWARD

Що це означає: Брандмауер увімкнено. Міграція зазвичай використовує SSH і порти QEMU, які погоджуються Proxmox. Надто суворі правила можуть це зламати.

Рішення: Якщо ви нещодавно ввімкнули брандмауер, підтвердіть дозволи для кластера/міграції. Тимчасово відключіть на вузлі лише для діагностики, якщо політика дозволяє, а потім впроваджуйте правильні правила.

Завдання 8: Підтвердіть кворум кластера та здоров’я corosync (бо операції фільтруються)

cr0x@server:~$ pvecm status
Cluster information
-------------------
Name:             prod
Config Version:   17
Transport:        knet
Secure auth:      on

Quorum information
------------------
Date:             Thu Dec 26 10:20:31 2025
Quorum provider:  corosync_votequorum
Nodes:            3
Node ID:          0x00000001
Ring ID:          1.4a
Quorate:          Yes

Що це означає: Кластер має кворум. Це виключає велику групу проблем «чому все заблоковано?»

Рішення: Якщо кворуму немає — виправляйте мережу кластера першочергово. Не намагайтеся використовувати міграцію як обхід; ви тільки погіршите інцидент.

Завдання 9: Перевірте конфігурацію VM щодо моделі CPU і сумісності для міграції

cr0x@server:~$ qm config 113 | egrep '^(name|memory|cores|sockets|cpu|machine|bios|efidisk0|hostpci|args):'
name: api-prod-01
memory: 16384
cores: 6
sockets: 1
cpu: host,hidden=1,flags=+aes
machine: pc-q35-8.1
bios: ovmf
efidisk0: ceph-vm:vm-113-disk-0,efitype=4m,pre-enrolled-keys=1,size=4M

Що це означає: CPU встановлено як host. Це добре для продуктивності й погано для гетерогенних кластерів. Також зверніть увагу, що тип машини має версію.

Рішення: Якщо цільовий вузол має інше покоління/вендора CPU, змініть тип CPU на сумісний базовий і вирівняйте типи машин між вузлами.

Завдання 10: Порівняйте прапорці CPU на хостах (швидко зловіть невідповідність)

cr0x@server:~$ lscpu | egrep 'Model name|Vendor ID|CPU family|Model:|Flags' | head -n 20
Vendor ID:             GenuineIntel
Model name:            Intel(R) Xeon(R) Silver 4314 CPU @ 2.40GHz
CPU family:            6
Model:                 106
Flags:                 fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss ht syscall nx pdpe1gb rdtscp lm constant_tsc rep_good nopl xtopology cpuid tsc_known_freq pni pclmulqdq vmx ssse3 fma cx16 pcid sse4_1 sse4_2 x2apic movbe popcnt aes xsave avx avx2

cr0x@server:~$ lscpu | egrep 'Model name|Vendor ID|CPU family|Model:|Flags' | head -n 20
Vendor ID:             AuthenticAMD
Model name:            AMD EPYC 7302P 16-Core Processor
CPU family:            23
Model:                 49
Flags:                 fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl cpuid tsc_known_freq pni pclmulqdq svm ssse3 fma cx16 sse4_1 sse4_2 x2apic movbe popcnt aes xsave avx avx2

Що це означає: Різні виробники. З cpu: host ця VM майже гарантовано не зможе мігрувати (або буде заблокована), бо видима модель CPU відрізняється.

Рішення: Використовуйте загальну модель CPU в конфігурації VM. У Proxmox вибирайте базову модель, наприклад x86-64-v2/v3 (залежно від вашого парку) або названу модель QEMU, яку підтримують усі вузли.

Завдання 11: Підтвердіть, що версії QEMU досить близькі (не змішуйте великі ери)

cr0x@server:~$ pveversion -v | egrep 'pve-manager|pve-qemu-kvm|kernel'
pve-manager/8.2.2/9355359cd
pve-qemu-kvm: 8.1.5-5
kernel: 6.8.12-4-pve

Що це означає: Якщо джерело на QEMU 8.1, а ціль на значно іншій версії з несумісними типами машин або моделями пристроїв, ви можете зіткнутися з проблемами міграції.

Рішення: Тримайте вузли на тих же основних версіях Proxmox/QEMU. Виконуйте rolling upgrades з політикою: мігруйте VM з вузла, що оновлюється, а не поєднуйте різні версії в роботі.

Завдання 12: Подивіться деталі спроби міграції в логах задач

cr0x@server:~$ grep -R "TASK OK\|TASK ERROR\|migration" /var/log/pve/tasks/active 2>/dev/null | tail -n 30
UPID:pve1:00003C2A:0001B2F4:676D5F9A:qmigrate:113:root@pam:
start migration of VM 113 to node 'pve2' (10.10.10.12)
migration aborted (duration 00:00:19): storage 'local-lvm' is not available on node 'pve2'
TASK ERROR: migration aborted

Що це означає: Перевірка на шару сховища провалилася. Це не проблема пропускної здатності; це «ви просите спільне сховище, а його немає».

Рішення: Або перемістіть диски на спільне сховище спочатку, або навмисно дозволіть міграцію з локальними дисками, або забезпечте наявність сховища на цільовому вузлі.

Завдання 13: Визначте, чи диски VM на спільному чи локальному сховищі

cr0x@server:~$ qm config 113 | grep -E '^(scsi|virtio|sata|ide)[0-9]+:'
scsi0: local-lvm:vm-113-disk-0,size=120G
scsi1: ceph-vm:vm-113-disk-1,size=500G

Що це означає: Змішане сховище. Один диск на local-lvm (локальний вузол), інший на Ceph (спільний). Жива міграція без переміщення локального диска буде невдалою або заблокованою.

Рішення: Вирішіть: або перемістіть scsi0 на спільне сховище (краще), або погодьтеся на витрати/час для міграції локальних дисків.

Завдання 14: Підтвердіть, що на цільовому вузлі достатньо вільної пам’яті і немає сюрпризів з ballooning

cr0x@server:~$ free -h
               total        used        free      shared  buff/cache   available
Mem:           251Gi       118Gi        11Gi       2.1Gi       122Gi       133Gi
Swap:           8.0Gi       0.0Gi       8.0Gi

Що це означає: Маєте запас. Пам’ятайте: при міграції потрібна пам’ять на цілі для отримання сторінок, і VM може підійняти навантаження під час переключення.

Рішення: Якщо доступної пам’яті замало — не ризикуйте. Спершу мігруйте іншу VM або заплануйте контрольоване відключення.

Завдання 15: Перевірте, чи VM занадто швидко «забруднює» пам’ять (pre-copy може не сходитися)

cr0x@server:~$ qm monitor 113 --cmd "info migrate"
capabilities: xbzrle: on  compress: off  events: on  postcopy-ram: off
Migration status: active
transferred ram: 7032.4 MB
remaining ram: 6141.2 MB
total ram: 16384.0 MB
duplicate: 82.1 MB
skipped: 0.0 MB
normal: 6950.3 MB
dirty pages rate: 61200 pages/s
expected downtime: 340 ms

Що це означає: Швидкість «забруднення» сторінок висока. Якщо вона залишатиметься такою — міграція може ніколи не завершитися або час відключення перевищить ваш поріг.

Рішення: Якщо не сходиться — обмежте навантаження, увімкніть стиснення міграції обережно або використайте postcopy для певних випадків (з розумінням ризиків).

Завдання 16: Перевірте здоров’я Ceph, якщо диски VM на Ceph (бо міграція його навантажує)

cr0x@server:~$ ceph -s
  cluster:
    id:     9c0ad9b4-1b2b-4b4d-a8b8-4f9b4b0f2a71
    health: HEALTH_WARN
            1 slow ops, oldest one blocked for 31 sec, osd.7 has slow ops
  services:
    mon: 3 daemons, quorum a,b,c (age 2h)
    mgr: a(active, since 2h)
    osd: 12 osds: 12 up (since 2h), 12 in (since 7d)
  data:
    pools:   3 pools, 256 pgs
    objects: 1.20M objects, 4.6 TiB
    usage:   13 TiB used, 21 TiB / 34 TiB avail
    pgs:     254 active+clean

Що це означає: Ceph має попередження. Повільні операції можуть привести до стрибків латентності IO VM під час міграції і блокувати storage migration.

Рішення: Якщо Ceph деградований або повільний — відкладіть важкі міграції. Виправте підсистему сховища; вона не «підлаштується» під навантаження.

Жарт #2: Якщо ваше сховище вже попереджає про slow ops, додавання живої міграції — це як «перевіряти» парашут, стрибаючи двічі.

Перевірки мережі, що ловлять 80% збоїв

Коли міграція швидко падає з помилками з’єднання, зазвичай це мережа або SSH. Коли вона повільно зависає (або «застрягає» на відсотках), зазвичай це пропускна здатність, втрати або VM, що не сходиться. Ваше завдання — зробити «мережа здається нормальною» вимірюваним фактом.

Переконайтеся, які IP та маршрути реально використовуються

Proxmox може бути налаштований на використання мережі для міграції, але Linux-маршрутизація все одно визначає, як пакети виходять із машини. Якщо у вас кілька NIC/VLAN, підтвердіть маршрут до цільового migration IP, що використовує потрібний інтерфейс.

cr0x@server:~$ ip route get 10.10.10.12
10.10.10.12 dev vmbr1 src 10.10.10.11 uid 0
    cache

Інтерпретація: Добре: використовується vmbr1 зі source IP у підмережі міграції.

Рішення: Якщо маршрут йде через management NIC — виправте маршрути або налаштування мережі для міграції, щоб не насичувати неправильне підключення.

Вимірюйте втрати й затримку як дорослий

Втрати вбивають TCP-пропускну здатність; джиттер ускладнює збіжність. Використовуйте mtr, якщо є, або хоча б ретельний ping. Для мережі міграції на одному комутаторі ви хочете нудні числа.

cr0x@server:~$ ping -c 50 10.10.10.12 | tail -n 5
--- 10.10.10.12 ping statistics ---
50 packets transmitted, 50 received, 0% packet loss, time 50062ms
rtt min/avg/max/mdev = 0.312/0.398/0.911/0.089 ms

Рішення: Будь-які втрати в LAN центру даних — сигнал тривоги. Виправте кабелі, порти комутатора, налаштування NIC offloads або перевантаження перед тим, як звинувачувати Proxmox.

Підтвердіть пропускну здатність (швидко і грубо)

Міграції — це по суті великі копії пам’яті плюс накладні витрати. Якщо очікуєте, що 16–64 ГБ VM мігрує «швидко», вам потрібна реальна пропускність. Якщо немає iperf3, встановіть його. Це інструмент діагностики, а не спосіб життя.

cr0x@server:~$ iperf3 -s
-----------------------------------------------------------
Server listening on 5201 (test #1)
-----------------------------------------------------------

cr0x@server:~$ iperf3 -c 10.10.10.12 -P 4 -t 10
Connecting to host 10.10.10.12, port 5201
[SUM]   0.00-10.00  sec  9.72 GBytes  8.35 Gbits/sec  0             sender
[SUM]   0.00-10.04  sec  9.70 GBytes  8.31 Gbits/sec                  receiver

Рішення: Якщо ви отримуєте 1–2 Gbps на «10G» лінку — міграція буде виглядати застиглою. Виправте мережу (конфіг бондингу, дуплекс, комутатор, VLAN, драйвери NIC, offloads) перед налаштуванням QEMU.

Спостерігайте трафік у реальному часі під час міграції

Не гадіть, чи міграція насичує лінк. Дивіться.

cr0x@server:~$ ip -s link show dev vmbr1 | sed -n '1,12p'
4: vmbr1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9000 qdisc noqueue state UP mode DEFAULT group default qlen 1000
    link/ether 2c:fd:a1:11:22:33 brd ff:ff:ff:ff:ff:ff
    RX:  bytes packets errors dropped  missed   mcast
    98234982344 81234567      0      12       0       0
    TX:  bytes packets errors dropped carrier collsns
    112334455667 92345678      0       0       0       0

Рішення: Якщо під час міграції лічильник drops зростає — ви знайшли лиходія. Втрати не «нормально, якщо мало». Вони примножують ретрансляції і гальмують прогрес.

Тримайте брандмауери передбачуваними

У суворо контрольованих середовищах брандмауер Proxmox корисний — поки хтось не увімкне його без моделювання трафіку. Міграція використовує:

• SSH від джерела до цілі для оркестрації.
• QEMU-канали міграції (часто тунелюються/керуються Proxmox; поведінка варіює з «secure migration»).
• Трафік сховища (Ceph, NFS, iSCSI), який може піковувати під час і після міграції.

Вам потрібна політика брандмауера, що є явною: дозвіл вузел-вузел на мережах міграції та суворість всюди інде. «Drop everything and see what breaks» — це не стратегія безпеки; це стратегія зайнятості для вашого інцидент-менеджера.

Прапорці CPU та невідповідності типів машини

Сумісність CPU — це найчистіша категорія «жорсткої зупинки». QEMU не може телепортувати можливості CPU. Міграція вимагає, щоб ціль подала CPU, сумісний із тим, який вже бачив гість.

Типова пастка: cpu: host в гетерогенному кластері

host відкриває модель CPU і можливості хоста для гостя. Це чудово, якщо ви прив’язуєте VM до вузла назавжди або дійсно маєте ідентичні CPU в усьому кластері. В іншому випадку — це зброя зворотного ефекту.

На різнорідному обладнанні обирайте базову модель CPU, щоб гість бачив однаковий віртуальний CPU скрізь. Так, ви можете втратити кілька інструкцій. Ні, ваш додаток, ймовірно, цього не помітить. Альтернатива — «міграція не працює», що помітно гірше.

Базові моделі CPU: оберіть одну і стандартизуйте

Що обрати залежить від вашого парку:

• x86-64-v2: консервативна базова модель для широкої сумісності (добре, якщо є старі вузли).
• x86-64-v3: більш сучасна базова модель із ширшим набором інструкцій; добра, якщо ваш парк новіший і однорідний.
• Названі моделі QEMU (наприклад Haswell, Skylake-Server): корисні в Intel-only парках, але можуть бути надто специфічними.

Ваша мета — не максимальна продуктивність, а передбачувана мобільність. Якщо вам потрібна максимальна продуктивність для окремого VM — задокументуйте, що він прикріплений і не мігрується між усіма вузлами.

Вирівнювання типу машини не є опціональним

Типи QEMU-машин, як-от pc-q35-8.1, кодують версії чіпсета/пристроїв. Якщо у вас різні версії QEMU-пакетів на вузлах, ви можете натрапити на невідповідність стану пристрою під час міграції.

Операційна політика: тримайте кластер на одній версії Proxmox якомога довше. Під час оновлень мігруйте робочі навантаження з вузла, що оновлюється, оновіть його, потім поверніть навантаження. Не робіть «половина кластера на новому QEMU» і не очікуйте гладкої живої міграції для будь-якої комбінації пристроїв.

PCI passthrough та vGPU: особливий біль

Якщо VM використовує hostpci пристрої, жива міграція зазвичай неможлива, якщо тільки у вас немає дуже специфічного обладнання й інструментів. Стан пристрою не можна безпечно перемістити, і на цілі може не бути того самого фізичного відображення пристрою.

cr0x@server:~$ qm config 210 | egrep 'hostpci|machine|cpu'
cpu: host
machine: pc-q35-8.1
hostpci0: 0000:65:00.0,pcie=1

Рішення: Розглядайте passthrough VM як прикріплені. Плануйте обслуговування навколо них (відмовостійкість на рівні додатка, заплановані вікна простою або холодна міграція).

Цитата про надійність, яку варто тримати на столі

Надія — не стратегія. — Rudy Giuliani

Цю фразу часто повторюють в операціях, бо вона брутально застосовна: не «надійтесь», що CPU співпаде; не «надійтесь», що MTU консистентний; не «надійтесь», що сховище спільне. Перевіряйте.

Сховище: спільне, локальне, Ceph, ZFS та шлях даних при міграції

Сховище — це місце, де міграції повільно помирають. Мережа і CPU вбивають міграцію швидко; неправильний дизайн сховища змусить її зависати, повзти або «працювати» з неприйнятним простоєм.

Знати, що ви мігруєте: стан обчислень проти стану диска

• Жива міграція (спільне сховище): рухається RAM+CPU+стан пристроїв; диски залишаються на спільному сховищі (Ceph RBD, NFS, iSCSI тощо). Швидко та передбачувано.
• Жива міграція з локальними дисками: рухається RAM+стан і копіюються блоки диска по мережі. Це може бути жорстоко для великих дисків і навантажених VM.
• Storage migration: копіювання дисків між сховищами; може бути онлайн для деяких налаштувань, але все одно важке з IO.

Якщо у вас нема спільного сховища і ви очікуєте швидкої живої міграції — ви не плануєте, ви готуєтеся до інциденту.

Перевірте визначення сховищ і їх доступність на обох вузлах

cr0x@server:~$ pvesm status
Name             Type     Status           Total            Used       Available        %
ceph-vm          rbd      active        34.00TiB        13.00TiB        21.00TiB   38.24%
local            dir      active         1.80TiB         0.72TiB         1.08TiB   40.00%
local-lvm        lvmthin  active         1.75TiB         1.62TiB       130.00GiB   92.70%

Що це означає: local-lvm майже повний. Якщо ви спробуєте міграцію локального диска, можете вичерпати місце під час копіювання.

Рішення: Якщо thin-пули понад ~85–90% — розглядайте це як інцидентний ризик. Звільніть місце або розширте перед міграціями дисків.

Особливості ZFS: локальний ZFS не є спільним сховищем

ZFS чудовий. Локальний ZFS лишається локальним. Жива міграція вимагає або спільного сховища, або механізму переміщення диска.

Якщо ви використовуєте ZFS на кожному вузлі, правильна модель: використовувати реплікацію (ZFS send/receive) для попереднього підготовлення дисків, а потім робити контрольоване переключення. Це не те саме, що «жива міграція коли завгодно».

Особливості Ceph: окремі мережі, окремі режими відмов

Ceph зазвичай використовує «public» мережу (клієнти) і можливу «cluster» мережу (реплікація/backfill). Трафік міграції окремий. Але оперативно вони перетинаються, бо міграція збільшує IO і CPU, що змушує нестабільний Ceph показати свій справжній характер.

Перед великими міграціями зробіть Ceph «нудним»:

• Усі OSD up/in.
• Ніяких штормів deep-scrub.
• Немає recovery/backfill перевантажень.
• Латентність у межах норми.

Локальна міграція диска: вирішіть, чи це того варте

Якщо потрібно мігрувати локальні диски онлайн, хоча б кількісно оціни це:

• Розмір диска (виділений та фактичний).
• Доступна пропускна здатність між вузлами.
• Швидкість запису VM (накладні витрати copy-on-write).
• Комерційна терпимість до деградованої продуктивності під час копіювання.

У багатьох продакшен-середовищах правильне рішення: запланувати вікно обслуговування і зробити холодний перенос або переробити архітектуру для спільного сховища.

Типові помилки: симптом → корінь проблеми → виправлення

1) «Migration failed: can’t connect to destination»

• Симптом: Падає за секунди, у логах SSH exit code 255.
• Корінь проблеми: Невідповідність SSH-ключів, зміна хост-ключів, брандмауер блокує SSH, невірний IP/маршрут.
• Виправлення: Переконайтеся, що ssh -o BatchMode=yes root@dest працює зі джерела на migration IP. Виправте маршрути/hosts/брандмауер; відновіть довіру SSH кластера за потреби.

2) Міграція зависає на 0% або дуже повільно рухається

• Симптом: Прогрес не зростає; UI показує довге виконання завдання.
• Корінь проблеми: Неправильний мережевий шлях (використовується 1G management замість 10G), проблеми MTU викликають ретрансляції, втрата пакетів або проблеми зі stateful firewall.
• Виправлення: Підтвердіть ip route get і протестуйте пропускну здатність (iperf3). Перевірте великі ping з -M do. Виправте MTU, маршрути або вимкніть некоректні offloads.

3) «CPU feature mismatch» / «host doesn’t support requested features»

• Симптом: Падає швидко з помилками пов’язаними з CPU; часто видно лише в QEMU логах.
• Корінь проблеми: VM використовує cpu: host або надто специфічну модель CPU; ціль не має потрібного прапорця.
• Виправлення: Встановіть VM CPU на загальний базовий для кластера. Підтримуйте вузли в однорідних сімействах апаратури, якщо це можливо.

4) «storage ‘local-lvm’ is not available on node …»

• Симптом: Міграція заблокована до старту; лог задачі згадує, що сховище недоступне.
• Корінь проблеми: Диск VM знаходиться на локальному сховищі; цільовий вузол не має такого ідентифікатора сховища (за задумом).
• Виправлення: Перенесіть диски на спільне сховище спочатку, або виконуйте міграцію з локальними дисками свідомо, або виправте визначення сховища, якщо ви насправді хотіли спільне сховище.

5) Міграція завершилась, але VM зависає занадто довго («жива» була дуже офлайн)

• Симптом: Міграція вдається, але час простою декілька секунд+; додаток бачить таймаути.
• Корінь проблеми: VM занадто швидко «забруднює» пам’ять; pre-copy не сходиться; мережа не дає пропускної здатності; піки латентності диска (особливо на спільному сховищі під навантаженням).
• Виправлення: Мігруйте під час меншої активності записів, розгляньте налаштування стиснення/ postcopy обережно і виправте базову латентність сховища.

6) Міграція падає тільки для певних VM (інші мігрують нормально)

• Симптом: Деякі VM мігруються; інші систематично падають.
• Корінь проблеми: Ці VM мають passthrough-пристрої, спеціальні прапорці CPU, різницю в налаштуваннях huge pages або конкретні комбінації типу машини/пристрою.
• Виправлення: Нормалізуйте апаратні профілі VM. Документуйте виключення (прикріплені VM). Не прикидайтеся, що кожне навантаження мобільне.

7) Міграція зламалась одразу після увімкнення брандмауера Proxmox

• Симптом: Раніше працювальні міграції тепер падають; інший трафік може бути в порядку.
• Корінь проблеми: Відсутні дозволи вузел-вузел для мережі міграції або пов’язаних сервісів; stateful правила ріжуть довгі потоки.
• Виправлення: Впровадьте явні allowlists для вузлів кластера на мережах міграції. Тестуйте міграції як частину rollout політики зміни брандмауера.

Три корпоративні історії з бойових дій

Міні-історія 1: Інцидент через неправильне припущення

Компанія мала два вузли Proxmox, які «виглядали однаково» у стійці: той же шасі, той же вендор, та сама кількість NIC. Хтось замовив їх з різницею в шість місяців і припустив, що «та сама модель» означає «той самий CPU». Це було не так. Один прийшов із новішим stepping і іншим мікрокодом, а інший — з іншою сімейством CPU через заміни в ланцюгу постачання.

Вони встановили більшість VM на cpu: host заради продуктивності. Це працювало місяцями, бо їм ніколи не доводилось мігрувати важкі VM — доки оновлення прошивки на вузлі A не вимагало перезавантаження і вони спробували евакуювати навантаження. Перша міграція впала миттєво. Друга теж. Тепер у них був вузол на обслуговуванні і вузол, що не міг прийняти робочі навантаження.

На інцидентному колі припущення, що «жива міграція — це кнопка», витратило час. Люди ганялися за Ceph-латентністю, потім за правилами брандмауера, потім за HA-настройками. Підказка була у qm config весь час: cpu: host. Швидке порівняння lscpu закінчило загадку.

Виправлення було не героїчне. Вони змінили моделі CPU VM на базову, підтримувану обома вузлами, протестували міграцію на одній VM, потім розгорнули по флоту. Вплив на продуктивність — незначний. Урок запам’ятався: якщо ви хочете мобільності — треба закласти це в політику експозиції можливостей CPU.

Міні-історія 2: Оптимізація, що обернулась проти

Інша організація була хитрою з jumbo frames. Вони ввімкнули MTU 9000 на хостах, бо «10G дороге і треба оптимізувати». Але мережевий відділ увімкнув jumbo лише на деяких портах комутаторів. Декілька VLAN-транків були на 1500. Ніхто не мав повної енд-то-енд діаграми, бо, звісно, не мав.

Звичайний трафік виглядав нормально. Management ping працював. SSH працював. Малі пакети не дуже звертали уваги. Потім вони спробували мігрувати пам’яттєво-важку VM. Вона стартувала, трохи передавала, потім зависала і зрештою падала. Іноді вдавалося, але дуже довго. Команда звинуватила Proxmox, потім QEMU, потім Ceph, потім життєві рішення.

Переломний момент настав після ненаважного тесту: великий ping з «do not fragment». Він упав. Не «може», а впав. Мережа міграції мала шлях, що мовчки чорноголив великі пакети, призводячи до фрагментації, ретрансляцій і жахливої пропускної здатності.

Вони виправили це, стандартизувавши MTU по всьому шляху міграції. І тут поворот: після виправлення вони все ж повернулися до MTU 1500. Чому? Операційна простота. Вони обрали передбачувану продуктивність замість теоретичної оптимізації. Саме так навчають продакшн-системи: найшвидша мережа — та, що працює щодня.

Міні-історія 3: Нудна, але правильна практика, що врятувала день

Одна команда ставилася до живої міграції як до фічі, яку треба регулярно тестувати, а не як до кнопки, знайденої під час інциденту. Щотижня вони робили набір з міграцій: одна Linux VM, одна Windows VM, одна «завантажена» VM і одна з UEFI. Вони логували результати і вели базову лінію часу міграції та часу простою.

Це було нудно. Ніхто не отримав підвищення за «все ще працює». Але практика окупилася, коли оновлення прошивки комутатора ввело періодичну втрату пакетів на конкретному VLAN. Першим сигналом не були скарги користувачів — це були щотижневі тести міграції, які показали раптове уповільнення і зрідка невдачі.

Оскільки у них була базова лінія, вони могли сказати «ось що змінилося» і довести це даними: ping loss, падіння iperf і подвоєння тривалості міграції. Мережевий відділ взяв це серйозно, бо докази були чіткі та відтворювані.

Вони відкотили прошивку, відновили базу, а потім оновили з нормальною валідацією. Жодного великого інциденту. Нудна практика не просто «врятувала день»; вона запобігла нічному дзвінку, що включив би забагато людей і недостатньо кави.

Чеклісти / покроковий план

Чекліст A: Перед тим як робити живу міграцію в продакшені

1. Здоров’я кластера: pvecm status показує кворум. Якщо ні — зупинитись.
2. Вирівнювання версій: pveversion -v консистентно по вузлах (особливо pve-qemu-kvm).
3. Мережа міграції: Вирішіть, чи використовуєте окрему мережу. Якщо так — налаштуйте і перевірте великими ping-тестами.
4. SSH-довіра: Node-to-node ssh -o BatchMode=yes працює на IP міграції.
5. Політика моделі CPU: Визначена базова модель для мобільних навантажень; уникайте cpu: host, якщо вузли не однорідні.
6. Політика сховища: Спільне сховище для мігрованих VM або задокументований план для локальних дисків.
7. Список виключень: Passthrough/vGPU/edge-case VM задокументовані як прикріплені.
8. Резерв потужностей: Ціль має запас пам’яті і CPU для VM та накладних витрат міграції.

Чекліст B: Коли міграція падає (план на 15 хвилин для інциденту)

1. Заберіть реальну помилку: перевірте journalctl -u pvedaemon і логи задач.
2. Класифікуйте збій: з’єднання/автентифікація vs сумісність CPU vs блокування сховища vs повільна збіжність.
3. Мережна санітарність: ip route get, ping -M do -s ..., швидкий iperf3, якщо дозволено.
4. CPU-санітарність: qm config VMID для типу CPU; lscpu для порівняння вузлів.
5. Сховище: qm config для місць дисків; pvesm status і (якщо Ceph) ceph -s.
6. Повторіть спробу один раз після цілеспрямованого виправлення. Не п’ять разів. Повторні спроби створюють шум, блокування і іноді частковий стан.
7. Ескалюйте з доказами: принесіть точний рядок помилки і виводи команд. «Міграція зламалась» — не тикет; це емоція.

Чекліст C: Після виправлення (щоб не поверталося)

1. Стандартизувати моделі CPU VM по мобільному флоту.
2. Стандартизувати MTU по мережі міграції або прийняти 1500 як стандарт.
3. Запланувати регулярні тестові міграції і вести метрики duration/downtime.
4. Документувати прикріплені VM і причини прикріплення.
5. Тримати версії вузлів вирівняними; уникати тривалих mixed-version кластерів.

Питання та відповіді

1) Чи потрібно мені спільне сховище для живої міграції?

Якщо ви хочете швидку, надійну живу міграцію: так, на практиці. Без спільного сховища можна мігрувати локальні диски, але тоді ви робите велику онлайн-копію й називаєте це «живою». Це може бути прийнятно для малих дисків і тихих VM, але не для навантажених баз даних у продакшені.

2) Чому міграція працює для деяких VM, але не для інших?

Різні віртуальні апаратні профілі. CPU тип host, passthrough пристрої, різні типи машин або спеціальні QEMU args можуть зробити VM не мігрувальною навіть на здоровому кластері.

3) Чи завжди погано використовувати cpu: host?

Ні. Це нормально для одно-вузлових «продуктивність перш за все» VM або справді ідентичних кластерів. Це погано, коли ви припускаєте однорідність апаратури, яку не забезпечуєте. Якщо потрібна мобільність — оберіть базову модель і дотримуйтесь її.

4) Який найшвидший спосіб виявити проблему MTU?

Великий ping з «do not fragment» на IP міграції: ping -M do -s 8972 target для MTU 9000. Якщо він фейлить — jumbo не працює енд-то-енд. Виправте або перестаньте використовувати jumbo.

5) Чому міграція застрягає на певному відсотку?

Часто це pre-copy, що не сходиться через високий dirty page rate, або мережа, що руйнує пропускну здатність через втрати/ретрансляції. Перевірте qm monitor VMID --cmd "info migrate" і подивіться на dirty page rate та статус міграції.

6) Чи можна мігрувати між вузлами на різних версіях Proxmox/QEMU?

Іноді можна, але це не спосіб життя. Сумісність міграції найкраща, коли версії QEMU та типи машин вирівняні. При поетапних оновленнях евакуюйте вузол, оновіть його, потім повертайте — мінімізуючи роботу в режимі mixed-version.

7) Як я дізнаюся, що міграція використовує неправильний NIC?

ip route get <destination migration IP> покаже інтерфейс і source IP, які будуть використані. Якщо це не ваш міст/ніс міграції — виправте маршрути або конфігурацію мережі для міграції.

8) Windows VM і UEFI — які особливі ризики при міграції?

UEFI зазвичай в порядку, якщо обидва вузли його підтримують і конфігурація VM узгоджена. Проблеми зазвичай виникають через різниці в пристроях, невідповідності типів машин або зміни в макеті сховища. Тримайте firmware/machine type консистентними і уникайте ад-хок змін апаратури.

9) Чи варто вмикати стиснення міграції?

Лише після вимірювання вузького місця в мережі і за наявності CPU-запасу. Стиснення міняє CPU на пропускну здатність. На CPU-обмежених хостах це все погіршить, включно з навантаженням, яке ви намагаєтесь не турбувати.

10) Що якщо у мене Ceph і міграція все одно падає?

Тоді збій, ймовірно, не в «доступності спільного диска», а в мережі/CPU/брандмауері або в здоров’ї Ceph під навантаженням. Перевірте ceph -s і дивіться на slow ops. Ceph може бути «up», але операційно — нещасливим.

Висновок: наступні кроки, що збережуть здоровий глузд

Коли жива міграція Proxmox падає, не сприймайте це як містичну подію. Це набір передбачуваних передумов: стабільний мережевий шлях, сумісна експозиція CPU і архітектура сховища, що відповідає вашим очікуванням.

Наступні кроки, що реально зменшать кількість інцидентів у майбутньому:

• Визначте політику CPU для VM (базова модель для мігруваних навантажень) і дотримуйтесь її.
• Зробіть мережу міграції нудною: консистентний MTU енд-то-енд, перевірена пропускна здатність, явні дозволи брандмауера.
• Перестаньте прикидатися, що локальні диски — спільні. Якщо вам потрібна мобільність — проектуйте спільне сховище або процес реплікації для cutover.
• Регулярно запускайте тестові міграції і ведіть базову лінію. Якщо ви тестуєте лише в аваріях — ви практикуєте chaos engineering на клієнтах.

Якщо нічого іншого не зробите: перевірте шлях migration IP і припиніть використовувати cpu: host в гетерогенних кластерах. Ці дві зміни усувають величезну кількість болю.