Перенесення ESXi до Proxmox V2V: найкращі методи та підводні камені

Цікаві факти та коротка історія (щоб рішення мали сенс)

• OVF створювали для портативності, а не для досконалості. Це стандарт упаковки (дескриптор + диски), але постачальники люблять «розширення», і саме там портативність гине.
• VMDK старший за сучасну «хмарну» парадигму. Він народився у світі thick-дисків на SAN, тому випадки з тонким провізіюванням часто працюють доти, доки не перестають.
• KVM став модулем ядра Linux у 2007 році. Саме ця зміна (апаратна віртуалізація в ядрі) робить Proxmox не науковим експериментом.
• Virtio — це контракт продуктивності. Це не просто «драйвер», а паравіртуалізований інтерфейс, який міняє сумісність на швидкість — чудово, коли драйвери є, болісно — коли їх немає.
• QCOW2 створили для снапшотів і гнучкості. RAW — тупо-швидкий; QCOW2 — зручний для операцій. Вибирайте залежно від бекенда сховища та звичок опсів.
• Снапшоти VMware ніколи не були резервними копіями. Це журнали переадресації; якщо їх лишати, ви побудуєте машину затримок, яка рано чи пізно закінчить місце.
• UEFI vs BIOS — це лінія розлому епох міграції. Багато старих ВМ — BIOS/MBR; сучасні шаблони — UEFI/GPT. Конвертувати диски простіше, ніж розв’язувати припущення завантажувача.
• Інструменти VMware ховають складнощі ідентичності пристроїв. Коли переходите на KVM, MAC, моделі NIC та контролерів знову набувають значення.
• «qm importdisk» у Proxmox має власну думку. Воно прагне приєднати імпортовані диски до конфігурації ВМ і цільового сховища; це не універсальний конвертер, а інструмент робочого процесу.

Одна перефразована ідея від Gene Kim, що працює в кожній міграції: Покращуйте систему роботи, а не героїчні подвиги; надійність приходить від повторюваного потоку. (перефразовано)

Вибір методу: OVF/OVA проти qemu-img проти Clonezilla

Мій суб’єктивний правило вибору

• Якщо можете вимкнути ВМ і маєте доступ до VMDK: використовуйте qemu-img + імпорт у Proxmox. Ви отримаєте контроль, передбачуваний результат і менше «магічних» шарів.
• Якщо потрібна артефактна портативність або ви прив’язані до експорту через vCenter: використовуйте OVF/OVA, але розглядайте це як спосіб упаковки, а не гарантію повної сумісності.
• Якщо ВМ — аплайянс зі дивними завантажувачами або ви не довіряєте форматам дисків: використовуйте Clonezilla і клонуйте на рівні файлової системи/блоку.

Торги, які важливі в продакшні

• Простій: усі три методи краще працюють при вимкненні ВМ. Існують живі конверсії; вони також дають новий зміст слову «непослідовність».
• Точність: Clonezilla може давати найвищу вірність «того, що на диску», але вона не розуміє семантики віртуалізації (контролери, тип NIC). OVF інколи зберігає більше метаданих.
• Швидкість: qemu-img → RAW на швидкому локальному сховищі зазвичай найшвидший варіант. Експорт OVF може бути повільним через перепакування і компресію.
• Можливість налагодження: qemu-img і raw-файли легко інспектувати. OVA — це tarball з дескриптором, що додає ще один шар під час стресу.

Жарт №1: V2V — як переїзд квартири — упакувати легко, а ось знайти коробку з кавоваркою — справжній простій.

Підготовка: інвентаризація, фріз та проєктні рішення

Що треба вирішити перед тим, як торкатися хоч одного диска

• Режим завантаження: BIOS або UEFI у цільовій ВМ. Підтримуйте режим джерела, якщо вам не до вподоби археологія завантажувачів.
• Шина диска: VirtIO SCSI зазвичай правильний вибір у Proxmox. SATA — парашут сумісності. IDE — для музеїв.
• Модель NIC: VirtIO для продуктивності; E1000, якщо потрібно «щоб завантажилось без драйверів».
• Бекенд сховища: ZFS, LVM-thin або Ceph. Це змінює, чи RAW чи QCOW2 буде розумним вибором і впливає на тонке налаштування продуктивності.
• Мережа: імена бриджів, тегування VLAN, MTU і чи зміна MAC спричинить проблеми з ліцензіями або DHCP-резерваціями.
• План відкату: тримайте ESXi-ВМ вимкненою та цілою, поки Proxmox-ВМ не пройде принаймні одне перезавантаження та успішний цикл резервного копіювання.

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

Завдання 1: Підтвердити підтримку віртуалізації на узлі Proxmox

cr0x@pve1:~$ egrep -m1 -o 'vmx|svm' /proc/cpuinfo
vmx

Що це означає: vmx (Intel VT-x) або svm (AMD-V) має бути присутнім.

Рішення: Якщо відсутній — зупиніть. KVM без цього перетворюється на QEMU TCG емулювання і сум.

Завдання 2: Перевірити типи сховища Proxmox і вільне місце

cr0x@pve1:~$ pvesm status
Name             Type     Status           Total            Used       Available        %
local             dir     active        196473240        5123456       185678912        2.61%
local-zfs         zfspool active       1889785616      934281216       955504400       49.44%

Що це означає: У вас є директоріальний сховищe (local) і ZFS пул (local-zfs) з приблизно 955 ГБ вільного місця.

Рішення: Оберіть ціль. Для ZFS RAW підходить, бо ZFS вже реалізує copy-on-write та снапшоти.

Завдання 3: Інвентаризація апаратури ВМ у ESXi (з експортованого конфига)

cr0x@jump:~$ grep -E 'firmware|scsi|ethernet|nvram|virtualHW' vm1/vm1.vmx
virtualHW.version = "14"
firmware = "efi"
scsi0.virtualDev = "pvscsi"
ethernet0.virtualDev = "vmxnet3"
nvram = "vm1.nvram"

Що це означає: UEFI, PVSCSI контролер, vmxnet3 NIC.

Рішення: У Proxmox плануйте UEFI (OVMF) і VirtIO SCSI + VirtIO net (або тимчасово E1000 для Windows, якщо драйвери не підготовлені).

Завдання 4: Виявити снапшоти ESXi перед експортом

cr0x@esxi1:~$ vim-cmd vmsvc/getallvms | grep -i vm1
12   vm1   [datastore1] vm1/vm1.vmx   ubuntu64Guest   vmx-14

cr0x@esxi1:~$ vim-cmd vmsvc/snapshot.get 12
Get Snapshot:
|--ROOT
   |--Snapshot Name        : pre-upgrade
   |--Snapshot Id          : 1
   |--Snapshot Created On  : 2025-12-01
   |--Snapshot State       : powered off

Що це означає: Снапшоти існують. Експорти можуть захопити ланцюжки дельт або консолідувати їх автоматично.

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

Завдання 5: Підтвердити, що ВМ вимкнена (послідовність важливіша за героїзм)

cr0x@esxi1:~$ vim-cmd vmsvc/power.getstate 12
Retrieved runtime info
Powered off

Що це означає: Вимкнено. Це чистий стан, який потрібен для конверсії на рівні диска.

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

Метод 1: експорт OVF/OVA + імпорт у Proxmox

Коли OVF/OVA — правильний вибір

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

Де OVF/OVA підводить

• Метадані NIC/контролера не відображаються коректно у KVM-пристроях.
• Деякі експорти виробляють «streamOptimized» VMDK, які валідні, але потребують додаткового кроку конвертації.
• Опис OVF може містити VMware-специфічні секції; Proxmox більшість ігнорує.

Практичні завдання з OVF/OVA

Завдання 6: Перевірте OVA перед довір’ям

cr0x@pve1:~$ tar -tf vm1.ova | head
vm1.ovf
vm1.mf
vm1-disk1.vmdk

Що це означає: OVA — це tar, який містить OVF-дескриптор, маніфест і диск.

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

Завдання 7: Перевірити контрольні суми у маніфесті OVF

cr0x@pve1:~$ sha1sum -c vm1.mf
vm1.ovf: OK
vm1-disk1.vmdk: OK

Що це означає: Перевірки цілісності пройшли. Якщо не OK — не «пробуйте все одно». Експортуйте або передайте знову.

Рішення: Продовжуйте лише коли контрольні суми в порядку; корупція тут дорого обходиться пізніше.

Завдання 8: Створіть пусту оболонку ВМ у Proxmox, що відповідає режиму завантаження

cr0x@pve1:~$ qm create 120 --name vm1 --memory 8192 --cores 4 --machine q35 --bios ovmf --net0 virtio,bridge=vmbr0
create VM 120: success

Що це означає: ВМ 120 створена, UEFI прошивка, VirtIO мережа.

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

Завдання 9: Конвертуйте VMDK з OVA у RAW або QCOW2 і імпортуйте

cr0x@pve1:~$ qemu-img info vm1-disk1.vmdk
image: vm1-disk1.vmdk
file format: vmdk
virtual size: 80G (85899345920 bytes)
disk size: 22G
cluster_size: 65536
Format specific information:
    cid: 2155942229
    parent cid: 4294967295
    create type: streamOptimized

cr0x@pve1:~$ qemu-img convert -p -f vmdk -O raw vm1-disk1.vmdk /var/lib/vz/images/120/vm-120-disk-0.raw
    (progress output omitted)

Що це означає: Це streamOptimized VMDK. Потрібна конвертація; Proxmox не запустить його прямо.

Рішення: Використовуйте RAW для ZFS/LVM-thin бекендів, якщо вам не потрібні особливості QCOW2 на директоріальному сховищі.

Завдання 10: Приєднайте імпортований диск і встановіть порядок завантаження

cr0x@pve1:~$ qm set 120 --scsihw virtio-scsi-pci --scsi0 local-zfs:vm-120-disk-0
update VM 120: -scsihw virtio-scsi-pci -scsi0 local-zfs:vm-120-disk-0

cr0x@pve1:~$ qm set 120 --boot order=scsi0
update VM 120: -boot order=scsi0

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

Рішення: Якщо Windows не завантажується, тимчасово приєднайте як SATA і виправте драйвери, потім поверніть назад.

Метод 2: VMDK → QCOW2/RAW з qemu-img (мій дефолт)

Чому цей метод перемагає в більшості випадків

Якщо ви можете забрати VMDK(и) з datastore (або підключитись до них через NFS/SSH з оболонки ESXi), qemu-img дає детермінований процес.
Ви контролюєте формати, можете інспектувати ланцюжок, обирати sparse або повністю алоковані цілі, і виконувати конвертацію на самому вузлі Proxmox поруч із цільовим сховищем.

Дві конверсії, які вам дійсно потрібні

• VMDK → RAW: найкраще, коли цільове сховище вже робить снапшоти/COW (ZFS, Ceph RBD). Швидко, просто, менше шарів.
• VMDK → QCOW2: корисно на директоріальному сховищі, коли ви хочете снапшоти на рівні образу (і готові до накладних витрат), або для портативності.

Практичні завдання з qemu-img

Завдання 11: Підтвердити, що VMDK — не забутий ланцюжок снапшотів

cr0x@pve1:~$ qemu-img info -U vm1-flat.vmdk
image: vm1-flat.vmdk
file format: raw
virtual size: 80G (85899345920 bytes)
disk size: 80G

Що це означає: Це raw «flat» extent, а не дельта-ланцюжок. Саме те, що вам потрібно.

Рішення: Якщо ви бачите parent/child відносини (backing file), зупиніться і консолідуйте на ESXi спочатку.

Завдання 12: Конвертувати з прогресом і розумними дефолтами

cr0x@pve1:~$ qemu-img convert -p -f vmdk -O raw vm1.vmdk /tank/images/120/vm-120-disk-0.raw
    (progress output omitted)

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

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

Завдання 13: Правильно імпортувати диск у сховище Proxmox (qm importdisk)

cr0x@pve1:~$ qm importdisk 120 /tank/images/120/vm-120-disk-0.raw local-zfs
importing disk '/tank/images/120/vm-120-disk-0.raw' to VM 120 ...
transferred 0.0 B of 80.0 GiB (0.00%)
transferred 80.0 GiB of 80.0 GiB (100.00%)
Successfully imported disk as 'local-zfs:vm-120-disk-0'

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

Рішення: Віддавайте перевагу qm importdisk коли можливо; воно підтримує порядок обліку сховища.

Завдання 14: Підтвердити, що конфіг ВМ посилається на правильний диск і контролер

cr0x@pve1:~$ qm config 120
bios: ovmf
boot: order=scsi0
cores: 4
memory: 8192
name: vm1
net0: virtio=DE:AD:BE:EF:12:20,bridge=vmbr0
scsi0: local-zfs:vm-120-disk-0
scsihw: virtio-scsi-pci

Що це означає: Диск на scsi0 з VirtIO SCSI. UEFI увімкнено.

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

Метод 3: Clonezilla (коли потрібне «просте, але надійне»)

Коли Clonezilla — правильний інструмент

• Аплайянсні ВМ з дивними розділеннями, кастомними завантажувачами або вендорними ядрами, до яких ви не хочете торкатися.
• Ситуації, коли формати дисків заплутані (ланцюжки снапшотів, streamOptimized експорти, невідомі VMDK варіанти).
• Коли треба мігрувати між повністю різними макетами сховища і ви віддаєте перевагу копіюванню використаних блоків на файловому рівні.

Чого Clonezilla за вас не зробить

• Вона не встановить драйвери VirtIO у Windows.
• Вона не зіставить модель NIC VMware з семантикою Proxmox.
• Вона не зробить режим завантаження сумісним; вам все одно потрібно налаштувати BIOS/UEFI правильно.

Практичні завдання з Clonezilla (і операційний підхід)

Завдання 15: Створіть цільову ВМ із консервативними пристроями для першого запуску

cr0x@pve1:~$ qm create 130 --name vm1-clone --memory 8192 --cores 4 --machine q35 --bios seabios --net0 e1000,bridge=vmbr0 --sata0 local-zfs:80
create VM 130: success

Що це означає: BIOS-ВМ з E1000 NIC і SATA диском. Сумісні «нудні» налаштування за замовчуванням.

Рішення: Використовуйте це, якщо не впевнені у драйверах гостя. Коли стане стабільно — переходьте на VirtIO для продуктивності.

Завдання 16: Переконайтесь, що новий диск існує і має правильний розмір перед клонуванням

cr0x@pve1:~$ lsblk -o NAME,SIZE,TYPE,MODEL | grep -E 'zd|sd'
sda   447.1G disk  Samsung_SSD
zd0    80G   disk

Що це означає: Proxmox створив віртуальний диск (zvol ZFS відображається як zd0).

Рішення: Якщо розмір неправильний — видаліть і створіть заново. Клонування в неправильний розмір — чудовий спосіб зустріти свого майбутнього on-call.

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

Особливості гостьової ОС: Windows, Linux, аплайянси

Windows: драйвери та завантаження — це все

Міграції Windows зазвичай падають через дві причини: драйвери контролера сховища і невідповідність режиму завантаження. Все інше — другорядне.
Якщо ваша Windows-ВМ використовувала VMware PVSCSI і vmxnet3, вона автоматично не матиме драйверів VirtIO для сховища та мережі.
Ви все ще зможете завантажити систему, якщо спочатку оберете сумісні пристрої (SATA + E1000), встановите драйвери VirtIO, а потім перемкнете контролери.

Завдання 17: Додайте ISO з драйверами VirtIO і «безпечний NIC» для першого запуску

cr0x@pve1:~$ qm set 120 --ide2 local:iso/virtio-win.iso,media=cdrom
update VM 120: -ide2 local:iso/virtio-win.iso,media=cdrom

cr0x@pve1:~$ qm set 120 --net0 e1000,bridge=vmbr0
update VM 120: -net0 e1000,bridge=vmbr0

Що це означає: Драйвери VirtIO доступні гостю; NIC встановлено як E1000 для сумісності.

Рішення: Завантажтеся, встановіть драйвери VirtIO, потім переключіть net0 назад на VirtIO.

Завдання 18: Після встановлення драйверів перемкніть диск на VirtIO SCSI (вікно техобслуговування)

cr0x@pve1:~$ qm set 120 --scsihw virtio-scsi-pci
update VM 120: -scsihw virtio-scsi-pci

Що це означає: Тип контролера встановлено. Можливо, вам все ще потрібно перемістити диск з SATA на SCSI в конфігу, якщо ви використовували SATA як проміжний етап.

Рішення: Міняйте один клас пристроїв за раз: спочатку NIC, потім сховище. Не накопичуйте невизначеність.

Linux: зазвичай працює, якщо не трапилося непередбачуване

Сучасні ядра Linux включають драйвери VirtIO. Поширений режим відмови — коли initramfs не містить потрібного драйвера сховища у старих ВМ,
або коли ім’я мережевого інтерфейсу (predictable network names) змінилося і ваша статична конфігурація вказує на відсутній інтерфейс.

Завдання 19: Якщо Linux завантажується, але мережа мертва — підтвердьте стан лінку з боку Proxmox

cr0x@pve1:~$ qm monitor 120
Enter QEMU Monitor for VM 120 - type 'help' for help
(qemu) info network
hub 0
  netdev net0, peer=(null)
    virtio-net-pci.0: mac=DE:AD:BE:EF:12:20
    link=up
(qemu) quit

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

Рішення: Перевірте udev/прогнозовані імена, статичні IP-настройки та правила фаєрвола всередині гостя.

Аплайянси: ставтесь до них як до чорних скриньок

Вендорні аплайянси часто прив’язують модулі ядра до конкретних ідентифікаторів пристроїв. Найкраща стратегія — консервативне віртуальне обладнання спочатку (SATA, E1000),
завантажитись, перевірити сервіси, і лише потім намагатись перейти на VirtIO, якщо вендор це підтримує.

Сховище в Proxmox: ZFS/LVM-thin/Ceph і чому це важливо

ZFS: чудові дефолти, але гострі краї

ZFS відмінний для Proxmox, бо снапшоти й реплікація — нативні, а scrubs показують реальний стан дисків.
Але ZFS теж дуже чесний: якщо ви перевантажите RAM, позбавите ARC або оберете неправильний recordsize/volblocksize для zvol, він дасть вам це відчути.

Завдання 20: Перевірити стан ZFS пулу перед імпортом великих дисків

cr0x@pve1:~$ zpool status -x
all pools are healthy

Що це означає: Жодних відомих помилок. Імпорт на деградований пул — шлях перетворити міграцію на відновлення даних.

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

Завдання 21: Спостерігати симптоми write amplification у ZFS під час конверсії

cr0x@pve1:~$ zpool iostat -v 2
              capacity     operations     bandwidth
pool        alloc   free   read  write   read  write
----------  -----  -----  -----  -----  -----  -----
tank        890G   890G     12    420   3.1M   210M
  mirror    890G   890G     12    420   3.1M   210M
    sda        -      -      6    210   1.6M   105M
    sdb        -      -      6    210   1.5M   105M

Що це означає: Під час конверсії домінують операції запису. Це нормально; конверсії інтенсивно навантажують запис.

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

LVM-thin: просто та швидко, але з меншими можливостями

LVM-thin простий у використанні і добре працює для багатьох робочих навантажень. Снапшоти є, але це інший операційний досвід ніж у ZFS.
RAW-образи на LVM-thin — типовий вибір; QCOW2 додає накладні витрати без значного виграшу.

Ceph: відмінно на масштабі, болісно при неправильному розмірі

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

Жарт №2: Ceph — як груповий проєкт: коли працює — прекрасний, коли ні — всі звинувачують мережу.

Міграція мережі: бриджі, VLAN, MAC та несподівані міжмережеві екрани

Відображення бриджів: vmbr0 — не універсальна константа

В ESXi port group абстрагує багато чого. В Proxmox Linux-бриджі й VLAN-aware бриджі — явні. Це добре. Саме тут помилки стають видимими.
ВМ може «працювати», але опинитися на неправильному L2 острові.

Завдання 22: Підтвердити налаштування бриджа та VLAN-aware на Proxmox

cr0x@pve1:~$ cat /etc/network/interfaces | sed -n '1,120p'
auto lo
iface lo inet loopback

auto enp3s0
iface enp3s0 inet manual

auto vmbr0
iface vmbr0 inet static
        address 10.10.10.11/24
        gateway 10.10.10.1
        bridge-ports enp3s0
        bridge-stp off
        bridge-fd 0
        bridge-vlan-aware yes

Що це означає: vmbr0 VLAN-aware. Це звичне налаштування «зроби правильно один раз».

Рішення: Якщо потрібне тегування VLAN на ВМ — зберігайте VLAN-aware і ставте теги на NIC ВМ.

Завдання 23: Підтвердити тег NIC і MAC у конфігу ВМ

cr0x@pve1:~$ qm config 120 | grep -E '^net0'
net0: virtio=DE:AD:BE:EF:12:20,bridge=vmbr0,tag=120

Що це означає: ВМ на VLAN 120 через тегування.

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

Завдання 24: Перевірити, чи хост не відкидає пакети через фаєрвол

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

cr0x@pve1:~$ pve-firewall localnet
allow 10.0.0.0/8
allow 192.168.0.0/16

Що це означає: Фаєрвол увімкнений. Правила localnet існують; правила для трафіку ВМ окремі, але стан фаєрвола хоста важливий при відлагодженні.

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

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

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

По-перше: чи конверсія/завантаження заблоковані сховищем?

• Перевірте здоров’я ZFS/LVM/Ceph і поточні I/O.
• Шукайте дрібні випадкові записи, спричинені QCOW2 поверх COW сховища.
• Перевірте, чи випадково не конвертуєте sparse-диск у повністю алокований на повільному сховищі.

Завдання 25: Виявити латентність сховища та насичення (рівень хоста)

cr0x@pve1:~$ iostat -xm 2 3
Linux 6.8.12-4-pve (pve1) 	12/28/2025 	_x86_64_	(16 CPU)

Device            r/s     w/s   rkB/s   wkB/s  avgrq-sz avgqu-sz   await  %util
sda              2.1   210.5    92.4  105432.0   998.3     2.41   11.5   92.3
sdb              2.0   209.8    88.7  105120.4   995.1     2.38   11.3   91.9

Що це означає: ~92% завантаження і ~11 мс очікування. Сховище зайняте; конверсія буде обмежена диском.

Рішення: Обмежте паралельність (одна конверсія за раз), конвертуйте спочатку на локальний NVMe або плануйте роботу в низьконавантажені вікна.

По-друге: чи ви CPU-зв’язані під час конверсії (компресія, контрольні суми, шифрування)?

Завдання 26: Перевірити насичення CPU під час qemu-img convert

cr0x@pve1:~$ mpstat -P ALL 2 2
Linux 6.8.12-4-pve (pve1) 	12/28/2025 	_x86_64_	(16 CPU)

12:02:10 PM  CPU   %usr  %nice  %sys  %iowait  %irq  %soft  %idle
12:02:12 PM  all   42.1   0.0   8.3    18.7    0.0   0.7   30.2

Що це означає: Значний %iowait; не чисто CPU-зв’язано. CPU має запас, але вузьке місце — сховище.

Рішення: Зосередьтесь на шляху зберігання, а не на налаштуванні CPU.

По-третє: якщо ВМ працює погано, чи це драйвери (VirtIO) чи макет сховища?

• Windows без драйверів VirtIO повільно працюватиме на IDE/SATA і E1000, і ви подумаєте, що Proxmox повільний. Це не так. Проблeма — у вас.
• Linux з неправильним планувальником вводу/виводу або без TRIM на SSD-backed thin-сховищі може деградувати з часом.

Завдання 27: Підтвердити, що ВМ використовує очікувані настройки кешу і discard

cr0x@pve1:~$ qm config 120 | grep -E 'scsi0|sata0|cache|discard|iothread'
scsi0: local-zfs:vm-120-disk-0

Що це означає: Явних налаштувань cache/discard не видно; застосовуються значення за замовчуванням.

Рішення: Для SSD-backed сховища з тонким провізіюванням розгляньте увімкнення discard=on та IO thread для важких дисків після підтвердження підтримки TRIM у гості.

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

1) ВМ не завантажується: «No bootable device»

Симптом: Консоль Proxmox показує UEFI shell або помилку BIOS завантаження.

Корінь: Невідповідність BIOS/UEFI (джерело був BIOS, ціль — OVMF, або навпаки). Або порядок завантаження вказує на неправильний диск.

Виправлення: Підлаштуйте прошивку під джерело. Встановіть правильний порядок завантаження. Якщо потрібно, додайте EFI-диск для UEFI-гістьових систем і перевірте запис завантаження.

2) Windows сині екрани на початку (INACCESSIBLE_BOOT_DEVICE)

Симптом: BSOD одразу після логотипу Windows.

Корінь: Контролер сховища змінився на VirtIO без наявних драйверів.

Виправлення: Поверніть SATA тимчасово, завантажтеся, встановіть драйвер VirtIO з ISO, потім перемкніть на VirtIO SCSI.

3) ВМ завантажується, але мережа мертва

Симптом: Гість не отримує IP, не пінгується шлюз або DHCP не відповідає.

Корінь: Відсутній/неправильний VLAN-тег, невідповідність бриджу, зміна MAC і DHCP-резервації відкидають його, або гостьова ОС перейменувала інтерфейс (Linux).

Виправлення: Підтвердьте бридж і тег у qm config. Перевірте trunk на верхньому комутаторі і наявність VLAN. Зберігайте MAC, якщо ліцензії/DHCP на ньому залежать. Виправте конфігурацію інтерфейсу гостя.

4) Конверсія повільна до неймовірності

Симптом: qemu-img convert повзає, хост відчутно повільний.

Корінь: Вузьке місце в сховищі, конвертація у повністю алокований RAW на повільних дисках, або конкуренція за I/O (інші ВМ, scrub, резервні копії).

Виправлення: Запускайте одну конверсію за раз; перемістіть конверсію на швидкий локальний SSD/NVMe; уникайте QCOW2 поверх ZFS без потреби.

5) ВМ швидка день, потім продуктивність падає

Симптом: Зростає затримка, особливо при записах.

Корінь: Тонке провізіювання без discard/TRIM, накопичення снапшотів або взаємодія кешу запису гостя з налаштуваннями синку сховища.

Виправлення: Увімкніть discard де доречно, слідкуйте за гігієною снапшотів і узгодьте політику кешу з моделлю надійності сховища.

6) Диск здається «більшим» або «меншим», ніж очікувалося

Симптом: Гість бачить неправильну ємність або помилки файлової системи.

Корінь: Обрано неправильний диск у багатодисковій ВМ, конвертація дельти замість бази, або невідповідність розміру секторів/геометрії в старих ОС.

Виправлення: Перевірте відповідність кожного VMDK до кожного диска Proxmox. Консолідуйте снапшоти. Для дуже старих гостьових систем віддавайте перевагу Clonezilla або залишайте консервативні контролери.

7) Імпортований диск займає повний розмір на ZFS, хоча на ESXi був thin

Симптом: Тонкий 2 ТБ диск перетворився на страхітливе алокаційне явище.

Корінь: Ви конвертували в RAW так, що записали нульові блоки, або імпортували на тип сховища, який не зберігає sparse так, як ви припускали.

Виправлення: Використовуйте перетворення, що зберігають sparsity, і перевіряйте фактичне зайняття блоків. Для великих sparse-дисків розгляньте QCOW2 на dir-сховищі або обережний імпорт RAW у тонкий zvol.

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

План A (рекомендовано): конверсія з qemu-img з контрольованими змінами апаратури

1. Інвентаризація джерела: прошивка (BIOS/UEFI), диски, контролери, тип NIC, снапшоти.
2. Консолідуйте снапшоти: не мігруйте дельта-ланцюжки, якщо вам не подобається невизначеність.
3. Вимкніть ВМ: послідовність важливіша за хитрість.
4. Скопіюйте VMDK на хост для конверсії: бажано на вузол Proxmox або близький staging-бокс.
5. Інспектуйте за допомогою qemu-img: підтвердіть формат і виявіть backing files.
6. Конвертуйте в RAW (ZFS/Ceph) або QCOW2 (dir): обирайте формат за бекендом, а не за відчуттями.
7. Створіть оболонку ВМ у Proxmox: співставте прошивку, почніть із сумісних пристроїв для Windows.
8. Імпортуйте диск: використайте qm importdisk коли можливо; приєднайте як потрібний шину.
9. Перший запуск в «безпечному режимі» апаратури: E1000 + SATA, якщо драйвери невідомі.
10. Встановіть драйвери VirtIO: потім переключіть NIC на VirtIO, потім диск на VirtIO SCSI.
11. Валідація: тест перезавантаження, перевірка сервісів, прикладні тести, пробний бекап.
12. Перехід: зміни DNS/IP, оновлення моніторингу, виведення ESXi-копії лише після стабільності.

План B: OVF/OVA коли потрібен портативний артефакт

1. Експортуйте OVA/OVF з vCenter/ESXi.
2. Перевірте контрольні суми у файлi маніфесту.
3. Витягніть диски та інспектуйте за допомогою qemu-img info.
4. Конвертуйте у RAW/QCOW2; не намагайтесь «просто приєднати» streamOptimized VMDK.
5. Створіть Proxmox-ВМ з відповідною прошивкою, приєднайте диск, виправте пристрої/драйвери.

План C: Clonezilla для аплайянсів та дивних випадків

1. Створіть цільову ВМ з консервативними пристроями (BIOS + SATA + E1000).
2. Завантажте Clonezilla і клоніруйте з образу/шару джерело на цільовий диск.
3. Завантажте ціль, перевірте працездатність додатків.
4. Лише після цього намагайтеся покращувати до VirtIO, якщо підтримується.

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

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

Одна команда з фінансової галузі перенесла кілька Windows серверів з ESXi у Proxmox. Вони зробили те, що здавалось розумним:
конвертували диски, створили ВМ і «модернізували» все до VirtIO відразу. Перший запуск не пройшов, тож вони переключили кілька налаштувань,
спробували ще раз і врешті-решт змогли завантажити один сервер. Вони оголосили перемогу і запланували решту.

У ніч перехідного етапу три ВМ закрутились у цикл перезавантажень з INACCESSIBLE_BOOT_DEVICE. Та, що запустилася, залишилася без мережі, бо також переключили NIC на VirtIO,
а ОС не мала драйвера. Їхнє припущення було простим: «Windows знайде драйвери як Linux.» Не знайде.

Негайне виправлення було клопітким, але ефективним: повернутися на SATA для завантаження, приєднати ISO з VirtIO драйверами, інсталювати драйвери в гості, потім по черзі змінювати контролери.
Більш масштабне виправлення — культурне: ставитись до змін пристроїв як до міграції схеми. Підготуйте, протестуйте, і лише тоді рухайтесь далі.

Постмортем був коротким і корисним: у них не було стандартного «профілю першого запуску». Після цього всі Windows V2V починалися з SATA + E1000,
потім переходили на VirtIO після підтвердження драйверів. Повільніше, але повторювано. Продакшн цінує повторюваність.

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

Інша організація вирішила бути хитрою щодо сховища. Вони мігрували флот Linux ВМ і обрали QCOW2 скрізь, бо «снапшоти гарні».
Їхній Proxmox був на ZFS. Вони фактично наклали copy-on-write поверх copy-on-write. В тестах все було нормально, бо тести були короткі і ввічливі.
Продакшн — ні.

Перший сигнал — підвищена латентність запису в пікові години. Бази даних шуміли. CI ранери гальмували. Потім резервні вікна почали зсуватися.
Команда почала налаштування: режими кешу, глибина черги, кілька sysctl. Деякі зміни тимчасово допомагали, але це було лише пересування болю.

Зрештою вони зробили нудну вимірювальну роботу: iostat на хості, zpool iostat і латентність на рівні ВМ. Шаблон був очевидний — випадкове write amplification і метаданний шум.
QCOW2 робив свою роботу; ZFS — свою; разом вони робили надто багато роботи.

Вони пересунули «гарячі» ВМ на RAW на zvol і лишили QCOW2 для кількох випадків, де портативність важливіша за продуктивність. Латентність запису нормалізувалась.
Урок — не «QCOW2 поганий». Урок — не накладайте функції одна на одну, якщо не готові платити за це у вигляді латентності і складності.

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

Компанія в суміжній із охороною здоров’я галузі мусила мігрувати мішанину ВМ у жорсткі вікна змін. Вони не були модними. Вони були дисципліновані.
Кожна ВМ проходила однаковий pre-flight чеклист: статус снапшотів, перевірка вимкнення, валідація контрольних сум експорту і задокументований крок відкату.
Кожна мігрувана ВМ мала пройти «два перезавантаження і один бекап» перед тим, як копія ESXi була видалена.

Посеред проєкту перемикач сховища почав періодично скидати пакети на мережі міграції. Нічого не впало повністю.
Замість цього кілька OVA трансферів прийшли пошкодженими. Команда не помітила одразу — поки перевірка маніфесту не почала падати.
Цей один нудний крок не дозволив їм імпортувати пошкоджені диски і потім дебажити фантомні помилки файлової системи.

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

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

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

1) Чи може Proxmox безпосередньо імпортувати OVF і відтворити апаратну конфігурацію ВМ?

Не в тому сенсі, як це робить vSphere. Зазвичай ви створюєте оболонку ВМ самі і імпортуєте/конвертуєте диски. Очікуйте ручного зіставлення пристроїв.

2) Що обрати: QCOW2 або RAW у Proxmox?

RAW на ZFS і Ceph зазвичай правильний вибір. QCOW2 підходить на директоріальному сховищі, коли потрібні снапшоти на рівні образу або портативність.
Не накладайте QCOW2 на ZFS, якщо ви не розумієте, за що платите.

3) Яка модель NIC найбезпечніша для першого запуску?

E1000 — загальний вибір сумісності, особливо для Windows. Після інсталяції драйверів перемикайтеся на VirtIO для продуктивності.

4) Який контролер диска безпечний для першого запуску на Windows?

SATA. Завантажуйтеся з SATA, встановіть драйвери VirtIO, потім перемикайте диск на VirtIO SCSI (по одному зміненому пристрою).

5) Моя ESXi ВМ використовувала UEFI. Що робити у Proxmox?

Використовуйте OVMF (--bios ovmf) і зазвичай додайте EFI-диск, якщо потрібно. Тримайте режим завантаження послідовним, інакше опинитесь у EFI shell.

6) Чи можна мігрувати ВМ зі снапшотами?

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

7) Чому мій імпортований диск займає більше місця, ніж thin VMDK?

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

8) Як визначити, чи вузьке місце під час конверсії — мережа, диск чи CPU?

Вимірюйте на вузлі Proxmox: iostat для насичення диска, mpstat для iowait vs CPU, та специфічні інструменти сховища (як zpool iostat).
Не «налаштовуйте», поки не знатимете, що саме насичено.

9) Чи потрібно зберігати MAC-адреси?

Іноді. Резервації DHCP, системи ліцензування і правила фаєрволу можуть орієнтуватись на MAC. Якщо не знаєте — збережіть MAC і змінюйте пізніше свідомо.

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

1. Оберіть метод для кожної ВМ: за замовчуванням — qemu-img; OVA — коли потрібен артефакт; Clonezilla — для аплайянсів і дивних завантажувачів.
2. Уніфікуйте «профіль першого запуску»: відповідність BIOS/UEFI, SATA + E1000 для Windows якщо драйвери не підготовлені, потім перехід на VirtIO.
3. Зробіть конверсію вимірюваною: запускайте iostat/mpstat/zpool iostat під час перших конверсій і записуйте, як виглядає «норма».
4. Вимагаємо два перезавантаження і один бекап перед тим, як виводити ESXi-оригінал з експлуатації. Якщо цього не зробити — всесвіт навчить вас, чому такий крок існує.
5. Документуйте відображення пристроїв (disk1 → scsi0, disk2 → scsi1, теги VLAN, MAC). Помилки міграції люблять невизначеність.

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