Audyt i inwentaryzacja środowiska
Każda migracja zaczyna się od precyzyjnej inwentaryzacji. Bez pełnego obrazu środowiska VMware nie da się bezpiecznie zaplanować przeniesienia. Na tym etapie zbieramy wszystkie dane niezbędne do dalszych decyzji architektonicznych.
Co zbieramy podczas audytu
- Pełna lista VM: vCPU, RAM, dyski (thin/thick), snapshoty, narzędzia VMware Tools
- Topologia sieci: vSwitche, portgrupy, VLAN-y, vDS (distributed switches)
- Konfiguracja storage: datastores NFS/iSCSI/VMFS, polityki RDM
- Zależności aplikacyjne między maszynami (mapowanie ruchu sieciowego)
- Harmonogram backupów i retencja (Veeam, NetBackup, wbudowany VMware)
- Licencje i wersje: vCenter, ESXi, vSAN, NSX — co jest używane
- SLA i okna serwisowe dla każdego systemu produkcyjnego
Pro tip: Zidentyfikuj VM z bardzo dużą ilością snapshotów lub dyskami RDM — wymagają specjalnej obsługi podczas konwersji i mogą wydłużyć harmonogram migracji.
Projekt architektury Proxmox VE
Na podstawie zebranych danych projektujemy docelowe środowisko Proxmox. Kluczowe decyzje to: model storage, konfiguracja sieci oraz strategia HA. Dobra architektura na tym etapie eliminuje 90% problemów operacyjnych po migracji.
Wybór modelu storage
Trzy główne opcje: Local-ZFS (prostota, wysoka wydajność I/O), ZFS Shared + RoCE (dedykowany serwer ZFS z iSCSI/NFS — rekomendowane), NFS/iSCSI (SAN) (integracja z istniejącą infrastrukturą). Rekomendujemy dedykowany serwer ZFS eksportujący storage przez iSCSI lub NFS, z siecią RDMA over Converged Ethernet (RoCE) — opóźnienia rzędu 1–5 µs przy minimalnym narzucie CPU.
Konfiguracja sieci
Proxmox obsługuje Linux bridges, VLAN-aware bridges, bonding (LACP/active-backup) oraz SDN. Mapujemy vSwitche VMware na odpowiedniki Linux — portgrupy z VLAN ID stają się bridge-portami z vlan_id.
Klaster HA z Corosync
Proxmox Cluster Manager (pmxcfs) wymaga minimum 3 węzłów dla kworum. Wbudowany stos pve-ha-manager (CRM + LRM) na Corosync zarządza automatycznym failoverem VM — bez Pacemakera czy zewnętrznych agentów. Konfigurujemy watchdog, fencing i polityki restartu zgodnie z SLA klienta.
Rekomendacja storage: dedykowany serwer ZFS + RoCE v2. Karty 25/100 GbE z obsługą RDMA (np. NVIDIA/Mellanox ConnectX-5 lub ConnectX-6) — opóźnienia rzędu 1–5 µs przy minimalnym narzucie CPU dzięki hardware offloadowi. Pełne live migration VM bez zatrzymania, wydajność I/O porównywalna z lokalnym NVMe, pełna redundancja HA.
Instalacja i konfiguracja klastra
Proxmox VE instalujemy z obrazu ISO (Debian-based). Instalacja typowego węzła trwa ok. 15 minut. Po instalacji konfigurujemy storage, sieć oraz integrujemy z zewnętrznymi systemami: LDAP/AD, monitoring, backup.
| Komponent | VMware (odpowiednik) | Proxmox VE | Czas konfiguracji |
|---|---|---|---|
| Hypervisor | ESXi | Proxmox VE + KVM | ~15 min/węzeł |
| Zarządzanie klastrem | vCenter | Proxmox Web UI / pvecm | ~30 min |
| Shared storage | vSAN / SAN | ZFS + RoCE / NFS / iSCSI | ~2–4h (ZFS server) |
| Sieć wirtualna | vDS / vSS | Linux Bridge + VLAN SDN | ~1h |
| Backup | Veeam / VDP | Proxmox Backup Server | ~1h |
| Monitoring | vROps | Prometheus + Grafana | ~2h |
| Autentykacja | vSphere SSO | LDAP / AD integration | ~30 min |
Środowisko Proxmox konfigurujemy i testujemy zanim zaczniemy migrację VM. VMware pozostaje w pełni operacyjne przez cały czas — to nasza siatka bezpieczeństwa.
Konwersja VM: virt-v2v
Główne narzędzie do konwersji maszyn VMware na format KVM to virt-v2v — open-source'owe narzędzie projektu libguestfs. Konwertuje dyski VMDK na qcow2/raw i automatycznie instaluje sterowniki virtio w systemie gościa.
Wspierane systemy operacyjne
- Windows Server 2008 R2 / 2012 / 2016 / 2019 / 2022 / 2025
- RHEL / CentOS / Rocky Linux / AlmaLinux 7, 8, 9
- Ubuntu 18.04 / 20.04 / 22.04 / 24.04 LTS
- Debian 10, 11, 12
- SUSE Linux Enterprise Server 12, 15
- Oracle Linux 7, 8, 9
Uwaga na dyski RDM: Raw Device Mappings wymagają osobnego podejścia — konwertujemy je na dyski passthrough lub zastępujemy rozwiązaniem storage-level przed migracją.
Migracja live — near-zero downtime
Dla systemów produkcyjnych stosujemy technikę delta-sync: kopiujemy dane podczas pracy VM, a potem wykonujemy krótką synchronizację różnicową. Wyłączenie VM trwa jedynie na czas ostatecznego transferu delta — zazwyczaj poniżej 2 minut.
Wstępna synchronizacja (VM online)
Kopiujemy obraz dysku do Proxmox podczas pracy VM (VM pozostaje dostępna). Przy dysku 500 GB na łączu 10GbE zajmuje to ~7 minut. VM działa normalnie przez cały czas.
Delta sync — chwilowe zamrożenie
Zatrzymujemy VM na czas transferu blokowego delta (tylko zmienione bloki). Przy typowym obciążeniu produkcyjnym delta to 0.5–3% dysku. Transfer 500 GB dysku — delta ~2 GB — zajmuje ok. 20–90 sekund.
Uruchomienie na Proxmox + UAT
Startujemy VM na Proxmox i uruchamiamy automatyczne testy akceptacyjne (ping, port check, application health endpoint). VMware pozostaje wyłączone ale gotowe do rollbacku przez cały czas trwania UAT.
Weryfikacja i wyłączenie VMware
Ostatni etap — ale najważniejszy z perspektywy bezpieczeństwa. VMware wyłączamy dopiero po potwierdzeniu stabilności środowiska Proxmox. Standardowy okres obserwacji przed zamknięciem licencji VMware to 30–90 dni.
- Monitoring 24/7 przez minimum 2 tygodnie po migracji wszystkich VM
- Weryfikacja backupów PBS — co najmniej 3 udane cykl pełne + przyrostowe
- Testy failover HA — symulacja awarii węzła w oknie serwisowym
- Przegląd alertów i metryk wydajnościowych (Prometheus/Grafana)
- Szkolenie zespołu adminów na nowym środowisku
- Dokumentacja nowej architektury i runbooki operacyjne
- Formalne zamknięcie licencji VMware / zakończenie subskrypcji Broadcom
Rollback zawsze możliwy: Do momentu formalnego wyłączenia hostów ESXi środowisko VMware pozostaje sprawne. Powrót do VMware w przypadku krytycznego problemu zajmuje minuty — wystarczy zmienić DNS lub przełączyć routing.
Gotowy na migrację?
Przeprowadzimy bezpłatny audyt Twojego środowiska VMware i przygotujemy szczegółowy plan migracji z szacunkiem kosztów i harmonogramem.
⚡ Bezpłatna analiza środowiska → Analiza finansowa