Przez ostatnie dwa lata obserwujemy w Polsce wyraźną tendencję – firmy odchodzą od VMware po podwyżkach Broadcoma, szukają alternatywy i trafiają na Proxmoxa. Wygląda atrakcyjnie: darmowy, znany, społeczność jest aktywna, a pierwsze środowisko testowe stoi po godzinie.
Kilka miesięcy później dzwonią do nas.
Nie ma w tym złośliwości, Proxmox to narzędzie, które robi pewne rzeczy dobrze. Ale jest fundamentalnie innym produktem niż VMware. I fundamentalnie innym produktem niż XCP-ng. Różnice, które wyglądają jak detale podczas instalacji, w środowisku produkcyjnym zamieniają się w realne problemy: operacyjne, bezpieczeństwa, compliance.
Poniżej rozpisujemy to bez owijania w bawełnę.
Spis treści
1. Bezpieczeństwo: nie wszystkie hiperwizory są sobie równe
XCP-ng opiera się na hiperwizorze Xen. To ta sama technologia, która napędza infrastrukturę Amazon AWS. Xen jest rozwijany od dekad z myślą o środowiskach, gdzie izolacja nie jest opcją, tylko wymogiem.
Jak to wygląda w praktyce? Xen działa jako warstwa bezpośrednio między sprzętem a systemami operacyjnymi maszyn wirtualnych. Każda maszyna wirtualna jest od pozostałych odgrodzona na poziomie sprzętowym. Nawet samo jądro systemu nie ma do niej dostępu.
Proxmox używa KVM, który jest modułem jądra Linuxa. To sprawdzona technologia, ale z zupełnie inną filozofią. KVM działa w przestrzeni jądra, co oznacza, że granica między hiperwizorem a maszynami wirtualnymi jest cieńsza. W środowiskach, gdzie izolacja jest wymaganiem regulacyjnym (finanse, ochrona zdrowia, administracja publiczna), ta różnica przestaje być akademicka.
Nie mówimy, że KVM jest zły. Mówimy, że Xen został zaprojektowany do konkretnego celu. I ten cel to właśnie środowiska produkcyjne z wymaganiami bezpieczeństwa.
2. Migracja z VMware: kto tu jest bliższym krewnym?
Kiedy administrator przyzwyczajony do VMware siada przy XCP-ng po raz pierwszy, rozumie co widzi. Pule zasobów, zarządzanie hostem, sieci, storage – logika jest znajoma. Xen Orchestra, webowy interfejs zarządzania, prowadzi przez konfigurację w sposób, który nie wymaga przeczytania trzech poradników przed pierwszym krokiem.
Proxmox jest inny. I nie chodzi o to, że gorszy ale o to, że wymaga zmiany sposobu myślenia. Użytkownicy VMware, którzy przez lata dobrze obsługiwał vSphere, przy Proxmoxie zaczynają od nowa. To nie jest naturalny krok naprzód. To skok w bok, który kosztuje czas, cierpliwość i często błędy na starcie.
Z naszego doświadczenia: czas adaptacji zespołów przy przejściu VMware → XCP-ng jest znacznie krótszy niż VMware → Proxmox.
3. Backup i Disaster Recovery: „działa od razu” vs „zrób to sam”
XCP-ng ma wbudowane narzędzia backup’u i Disaster Recovery. Replikacja maszyn wirtualnych na środowisko zapasowe działa natywnie, bez dodatkowych komponentów. VM jest gotowa do uruchomienia w razie awarii. Jeśli organizacja korzysta z Veeam to XCP-ng integruje się z nim bezpośrednio.
Proxmox obsługuje replikację VM wyłącznie wtedy, gdy storage oparty jest na ZFS. W standardowych konfiguracjach klastrów większość środowisk tak nie wygląda. Osiągnięcie scenariusza DR wymaga albo przeprojektowania całej architektury storage, albo dokupienia zewnętrznych rozwiązań i tak czy inaczej, więcej czasu i pieniędzy.
Jest też kwestia backupu jako takiego. W Proxmoxie backup działa na Proxmox Backup Server (osobny serwer lub VM) albo na lokalnym storage. To dodatkowy element infrastruktury, który trzeba postawić, utrzymać i zabezpieczyć. W XCP-ng backup jest częścią platformy.
4. NIS2 i backup immutable: nie wszystkie rozwiązania są równe przed audytem
Dyrektywa NIS2 wymaga, żeby kopie zapasowe były niemodyfikowalne, czyli odporne na zaszyfrowanie przez ransomware i niemożliwe do nadpisania nawet przez administratora systemu. To konkretny wymóg, który pojawia się coraz częściej podczas audytów.
XCP-ng pozwala automatycznie wysyłać kopie zapasowe do chmury(na przykład na Amazon S3 lub dowolny kompatybilny serwis). Co ważne, kopie można tam przechowywać w trybie, który uniemożliwia ich modyfikację lub usunięcie nawet przez administratora systemu. To właśnie tego wymaga NIS2: kopia, której nikt nie może nadpisać ani zaszyfrować ransomwarem.
Proxmox oficjalnie wspiera backup wyłącznie na Proxmox Backup Server lub lokalne storage. Backup na S3 nie jest natywnie obsługiwany. Obejścia istnieją ale ich zgodność z wymogami audytowymi bywa kwestionowana. I słusznie.
Podczas rozmów o NIS2 warto zadać proste pytanie: czy potrafisz pokazać audytorowi, gdzie jest kopia zapasowa, dlaczego jest niemodyfikowalna i jak to udowodnić? W przypadku XCP-ng odpowiedź jest prosta. W przypadku Proxmoxa: zależy.
5. Złożoność wdrożenia: co naprawdę kosztuje „darmowe” narzędzie
To argument, który rzadko pada na początku rozmowy o wyborze platformy. Pada za to kilka miesięcy później, kiedy środowisko produkcyjne już stoi.
Proxmox sprawia wrażenie prostego i rzeczywiście, postawienie środowiska testowego jest łatwe. Problem pojawia się przy wdrożeniu produkcyjnym. Konfiguracja sieci (VLAN-y, bonding, bridging) odbywa się ręcznie przez pliki konfiguracyjne. Zarządzanie storage wymaga solidnej znajomości ZFS lub Ceph, a każde z tych rozwiązań to temat na osobne szkolenie. Zabezpieczenie środowiska, integracja z Active Directory, certyfikaty TLS, zarządzanie logami – nad każdym z tych obszarów trzeba usiąść osobno, najczęściej opierając się na dokumentacji pisanej przez społeczność, o zmiennej jakości.
Firmy, które wdrażają Proxmoxa bez dedykowanego inżyniera z głęboką wiedzą o Linuxie, ponoszą ukryte koszty: długi czas wdrożenia, błędy konfiguracyjne, które ujawniają się dopiero pod obciążeniem, i awarie w najmniej odpowiednim momencie.
XCP-ng zostało zaprojektowane z myślą o administratorach środowisk wirtualizacyjnych a nie o inżynierach Linuxa. Budowa klastra, konfiguracja sieci, harmonogram backupów, replikacja DR to w Xen Orchestra kwestia minut, nie godzin w terminalu.
6. Stabilność: co kryje się za darmową wersją
To temat, o którym mówi się najrzadziej, a który ma największe znaczenie dla środowisk produkcyjnych.
Proxmox w wersji bezpłatnej korzysta z repozytoriów Debiana, które są aktualizowane znacznie rzadziej niż repozytoria subskrypcyjne. W praktyce oznacza to, że znane błędy, łatki bezpieczeństwa i poprawki stabilności trafiają do użytkowników darmowej wersji z opóźnieniem albo wcale. Proxmox otwarcie zachęca do wykupienia subskrypcji właśnie po to, żeby mieć dostęp do aktualnych i przetestowanych paczek. To jest uczciwe, ale trzeba o tym wiedzieć na początku.
Kiedy opóźnienie łatki kosztuje dane
W środowisku Proxmox udev zaczął błędnie mapować dyski. Udev to usługa odpowiedzialna za rozpoznawanie i przypisywanie urządzeń w systemie. W pewnych scenariuszach zamiast przypisać dysk do właściwej maszyny, podpinał go pod inną. Ta druga zaczynała na nim zapisywać dane, nadpisując to, co już tam było.
Ten typ błędu jest udokumentowany publicznie, trafiał do bugtrackera Debiana i repozytoriów systemd (m.in. Bug #993738, GitHub #20212). To nie jest scenariusz egzotyczny. To znana klasa problemów. A użytkownicy darmowej wersji Proxmoxa czekali na poprawkę znacznie dłużej niż ci z subskrypcją.
XCP-ng nie ma podziału na wersję „darmową” i „płatną” w kontekście dostępu do poprawek. Aktualizacje bezpieczeństwa i stabilności są dostępne dla wszystkich jednakowo. Nie trzeba płacić subskrypcji, żeby środowisko działało poprawnie.
Podsumowanie: kogo wybierasz?
Proxmox to dobre narzędzie dla konkretnego profilu użytkownika: doświadczonego inżyniera Linuxa, który ma czas na dopracowanie środowiska i chętnie buduje infrastrukturę od podstaw. W rękach właściwej osoby działa dobrze.
Ale dla firm, które szukają stabilnego następcy VMware: bezpiecznego, zgodnego z regulacjami, łatwego w zarządzaniu dla całego zespołu to XCP-ng jest naturalnym nastepcą VMware’a. Nie wymaga przebudowy całego środowiska. Nie ukrywa krytycznych aktualizacji za paywallem. Nie wymaga inżyniera Linuxa do wykonania codziennych zadań.
Widzimy w Polsce wiele firm, które wybrały Proxmoxa na szybko, bo wyglądał znajomo. Kilka miesięcy później szukają wyjścia.
Lepiej zadać właściwe pytania zanim się wejdzie, niż szukać wyjścia po fakcie.
Czy nasza opinia jest stronnicza?
Pewnie tak.
Jesteśmy Team XCP-ng i nie zamierzamy tego ukrywać. Ale ta stronniczość ma swoje źródło. Nie wzięła się z folderów producenta ani ze słupków w prezentacji sprzedażowej. Wzięła się z lat pracy w środowiskach produkcyjnych, z telefonów od klientów w środku nocy, z analiz po awariach i z długich godzin spędzonych na szukaniu przyczyny problemu.
Proxmox nauczył nas wielu rzeczy. Przede wszystkim tego, że narzędzie, które sprawdza się w labie, niekoniecznie sprawdza się o trzeciej w nocy w środowisku produkcyjnym, kiedy ktoś dzwoni i mówi że dane zniknęły. Dlatego rekomendujemy XCP-ng. Nie dlatego, że Proxmox jest zły. Dlatego, że wiemy co działa, i dla kogo.
