Міграція VM з ESXi в Proxmox без vCenter: експорт OVF/OVA, імпорт і виправлення драйверів

November 1, 2025 • February 3, 2026 • Читання: 4 хв • Views: 8

Було корисно?

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

Це польовий посібник для чистої міграції: експортуйте OVF/OVA зі standalone ESXi, імпортуйте в Proxmox і виправте передбачувані поломки — контролери дисків, моделі NIC, режим завантаження та драйвери — не перетворюючи міграцію на уїк-енд як заручника.

Цікаві факти та контекст (щоб зрозуміти дивні явища)

OVF — це специфікація пакування, а не магія. OVF описує VM (CPU, RAM, пристрої). Диски зазвичай окремі файли VMDK або упаковані в OVA (архів tar).
OVA — це просто tar. Якщо OVA не імпортується, її зазвичай можна розпакувати стандартними інструментами й працювати з VMDK напряму.
VMDK має різновиди. ESXi часто використовує «monolithicSparse» або «streamOptimized» при експорті. Деякі конвертери й імпортери не люблять певні підтипи. «Stream optimized» часто зустрічається в OVF/OVA експортах.
VMXNET3 і PVSCSI — це специфічні для VMware високопродуктивні пристрої. Вони чудові на ESXi, але Proxmox/QEMU не емулює їх нативно. Ви перейдете на VirtIO або Intel E1000, і це призведе до питань із драйверами.
VirtIO швидкий, бо паравіртуалізований. Гостьова ОС потребує драйверів. Linux зазвичай вже має їх; Windows часто — ні (якщо тільки це не сучасна система з попередньо встановленими VirtIO).
UEFI проти BIOS — тихий вбивця. ESXi VM може бути з BIOS або EFI; Proxmox підтримує обидва, але треба збігтися. Завантаження ОС, встановленої під BIOS, у середовищі UEFI — швидкий шлях до повідомлення «no bootable device».
Snapshot-и ускладнюють експорт. Якщо у VM є snapshots, «поточний диск» — це ланцюг delta-файлів. Інструменти експорту іноді консолідують їх; іноді — ні. Завжди перевіряйте, що саме ви експортували.
Thin vs thick впливає на час і простір. «Thin» VMDK може конвертуватися у «thick» raw-образ, якщо не обережні, що різко збільшить площу й час міграції.
Proxmox використовує моделі пристроїв QEMU. «Така сама» VM на новому гіпервізорі — це інший набір апаратного забезпечення. Операційні системи вередують щодо ідентичності контролерів дисків.

Рішення, які важливо прийняти перед будь-якими діями

1) Визначте, чи можете ви дозволити простої

Якщо у вас немає реплікації на спільному сховищі або інструменту блок-рівня для міграції, OVF/OVA експорт за замовчуванням — це cold migration. Можна зробити напів-теплий підхід (вікно простою, експорт, імпорт, тест і переключення), але не прикидайтеся, що це жива міграція. Бізнес-стейкхолдери часто оцінюють «міграцію» як «нульовий простій», бо оптимізм дешевший за інженерні зусилля.

2) Визначте формат цільового диска: raw чи qcow2

У Proxmox диски зазвичай розміщують на:

ZFS: raw zvol — поширений варіант; qcow2 можливий, але часто зайвий. Raw простіший і швидший для більшості навантажень.
LVM-thin: зазвичай raw (thin-provisioned на шарі сховища).
Directory storage (ext4/xfs): qcow2 зручний (снапшоти), raw — теж ок (простота).

Моя думка: якщо ваше сховище Proxmox — ZFS або LVM-thin, віддавайте перевагу raw. Якщо це директорія і потрібні файл-ґрунтові снапшоти, використовуйте qcow2. Не обирайте qcow2 тому, що це «звучить віртуально». Обирайте, бо це відповідає вашим вимогам щодо снапшотів і продуктивності.

3) Визначте моделі пристроїв: VirtIO де можливо

Для Linux-гостьових систем: VirtIO для диска і NIC майже завжди працює. Для Windows: VirtIO — також правильний вибір, але потрібно спланувати встановлення драйверів. Якщо це критична Windows VM і хочете, щоб міграція пройшла без пригод, можна спочатку завантажитися з SATA + E1000, а потім переключитися на VirtIO після встановлення драйверів.

4) Визначте BIOS чи UEFI прямо зараз

Збігайте режим завантаження гостьової ОС. Якщо ESXi VM завантажується через EFI, налаштуйте прошивку Proxmox як OVMF (UEFI). Якщо BIOS — використовуйте SeaBIOS. Конвертація пізніше — окремий проєкт із реальними ризиками відмови.

Парафраз ідеї від Gene Kranz: «Бути твердим і компетентним» — це вибір, який роблять до помилки, не під час неї.

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

Що робити, коли імпортована VM не завантажується, не бачить диск або не має мережі. Не метушіться. Пройдіть стек.

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

Перевірте апаратну конфігурацію VM у Proxmox: диск присутній, правильна шина (SATA/SCSI/VirtIO), правильний порядок завантаження.
Перевірте сховище: чи існує образ диска там, де Proxmox його очікує?

Друге: переконайтеся, що прошивка відповідає встановленню (UEFI vs BIOS)

BIOS-інсталяція + UEFI-прошивка = театр «no bootable device».
UEFI-інсталяція + BIOS-прошивка = те саме, але з додатковою плутаниною.
UEFI часто потребує окремого EFI-диска в Proxmox (малий диск для NVRAM).

Третє: переконайтеся у доступності драйверів для обраного контролера диска та NIC

Якщо Windows синій екран на ранньому етапі (INACCESSIBLE_BOOT_DEVICE): відсутній драйвер контролера диска. Запустіть з SATA, встановіть VirtIO, переключіть потім.
Якщо Linux падає в initramfs: неправильне відображення root-диска або initramfs без модулів для нового контролера; перебудуйте initramfs і/або виправте fstab/GRUB.

Четверте: переконайтеся, що мережа правильно змаплена

Міст підключений? Правильний тег VLAN? Фаєрвол Proxmox блокує?
У гостя: ім’я інтерфейсу змінилося (Linux), метрика інтерфейсу дивна (Windows), або статична IP прив’язана до старого адаптера.

П’яте: проблеми з продуктивністю після завантаження

Перевірте, чи ви випадково не використовували емуляцію IDE або E1000 для високонавантажених робіт.
Перевірте режим кешування і iothreads. Перевірте затримки на шляху до сховища на вузлі Proxmox. Зазвичай це не «Proxmox повільний», а «шлях до сховища тепер інший».

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

Ось виконувані команди і що робити з результатами. Мета — замінити здогадки доказами.

Завдання 1: Визначити режим завантаження і типи контролерів на ESXi

На хості ESXi (SSH увімкнено) знайдіть файл VMX і перегляньте його.

Значення: Тепер у вас є шлях до VMX на datastore. Можна перевірити прошивку і типи пристроїв.

Рішення: Якщо VM критичний, стратегія snapshot/консолідації має значення перед експортом.

Завдання 2: Перевірте наявність snapshоt-ів (і не ігноруйте їх)

Значення: Snapshоt-и є. Поведінка експорту залежить від інструменту; ви можете експортувати ланцюг або консолідований образ.

Рішення: Віддавайте перевагу консолідації snapshot-ів перед експортом, якщо немає причин інакше. Експорт — не те місце для хитромудрих ланцюгів.

Завдання 3: Експорт без vCenter (практичні варіанти)

Без vCenter зазвичай експортують, копіюючи файли зі datastore або використовуючи інструмент OVF на робочій станції, що має доступ до IP керування ESXi.

Якщо у вас вже є OVA/OVF експорт, пропустіть цей крок. Якщо ні, копіювання VMDK(ів) напряму часто простіше.

Значення: У вас є дескриптор VMDK і плоский екстент. Це типовий розклад ESXi.

Рішення: Копіюйте і .vmdk, і -flat.vmdk якщо робите сире копіювання файлів. Якщо скопіюєте лише дескриптор — ви скопіювали ярлик, а не диск.

Завдання 4: Перевірити, який саме VMDK у вас є

Значення: Це дескриптор у стилі VMFS, який вказує на плоский екстент. Добре.

Рішення: Конвертація з qemu-img має працювати. Якщо createType — streamOptimized, очікуйте іншу поведінку і можливий проміжний крок конвертації.

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

Значення: У вас є кілька бекендів сховища. Місце є, але не безмежне.

Рішення: Оберіть цільове сховище на основі продуктивності і потреб у снапшотах. Не кладіть базу даних на повільне директорне сховище тільки тому, що «так зручніше».

Завдання 6: Розпакувати OVA (якщо це те, що у вас є)

Значення: Тепер у вас є OVF-дескриптор і VMDK(и).

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

Завдання 7: Переглянути OVF на очікування пристроїв

Значення: OVF описує апаратні типи VMware (vmxnet3). Proxmox цього не повторить один-до-одного.

Рішення: Ставтеся до OVF як до метаданих, а не до обіцянки. Ви явно визначатимете апарат у Proxmox.

Завдання 8: Конвертувати VMDK у raw або qcow2 на Proxmox

Вибирайте raw для ZFS/LVM-thin; qcow2 — для директорних сховищ із потребою в снапшотах.

Значення: streamOptimized диск. Конвертація працює, але звертайте увагу на sparse-поведінку.

Рішення: Конвертуйте за допомогою qemu-img convert. Якщо бачите корупцію або помилки, конвертуйте спочатку в raw, а потім імпортуйте.

Завдання 9: Створити «каркас» VM у Proxmox (ще не підключаючи диски)

Значення: VM створена з VirtIO NIC і контролером VirtIO SCSI. Тип машини q35 сучасний і добре працює з UEFI.

Рішення: Якщо джерело — UEFI, задайте OVMF зараз. Якщо BIOS — лишіть SeaBIOS.

Завдання 10: Налаштувати UEFI (OVMF) і додати EFI-диск при потребі

Значення: VM завантажуватиметься з UEFI і матиме диск для збереження змін NVRAM.

Рішення: Якщо Secure Boot не використовувався на ESXi, лишайте pre-enrolled-keys=0, аби уникнути проблем з підписами.

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

Значення: Диск тепер — керований том у сховищі. Це важливо для бекапів, реплікації й порядку.

Рішення: Підключіть імпортований диск до потрібної шини. Для Linux зазвичай підійде VirtIO SCSI. Для Windows без драйверів — почніть з SATA.

Завдання 12: Підключити диск і задати порядок завантаження

Значення: Диск підключений як SCSI (VirtIO SCSI) і встановлений першим у порядку завантаження.

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

Завдання 13: Запустити VM і уважно дивитися консоль

Значення: Якщо бачите ініціалізацію драйверів virtio — хороший знак. Якщо впав у initramfs, потрібні виправлення root-диска і initramfs.

Рішення: Не «чекайте і дивіться» 20 хвилин. Помилки завантаження не проходять самі по собі.

Завдання 14: Перевірити видимість диска в Linux

Значення: Розділи присутні й змонтовані. ОС бачить диск.

Рішення: Якщо імена пристроїв змінилися (наприклад, з /dev/sda на /dev/vda), переконайтеся, що /etc/fstab використовує UUID, а не імена пристроїв.

Завдання 15: Перевірити мережевий пристрій і стан каналу

Значення: Інтерфейс піднятий. Ім’я, ймовірно, змінилося порівняно з ESXi. Це нормально.

Рішення: Якщо ім’я інтерфейсу змінилося й конфігурація мережі посилається на старе, оновіть netplan/systemd-networkd/ifcfg відповідно.

Завдання 16: На Proxmox перевірити міст і VLAN-теги

Значення: Стандартний Linux-міст. Теги VLAN можна задавати для кожного NIC у Proxmox або через VLAN-aware міст.

Рішення: Якщо потрібен VLAN-trunking, ввімкніть bridge-vlan-aware yes і налаштуйте теги свідомо. Не вгадуйте; ваш комутатор не пробачить помилок.

Завдання 17: Підтвердити, що Proxmox бачить конфігурацію VM, яку ви очікували

Значення: Це канонічна істина. Якщо GUI відрізняється, саме конфіг виглядає виводом.

Рішення: Збережіть цей вивід у звіті про зміни. Так ви потім доведете, що саме змінювали.

Жарт №1: OVF — як коносамент: каже, що має бути в коробці, але не гарантує, що коробка пережила вилочний навантажувач.

Чеклісти / покроковий план (нудно, але правильно)

Чекліст перед міграцією (джерело ESXi)

Документуйте апаратну конфігурацію VM: прошивка (EFI/BIOS), контролер диска, тип NIC, кількість дисків, IP-конфігурація.
Очистіть snapshot-и: консолідуйте або хоча б розумійте ланцюг. Експорт ланцюга snapshot-ів — місце, де втрачають дані.
Згасіть додаток: на рівні застосунку вимкніть сервіси (бази даних, черги). Якщо не можна — хоча б коректно вимкніть VM.
Зберіть драйвери: для Windows підготуйте ISO з драйверами VirtIO. Для Linux переконайтеся, що інструменти initramfs доступні всередині гостя.
Визначте метод переключення: нова IP чи та сама? Зміни DNS? MAC-резервації? Правила фаєрволу?

Чекліст виконання міграції (Proxmox)

Створіть каркас VM з CPU/RAM, близьким до джерела. Не підганяйте ідеально відразу.
Встановіть прошивку (OVMF vs SeaBIOS) відповідно до джерела.
Імпортуйте диск у вибране сховище.
Підключіть диск до адекватного контролера (VirtIO SCSI для Linux; SATA спочатку для Windows, якщо драйвери відсутні).
Явно задайте порядок завантаження.
Завантажуйте з відкритою консоллю; фіксуйте помилки рано.
Виправляйте проблеми завантаження/драйверів (див. розділи нижче).
Виправте мережеве відображення, підтвердіть зв’язність, ім’я хоста/DNS.
Видаліть VMware Tools, якщо потрібно, встановіть QEMU guest agent.
Прогіньте валідацію навантаження: I/O диска, перевірки додатків, логи, моніторинг.

Чекліст після міграції (стабільність і працездатність)

Резервні копії: переконайтеся, що завдання бекапу Proxmox включають VM і тестове відновлення працює.
Моніторинг: підтвердіть, що VM у правильних алертах з коректними агентами.
Синхронізація часу: перевірте NTP/chrony; не покладайтеся на «час гіпервізора».
Перевірка продуктивності: підтвердіть, що ви використовуєте VirtIO, а не IDE. Перегляньте налаштування I/O scheduler та discard/TRIM, якщо треба.
Запис змін: збережіть «до» і «після» конфігурації VM та мережеві деталі.

Виправлення драйверів і завантаження: Windows та Linux

Windows: безпечний шлях (спочатку завантаження, потім оптимізація)

Якщо Windows на ESXi використовував PVSCSI і VMXNET3, він не буде знати, що робити з VirtIO. Типова відмова — BSOD при завантаженні: INACCESSIBLE_BOOT_DEVICE. Це Windows каже: «Новий контролер — я цієї мови не знаю.»

Linux: зазвичай легко, поки ні

Linux має тенденцію завантажуватися на VirtIO без драм. Коли не завантажується — причини постійні:

/etc/fstab посилається на /dev/sdX замість UUID/LABEL і ім’я пристрою змінилося.
initramfs не містить модулів для нового контролера (менш ймовірно на сучасних дистрибутивах, але трапляється на мінімальних образах).
несумісний режим завантаження (UEFI vs BIOS).

Виправлення: переконайтеся, що fstab використовує UUID

Значення: Монтування за UUID. Зміна імен пристроїв не зламає завантаження.

Рішення: Якщо бачите /dev/sda1 у fstab, виправте це перед наступним перезавантаженням.

Виправлення: перебудувати initramfs (приклад Debian/Ubuntu)

Значення: initramfs оновлено; він міститиме потрібні модулі.

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

Виправлення: перевстановлення GRUB після невідповідності прошивки або зміни відображення дисків

Для BIOS-інсталяцій на новому віртуальному контролері перевстановлення GRUB може бути найпростішим рішенням.

Значення: Завантажувач відновлено у BIOS-режимі на цьому диску.

Рішення: Якщо насправді ви використовуєте UEFI, не робіть grub-install для BIOS — це лише додасть плутанини з двома варіантами завантаження.

Жарт №2: UEFI чудовий, поки не перестає бути, тоді це стає інтерпретативним танцем прошивки.

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

Вибір мосту: підключіть VM до правильного світу

Мережі Proxmox — це Linux-мережі. І це комплімент і попередження одночасно.

vmbr0 зазвичай — ваш LAN-міст.
Теги VLAN можна задавати на рівні NIC у Proxmox (tag=123) або використовуючи VLAN-aware міст.
Bonding/LACP налаштовується на хості; VM просто бачить NIC.

Значення: NIC VM на VLAN 120, фаєрвол увімкнено на рівні Proxmox.

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

MAC-адреси і ліцензування

Деяке програмне забезпечення прив’язує ліцензії до MAC-адрес. Деякі підходи довіри теж. Proxmox згенерує новий MAC, якщо ви явно його не задано.

Значення: У VM є стабільний MAC, заданий у конфігурації.

Рішення: Якщо потрібно зберегти MAC ESXi, задайте його явно перед першим завантаженням, щоб уникнути поведінки «нового NIC» у гостя.

Зміни імен NIC у Linux і правила постійності

На ESXi NIC могло називатися ens160. На Proxmox — ens18 або enp0s18. Якщо дистрибутив використовує netplan або systemd-networkd, логіка перейменування може заподіяти проблеми.

Значення: Перейменування відбулося; systemd бачить інтерфейс.

Рішення: Оновіть сітьову конфігурацію під нові імена або закріпіть імена за MAC через правила match.

Три корпоративні міні-історії (як це йде не так на практиці)

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

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

Хтось нарешті купив Proxmox-кластер. Мандат був простий: перенести найкритичнішу VM за вікенд, без vCenter, не витрачаючи гроші. Інженер експортував OVA з ESXi, імпортував його, і VM завантажилася. Це був момент, коли всі розслабилися — історично найнебезпечніший момент у роботі операцій.

Вранці в понеділок користувачі почали скаржитися на періодичні збої. Додаток «працював», але половина запитів тайм-аут. Корінь проблеми не в CPU чи пам’яті. Це була мережа: у ESXi VM мала дві NIC — фронтенд і бекенд — і метадані OVA не змепили ролі пристроїв. На Proxmox порядок NIC змінився, ОС зберегла статичні IP, і застосунок почав звертатися до бекенд-сервісів через фронтенд VLAN.

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

Виправлення було нудним: явно змепити NIC (міст + VLAN тег), задати MAC, перевірити таблиці маршрутизації і валідувати справжню залежність додатку — не лише ICMP. Урок засвоїли, бо він був болючим і публічним.

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

Інша команда розглядала міграцію як шанс оптимізувати. Вони конвертували всі диски в qcow2, бо «снапшоти корисні», і ввімкнули всі параметри кешування, що звучали швидко. Також одразу перевели Windows VM на VirtIO для диска і NIC, бо вже робили це в лабораторії.

Результат був вражаючим так само, як піротехнічний склад може вразити. Деякі VM не завантажилися (проблема з драйвером). Інші завантажилися, але під навантаженням мали дивні сплески латентності. Команда ганяла привидів усередині гостя дні — антивірус, оновлення Windows, «може SQL щось робить».

Насправді проблема була в сукупності рішень: qcow2 на директорному сховищі поверх RAID з нестабільним кешем, агресивні writeback-настройки в QEMU і відсутність UPS-гарантій. Працювало, поки не перестало. Латентність зростала під час подій flush на хості, і профіль ризику виявився неприйнятним для stateful навантажень.

Вони відкотилися до raw-томів на ZFS zvol для баз даних, поставили консервативний кеш і продуктивність стабілізувалася одразу. Снапшоти перемістилися до нативних ZFS-снапшотів. Оптимізація не погана; погана — невпорядкована оптимізація.

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

Регульоване підприємство повинно було мігрувати ESXi VM з критичним лінійним сервісом, з давніми залежностями і постачальником, який давно пішов далі. Середовища не мало vCenter. ESXi-хост — «pet», не cattle, з локальним сховищем і нервовою командою з експлуатації інфраструктури.

SRE на виклику наполягав на нудному процесі: зафіксувати налаштування VMX, записати контрольні суми дисків після експорту, імпортувати в Proxmox з тим же режимом завантаження і тримати стару VM вимкненою, але цілою протягом робочого тижня. Також вимагали тестового завантаження в ізольованому VLAN перед продуктивним переключенням.

Під час ізольованого тестування VM завантажилася, але не могла досягти свого ліцензійного сервера. Проблема не в мережі; вона в часі. VM тихо покладалася на синхронізацію часу від VMware Tools, а Proxmox не дає такої ж поведінки. Ліцензійний обмін не пройшов, коли розбіжність часу перевищила допуск.

Оскільки команда тестувала в ізоляції і мала план відкату, вони правильно налаштували NTP/chrony, задокументували поведінку і зробили переключення акуратно. В проді нічого драматичного не сталося — найвища похвала для людини з експлуатації.

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

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

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

Виправлення: Збігайте прошивку з джерелом (OVMF для EFI, SeaBIOS для BIOS). Додайте efidisk0 для OVMF. Встановіть явний порядок завантаження.

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

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

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

3) Симптом: Linux падає в initramfs або emergency shell

Корінь: Root-файлова система не знайдена через зміну імен пристроїв, відсутні модулі в initramfs або fstab посилається на /dev/sdX.

Виправлення: Використовуйте UUID у fstab, перебудуйте initramfs, перевірте, що GRUB вказує на правильний root.

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

Корінь: Неправильний міст/VLAN тег, правила фаєрволу Proxmox, зміни імен NIC у гості або Windows з статичним IP, прив’язаним до старого адаптера.

Виправлення: Перевірте міст і VLAN на хості; тимчасово відключіть фаєрвол Proxmox для ізоляції; виправте конфігурацію гостя; збережіть MAC, якщо потрібно.

5) Симптом: Диск присутній у Proxmox, але гість бачить 0 байт або пошкоджену ФС

Корінь: Неповне копіювання VMDK екстентів, snapshot-ланцюг не консолідовано або помилка конвертації зі streamOptimized.

Виправлення: Повторно експортуйте після консолідації snapshot-ів; перевірте, що і дескриптор, і плоскі файли скопійовані; переконвертуйте через проміжний raw; перевірте контрольні суми.

6) Симптом: VM повільна, особливо I/O

Корінь: Використання IDE/SATA для навантаження, яке потребує VirtIO, невірний режим кешу, невідповідність бекенду сховища або відсутність iothread для навантажених дисків.

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

7) Симптом: Додаток працює, але ліцензування ламається

Корінь: Зміна MAC-адреси, зсув часу або зміна апаратного відбитка.

Виправлення: Збережіть MAC, якщо потрібно; налаштуйте NTP; задокументуйте новий віртуальний апаратний профіль і зверніться до постачальника, якщо уникнути проблем не вдається.

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

1) Чи потрібен vCenter, щоб експортувати OVF/OVA?

Ні. vCenter полегшує процес, але можна експортувати, копіюючи файли VM зі datastore ESXi або використовуючи інструмент OVF проти самого ESXi-хоста.

2) Краще експортувати OVF/OVA чи копіювати VMDK?

Якщо можна коректно завершити роботу, копіювання VMDK-файлів часто простіше й прозоріше. OVF/OVA зручні для пакування, але можуть приховувати нюанси формату диска (наприклад, streamOptimized).

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

Не в ті способи, на які варто ставити продукцію. Ставтеся до OVF як до дескриптора; витягайте диски та імпортуйте їх за допомогою qm importdisk після конвертації за потреби.

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

Raw на ZFS zvol або LVM-thin зазвичай правильний вибір для продуктивності й простоти. qcow2 підходить на директорних сховищах, коли потрібні файл-ґрунтові снапшоти.

5) Чому моя Linux VM завантажується на ESXi, але падає на Proxmox в initramfs?

Бо «апарат» змінився: модель контролера, іменування дисків або прошивка. Виправте fstab на UUID, перебудуйте initramfs і переконайтеся в режимі BIOS/UEFI.

6) Як безпечно працювати з драйверами VirtIO у Windows?

Спочатку завантажте Windows на SATA, встановіть драйвери VirtIO з підключеного ISO, потім переключіть контролер диска на VirtIO SCSI і NIC на VirtIO. Один крок за раз з перезавантаженнями між ними.

7) Чи потрібно видаляти VMware Tools?

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

8) Що з підтримкою гостьового агента в Proxmox?

Встановіть QEMU guest agent у VM після стабілізації. Це покращує поведінку при вимкненні, звіт про IP і деякі сценарії бекапу. Це — операційна гігієна.

9) Чи можу зберегти ту ж IP-адресу після міграції?

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

10) Який найбільший «невідомий невідомий» у цих міграціях?

Залежності від поведінки VMware: синхронізація часу, порядок NIC, кастомні драйвери і припущення щодо snapshot-ів. Проведіть аудит цих речей заздалегідь — і міграція стане рутинною.

Висновок: кроки, які реально знижують ризик

Якщо з цієї інструкції ви зробите лише три дії, зробіть ці:

Збігайте режим завантаження (UEFI vs BIOS) перед першим запуском у Proxmox. Це найдешевша перемога.
Спочатку завантажуйте для сумісності (особливо Windows), а потім переходьте на VirtIO після встановлення драйверів.
Доведіть коректність командами: наявність сховища, порядок завантаження, стан інтерфейсів і логи. Під тиском пам’ять бреше.

Операційно розглядайте міграцію як два результати: здатність до завантаження і працездатність. Отримання запрошення до входу — не фініш. Бекапи, моніторинг, синхронізація часу і продуктивність утримують вас від повторного відвідування цієї VM о 3-й ранку з аудиторією.