Міграція сховища з ESXi в Proxmox: переміщення VMFS на ZFS, NFS або iSCSI з мінімальним простоєм

Факти та контекст, які змінюють рішення

Ось кілька конкретних фактів та історичних відомостей, які важливі під час планування міграцій VMFS→Proxmox. Не дрібниці. Паливо для рішень.

1. VMFS створювався для одночасного доступу кількох ESXi-хостів, з примітивами блокування на диску, які припускають стек VMware. Linux може читати VMFS, але це не перший громадянин у світі Proxmox.
2. VMDK — це не «один формат». Є монолітні sparse, thick, split і stream-optimized варіанти. Шлях експорту (OVF/OVA) може непомітно змінити формат диска, який ви в результаті копіюєте.
3. ZFS починався в Sun Microsystems з філософією «end-to-end checksumming». Це важливо для образів ВМ, бо тихі пошкодження — реальний режим відмови, а не страшилка.
4. NFS існує з 1980-х і мав десятиліття, щоб стати нудним. У production-системах нудність — це фіча, про яку рідше викликають інженера у нічні години.
5. iSCSI — це блочне сховище по IP — отже хост ВМ відповідає за файлову систему (наприклад, ext4, xfs або ZFS). Це суттєво змінює тонку настройку продуктивності та домени відмов порівняно з NFS.
6. Зміни блоків у VMware (CBT) можуть зробити інкрементні копії швидкими у VMware, але це не нативна концепція Proxmox. Якщо ви опиралися на це опосередковано (продукти резервного копіювання), готуйтеся до зміни поведінки.
7. Тонке провізування — це політика, а не закон фізики. Перевищити виділення легко; повернути простір пізніше — ось де починається драма, особливо при конвертації форматів.
8. Вирівнювання секторів 4K раніше було опціональним. Тепер ні. Невірне вирівнювання може коштувати вам подвійних записів і «чому цей SSD повільніший за HDD?» моменти під час міграцій.

Жарт #1: Міграції сховища схожі на переїзд: коробки множаться, коли ви цього не помічаєте, і врешті ви несете принтер, яким не користувалися з 2017 року.

Виберіть місце приземлення: ZFS vs NFS vs iSCSI

ZFS на Proxmox (локально або розподілене через реплікацію)

Коли вибирати: Ви хочете сильну цілісність даних, снапшоти, просте оперативне управління і можете тримати диски ВМ локально на вузлі Proxmox (або погоджуєтесь на HA на основі реплікації, а не на спільне сховище).

Оперативна реальність: ZFS не «налаштував і забув». Це «налаштуй і моніторь». ZFS поводиться відмінно, якщо ви поважаєте його потреби: достатньо RAM, адекватні recordsize/volblocksize рішення й не видаєте RAIDZ1 з побутових SSD за ентерпрайз.

Кут мінімального простою: ZFS снапшоти та zfs send/zfs receive — ваші друзі для великих переносів і відтворюваних cutover-ів. Якщо можна заздалегідь підготувати dataset і зробити фінальний інкрементальний send під час короткого вікна простою — отримаєте передбачуваний downtime.

Не обирайте, якщо: вам потрібна семантика спільного сховища для live migration між вузлами і ви не хочете запускати розклад реплікації з логікою failover. Proxmox вміє реплікувати, але це не те саме, що «спільний datastore».

NFS (спільне сховище без iSCSI-поведінки)

Коли вибирати: Ви хочете спільне сховище, яке легко зрозуміти, у вас є надійний NAS або Linux NFS-сервер, і ви цінуєте простоту операцій і портативність.

Оперативна реальність: Продуктивність NFS сильно залежить від сервера, мережі та опцій монтування. Плюс: коли щось ламається, інструменти і ментальні моделі звичні. Мінус: якщо у вашій мережі є мікросплески, ви це помітите.

Кут мінімального простою: Спільний NFS дозволяє розміщувати диски ВМ централізовано, отже переміщення обчислювальної частини відбувається окремо. Для cutover вам досі потрібно копіювати дані, але коли диски вже на NFS, евакуація хосту набагато простіша.

Не обирайте, якщо: у вас лише перевантажена LAN без ізоляції трафіку і ви не можете виділити трафік сховища. NFS поверх ненадійної мережі — це як база даних на батуті.

iSCSI (блочне сховище з гострими краями)

Коли вибирати: У вас уже є SAN, вам потрібні блочні семантики, ви хочете мультипат і дисципліну управління. iSCSI підходить — якщо ви ставитесь до нього як до системи, а не як до галочки у списку.

Оперативна реальність: iSCSI дає режими відмов, які виглядають як «сховище повільне», але насправді це «один шлях флапає і multipath виконує інтерпретаційний танець». Моніторинг має включати стан шляхів і розподіл латентності, а не лише пропускну здатність.

Кут мінімального простою: Якщо iSCSI LUN вже є спільним бекендом, ви можете вільніше мігрувати обчислення. Проблема з копіюванням даних (VMFS → файлова система на LUN) залишається, але потім ви отримуєте більшу гнучкість.

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

Цільові архітектури, які реально працюють

Архітектура A: Один вузол Proxmox з локальним ZFS

Підходить для малих і середніх середовищ, лабораторій, віддалених офісів або команд, що мігрують поетапно. Розміщуйте ВМ на локальному пулі ZFS. Використовуйте снапшоти для відкатів. Реплікацію ZFS застосуйте для другого вузла як DR або «бідного HA».

Ключові рішення: mirror vs RAIDZ, SLOG чи ні, стиснення, ashift та як ви будете робити бекапи (Proxmox Backup Server або інші). Макет пулу — це двері в один бік.

Архітектура B: Кластер Proxmox зі спільним NFS

Це опція «зробити нудним». Спільне NFS-сховище для дисків ВМ + окрема мережа Proxmox для corosync + окремий шлях для бекапів. Live migration стає переміщенням обчислень, а не сховища.

Ключові рішення: дизайн NFS-сервера (часто NAS на ZFS), ізоляція мережі (VLAN або фізично окремі NIC), і опції монтування, що відповідають вашому навантаженню.

Архітектура C: Кластер Proxmox з iSCSI + multipath + LVM-thin або ZFS

Можна робити iSCSI LUN з LVM-thin, або iSCSI LUN, які споживає ZFS як vdev (не моя перша рекомендація, якщо ви не знаєте, навіщо це робите). Більшість команд роблять LVM-thin на iSCSI для блочного сховища.

Ключові рішення: політика multipath, глибина черги, параметри ALUA та як ви будете моніторити латентність по шляхах. Також: хто володіє конфігурацією SAN і як контролюються зміни.

Жарт #2: iSCSI — це як стосунки з чудовою хімією і жахливим спілкуванням — коли все добре, це блискуче; коли погано, це 3:00 ранку з Wireshark.

Передпольотні перевірки: інвентар, обмеження та арифметика простою

Зробіть інвентар віртуальних машин як слід

Ваш план міграції буде настільки добрий, наскільки добрий ваш інвентар. «Приблизно 40 ВМ» — це не інвентар. Інвентар включає: розміри дисків (виділені та використані), типи ОС, режими завантаження (BIOS vs UEFI), критичні сервіси, очікування RPO/RTO та чи підтримує гість коректне завершення роботи.

Вимірюйте швидкість змін, а не лише розмір

Якщо ВМ має 2 ТБ диска, але змінює 2 ГБ/день, ви можете заздалегідь підготувати більшу частину даних і зробити короткий cutover. Якщо зміна — 400 ГБ/день, вам потрібен холодний cut або стратегія реплікації на рівні застосунку.

Визначте, що означає «мінімальний простій»

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

Виберіть історію відкату перед стартом

Якщо ви не можете відкотитися, ви не мігруєте; ви граєте в рулетку. Відкат зазвичай означає: зберігайте ESXi-VM цілою, не видаляйте VMFS-дані та сплануйте зміни DNS/load balancer. Якщо потрібно повторно використовувати IP, підготуйте ARP-освіження та скидання стану firewall.

Практичні завдання з командами (і що вирішувати за виходом)

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

Завдання 1: Підтвердьте здоров’я вузла Proxmox і основи ядра

cr0x@server:~$ pveversion -v
pve-manager/8.2.2/1a2b3c4d (running kernel: 6.8.12-4-pve)

Що це означає: У вас сучасний реліз Proxmox з актуальним pve-kernel. Драйвери сховища і поведінка ZFS чутливі до ядра.

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

Завдання 2: Перевірте віртуалізацію CPU і IOMMU (для майбутньої сумісності)

cr0x@server:~$ lscpu | egrep -i 'Virtualization|Model name'
Model name:                           Intel(R) Xeon(R) Silver 4214R CPU @ 2.40GHz
Virtualization:                       VT-x

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

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

Завдання 3: Перевірте лінк NIC, швидкість і помилки (сховище по мережі залежить від цього)

cr0x@server:~$ ip -s link show dev eno1
2: eno1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
    link/ether 3c:ec:ef:12:34:56 brd ff:ff:ff:ff:ff:ff
    RX:  bytes packets errors dropped  missed   mcast
    9876543210  1234567      0      12       0       0
    TX:  bytes packets errors dropped carrier collsns
    8765432109  1122334      0       0       0       0

Що це означає: Помилок немає; кілька дропів можуть бути нормою при сплеску, але «12 dropped» — це запах, який варто зрозуміти.

Рішення: Якщо помилки зростають під час тестування — виправте кабелі/комутатор перед тим як звинувачувати NFS/iSCSI/ZFS.

Завдання 4: Перевірте jumbo frames наскрізь (лише якщо ви їх хочете)

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

--- 10.10.20.10 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2040ms

Що це означає: MTU 9000 працює по шляху. Якщо це не проходить — у вас немає jumbo frames; у вас фрагментація і сум.

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

Завдання 5: Створіть пул ZFS з правильним ashift (приклад: дзеркальні SSD)

cr0x@server:~$ sudo zpool create -o ashift=12 -o autotrim=on rpool mirror /dev/disk/by-id/nvme-SAMSUNG_MZVLB1T0HBLR-00000_S4X7NX0N123456 /dev/disk/by-id/nvme-SAMSUNG_MZVLB1T0HBLR-00000_S4X7NX0N789012
cr0x@server:~$ sudo zpool status rpool
  pool: rpool
 state: ONLINE
config:

        NAME                                                                STATE     READ WRITE CKSUM
        rpool                                                               ONLINE       0     0     0
          mirror-0                                                          ONLINE       0     0     0
            nvme-SAMSUNG_MZVLB1T0HBLR-00000_S4X7NX0N123456                  ONLINE       0     0     0
            nvme-SAMSUNG_MZVLB1T0HBLR-00000_S4X7NX0N789012                  ONLINE       0     0     0

errors: No known data errors

Що це означає: Пул здоровий; ashift=12 — розумний дефолт для 4K-секційних пристроїв (включно з багатьма SSD, що «брешуть» про сектори).

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

Завдання 6: Налаштуйте datasets ZFS для образів ВМ (volblocksize + compression)

cr0x@server:~$ sudo zfs create -o compression=zstd -o atime=off rpool/vmdata
cr0x@server:~$ sudo zfs get -o name,property,value compression,atime rpool/vmdata
NAME         PROPERTY     VALUE
rpool/vmdata compression  zstd
rpool/vmdata atime        off

Що це означає: Стиснення увімкнене (зазвичай виграш для образів ВМ), atime вимкнено (менше метадантичного шуму).

Рішення: Якщо ваше навантаження вже CPU-залежне — стиснення може нашкодити. Інакше воно часто покращує і простір, і продуктивність.

Завдання 7: Бенчмаркуйте латентність сховища нудним способом (fio, sync writes)

cr0x@server:~$ sudo fio --name=sync4k --directory=/rpool/vmdata --rw=randwrite --bs=4k --iodepth=1 --numjobs=1 --size=2G --direct=1 --fsync=1
sync4k: (g=0): rw=randwrite, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=psync, iodepth=1
fio-3.33
sync4k: (groupid=0, jobs=1): err= 0: pid=22110: Mon Dec 23 14:03:41 2025
  write: IOPS=4200, BW=16.4MiB/s (17.2MB/s)(2048MiB/124800msec)
    clat (usec): min=120, max=24000, avg=230.50, stdev=410.20

Що це означає: Середня 4K sync латентність ≈230 мкс — прийнятно для дзеркальних NVMe. Хвіст (max 24 ms) — те, що завдасть болю базам даних і сервісам, що інтенсивно логують.

Рішення: Якщо хвіст поганий — зупиніться. Виправте прошивку пристрою, перевірте налаштування кешу запису або перегляньте макет пулу перед імпортом продакшн-ВМ.

Завдання 8: Експортуйте диски ВМ із ESXi datastore на проміжний сервер (через SSH + vmkfstools copy)

cr0x@server:~$ ssh root@esxi-01 "vim-cmd vmsvc/getallvms | head"
Vmid   Name                 File                                 Guest OS           Version   Annotation
12     app01                [vmfs01] app01/app01.vmx              ubuntu64Guest      vmx-19
13     db01                 [vmfs01] db01/db01.vmx                centos7_64Guest    vmx-19

Що це означає: Ви можете перерахувати ВМ і знайти їхні VMX-шляхи. Звідти ви знайдете VMDK у каталозі ВМ.

Рішення: Якщо немає SSH до ESXi через політику — доведеться використовувати експорт (OVF/OVA) або відновлення з продукту резервного копіювання. Плануйте зміни формату і час.

Завдання 9: Підтвердьте тип VMDK і розмір на ESXi перед копіюванням

cr0x@server:~$ ssh root@esxi-01 "ls -lh /vmfs/volumes/vmfs01/app01 | egrep 'vmdk|vmx'"
-rw-------    1 root     root         8.0K Dec 20 10:12 app01.vmx
-rw-------    1 root     root         1.2K Dec 20 10:12 app01.vmdk
-rw-------    1 root     root        150G Dec 23 03:20 app01-flat.vmdk

Що це означає: Ця ВМ використовує дескриптор + flat extent (звично для thick-ish форматів). Копіюйте обидва. Дескриптор маленький, але потрібний.

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

Завдання 10: Копіюйте VMDK ефективно (rsync по SSH з можливістю відновлення)

cr0x@server:~$ rsync -avP --inplace -e ssh root@esxi-01:/vmfs/volumes/vmfs01/app01/ /srv/stage/app01/
sending incremental file list
app01.vmdk
          1,248 100%    1.19KB/s    0:00:01 (xfr#1, to-chk=1/3)
app01-flat.vmdk
  12,884,901,888  8%   112.34MB/s    0:19:42

Що це означає: Ви переміщаєте extent ≈112 MB/s. Опція --inplace допомагає відновлювати великі файли.

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

Завдання 11: Конвертуйте VMDK у raw або qcow2 на боці Proxmox

cr0x@server:~$ qemu-img info /srv/stage/app01/app01.vmdk
image: /srv/stage/app01/app01.vmdk
file format: vmdk
virtual size: 150 GiB (161061273600 bytes)
disk size: 150 GiB

cr0x@server:~$ qemu-img convert -p -f vmdk -O raw /srv/stage/app01/app01.vmdk /rpool/vmdata/app01-disk-0.raw
    (100.00/100%)

Що це означає: Ви валідували формат джерела і конвертували в raw, що просто і продуктивно на ZFS (ZVOL теж звично; raw файл на dataset — робочий варіант при налаштуванні).

Рішення: Якщо вам потрібні снапшоти на шарі сховища і тонке провізування — qcow2 може допомогти, але додає накладні витрати. Для продуктивних ВМ на ZFS зазвичай raw або ZVOL — правильний вибір.

Завдання 12: Імпортуйте диск у VM Proxmox і перевірте конфігурацію завантаження (BIOS/UEFI)

cr0x@server:~$ qm create 120 --name app01 --memory 8192 --cores 4 --net0 virtio,bridge=vmbr0
create VM 120: success

cr0x@server:~$ qm importdisk 120 /rpool/vmdata/app01-disk-0.raw rpool
importing disk 'app01-disk-0.raw' to VM 120 ...
transferred 0.0 B of 150.0 GiB (0.00%)
transferred 150.0 GiB of 150.0 GiB (100.00%)
Successfully imported disk as 'unused0: rpool:vm-120-disk-0'

cr0x@server:~$ qm set 120 --scsihw virtio-scsi-pci --scsi0 rpool:vm-120-disk-0 --boot order=scsi0
update VM 120: success

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

Рішення: Якщо ВМ не завантажується — перевірте прошивку (SeaBIOS vs OVMF), тип контролера диска (LSI vs virtio) і чи має ОС драйвери virtio.

Завдання 13: Налаштуйте NFS-сховище в Proxmox і перевірте монтування

cr0x@server:~$ sudo pvesm add nfs nfs-vmstore --server 10.10.20.10 --export /export/vmstore --content images,iso,backup --options vers=4.1
create storage 'nfs-vmstore'

cr0x@server:~$ pvesm status
Name         Type     Status     Total      Used      Available   %
local        dir      active     98.00GB    12.44GB    85.56GB   12.69%
nfs-vmstore  nfs      active     10.00TB     4.20TB     5.80TB   42.00%

Що це означає: Сховище змонтовано і видно. Якщо воно показує inactive — у вас проблеми з мережею/експортом/опціями.

Рішення: Якщо NFS активний, але продуктивність погана — перевірте кількість потоків на NFS-сервері, sync-налаштування і QoS мережі перед тим, як звинувачувати Proxmox.

Завдання 14: Налаштуйте iSCSI target і перевірте сесію/логін

cr0x@server:~$ sudo apt-get update -qq
cr0x@server:~$ sudo apt-get install -y -qq open-iscsi multipath-tools

cr0x@server:~$ sudo iscsiadm -m discovery -t sendtargets -p 10.10.30.20
10.10.30.20:3260,1 iqn.2001-04.com.example:san.lun01

cr0x@server:~$ sudo iscsiadm -m node -T iqn.2001-04.com.example:san.lun01 -p 10.10.30.20 --login
Logging in to [iface: default, target: iqn.2001-04.com.example:san.lun01, portal: 10.10.30.20,3260]
Login to [iface: default, target: iqn.2001-04.com.example:san.lun01, portal: 10.10.30.20,3260] successful.

Що це означає: Відкриття пройшло і ви залогінені. Наступний крок — перевірка sanity multipath і створення файлової системи/LVM.

Рішення: Якщо discovery пустий — у вас ACL на таргеті, проблеми з VLAN/маршрутизацією або невідповідність CHAP. Виправте це перед налаштуванням сховища Proxmox.

Завдання 15: Перевірте multipath і стан шляхів (iSCSI)

cr0x@server:~$ sudo multipath -ll
mpatha (36001405abcde1234567890fedcba9876) dm-2 DGC,VRAID
size=2.0T features='1 queue_if_no_path' hwhandler='1 alua' wp=rw
|-+- policy='service-time 0' prio=50 status=active
| `- 3:0:0:10 sdb 8:16 active ready running
`-+- policy='service-time 0' prio=10 status=enabled
  `- 4:0:0:10 sdc 8:32 active ready running

Що це означає: Є два шляхи; один active/optimized (prio 50). Це бажана поведінка для масивів з ALUA.

Рішення: Якщо бачите лише один шлях — не продовжуйте. Виправте резервну мережу зараз; пізніше робити це під навантаженням буде важче.

Завдання 16: Перевірте здоров’я ZFS і виявляйте тихі проблеми зарані

cr0x@server:~$ sudo zpool iostat -v rpool 2 3
                              capacity     operations     bandwidth
pool                        alloc   free   read  write   read  write
--------------------------  -----  -----  -----  -----  -----  -----
rpool                        320G   612G    120    450  12.3M  55.1M
  mirror-0                   320G   612G    120    450  12.3M  55.1M
    nvme-SAMSUNG...123456      -      -     60    225  6.1M   27.5M
    nvme-SAMSUNG...789012      -      -     60    225  6.2M   27.6M
--------------------------  -----  -----  -----  -----  -----  -----

Що це означає: Балансоване I/O по дзеркалу і адекватний throughput. Якщо один пристрій показує дивні латентні сплески — це видно в шаблонах zpool iostat.

Рішення: Якщо один vdev відстає — замініть його перед міграцією. Не «моніторьте до відмови» під час тижня cutover-ів.

Методи міграції: холодний, тепловий та «не робіть так»

Метод 1: Холодна міграція (вимкнути ВМ, скопіювати диски, завантажити на Proxmox)

Це стандарт, бо передбачувано. Ви вимикаєте ВМ на ESXi, копіюєте фінальний стан диска, конвертуєте/імпортуєте, завантажуєте на Proxmox, валідуєте сервіси і оновлюєте мережу/DNS.

Профіль простою: Може бути великий, але обмежений та зрозумілий. Ви можете протестувати процес імпорту заздалегідь з клонуванням або експортом снапшоту.

Де виграє: Бази даних з жорсткою консистентністю, застарілі ОС або коли ви не довіряєте реплікації на рівні гостя.

Метод 2: Стадійне копіювання + короткий cutover (копіюємо більшість даних заздалегідь, потім фінальний синхрон)

Якщо ВМ може працювати під час підготовки (або ви можете взяти снапшот), можна скоротити простій до «фінальна дельта + завантаження». Типовий підхід:

• Підготуйте повну копію VMDK(ів) на трансфер-хості.
• Заплануйте вікно cutover.
• Вимкніть ВМ, зробіть фінальний rsync/копію (мала дельта, якщо швидкість змін низька), конвертуйте/імпортуйте, завантажте.

Профіль простою: Часто відмінний для ВМ з низькою швидкістю змін. Ключ — не обманювати себе щодо швидкості змін.

Метод 3: Реплікація на рівні застосунку (мінімальний простій, але більше складності)

Для великих баз даних або систем з інтенсивним записом копіювання образу диска часто невірна абстракція. Реплікуйте на рівні застосунку: реплікація бази даних, файлова реплікація або специфічний sync сервіс, потім переключення клієнтів.

Профіль простою: Може бути дуже малим, але оперативно важчим. Також вимагає, щоб застосунок мав чистий план failover.

Метод 4: «Примонтувати VMFS і копіювати з Linux» (працює, але не романтизуйте)

Можна монтувати VMFS-томи з Linux за допомогою інструментів типу vmfs-fuse і копіювати VMDK. Це корисно в критичній ситуації, коли ESXi мертвий, але LUNи живі. Але це не найчистіший первинний план. Часто доступно лише для читання, продуктивність змінюється і ви додаєте ще один шар абстракції в стресовий момент.

Методи, яких слід уникати, якщо ви не знаєте, навіщо

• «Ми просто конвертуємо безпосередньо з ESXi datastore онлайн.» Якщо datastore зайнятий, ви конкуруєте з продакшн I/O під час копіювання. Так народжуються інциденти.
• «Ми будемо використовувати qcow2 скрізь, бо це гнучко.» Гнучкість не безкоштовна. qcow2 може бути прийнятним, але це додаткові CPU і метадантичні накладні витрати. Використовуйте там, де є причина (снапшоти, thin), а не як релігію.
• «Ми запустимо RAIDZ для випадкових записів ВМ і пощастить.» RAIDZ чудовий для послідовних робочих навантажень і ємності. Поведінка випадкових записів ВМ покаже, чому існують дзеркала.

Контрольні списки / покроковий план

Чекліст A: Визначте цільове сховище (10 хвилин на рішення)

1. Якщо вам потрібне спільне сховище для live migration зараз, віддавайте перевагу NFS (нудно) або iSCSI (гостро) залежно від середовища.
2. Якщо ви віддаєте перевагу цілісності даних + передбачуваній експлуатації і можете прийняти локальні диски + реплікацію, обирайте ZFS локально.
3. Якщо у вас вже є SAN і є досвід з multipath, iSCSI підходить. Якщо ні — не вчіться під час тижня міграцій.

Чекліст B: Стадія перед міграцією (зробіть це до дотику до продакшн-ВМ)

1. Побудуйте сховище Proxmox (ZFS/NFS/iSCSI) і проганяйте fio з sync writes.
2. Перевірте узгодженість MTU мережі і лічильники помилок.
3. Створіть хоча б одну тестову ВМ на Proxmox; переконайтесь, що бекапи працюють.
4. Виберіть одну не критичну ESXi ВМ; проведіть повну репетицію міграції і задокументуйте точні кроки та часи.
5. Визначте відкат: ESXi ВМ залишається вимкненою, але цілою до підтвердження; зміни DNS відслідковуються; правила firewall/NAT підготовані.

Чекліст C: План cutover (для кожної ВМ)

1. Підтвердьте останню робочу резервну копію та тест відновлення (так, справді протестуйте).
2. Повідомте зацікавлених з вікном простою, що включає час валідації.
3. Коректно вимкніть гість (спочатку зупиніть застосунок для баз даних).
4. Виконайте фінальне копіювання диска / фінальну дельту.
5. Конвертуйте/імпортуйте диск у формат сховища Proxmox.
6. Встановіть прошивку/контролер ВМ відповідно до вимог гостьової ОС.
7. Спочатку завантажуйте в ізольованому VLAN або з відключеною мережею, якщо потрібно уникнути IP-конфліктів.
8. Перевірте здоров’я сервісів (systemd, логи, перевірки застосунків).
9. Переключіть трафік (DNS/LB) і моніторьте.
10. Тримайте опцію відкату протягом визначеного періоду; потім знешкодьте старі артефакти ВМ.

Чекліст D: Закріплення після міграції (бо майбутньому собі доведеться це обслуговувати)

1. Увімкніть бекапи Proxmox з політикою зберігання і періодичними тестами відновлення.
2. Налаштуйте розклад scrub для ZFS і оповіщення, або перевірки здоров’я NFS/iSCSI з оповіщеннями по латентності.
3. Документуйте топологію сховища: пули, datasets, експорти, LUN ID, WWID multipath.
4. Зніміть базову метрику латентності диска зсередини гостя (щоб мати «нормальне» значення).

Швидкий план діагностики: знайдіть вузьке місце швидко

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

Перше: чи мережа?

• Перевірте помилки/дропи інтерфейсів на хості Proxmox і на портах сховища/комутатора.
• Зробіть MTU ping тест (тільки якщо використовуєте jumbo frames).
• Виміряйте сирий throughput з iperf3 між Proxmox і NFS/iSCSI-ендпоінтами.

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

Друге: чи латентність пристрою (tail latency)?

• Проганяйте fio з --fsync=1 і малими блоками (4k/8k), щоб імітувати найгірші записи ВМ.
• На ZFS використовуйте zpool iostat, щоб подивитися, чи якийсь пристрій не веде себе дивно.
• На iSCSI перевірте стан multipath і латентність по шляхах, якщо масив надає такі дані.

Інтерпретація: Середні IOPS можуть виглядати добре, а хвилі латентності руйнують бази даних. Довіряйте хвостам.

Третє: чи це контеншн або неправильна конфігурація на хості?

• Шукайте CPU steal / насичення CPU хоста під час конвертації.
• Перевірте, що диски ВМ використовують virtio-scsi, а не емуляцію контролера, якщо це не потрібно.
• Переконайтесь, що ви випадково не на повільному бекенді (наприклад local dir на обертальних дисках).

Інтерпретація: Якщо хост зайнятий конвертацією кількох дисків одночасно, ви самі робите сховище повільним. Обмежте амбіції.

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

1) Симптом: Швидкість копіювання застряє на 20–40 MB/s у 10Gb мережі

Корінна причина: вузьке місце в одному TCP-потоці, погані налаштування NIC offload або ви читаєте з зайнятого VMFS datastore під навантаженням.

Виправлення: Перевірте з iperf3. Якщо мережа в порядку — робіть копію зі снапшоту або в години, коли datastore спокійний. Розгляньте паралелізацію обережно (два потоки допомагають; двадцять можуть спалити масив джерела).

2) Симптом: ВМ завантажується на Proxmox, але файлову систему змонтовано лише для читання

Корінна причина: Непослідовність файлової системи від некоректного вимкнення або неповної копії; інколи — несумісність драйверів/контролера, що призводить до тайм-аутів.

Виправлення: Робіть чисте вимкнення на ESXi. Перекопіюйте після вимкнення. Запустіть fsck (Linux) або chkdsk (Windows) під час валідації в ізольованій мережі.

3) Симптом: ВМ не завантажується; потрапляє в EFI shell або «no bootable device»

Корінна причина: Невідповідність прошивки (UEFI vs BIOS), відсутній EFI-диск, неправильний порядок завантаження або завантажувач прив’язаний до типу контролера.

Виправлення: Зіставте прошивку: SeaBIOS для BIOS-інсталяцій, OVMF для UEFI. Додайте EFI-диск для OVMF. Переконайтесь, що диск прикріплено як scsi0/virtio, де ОС очікує його.

4) Симптом: NFS сховище активне, але I/O ВМ стрибкоподібні і латентність стрибає

Корінна причина: sync-налаштування NFS-сервера, перевантажений CPU NAS або мережеві мікросплески/дропи. Іноді це один поганий NIC/порт.

Виправлення: Перевірте лічильники помилок NIC і статистику порту комутатора. Валідуйте версію NFS (4.1 часто поводиться краще) і кількість серверних потоків. Ізолюйте трафік сховища, якщо можете.

5) Симптом: Продуктивність iSCSI LUN нормальна, поки шлях не відвалиться, потім все зависає

Корінна причина: Налаштування multipath (queue_if_no_path без адекватних таймаутів), ALUA не дотримується або асиметричні шляхи не опрацьовуються.

Виправлення: Виправте політику multipath і таймаути. Перевірте пріоритети ALUA. Натренуйте контролюваний відмовний сценарій перед продакшн cutover.

6) Симптом: ZFS пул виглядає здоровим, але записи ВМ повільні

Корінна причина: RAIDZ при випадковому навантаженні записів, нестача RAM (ARC misses) або неправильне розуміння SLOG (додавання повільного SLOG може зашкодити).

Виправлення: Дзеркала для пулів з інтенсивними випадковими I/O ВМ. Не купуйте дешевий SSD для SLOG; якщо вам не потрібна синхронна семантика, не додавайте його. Міряйте через fio.

7) Симптом: Прогресує «зникнення» місця після міграції

Корінна причина: Товсті диски створені з тонких джерел, вибір попереднього виділення qcow2, або застарілі снапшоти на новому бекенді.

Виправлення: Усвідомлено вирішуйте thin vs thick. Відслідковуйте снапшоти і очищуйте. На ZFS стежте за referenced vs used; на LVM-thin стежте за використанням даних+метаданих.

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

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

У них був чудовий план: експортувати ВМ з ESXi, імпортувати в Proxmox, вказати все на нове NFS-сховище. Команда зробила пілот на двох малих Linux ВМ — все виглядало нормально, і PowerPoint майже написав себе.

Неправильне припущення було простим: «Якщо NFS змонтовано, продуктивність буде в порядку». Ніхто не виміряв хвостову латентність. Ніхто не перевірив буфери комутатора. VLAN сховища ділив uplink з трафіком бекапів, а бекапи запускалися, коли команда бекапів почувалася духовно натхненною натиснути «run now».

Вночі cutover, на Proxmox потрапив навантажена Windows file server ВМ. Користувачі в понеділок вранці скаржилися, що Explorer «зависає». ВМ не була падучою; це було гірше — жива і страждаюча. На хості NFS I/O мав періодичні застої; всередині гостя SMB таймаути накопичувались як погані рішення.

Команда гналася за привидами: драйвери virtio, Windows-оновлення, антивірус, навіть DNS. Зрештою хтось побудував графік латентності NFS і помітив, що сплески збігаються з бекап-трафіком на тих самих uplink.

Виправлення було нудним: виділити пропускну здатність для сховища, ввести QoS і розклад бекапів з дисципліною, зазвичай зарезервованою для виплати зарплат. Урок був гострим: «Воно змонтовано» — це не тест продуктивності. Це ледве привітання.

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

Інша команда хотіла швидкості. Вони вибрали ZFS для локального сховища ВМ і прочитали кілька впевнених постів в інтернеті про SLOG. Тож вони додали «швидкий» побутовий NVMe як SLOG, бо він був під рукою і фраза «separate intent log» звучала як чит-код.

Навколишнє навантаження було змішаним. Деякі ВМ були базами даних з синхронними записами. Інші — загальні аплікації. Тиждень все було нормально. Потім побутовий NVMe почав видавати періодичні сплески латентності під тривалим sync-навантаженням. Не повний вихід з ладу. Гірше: напіввихід.

ZFS зробив те, що ZFS робить: зберіг коректність. Продуктивність же впала на краю під час цих сплесків. ВМ отримали періодичні паузи I/O. Команда інтерпретувала це як «ZFS повільний» і почала крутити ручки: зміна recordsize, вимкнення стиснення, налаштування ARC. Вони перетворили ситуацію на тижневий фестиваль тюнінгу.

Справжня проблема була в «оптимізації»: SLOG не мав захисту від втрати енергії і мав непередбачувану латентність під sync-навантаженням. Видалення SLOG і повернення до дзеркальних ентерпрайз SSD відновило стабільну поведінку. Пізніше вони додали правильний SLOG з PLP тільки після вимірювання, що sync-навантаження дійсно виграють від нього.

Оптимізація — це не про додавання частин. Це про зменшення невизначеності. Коли ви додаєте компонент з непередбачуваною латентністю, ви оптимізуєте під розподіл провини.

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

Одна компанія у фінансовій сфері мала перенести старі, але критичні ВМ: ліцензійний сервер, внутрішній додаток і базу даних, яку всі робили вигляд, що вона неважлива, поки не зламалась. У них було суворе вікно змін і керівники, які чули «віртуальний» і думали, що це означає «миттєво».

Практика команди була нестерпно нудною: кожна міграція ВМ мала відрепетируваний рукбук, таймінг-лист і відкатну вправу. Також вони зберігали ESXi ВМ цілими протягом «періоду впевненості» після cutover. Ніхто не мав права очищати простір раніше, якою б привабливою не була пуста datastore.

Під час реального cutover база даних імпортувалася, але не завантажувалась через невідповідність прошивки: ESXi мав UEFI, а початкова Proxmox ВМ створена з SeaBIOS. Це проста правка, але не весела, коли тече відлік простою.

Оскільки вони репетирували, вони швидко впізнали режим відмови. Переключили VM на OVMF, додали EFI-диск, виправили порядок завантаження і завантажили чисто. Загальна затримка: хвилини, а не години.

Справжнє спасіння сталося пізніше: підсумковий додаток мав хардкодну IP для бази даних, і NAT правило мережної команди не застосовувалось у новому сегменті. Відкат не був теоретичним. Вони відкотили трафік, виправили NAT і знову зробили cutover. Нудна практика — рукбуки і дисципліна відкату — перемогла кмітливість. Щоразу.

Одна цитата про надійність (погоджено з операціями)

Парафразована ідея (приписується Gene Kim): «Покращення надійності часто означає покращення потоку роботи і зворотного зв’язку, а не просто додавання контролів.»

FAQ

1) Чи може Proxmox читати VMFS напряму?

Не в підтримуваний, первинний спосіб для записів у production. Іноді можна прочитати VMFS-томи з Linux за допомогою допоміжних інструментів і витягнути дані. Розцінюйте це як техніку відновлення, а не основний канал міграції.

2) Чи конвертувати VMDK у qcow2 або raw?

Для продуктивних ВМ raw (або диски на ZVOL) зазвичай безпечніший вибір. qcow2 корисний, коли потрібні функції, як прості снапшоти на файловому шарі або тонке провізування, але це додає накладні витрати.

3) Який найкращий варіант для live migration у Proxmox?

Спільне сховище (зазвичай NFS або iSCSI зі спільним блочним бекендом) робить live migration простішою. Локальний ZFS все ще працює з підходами на основі реплікації, але це не та сама модель «спільного datastore».

4) Як мінімізувати простій для великих ВМ?

Або заздалегідь підготуйте більшість даних і зробіть короткий фінальний синхрон у вікні cutover, або реплікуйте на рівні застосунку (реплікація БД, синхрон файлів). Копіювання образів дисків саме по собі не переможе фізику для систем з високою швидкістю змін.

5) Чи потрібні драйвери virtio?

Linux загалом добре працює з virtio. Windows часто потребує драйверів virtio залежно від інсталяції і типу контролера. Якщо ви міняєте контролери (наприклад з LSI на virtio-scsi), плануйте наявність драйверів перед cutover.

6) Дзеркала чи RAIDZ для ZFS VM storage?

Дзеркала для VM-важких випадкових I/O. RAIDZ чудовий для ємності і послідовних навантажень, але може «нагородити» випадкові записи і хвостову латентність — саме те, що генерує ВМ.

7) Чи потрібен SLOG для ZFS?

Ні. SLOG важливий тільки для синхронних записів, коли ви використовуєте sync=standard і навантаження дійсно виконує sync. Поганий SLOG може погіршити продуктивність. Використовуйте його лише після вимірювання і вибирайте обладнання з захистом від втрати живлення.

8) NFS чи iSCSI для спільного сховища?

NFS зазвичай простіший у експлуатації і діагностиці. iSCSI може бути відмінним при належній мультипат і дисципліні SAN, але вимагає більше конфігурації і має цікавіші режими відмов.

9) Як валідувати продуктивність після міграції?

Вимірюйте з обох сторін: на рівні хоста (fio, zpool iostat, стан multipath) і всередині гостя (латентність застосунку, латентність файлової системи, час комітів БД). Користувачі відчувають латентність, а не throughput.

10) Яка найнадійніша стратегія відкату?

Зберігайте оригінальну ESXi ВМ вимкненою, але цілою, доки не підтвердите функціональність і продуктивність на Proxmox і не пройдете визначений період спостереження. Відкат має бути процедурою, не відчуттям.

Висновок: наступні кроки, які ви можете виконати

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

1. Виберіть місце приземлення: ZFS локально (цілісність + простота), NFS (спільне + нудне), або iSCSI (спільне + гостре).
2. Бенчмаркуйте те, що важливо: sync 4K латентність і хвостову поведінку, а не лише великий послідовний throughput.
3. Репетируйте одну ВМ від початку до кінця: копіювання, конвертація, імпорт, завантаження, валідація, відкат. Заміряйте час.
4. Підготуйте дані заздалегідь для ВМ з низькою зміною; для систем з високою змінністю використовуйте реплікацію на рівні застосунку.
5. Робіть cutover з можливістю відкату, і не видаляйте VMFS-дані, поки не виживете в реальності.

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