Імпорт VM з ESXi в Proxmox: Windows/Linux, драйвери VirtIO, маппінг NIC, виправлення завантаження

Факти та історія, що справді важливі

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

1. VMDK старший за більшість «cloud-first» стратегій. VMware представив VMDK на початку 2000-х; він має sparse/thick варіанти та низку підтипів, з якими інструменти конвертації не завжди погоджуються.
2. KVM вбудований у ядро Linux з 2007 року. Proxmox базується на цій фундаментальній частині, а значить зміни в ядрі Linux (драйвери, іменування, initramfs) можуть бути важливішими, ніж «налаштування Proxmox».
3. VirtIO виник у екосистемі KVM/QEMU, щоб уникнути оверхеду емульованого обладнання. Чудово для продуктивності, катастрофа якщо гостьова ОС не має драйвера на момент завантаження.
4. UEFI проти BIOS — це не косметичний перемикач. Якщо ESXi встановив гість у режимі UEFI, а ви завантажуєте його в BIOS (або навпаки), часто отримаєте ситуацію «диск виглядає порожнім».
5. VMware PVSCSI — це не VirtIO. Обидва звучать як «паравіртуалізація», але стек драйверів різний. Windows особливо карає такі припущення.
6. «Прогнозовані» імена NIC змінили людську модель мислення. Linux перейшов від eth0/eth1 до імен на кшталт ens18/enp0s3; під час міграції ця зміна явно проявляється.
7. qcow2 — це не «ще один формат диска». Він підтримує снапшоти й стиснення, але додає рівень проміжності. На деяких бекендах raw швидший і простіший.
8. OVA — це tarball, а не магія. Зазвичай містить опис OVF плюс один або кілька VMDK. Розглядайте його як архів для інспекції, а не як сакральний артефакт.
9. Активація Windows і апаратні ідентифікатори завжди примхливі. Переміщення між гіпервізорами змінює достатньо віртуального обладнання, тому плануйте запити активації та перевірки ліцензійної відповідності.

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

Вернер Вогельс (парафраз): «Все ламається, весь час — проектуйте і працюйте так, ніби це норма.»

Дерево рішень: оберіть шлях імпорту

Є три поширені шляхи. Оберіть один, дотримуйтеся його і уникайте змішування «швидких хаків» посеред процесу.

Шлях A: У вас є OVA/OVF експорт

Краще, коли ви можете чисто експортувати з vCenter/ESXi і хочете портативний бандл. Ви витягаєте VMDK(и) і конвертуєте їх за допомогою qemu-img або дозволяєте Proxmox імпортувати диск.

Шлях B: У вас є VMDK файли зі сховища

Краще, коли можна SCP з ESXi або переглянути datastore. Ви копіюєте VMDK(и) і конвертуєте/імпортуєте.

Шлях C: Немає ні того, ні іншого, є тільки працююча VM, яку не можна вимкнути

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

Підготовка на ESXi: чистий експорт і фіксація стану

Ваша мета на ESXi проста: зафіксувати факти про VM перед її переміщенням. Який контролер диска? BIOS чи UEFI? Який тип NIC? Які VLAN? Які IP? У Proxmox ці деталі стають здогадками, а здогадки — це шлях до VM, яка «завантажується нормально», але не може нічого при цьому зробити.

Задача 1: Запишіть прошивку VM, диски та типи NIC (з ESXi shell)

cr0x@server:~$ ssh root@esxi01 'vim-cmd vmsvc/getallvms | head'
Vmid   Name                 File                               Guest OS      Version   Annotation
1      dc01                 [datastore1] dc01/dc01.vmx          windows9Server64Guest   vmx-13
2      web01                [datastore1] web01/web01.vmx        ubuntu64Guest  vmx-14

Що означає вивід: у вас є VMID та шляхи до VMX. Ви використаєте VMX, щоб підтвердити прошивку і пристрої.

Рішення: ідентифікуйте VMID, який ви мігруєте, і збережіть шлях до VMX у своїх нотатках.

Задача 2: Витягніть VMX і перевірте прошивку та модель пристрою

cr0x@server:~$ ssh root@esxi01 'grep -E "firmware|scsi|nvme|ethernet.*virtualDev" /vmfs/volumes/datastore1/web01/web01.vmx'
firmware = "efi"
scsi0.virtualDev = "pvscsi"
ethernet0.virtualDev = "vmxnet3"

Що це означає: гість у UEFI, VMware paravirtual SCSI і vmxnet3 NIC.

Рішення: плануйте використання UEFI в Proxmox (OVMF) і врахуйте, що гість покладається на драйвери PVSCSI і vmxnet3, а не на VirtIO.

Задача 3: Коректно вимкніть (або зробіть снапшот, який можна обґрунтувати)

cr0x@server:~$ ssh root@esxi01 'vim-cmd vmsvc/power.getstate 2'
Retrieved runtime info
Powered on

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

cr0x@server:~$ ssh root@esxi01 'vim-cmd vmsvc/power.shutdown 2; sleep 5; vim-cmd vmsvc/power.getstate 2'
Retrieved runtime info
Powered off

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

Задача 4: Експорт/копіювання дисків (приклад: scp з ESXi)

cr0x@server:~$ scp root@esxi01:/vmfs/volumes/datastore1/web01/web01.vmdk .
web01.vmdk                                      100%  512B   2.1KB/s   00:00

Що це означає: цей маленький файл — це дескриптор. Дані зазвичай знаходяться у -flat.vmdk або подібному файлі.

Рішення: завжди копіюйте flat/extent файли також або використовуйте метод експорту, який створює єдиний потік (OVA), щоб не втратити частини.

cr0x@server:~$ scp root@esxi01:/vmfs/volumes/datastore1/web01/web01-flat.vmdk .
web01-flat.vmdk                                 100%   40G  110.2MB/s   06:12

Підготовка на Proxmox: сховище, мережі та запобіжні заходи

На боці Proxmox дві великі ризики: (1) розмістити великі raw-образи на невідповідному сховищі й потім виявити, що не можна робити снапшоти/реплікацію так, як ви очікували; (2) підключити VM до неправильного bridge/VLAN і «успішно» ізолювати її від світу.

Задача 5: Перевірте цілі сховища та вільне місце

cr0x@server:~$ pvesm status
Name            =reqtype  Status     Total     Used    Avail   %  Content
local             dir     active    98.0G    11.2G    81.6G  11  iso,vztmpl,backup
local-lvm         lvmthin active   900.0G   612.4G   287.6G  68  rootdir,images
zfspool           zfspool active     2.7T     1.1T     1.6T  40  images,rootdir

Що це означає: у вас декілька цілей. ZFS-пул має місце і підтримує снапшоти; LVM-thin теж підтримує снапшоти, але поводиться інакше під навантаженням.

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

Задача 6: Підтвердіть bridge та підтримку VLAN

cr0x@server:~$ ip -br link
lo               UNKNOWN        00:00:00:00:00:00
eno1             UP             3c:ec:ef:11:22:33
vmbr0            UP             3c:ec:ef:11:22:33
vmbr1            UP             3c:ec:ef:aa:bb:cc

Рішення: зіставте ESXi portgroup/VLAN наміри з Proxmox bridge і тегом. Якщо ви не можете описати мережу в одному реченні — зупиніться і промапуйте її перед імпортом.

Задача 7: Перевірте стан хоста Proxmox перед тим, як звинувачувати VM

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/2a1b7d2c)

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

Жарт #1: Віртуалізація — це просто дуже переконлива гра в уяві, і якось на неї залежить зарплатня.

Конвертація дисків: VMDK/OVA до сховища Proxmox

Конвертація — це місце, де ви можете тихо зіпсувати собі день. Правила прості:

• Підтвердіть наявність фактичних extents даних (flat/sesparse/etc.).
• Конвертуйте інструментом, що розуміє підформати VMDK.
• Оберіть raw для простоти/продуктивності на ZFS/LVM-thin, якщо немає причин для qcow2.
• Перевірте розмір утвореного образу та базову цілісність перед приєднанням.

Задача 8: Перевірте дескриптор VMDK (щоб зловити мульти-extent сюрпризи)

cr0x@server:~$ head -n 20 web01.vmdk
# Disk DescriptorFile
version=1
encoding="UTF-8"
CID=fffffffe
parentCID=ffffffff
createType="vmfs"

# Extent description
RW 83886080 VMFS "web01-flat.vmdk"

Що це означає: один extent-файл, близько 40GiB секторів. Добре. Якщо ви бачите кілька extent-ів — потрібно скопіювати всі частини та зберегти відносні шляхи.

Рішення: якщо це multi-extent і у вас не всі частини — зупиніться. Експортуйте як OVA або перекопіюйте правильно.

Задача 9: Конвертуйте VMDK в raw (рекомендовано для ZFS через менше шарів)

cr0x@server:~$ qemu-img convert -p -f vmdk -O raw web01.vmdk web01.raw
    (0.00/100%)
    (12.50/100%)
    (25.00/100%)
    (37.50/100%)
    (50.00/100%)
    (62.50/100%)
    (75.00/100%)
    (87.50/100%)
    (100.00/100%)

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

Рішення: якщо таргет — LVM-thin або ZFS, raw підходить. Якщо потрібні file-based снапшоти і у вас немає ZFS/LVM-thin, qcow2 може бути корисним.

Задача 10: Перевірте інформацію про образ (саніті-чек перед імпортом)

cr0x@server:~$ qemu-img info web01.raw
image: web01.raw
file format: raw
virtual size: 40 GiB (42949672960 bytes)
disk size: 40 GiB

Що це означає: raw повністю алокований; це очікувано. Якщо ви очікували тонке забезпечення — побачите це тільки з qcow2 або коли цільове сховище (наприклад, ZVOL/LVM-thin) обробляє sparsity.

Рішення: якщо розмір диска суттєво не відповідає очікуваному (наприклад, 4 GiB замість 40 GiB) — ви конвертували не те або пропустили extents.

Задача 11: Імпортуйте диск до сховища Proxmox за допомогою qm importdisk

cr0x@server:~$ qm create 120 --name web01 --memory 4096 --cores 2 --net0 virtio,bridge=vmbr0
create VM 120: success

cr0x@server:~$ qm importdisk 120 web01.raw zfspool
importing disk 'web01.raw' to VM 120 ...
transferred 40.0 GiB of 40.0 GiB (100.00%)
Successfully imported disk as 'zfspool:vm-120-disk-0'

Що це означає: диск тепер — обсяг, керований Proxmox.

Рішення: відтепер трактуйте імпортований том як джерело істини; збережіть оригінальні VMDK/raw у безпечному місці, поки VM не буде стабільною і не створено резервну копію.

Створення VM в Proxmox: контролери, прошивка, CPU та RAM

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

Правильно приєднайте імпортований диск

Після qm importdisk вам ще потрібно приєднати диск до контролера і задати порядок завантаження.

Задача 12: Приєднайте диск як SATA спочатку (підхід «стабільність першочергово»)

cr0x@server:~$ qm set 120 --sata0 zfspool:vm-120-disk-0
update VM 120: -sata0 zfspool:vm-120-disk-0

Що це означає: диск приєднано до SATA-контролера. Майже кожна ОС може завантажуватися з SATA без додаткових драйверів.

Рішення: використовуйте SATA (або IDE для дуже старих ОС) для першого завантаження. Переключайтеся на VirtIO SCSI пізніше для продуктивності.

Задача 13: Підберіть режим прошивки (UEFI vs BIOS)

cr0x@server:~$ qm set 120 --bios ovmf --efidisk0 zfspool:0,pre-enrolled-keys=1
update VM 120: -bios ovmf -efidisk0 zfspool:vm-120-disk-1,pre-enrolled-keys=1

Що це означає: ви ввімкнули OVMF (UEFI) і створили диск змінних EFI. Якщо у VMX було firmware="efi", це відповідність.

Рішення: якщо гість на ESXi був у BIOS, не вмикайте OVMF. Якщо не знаєте — перевірте VMX і розбиття на розділи (EFI System Partition проти MBR).

Задача 14: Явно встановіть порядок завантаження

cr0x@server:~$ qm set 120 --boot order=sata0
update VM 120: -boot order=sata0

Рішення: не довіряйте налаштуванням за замовчуванням. Нехай VM завантажується з диска, який ви імпортували, а не з порожнього віртуального CD-ROM.

Задача 15: Запустіть і спостерігайте вихід консолі (не робіть сліпих перезапусків)

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

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

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

Імпорт Windows: драйвери VirtIO, виправлення завантаження та послідовність дій

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

Найбезпечніша послідовність для Windows:

1. Завантажтеся на «універсальному» контролері (SATA) і «універсальній» моделі NIC (E1000), якщо потрібно.
2. Встановіть драйвери VirtIO всередині Windows.
3. Переключіть дисковий контролер на VirtIO SCSI (або VirtIO Block) і NIC на VirtIO.
4. Перезавантажте і перевірте.

Стратегія драйверів VirtIO, яка працює

Підмонтуйте ISO з драйверами VirtIO в Proxmox, потім встановіть драйвери через Device Manager або запустіть інсталятор, якщо він є. Ключове: драйвер диска має бути присутній і увімкнений під час завантаження.

Задача 16: Додайте ISO драйверів VirtIO (приклад: ISO вже завантажений)

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

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

Задача 17: Тимчасово використайте сумісну модель NIC (якщо потрібно)

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

Що це означає: ви використовуєте емульовану Intel NIC. Повільніше, але Windows розпізнає її без додаткових драйверів.

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

Після встановлення драйверів: перейдіть на VirtIO SCSI

VirtIO SCSI — це оптимальний варіант для більшості навантажень. Він краще підтримує TRIM/UNMAP в багатьох конфігураціях і добре протестований.

Задача 18: Додайте контролер VirtIO SCSI і перемістіть диск

cr0x@server:~$ qm set 120 --scsihw virtio-scsi-single
update VM 120: -scsihw virtio-scsi-single

cr0x@server:~$ qm set 120 --scsi0 zfspool:vm-120-disk-0
update VM 120: -scsi0 zfspool:vm-120-disk-0

cr0x@server:~$ qm set 120 --delete sata0
update VM 120: delete sata0

Рішення: видаляйте SATA-підключення лише після того, як драйвери VirtIO встановлені і ви впевнені, що наступне завантаження знайде диск.

Задача 19: Переключіть NIC на VirtIO після встановлення драйвера в Windows

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

Що це означає: Windows побачить новий NIC. Налаштування IP може не перейти автоматично, якщо воно було прив’язане до старого адаптера.

Рішення: плануйте переналаштування IP або скриптування. Для серверів зі статичними IP очікуйте короткого вікна «куди зник мій IP?».

Помилки завантаження Windows, які ви справді побачите

• INACCESSIBLE_BOOT_DEVICE (BSOD): невідповідність драйвера з контролером диска. Завантажувалося нормально на SATA, зламалося після переходу на VirtIO до встановлення драйверів.
• Зависання на обертових точках: іноді проблема з драйверами, іноді — режим прошивки, іноді — пошкоджений BCD після конвертації.
• No boot device: неправильний порядок завантаження або невідповідність UEFI/BIOS.

Жарт #2: Драйвери Windows — як парасолі: помічаєш, що вони потрібні, лише коли вже промок.

Імпорт Linux: initramfs, імена NIC та пастки файлових систем UUID

Міграції Linux зазвичай простіші за Windows — до того моменту, поки не стають складними. Основні точки відмов:

• initramfs не містить драйвер для нового дискового контролера (VirtIO), тому коренева файловa система ніколи не з’являється.
• Зміни імен мережевих інтерфейсів (ens160 на VMware стає ens18 в Proxmox) і ваша мережева конфігурація вказує на неіснуючий пристрій.
• Записи завантажувача посилаються на старі UUID, або конвертація змінила щось настільки, що kernel cmdline не може знайти root.

Задача 20: Отримайте роздільну карту диска VM з хоста Proxmox (без завантаження)

cr0x@server:~$ ls -l /dev/zvol/zfspool/vm-120-disk-0
lrwxrwxrwx 1 root root 13 Dec 28 10:12 /dev/zvol/zfspool/vm-120-disk-0 -> ../../zd0

cr0x@server:~$ partprobe /dev/zd0 && lsblk -f /dev/zd0
NAME   FSTYPE FSVER LABEL UUID                                 FSAVAIL FSUSE% MOUNTPOINTS
zd0
├─zd0p1 vfat   FAT32       1A2B-3C4D
└─zd0p2 ext4   1.0         11111111-2222-3333-4444-555555555555

Що це означає: ймовірно UEFI (vfat ESP) плюс ext4 як корінь. Це підкріплює ваше попереднє рішення щодо прошивки.

Рішення: якщо ви очікували BIOS/MBR, але бачите ESP — переключіть VM на OVMF і додайте efidisk.

Задача 21: Якщо Linux завантажується, але немає мережі — знайдіть нову назву NIC

cr0x@server:~$ qm guest exec 120 -- ip -br a
{
  "exitcode": 0,
  "out-data": "lo               UNKNOWN        127.0.0.1/8 ::1/128\nens18            DOWN           \n",
  "err-data": ""
}

Що це означає: гість бачить ens18, але він вимкнений/не налаштований.

Рішення: оновіть ваш netplan/systemd-networkd/ifcfg-скрипти, щоб вони посилалися на нову назву інтерфейсу, або використайте MAC-базоване зіставлення.

Задача 22: Перевірте, чи гість бачить диск як VirtIO після перемикання контролерів

cr0x@server:~$ qm guest exec 120 -- lsblk
{
  "exitcode": 0,
  "out-data": "NAME   MAJ:MIN RM  SIZE RO TYPE MOUNTPOINTS\nvda    252:0    0   40G  0 disk \nvda1   252:1    0  512M  0 part /boot/efi\nvda2   252:2    0 39.5G  0 part /\n",
  "err-data": ""
}

Що це означає: диск з’являється як /dev/vda (VirtIO). Добре.

Рішення: якщо у вашому /etc/fstab використовується /dev/sda2 замість UUID — виправте це перед наступним перезавантаженням.

Задача 23: Перевірте, чи initramfs містить модулі VirtIO (всередині гостя)

cr0x@server:~$ qm guest exec 120 -- bash -lc 'lsinitramfs /boot/initrd.img-$(uname -r) | grep -E "virtio|vda|scsi" | head'
{
  "exitcode": 0,
  "out-data": "usr/lib/modules/6.5.0-28-generic/kernel/drivers/block/virtio_blk.ko\nusr/lib/modules/6.5.0-28-generic/kernel/drivers/scsi/virtio_scsi.ko\n",
  "err-data": ""
}

Рішення: якщо модулі VirtIO відсутні, перебудуйте initramfs перед тим, як остаточно перемикати контролери (update-initramfs -u на Debian/Ubuntu, dracut -f на RHEL-подібних).

Маппінг NIC: від vSwitch до Linux-бриджів

Мережі ESXi — це portgroup на vSwitch (стандартному або розподіленому). Мережі Proxmox — це Linux-бриджі (часто vmbr0) і опційне VLAN-тегування. Підступ у тому, що «той самий VLAN ID» ≠ «та сама підключеність», якщо upstream trunking або VLAN-aware налаштування бриджа відрізняються.

Сплануйте маппінг свідомо

• ESXi portgroup VLAN 0/none → Proxmox bridge без тегування на тому ж фізичному сегменті.
• ESXi portgroup VLAN X → Proxmox NIC в тегованому VLAN X (tag=X) на VLAN-aware bridge, або окремий підінтерфейс/бридж.
• Кілька NIC → зіставте кожен із правильним bridge; не «кидати все на vmbr0», якщо ви не хочете ненавмисного латерального руху.

Задача 24: Покажіть, чи bridge Proxmox підтримує VLAN (на хості)

cr0x@server:~$ grep -A4 -B2 -n "vmbr0" /etc/network/interfaces
7:auto vmbr0
8:iface vmbr0 inet static
9:        address 10.10.10.5/24
10:       gateway 10.10.10.1
11:       bridge-ports eno1
12:       bridge-stp off
13:       bridge-fd 0
14:       bridge-vlan-aware yes

Що це означає: VLAN-aware bridge. Можна тегувати NIC гостя без додаткових Linux VLAN-інтерфейсів.

Рішення: якщо bridge-vlan-aware не ввімкнено, але потрібні теги — або увімкніть його (обережно), або побудуйте альтернативний дизайн. Не робіть цього на продакшн-хості під час робочого дня.

Задача 25: Встановіть тегований VLAN на NIC VM

cr0x@server:~$ qm set 120 --net0 virtio,bridge=vmbr0,tag=30
update VM 120: -net0 virtio,bridge=vmbr0,tag=30

Рішення: якщо гість досі не досягає шлюзу — підтвердьте, що upstream комутатор trunk-ить VLAN 30 і що host bridge підключений до правильної фізичної інтерфейсу.

Швидка діагностика: план дій

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

Перш за все: Чи завантажується, і яку точну помилку ви бачите?

• No bootable device / переходить в UEFI shell → невірний режим прошивки або порядок завантаження, або диск не приєднано.
• GRUB rescue / kernel panic: unable to mount root → невідповідність контролера/драйвера диска або mismatch fstab/UUID root.
• Windows BSOD INACCESSIBLE_BOOT_DEVICE → диск завантаження на контролері, для якого немає драйвера.

По-друге: Чи присутній диск і де саме?

Перевірте на хості Proxmox: чи диск імпортовано коректно і чи приєднано до VM на потрібній шині?

cr0x@server:~$ qm config 120 | egrep "boot|bios|efidisk|scsi|sata|ide"
bios: ovmf
boot: order=scsi0
efidisk0: zfspool:vm-120-disk-1,pre-enrolled-keys=1,size=4M
ide2: local:iso/virtio-win.iso,media=cdrom
scsi0: zfspool:vm-120-disk-0
scsihw: virtio-scsi-single

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

По-третє: Мережа зламана або просто змінилося ім’я NIC?

• Гість завантажується, але немає ping → ймовірно невірний VLAN/bridge або відсутні драйвери/перейменування NIC.
• Ping працює, але сервіси недоступні → проблема додатку, фаєрвол або змінена IP-конфігурація.

По-четверте: Проблема з продуктивністю чи хост насичений?

Не налаштовуйте VM, поки не зрозумієте, чи саме хост — вузьке місце.

cr0x@server:~$ pvesh get /nodes/$(hostname)/status | egrep '"cpu"|mem|swap'
  "cpu": 0.23,
  "memory": {
    "free": 5826394112,
    "total": 34359738368,
    "used": 28533344256
  },
  "swap": {
    "free": 8589934592,
    "total": 8589934592,
    "used": 0
  }

Рішення: якщо пам’ять на межі або CPU завантажено — «повільна VM» може бути через перевантажений хост. Виправте платформу перш за все.

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

1) Симптом: «No bootable device» після імпорту

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

Виправлення: підтвердіть прошивку в VMX, потім підберіть відповідні налаштування в Proxmox (--bios seabios або --bios ovmf + efidisk). Явно встановіть порядок завантаження.

2) Симптом: Windows BSOD INACCESSIBLE_BOOT_DEVICE

Корінь: ви приєднали завантажувальний диск на VirtIO SCSI/Block до того, як Windows мав драйвер VirtIO.

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

3) Симптом: Linux падає в initramfs або kernel panic «unable to mount root»

Корінь: initramfs не містить модулів VirtIO, або root= посилається на ім’я пристрою, яке змінилося (sda → vda), або fstab використовує шляхи пристроїв.

Виправлення: завантажтеся через SATA тимчасово, перебудуйте initramfs, оновіть fstab на UUID, потім переключіться на VirtIO.

4) Симптом: VM завантажується, але немає мережі

Корінь: зміни моделі NIC і відсутній драйвер (Windows) або змінилася назва інтерфейсу (Linux), або неправильне VLAN/bridge.

Виправлення: тимчасово використайте E1000 на Windows для відновлення доступу; для Linux оновіть мережеві налаштування під нове ім’я NIC. Перевірте bridge і VLAN на хості.

5) Симптом: Мережа працює, але служби недоступні зовні

Корінь: профіль фаєрвола змінився, Windows вважає мережу «Public», або IP прив’язаний до прихованого/старого адаптера.

Виправлення: прив’яжіть IP до активного адаптера, перевірте профіль Windows firewall, маршрути і відкриті сокети.

6) Симптом: Продуктивність диска жахлива після імпорту

Корінь: ви залишили емульований контролер (IDE/SATA) або використали qcow2 на сховищі з невідповідною поведінкою copy-on-write, або хост I/O завантажений.

Виправлення: перейдіть на VirtIO SCSI і ввімкніть iothreads там, де потрібно; надавайте перевагу raw на ZFS/LVM-thin; спочатку перевірте латентність хоста та здоров’я сховища.

7) Симптом: Дрейф часу або дивні стрибки годинника

Корінь: зміни в інструментах гостя (видалено VMware tools, не встановлено QEMU guest agent), невірне джерело синхронізації часу, або Windows time service переосмислює апарат.

Виправлення: встановіть і ввімкніть QEMU guest agent; налаштуйте NTP/chrony/systemd-timesyncd; перевірте Windows time service і доменну ієрархію часу.

8) Симптом: VM не стартує, Proxmox повідомляє про lock або помилки конфігу

Корінь: залишений лок, сховище недоступне, неправильний ID тому або погані редагування конфігу.

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

cr0x@server:~$ qm unlock 120
unlock VM 120

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

Контрольний список A: Перш ніж починати

• Підтвердіть вікно обслуговування і план відкату (залиште оригінальну VM вимкненою, але цілою).
• Запишіть ESXi VMX: прошивка, контролер диска, модель NIC, кількість дисків і MAC-адреси.
• Запишіть IP-адреси, маршрути та вимоги до VLAN.
• Переконайтеся, що цільове сховище Proxmox має місце і підтримує потрібні функції (снапшоти/реплікацію).

Контрольний список B: Експорт диска і конвертація

1. Вимкніть VM (рекомендовано).
2. Скопіюйте VMDK дескриптор і extents (або експортуйте OVA).
3. Проінспектуйте дескриптор: single vs multi-extent, нотатки про адаптер.
4. Конвертуйте за допомогою qemu-img у raw (або qcow2, якщо потрібно file-based сховище).
5. Підтвердіть за допомогою qemu-img info.

Контрольний список C: Перше завантаження в Proxmox (стабільність першочергово)

1. Створіть VM з консервативними налаштуваннями (SATA диск, E1000 NIC для Windows).
2. Підберіть прошивку (OVMF vs SeaBIOS).
3. Явно встановіть порядок завантаження.
4. Завантажтеся і підтвердіть, що ОС піднімається.
5. Виправте мережу всередині гостя, якщо змінилося ім’я/модель NIC.

Контрольний список D: Проходження продуктивності (після стабільного завантаження)

1. Встановіть QEMU guest agent.
2. Встановіть драйвери VirtIO (Windows).
3. Переключіть диск на VirtIO SCSI і NIC на VirtIO.
4. Перезавантажте і перевірте диск + мережу + додаток.
5. Зробіть бекап Proxmox і/або снапшот лише після валідації.

Задача 26: Увімкніть QEMU guest agent у конфігурації Proxmox

cr0x@server:~$ qm set 120 --agent enabled=1
update VM 120: -agent enabled=1

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

Задача 27: Підтвердіть, що агент гостя відповідає

cr0x@server:~$ qm guest ping 120
qemu-agent is running

Рішення: якщо він не працює, не звинувачуйте автоматично Proxmox — встановіть/запустіть агент в гості і перевірте firewall/SELinux, якщо потрібно.

Задача 28: Зробіть бекап після валідації

cr0x@server:~$ vzdump 120 --storage local --mode snapshot --compress zstd
INFO: starting new backup job: vzdump 120 --storage local --mode snapshot --compress zstd
INFO: VM 120: starting backup
INFO: VM 120: backup finished
INFO: Finished Backup of VM 120 (00:02:41)

Що це означає: тепер у вас є Proxmox-нативний бекап, який можна швидко відновити, якщо наступна зміна зламає завантаження.

Рішення: зробіть це перед тим, як «тюнінгувати». Бекапи дешевші за героїчні заходи.

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

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

Вони мігрували Windows file server з ESXi в Proxmox під час рутинного оновлення гіпервізора. Інженер, який робив роботу, вже успішно переносив кілька Linux-машин і припустив, що Windows поводитиметься подібно: «Приєднаю диск як VirtIO, це швидше, драйвери поставимо пізніше.» Це припущення має дуже конкретний код BSOD.

VM піднялася, враз отримала INACCESSIBLE_BOOT_DEVICE і застрягла в циклах автоматичного відновлення. Команда пробувала класичний набір прийомів: зміна типу CPU, переключення machine type, навіть «можливо це Secure Boot». Кожен перезапуск робив ситуацію голоснішою, а не кращою. Тим часом відділ надсилав скріншоти відсутніх шаред-дисків, наче це новий арт-проєкт.

Виправлення виявилося боляче простим. Вони повернули підключення диска на SATA, успішно завантажилися, встановили драйвери VirtIO для диска і мережі з ISO і лише потім переключилися на VirtIO SCSI. Windows відновилася миттєво, бо нічого не було пошкоджено; просто бракувало драйвера при завантаженні.

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

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

Інша команда вирішила бути кмітливою і імпортувати все в qcow2, бо «знаходити снапшоти легше», а потім зберігати ці qcow2 на copy-on-write бекенді. Це не було б неправильним — доки ви не робите це в масштабі з write-heavy навантаженнями і ніхто не моделює ампліфікацію.

Через кілька днів симптом був «Proxmox повільний». Латентність дисків у VM зросла. Бекапи почали тривати довше і накладатися з робочим часом. Люди почали звинувачувати мережу, бо це завжди модно.

Насправді проблема була в багатошаровому copy-on-write у середовищі, яке вже мало снапшоти і високу зміну даних. Випадкові записи перетворилися на податковий фестиваль. Накладні витрати на метадані зросли. Хости не були зламані; архітектура була.

Вони виправили це, конвертувавши високохмарні томи в raw на відповідному бекенді і залишивши qcow2 лише там, де він мав явну операційну вигоду. Продуктивність повернулася, як і здатність припинити гадати.

Оптимізація гарна. Просто не оптимізуйте два шари одночасно і не дивуйтеся, коли фізика помітить це.

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

Одна організація мала міграційний runbook, який виглядав боляче консервативним. Кожна імпортована VM спочатку завантажувалась на SATA і сумісній NIC, якщо ОС була невідома. Вони одразу брали бекап після першого вдалого завантаження, а потім переходили до встановлення драйверів і конвертації до VirtIO як до другої фази.

Це було повільно. Це не було гламурно. І це запобігло неприємному простою, коли legacy Linux appliance VM добре завантажився на SATA, але впав на VirtIO, бо його vendor image мав закритий initramfs без модулів. Якби вони почали з VirtIO — мали б мертву VM і лотерею з техпідтримки.

Оскільки вони зробили бекап у «знаному доброму» стані, вони змогли швидко відкотити зміни під час експериментів з типами контролерів. Зрештою вони залишили цей appliance на SATA назавжди, прийнявши втрату продуктивності, бо навантаження VM не виправдовувало ризик.

Це справжній дорослий крок: обирати нудну надійність над теоретичною пропускною здатністю, коли бізнес-ефект не окуповує ризик.

Питання та відповіді (FAQ)

1) Чи слід конвертувати VMDK у raw чи qcow2 для Proxmox?

Для ZFS або LVM-thin я зазвичай обираю raw. Це простіше і часто швидше. Обирайте qcow2, коли потрібні file-based снапшоти/стиснення на директоріальному сховищі.

2) Чи може Proxmox імпортувати OVA напряму?

Proxmox може працювати з дисками всередині OVA, але часто ви витягатимете OVA (це tar-архів) і конвертуватимете VMDK(и) самостійно. Це дає більше контролю і менше сюрпризів.

3) Моя VM використовувала VMware PVSCSI. Що обрати в Proxmox?

Для першого завантаження використовуйте SATA, якщо ви обережні, потім переходьте на VirtIO SCSI після встановлення драйверів. PVSCSI специфічний для VMware; немає прямого «PVSCSI еквіваленту» для простого перемикання.

4) Windows завантажується на SATA, але падає на VirtIO SCSI. Чому?

Драйвер VirtIO для сховища не встановлений/не увімкнений на момент завантаження. Завантажтеся на SATA, встановіть драйвери VirtIO і потім перемикайте контролер і перезавантажуйтесь.

5) Linux завантажується, але змінилося ім’я NIC і мережа не працює. Яке чисте виправлення?

Оновіть мережеву конфігурацію відповідно до нового імені інтерфейсу, або використайте MAC-базовані правила. Уникайте хардкоджених припущень eth0; це вже пройшло.

6) Яка найпоширеніша помилка з UEFI/BIOS?

Імпорт UEFI-встановленого гостя з подальшим завантаженням через SeaBIOS (або навпаки). Підтвердіть з VMX і/або наявність EFI System Partition.

7) Чи потрібен QEMU guest agent?

Потрібен? Ні. Бажаний? Так. Він покращує поведінку вимкнення, звітування IP і автоматизацію, і зменшує кількість «чому Proxmox бреше» дискусій.

8) Імпортована Windows VM втратила статичний IP. Куди він подівся?

Windows трактує новий NIC як інший адаптер. Старий адаптер може «володіти» IP-конфігом, але бути прихованим/відключеним. Перепризначте IP активному адаптеру і приберіть застарілі NIC при потребі.

9) Чи можна назавжди залишити VM на SATA?

Так. Для легких навантажень накладні витрати SATA можуть бути незначними. Для інтенсивного I/O VirtIO SCSI варто використовувати після підтвердження стабільності.

10) Як зрозуміти, чи вузьке місце — це сховище хоста Proxmox або гість?

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

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

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

Конкретні кроки на сьогодні:

1. Оберіть одну VM і пройдіть «workflow у стилі стабільність першочергово»: імпорт диска, завантаження на SATA, перевірка сервісів.
2. Встановіть QEMU guest agent і зробіть бекап Proxmox у першій відомо-робочій точці.
3. Для Windows: підмонтуйте VirtIO ISO, встановіть драйвери диска і мережі, потім переведіть на VirtIO SCSI + VirtIO NIC.
4. Для Linux: перевірте, що initramfs містить модулі VirtIO, перекладіть fstab на UUID якщо потрібно, потім переключайте контролери.
5. Лише після вдалого завершення: стандартизуйте шаблони і документуйте ваш маппінг NIC/VLAN, щоб наступна міграція не була археологією.