Czym jest migracja P2P
Migracja P2P (Physical-to-Physical) to przeniesienie całego systemu operacyjnego, aplikacji i danych z jednego serwera fizycznego (bare-metal) na inny serwer fizyczny — bez warstwy hypervisora. W przeciwieństwie do migracji P2V, system po migracji nadal działa bezpośrednio na sprzęcie docelowym.
Typowe scenariusze P2P:
- Odświeżenie sprzętu (hardware refresh) — stary Dell/HP → nowy AMD EPYC
- Przeniesienie między szafami rack lub ośrodkami danych (relokacja DC)
- Zamiana uszkodzonego węzła na identyczny model zapasowy
- Systemy, które historycznie „nie nadają się do wirtualizacji” (licencje per-socket, urządzenia HSM, specyficzne karty PCIe)
P2P to nie to samo co klonowanie VM ani migracja VMware → Proxmox. To operacja na poziomie dysku i boot loadera — bliżej disaster recovery niż konsolidacji.
Kiedy P2P ma sens — a kiedy nie
| Scenariusz | P2P (bare-metal) | P2V na Proxmox VE |
|---|---|---|
| Hardware refresh 1:1, brak czasu na projekt | Tak — szybki lift-and-shift | Lepsze długoterminowo |
| Konsolidacja 10+ serwerów fizycznych | Nie — koszt rośnie liniowo | Tak — ratio 10:1 realne |
| Wymóg HA i szybkiego failoveru | Klastry aplikacyjne lub drogi sprzęt | Wbudowany HA Proxmox |
| Licencje Oracle/SQL per rdzeń | Wszystkie fizyczne rdzenie każdego serwera | Nadal rdzenie hosta; Oracle liczy cały host (soft partitioning) |
| Karta PCIe (FPGA, GPU, HBA dedykowane) | Passthrough lub bare-metal | PCIe passthrough w Proxmox |
| Redukcja OPEX (energia, rack, support) | Minimalna | Do ~75% mniej energii (kalkulator P2V) |
Reguła praktyczna: jeśli planujesz P2P dla więcej niż 2–3 serwerów w tym samym cyklu budżetowym — zatrzymaj się i policz TCO pod konsolidację P2V na Proxmox. W 8 na 10 audytów, które wykonujemy, P2P okazuje się droższym obejściem.
Jak przeprowadzamy migrację P2P
Bezpieczna migracja P2P wymaga inżynierii na poziomie dysku, firmware i boot — nie wystarczy skopiować plików przez sieć. Nasz sprawdzony proces:
Audyt sprzętowy i mapowanie zależności
Model RAID (sprzętowy vs mdadm/ZFS), wersja firmware, mapowanie NIC (bonding, VLAN), karty PCIe, wersja kernela i sterowników. Dokumentujemy boot order i identyfikatory dysków (UUID/labels).
Replikacja blokowa lub obraz dysku
W zależności od systemu: kopia blokowa (dd z kompresją albo Clonezilla), rsync plików albo narzędzia producenta (np. wirtualne nośniki Dell iDRAC). Dla Windows — VSS snapshot przed kopią lub narzędzia typu Disk2vhd jako etap pośredni.
Dostosowanie do nowego sprzętu
Przebudowa initramfs z modułami dla nowego kontrolera RAID/NVMe i ponowna instalacja GRUB z nośnika ratunkowego (chroot), mapowanie interfejsów sieciowych (przewidywalne nazwy, np. enp1s0), weryfikacja licencji Windows/RHEL po zmianie UUID maszyny.
Testy i przełączenie produkcyjne
Boot w izolowanej sieci, testy aplikacji, synchronizacja delta (jeśli możliwa), okno serwisowe na cutover DNS/IP. Stary serwer zostaje punktem wycofania przez uzgodniony czas.
Pułapka P2P: ten sam model na nowym sprzęcie
Sam refresh bare-metal rozwiązuje tylko problem starzejącego się sprzętu. Nie rozwiązuje strukturalnych problemów infrastruktury:
- Niska gęstość — każda aplikacja nadal zajmuje cały serwer fizyczny, nawet jeśli wykorzystuje 15% CPU
- Brak elastyczności — dodanie RAM lub dysku wymaga okna serwisowego na fizycznym hoście
- Koszt licencji — Windows Server, Oracle, SQL Server licencjonowane per rdzeń na każdym hoście osobno
- HA manualne — failover wymaga drugiego identycznego serwera + skomplikowanej konfiguracji aplikacji
- Backup i DR — agent na każdym hoście, brak snapshotów na poziomie hypervisora
Po trzecim cyklu P2P w ciągu 10 lat firma często ma nowszy sprzęt, ale ten sam chaos operacyjny — tylko droższy rack i wyższe rachunki za prąd.
Błąd strategiczny: planowanie P2P dla całego DC bez pytania „czy te workloady mogą działać jako VM?” to najczęstszy powód, dla którego klienci wracają do nas po roku z prośbą o prawdziwą konsolidację.
Dlaczego docelowy stan to Proxmox VE
Zamiast kolejnej fali serwerów bare-metal warto zaplanować migrację P2V na Proxmox VE — nawet jeśli najpierw musisz wykonać P2P na krytycznym systemie legacy.
CAPEX i OPEX
Konsolidacja 10:1 — zamiast 10 serwerów fizycznych wystarczą 1–2 hosty Proxmox. Oszczędność energii i rack space do 75% — policz w kalkulatorze serwerów fizycznych.
HA bez dublowania sprzętu
Proxmox HA + live migration — failover VM w minutach, bez drugiego fizycznego serwera na każdą aplikację. Reguły affinity jak w vSphere — opisaliśmy w artykule o HA affinity.
Licencje
Licencja Oracle EE i SQL Server Enterprise jest za rdzeń, nie za socket. Na Proxmoxie Oracle traktuje KVM jako soft partitioning: płacisz za wszystkie fizyczne rdzenie hosta, na którym baza może działać (w HA także za węzeł zapasowy). Gęstsze VM nie obniżają tego rachunku Oracle — mniejszy rachunek daje węzeł z mniejszą liczbą rdzeni. Dobór EPYC 9175F pod bazy to świadoma strategia licencyjna.
Backup i ransomware
Proxmox Backup Server — snapshoty na poziomie VM, deduplikacja, szyfrowanie i replikacja off-site. Jeden punkt polityki backupu zamiast agentów na każdym bare-metal.
Proxmox VE nie wymaga drogich licencji per rdzeń jak VMware po przejęciu przez Broadcom — oprogramowanie jest bezpłatne, subskrypcja wsparcia opcjonalna. Porównanie TCO: VMware vs Proxmox i oficjalny cennik Proxmox.
Ścieżka hybrydowa: refresh → konsolidacja
Nie musisz wybierać „albo P2P, albo Proxmox” od pierwszego dnia. Rekomendowany model dla firm z mieszanym środowiskiem bare-metal:
- Etap 1 — audyt: inwentaryzacja workloadów i decyzja bare-metal vs VM (szczegóły poniżej).
- Etap 2 — P2P tylko tam, gdzie konieczne: krytyczne legacy na nowym sprzęcie z planem wyjścia.
- Etap 3 — klaster Proxmox: wdrożenie 3-węzłowego HA (wdrożenie Proxmox dla firm).
- Etap 4 — P2V falami: migracja kolejnych serwerów fizycznych do VM na Proxmox, jak w migracji serwerów fizycznych (virt-p2v, Clonezilla albo dd). Źródło jest wyłączone na czas kopiowania dysku — to nie jest okno poniżej 2 minut znane z przełączenia VMware.
- Etap 5 — wyłączenie starego bare-metal: po 30–90 dniach stabilnej produkcji na Proxmox.
Etap 1 w praktyce: co zostaje na serwerze fizycznym
W typowym audycie 70–85% serwerów kwalifikuje się do VM na Proxmox. Na bare-metal zostają wyjątki — poniżej kategorie, które sprawdzamy w pierwszej kolejności. Jeśli workload nie pasuje do żadnej z nich, domyślnie planujemy P2V.
| Kategoria | Przykłady | Dlaczego zostaje fizyczny |
|---|---|---|
| HSM i kryptografia sprzętowa | Thales Luna, Utimaco, moduły PKCS#11 na PCIe/USB | Klucze prywatne nie mogą opuścić hardware; wymogi FIPS / Common Criteria / PCI DSS często zakazują współdzielonego hypervisora |
| Latency < 1 ms (deterministyczna) | HFT, matching engine, sterowanie CNC/robotyka, synchrofazacja telekom | Jitter VM, współdzielenie cache CPU i szeregowanie I/O psują SLA czasu rzeczywistego — nawet przy niskim średnim opóźnieniu |
| Licencja vendor lock | Stare ERP/ISV „tylko fizyczny serwer”, OEM bez praw do VM, aktywacja na UUID płyty głównej | Umowa licencyjna lub mechanizm aktywacji nie przewiduje rehostu — migracja do VM wymaga negocjacji z producentem lub P2P jako etapu przejściowego |
| Dedykowany sprzęt PCIe bez wsparcia w gościu | FPGA (np. trading), karty przechwytujące, stare HBA Fibre Channel z boot-from-SAN | Sterownik lub firmware nie działa stabilnie w VM; binding WWPN/WWNN przy starcie z SAN |
| OT / SCADA / automatyka | Bramki PLC, systemy wizyjne, MES z certyfikacją producenta | Gwarancja i support wyłącznie na fizycznym serwerze z listy kwalifikowanej — zmiana platformy = utrata wsparcia |
| Binding sprzętowy legacy | Dongle USB, MAC na licencji, dysk UUID, klucz sprzętowy w porcie równoległym | Aplikacja nie startuje po zmianie identyfikatora maszyny — wymaga P2P 1:1 lub rekonfiguracji licencji przed P2V |
Co zwykle nie zostaje na fizycznym (idzie do VM bez dyskusji): serwery WWW i API, Active Directory, DNS/DHCP, pliki, poczta, większość baz danych (PostgreSQL, MSSQL, Oracle — przy świadomej strategii licencjonowania per rdzeń), monitoring, backup, logi, środowiska dev/test. Hosty Proxmox VE same w sobie są bare-metal — to warstwa, na której działają VM, nie kolejny „serwer aplikacyjny”.
Granica szara — sprawdź, zanim zostawisz na fizycznym: GPU (często wystarczy PCIe passthrough w Proxmox zamiast osobnego serwera fizycznego). W audycie każdą pozycję z tabeli oceniamy: czy wymóg jest techniczny, licencyjny, czy tylko historyczny („zawsze tak było”).
Deliverable audytu: macierz serwer → kategoria (bare-metal / VM / passthrough) → uzasadnienie → plan migracji (P2P, P2V lub hybryda). Dzięki temu zarząd widzi, ile serwerów fizycznych naprawdę musi zostać, a ile można skonsolidować w pierwszej fali P2V.
Efekt: zachowujesz ciągłość biznesową tam, gdzie P2P jest nieuniknione — a jednocześnie budujesz infrastrukturę, która obniża CAPEX/OPEX i umożliwia raportowanie oszczędności zarządowi.
Zaplanuj migrację P2P lub przejście na Proxmox
Bezpłatnie przeanalizujemy Twoje serwery fizyczne — powiemy, co ma sens jako P2P, a co opłaca się od razu zwirtualizować na Proxmox VE. Wycena w 24 godziny.
⚡ Bezpłatna analiza środowiska → Migracja P2V na Proxmox