Migracja VMware do Proxmox: usługa i poradnik techniczny (2026)

⚡

Usługa: audyt VMware → architektura PVE → PoV → fale migracji → szkolenie i wsparcie. Szczegóły: wdrożenie Proxmox dla firm. Poradnik poniżej zostaje dla adminów — także gdy migrację prowadzi partner. Typowa ścieżka to migracja vmware esxi do proxmox ve; migracja vmware w firmie to więcej niż konwersja dysków.

// Spis treści

Wymagania wstępne i przygotowanie PVE
Inwentaryzacja i audyt środowiska VMware
Porównanie metod migracji
Macierz: Wizard vs virt-v2v vs OVF
ESXi Import Wizard — krok po kroku
Workflow virt-v2v (konwerter dysków)
Mapowanie sieci: VLAN i mosty Linux
Projekt storage: ZFS, iSCSI, Ceph
Strojenie gości: VirtIO w Windows i Linux
Przypadki brzegowe: snapshoty, vSAN, BSOD Windows
Migracja klastra HA na Proxmox
Walidacja i przełączenie z minimalnym przestojem
Plan cofnięcia i wygaszenie VMware
Lista kontrolna przed przełączeniem (do wydruku)
Pytania i odpowiedzi

01 Wymagania

Wymagania wstępne i przygotowanie PVE

Każda migracja vmware proxmox wymaga stabilnego środowiska docelowego zanim skopiujesz pierwszą maszynę wirtualną. Proxmox VE 8.2 lub nowszy (z pakietem pve-esxi-import-tools) udostępnia natywny Import Wizard dla ESXi 6.5–8.0. Starsze wersje PVE nadal pozwalają na migrację przez virt-v2v lub ręczny import VMDK/OVF.

Przed startem upewnij się, że masz kompletny backup VMware (Veeam, NetBackup lub snapshot na poziomie storage) oraz działający Proxmox Backup Server lub równoważny mechanizm kopii zapasowych na docelowym klastrze. VMware pozostaje źródłem prawdy do momentu formalnego przełączenia — nie wyłączaj hostów ESXi przed walidacją. Przed importem usuń wszystkie snapshoty VM, bo spowalniają import. Punktem cofnięcia jest oryginalna, wyłączona VM na ESXi i backup — snapshot do tego nie jest potrzebny.

ℹ️

Minimalna topologia produkcyjna HA: 3 węzły Proxmox dla kworum Corosync (pmxcfs). Dwa węzły nie zapewniają bezpiecznego quorum przy awarii jednego hosta.

Lista kontrolna infrastruktury

Proxmox VE 8.2+ z aktualnymi aktualizacjami i zainstalowanym pve-esxi-import-tools
Sieć zarządzania: 1 GbE minimum, migracja dużych VM — dedykowany VLAN 10/25 GbE między ESXi a PVE
Konto administratora ESXi (np. root) — vCenter nie jest wymagany, a import bezpośrednio z hosta ESXi jest znacznie szybszy
Storage docelowy: local-zfs, NFS, iSCSI lub Ceph — z wolną przestrzenią ≥ 120% rozmiaru VM (snapshoty, logi, bufor)
Skonfigurowany Proxmox Backup Server lub harmonogram vzdump przed migracją produkcyjną
Dokumentacja mapowania VLAN: portgrupy VMware → mosty vmbr w Proxmox
Okno serwisowe na finalny import (VM musi być wyłączona na ESXi przy standardowym imporcie)

przygotowanie-pve.sh
# Weryfikacja wersji i pakietu importu ESXi
root@pve1# pveversion -v | grep -E 'pve-manager|pve-esxi'
root@pve1# apt install pve-esxi-import-tools -y
 
# Test łączności z hostem ESXi (port 443)
root@pve1# openssl s_client -connect esxi01.firma.pl:443 -brief </dev/null
 
# Następny wolny VMID w klastrze
root@pve1# pvesh get /cluster/nextid
✓ PVE gotowy do importu · next VMID: 200

02 Audyt

Inwentaryzacja i audyt VMware

Bez pełnej inwentaryzacji nie wybierzesz właściwej metody migracji ani nie oszacujesz czasu przełączenia. Zbierz listę VM z zużyciem zasobów, zależnościami aplikacyjnymi, konfiguracją sieci i wyjątkami (RDM, vGPU, nieobsługiwany vSAN).

vmware-inventory.ps1
# Eksport inwentaryzacji przez PowerCLI
PS> Connect-VIServer -Server vcenter.firma.pl
PS> Get-VM | Select-Object Name,PowerState,NumCpu,MemoryGB,VMHost,@{N='ProvisionedGB';E={($_.ExtensionData.Summary.Storage.Uncommitted+$_.ExtensionData.Summary.Storage.Committed)/1GB}} | Export-Csv vm-inventory.csv -NoTypeInformation
 
# Snapshoty i wersja VMware Tools
PS> Get-VM | Get-Snapshot | Select VM,Name,SizeGB,Created | Export-Csv snapshots.csv -NoTypeInformation
PS> Get-VM | Select Name,@{N='Tools';E={$_.ExtensionData.Guest.ToolsVersionStatus}} | Export-Csv tools-status.csv -NoTypeInformation
 
# Portgrupy i VLAN ID
PS> Get-VirtualPortGroup | Select Name,VLanId,VirtualSwitch | Export-Csv portgroups.csv -NoTypeInformation
 
# Datastores i wykorzystanie
PS> Get-Datastore | Select Name,Type,CapacityGB,FreeSpaceGB | Export-Csv datastores.csv -NoTypeInformation
✓ Wyeksportowano 52 VM · 14.2 TB provisioned · 8 portgroups · 5 datastores

Co oznacza każdy rekord

VM ze snapshotami — usuń wszystkie przed importem (importer wystartuje i ze snapshotami, tylko wolniej)
Dyski RDM (fizyczne mapowanie) — Import Wizard ich nie obsługuje; wymagana migracja na VMDK lub passthrough PCIe/NVMe
vSAN — nie jest wspierany przez natywny importer; eksport OVF lub virt-v2v przez sieć
VM z zainstalowanymi VMware Tools — odinstaluj je na ESXi przed migracją (zwłaszcza w Windows); usunięcie po przeniesieniu na Proxmox bywa trudne
Zależności HA aplikacyjnej — oznacz pary klastrowe do migracji w trybie przełączenia z minimalnym przestojem (jedna instancja na raz)

03 Metody

Porównanie metod migracji

Proxmox nie oferuje natywnego odpowiednika vMotion z ESXi na KVM — przełączenie z minimalnym przestojem (near-live) to proces inżynieryjny (kopia w tle + krótkie wyłączenie źródła), a nie jednoklikowa migracja na żywo między hypervisorami. Poniższa tabela pomaga dobrać narzędzie do skali i typu VM.

Metoda	Opis	Przestój	Kiedy stosować
ESXi Import Wizard	Natywny importer PVE 8.2+ przez API ESXi; mapuje VMX → konfiguracja QEMU	VM wyłączona na ESXi (opcja live-import startuje VM na PVE wcześniej)	Standardowa migracja VM z ESXi 6.5–8.0
virt-v2v (libguestfs)	Konwersja VMDK → qcow2/raw + instalacja sterowników VirtIO w gościu	VM wyłączona podczas konwersji	Windows/Linux, duże dyski, automatyczne VirtIO
Import OVF/OVA	`qm importovf` lub kreator GUI dla wyeksportowanych szablonów	Zależy od rozmiaru OVA	VM bez bezpośredniego dostępu ESXi, szablony OVF
Import dysku (VMDK)	Kopiowanie plików VMDK na storage PVE + `qm disk import`	VM wyłączona	Pojedyncze dyski, pliki VMDK już skopiowane na PVE
Attach & Move	VM na PVE startuje bezpośrednio z pliku VMDK na współdzielonym NFS (widocznym dla ESXi i PVE), a dysk jest potem przenoszony na żywo na docelowy storage (`qm disk move`)	Tylko restart VM na PVE	Duże dyski, NFS współdzielony między ESXi a PVE
Przełączenie z minimalnym przestojem	Pełna kopia online + delta sync + krótkie wyłączenie źródła	Sekundy–minuty (nie natywny ESXi live migrate)	Produkcja HA, bazy danych, serwisy krytyczne

⚠️

Live-import w PVE uruchamia VM na Proxmox po skopiowaniu minimalnych danych bootowych — VM na ESXi nadal musi być wyłączona. To skraca przestój, ale nie jest równoważne z vMotion ani migracji na żywo bez wyłączenia źródła.

Macierz decyzyjna: Import Wizard vs virt-v2v vs OVF/OVA

Poniższa tabela to szybki wybór metody vmware to proxmox migration — możesz linkować bezpośrednio do tego fragmentu (#vtp-method-matrix) z runbooków wewnętrznych.

Kryterium	ESXi Import Wizard	virt-v2v	OVF / OVA
Wymagany dostęp do ESXi API	Tak (443/tcp)	Opcjonalnie (VDDK)	Nie — wystarczy plik eksportu
VM na vSAN	Nieobsługiwane	Tak, VDDK transportem NBD	Tak, po eksporcie OVF z vCenter
Snapshoty na VM	Spowalniają import — usunięcie ich przyspiesza	Najlepiej VM bez snapshotów	Eksport zwykle bez snapshotów
Automatyczne VirtIO (Windows)	Częściowo — często ręcznie po imporcie	Tak (virtio-win w locie)	Nie — ręczna instalacja sterowników
Mapowanie VMX → QEMU	Automatyczne	Ręczne `qm set`	Z metadanych OVF
GUI w Proxmox	Pełny kreator	CLI (conversion host)	`qm importovf` + GUI
Batch (dziesiątki VM)	API / skrypty `qm import`	Skalowalne w cron/Ansible	Jedna VM na eksport
Typowy przestój	Pełny import offline	Konwersja offline	Zależy od rozmiaru OVA
Kiedy wybrać	Standard ESXi 6.5–8.0, lokalny/SAN datastore	Windows, nietypowe dyski, masowa konwersja	vSAN, brak API, archiwalne VM

Lista kontrolna wyboru metody (30 sekund)

Datastore to vSAN? → virt-v2v -it vddk (NBD czyta vSAN) albo OVF. Import Wizard dopiero po wyniesieniu dysku poza vSAN. Szyfrowany VMDK? → najpierw odszyfruj w vCenter, potem OVF
Na VM są snapshoty? → usuń wszystkie przed importem. Wizard wystartuje i ze snapshotami, tylko wolniej
Windows Server bez VirtIO? → virt-v2v albo Wizard i przełączenie kontrolera przez tymczasowy dysk VirtIO SCSI (sekcja 08)
Pojedyncza VM, ESXi online, brak wyjątków? → Import Wizard
Brak dostępu do hosta, tylko pliki? → OVF lub lokalny virt-v2v -i disk

04 Import Wizard

ESXi Import Wizard — krok po kroku

Oficjalny Import Wizard (od PVE 8.2) dodaje źródło typu „ESXi” w Datacenter → Storage → Add. Importer korzysta z publicznego API ESXi — bez własnościowych hooków VMware. Dla automatyzacji użyj równoważnego polecenia qm import.

Dodaj źródło ESXi

W GUI: Datacenter → Storage → Add → ESXi. Podaj IP/FQDN hosta, konto administratora. Przy self-signed cert dodaj CA do trust store lub zaznacz „Skip Certificate Verification” (tylko lab).

Wybierz VM i storage docelowy

Przejdź do zawartości storage ESXi, zaznacz VM, kliknij Import. Mapuj interfejsy sieciowe na most vmbr. Wybierz storage (np. local-zfs, ceph-pool).

Wyłącz VM na ESXi i uruchom import

Standardowy import wymaga wyłączonej VM na źródle. Opcjonalnie włącz live-import, aby PVE uruchomił gościa po skopiowaniu danych bootowych.

qm-import-esxi.sh
# Po dodaniu storage ESXi o ID "esxistore" w /etc/pve/storage.cfg
root@pve1# VMID=$(pvesh get /cluster/nextid)
root@pve1# qm import $VMID esxistore:ha-datacenter/datastore1/prod-web/prod-web.vmx --storage local-zfs
 
# Mapowanie sieci po imporcie (net0 → vmbr0 VLAN 100, MAC ze źródłowej VM)
root@pve1# qm set $VMID --net0 virtio=AA:BB:CC:DD:EE:FF,bridge=vmbr0,tag=100
 
# Uruchomienie i weryfikacja
root@pve1# qm start $VMID
root@pve1# qm status $VMID
✓ Import zakończony · VMID 200 · status: running

W virtio= podaj adres MAC źródłowej VM (z pliku .vmx — ethernet0.address lub ethernet0.generatedAddress — albo z qm config $VMID zaraz po imporcie). Bez niego Proxmox wygeneruje losowy MAC, co psuje rezerwacje DHCP i licencje powiązane z adresem MAC.

💡

Import przez vCenter działa, ale jest znacznie wolniejszy niż bezpośrednio z hosta ESXi. W produkcji rekomendujemy dodanie każdego hosta ESXi jako osobnego źródła importu.

05 virt-v2v

Workflow virt-v2v

virt-v2v z projektu libguestfs to sprawdzony konwerter dysków VMware → KVM. Sterowniki VirtIO w Windows wstrzykuje tylko wtedy, gdy na hoście konwersji jest virtio-win (katalog albo ISO); w Linuxie przebudowuje initramfs. Idealny, gdy Import Wizard napotyka problemy z nietypową konfiguracją VMX lub gdy potrzebujesz offline konwersji na dedykowanym hoście konwersji.

Na hoście konwersji (Debian/Ubuntu/RHEL albo węzeł Proxmox z wolnym miejscem) zainstaluj osobny pakiet virt-v2v (apt install virt-v2v), a do odczytu dysków przez vCenter rozpakuj bibliotekę VMware VDDK do /opt/vmware-vix-disklib. Poniższy przykład konwertuje VM prod-db-01 do VMID 201 (VMID 200 zajęła już prod-web z Import Wizard).

virt-v2v-proxmox.sh
# Katalog -os musi już istnieć. Konwersja przez vCenter API (VM musi być wyłączona)
$ mkdir -p /var/lib/vz/images/201
$ virt-v2v -ic vpx://vcenter.firma.pl/Datacenter/cluster/esxi01 \
    -it vddk \
    -io vddk-libdir=/opt/vmware-vix-disklib \
    -io vddk-thumbprint=xx:xx:xx:… \
    -o local -os /var/lib/vz/images/201 \
    -of qcow2 \
    "prod-db-01"
 
# Utworzenie VM i podpięcie dysku w Proxmox
root@pve1# qm create 201 --name prod-db-01 --memory 16384 --cores 8 --net0 virtio=00:50:56:12:34:56,bridge=vmbr0
root@pve1# qm disk import 201 /var/lib/vz/images/201/prod-db-01-sda local-zfs
root@pve1# qm set 201 --virtio0 local-zfs:vm-201-disk-0 --boot order=virtio0 --agent enabled=1
✓ Konwersja: 240 GB VMDK → plik qcow2 · na local-zfs dysk ląduje jako zvol (raw) · VirtIO w gościu

ℹ️

Parametr -io vddk-thumbprint jest wymagany w virt-v2v starszym niż 2.10 — Proxmox VE 9 (Debian 13) dostarcza virt-v2v 2.6. Odcisk SHA-1 certyfikatu serwera z adresu -ic (tu vCenter) odczytasz poleceniem openssl s_client -connect vcenter.firma.pl:443 </dev/null | openssl x509 -noout -fingerprint -sha1. OpenSSL dopisuje na początku linii prefiks sha1 Fingerprint=, a -io vddk-thumbprint przyjmuje wyłącznie pary szesnastkowe — obetnij prefiks, na przykład sed 's/.*Fingerprint=//', i wklej sam wynik. Sterowniki VirtIO dla Windows virt-v2v bierze z /usr/share/virtio-win (albo ze ścieżki w zmiennej VIRTIO_WIN, która może wskazywać plik virtio-win.iso) — Debian nie ma pakietu virtio-win, więc przed konwersją Windows pobierz ISO na host konwersji. W qm create podaj adres MAC źródłowej VM (z pliku .vmx), żeby nie stracić rezerwacji DHCP ani licencji powiązanych z MAC.

Alternatywa: konwersja lokalnego VMDK

Jeśli masz już skopiowane pliki VMDK na hoście PVE:

virt-v2v-local.sh
# Katalog -os musi już istnieć. Plik wynikowy to nazwa VMDK bez rozszerzenia plus -sda.
$ mkdir -p /var/lib/vz/images/202
$ virt-v2v -i disk /mnt/import/vm-disk.vmdk -o local -os /var/lib/vz/images/202 -of qcow2
# qm disk import wymaga istniejącej konfiguracji VM
root@pve1# qm create 202 --name vm-disk --memory 2048 --cores 2
root@pve1# qm disk import 202 /var/lib/vz/images/202/vm-disk-sda local-zfs
root@pve1# qm set 202 --virtio0 local-zfs:vm-202-disk-0 --boot order=virtio0

06 Sieć

Mapowanie sieci: VLAN i mosty

Portgrupy VMware z VLAN ID mapujemy na mosty Linux z tagiem 802.1Q. W Proxmox standardem jest vmbr0 jako trunk z wieloma VLAN-ami gości lub dedykowane mosty per segment.

VMware	Proxmox VE	Przykład
vSS / vDS portgroup VLAN 100	bridge=vmbr0,tag=100	Produkcja aplikacji
Portgroup bez VLAN (native)	bridge=vmbr0 (bez tag)	Management
vDS LACP uplink	OVS bridge lub linux bond + vmbr	Agregacja 2×25GbE
NSX overlay	SDN EVPN/VXLAN (osobny projekt)	Mikrosegmentacja

/etc/network/interfaces (fragment)
auto vmbr0
iface vmbr0 inet static
  address 10.0.10.11/24
  gateway 10.0.10.1
  bridge-ports bond0
  bridge-stp off
  bridge-vlan-aware yes
  bridge-vids 2-4094
 
# Bez bridge-vids ifupdown2 nie dopisze VLAN-ów gościa: zostaje PVID 1 i tag 100/200 odpada
# VM w VLAN 200: qm set <vmid> --net0 virtio=<MAC-źródłowej-VM>,bridge=vmbr0,tag=200

ℹ️

Po migracji zweryfikuj MAC adresy i reguły firewall (iptables/nftables, Proxmox firewall). Zmiana kolejności interfejsów eth0/eth1 w gościu może wymagać korekty netplan lub /etc/udev/rules.d/70-persistent-net.rules.

07 Storage

Projekt storage: ZFS, iSCSI, Ceph

Wybór storage determinuje możliwość live migration między węzłami PVE, wydajność I/O i koszt. Trzy najczęstsze modele w migracjach z VMware:

Local-ZFS

Prosty start: każdy węzeł ma własny pool ZFS. Brak współdzielonego storage — live migration lokalnych dysków w tym samym klastrze to qm migrate --online --with-local-disks. qm remote-migrate kopiuje dyski między klastrami i nie wymaga współdzielonego storage. Dobre dla mniejszych klastrów i środowisk dev/test.

iSCSI / NFS (SAN)

Współdzielony LUN lub export NFS montowany na wszystkich węzłach. Umożliwia natywną migrację na żywo między hostami PVE (qm migrate). Integracja z istniejącym SAN po migracji z VMFS.

Ceph RBD

Rozproszony storage wbudowany w Proxmox — replikacja 3x, self-healing, skalowanie poziome. Wymaga dedykowanej sieci storage (minimum 10 GbE, rekomendowane 25 GbE). Zamiennik vSAN bez licencji Broadcom.

storage-przyklad.sh
# Współdzielony LVM na LUN iSCSI. LVM-thin nie jest współdzielony między węzłami.
# Najpierw storage iSCSI — dopiero wtedy LUN jest widoczny. pvcreate przed logowaniem nie ma na czym działać.
root@pve1# pvesm add iscsi iscsi-san --portal 10.0.20.50 --target iqn.2024-01.com.firma:prod --content none
# Na jednym węźle, na ścieżce LUN-u (ls /dev/disk/by-path). pvesm add lvm tylko rejestruje gotową grupę.
root@pve1# pvcreate /dev/disk/by-path/ip-10.0.20.50:3260-iscsi-iqn.2024-01.com.firma:prod-lun-0
root@pve1# vgcreate pve-iscsi /dev/disk/by-path/ip-10.0.20.50:3260-iscsi-iqn.2024-01.com.firma:prod-lun-0
root@pve1# pvesm add lvm iscsi-lvm --vgname pve-iscsi --content images,rootdir --shared 1
 
# Status pool ZFS lokalnego
root@pve1# zpool list && zfs list

08 VirtIO

Strojenie gości: VirtIO w Windows i Linux

Po migracji zamień emulowane urządzenia VMware (vmxnet3, LSI Logic) na VirtIO dla lepszej wydajności i mniejszego CPU overhead. Import Wizard częściowo mapuje interfejsy. virt-v2v instaluje sterowniki Windows tylko wtedy, gdy na hoście konwersji jest virtio-win.

Windows Server

Przed migracją, jeszcze na ESXi: odinstaluj VMware Tools w Panelu sterowania (Programy i funkcje) tuż przed wyłączeniem VM — usunięcie ich po przeniesieniu na Proxmox bywa trudne
Zamontuj ISO virtio-win.iso — nie ma go w repozytoriach Proxmox; pobierz je z projektu Fedora: fedorapeople.org/groups/virt/virtio-win/direct-downloads/
Zainstaluj sterowniki z pakietu virtio-win-guest-tools: VirtIO SCSI, VirtIO Net, QEMU Guest Agent
Włącz QEMU Guest Agent w konfiguracji VM: --agent enabled=1
Kontroler dysku systemowego zmień na VirtIO SCSI dopiero wtedy, gdy Windows załadował sterownik vioscsi (procedura z dyskiem tymczasowym poniżej)
Zweryfikuj aktywację Windows — zmiana motherboard UUID może wymagać reaktywacji KMS

Windows Server — unikanie BSOD (0x7B INACCESSIBLE_BOOT_DEVICE)

Najczęstszy błąd po migracji na Windows: niebieski ekran 0x0000007B zaraz po przełączeniu kontrolera dysku na VirtIO SCSI. Import Wizard ma dla gościa Windows opcję „Prepare for VirtIO-SCSI” (domyślnie zaznaczoną przy rozruchu UEFI): przepina dyski SCSI na SATA i ustawia kontroler VirtIO SCSI. Bez niej dyski zostają na kontrolerze SCSI odwzorowanym z pliku VMX (LSI albo PVSCSI). Dysk na SATA uruchomi się od razu, ale sama instalacja virtio-win nie wystarcza: dopóki Windows nie wykryje urządzenia na kontrolerze VirtIO SCSI, nie ładuje sterownika vioscsi przy rozruchu i nie znajdzie woluminu rozruchowego.

Metoda A (przygotowanie na ESXi): na działającej VM zamontuj virtio-win.iso i zainstaluj virtio-win-guest-tools. Sterownik VirtIO SCSI musi być zainstalowany i ustawiony na start podczas rozruchu systemu — sam instalator tego nie gwarantuje, więc po imporcie i tak najbezpieczniej wykonać krok z dyskiem tymczasowym (Metoda B)
Metoda B (zalecana): po imporcie dysk systemowy powinien być na SATA lub IDE — tylko te magistrale Windows obsługuje bez dodatkowych sterowników, więc jeśli kreator zostawił go na SCSI, przepnij go przed pierwszym uruchomieniem; uruchom VM; zainstaluj virtio-win-guest-tools z ISO; dodaj mały tymczasowy dysk na kontrolerze VirtIO SCSI i uruchom VM, aby Windows załadował vioscsi; wyłącz VM, usuń dysk tymczasowy, przepnij dysk systemowy jako scsi0 na VirtIO SCSI, ustaw kolejność rozruchu i uruchom VM
Metoda C: virt-v2v wstrzykuje sterowniki podczas konwersji, gdy na hoście jest virtio-win (na PVE 9 ISO trzeba podłożyć — sekcja 05) — najmniej ryzyka BSOD przy pierwszym rozruchu na PVE
VMware Tools odinstaluj przed migracją, jeszcze na ESXi — pozostawione usługi VMware mogą kolidować z QEMU Guest Agent, a ich usunięcie po migracji bywa trudne
Sprawdź tryb UEFI vs BIOS — Import Wizard zachowuje firmware; przy OVF zweryfikuj qm set <vmid> --bios ovmf vs seabios

windows-migracja.ps1
# W gościu Windows, VM nadal na ESXi. Kod produktu bierz z rejestru — zapytanie Win32_Product przebudowuje wszystkie instalacje MSI.
PS> $u = Get-ItemProperty HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\*, HKLM:\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\* | Where-Object DisplayName -eq 'VMware Tools'
PS> msiexec.exe /x $u.PSChildName /qn /norestart
 
# Na Proxmox, po pierwszym uruchomieniu: weryfikacja QEMU Guest Agent
PS> Get-Service QEMU-GA | Select Status, StartType
✓ VMware Tools odinstalowane przed migracją · Guest Agent: Running

Linux

Większość nowoczesnych kerneli ma wbudowane moduły virtio_blk/virtio_scsi
Po virt-v2v: update-initramfs -u (Debian/Ubuntu) lub dracut --force (RHEL)
Zainstaluj qemu-guest-agent i uruchom usługę
Sprawdź lsblk i fstab — nazwy urządzeń mogą się zmienić z /dev/sda na /dev/vda

Przykład dla VM 201 (prod-db-01 z sekcji virt-v2v): przepięcie dysku z virtio0 na scsi0 i sieć w VLAN 100 z zachowanym adresem MAC. W Windows najpierw wykonaj krok z tymczasowym dyskiem VirtIO SCSI opisany wyżej.

qm-virtio-tuning.sh
root@pve1# qm set 201 --delete virtio0
root@pve1# qm set 201 --scsihw virtio-scsi-pci --scsi0 local-zfs:vm-201-disk-0 --boot order=scsi0
root@pve1# qm set 201 --net0 virtio=00:50:56:12:34:56,bridge=vmbr0,tag=100
root@pve1# qm set 201 --agent enabled=1
root@pve1# qm set 201 --serial0 socket

09 Przypadki brzegowe

Przypadki brzegowe: snapshoty, vSAN, BSOD Windows

Większość nieudanych importów to nie błąd Proxmox, lecz stan źródła VMware. Poniżej procedury dla siedmiu najczęstszych problemów przy migracji vmware proxmox.

1. Snapshoty spowalniają Import Wizard

Import maszyny ze snapshotami jest możliwy, ale wyraźnie wolniejszy. Najlepiej, żeby VM nie miała żadnych snapshotów: usuń je przed importem. To skraca czas, choć nie jest warunkiem startu importera.

remove-snapshots.ps1
PS> Get-VM prod-app-01 | Get-Snapshot | Select Name,SizeGB,Created
PS> Get-VM prod-app-01 | Get-Snapshot | Remove-Snapshot -Confirm:$false
PS> Get-VM prod-app-01 | Get-View | ForEach-Object { $_.ConsolidateVMDisks_Task() }
✓ Wszystkie snapshoty usunięte · dysk skonsolidowany · import będzie szybszy

2. VM na vSAN — Import Wizard nie zadziała

Natywny importer czyta datastore przez ESXi API — obiekty vSAN nie są eksportowalne tą ścieżką. Procedura obejścia:

Storage vMotion VM na datastore NFS/VMFS (poza vSAN) — potem Import Wizard
Eksport OVF/OVA z vCenter → qm importovf na Proxmox
virt-v2v przez VDDK z vCenter (VM wyłączona; transport NBD czyta vSAN i nie wymaga wyniesienia dysku)
Dla dużych VM: klon na staging LUN, import z stagingu, usuń klon po walidacji

3. RDM i dyski niezależne (p-mode)

Raw Device Mapping w trybie fizycznym nie ma pliku VMDK z danymi do skopiowania, a Storage vMotion takiego dysku przenosi wyłącznie plik mapowania — dane zostają na LUN-ie. Aby uzyskać VMDK, wykonaj migrację na zimno (VM wyłączona) na inny datastore z docelowym formatem dysku Thin Provision lub Thick Provision albo odłącz RDM, dodaj ten sam LUN ponownie jako RDM w trybie wirtualnym i wykonaj Storage vMotion ze zmianą formatu dysku. Alternatywnie zaplanuj w Proxmox bezpośrednie podłączenie LUN-u do VM lub PCIe passthrough dla wyjątków (np. licencjonowany HBA).

4. Zaszyfrowane VM i vTPM

Zaszyfrowanych dysków VM (np. przez politykę storage VM Encryption) nie da się zaimportować — najpierw usuń szyfrowanie, przypisując w vCenter politykę storage bez szyfrowania. Stanu vTPM nie da się przenieść z VMware do Proxmox — dodaj nowy moduł TPM w konfiguracji QEMU, a jeśli klucze szyfrowania całego dysku (np. BitLocker) są w vTPM, przed migracją wyłącz szyfrowanie albo zabezpiecz klucz odzyskiwania.

5. VLAN — VM bootuje, ale brak sieci

Po migracji najczęstszy problem sieciowy to błędny tag VLAN albo most bez bridge-vlan-aware yes i bridge-vids.

Objaw	Przyczyna	Naprawa
Brak IP po bootcie	Zły tag w `qm set --net0`	Porównaj VLAN ID portgrupy VMware z `tag=` w PVE
eth0 → eth1 w Linuxie	Zmiana kolejności NIC	netplan / `70-persistent-net.rules`
Windows „nieznana sieć”	Nowy MAC → nowy profil	Przypisz statyczne IP lub reset profilu sieci
Ruch nie przechodzi mimo IP	Firewall PVE / brak trunku	`bridge-vlan-aware yes` i `bridge-vids 2-4094` + sprawdź switch port mode

6. Windows BSOD 0x7B po pierwszym restarcie

Patrz sekcja VirtIO powyżej. Skrót: nie przełączaj dysku systemowego na VirtIO SCSI zaraz po instalacji sterowników. virt-v2v wstrzykuje sterowniki tylko wtedy, gdy na hoście jest virtio-win. Przy Wizard dysk ląduje na SATA wyłącznie z włączoną opcją „Prepare for VirtIO-SCSI” (domyślnie przy UEFI); bez niej zostaje na SCSI z pliku VMX i przed pierwszym startem trzeba go przepiąć na SATA albo IDE. Potem zainstaluj virtio-win, dodaj tymczasowy dysk na VirtIO SCSI i uruchom VM, aby Windows załadował vioscsi — dopiero potem usuń dysk tymczasowy i przepnij dysk systemowy na scsi0.

7. Import Wizard zwraca „certificate verify failed”

ESXi używa self-signed cert. W labie: Skip verification. W produkcji: dodaj cert ESXi do trust store PVE lub użyj FQDN zgodnego z SAN w certyfikacie.

10 HA

Migracja klastra HA na Proxmox

VMware HA (vSphere DRS/HA) nie ma bezpośredniego odpowiednika podczas migracji ESXi → PVE. HA w Proxmox włączasz po przeniesieniu VM na współdzielony storage i skonfigurowaniu minimum 3 węzłów.

VMware	Proxmox VE	Uwagi migracyjne
vSphere HA	pve-ha-manager + quorum 3 węzły	Włącz HA dopiero po migracji VM na shared storage
DRS	Dynamic Load Balancer (PVE 9.2+)	Wymaga HA; reguły affinity są respektowane, ale nie są warunkiem
vMotion wewnątrz vSphere	`qm migrate` między węzłami PVE	Współdzielony storage albo `qm migrate --with-local-disks`
FT (Fault Tolerance)	Brak 1:1 — replikacja aplikacyjna	Zaplanuj active/passive lub K8s/DB cluster

Kolejność migracji klastra aplikacyjnego

Migruj passive / secondary node pierwszy — waliduj na izolowanym VLAN
Przełącz ruch (DNS/LB) na instancję na PVE
Migruj primary w oknie serwisowym (przełączenie z minimalnym przestojem)
Dodaj obie VM do grupy HA w Proxmox dopiero po testach failover
Ustaw reguły anti-affinity, aby repliki nie lądowały na tym samym węźle

ℹ️

HA nie przenosi dysku. VM wystartuje na innym węźle tylko wtedy, gdy dysk już tam jest: współdzielony storage (iSCSI, NFS, Ceph) albo replika ZFS.

11 Walidacja

Walidacja i przełączenie z minimalnym przestojem

Przełączenie z minimalnym przestojem to sekwencja faz minimalizująca przestój — nie jest to natywna migracja na żywo z ESXi. Stosuj ją dla systemów produkcyjnych, gdzie akceptowalne są sekundy–minuty niedostępności.

Kopia wstępna

Przygotowawczy zrzut (backup albo kopia dysku) może powstać, gdy VM jeszcze działa na ESXi. Sam Import Wizard — także z live-import — wymaga wyłączenia źródła. Live-import tylko wcześniej uruchamia gościa na PVE; to nie jest kopia online.

Testy na PVE (izolowana sieć)

Uruchom kopię na Proxmox w VLAN testowym. Sprawdź logowanie, usługi, integrację z bazą danych.

Finalne przełączenie

Wyłącz VM na ESXi, wykonaj ostatnią synchronizację delta, uruchom na PVE, przełącz DNS/load balancer. Typowy przestój: 30 s – 2 min.

Lista kontrolna walidacji przed produkcją

Boot VM bez błędów — konsola Proxmox i logi systemu gościa
Sieć: ping bramy, DNS, test portów aplikacji (curl, nc, telnet)
Dysk: wydajność I/O (fio lub CrystalDiskMark w Windows)
Backup PBS: pierwszy pełny backup po migracji z weryfikacją restore
Monitoring: agent Prometheus/node_exporter lub SNMP — alerty skonfigurowane
HA: VM dodana do grupy HA, test failover w oknie serwisowym
Dokumentacja: zaktualizowany CMDB, diagram sieci, procedura operacyjna

12 Plan cofnięcia

Plan cofnięcia i wygaszenie VMware

Do momentu formalnego decommission środowisko VMware pozostaje gotowe do powrotu. Cofnięcie to zwykle przełączenie DNS/VIP z powrotem na ESXi i uruchomienie oryginalnej VM — minuty, nie godziny.

Utrzymuj oryginalną, wyłączoną VM na ESXi do końca okresu obserwacji (30–90 dni)
Nie usuwaj datastores VMFS dopóki wszystkie VM nie są zweryfikowane na PVE
Po stabilnym okresie: wyrejestruj wyłączoną VM z ESXi i zwolnij datastore
Zamknij licencje Broadcom / anuluj subskrypcję vSphere po akceptacji zarządu
Zarchiwizuj eksporty PowerCLI i dokumentację konfiguracji VMware (compliance)

🎯

Plan cofnięcia zawsze na piśmie: dla każdej krytycznej VM zapisz RTO, osobę decyzyjną i kroki przełączenia (DNS, VIP, firewall). Przetestuj cofnięcie w środowisku staging przed przełączeniem produkcyjnym.

Procedura cofnięcia (szablon)

Krok	Akcja	Odpowiedzialny	Czas
1	Zatrzymaj VM na Proxmox (`qm stop`)	Admin PVE	30 s
2	Uruchom oryginalną, wyłączoną VM na ESXi	Admin VMware	1–2 min
3	Przełącz DNS / VIP / firewall na adresy VMware	Network team	1–5 min
4	Weryfikacja aplikacji (health check, logi)	App owner	5–15 min
5	Komunikat do użytkowników + post-mortem	IT manager	—

Lista kontrolna przed przełączeniem (do wydruku)

Skopiuj lub wydrukuj listę kontrolną przed finalnym przełączeniem produkcji. Anchor: #vtp-checklist.

Backup VMware + PBS snapshot VM na PVE po teście
Brak snapshotów na VM źródłowej; oryginalna VM zostaje wyłączona na ESXi
VirtIO / Guest Agent zainstalowane i przetestowane
Mapowanie VLAN i firewall zweryfikowane na VLAN testowym
DNS TTL obniżony (300 s) 24 h przed przełączeniem
Procedura cofnięcia podpisana przez właściciela aplikacji
Okno serwisowe i komunikat do użytkowników wysłany
Monitoring i alerty skonfigurowane na docelowej VM

Najczęstsze pytania

Nie — nie ma natywnego odpowiednika vMotion między ESXi a KVM. Import Wizard wymaga wyłączenia VM na ESXi przy standardowym imporcie. Opcja live-import skraca przestój przez wczesny start na PVE, ale źródło nadal musi być zatrzymane. Przełączenie z minimalnym przestojem (kopia + delta) to osobna procedura inżynieryjna.

Proxmox VE 8.2 lub nowszy z pakietem pve-esxi-import-tools. Testowano z ESXi 6.5–8.0. Starsze środowiska migrujemy przez virt-v2v lub import OVF/VMDK.

Oba narzędzia są uzupełniające. Import Wizard jest szybszy w integracji z GUI/API PVE i mapuje konfigurację VMX automatycznie. virt-v2v (libguestfs) lepiej radzi sobie z masową konwersją offline, nietypowymi dyskami i automatyczną instalacją VirtIO — szczególnie w Windows.

Minimum 3 węzły dla bezpiecznego kworum Corosync. Przy 2 węzłach awaria jednego hosta odbiera kworum. Konfiguracja klastra przechodzi w tryb tylko do odczytu: nie uruchomisz ani nie przeniesiesz maszyny, a HA nie przejmie usług — to chroni przed split-brainem. Działające maszyny pracują dalej, chyba że węzeł z zasobami HA sam się zrestartuje (fencing). Restart HA na innym węźle potrzebuje współdzielonego storage albo repliki. Migracja na żywo lokalnych dysków działa bez wspólnego storage: qm migrate --online --with-local-disks.

Import ze snapshotami jest możliwy, ale wyraźnie wolniejszy. Najlepiej usuń wszystkie snapshoty przed importem — importer nie wymaga tego, żeby wystartować. Do cofnięcia wystarczy oryginalna, wyłączona VM na ESXi. Patrz sekcja przypadki brzegowe — snapshoty.

Nie Wizardem, dopóki dysk jest na vSAN. Wyniesienie dysku odblokowuje kreator. OVF też działa. virt-v2v -it vddk czyta vSAN przez NBD i stagingu nie wymaga. Szczegóły w sekcji vSAN.

Uruchom VM z dyskiem na kontrolerze SATA/IDE (po Wizardzie jest tak tylko przy włączonej opcji „Prepare for VirtIO-SCSI”; inaczej przepnij dysk z SCSI przed startem) i zainstaluj virtio-win-guest-tools z virtio-win.iso. Dodaj mały tymczasowy dysk na kontrolerze VirtIO SCSI i uruchom VM, aby Windows załadował sterownik vioscsi. Następnie wyłącz VM, usuń dysk tymczasowy, przepnij dysk systemowy jako scsi0 na VirtIO SCSI, ustaw kolejność rozruchu (qm set <vmid> --boot order=scsi0) i uruchom VM. Alternatywnie virt-v2v wstrzykuje sterowniki w trakcie konwersji, gdy na hoście jest virtio-win. Patrz sekcja VirtIO / BSOD.

Rolę konwertera VMware do Proxmox pełnią dwa narzędzia: wbudowany Import Wizard w Proxmox VE oraz virt-v2v. Oba konwertują dyski VMDK do formatu QEMU (QCOW2/raw). Sterowniki VirtIO w trakcie konwersji wstrzykuje virt-v2v; Import Wizard zwykle wymaga ich dołożenia ręcznie po imporcie. Osobnego oprogramowania nie potrzebujesz.

Tak — migrację maszyn VMware do Proxmox realizujemy wsadowo (batch), grupując VM według zależności. Przy większej liczbie maszyn skryptujemy konwersję virt-v2v, dzięki czemu proces jest powtarzalny i audytowalny, a każda partia ma punkt cofnięcia.

Tak. Migracja VMware do Proxmox VE dla enterprise obejmuje klaster HA (min. 3 węzły), współdzielony storage (Ceph/iSCSI/NFS), mapowanie sieci VLAN oraz przełączenie z minimalnym przestojem. Obsługujemy środowiska od kilku do ponad 100 VM.

Potrzebujesz partnera do migracji — nie tylko listy kontrolnej?

Przeprowadzimy audyt VMware i wykonamy migrację vmware proxmox z planem cofnięcia i minimalnym przestojem — w ramach wdrożenia Proxmox dla firm. Poradnik powyżej zostaje Waszą mapą techniczną.

⚡ Bezpłatna analiza środowiska → Oferta wdrożenia