Migracja VMware → Proxmox 2026 — kompletny playbook PL

Kontekst rynkowy 2026

Po przejęciu VMware przez Broadcom (listopad 2023) producent zlikwidował model perpetual license na rzecz subskrypcji w pełnym pakiecie (vSphere Foundation, Cloud Foundation), znacząco podnosząc ceny dla klientów MŚP. Według publicznie dostępnych komunikatów producenta (vmware.com, broadcom.com), minimalna subskrypcja vSphere Standard wynosi 16 rdzeni per CPU, a model wycen przesunął się z socket-based na core-based.

W praktyce dla przeciętnego serwera 2× 16-core (32 rdzenie) oznacza to roczny koszt subskrypcji vSphere Standard rzędu 11 000-14 000 USD plus vCenter (~6 000 USD/rok) i Veeam Backup (~2 000 USD/socket/rok). Dla porównania Proxmox VE Standard z PBS dla tego samego sprzętu mieści się w okolicach 750-900 EUR/rok.

To ekonomiczne nożyce wywołały falę migracji w 2024-2026, szczególnie w segmencie MŚP i sektorze publicznym (ograniczenia budżetowe). Niniejszy playbook to skondensowane doświadczenia z wdrożeń realizowanych w Polsce w tym okresie.

9-fazowy proces migracji

Faza 1: Audyt środowiska VMware

Przed migracją trzeba dokładnie wiedzieć co masz. Audyt to nie luksus — to fundament planu.

Inwentaryzacja VM

Z vCenter API lub PowerCLI wyciągnij listę wszystkich VM z parametrami:

# PowerCLI — wszystkie VM z metadata
Connect-VIServer -Server vcenter.firma.pl
Get-VM | Select Name, NumCpu, MemoryGB, ProvisionedSpaceGB, UsedSpaceGB,
  PowerState, GuestId, Notes | Export-CSV vm-inventory.csv

# Lista snapshotów (snapshoty komplikują migrację)
Get-VM | Get-Snapshot | Select VM, Name, Created, SizeGB | Export-CSV snapshots.csv

Mapa zależności

Najważniejszy dokument migracji: która VM zależy od której. Standardowa struktura:

• Warstwa danych: bazy SQL/PostgreSQL/MariaDB (najtwardsze do migracji, krytyczne)
• Warstwa aplikacyjna: serwery WWW/aplikacje (zależne od baz)
• Warstwa frontowa: load balancery, reverse proxy
• Warstwa wspierająca: DNS, AD/Samba, NTP, monitoring (uważaj — często single point of failure)
• Storage: NFS/SMB shares (niekoniecznie wszystkie do migracji)

Dla każdej VM dokumentuj: do których innych VM kieruje ruch (sieć), z których VM odbiera (bazy do app), które usługi muszą być dostępne synchronicznie.

Analiza ryzyka per VM

Nadaj każdej VM klasyfikację:

• P1 (krytyczne): bazy produkcyjne, ERP, e-commerce, AD — migracja w cutover z planem rollback
• P2 (ważne): serwery aplikacyjne, file servery, intranet — migracja w fali z buforem 24h na test
• P3 (standardowe): dev, test, narzędziowe — migracja jako pierwsze, tolerancja błędów

Faza 2: Plan migracji

Kolejność fal — odwrotna do priorytetu

Pierwsza fala = P3 (najmniej krytyczne). Powód: testujesz procedurę na czymś co może chwilowo nie działać. Dopiero po 2-3 udanych falach P3 i P2 ruszasz P1.

Plan rollback (krytyczny)

Zasada: przez 14-30 dni po migracji każdej VM, oryginał na VMware pozostaje uruchomiony lub w stanie suspended/snapshot. W razie problemu na Proxmox:

1. Wyłącz VM na Proxmox
2. Wystartuj VM na VMware z ostatniego snapshot
3. Przekieruj DNS/load balancer z powrotem na VMware
4. Diagnoza problemu, fix, ponowna migracja po tygodniu

Faza 3: Lab test

Wybierz 1-2 niekrytyczne VM z różnymi systemami (np. jedna Windows, jedna Linux). Wykonaj pełny cykl migracji jak w produkcji, ale na lab. Mierz:

• Czas migracji — od pierwszej akcji do "VM działa stabilnie na Proxmox" (do estymacji okien serwisowych)
• Problemy techniczne — co się nie udało za pierwszym razem (drivery, sieć, storage)
• Performance po migracji — czy VM działa porównywalnie szybko jak na VMware
• Procedurę rollback — czy faktycznie potrafimy wrócić w razie awarii

Lab test powinien dać Ci pewność że wiesz co robisz. Jeśli w lab pojawiają się niespodzianki, w produkcji będą gorsze — wróć do audytu.

Faza 4: Budowa klastra Proxmox

Równolegle z VMware budujesz nowe środowisko Proxmox VE. Wymagania minimum:

• Minimum 3 węzły dla kworum klastra (lub 2 + QDevice)
• Sieć z dedykowanym VLAN dla corosync (latency < 5 ms)
• Shared storage dla HA: Ceph hyperconverged, NFS, lub iSCSI
• Proxmox Backup Server dla strategii backupu (oddzielny serwer/VM)
• Monitoring (Zabbix template dla Proxmox)

Szczegóły konfiguracji klastra opisaliśmy w osobnym artykule: Klaster Proxmox — konfiguracja krok po kroku. Strategia backupu: Proxmox Backup Server przewodnik.

Narzędzia migracji

PVE Import Wizard (od Proxmox VE 8.2+)

Najwygodniejsza droga. Datacenter → Storage → Add → ESXi. Podajesz IP hosta ESXi, użytkownika, hasło. Proxmox listuje VM z ESXi i pozwala importować bezpośrednio (online lub offline).

# CLI: import VM z ESXi
qm importovf 200 https://esxi.firma.pl/folder/vm-name/vm-name.ovf \
  --storage local-zfs \
  --format qcow2

# Lub przez API ESXi (PVE 8.2+)
qm import-from-esxi 200 \
  --esxi-server esxi.firma.pl \
  --esxi-user root \
  --vm vm-name \
  --target-storage local-zfs

OVF export + import (klasyczny)

Działa zawsze, niezależnie od wersji ESXi. Z VMware:

# Z hosta z zainstalowanym ovftool (VMware utility)
ovftool 'vi://root@esxi.firma.pl/path/to/vm' /tmp/vm.ovf

# Transfer pliku na Proxmox
scp /tmp/vm-1.ovf root@pve:/var/lib/vz/template/iso/

# Import na Proxmox
qm importovf 100 /var/lib/vz/template/iso/vm-1.ovf local-zfs

virt-v2v (fallback dla skomplikowanych przypadków)

Linux libguestfs tool. Konwertuje ze formatu VMware (vmdk) bezpośrednio na qcow2 + KVM, automatycznie podmieniając niektóre drivery.

# Z hosta Linuxa z dostępem do datastore VMware (NFS/CIFS)
virt-v2v -i vmx /datastore/vm-name/vm-name.vmx \
  -o local -of qcow2 \
  -os /var/lib/vz/images/200/

# Lub bezpośrednio do PVE storage
virt-v2v -i vmx vm.vmx -o pve -os local-zfs

qemu-img convert (najtwardszy fallback)

Bezpośrednia konwersja formatu dysku, gdy inne metody zawiodą:

# VMDK → qcow2
qemu-img convert -f vmdk -O qcow2 disk-flat.vmdk disk.qcow2

# Załącz dysk do VM Proxmox
qm importdisk 200 disk.qcow2 local-zfs --format qcow2

Specyfika Windows

Najczęstszy problem migracji: VM Windows boot na Proxmox kończy się BSOD INACCESSIBLE_BOOT_DEVICE. Powód: VMware używa drivera paravirtual (vmware tools), Proxmox używa virtio. Windows nie ma virtio drivera w boot loaderze.

Procedura PRE-migracji dla Windows (krytyczna)

1. Uruchom VM na VMware (jeszcze przed migracją)

   Pobierz VirtIO Drivers ISO (oficjalne z fedoraproject.org/wiki/Windows_Virtio_Drivers).

2. Zamontuj ISO i zainstaluj drivery

   Otwórz ISO → uruchom virtio-win-guest-tools.exe. Zainstaluje to: virtio-net (sieć), virtio-blk i virtio-scsi (dyski), virtio-serial, balloon driver.

3. Odinstaluj VMware Tools

   Panel sterowania → Programy → odinstaluj VMware Tools. Restart Windows. (Bez tego po migracji w Device Manager pojawiają się "?" przy nieznajdujących sprzęcie.)

4. Wyłącz VM, eksportuj OVF z VMware

   Po tym kroku Windows ma już virtio drivery i wie jak bootować na Proxmox.

5. Zaimportuj na Proxmox

   Standardowa procedura. Jeśli VM dalej nie bootuje, dodaj dysk wirtualny IDE z VirtIO ISO + boot do recovery, popraw konfigurację.

Specyfika Linux

Linux jest zazwyczaj prostszy. Większość kerneli ma virtio drivery wbudowane od dawna. Standardowe kroki:

1. Sprawdź czy initramfs zawiera virtio:

   # Na działającej VM przed migracją
   lsinitramfs /boot/initrd.img-$(uname -r) | grep virtio
   # Jeśli puste — dodaj:
   echo "virtio_blk virtio_net virtio_scsi virtio_pci" >> /etc/initramfs-tools/modules
   update-initramfs -u -k all

2. Sprawdź /etc/fstab: użyj UUID lub LABEL zamiast /dev/sdX (urządzenia mogą się zmienić nazwą po migracji)

   # Konwersja /dev/sdaX na UUID
   blkid /dev/sda1
   # UUID="xxx-xxx-xxx-xxx" — użyj w /etc/fstab

3. Odinstaluj open-vm-tools (jeśli było zainstalowane):

   apt remove open-vm-tools open-vm-tools-desktop
   apt autoremove

4. Po migracji zainstaluj qemu-guest-agent:

   apt install qemu-guest-agent
   systemctl enable qemu-guest-agent
   systemctl start qemu-guest-agent

   I włącz w Proxmox: VM → Options → QEMU Guest Agent → Enabled.

Cutover i rollback

Procedura cutover dla VM krytycznej

1. T-7 dni: powiadomienie biznesu

   Komunikat: "W weekend X migracja systemu Y. Niedostępność szacowana 4h. Plan B: rollback w 30 min."

2. T-1 dzień: migracja preliminary

   Migrujesz VM na Proxmox (offline copy z aktualnego stanu). Bootujesz, testujesz dostęp do bazy/aplikacji bez ruchu produkcyjnego (osobny VLAN testowy).

3. T-0 godzina X: cutover (typowo sobota 22:00)

   (a) Zatrzymaj usługi na VMware (graceful shutdown)
   (b) Ostatnia synchronizacja delta (rsync, mysqldump, lub snapshot)
   (c) Importuj delta na Proxmox
   (d) Wystartuj VM na Proxmox
   (e) Test funkcjonalny (smoke test)
   (f) Przekieruj DNS/load balancer na nowe IP

4. T+0 do T+24h: monitoring intensywny

   Dyżur tech 24/7. Monitorowanie: aplikacja, baza, sieć, performance. W razie problemu — decyzja rollback w max 60 minut od wykrycia.

5. T+30 dni: decommission VMware

   Po 30 dniach stabilnej pracy — wyłącz VMware, zwolnij sprzęt, dodaj jako kolejny węzeł Proxmox.

TCO 3-letnie — model porównawczy

Hipotetyczny scenariusz: 5 serwerów (każdy 2× 16-core, 256 GB RAM), 30 maszyn wirtualnych, 50 TB storage, środowisko produkcyjne MŚP.

Oszczędność 3-letnia: ~250 000 zł (70-75% redukcja kosztów licencyjnych). Break-even (zwrot inwestycji w migrację): typowo 4-8 miesięcy po cutover.

Top 10 ryzyk migracji

1. Brak Virtio Drivers w Windows pre-migracji — BSOD przy boot. Fix: opisany w sekcji Windows.
2. Snapshoty pozostawione na VMware przed eksportem — niepełne dane w eksporcie. Fix: Get-VM | Get-Snapshot | Remove-Snapshot przed migracją.
3. Zaszyfrowane vmdk (vTPM) — nie eksportują się standardowo. Fix: tymczasowo wyłącz szyfrowanie VM, eksportuj, włącz na Proxmox z innym mechanizmem.
4. RDM (Raw Device Mappings) — bezpośrednie LUN-y nie migrują jako pliki. Fix: skopiuj dane na nowy storage Proxmox, zmień konfigurację aplikacji.
5. VLAN/Network różnice — VM nie widzi sieci po migracji. Fix: dokładna mapa VLAN przed, replikacja konfiguracji vmbr na Proxmox.
6. Licencje aplikacji powiązane z UUID/MAC VM — aplikacja "wykryje nową maszynę". Fix: przed migracją zachowaj UUID i MAC, ustaw te same na Proxmox.
7. Zależności synchroniczne (np. AD przed file server) — kolejność cutover. Fix: AD migrujesz pierwszy/ostatni z całym buforem.
8. Brak monitoringu w okresie rollback — problemy widoczne dopiero po awarii. Fix: Zabbix templates dla Proxmox PRZED migracją krytycznych VM.
9. Zerwanie subskrypcji VMware przed terminem — kary umowne. Fix: dokończ subskrypcję, dopiero potem decommission.
10. Niedostateczne szkolenie zespołu IT — Proxmox jest podobny ale nie identyczny z VMware. Fix: minimum 1-dniowe szkolenie operacyjne dla zespołu utrzymaniowego przed cutover P1.

Cennik wdrożenia migracji

Pełna usługa migracji VMware → Proxmox VE realizowana przez Sztorm IT obejmuje wszystkie 9 faz playbooka. Wycena zawsze indywidualna po audycie środowiska — poniżej szacunkowe widełki dla typowych skali:

Ceny obejmują: audyt środowiska, plan migracji, lab test, budowę klastra Proxmox, migrację VM (wszystkie fale), walidację, dokumentację techniczną, szkolenie zespołu (1 dzień), 30 dni wsparcia powdrożeniowego.

Wymagania po stronie klienta: sprzęt pod Proxmox VE (możemy dostarczyć w wycenie indywidualnej), dostęp administracyjny do vCenter/ESXi, okno serwisowe dla cutover, decydent biznesowy do akceptacji harmonogramu.

Często zadawane pytania (FAQ)

Powiązane materiały

• Klaster Proxmox — konfiguracja krok po kroku
• Proxmox Backup Server — kompletny przewodnik
• Proxmox VE vs VMware — porównanie 2026
• Cennik subskrypcji Proxmox (PVE/PBS/PMG)
• Audyt środowiska Proxmox — cennik