Як мігрувати з VMware ESXi до Proxmox VE (покроково): ВМ, диски, VLAN, простої

Що ви насправді мігруєте (це не тільки ВМ)

Господарство ESXi — це набір домовленостей, які ви не записали: які VLAN існують, які NIC — trunk-и, які datastore «достатньо швидкі»,
які ВМ дозволено запускати на старому віртуальному апаратному забезпеченні, і які тихо накопичують snapshot-и ще з кварталу тому.
Proxmox із задоволенням запустить ваші навантаження, але не збереже ці домовленості, якщо ви спеціально їх не відтворите.

Думайте про міграцію як про чотири незалежні переміщення:

• Семантика обчислень: експозиція моделі CPU, поведінка NUMA, тип контролера диска, прошивка (BIOS vs UEFI), secure boot, таймери.
• Семантика сховища: thin vs thick, snapshot-и, порядок записів, глибина черги, TRIM/discard, вирівнювання, налаштування кешу.
• Семантика мережі: теги VLAN, MTU, LACP, навчання MAC, режим promiscuous (рідко потрібно, часто «включено випадково»).
• Операційна семантика: бекапи, відновлення, моніторинг, вікна обслуговування та як ви відкочуєтеся, коли ВМ не завантажується.

Ваша мета не «запустити». Ваша мета — «зробити нудно». Нудність — це перевага.

Факти та контекст, що впливають на рішення

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

1. VMDK старший за більшість ваших інструментів. Формати віртуальних дисків VMware розвивалися поруч із VMFS і ланцюгами snapshot-ів; довгоживучі ВМ часто несуть у собі спадкові припущення (наприклад, тип контролера).
2. QCOW2 не створювався як «формат для продуктивності». Він гнучкий (snapshot-и, стиснення), але raw на ZFS або LVM-thin часто простіший і швидший для багатьох продукційних навантажень.
3. Virtio став де-факто стандартом для продуктивності KVM, бо емулювання дороге. Якщо лишити NIC і диск як e1000/IDE «для безпеки», ви платитимете за це вічно.
4. OVF/OVA були призначені для портативності, але справжня портативність залежить від драйверів. Експорт appliance не гарантує його чисте завантаження на іншому віртуальному апаратному забезпеченні.
5. Snapshot-и ESXi — не бекапи, і структура файлів це показує. Ланцюг дельта-дисків поводиться як Jenga-кубик: стабільний, поки ви його не зачепите.
6. Кластерна модель Proxmox проста навмисно. Вона створена так, щоб невелика команда могла її обслуговувати без окремої управлінської площини; ця простота перекладає відповідальність за мережу й сховище на вас.
7. Мости Linux з підтримкою VLAN зрілі. Це вже не 2008 рік. Linux bridge з VLAN filtering може замінити багато випадків vSwitch — якщо ви правильно відобразите теги.
8. ZFS має довгу пам’ять. Він захистить вас від мовчазної корупції, але також збережe ваші погані рішення (наприклад, невідповідний recordsize для баз даних) до тих пір, поки ви не налаштуєте його.

Одна цитата, щоб тримати вас у реаліях і виправдати параноїдальність у плані змін:
Надія — не стратегія. — James R. Schlesinger

Предпольотний інвентар: що виміряти перед будь-якими діями

Якщо ви не можете перерахувати VLAN-и, використання datastore і прошивку ВМ, ви не мігруєте — ви граєте в азартну гру з додатковими кроками.
Інвентаризація не гламурна. Ні інцидентний звіт.

Що інвентаризувати (мінімум)

• Список ВМ: ім’я, CPU, RAM, диски, кількість NIC, ОС, критичність, власник, вікно обслуговування, RPO/RTO.
• Розклад дисків: які VMDK тонкі, ланцюжки snapshot-ів і на якому datastore вони лежать.
• Прошивка: BIOS vs EFI. Secure boot важливіший, ніж здається.
• Мережа: порт-групи, VLAN ID, trunk-порти, MTU, LACP, uplink-и.
• Спеціальні пристрої: USB passthrough, послідовні порти, GPU, донгли, passthrough фізичних NIC.
• Залежності часу: NTP-пул, контролери домену, ліцензійні сервери.
• Бекапи: що можна відновити, як швидко і чи хтось цього року це тестував.

Жарт №1: Єдина річ більш постійна, ніж «тимчасове» правило для firewall — це «тимчасовий» snapshot ВМ.

Вирішіть наперед: холодна міграція чи часткова жива?

При ESXi → Proxmox «жива міграція» не є стандартним шляхом, якщо ви не додаєте проміжні інструменти реплікації.
Для більшості організацій надійний підхід — холодна міграція для кожної ВМ (вимкнути, експорт/копіювати, імпортувати, завантажити).
Ваш час простою в основному визначається копіюванням диска та перевіркою після запуску.

Можна зменшити простої за допомогою:

• Попереднього насичення дисків під час роботи ВМ (скопіювати VMDK на проміжне сховище, потім зробити фінальний синхрон під час простою).
• Реплікації на рівні додатків (реплікація БД, синхрон файлів), потім переключення кінцевих точок.
• Паралелізму (кілька ВМ за вікно), але не перенавантажуйте сховище й не дивуйтеся результату.

Цільова архітектура на Proxmox: сховище, типи CPU, модель мережі

Proxmox дає вам багато свободи — з нею можна побудувати чудову платформу або «артісанальний» збій. Визначте базу і стандартизуйтесь.

Обчислення: обирайте сумісність спочатку, потім продуктивність

Для змішаних кластерів почніть з консервативного типу CPU (x86-64-v2 або подібного базового рівня), щоб ВМ могли переміщатися між вузлами пізніше.
Якщо у вас назавжди по одній ноді на ВМ — добре, використовуйте host для максимальної продуктивності. Але будьте чесні щодо майбутнього.

• Шина диска: VirtIO SCSI (single) або VirtIO Block; уникайте IDE/SATA, якщо не завантажуєте стару ОС.
• Модель NIC: VirtIO; залишайте e1000 тільки для древніх інсталяторів і видаляйте пізніше.
• Прошивка: відповідність вихідній ВМ (BIOS vs OVMF/UEFI). Не «модернізуйте» під час міграції, якщо не хочете діагностувати подвійно.

Сховище: оберіть основний бекенд і тримайтеся його

Поширені бекенди Proxmox в проектах міграції:

• ZFS: сильна цілісність, snapshot-и, реплікація; чудово, якщо ви розумієте потреби в RAM і write amplification.
• LVM-thin: просто, швидко, знайомо; менше налаштувань; snapshot-и існують, але поводяться інакше, ніж ZFS.
• Ceph: потужний, але міграція в Proxmox — не час вчитися розподіленому сховищу з нуля.
• NFS/iSCSI: підходить для шаред-сховища; продуктивність залежить від мережі та налаштувань серверу.

Суб’єктивна порада: якщо це перша міграція на Proxmox і у вас немає команди зі сховища, використовуйте ZFS на mirror/RAIDZ
або LVM-thin на hardware RAID. Залиште Ceph на пізніше, коли зможете в нього зануритися.

Мережа: прийміть Linux-мости і будьте явними

Proxmox використовує Linux-мережі під капотом. Це хороша новина: передбачувано, скриптовано і дебагово через стандартні інструменти.
Ваша міграція залежить від відтворення порт-груп ESXi як Linux-bridge з VLAN (або окремих мостів), потім підключайте NIC ВМ з правильними тегами.

VLAN, мости, бонди: як відобразити мережу ESXi у Proxmox

ESXi ховає певну складність за «vSwitch» і «порт-групою». Linux показує вам шестерні. Це перевага, поки ви не помилитеся з тегуванням трафіку.

Перекладіть модель

• ESXi vSwitch uplinks → Linux bond (опціонально) або одна фізична NIC
• Port group з VLAN ID → порт мосту Proxmox з встановленим tag, або VLAN-aware bridge + тег VLAN на ВМ
• Trunk/native VLAN поведінка → Linux bridge VLAN filtering + налаштування switchport мають погоджуватися

Рекомендований шаблон: один VLAN-aware bridge на хост

Створіть vmbr0, приєднаний до вашого trunk uplink (або bond), увімкніть VLAN-aware і тегуйте NIC ВМ.
Це тримає конфіг хоста стабільним, поки ви змінюєте теги на рівні ВМ під час міграції.

MTU та jumbo frames: вирішіть на підставі даних

Якщо вам потрібен MTU 9000 для сховища (iSCSI/NFS/Ceph), встановіть його енд-ту-енд: switchports, фізичні NIC, бонди, мости та інтерфейси ВМ.
Одна лінка на 1500 створює «іноді працює» кошмар. Це найкращий вид кошмарів: періодичний.

Стратегії міграції дисків (виберіть свій біль)

Є три поширені способи перемістити диск з ESXi у Proxmox. Немає універсально найкращого; обирайте за розміром, пропускною здатністю і вашою алергією до простою.

Стратегія A: експорт OVF/OVA, імпорт у Proxmox

Краще, коли: ви хочете упакований експорт і ваші ВМ прості.
Гірше, коли: у вас величезні диски або ви хочете точного контролю над форматами дисків і контролерами.

• Плюси: стандартизований контейнер, легко архівувати.
• Мінуси: може бути повільно; імпорт не зберігає всі нюанси; все одно потрібна перевірка драйверів/контролерів.

Стратегія B: копіювати VMDK і конвертувати за допомогою qemu-img

Краще, коли: ви хочете контроль, маєте shell-доступ, хочете обирати raw vs qcow2 і дбаєте про продуктивність.

• Плюси: прозоро, скриптується, працює без складних інструментів.
• Мінуси: ланцюжки snapshot-ів вимагають уваги; час конвертації може бути значним; потрібне планування місця на диску.

Стратегія C: реплікація на блочному рівні або переміщення на рівні сховища

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

Жарт №2: План міграції, який каже «ми просто конвертуємо диски», схожий на «ми просто посадимо літак». Технічно вірно, емоційно — неповно.

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

Фаза 0: оберіть пілота і визначте успіх

• Обрати 1–3 ВМ, що репрезентативні, але ще не критичні для бізнесу.
• Визначити «успіх» в операційних термінах: завантаження, доступність мережі, перевірки здоров’я додатка, бекапи працюють, моніторинг зелений.
• Визначити відкочування: вимкнути ВМ у Proxmox, увімкнути ESXi ВМ, при потребі повернути DNS або VIP.

Фаза 1: побудувати Proxmox хост(и) з нудним базовим набором

• Встановити Proxmox VE, оновити і перезавантажитися в очікуваному ядрі.
• Налаштувати сховище з одним основним пулом/volume group; уникайте безпідставного змішування форматів.
• Налаштувати VLAN-aware bridge і підтвердити trunking з мережею (або вашим майбутнім «я»).
• Встановити NTP, DNS та модель доступу для управління, що не залежить від одного jump-host.

Фаза 2: попереднє наповнення даних (опціонально, але корисно)

• Копіюйте експортовані ВМ або VMDK в staging, поки ВМ ще працює.
• Виміряйте пропускну здатність і оціни­ть час простою: розмір диска / спостережуваний MB/s + накладні витрати на конвертацію.
• Якщо час простою надто великий — зупиніться і переробіть дизайн (реплікація, краща лінка, локальне staging, паралельні копії).

Фаза 3: вікно простою (на ВМ)

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

Фаза 4: стандартизація після успіху

• Переключіть NIC/диск на VirtIO, якщо ви завантажувалися з legacy моделями.
• Встановіть qemu-guest-agent і ввімкніть його для коректних вимкнень і звітності IP.
• Налаштуйте політику бекапів Proxmox і протестуйте відновлення (не домовляйтеся з фізикою пізніше).

Збірник завдань: команди, виводи та що з них вирішувати

Ви хотіли практичності. Ось вона. Кожне завдання включає (1) команду, (2) що означає вивід, (3) яке рішення ви приймаєте.
Підлаштуйте hostnames, VMID, імена сховищ та інтерфейсів під своє середовище.

Завдання 1: підтвердити стан вузла Proxmox і версії

cr0x@server:~$ pveversion -v
proxmox-ve: 8.2.2 (running kernel: 6.8.12-4-pve)
pve-manager: 8.2.4 (running version: 8.2.4/2e1f9d1a)
pve-kernel-6.8: 6.8.12-4
qemu-server: 8.2.2
libpve-storage-perl: 8.2.3

Значення: Підтверджує ядро й стек QEMU. Міграції інколи ламаються через невідповідності userland/kernel.

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

Завдання 2: перевірити ємність сховища і тип файлової системи цілі

cr0x@server:~$ pvesm status
Name             Type     Status           Total            Used       Available        %
local             dir     active         98.00 GiB       12.34 GiB       80.12 GiB   12.59%
rpool             zfspool active          3.64 TiB        1.02 TiB        2.62 TiB   28.02%

Значення: Показує сховища, доступні Proxmox, і вільне місце. Імпорт вимагає запасу (конвертація може тимчасово подвоїти простір).

Рішення: Якщо вільного місця менше ніж 1.3–1.5× найбільшого диска, який ви конвертуєте, зупиніться і додайте простір або змініть стратегію (raw import, stream conversion або staging на іншому боці).

Завдання 3: перевірити стан ZFS pool перед довірою

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

Значення: ZFS наразі не повідомляє про помилки чи деградацію vdev.

Рішення: Якщо ви бачите DEGRADED/FAULTED, не імпортуйте продукційні ВМ. Виправте пул спочатку, інакше ви імпортуєте в повільний інцидент.

Завдання 4: базова перевірка інтерфейсів і мостів

cr0x@server:~$ ip -br link
lo               UNKNOWN        00:00:00:00:00:00
eno1             UP             3c:fd:fe:aa:bb:01
bond0            UP             3c:fd:fe:aa:bb:01
vmbr0            UP             3c:fd:fe:aa:bb:01

Значення: Підтверджує стан лінків. Якщо ваш міст або uplink не UP, «імпорт пройшов» скоро перетвориться на «чому не пінгує».

Рішення: Виправте фізичні/bond/bridge проблеми зараз; не починайте з поламаною мережею і не сподівайтеся, що вона сама зцілиться.

Завдання 5: підтвердити режим бонду і LACP (якщо використовується)

cr0x@server:~$ cat /proc/net/bonding/bond0
Ethernet Channel Bonding Driver: v6.8.12-4-pve

Bonding Mode: IEEE 802.3ad Dynamic link aggregation
MII Status: up
LACP rate: fast
Aggregator selection policy (ad_select): stable

Slave Interface: eno1
MII Status: up
Actor Churn State: none

Slave Interface: eno2
MII Status: up
Actor Churn State: none

Значення: Підтверджує 802.3ad і стан лінків. Churn та «down» вказують на невідповідність на комутаторі або проблеми з кабелем.

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

Завдання 6: перевірити VLAN-фільтрацію і дозволені VLAN-и на Linux-бриджі

cr0x@server:~$ bridge vlan show
port              vlan-id
bond0             1 PVID Egress Untagged
bond0             10
bond0             20
bond0             30
vmbr0             1 PVID Egress Untagged

Значення: Показує, які VLAN-и дозволені/фільтруються на портах моста. Якщо VLAN 20 відсутній, ВМ з тегом 20 буде мовчати.

Рішення: Якщо VLAN-и відсутні, виправте конфіг bridge VLAN і trunk на комутаторі перед cutover. Це бінарна умова успіху.

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

cr0x@server:~$ iperf3 -c 10.20.30.40 -t 10
Connecting to host 10.20.30.40, port 5201
[  5] local 10.20.30.11 port 50422 connected to 10.20.30.40 port 5201
[ ID] Interval           Transfer     Bitrate
[  5]   0.00-10.00  sec  9.42 GBytes  8.09 Gbits/sec                  sender
[  5]   0.00-10.00  sec  9.41 GBytes  8.08 Gbits/sec                  receiver
iperf Done.

Значення: У цьому шляху приблизно 8 Gbit/s корисної пропускної здатності.

Рішення: Використайте це для оцінки часу копіювання. Якщо у ВМ диск 2 TB, ви не вкладетеся в «швидке вікно» через цей лінк без попереднього насичення або редизайну.

Завдання 8: скопіювати експортований бандл ВМ до Proxmox (staging)

cr0x@server:~$ rsync -ah --info=progress2 /mnt/stage/ESXI-EXPORTS/app01/ /var/lib/vz/import/app01/
         12.34G  12%   215.78MB/s    0:00:46
        101.22G 100%   238.11MB/s    0:07:14 (xfr#12, to-chk=0/14)

Значення: Підтверджує реальну стійку швидкість передачі і завершення.

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

Завдання 9: конвертувати VMDK у raw (часто найкраще на ZFS/LVM-thin)

cr0x@server:~$ qemu-img info /var/lib/vz/import/app01/app01-disk1.vmdk
image: /var/lib/vz/import/app01/app01-disk1.vmdk
file format: vmdk
virtual size: 300G (322122547200 bytes)
disk size: 128G
cluster_size: 65536

Значення: Показує віртуальний розмір (видимий гостем) проти фактично зайнятих блоків (реальність thin-provisioning).

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

cr0x@server:~$ qemu-img convert -p -O raw /var/lib/vz/import/app01/app01-disk1.vmdk /rpool/vmdata/app01-disk-0.raw
    (0.99/100%)

Значення: Конвертація навантажує CPU і IO; прогрес показує стадію виконання.

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

Завдання 10: створити оболонку ВМ у Proxmox із відповідною прошивкою

cr0x@server:~$ qm create 120 --name app01 --memory 8192 --cores 4 --sockets 1 --net0 virtio,bridge=vmbr0,tag=20 --scsihw virtio-scsi-single --ostype l26 --bios ovmf
create VM 120: success

Значення: Створює VMID 120 з OVMF (UEFI) прошивкою і VLAN-тегованим NIC virtio.

Рішення: Відповідайте BIOS/OVMF вихідній ВМ. Якщо помилитеся, отримаєте «no boot device», що виглядає як проблема з диском, але не є нею.

Завдання 11: імпортувати диск у сховище, кероване Proxmox

cr0x@server:~$ qm importdisk 120 /rpool/vmdata/app01-disk-0.raw rpool
importing disk '/rpool/vmdata/app01-disk-0.raw' to VM 120 ...
Formatting '/rpool/data/vm-120-disk-0.raw', fmt=raw size=322122547200
Successfully imported disk as 'unused0:rpool:vm-120-disk-0'

Значення: Диск тепер у Proxmox-сховищі і підключений як unused device.

Рішення: Далі ви маєте прикріпити його як правильний завантажувальний пристрій/контролер. «Unused» означає, що Proxmox імпортував диск, але ви ще не під’єднали його.

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

cr0x@server:~$ qm set 120 --scsi0 rpool:vm-120-disk-0 --boot order=scsi0 --efidisk0 rpool:1,format=raw
update VM 120: -scsi0 rpool:vm-120-disk-0 -boot order=scsi0 -efidisk0 rpool:1,format=raw

Значення: ВМ має свій основний диск на SCSI (VirtIO SCSI) і EFI-диск для змінних OVMF.

Рішення: Якщо джерело було BIOS (legacy), не додавайте efidisk0; натомість тримайте --bios seabios і встановіть відповідний порядок завантаження.

Завдання 13: перший запуск з консоллю і негайна перевірка логів

cr0x@server:~$ qm start 120
start VM 120: success

cr0x@server:~$ qm terminal 120
connected to qemu-server 120 (running)

Значення: Ви на консолі ВМ. Якщо вона зависає на ранніх стадіях, саме тут ви побачите проблеми з завантажувачем і драйверами.

Рішення: Якщо ядро гостя панікує або Windows дає BSOD, не змінюйте випадково п’ять налаштувань. Спочатку ідентифікуйте невідповідність контролера/прошивки.

Завдання 14: перевірити, що ВМ бачить NIC і отримує IP (через guest agent)

cr0x@server:~$ qm guest cmd 120 network-get-interfaces
{
  "return": [
    {
      "name": "eth0",
      "ip-addresses": [
        {
          "ip-address": "10.20.20.51",
          "ip-address-type": "ipv4",
          "prefix": 24
        }
      ],
      "hardware-address": "BC:24:11:22:33:44"
    }
  ]
}

Значення: Guest agent працює і повідомляє інтерфейси. Це золото під час cutover.

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

Завдання 15: перевірити латентність IO хоста під час конвертації/імпорту

cr0x@server:~$ iostat -xz 1 3
Linux 6.8.12-4-pve (server)  12/28/2025  _x86_64_ (32 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          12.40    0.00    6.10   18.20    0.00   63.30

Device            r/s     rkB/s   rrqm/s  %rrqm r_await rareq-sz     w/s     wkB/s   wrqm/s  %wrqm w_await wareq-sz aqu-sz  %util
nvme0n1         20.00   880.00     0.00   0.00   2.10    44.00  420.00  51200.00    12.00   2.78  18.50   121.90   7.90  92.00

Значення: Високе %iowait і велике w_await вказують на тиск на сховище. %util близько 100% — ознака насичення.

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

Завдання 16: перевірити VLAN-тегування зсередини ВМ (швидка санітарна перевірка)

cr0x@server:~$ ping -c 2 10.20.20.1
PING 10.20.20.1 (10.20.20.1) 56(84) bytes of data.
64 bytes from 10.20.20.1: icmp_seq=1 ttl=64 time=0.410 ms
64 bytes from 10.20.20.1: icmp_seq=2 ttl=64 time=0.392 ms

--- 10.20.20.1 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 0.392/0.401/0.410/0.009 ms

Значення: ВМ досягає шлюзу у підмережі; VLAN і тегування мосту, ймовірно, налаштовані правильно.

Рішення: Якщо не пінгується шлюз, не дебажте додаток. Спочатку виправте L2/L3: тег VLAN, список допустимих VLAN на trunk, міст або IP-налаштування.

Підводні камені Windows і Linux гостьових систем (драйвери, завантаження, qemu-guest-agent)

Типи контролерів — це не лише косметика

Багато Windows ВМ на ESXi роками завантажувалися на LSI Logic SAS або VMware Paravirtual контролерах.
На Proxmox ви, ймовірно, захочете VirtIO SCSI за продуктивність. Але якщо у Windows немає драйвера VirtIO, після переключення вона не завантажиться.

Практичний підхід:

• Перший запуск — використовуючи сумісний контролер (SATA може бути тимчасовим костилем).
• Встановіть VirtIO драйвери у Windows.
• Потім переключіть шину диска на VirtIO SCSI і підтвердіть завантаження.

Несумісність UEFI vs BIOS виглядає як відмова диска

Якщо джерельна ВМ використовувала EFI, а ви завантажили її під SeaBIOS (або навпаки), часто отримуєте «no boot device».
Люди після цього повторно імпортують диски, конвертують і втрачають день. Спочатку зіставляйте прошивку.

Синхрон часу: уникайте подвійних годинників

ESXi у багатьох середовищах використовував VMware Tools для синхронізації часу. Proxmox використовує QEMU guest agent і стандартні сервіси часу в ОС.
Оберіть один авторитетний метод (зазвичай NTP/chrony у гості) і відключіть інші.

Trim/discard і реальність thin provisioning

Якщо ви мігруєте тонко-провіжені диски і потім зберігаєте їх знову на тонкому шарі, ви створили «thin-on-thin» стек.
Це може працювати, але потрібно моніторити фактичне фізичне використання й переконатися, що discard/TRIM підтримується наскрізь.

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

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

По-перше: чи мережа лімітує?

• Запустіть iperf3 між стороною джерела staging і Proxmox.
• Шукайте насичену лінку, проблему дуплексу або прихований 1G хоп.
• Підтвердіть узгодженість MTU, якщо очікуєте jumbo frames.

По-друге: чи цільове сховище насичено або має високу латентність?

• Використайте iostat -xz 1 на Proxmox під час конвертації/імпорту.
• Шукайте %util близько 100% і await у десятках мс для SSD/NVMe (або сотнях для HDD).
• Перевірте ZFS: стан пулу, тиск ARC і чи не виконується синхронізація всього підряд.

По-третє: чи CPU лімітує (часто під час конвертації)?

• Використайте top або pidstat, щоб побачити, чи qemu-img завантажує ядро.
• Якщо навантаження на CPU, паралелізація конвертацій може допомогти — але лише якщо сховище витримає навантаження.

По-четверте: чи гість некоректно налаштований (завантаження і драйвери)?

• Перевірте прошивку і шину диска спочатку (OVMF vs SeaBIOS; VirtIO vs SATA).
• Потім модель NIC (VirtIO) і теги VLAN.
• Лише після цього переходьте до проблем на рівні додатку.

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

1) ВМ завантажується до «no boot device»

Симптом: ВМ стартує, потім потрапляє в оболонку прошивки або boot manager без диска.

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

Виправлення: Зіставте прошивку з вихідною ВМ; встановіть порядок завантаження на правильний диск; тимчасово підключіть диск на SATA, щоб завантажитися, потім встановіть VirtIO і переключіть.

2) ВМ має лінк мережі, але не дістає до шлюзу

Симптом: Інтерфейс UP; IP налаштований; пінг до шлюзу не проходить.

Корінна причина: Неправильний VLAN-тег (або VLAN відсутній на trunk); міст не VLAN-aware; switchport не trunk-ить VLAN.

Виправлення: Перевірте тег VLAN на NIC ВМ; підтвердіть VLAN filtering на мосту; підтвердьте список дозволених VLAN на комутаторі. Доведіть L2 робочість через ARP і пінг до шлюзу.

3) Копіювання міграції «швидке спочатку, потім повзе»

Симптом: Копія стартує на сотнях MB/s, потім падає до десятків.

Корінна причина: ZFS pool досягає SLOG-less sync writes (якщо примусово), тиск ARC, або диск призначення стає латентнісно обмеженим через випадкові записи під час конвертації.

Виправлення: Стадіруйте на швидкому локальному сховищі; конвертуйте в непік; розгляньте raw замість qcow2; моніторьте iostat і ZFS-статистику; уникайте примусового sync, якщо не потрібно.

4) Windows VM BSOD після переключення на VirtIO

Симптом: Збій завантаження/BSOD одразу після зміни контролера диска або моделі NIC.

Корінна причина: Відсутні VirtIO драйвери або неправильний тип контролера сховища.

Виправлення: Завантажте з SATA або сумісним контролером; встановіть VirtIO драйвери; потім переключіть і перезавантажте. Майте одну відкатну точку, що працює.

5) ВМ працюють, але дивно повільніші, ніж на ESXi

Симптом: Більша латентність, нижча пропускна здатність, періодичні зупинки.

Корінна причина: Емульовані пристрої (e1000/IDE), неправильний режим кешування, налаштування енергозбереження хоста або невідповідний recordsize (ZFS).

Виправлення: Використовуйте VirtIO для NIC і дисків; перевірте налаштування кешу; упевніться в адекватних налаштуваннях CPU governor; налаштуйте властивості ZFS dataset там, де потрібно.

6) Бекапи мовчки не охоплюють нові ВМ

Симптом: Завдання бекапу запускаються, але мігрувана ВМ не включена або бекап не вдається.

Корінна причина: ВМ збережена на бекенді, який не включено в конфіг бекапів, або snapshot-и не підтримуються/вимкнені.

Виправлення: Синхронізуйте IDs сховищ, розклади бекапів і можливості snapshot-ів. Негайно протестуйте відновлення після першого успішного cutover.

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

Міні-історія 1: інцидент через неправильне припущення (VLAN «за замовчуванням»)

Середня SaaS-компанія планувала міграцію ESXi → Proxmox з начебто чистою мережею:
«Усі мережі ВМ — це теги VLAN, trunk-ліно, залежності від native VLAN немає.» Це речення мало бути підкріплене доказами, але ними нехтували.

Під час першого production cutover ВМ піднялася, відповідала на порт додатка з одних місць і була повністю недоступна з інших.
Команда на виклику бачила індикатори лінків, правильну IP-конфіг і чисте завантаження. Класично — звинуватили firewall.
Після кількох перемикань правил зона ураження зросла, бо вони змінили більше змінних, не маючи ключової.

Корінна причина була жорстко проста: порт-група ESXi мала VLAN ID, але апстрім-комутатор мав «native VLAN», що переносив management-трафік,
і деякі legacy-системи покладалися на неочікувано ненадісланий трафік. На Proxmox міст був VLAN-aware, але налаштований зі строгим дозволеним списком, що відкидав нетегований трафік.

Виправлення не полягало в «змусити Proxmox поводитися як ESXi» шляхом відключення фільтрації. Виправлення — документувати який трафік має бути тегований,
ліквідувати випадкову залежність від native VLAN та явно налаштувати обробку нетегованого трафіку там, де це дійсно потрібно.
Після цього наступні міграції пройшли нудно. Перша — ні.

Міні-історія 2: оптимізація, що відгукнулась проблемою (thin-on-thin і сюрприз з ємністю)

Корпоративна IT-команда пишалася ефективністю сховища. На ESXi використовували тонкі VMDK на шаред-масиві — і «працювало».
Перехід на Proxmox з ZFS зберіг ту саму модель: VMDK → qcow2 (thin) → ZFS (copy-on-write). Тонко всюди. Ефективно всюди.

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

Команда відреагувала додаванням ще snapshot-ів («щоб можна було відкатитися»). Це збільшило метадані і тиск на простір.
Потім ввімкнули стиснення на вже стиснених даних. CPU виріс, латентність погіршилася, і бізнес-користувачі навчилися описувати повільність новими способами.

Остаточне рішення було нудним і ефективним: перемістити гарячі диски баз даних у raw на окремий dataset з адекватним recordsize,
мінімізувати частоту snapshot-ів на цих томах і зберігати thin provisioning там, де він справді допомагає (шаблони ВМ, dev-box-и, низькочаржеві сервери).
Ефективність — не безкоштовна; рахунок приходить у вигляді латентності.

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

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

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

Оскільки вони вже тестували відновлення на Proxmox, їм не довелося вигадавати процедуру відновлення у стресі.
Вони відновили останню відому хорошу резервну копію на новий VMID, прикріпили NIC з правильними VLAN-тегами, і сервіс повернувся.
Оригінальна ВМ залишилася для розбору, не блокуючи операції для пацієнтів.

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

Часті запитання

1) Чи можу я мігрувати ESXi ВМ у Proxmox з майже нульовим простоєм?

Іноді — але не універсально. Для справжнього майже-нульового простою використовуйте реплікацію на рівні додатка (реплікація БД, синхрон файлів, кластери) і переключайте кінцеві точки.
Переміщення ВМ через конвертацію дисків зазвичай — холодна міграція, якщо ви не додаєте спеціалізовані інструменти реплікації.

2) Використовувати qcow2 чи raw на Proxmox?

Якщо ви на ZFS або LVM-thin, raw часто є простішою базою для продуктивності. qcow2 корисний, коли потрібні його фічі (внутрішні snapshot-и),
але додає накладні витрати і складність. Виберіть один стандарт для класу сховища і не змішуйте без причини.

3) Найчистіший спосіб обробляти VLAN-и на Proxmox?

VLAN-aware bridge (vmbr0) на trunk uplink, потім встановлюйте VLAN tag на NIC ВМ. Це масштабовано, явно і концептуально відображає порт-групи.

4) Чи потрібен мені Proxmox кластер, щоб почати?

Ні. Один вузол підходить для пілоту. Але якщо ви плануєте live-migrate ВМ між нодами пізніше, заплануйте сумісність CPU, шаред-сховище (або реплікацію)
і послідовну мережеву конфігурацію з самого початку.

5) Моя Windows ВМ не завантажується після імпорту. Що перевірити перш за все?

Прошивка (UEFI vs BIOS), потім контролер/шина диска. Якщо ви переключили на VirtIO до встановлення драйверів — поверніть сумісний контролер, завантажтеся, встановіть драйвери, знову переключіть.

6) Як оцінити час простою на ВМ?

Виміряйте пропускну здатність передачі (iperf і реальний rsync), потім порахуйте: байти диска / стійкі байти в секунду + час конвертації + завантаження/валідація.
Додайте буфер для сюрпризів. Якщо ви намагаєтеся запхати 2 TB у 30-хвилинне вікно — математика вас публічно спростує.

7) Чи можу я зберегти ті ж IP і MAC-адреси?

IP можна зберегти, якщо VLAN/підмережа залишається тією ж. MAC можна встановити вручну в Proxmox, якщо потрібно,
але робіть це лише коли ліцензія або політика залежить від цього; інакше дозвольте Proxmox призначити і оновіть залежності.

8) Що з snapshot-ами під час міграції?

Стисніть або видаліть непотрібні snapshot-и ESXi перед експортом/копіюванням. Ланцюжки snapshot-ів уповільнюють експорт і підвищують ризик.
У Proxmox встановіть нову політику snapshot/backup після стабілізації; не імпортуйте старі snapshot-багаґи без сильної причини.

9) Чи безпечно одночасно «оновлювати» апаратну частину ВМ під час міграції (UEFI, VirtIO, нова NIC)?

Це безпечно, якщо ви готові до подвійних дебагів. Для критичних систем спочатку мігруйте з мінімальними змінами, доведіть стабільність, потім модернізуйте у другому вікні змін.

10) Яка мінімальна валідація після cutover?

Завантаження, правильний IP/підмережа/шлюз/DNS, синхрон часу, перевірки здоров’я додатка, чисті логи для виявлення нових помилок, моніторинг і успішна задача бекапу (або хоча б ручний бекап).

Висновок: практичні наступні кроки

Міграцію робіть як оператор, а не гравець у рулетку. Побудуйте нудний Proxmox baseline, інвентаризуйте ESXi-майно з наміром
і ставте VLAN-и та прошивку/контролери дисків як першокласні дані міграції — а не «деталі, які ми виправимо після завантаження».

Наступні кроки, що швидко окупаються:

• Оберіть пілотну ВМ і пройдіть повний холодний шлях міграції від початку до кінця, включно з тестом відновлення.
• Стандартизуйте один мережевий патерн (VLAN-aware bridge) і один сховищний патерн (raw на ZFS або LVM-thin) для більшості ВМ.
• Напишіть per-VM cutover sheet: прошивка, шина диска, VLAN тег, IP-план, кроки валідації власника, кроки відкату.
• Плануйте міграції в батчах, що відповідають виміряному throughput і латентності сховища, а не бажаній календарній арифметиці.

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