Migracja VMware → Proxmox: 7 pułapek, które psują maszyny po imporcie

Sam import maszyny z VMware do Proxmox VE to dziś kwestia kilku kliknięć – kreator „Import from ESXi" w Proxmox 8+ albo `qm disk import` robią większość roboty. Problem w tym, że import prawie zawsze „się udaje", a prawdziwe kłopoty zaczynają się przy pierwszym starcie: Windows wpada w niebieski ekran, Linux gubi sieć, zegar się rozjeżdża, a live migration między nodami nagle nie działa.

To nie są egzotyczne przypadki – to te same siedem pułapek, które łapiemy w niemal każdej migracji. Poniżej opisujemy objaw, przyczynę i konkretne rozwiązanie każdej z nich. Jeśli planujesz przeniesienie środowiska z vSphere po podwyżkach Broadcomu, potraktuj ten tekst jak checklistę „co sprawdzić, zanim uznasz migrację za skończoną".

1. Windows nie startuje: BSOD `INACCESSIBLE_BOOT_DEVICE`

Objaw: zaimportowana maszyna z Windows Server wpada w pętlę niebieskiego ekranu z kodem `INACCESSIBLE_BOOT_DEVICE` zaraz po logo.

Dlaczego: w VMware dysk systemowy „wisiał" na kontrolerze LSI/PVSCSI. W Proxmox domyślnie proponowany jest VirtIO SCSI – wydajny, ale Windows nie ma jego sterownika w obrazie systemu, więc nie widzi dysku, z którego ma się uruchomić.

Rozwiązanie: nie podłączaj dysku systemowego od razu jako VirtIO. Kolejność, która działa zawsze:

Od tej chwili Windows ma sterownik i bootuje z szybkiego kontrolera. Ten sam trik dotyczy dysków danych.

2. Zły kontroler dysku i brak `discard` (TRIM)

Objaw: maszyna działa, ale dysk jest wolniejszy niż na VMware, a skasowane dane nie zwalniają miejsca na storage (thin provisioning „puchnie").

Dlaczego: po imporcie dysk często ląduje na SATA/IDE „na stałe" (patrz punkt 1) albo bez włączonej opcji odzyskiwania miejsca.

Rozwiązanie: docelowo trzymaj dyski na VirtIO SCSI single, a w ustawieniach dysku zaznacz Discard oraz SSD emulation (jeśli storage pod spodem to SSD/NVMe/thin LVM/ZFS). Discard sprawia, że `fstrim` w gościu realnie zwalnia bloki na warstwie storage – bez tego thin provisioning rośnie i nigdy się nie kurczy.

3. UEFI kontra BIOS: VM w ogóle się nie uruchamia

Objaw: po imporcie maszyna „nie robi nic" – czarny ekran, brak bootloadera, ewentualnie od razu wchodzi do UEFI Shell.

Dlaczego: maszyna z VMware była instalowana w trybie UEFI, a w Proxmox trafiła na domyślny SeaBIOS (albo odwrotnie). Firmware musi się zgadzać z tym, jak zainstalowany jest system gościa – inaczej nie ma z czego wystartować.

Rozwiązanie:

• Dla maszyn UEFI ustaw w Options → BIOS: OVMF (UEFI) i dodaj EFI Disk (Proxmox zaproponuje utworzenie).
• Jeśli oryginał miał Secure Boot i nie masz zaimportowanych kluczy – wyłącz Secure Boot w konsoli OVMF (`Device Manager → Secure Boot Configuration`), inaczej bootloader zostanie odrzucony.
• Dla starszych maszyn na BIOS zostaw SeaBIOS.

Prosty test diagnostyczny: jeśli w VMware w ustawieniach było „EFI", w Proxmox musi być OVMF.

4. Linux wstaje, ale nie ma sieci

Objaw: maszyna Linux uruchamia się poprawnie, ale nie ma połączenia – `ip a` pokazuje interfejs bez adresu albo interfejsu w ogóle nie ma.

Dlaczego: dwie typowe przyczyny. Po pierwsze, nazwa interfejsu się zmieniła – w VMware było `ens160`, w Proxmox jest `ens18` – a konfiguracja sieci (netplan, `ifcfg`, `/etc/network/interfaces`) wciąż odwołuje się do starej nazwy. Po drugie, w systemie zostały reguły udev przypinające interfejs do starego adresu MAC (`/etc/udev/rules.d/70-persistent-net.rules`).

Rozwiązanie:

• Sprawdź realną nazwę interfejsu: `ip link`.
• Zaktualizuj konfigurację sieci pod nową nazwę (netplan/`interfaces`/NetworkManager).
• Usuń nieaktualne reguły `70-persistent-net.rules`, jeśli istnieją.
• Alternatywnie – dla maszyn, które muszą zachować `eth0` – dodaj `net.ifnames=0 biosdevname=0` do parametrów jądra w GRUB.

Przy okazji: jeśli w gościu było oprogramowanie licencjonowane po adresie MAC, ustaw w Proxmox ten sam MAC, jaki miała karta w VMware (Hardware → Network Device → MAC address).

5. Zostały VMware Tools, brakuje qemu-guest-agent

Objaw: Proxmox nie pokazuje adresu IP maszyny, „Shutdown" nie działa poprawnie (twarde wyłączenie zamiast czystego), a backupy nie są w pełni spójne.

Dlaczego: w gościu wciąż siedzą VMware Tools, które w środowisku Proxmox nie mają czego obsługiwać, a jednocześnie brakuje qemu-guest-agent – to on odpowiada za czyste zamykanie, raportowanie IP i „zamrożenie" systemu plików (fs-freeze) na czas snapshotu/backupu.

Rozwiązanie:

• Odinstaluj VMware Tools w systemie gościa (Windows: „Programy i funkcje"; Linux: `open-vm-tools` przez menedżera pakietów).
• Zainstaluj agenta: Linux – `apt install qemu-guest-agent` (lub odpowiednik), Windows – jest w paczce virtio-win-guest-tools.
• Włącz agenta w Proxmox: Options → QEMU Guest Agent → Enabled, i uruchom VM ponownie.

Bez tego kroku backupy PBS działają w trybie „unmanaged" i mogą złapać niespójny stan bazy danych.

6. Zegar się rozjeżdża (dryf czasu)

Objaw: po migracji czas w maszynie ucieka – typowo Windows pokazuje inną godzinę niż powinien, logi mają złe znaczniki, kończą się bilety Kerberos.

Dlaczego: Linux zwykle zakłada, że zegar sprzętowy (RTC) chodzi w UTC, a Windows – w czasie lokalnym. Po przeniesieniu maszyny ustawienie RTC w Proxmox nie pasuje do oczekiwań gościa.

Rozwiązanie: dla maszyn Windows ustaw w Options → RTC start date / Local time: zaznacz, że zegar sprzętowy jest w czasie lokalnym (`localtime`). Dla Linuksa zostaw UTC i zadbaj o działający NTP/chrony w gościu. To drobiazg, który potrafi wywrócić uwierzytelnianie w domenie AD.

7. Typ CPU: albo wolno, albo live migration nie działa

Objaw: dwa warianty. Albo aplikacje działają zauważalnie wolniej niż na VMware (brak nowoczesnych instrukcji CPU), albo – po ustawieniu CPU na `host` – live migration między nodami klastra kończy się błędem.

Dlaczego: domyślny typ CPU w Proxmox (`kvm64`) jest maksymalnie zgodny, ale ubogi – nie przekazuje gościowi nowoczesnych flag (AES-NI, AVX). Ustawienie `host` daje pełną wydajność, ale „przykleja" maszynę do konkretnego modelu procesora – a live migration wymaga, by CPU na obu nodach było zgodne.

Rozwiązanie:

• Pojedynczy host / jednorodny klaster: ustaw CPU type = host – maksymalna wydajność.
• Klaster z różnymi generacjami procesorów: wybierz wspólny mianownik, np. x86-64-v2-AES albo najstarszy pasujący model – wtedy live migration działa na wszystkich nodach, a i tak dostajesz nowoczesne instrukcje.

Zrobić samemu czy zlecić?

Pojedynczą maszynę testową spokojnie przeniesiesz sam według powyższej listy – i warto to zrobić, żeby „poczuć" proces. Schody zaczynają się przy migracji produkcji: kilkadziesiąt VM, klaster z HA, storage do zaprojektowania od zera (ZFS vs Ceph), okno serwisowe liczone w godzinach i zero tolerancji na utratę danych. Tutaj kolejność działań, projekt sieci i storage oraz plan wycofania ważą więcej niż same komendy importu.

Jeśli planujesz przeniesienie całego środowiska vSphere, a nie chcesz uczyć się tych pułapek na produkcji – zróbmy to razem. Robimy migracje VMware/Hyper-V → Proxmox po polsku: audyt środowiska, projekt docelowej architektury, migracja w oknie serwisowym i wsparcie powdrożeniowe.

FAQ

Czy podczas migracji trzeba wyłączać maszynę?

Standardowa migracja „na zimno" wymaga wyłączenia VM na czas kopiowania dysku. Da się skrócić okno serwisowe (wstępna kopia + krótkie okno na dosynchronizowanie), ale to już element projektu migracji, nie prostego importu.

Czy da się zaimportować prosto z działającego ESXi?

Tak – Proxmox VE 8+ ma wbudowany import ze storage ESXi (Datacenter → Storage → Add → ESXi). Nie zwalnia to jednak z siedmiu punktów powyżej – one dotyczą stanu maszyny po skopiowaniu.

Co z maszynami z wieloma dyskami i snapshotami VMware?

Snapshoty VMware należy skonsolidować przed migracją – przenosimy „płaski" dysk, nie łańcuch delt. Maszyny wielodyskowe importujemy dysk po dysku i dopiero potem składamy w VM.

Podsumowanie

Import to 20% pracy – pozostałe 80% to VirtIO, firmware, sieć, agent, czas i CPU. Przejdź te siedem punktów, a maszyna po migracji będzie działać stabilnie i szybko, a nie „jakoś".

Chcesz policzyć koszt subskrypcji Proxmox dla docelowego środowiska? Otwórz kalkulator. Planujesz migrację z VMware i wolisz omówić ją z kimś, kto robił to wielokrotnie? Umów bezpłatną konsultację albo napisz na proxmox@polsoft.pl / zadzwoń 32 209 80 39 (pon.–pt. 8:00–16:00).