VMware do Proxmox: kompletny poradnik techniczny migracji (2026)

// 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
Edge case: snapshoty, vSAN, BSOD Windows
Migracja klastra HA na Proxmox
Walidacja i near-live cutover
Rollback i wygaszenie VMware
Checklist przed cutover (do wydruku)

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.1 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 cutover — nie usuwaj snapshotów ani nie wyłączaj hostów ESXi przed walidacją.

ℹ️

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.

Checklist infrastruktury

Proxmox VE 8.1+ 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 ESXi/vSphere z uprawnieniami do odczytu VM i datastore (nie wymaga vCenter, ale import bezpośrednio z ESXi jest 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 cutover. 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 — scal przed importem lub zaplanuj osobną konwersję virt-v2v
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 nieaktualnymi VMware Tools — zaktualizuj przed migracją Windows (ułatwia późniejszą instalację VirtIO)
Zależności HA aplikacyjnej — oznacz pary klastrowe do migracji w trybie near-live (jedna instancja na raz)

03 Metody

Porównanie metod migracji

Proxmox nie oferuje natywnego odpowiednika vMotion z ESXi na KVM — near-live cutover 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.1+ 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
Attach-and-move (VMDK)	Kopiowanie plików VMDK na storage PVE + `qm disk import`	VM wyłączona	Pojedyncze dyski, NFS współdzielony między ESXi a PVE
Near-live cutover	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	Tylko po migracji dysku poza vSAN	Tak, po eksporcie OVF z vCenter
Snapshoty na VM	Blokują import — scal wcześniej	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

Checklist wyboru metody (30 sekund)

Datastore to vSAN lub szyfrowany VMDK? → OVF/OVA lub virt-v2v po stagingu poza vSAN
Na VM są snapshoty? → usuń lub scal przed jakąkolwiek metodą
Windows Server bez VirtIO? → virt-v2v albo pre-instalacja virtio-win na ESXi, potem Wizard
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.1) 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)
root@pve1# qm set $VMID --net0 virtio,bridge=vmbr0,tag=100
 
# Uruchomienie i weryfikacja
root@pve1# qm start $VMID
root@pve1# qm status $VMID
✓ Import zakończony · VMID 200 · status: running

💡

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. Automatycznie instaluje sterowniki VirtIO w Windows (przez virtio-win) i modyfikuje initramfs w Linuxie. Idealny, gdy Import Wizard napotyka problemy z nietypową konfiguracją VMX lub gdy potrzebujesz offline konwersji na dedykowanym hoście konwersji.

virt-v2v-proxmox.sh
# Konwersja przez vCenter API (VM musi być wyłączona)
$ virt-v2v -ic vpx://vcenter.firma.pl/Datacenter/cluster/esxi01 \
    -it vddk \
    --vddk-libdir /usr/lib/vmware-vix-disklib \
    -o local -os /var/lib/vz/images/200 \
    -of qcow2 \
    "prod-db-01"
 
# Utworzenie VM i podpięcie dysku w Proxmox
root@pve1# qm create 200 --name prod-db-01 --memory 16384 --cores 8 --net0 virtio,bridge=vmbr0
root@pve1# qm importdisk 200 /var/lib/vz/images/200/prod-db-01-sda qcow2 local-zfs
root@pve1# qm set 200 --virtio0 local-zfs:vm-200-disk-0 --boot order=virtio0 --agent enabled=1
✓ Konwersja: 240 GB VMDK → 178 GB qcow2 · VirtIO zainstalowane w gościu

Alternatywa: konwersja lokalnego VMDK

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

virt-v2v-local.sh
$ virt-v2v -i local -i disk /mnt/import/vm-disk.vmdk -o local -os /var/lib/vz/images/201 -of qcow2
root@pve1# qm disk import 201 /var/lib/vz/images/201/vm-disk.qcow2 local-zfs --format qcow2

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
 
# VM z VLAN 200: qm set 200 --net0 virtio,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 wymaga kopii dysku przez sieć (qm remote-migrate tylko przy współdzielonym 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
# Dodanie iSCSI LUN jako storage RBD-compatible (LVM-thin na iSCSI)
root@pve1# pvesm add iscsi iscsi-san --portal 10.0.20.50 --target iqn.2024-01.com.firma:prod
root@pve1# pvesm add lvmthin iscsi-thin --thinpool data --vgname pve-iscsi --content images,rootdir
 
# 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 automatycznie.

Windows Server

Zamontuj ISO virtio-win.iso (dostępne w repozytorium Proxmox lub virtio-win.org)
Zainstaluj sterowniki: VirtIO SCSI, VirtIO Net, QEMU Guest Agent
Włącz QEMU Guest Agent w konfiguracji VM: --agent enabled=1
Sprawdź boot: zmień kontroler dysku na VirtIO SCSI przed restartem
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. Dysk bootuje na emulowanym SATA/IDE z Import Wizard, ale po zmianie na VirtIO brakuje sterownika w boot volume.

Metoda A (zalecana): na działającej VM w ESXi zamontuj virtio-win.iso, zainstaluj VirtIO SCSI + Net + Guest Agent, dopiero potem importuj i przełącz kontroler
Metoda B: po imporcie zostaw dysk na SATA/IDE, bootuj, zainstaluj VirtIO z ISO, zmień na VirtIO SCSI, restart
Metoda C: virt-v2v wstrzykuje sterowniki podczas konwersji — najmniej ryzyka BSOD przy pierwszym bootcie na PVE
Po migracji odinstaluj VMware Tools — pozostałe usługi VMware mogą konfliktować z QEMU Guest Agent
Sprawdź tryb UEFI vs BIOS — Import Wizard zachowuje firmware; przy OVF zweryfikuj qm set <vmid> --bios ovmf vs seabios

windows-post-migrate.ps1
# Usunięcie VMware Tools po udanym bootcie na Proxmox
PS> Get-WmiObject -Class Win32_Product | Where-Object { $_.Name -like '*VMware Tools*' } | ForEach-Object { $_.Uninstall() }
 
# Weryfikacja QEMU Guest Agent
PS> Get-Service QEMU-GA | Select Status, StartType
✓ Guest Agent: Running · VMware Tools removed

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

qm-virtio-tuning.sh
root@pve1# qm set 200 --scsihw virtio-scsi-pci --scsi0 local-zfs:vm-200-disk-0
root@pve1# qm set 200 --net0 virtio,bridge=vmbr0,tag=100
root@pve1# qm set 200 --agent enabled=1
root@pve1# qm set 200 --serial0 socket

09 Edge cases

Edge case: 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 scenariuszy blokujących migrację vmware proxmox.

1. Snapshoty blokują Import Wizard

Importer odmawia startu, gdy na VM istnieje łańcuch snapshotów. Rozwiązanie: scalenie (consolidate) lub usunięcie snapshotów przed importem — nie podczas.

remove-snapshots.ps1
PS> Get-VM prod-app-01 | Get-Snapshot | Select Name,SizeGB,Created
PS> Get-VM prod-app-01 | Remove-Snapshot -Snapshot (Get-Snapshot -Name 'backup-2026-06') -RemoveChildren -Confirm:$false
PS> Get-VM prod-app-01 | Get-View | ForEach-Object { $_.RunConsolidateVM_Task() }
✓ Snapshoty usunięte · dysk skonsolidowany · gotowe do importu

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, dysk już poza vSAN)
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 do skopiowania. Przed migracją przekonwertuj RDM na VMDK (Storage vMotion) lub zaplanuj PCIe passthrough w Proxmox dla wyjątków (np. licencjonowany HBA).

4. Zaszyfrowane VM i vTPM

VM z VM Encryption wymaga eksportu z kluczami KMS lub migracji przez OVF z odszyfrowaniem w vCenter. vTPM nie jest przenoszony 1:1 — odtwórz moduł TPM w konfiguracji QEMU lub wyłącz wymaganie TPM w aplikacji przed cutover.

5. VLAN — VM bootuje, ale brak sieci

Po migracji najczęstszy problem sieciowy to błędny tag VLAN lub brak bridge-vlan-aware yes na hoście.

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` + sprawdź switch port mode

6. Windows BSOD 0x7B po pierwszym restarcie

Patrz sekcja VirtIO powyżej. Skrót: nie przełączaj na VirtIO SCSI, dopóki sterownik nie jest w obrazie boot volume. virt-v2v robi to automatycznie; przy Wizard — pre-instalacja na ESXi lub boot przez SATA.

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ł affinity
vMotion wewnątrz vSphere	`qm migrate` między węzłami PVE	Tylko przy współdzielonym storage (SAN/Ceph)
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 (near-live cutover)
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

ℹ️

Bez współdzielonego storage HA w Proxmox restartuje VM na innym węźle, ale nie przenosi dysku — potrzebujesz iSCSI/NFS/Ceph lub replikacji ZFS/ceph.

11 Walidacja

Walidacja i near-live cutover

Near-live cutover to sekwencja faz minimalizująca przestój — nie jest to natywna migracja live z ESXi. Stosuj ją dla systemów produkcyjnych, gdzie akceptowalne są sekundy–minuty niedostępności.

Kopia wstępna (VM online na ESXi)

Import Wizard z live-import lub rsync/virt-v2v w trybie przygotowawczym. VM produkcyjna nadal działa na VMware.

Testy na PVE (izolowana sieć)

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

Finalny cutover

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

Checklist 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, runbook operacyjny

12 Rollback

Rollback i wygaszenie VMware

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

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

🎯

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

Runbook rollback (szablon)

Krok	Akcja	Odpowiedzialny	Czas
1	Zatrzymaj VM na Proxmox (`qm stop`)	Admin PVE	30 s
2	Uruchom oryginalną VM na ESXi (snapshot sprzed cutover)	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	—

Checklist przed cutover (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 źródle ESXi
VirtIO / Guest Agent zainstalowane i przetestowane
Mapowanie VLAN i firewall zweryfikowane na VLAN testowym
DNS TTL obniżony (300 s) 24 h przed cutover
Runbook rollback podpisany 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. Near-live cutover (kopia + delta) to osobna procedura inżynieryjna.

Proxmox VE 8.1 lub nowszy z pakietem pve-esxi-import-tools (pve-manager ≥ 8.1-8, libpve-storage-perl ≥ 8.1.3). 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 może zablokować klaster (split-brain). HA w Proxmox (pve-ha-manager) wymaga współdzielonego storage lub replikacji dla live migration.

Usuń lub scal wszystkie snapshoty na VM w vSphere przed importem. To najczęstsza przyczyna błędu. Po konsolidacji dysku uruchom import ponownie — patrz sekcja edge case snapshoty.

Nie bezpośrednio. Przenieś VM Storage vMotion na datastore poza vSAN, wyeksportuj OVF, lub użyj virt-v2v po stagingu dysku. Szczegóły w sekcji vSAN.

Bootuj z kontrolera SATA/IDE, zainstaluj VirtIO SCSI z virtio-win.iso, dopiero potem zmień typ dysku w qm set. Alternatywnie użyj virt-v2v, który wstrzykuje sterowniki podczas konwersji. 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) i wstrzykują sterowniki VirtIO, więc nie potrzebujesz osobnego oprogramowania.

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 rollbacku.

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 cutover z minimalnym przestojem. Obsługujemy środowiska od kilku do ponad 100 VM.

Potrzebujesz wsparcia przy migracji?

Przeprowadzimy audyt Twojego środowiska VMware i wykonamy migrację vmware proxmox z gwarancją rollbacku i minimalnego przestoju — w ramach kompleksowego wdrożenia Proxmox dla firm.

⚡ Bezpłatna analiza środowiska

// Table of Contents

Prerequisites and PVE preparation
VMware inventory and audit
Migration methods comparison
Matrix: Wizard vs virt-v2v vs OVF
ESXi Import Wizard step-by-step
virt-v2v workflow (vmware to proxmox converter)
Network mapping: VLANs and bridges
Storage design: ZFS, iSCSI, Ceph
Guest tuning: VirtIO for Windows and Linux
Edge cases: snapshots, vSAN, Windows BSOD
HA cluster migration on Proxmox
Validation checklist and near-live cutover
Rollback and VMware decommission
Pre-cutover checklist (printable)

01 Prerequisites

Prerequisites and PVE preparation

A production-grade vmware to proxmox migration starts with a stable target cluster — not with copying the first virtual machine. Proxmox VE 8.1 and later ships the integrated ESXi Import Wizard (package pve-esxi-import-tools) for VMware ESXi 6.5 through 8.0. Older PVE releases still support migration through virt-v2v, OVF import, or manual VMDK attach-and-move workflows.

Before touching production workloads, take a verified backup of every VMware VM (Veeam, NetBackup, or storage-level snapshots) and configure Proxmox Backup Server or scheduled vzdump jobs on the destination cluster. VMware remains the source of truth until formal cutover — do not delete snapshots or power off ESXi hosts until validation is complete.

ℹ️

Production HA topology: minimum 3 Proxmox nodes for Corosync quorum (pmxcfs). A two-node cluster cannot safely survive a single host failure without risking split-brain.

Infrastructure checklist

Proxmox VE 8.1+ fully patched with pve-esxi-import-tools installed
Management network: 1 GbE minimum; large VM migrations benefit from a dedicated 10/25 GbE VLAN between ESXi and PVE
ESXi/vSphere account with VM and datastore read access (vCenter optional; direct ESXi import is faster)
Target storage: local-zfs, NFS, iSCSI, or Ceph — free space ≥ 120% of VM size (snapshots, logs, buffer)
Proxmox Backup Server or vzdump schedule configured before production migration
VLAN mapping document: VMware port groups → Proxmox vmbr bridges
Maintenance window for final import (VM must be powered off on ESXi for standard import)

pve-prep.sh
# Verify PVE version and ESXi import package
root@pve1# pveversion -v | grep -E 'pve-manager|pve-esxi'
root@pve1# apt install pve-esxi-import-tools -y
 
# Test connectivity to ESXi host (port 443)
root@pve1# openssl s_client -connect esxi01.company.com:443 -brief </dev/null
 
# Next free VMID in cluster
root@pve1# pvesh get /cluster/nextid
✓ PVE ready for import · next VMID: 200

Network planning deserves equal attention. Separate management, storage, migration, and guest traffic onto dedicated VLANs where possible. Corosync cluster traffic should use a low-latency link — never route it over a congested production LAN. If you plan Ceph, reserve a dedicated 10/25 GbE network before installing OSDs.

02 Inventory

VMware inventory and audit

Without a complete inventory you cannot choose the right migration method or estimate cutover time. Collect VM resource usage, application dependencies, network configuration, and exceptions (RDM disks, vGPU passthrough, vSAN-backed VMs that the native importer cannot read).

PowerCLI remains the standard tool for VMware inventory export. Run scripts against vCenter for a cluster-wide view, or connect directly to standalone ESXi hosts for smaller environments. Store exports in version control or a secure document repository — they become the baseline for post-migration validation.

vmware-inventory.ps1
# Export inventory via PowerCLI
PS> Connect-VIServer -Server vcenter.company.com
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
 
# Snapshots and VMware Tools status
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
 
# Port groups and VLAN IDs
PS> Get-VirtualPortGroup | Select Name,VLanId,VirtualSwitch | Export-Csv portgroups.csv -NoTypeInformation
 
# Datastores and utilization
PS> Get-Datastore | Select Name,Type,CapacityGB,FreeSpaceGB | Export-Csv datastores.csv -NoTypeInformation
✓ Exported 52 VMs · 14.2 TB provisioned · 8 port groups · 5 datastores

How to interpret each record

VMs with snapshots — consolidate before import or plan a separate virt-v2v conversion
RDM (physical mode) disks — not supported by Import Wizard; migrate to VMDK or PCIe/NVMe passthrough first
vSAN — not supported by the native importer; use OVF export or virt-v2v over the network
VMs with outdated VMware Tools — update before Windows migration (simplifies later VirtIO installation)
Application HA pairs — mark cluster members for near-live migration (one instance at a time)

Classify VMs into migration waves: non-critical dev/test first, then internal services, then production databases and customer-facing applications. Each wave should have a defined rollback owner and communication plan.

03 Methods

Migration methods comparison

Proxmox does not offer a native equivalent of vMotion from ESXi to KVM — near-live cutover is an engineering process (background copy + short source shutdown), not a one-click live migration between hypervisors. The table below helps you pick the right tool for scale and VM type.

Method	Description	Downtime	Best for
ESXi Import Wizard	Native PVE 8.1+ importer via ESXi API; maps VMX → QEMU config	VM powered off on ESXi (live-import option starts VM on PVE earlier)	Standard ESXi 6.5–8.0 VM migration
virt-v2v (libguestfs)	Converts VMDK → qcow2/raw + installs VirtIO drivers in guest	VM powered off during conversion	Windows/Linux, large disks, automatic VirtIO
OVF/OVA import	`qm importovf` or GUI wizard for exported templates	Depends on OVA size	VMs without direct ESXi access, OVF templates
Attach-and-move (VMDK)	Copy VMDK files to PVE storage + `qm disk import`	VM powered off	Single disks, NFS shared between ESXi and PVE
Near-live cutover	Full online copy + delta sync + brief source shutdown	Seconds–minutes (NOT native ESXi live migrate)	HA production, databases, critical services

⚠️

Live-import in PVE starts the VM on Proxmox after copying minimal boot data — the VM on ESXi must still be powered off. This reduces downtime but is not equivalent to vMotion or live migration without shutting down the source.

Decision matrix: Import Wizard vs virt-v2v vs OVF/OVA

Use this vmware to proxmox migration matrix in internal runbooks — link directly to #vtp-method-matrix.

Criteria	ESXi Import Wizard	virt-v2v	OVF / OVA
ESXi API access required	Yes (443/tcp)	Optional (VDDK)	No — export file only
VM on vSAN	Not supported	After disk staging off vSAN	Yes, via vCenter OVF export
VM snapshots	Blocks import — consolidate first	VM must be snapshot-free	Export typically without snapshots
Auto VirtIO (Windows)	Partial — often manual post-import	Yes (virtio-win injection)	No — manual driver install
VMX → QEMU mapping	Automatic	Manual `qm set`	From OVF metadata
Proxmox GUI	Full wizard	CLI on conversion host	`qm importovf` + GUI
Batch (dozens of VMs)	API / `qm import` scripts	Scalable via Ansible/cron	One VM per export
Typical downtime	Full offline import	Offline conversion	Depends on OVA size
Choose when	Standard ESXi 6.5–8.0, local/SAN datastore	Windows, unusual disks, bulk conversion	vSAN, no API, archival VMs

30-second method picker checklist

Datastore is vSAN or encrypted VMDK? → OVF/OVA or virt-v2v after staging off vSAN
Snapshots on the VM? → remove or consolidate before any method
Windows without VirtIO? → virt-v2v or pre-install virtio-win on ESXi, then Wizard
Single VM, ESXi online, no exceptions? → Import Wizard
No host access, files only? → OVF or local virt-v2v -i disk

04 Import Wizard

ESXi Import Wizard — step by step

The official Import Wizard (PVE 8.1+) adds an "ESXi" source under Datacenter → Storage → Add. The importer uses the public ESXi API — no proprietary VMware hooks. For automation, use the equivalent qm import command.

Add ESXi source

In the GUI: Datacenter → Storage → Add → ESXi. Enter host IP/FQDN and administrator credentials. For self-signed certificates, add the CA to the trust store or check "Skip Certificate Verification" (lab only).

Select VM and target storage

Browse the ESXi storage content, select the VM, click Import. Map network interfaces to vmbr bridges. Choose target storage (e.g. local-zfs, ceph-pool).

Power off VM on ESXi and run import

Standard import requires the VM to be powered off on the source. Optionally enable live-import so PVE starts the guest after copying boot-critical data.

qm-import-esxi.sh
# After adding ESXi storage "esxistore" in /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
 
# Network mapping after import (net0 → vmbr0 VLAN 100)
root@pve1# qm set $VMID --net0 virtio,bridge=vmbr0,tag=100
 
# Start and verify
root@pve1# qm start $VMID
root@pve1# qm status $VMID
✓ Import complete · VMID 200 · status: running

💡

Import through vCenter works but is significantly slower than direct ESXi host import. In production we recommend adding each ESXi host as a separate import source.

The Proxmox API exposes the same workflow: first call GET /nodes/{node}/storage/{storage}/import-metadata to list importable VMs, then POST /nodes/{node}/qemu with import-from= syntax for disk volumes. This enables Ansible or Terraform pipelines for large-scale migrations.

05 virt-v2v

virt-v2v workflow — vmware to proxmox converter

virt-v2v from the libguestfs project is a proven VMware-to-KVM disk converter. It automatically installs VirtIO drivers in Windows (via virtio-win) and updates initramfs on Linux. Use it when Import Wizard hits unusual VMX configurations, when you need offline conversion on a dedicated conversion host, or when batch-processing dozens of VMs with consistent virtio injection.

Install virt-v2v on a Linux conversion host (Debian/Ubuntu/RHEL) or directly on a Proxmox node with sufficient disk space. For vCenter access, install VMware VDDK libraries (libguestfs-tools + VDDK in /usr/lib/vmware-vix-disklib).

virt-v2v-proxmox.sh
# Conversion via vCenter API (VM must be powered off)
$ virt-v2v -ic vpx://vcenter.company.com/Datacenter/cluster/esxi01 \
    -it vddk \
    --vddk-libdir /usr/lib/vmware-vix-disklib \
    -o local -os /var/lib/vz/images/200 \
    -of qcow2 \
    "prod-db-01"
 
# Create VM and attach disk in Proxmox
root@pve1# qm create 200 --name prod-db-01 --memory 16384 --cores 8 --net0 virtio,bridge=vmbr0
root@pve1# qm importdisk 200 /var/lib/vz/images/200/prod-db-01-sda qcow2 local-zfs
root@pve1# qm set 200 --virtio0 local-zfs:vm-200-disk-0 --boot order=virtio0 --agent enabled=1
✓ Conversion: 240 GB VMDK → 178 GB qcow2 · VirtIO installed in guest

Alternative: local VMDK conversion

If VMDK files are already copied to the PVE host:

virt-v2v-local.sh
$ virt-v2v -i local -i disk /mnt/import/vm-disk.vmdk -o local -os /var/lib/vz/images/201 -of qcow2
root@pve1# qm disk import 201 /var/lib/vz/images/201/vm-disk.qcow2 local-zfs --format qcow2

virt-v2v supports Windows Server 2008 R2 through 2025, RHEL/CentOS/Rocky/Alma 7–9, Ubuntu LTS, Debian, SLES, and Oracle Linux. Always test one representative VM per OS generation before batch conversion.

06 Network

Network mapping: VLANs and bridges

Map VMware port groups with VLAN IDs to Linux bridges with 802.1Q tags. In Proxmox the standard pattern is vmbr0 as a VLAN-aware trunk carrying multiple guest VLANs, or dedicated bridges per segment for simpler firewall rules.

VMware	Proxmox VE	Example
vSS / vDS portgroup VLAN 100	bridge=vmbr0,tag=100	Application production
Portgroup without VLAN (native)	bridge=vmbr0 (no tag)	Management
vDS LACP uplink	Linux bond + vmbr or OVS bridge	2×25 GbE aggregation
NSX overlay	SDN EVPN/VXLAN (separate project)	Micro-segmentation

/etc/network/interfaces (excerpt)
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
 
# VM on VLAN 200: qm set 200 --net0 virtio,bridge=vmbr0,tag=200

ℹ️

After migration verify MAC addresses and firewall rules (iptables/nftables, Proxmox firewall). Interface reordering (eth0/eth1) in the guest may require netplan fixes or /etc/udev/rules.d/70-persistent-net.rules updates on Linux.

For environments migrating from NSX or complex vDS policies, plan a parallel networking phase: stand up Proxmox SDN or EVPN/VXLAN fabrics before cutover so security groups and micro-segmentation rules are ready on day one.

07 Storage

Storage design: ZFS, iSCSI, Ceph

Storage choice determines live migration between PVE nodes, I/O performance, and total cost. The three most common models when migrating from VMware:

Local-ZFS

Simple start: each node has its own ZFS pool. No shared storage — live migration requires copying disks over the network. Good for smaller clusters and dev/test. Use ZFS snapshots for local backup before risky changes.

iSCSI / NFS (SAN)

Shared LUN or NFS export mounted on all nodes. Enables native live migration between PVE hosts (qm migrate). Integrates with existing SAN after VMFS decommission. Match LUN alignment and thin-provisioning policies to your RPO/RTO targets.

Ceph RBD

Distributed storage built into Proxmox — 3× replication, self-healing, horizontal scaling. Requires dedicated storage network (minimum 10 GbE, recommended 25 GbE). A vSAN replacement without Broadcom licensing. Plan MON + OSD topology before the first VM import.

storage-example.sh
# Add iSCSI LUN as LVM-thin storage
root@pve1# pvesm add iscsi iscsi-san --portal 10.0.20.50 --target iqn.2024-01.com.company:prod
root@pve1# pvesm add lvmthin iscsi-thin --thinpool data --vgname pve-iscsi --content images,rootdir
 
# Local ZFS pool status
root@pve1# zpool list && zfs list

When sizing storage, account for Proxmox snapshots, PBS deduplication, and Ceph recovery overhead. A rule of thumb: provision 130–150% of current VMware used capacity for the first year of growth.

08 VirtIO

Guest tuning: VirtIO for Windows and Linux

After migration replace emulated VMware devices (vmxnet3, LSI Logic) with VirtIO for better performance and lower CPU overhead. Import Wizard partially maps interfaces; virt-v2v installs drivers automatically. QEMU Guest Agent enables clean shutdowns, IP reporting, and freeze/thaw for application-consistent backups.

Windows Server

Mount virtio-win.iso (available from Proxmox repositories or virtio-win.org)
Install drivers: VirtIO SCSI, VirtIO Net, QEMU Guest Agent
Enable QEMU Guest Agent in VM config: --agent enabled=1
Verify boot: switch disk controller to VirtIO SCSI before reboot
Check Windows activation — motherboard UUID change may require KMS reactivation

Windows Server — avoiding BSOD (0x7B INACCESSIBLE_BOOT_DEVICE)

The most common failure after vmware to proxmox migration on Windows: blue screen 0x0000007B right after switching the disk controller to VirtIO SCSI. The disk boots on emulated SATA/IDE from Import Wizard, but VirtIO drivers are missing from the boot volume.

Method A (recommended): on the running VM in ESXi mount virtio-win.iso, install VirtIO SCSI + Net + Guest Agent, then import and switch controller
Method B: after import keep disk on SATA/IDE, boot, install VirtIO from ISO, switch to VirtIO SCSI, reboot
Method C: virt-v2v injects drivers during conversion — lowest BSOD risk on first PVE boot
After migration uninstall VMware Tools — leftover VMware services can conflict with QEMU Guest Agent
Verify UEFI vs BIOS — Import Wizard preserves firmware; with OVF check qm set <vmid> --bios ovmf vs seabios

windows-post-migrate.ps1
# Remove VMware Tools after successful Proxmox boot
PS> Get-WmiObject -Class Win32_Product | Where-Object { $_.Name -like '*VMware Tools*' } | ForEach-Object { $_.Uninstall() }
 
# Verify QEMU Guest Agent
PS> Get-Service QEMU-GA | Select Status, StartType
✓ Guest Agent: Running · VMware Tools removed

Linux

Modern kernels include virtio_blk/virtio_scsi modules by default
After virt-v2v: update-initramfs -u (Debian/Ubuntu) or dracut --force (RHEL)
Install qemu-guest-agent and enable the service
Check lsblk and fstab — device names may change from /dev/sda to /dev/vda

qm-virtio-tuning.sh
root@pve1# qm set 200 --scsihw virtio-scsi-pci --scsi0 local-zfs:vm-200-disk-0
root@pve1# qm set 200 --net0 virtio,bridge=vmbr0,tag=100
root@pve1# qm set 200 --agent enabled=1
root@pve1# qm set 200 --serial0 socket

CPU type selection also matters post-migration: start with x86-64-v2-AES or x86-64-v3 for broad live-migration compatibility across heterogeneous hosts, then tighten to host only on dedicated single-socket database nodes. See our CPU type guide for details.

09 Edge cases

Edge cases: snapshots, vSAN, Windows BSOD

Most failed imports are source-state issues, not Proxmox bugs. Seven common blockers for vmware to proxmox migration and how to fix them.

1. Snapshots block Import Wizard

The importer refuses to start when snapshot chains exist. Consolidate or delete snapshots before import — not during.

remove-snapshots.ps1
PS> Get-VM prod-app-01 | Get-Snapshot | Select Name,SizeGB,Created
PS> Get-VM prod-app-01 | Remove-Snapshot -Snapshot (Get-Snapshot -Name 'backup-2026-06') -RemoveChildren -Confirm:$false
PS> Get-VM prod-app-01 | Get-View | ForEach-Object { $_.RunConsolidateVM_Task() }
✓ Snapshots removed · disk consolidated · ready to import

2. vSAN VMs — Import Wizard will not work

The native importer reads datastores via ESXi API — vSAN objects are not exportable on that path. Workarounds:

Storage vMotion VM to NFS/VMFS (off vSAN) — then Import Wizard
Export OVF/OVA from vCenter → qm importovf on Proxmox
virt-v2v via VDDK from vCenter (VM powered off, disk already off vSAN)
Large VMs: clone to staging LUN, import from staging, delete clone after validation

3. RDM and independent disks (physical mode)

Physical-mode RDM has no VMDK file to copy. Convert RDM to VMDK (Storage vMotion) before migration, or plan PCIe passthrough in Proxmox for exceptions (e.g. licensed HBA).

4. Encrypted VMs and vTPM

VM Encryption requires KMS key export or OVF export with decryption in vCenter. vTPM does not transfer 1:1 — recreate TPM in QEMU config or disable TPM requirement in the application before cutover.

5. VLAN — VM boots but no network

Most common post-migration network issue: wrong VLAN tag or missing bridge-vlan-aware yes on the host.

Symptom	Cause	Fix
No IP after boot	Wrong tag in `qm set --net0`	Match VMware port group VLAN ID with PVE `tag=`
eth0 → eth1 on Linux	NIC reordering	netplan / `70-persistent-net.rules`
Windows “unidentified network”	New MAC → new profile	Reassign static IP or reset network profile
Traffic blocked despite IP	PVE firewall / no trunk	`bridge-vlan-aware yes` + verify switch port mode

6. Windows BSOD 0x7B on first reboot

See VirtIO section above. Short version: do not switch to VirtIO SCSI until drivers are in the boot volume. virt-v2v handles this automatically; with Wizard — pre-install on ESXi or boot via SATA.

7. Import Wizard “certificate verify failed”

ESXi uses self-signed certs. In lab: skip verification. In production: add ESXi cert to PVE trust store or use FQDN matching the certificate SAN.

10 HA

HA cluster migration on Proxmox

VMware HA (vSphere DRS/HA) has no direct equivalent during ESXi → PVE migration. Enable Proxmox HA after VMs run on shared storage with a minimum of 3 nodes.

VMware	Proxmox VE	Migration notes
vSphere HA	pve-ha-manager + 3-node quorum	Enable HA only after VMs on shared storage
DRS	Dynamic Load Balancer (PVE 9.2+)	Requires HA + affinity rules
vMotion within vSphere	`qm migrate` between PVE nodes	Only with shared storage (SAN/Ceph)
FT (Fault Tolerance)	No 1:1 — application replication	Plan active/passive or K8s/DB cluster

Application cluster migration order

Migrate passive / secondary node first — validate on isolated VLAN
Switch traffic (DNS/LB) to the PVE instance
Migrate primary in maintenance window (near-live cutover)
Add both VMs to HA group only after failover tests
Set anti-affinity rules so replicas do not land on the same node

ℹ️

Without shared storage Proxmox HA restarts VMs on another node but does not move disks — you need iSCSI/NFS/Ceph or ZFS/ceph replication.

11 Validation

Validation checklist and near-live cutover

Near-live cutover is a phased sequence that minimizes downtime — it is not native live migration from ESXi. Use it for production systems where seconds to minutes of unavailability are acceptable.

Initial copy (VM online on ESXi)

Import Wizard with live-import option, or preparatory rsync/virt-v2v run. Production VM continues running on VMware.

Testing on PVE (isolated network)

Start the copy on Proxmox in a test VLAN. Verify login, services, database connectivity, and application health endpoints.

Final cutover

Power off VM on ESXi, run final delta sync, start on PVE, switch DNS/load balancer. Typical downtime: 30 s – 2 min. For HA pairs behind a load balancer, migrate one instance at a time for zero perceived downtime.

Pre-production validation checklist

Clean VM boot — Proxmox console and guest system logs
Network: gateway ping, DNS resolution, application port tests (curl, nc)
Disk: I/O performance (fio or CrystalDiskMark on Windows)
PBS backup: first full backup after migration with verified restore test
Monitoring: Prometheus node_exporter or SNMP — alerts configured
HA: VM added to HA group, failover test in maintenance window
Documentation: updated CMDB, network diagram, operational runbook

Automate smoke tests where possible: Ansible playbooks that check service ports, HTTP 200 responses, and database query latency against baseline metrics captured during the VMware audit phase.

12 Rollback

Rollback and VMware decommission

Until formal decommission, the VMware environment remains ready for rollback. Rollback is typically DNS/VIP switch back to ESXi and starting the original VM — minutes, not hours. Keep VMware snapshots and datastores intact through the observation period.

Maintain VMware snapshots through the observation period (30–90 days)
Do not delete VMFS datastores until all VMs are verified on PVE
After stable period: power off VMs on ESXi, remove from inventory, reclaim datastore space
Close Broadcom licenses / cancel vSphere subscription after management sign-off
Archive PowerCLI exports and VMware configuration documentation (compliance)

🎯

Always document rollback in writing: for each critical VM record RTO, decision owner, and switch steps (DNS, VIP, firewall). Test rollback in staging before production cutover.

Rollback runbook (template)

Step	Action	Owner	Time
1	Stop VM on Proxmox (`qm stop`)	PVE admin	30 s
2	Start original VM on ESXi (pre-cutover snapshot)	VMware admin	1–2 min
3	Switch DNS / VIP / firewall to VMware addresses	Network team	1–5 min
4	Application verification (health check, logs)	App owner	5–15 min
5	User communication + post-mortem	IT manager	—

Pre-cutover checklist (printable)

Copy or print this list before final production switchover. Anchor: #vtp-checklist.

VMware backup + PBS snapshot of PVE VM after test
No snapshots on ESXi source
VirtIO / Guest Agent installed and tested
VLAN mapping and firewall verified on test VLAN
DNS TTL lowered (300 s) 24 h before cutover
Rollback runbook signed by application owner
Maintenance window and user notice sent
Monitoring and alerts configured on target VM

Frequently asked questions

No — there is no native vMotion equivalent between ESXi and KVM. Import Wizard requires the VM to be powered off on ESXi for standard import. The live-import option reduces downtime by starting the VM on PVE early, but the source must still be stopped. Near-live cutover (copy + delta) is a separate engineering procedure.

Proxmox VE 8.1 or later with the pve-esxi-import-tools package (pve-manager ≥ 8.1-8, libpve-storage-perl ≥ 8.1.3). Tested with ESXi 6.5–8.0. Older environments migrate via virt-v2v or OVF/VMDK import.

The tools are complementary. Import Wizard is faster for GUI/API integration and automatic VMX mapping. virt-v2v (libguestfs) excels at offline batch conversion, unusual disk layouts, and automatic VirtIO installation — especially on Windows.

Minimum 3 nodes for safe Corosync quorum. With 2 nodes, a single host failure can lock the cluster (split-brain). Proxmox HA (pve-ha-manager) requires shared storage or replication for live migration between nodes.

Remove or consolidate all snapshots on the VM in vSphere before import. This is the most common failure cause. After disk consolidation, retry import — see snapshots edge case.

Not directly. Storage vMotion off vSAN, export OVF, or use virt-v2v after disk staging. Details in the vSAN section.

Boot from SATA/IDE controller, install VirtIO SCSI from virtio-win.iso, then change disk type in qm set. Alternatively use virt-v2v which injects drivers during conversion. See VirtIO / BSOD.

Two tools act as a VMware to Proxmox converter: the built-in Import Wizard in Proxmox VE and virt-v2v. Both convert VMDK disks to the QEMU format (QCOW2/raw) and inject VirtIO drivers, so you do not need any separate conversion software to migrate VMware VMs to Proxmox.

Yes — we migrate VMware VMs to Proxmox in batches, grouping machines by dependency. For larger estates we script the virt-v2v conversion so the process is repeatable and auditable, with a rollback point for every batch and minimal downtime per workload.

Yes. An enterprise VMware to Proxmox migration — a full VMware to Proxmox VE migration — covers an HA cluster (minimum 3 nodes), shared storage (Ceph/iSCSI/NFS), VLAN network mapping and a near-zero-downtime cutover. We handle environments from a handful to well over 100 VMs.

Need help with your migration?

We audit your VMware environment and execute vmware to proxmox migration with rollback guarantees and minimal downtime, as part of our end-to-end Proxmox implementation services.

⚡ Free Environment Analysis