Proxmox «migration aborted»: поширені причини та шляхи відновлення

Що насправді означає «migration aborted» у Proxmox

У Proxmox VE міграції бувають кількох типів:

• Жива міграція (стан пам’яті QEMU переноситься під час роботи VM). Зазвичай вимагає спільного сховища або стратегій реплікації, які роблять диск доступним на цільовому вузлі.
• Офлайн-міграція (VM зупинена; конфіг та диски переміщаються). Повільніше, часто простіше, іноді єдиний розумний вибір.
• Міграція сховища (переміщення дисків між бекендами сховища, опційно без переміщення обчислювального вузла).
• Підхід з підтримкою реплікації (реплікація ZFS або Ceph/RBD, де локальність дисків і правила консистентності відрізняються).

«migration aborted» — це не одна конкретна помилка. Це верхній стан відмови для багатокрокового робочого процесу:

1. Перевірки кластера (дозволи, конфіг, кворум, готовність цільового вузла).
2. Перевірки доступності (SSH та/або мережа міграції).
3. Перевірки сховища (чи існує диск на цілі? чи він шарований? чи є місце? чи вірний ідентифікатор сховища?).
4. Запуск QEMU каналу міграції (попередній копіювання пам’яті, відстеження «брудних» сторінок).
5. Фінальне переключення / очищення (ця частина болюча, коли відмовляє).

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

Перефразована ідея від James Hamilton (AWS reliability engineering): «Працюйте, мінімізуючи варіативність, і вчіться з кожної відмови.» Це не поезія. Це правильно.

Короткий жарт №1: Жива міграція — це як переїзд у квартиру, поки готуєш вечерю — можливо, але ризик пролити суп є.

Швидкий сценарій діагностики (перевірте це перш за все)

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

1) Підтвердіть здоров’я кластера та готовність цільового вузла

• Чи є кворум? Чи не флапає corosync?
• Чи знаходиться цільовий вузол у чистому стані і не відфенсований чи частково відключений?
• Чи не заблоковано VM?

2) Витягніть лог завдання, потім логи вузла

• Журнал завдань Proxmox дає перший значущий рядок помилки.
• Системні логи розкажуть вам справжню причину (помилка автентифікації, відмова дозволу, скидання мережі, OOM, переповнений диск).

3) Визначте топологію сховища і чи відповідає вона типу міграції

• Спільне сховище (Ceph, NFS, iSCSI тощо) робить обчислювальну міграцію простішою.
• Локальне сховище означає переміщення/реплікацію дисків і обмеження по пропускній здатності.
• ZFS datasets, thin LVM та qcow2 поводяться по-різному під час копіювання і роботи зі снапшотами.

4) Перевірте шлях мережі міграції

• Невідповідність MTU, асиметрична маршрутизація, правила фаєрвола або надмірне навантаження на bond можуть вбити міграцію.
• Сплески затримки можуть продовжити попереднє копіювання до таймауту або примусового скасування.

5) Перевірте блокувальники гостя

• Huge pages, passthrough-пристрої, локальні CD-ROM/ISO або непідтримувані CPU-флаги можуть блокувати або ускладнювати міграцію.
• Балонування пам’яті та швидкість «брудних» сторінок можуть зробити живу міграцію нескінченною.

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

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

• Факт 1: Proxmox VE використовує Corosync для членства в кластері та pmxcfs (FUSE-файлова система) для розповсюдження конфігурації під /etc/pve. Якщо pmxcfs проблемний, міграції швидко стають дивними.
• Факт 2: Жива міграція QEMU покладається на алгоритм попереднього копіювання: надсилає сторінки пам’яті під час роботи VM, потім повторно надсилає «брудні» сторінки. Висока швидкість записів може заважати збіжності.
• Факт 3: Канал міграції — це не «просто SSH». Proxmox використовує SSH для оркестрації, але QEMU відкриває власний потік міграції (часто по виділеній мережі), який може бути заблокований, навіть коли SSH працює.
• Факт 4: Конфіги VM у Proxmox зберігаються як текстові файли в /etc/pve/qemu-server/. Частково записаний або застарілий конфіг-лок може зірвати повторні спроби.
• Факт 5: VM на Ceph (RBD) зазвичай мігрують обчислювальний стан без копіювання дисків, але ви тепер залежите від здоров’я Ceph, дозволів клієнта та мережевих шляхів до публічної і кластерної мереж Ceph.
• Факт 6: Реплікація ZFS у Proxmox базується на снапшотах. Вона надійна, але не магічна: відсутні снапшоти, перейменування dataset-ів або «допоміжні» ручні команди zfs можуть порвати ланцюг.
• Факт 7: Механізм «блокування VM» існує, щоб запобігти конкурентним операціям. Якщо міграція переривалася не в той момент, блокування може застрягти і блокувати все до його очищення.
• Факт 8: Невідповідність MTU зазвичай проявляється як «працює для маленьких передач, ламається для великих». Міграції — це великі передачі.

Поширені кореневі причини з шляхами відновлення

A) Проблеми стану кластера (кворум, corosync, pmxcfs)

Як виглядає: Міграція відмовляє миттєво, іноді з загальними помилками; у GUI вузли можуть показуватись як «?»; конфіги не з’являються на всіх вузлах; завдання завершуються з «no quorum» або не можуть записати під /etc/pve.

Що насправді відбувається: Proxmox потребує узгодженого членства кластера, щоб безпечно переміщувати ресурси. Без кворуму він відмовляється робити зміни. Якщо pmxcfs деградований, навіть читання/запис конфігів VM може зірватись.

Шлях відновлення: Спочатку стабілізуйте кластер. Якщо кластер не здоровий, не мігруйте. Виправте посилання corosync, кворум та синхронізацію часу. Потім повторіть міграцію.

B) Помилки SSH та автентифікації (шар оркестрації)

Як виглядає: «migration aborted: ssh error» або відмови на ранніх етапах логу завдання. Іноді це переміжно — адже нічого так не робить «ентерпрайз», як ротація ключів у середині дня.

Що насправді відбувається: Proxmox використовує SSH між вузлами для координації й для певних передач файлів. Невірні host key, зламаний known_hosts, права або примусова команда в authorized_keys можуть це зіпсувати.

Шлях відновлення: Перевірте root SSH доступ між вузлами (як очікує Proxmox), усуньте невідповідності host key, підтвердіть, що sshd дозволяє потрібні функції, і повторіть спробу.

C) Проблеми мережевого шляху міграції (фаєрвол, MTU, маршрутизація, перевантаження)

Як виглядає: Міграція починається, потім відміняється; логи показують «connection reset», таймаути або помилки сокета QEMU migration. Іноді доходить до 90% і зупиняється. Це підказка: початкова координація спрацювала; дата-план не витримав.

Що насправді відбувається: Потік міграції QEMU чутливий до втрат пакетів і проблем з PMTU. Фаєрволи можуть дозволяти SSH, але блокувати діапазон портів міграції. Або ви запускаєте міграцію по завантаженій продуктивній мережі, де одночасно йде Ceph, бекапи і «тимчасове» rsync колеги.

Шлях відновлення: Підтвердіть MTU від краю до краю, переконайтесь, що правила фаєрволу дозволяють трафік міграції, виділіть для міграції окремий інтерфейс, якщо можливо, і зупиніть насичення лінку.

D) Невідповідність сховища: спільне проти локального

Як виглядає: «storage ‘local-lvm’ not found on target», «volume does not exist», «cannot open disk image», або міграція відміняється після копіювання деяких дисків.

Що насправді відбувається: Конфіг VM посилається на ідентифікатори сховища. Якщо цільовий вузол не має такої самої дефініції сховища (той же ID, сумісний тип), Proxmox не може розмістити диск. Для локального сховища потрібно або перемістити диски (міграція сховища), або реплікувати їх (ZFS реплікація, backup/restore тощо).

Шлях відновлення: Узгодьте дефініції сховища між вузлами, підтвердіть наявність місця, перевірте томи і оберіть правильний метод міграції (жива переміщення обчислення vs офлайн з передачею дисків).

E) Збої копіювання дисків (місце, права, повільне сховище, дивні снапшоти)

Як виглядає: rsync або qemu-img copy відмовляє; «No space left on device»; «Input/output error»; міграція повільна, потім abort.

Що насправді відбувається: Міграція диска — це навантаження на сховище: метадані критичні для qcow2, послідовні операції для raw, і важкощі для фрагментованих thin-томів. Також: якщо підлегле сховище деградоване (помилки ZFS, відновлення Ceph), ви виявите це під час міграції.

Шлях відновлення: Перевірте місце, стан сховища та помилки I/O. Якщо сховище хворе — припиніть міграції і виправте сховище. Якщо воно просто повільне — плануйте вікно техобслуговування і виконуйте офлайн-міграцію.

F) Обмеження гостя (CPU-модель, passthrough, hugepages, TPM, локальні носії)

Як виглядає: Міграція відміняється з повідомленнями про пристрої, несумісність CPU або «cannot migrate with device». Іноді abort відбувається після старту QEMU, бо на цілі не вдається відтворити ідентичне віртуальне обладнання.

Що насправді відбувається: Жива міграція вимагає, щоб ціль могла емулювати сумісний набір CPU та пристроїв. PCI passthrough, деякі USB-пристрої та особливі конфігурації ворожі до міграції. Стан TPM також може ускладнити процес залежно від налаштувань.

Шлях відновлення: Використовуйте сумісну базову модель CPU (наприклад, x86-64-v2/v3), уникайте passthrough для мігрувальних VM, від’єднайте локальні носії і обирайте офлайн-міграцію, коли потрібно.

G) Блокування, залишки і напівміграційний стан

Як виглядає: VM показана як заблокована; наступні операції кажуть «resource is locked»; конфіг існує на обох вузлах; диски існують в двох місцях з подібними іменами.

Що насправді відбувається: Міграція — це транзакція з кроками очищення. Якщо вона abort-илась, крок очищення могло не виконатися. Ви можете отримати блокування, що блокує подальші операції, і артефакти на цілі, які плутають наступну спробу.

Шлях відновлення: Визначте, де VM фактично працює, потім видаліть застарілі блокування і тільки ті артефакти, у безпечності видалення яких ви впевнені. «Впевненість» означає: перевірити посилання томів, VMID і вміст сховища — двічі.

Практичні завдання: команди, що означає вивід і яке рішення приймати

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

Завдання 1: Витягніть точну помилку з журналу завдань Proxmox

cr0x@server:~$ tail -n 80 /var/log/pve/tasks/active
UPID:pve1:000A1B2C:0F2B3C4D:676D2A1E:qmigrate:101:root@pam:

cr0x@server:~$ cat /var/log/pve/tasks/0F/2B/UPID:pve1:000A1B2C:0F2B3C4D:676D2A1E:qmigrate:101:root@pam: | tail -n 60
starting migration of VM 101 to node 'pve2' (192.168.10.12)
found local disk 'local-lvm:vm-101-disk-0' (in current node)
migration aborted (duration 00:00:14): storage 'local-lvm' not available on target node
TASK ERROR: migration aborted

Значення: Журнал завдань зазвичай містить один рядок, що має значення. Тут це — невідповідність ідентифікатора сховища.

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

Завдання 2: Перевірте кворум та членство кластера

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

Quorum information
------------------
Date:             Fri Dec 26 14:12:06 2025
Quorum provider:  corosync_votequorum
Nodes:            3
Node ID:          0x00000001
Ring ID:          1.2c
Quorate:          Yes

Значення: Quorate: Yes означає, що запис у кластер дозволений. Якщо «No», міграції — погана ідея.

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

Завдання 3: Перевірте стан зв’язку corosync

cr0x@server:~$ corosync-cfgtool -s
Local node ID 1, transport knet
LINK ID 0 udp
        addr    = 10.10.0.11
        status  = OK
LINK ID 1 udp
        addr    = 10.20.0.11
        status  = OK

Значення: Лінки мають бути OK. Флапаючі лінки спричиняють затримки pmxcfs і «випадкові» відмови.

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

Завдання 4: Підтвердіть, що pmxcfs змонтовано і відгукується

cr0x@server:~$ mount | grep pve
pve on /etc/pve type fuse.pve (rw,nosuid,nodev,relatime,user_id=0,group_id=0,default_permissions,allow_other)

cr0x@server:~$ ls -la /etc/pve/qemu-server | head
total 0
drwxr-xr-x 2 root www-data 0 Dec 26 13:58 .
drwxr-xr-x 8 root www-data 0 Dec 26 13:58 ..
-rw-r----- 1 root www-data 512 Dec 26 13:40 101.conf

Значення: Якщо /etc/pve не змонтовано, ви не в здоровому стані кластера.

Рішення: Виправте pmxcfs/corosync перед будь-якими іншими кроками. Міграція з пошкодженою файловою системою конфігів — це шлях до роботи у вихідні дні.

Завдання 5: Перевірте, чи VM заблокована (і чому)

cr0x@server:~$ qm config 101 | grep -i lock
lock: migrate

Значення: Блокування вказує на операцію в процесі або на абортовану операцію, яка не очистилась.

Рішення: Не знімайте блокування без роздумів. Спочатку визначте, де VM фактично працює (Завдання 6). Якщо вона стабільна і ви проводите очистку — тоді можна розблокувати.

Завдання 6: Визначте, де VM фактично працює

cr0x@server:~$ qm status 101
status: running

cr0x@server:~$ pvesh get /cluster/resources --type vm | awk '$1 ~ /qemu/ && $2 ~ /101/ {print}'
qemu 101 running pve1

Значення: Вид кластерних ресурсів має показувати одного власника вузла. Якщо він «unknown» або плутається — ваш кластер нестабільний.

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

Завдання 7: Очистіть застаріле блокування (тільки після перевірки реальності)

cr0x@server:~$ qm unlock 101

Значення: Unlock знімає операційне блокування, але не вирішує основну проблему.

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

Завдання 8: Перевірте, чи дефініції сховища збігаються між вузлами

cr0x@server:~$ pvesm status
Name        Type     Status     Total     Used    Available   %
local       dir      active    196G      22G        164G     11%
local-lvm   lvmthin  active    900G     610G        290G     67%
ceph-rbd    rbd      active     10T       6T          4T     60%

Значення: Стовпець Name (ідентифікатор сховища) має існувати як на джерелі, так і на цілі для дисків VM. Той же ID, сумісний бекенд.

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

Завдання 9: Перевірте фактичні томи дисків, на які посилається VM

cr0x@server:~$ qm config 101 | egrep '^(scsi|virtio|sata|ide)[0-9]+:'
scsi0: local-lvm:vm-101-disk-0,discard=on,iothread=1,size=80G
scsi1: ceph-rbd:vm-101-disk-1,size=200G

Значення: Змішане сховище — поширене явище. Воно також часто є пасткою при міграції: один диск шарований, інший — ні.

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

Завдання 10: Перевірте вільне місце там, куди має потрапити диск

cr0x@server:~$ lvs -a -o+lv_size,data_percent,metadata_percent,lv_attr,devices pve
  LV            VG  Attr       LSize   Data%  Meta%  Attr       Devices
  data          pve twi-aotz-- 900.00g  67.11  12.03 twi-aotz-- /dev/sda3(0)
  vm-101-disk-0 pve Vwi-aotz--  80.00g  92.30         Vwi-aotz-- data(12345)

Значення: Для thin-пулів слід стежити за Data% на пулі і конкретному LV. Високе заповнення пулу означає, що наступний запис може впасти посеред міграції.

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

Завдання 11: Перевірте здоров’я Ceph перед тим, як звинувачувати Proxmox

cr0x@server:~$ ceph -s
  cluster:
    id:     6e0e1d8a-5a1c-4b7a-a7a0-3f1b3e8c9c51
    health: HEALTH_WARN
            1 osds down
            Degraded data redundancy: 12/345678 objects degraded (0.003%)

  services:
    mon: 3 daemons, quorum a,b,c
    mgr: x(active), standbys: y
    osd: 9 osds: 8 up, 9 in

  data:
    pools:   4 pools, 512 pgs
    objects: 115k objects, 420 GiB
    usage:   1.2 TiB used, 8.8 TiB / 10 TiB avail
    pgs:     510 active+clean, 2 active+degraded

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

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

Завдання 12: Перевірте мережу міграції та MTU (мовчазний вбивця)

cr0x@server:~$ ip -br link show | egrep 'vmbr|bond|enp'
bond0            UP             3c:fd:fe:aa:bb:cc
vmbr0            UP             3c:fd:fe:aa:bb:cc
enp65s0f0        UP             3c:fd:fe:aa:bb:cc

cr0x@server:~$ ip link show vmbr0 | grep mtu
mtu 9000 qdisc noqueue state UP mode DEFAULT group default qlen 1000

cr0x@server:~$ ping -M do -s 8972 -c 3 10.10.0.12
PING 10.10.0.12 (10.10.0.12) 8972(9000) bytes of data.
8980 bytes from 10.10.0.12: icmp_seq=1 ttl=64 time=0.412 ms
8980 bytes from 10.10.0.12: icmp_seq=2 ttl=64 time=0.401 ms
8980 bytes from 10.10.0.12: icmp_seq=3 ttl=64 time=0.398 ms

--- 10.10.0.12 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2036ms

Значення: Якщо налаштовані jumbo frames, вони мають працювати в кінці в кінець. Якщо ви бачите «Frag needed» або втрати пакетів — готуйтеся до проблем під час міграції.

Рішення: Якщо MTU не збігається: або виправте мережу, або знизьте MTU до 1500 послідовно. Змішані MTU — це театральна продуктивність з високим рівнем жертв.

Завдання 13: Перевірте стан фаєрволу та правила (робота SSH — не доказ)

cr0x@server:~$ pve-firewall status
Status: enabled/running

cr0x@server:~$ iptables -S | head -n 20
-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT
-N PVEFW-FORWARD
-N PVEFW-INPUT
-N PVEFW-OUTPUT

Значення: Якщо Proxmox firewall увімкнений, переконайтесь, що трафік міграції дозволений на інтерфейсах, які використовуються. GUI може це показати, але CLI — швидша правда під час інцидентів.

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

Завдання 14: Шукайте помилки міграції на боці QEMU в journald

cr0x@server:~$ journalctl -u pvedaemon -u pveproxy -u pvestatd --since "1 hour ago" | tail -n 80
Dec 26 13:57:22 pve1 pvedaemon[1923]: starting migration of VM 101 to node 'pve2'
Dec 26 13:57:33 pve1 pvedaemon[1923]: migration aborted: QEMU exited with code 1
Dec 26 13:57:33 pve1 pvedaemon[1923]: ERROR: vm 101 - unable to migrate - VM uses local cdrom 'local:iso/installer.iso'

Значення: Це типова «очевидна заднім числом» перешкода, яку приховує верхня помилка.

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

Завдання 15: Підтвердіть налаштування сумісності CPU

cr0x@server:~$ qm config 101 | grep -E '^cpu:'
cpu: host,flags=+aes

cr0x@server:~$ pvesh get /nodes/pve1/capabilities/qemu/cpu | head
cputype
kvm64
qemu64
x86-64-v2-AES
x86-64-v3

Значення: cpu: host швидко працює, але прив’язує вас до фіч хоста. Міграція на вузол з іншою мікроархітектурою може невдатися або вимагати перезавантаження.

Рішення: Для кластерів з різними CPU стандартизуйте базову модель CPU для мігрувальних VM.

Завдання 16: Перевірте статус реплікації (користувачі ZFS replication)

cr0x@server:~$ pvesr status
JobID  Guest  Target  Last_sync              Status
101    101    pve2    2025-12-26 13:40:02    ok

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

Рішення: Виправте помилки реплікації спочатку; не використовуйте міграцію як інструмент налагодження реплікації.

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

1) Симптом: «storage not available on target»

Коренева причина: Ідентифікатор сховища у конфігу VM не існує на цілі або існує, але відрізняється (dir vs lvmthin vs zfs).

Виправлення: Узгодьте дефініції сховища між вузлами (pvesm status), або перемістіть диски на спільне сховище спочатку, або виконайте офлайн-міграцію з передачею дисків.

2) Симптом: Міграція відміняється після старту з «connection reset»

Коренева причина: Невідповідність MTU, фаєрвол блокує потік міграції, або перевантажений лінк спричиняє таймаут QEMU.

Виправлення: Тест MTU за допомогою ping -M do, перевірте правила фаєрволу, перенесіть міграцію на виділену мережу або зменшіть трафік у вікні.

3) Симптом: VM залишається заблокованою після відмови

Коренева причина: Очистка не завершилась; блокування лишилось у конфігу.

Виправлення: Перевірте, де VM працює (pvesh get /cluster/resources), потім qm unlock <vmid>. Очищайте часткові диски лише після впевненості, що вони не використовуються.

4) Симптом: «no quorum» або вузли кластера показуються як unknown

Коренева причина: Збій corosync, розділена мережа або проблеми синхронізації часу, що призводять до нестабільності членства.

Виправлення: Відновіть зв’язок corosync. Не мігруйте, поки pvecm status не покаже кворум і стабільність.

5) Симптом: Міграція не вдається лише для деяких VM

Коренева причина: Ці VM використовують cpu: host, passthrough-пристрої, локальні ISO або спеціальні пристрої, несумісні з ціллю.

Виправлення: Стандартизуйте моделі CPU, приберіть неміґрувальне обладнання, забезпечте доступність медіа з обох вузлів або виконайте офлайн-міграцію.

6) Симптом: Міграція «зависає» на високому відсотку довгий час

Коренева причина: Швидкість «брудних» сторінок перевищує пропускну здатність міграції; пам’ять змінюється швидше, ніж її можна скопіювати.

Виправлення: Зменште інтенсивність записів гостя (тимчасово), збільшіть пропускну здатність міграції або перейдіть на офлайн-міграцію для цього навантаження.

7) Симптом: Міграція відміняється і на цілі лишаються томи

Коренева причина: Копіювання диска частково завершилось; на цілі з’явились сиротливі томи або часткові dataset-и.

Виправлення: Визначте томи, що належать VMID, підтвердіть, що вони не посилаються жодним конфігом, потім видаліть їх. Якщо є сумнів — збережіть і змініть план на відновлення з бекапу/реплікації.

Короткий жарт №2: «Просто повторити» — це не стратегія; це як перетворити одну помилку на щотижневу рутину.

Три міні-історії зі світу корпоративної експлуатації (реалістично, анонімізовано)

Міні-історія 1: Інцидент, викликаний хибним припущенням

У них був двовузловий кластер Proxmox для внутрішніх інструментів. Нічого особливого: кілька десятків VM, локальне LVM-thin на кожному вузлі і нічні бекапи. Хтось попросив обслуговування на вузлі A, тож інженер на чергуванні вирішив «просто живо перемістити все на вузол B».

Припущення було простим: «Міграція — це переміщення обчислень». Вони вже використовували живу міграцію в іншому середовищі зі спільним сховищем і забули, що в цьому кластері диск жив локально. Перша міграція викинула «migration aborted», а інженер трактував це як «мережевий імпульс» і спробував ще раз. І ще.

Кожна спроба створювала часткові артефакти диска на цілі. LVM-thin ефективний, доки не стає іншим: метадані росли, thin-пул почав заповнюватись, і несуміжні VM на вузлі B почали відчувати паузи I/O. Проблема міграції перетворилась на проблему платформи.

Вони зрештою зупинились і подивились у конфіг VM. local-lvm не було спільним сховищем; це були два окремі острови з однаковою назвою в людській розмові, але не в Proxmox. Виправлення було нудним: припинити живі міграції, запланувати офлайн-міграцію з переміщенням сховища або відновити з бекапу на інший вузол.

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

Міні-історія 2: Оптимізація, що дала зворотний ефект

Інша компанія побудувала «швидку трасу» для Proxmox міграцій і трафіку Ceph. Включили jumbo frames, налаштували bonding, окремий VLAN — повний комплект. Графіки виглядали чудово. Оператори теж були в захваті. Тут сюжет загострюється.

Один комутатор у шляху мав порт з MTU 1500 через помилку шаблона. Більшість трафіку працювала нормально. SSH працював. Ceph майже працював, бо він стійкий і бо дрібні пакети переважали. Але живі міграції періодично abort-ились посеред потоку з невизначеними socket-помилками.

Інженери ганялися за примарами: версії Proxmox, оновлення ядра, опції QEMU. Декілька разів хтось радив «просто вимкнути фаєрвол». Це не допомогло. Хтось навіть звинуватив конкретний робочий навантаження, бо «він дуже швидко псує пам’ять». Частково це було правдою, але не корінною причиною.

Прорив стався після простого MTU-пробного тесту. Великі ICMP з прапором «do not fragment» падали по мережі міграції. Виправлення MTU на тім одному порті зробило міграції нудними замість випадкових.

Проблема не була в jumbo frames; проблема була в незбалансованих jumbo frames. Оптимізації, що вимагають ідеальної узгодженості інфраструктури, слід трактувати як виробничі зміни, а не як «мережеву приправу».

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

Команда, що експлуатувала Proxmox з різними поколіннями CPU, ще на ранньому етапі стандартизувала типи CPU для VM. Вони не використовували cpu: host для нічого, що може мігрувати. Вони вибрали базову модель CPU і задокументували її. Це коштувало трохи пікового швидкодії. Це кілька разів їх врятувало.

Одного дня вузол почав викидати помилки ECC пам’яті. Обладнання деградувало, але ще працювало. Треба було евакуювати VM швидко, щоб уникнути корупції, яку помічають лише на квартальних аудитах. Жива міграція була планом, і вона мала спрацювати.

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

Евакуація вдалася. Постмортем не мав драм. «Геройський хід» — це чекліст, якого вони дотримувались місяцями: узгоджені моделі CPU, узгоджені назви сховищ, періодична валідація шляху міграції.

Надійність — це здебільшого повторення. Захоплююча частина — опціональна.

Контрольні списки / покроковий план (чисте відновлення і запобігання)

Покроково: Чисте відновлення після abort-у міграції

1. Припиніть повторні спроби. Витягніть журнал завдання і визначте перший діючий рядок помилки.
2. Підтвердіть реальність VM. Де вона працює? Який вузол її власник згідно кластерних ресурсів?
3. Стабілізуйте кластер. Якщо кворум або corosync нестабільні — виправте це спочатку.
4. Перевірте блокування. Якщо VM заблокована через міграцію і ви маєте діяти, знімайте блокування тільки після визначення авторитетного вузла.
5. Перевірте топологію сховища. Диски на спільному сховищі? Існують ідентифікатори сховища на обох вузлах?
6. Перевірте артефакти дисків на цілі. Ідентифікуйте сирітливі томи/dataset-и; не видаляйте нічого, що не можете приписати.
7. Виберіть правильний метод міграції:
   • Спільне сховище здорове → жива міграція доречна.
   • Задіяне локальне сховище → плануйте міграцію сховища або офлайн-міграцію.
   • Присутня реплікація → переконайтесь, що реплікація актуальна і консистентна.
8. Повторіть один раз, з метою. Та сама помилка двічі означає, що ви не змінили умови. Не колекціонуйте помилки як картки.

Контрольний список запобігання: зробіть «migration aborted» рідшим

• Уніфікуйте ідентифікатори сховищ між вузлами. Одні й ті самі назви, одні й ті самі типи, одні й ті самі очікування.
• Базова модель CPU для мігрувальних навантажень. Уникайте cpu: host, якщо VM має мігрувати.
• Роздільні мережі де це практично: management, corosync, сховище, міграція. Принаймні ізолюйте конкуренцію за пропускну здатність.
• Періодична перевірка MTU в кінці в кінець (щоквартально, після змін в комутаторах, після оновлення прошивки). Jumbo frames — це контракт.
• Моніторинг здоров’я сховища (Ceph, ZFS, SMART). Міграції підсилюють слабкі сигнали.
• Документуйте VM, що не підлягають міграції (passthrough, ліцензійні обмеження, спеціальні пристрої), щоб черговий не дізнавався про це під час інциденту.
• Практикуйте міграції за розкладом. Якщо ви мігруєте лише в екстрених випадках, ви займаєтесь хаос-інженерією без переваг.

FAQ

1) Чому Proxmox показує лише «migration aborted» без чіткої причини?

Тому що верхній рівень завдання обгортає кілька підсистем. Діючий рядок зазвичай знаходиться раніше в журналі завдання або в journald для pvedaemon/qemu.

2) Чи можна жваво мігрувати VM з local-lvm?

Не як чисте переміщення обчислень. Якщо диски локальні на вузлі-джерелі, вам потрібна доступність диска на цілі (спільне сховище, реплікація або копія диска). Інакше Proxmox відмовиться.

3) Чи безпечно запускати qm unlock після проваленої міграції?

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

4) Чому міграція ламається на 90–99% і потім abort?

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

5) Чи означає «SSH працює», що мережа міграції в порядку?

Ні. SSH — це канал керування. Міграція QEMU — це дата-план, який може бути заблокований правилами фаєрволу, проблемами MTU або різницею маршрутизації, навіть якщо SSH ідеально працює.

6) Який найшвидший спосіб визначити, чи проблема в сховищі?

Перевірте рядки дисків у конфігу VM і порівняйте їх з pvesm status на цілі. Якщо вказаний ідентифікатор сховища не існує або не шарований — це проблема сховища.

7) Як обробити залишкові томи на цілі після неуспішної міграції сховища?

Ідентифікуйте томи за VMID, підтвердіть, що вони не посилаються жодним конфігом на цілі чи джерелі, потім видаліть їх. Якщо є невпевненість, збережіть їх і відновіть через backup/restore, щоб не видалити єдину робочу копію.

8) Чому налаштування CPU ламають міграцію?

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

9) Чи можуть проблеми Ceph проявлятися як «migration aborted», навіть якщо VM виглядає нормально?

Так. Міграція створює навантаження на сховище з метаданих, повторних підключень і іноді одночасних I/O-сплесків. Трохи деградований Ceph може «працювати», поки ви не попросите його зробити щось амбітне одночасно.

10) Коли слід перестати намагатись жваву міграцію і просто перейти в офлайн?

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

Наступні кроки (що робити після виправлення)

Після того, як міграція вдалась — або після того, як ви обрали правильний офлайн-шлях — виконайте ці практичні дії:

1. Запишіть кореневу причину у ваших оперативних нотатках. Наступний abort здаватиметься «новим», якщо ви його не позначите.
2. Нормалізуйте ідентифікатори сховища та моделі CPU по всьому кластеру. Це одна з нудних вправ, що щомісяця платить за себе.
3. Протестуйте мережу міграції з MTU-пробою і тестом пропускної здатності у тихому вікні. Зробіть це регулярно, а не коли щось зламалось.
4. Аудитуйте конфіги VM на предмет локальних ISO, passthrough-пристроїв і використання «host CPU». Визначте, які VM мають бути мігрувальними, і налаштуйте їх відповідно.
5. Очистіть артефакти після abort-ів: застарілі томи, старі снапшоти і залишкові завдання реплікації. Робіть це по доказах, а не за відчуттями.

Мета не в тому, щоб ліквідувати відмови. Мета — зробити відмови розбірними, відновлюваними і рідшими. «migration aborted» стане нудним, коли ваш кластер, мережа і сховище перестануть дивувати одне одного.