Proxmox VE vs VMware ESXi: Co wybrać do domowego serwera po zmianach licencyjnych Broadcom?

W niedzielę wieczorem serwer, który od lat trzyma Home Assistant, katalog zdjęć i kilka maszyn testowych, nagle przestaje być „ustawiony raz i zapomniany”. Pojawia się komunikat o licencji, brak jasności co do poprawek albo pytanie, czy kolejny obraz instalacyjny VMware da się jeszcze legalnie pobrać bez pakietu dla firmy. Zamiast spokojnej rozbudowy homelabu zostaje decyzja: zostać przy ESXi mimo zmian Broadcom, czy przenieść usługi na Proxmox VE.

Serwer działał bez problemu, aż nagle licencja i aktualizacje stały się problemem

Krótka scenka: domowy NAS, kilka maszyn wirtualnych i pytanie po komunikatach Broadcom

Typowy punkt wyjścia wygląda prosto. Na jednym hoście ESXi działa maszyna z Home Assistantem, druga z serwerem plików albo kontenerami multimediów, trzecia z systemem do testów aktualizacji i czwarta, na której od czasu do czasu ląduje środowisko deweloperskie. Przez lata hypervisor był warstwą, o której nikt nie myślał: startował po awarii prądu, przepuszczał dyski do maszyn i nie generował faktury.

Zmiana modelu VMware po przejęciu przez Broadcom rozbija tę ciszę. Problem nie sprowadza się do jednej kwoty na stronie producenta. Chodzi o to, czy za pół roku nadal będzie wiadomo, skąd pobrać aktualny instalator, jak dostać poprawki bezpieczeństwa, czy da się dołożyć kolejny host bez wchodzenia w pakiet przeznaczony dla działu IT oraz co stanie się ze starym kluczem, gdy padnie dysk systemowy.

Domowy serwer ma inne kryteria niż szafa w firmie. Ma działać przewidywalnie przy ograniczonym budżecie, na sprzęcie, który często jest konsumencki albo „po leasingu”, i nie wymagać vCenter, umowy wsparcia ani osoby, która codziennie czyta biuletyny licencyjne. Jeśli aktualizacja hypervisora staje się projektem prawno-handlowym, platforma przestaje pasować do roli, jaką pełni w mieszkaniu albo małym biurze.

Dlatego porównanie Proxmox VE z VMware ESXi po zmianach Broadcom nie jest akademickim rankingiem funkcji. To pytanie o kontrolę nad własnym laboratorium: kto decyduje o tempie aktualizacji, jakie usługi da się utrzymać bez nadmiarowej infrastruktury i jak kosztowny będzie powrót do działania, gdy dysk albo płyta główna odmówią posłuszeństwa.

Co zmienił Broadcom w VMware i dlaczego odczuwa to użytkownik domowy

Koniec znanego modelu darmowego ESXi i zmiany w ofercie produktowej

Po zamknięciu przejęcia VMware przez Broadcom oferta została uproszczona i wyraźniej skierowana do klientów komercyjnych. Zamiast szerokiego katalogu osobnych produktów i dobrze znanych ścieżek dla małych instalacji, nacisk przesunął się na pakiety subskrypcyjne, w których hypervisor jest elementem większego zestawu, a nie samodzielnym narzędziem „do pobrania i używania w domu”.

Wcześniej darmowy ESXi był dla wielu osób oczywistym startem: ograniczenia dotyczyły głównie zaawansowanego zarządzania, ale sam hypervisor pozwalał postawić maszyny wirtualne bez rozmowy z działem zakupów. Ten punkt odniesienia przestał być stabilny. Nawet jeśli w wybranych momentach pojawiała się ponownie bezpłatna edycja albo ograniczony dostęp do oprogramowania, warunki, zakres funkcji i sposób dystrybucji nie dają już tej samej pewności, co wieloletni, dobrze opisany model.

Dla użytkownika domowego różnica między „system jest zainstalowany i działa” a „mogę go legalnie i wygodnie utrzymywać” jest zasadnicza. Działający host nie gwarantuje dostępu do nowego obrazu ISO, poprawek, dokumentacji dla bieżącej wersji ani możliwości odtworzenia instalacji na identycznych zasadach po awarii. Portal pobierania, konto, uprawnienia licencyjne i zgodność z aktualną polityką producenta stają się częścią eksploatacji, a nie jednorazową formalnością przy pierwszej instalacji.

Subskrypcje zamiast części dotychczasowych licencji wieczystych

Kierunek zmian jest czytelny: Broadcom mocniej wiąże produkty VMware z subskrypcją i pakietami dla organizacji, które kupują wsparcie, centralne zarządzanie i funkcje klasy centrum danych. Licencja wieczysta, którą kiedyś można było „odhaczyć” i używać latami w małym środowisku, nie jest już naturalnym językiem tej oferty. W pakietach takich jak warianty vSphere pojawiają się minima, poziomy wsparcia i zależności od dodatkowych komponentów, które w domu zwykle nie mają uzasadnienia.

To nie oznacza, że ESXi nagle przestaje być technicznie dobrym hypervisorem. Oznacza, że koszt całkowity trzeba liczyć inaczej. Do ceny albo braku ceny samego hypervisora dochodzi niepewność: czy za rok aktualizacja będzie wymagała płatnego pakietu, czy darmowy wariant — jeśli będzie dostępny — utrzyma potrzebne funkcje, oraz czy sprzęt z listy kompatybilności nadal będzie wspierany w wersji, do której da się legalnie wejść.

Przywrócenie bezpłatnej edycji w jakimś momencie nie kasuje tego ryzyka. Zmienia tylko bieżący stan, nie wieloletnią przewidywalność. Domowy plan na pięć lat zakłada zwykle: jeden host, lokalne dyski, okazjonalne snapshoty, kopia na drugi dysk albo NAS i możliwość postawienia wszystkiego od zera z notatek. Jeśli każdy z tych kroków zależy od decyzji handlowej jednej firmy, model dostępności przestaje pasować do planu, nawet gdy dziś instalator da się uruchomić bez opłaty.

Praktyczny wniosek jest ostrożny, ale twardy: zanim zostanie podjęta decyzja „zostaję przy ESXi, bo działa”, trzeba osobno sprawdzić aktualne warunki na stronach Broadcom i VMware — dostęp do obrazów, poprawek, ograniczenia edycji i to, co dzieje się po wygaśnięciu subskrypcji. Artykuł nie zastępuje regulaminu licencji, a regulamin w tym obszarze zmieniał się szybciej niż nawyki administratorów homelabu.

Dwa rozwiązania tego samego problemu: Proxmox VE i VMware ESXi w domowym serwerze

Proxmox VE: otwarty hypervisor oparty na KVM i LXC

Proxmox VE jest dystrybucją opartą na Debianie, która łączy wirtualizację maszyn przez KVM/QEMU z lekkimi kontenerami LXC i panelem w przeglądarce. Dla domu oznacza to jeden system, na którym da się uruchomić pełne maszyny z Windows albo Linuksem oraz mniejsze usługi w kontenerach, bez dokładania osobnego klastra orkiestracji tylko po to, by postawić DNS, menedżer haseł albo kolejkę testową.

W standardowym zestawie są klastry, podstawowa wysoka dostępność przy wspólnej pamięci, integracja ze ZFS, obsługa różnych backendów storage i mechanizmy kopii oraz replikacji. Płatna subskrypcja Proxmox dotyczy przede wszystkim repozytorium enterprise i wsparcia producenta, a nie samego prawa do uruchomienia hypervisora. Bezpłatne repozytorium bez subskrypcji jest jawną, opisaną ścieżką — wolniejszą i bez gwarancji reakcji producenta, ale wystarczającą dla wielu laboratoriów, jeśli aktualizacje są robione świadomie, a nie „w piątek o północy”. ^[2]

Otwartość ma też cenę operacyjną. Pod spodem jest Linux: sieć, mostki, ZFS, uprawnienia, czasem needrestart albo konflikt pakietów po większej aktualizacji Debiana. Osoba, która chce wyłącznie klikać kreatory i nigdy nie zaglądać do powłoki, na początku może uznać panel za zbyt szeroki. Z drugiej strony, gdy karta sieciowa z rynku wtórnego nie wstaje, diagnostyka odbywa się narzędziami znanymi z Linuksa, a nie oczekiwaniem na sterownik z listy HCL.

VMware ESXi: dojrzały hypervisor skoncentrowany na ekosystemie vSphere

ESXi pozostaje hypervisorem typu bare metal o bardzo dojrzałym modelu maszyn wirtualnych, mocnym wsparciu dla obciążeń Windows i ugruntowanej pozycji tam, gdzie reszta środowiska — monitoring, backup, sieć, procedury zmian — jest już zbudowana wokół vSphere. W firmie jego wartość często nie leży w samym hoście, tylko w vCenter, vSAN, integracji z macierzami i w tym, że administratorzy oraz dostawcy usług mówią tym samym językiem.

W domu ten ekosystem bywa zarówno zaletą, jak i balastem. Sam ESXi potrafi być prostszy na starcie: instalacja, datastore na lokalnym dysku, kilka maszyn, konsola w przeglądarce. Pełnia możliwości — scentralizowane szablony, zaawansowane przełączniki, vMotion, spójne polityki storage — zwykle wymaga dodatkowych komponentów i licencji, których mały serwer nie wykorzysta. Filozofia jest inna niż w Proxmoxie: mniej swobody w doborze otwartych klocków, więcej spójności wewnątrz oferty jednego producenta i formalnego wsparcia, jeśli zostało kupione.

Sam hypervisor, niezależnie od logo, nie jest jeszcze środowiskiem. Nadal trzeba zdecydować, gdzie leżą kopie, jak wygląda sieć dla maszyn z dostępem do internetu i tych odciętych, kto monitoruje zapełnienie dysku oraz co się stanie, gdy jedyny host nie wstanie po aktualizacji BIOS-u. Porównanie ma sens dopiero wtedy, gdy te warstwy są nazwane, a nie schowane pod hasłem „jakoś to działało na ESXi”.

Dla domu liczy się nie prestiż platformy w ofertach pracy, lecz to, czy konkretne usługi — automatyka, pliki, multimedia, testy, VPN — da się utrzymać bez dokładania infrastruktury, której nikt nie będzie doglądał. Jeśli większość czasu ma iść w usługi, a nie w utrzymanie platformy, wygrywa rozwiązanie o mniejszej liczbie ukrytych zależności, nie to z dłuższą listą funkcji enterprise.

Porównanie Proxmox VE i VMware ESXi tam, gdzie domowy serwer naprawdę odczuwa różnicę

Koszty, licencjonowanie i dostęp do aktualizacji

Proxmox VE można eksploatować bez opłaty licencyjnej za samą platformę. Subskrypcja jest drogą do repozytorium enterprise, stabilniejszego kanału pakietów i wsparcia. W praktyce domowej wiele osób zostaje przy repozytorium no-subscription, akceptując komunikat w panelu i własną odpowiedzialność za test aktualizacji. To uczciwy układ, o ile jest świadomy: brak subskrypcji nie oznacza braku prawa do używania, oznacza brak komercyjnej opieki. ^[3]

VMware trzeba oceniać według aktualnego cennika i regulaminu Broadcom, a nie według wspomnień o darmowym ESXi sprzed przejęcia. Pakiety subskrypcyjne bywają projektowane pod minimalną liczbę rdzeni albo całe środowisko vSphere, co przy jednym serwerze z ośmioma albo szesnastoma wątkami szybko przestaje mieć sens ekonomiczny. Jeśli bezpłatna edycja jest w danym momencie dostępna, należy przeczytać, czego w niej nie ma: zdalnego zarządzania, liczby maszyn, integracji z vCenter, dostępu do poprawek. Te ograniczenia zmieniają się między wersjami, więc „kiedyś było darmowe” nie jest argumentem projektowym. ^[1]

Koszt ukryty bywa większy niż licencja. Przeniesienie sześciu maszyn, przebudowa sieci mostków, nauka ZFS i tydzień dopinania kopii potrafią zjeść więcej wieczorów niż roczna subskrypcja, której i tak nikt w domu nie kupi. Dlatego decyzja finansowa powinna obejmować czas migracji i ryzyko przestoju usług, nie tylko wiersz „0 zł” przy Proxmoxie.

Obsługa maszyn wirtualnych, kontenerów i usług domowych

Oba hypervisory dobrze prowadzą typowe maszyny z Linuksem i Windowsem: sterowniki virtio albo VMware Tools, snapshoty, zmiana przydziału CPU i RAM, przekazywanie dysków. Różnica, którą w domu czuć najszybciej, to natywne LXC w Proxmoxie. Lekki kontener na Pi-hole, reverse proxy albo prosty serwis w Debianie zużywa mniej pamięci niż pełna maszyna z własnym jądrem i potrafi wystartować w kilka sekund.

Nie wszystko powinno iść do LXC. Aplikacje wymagające własnego jądra, specyficznych modułów, pełnej izolacji albo oficjalnego wsparcia tylko jako maszyna wirtualna — zostają na KVM. Windows, Home Assistant w wariancie, który ma dostać własne urządzenia USB, oraz systemy „nie ruszaj, bo działa od trzech lat” zwykle lepiej czują się jako VM. ESXi nie oferuje odpowiednika LXC; lekkie usługi i tak lądują w małej maszynie z Dockerem albo w osobnym hoście. To działa, ale zjada RAM, którego w serwerze domowym nigdy nie ma w nadmiarze.

Szablony i klony skracają powtarzalne stawianie środowisk testowych. W Proxmoxie szablon maszyny albo kontenera da się przygotować lokalnie, bez vCenter. W ESXi podstawowe klonowanie bywa ograniczone edycją; wygodna biblioteka szablonów często zakłada komponenty, których w domu nie ma. Jeśli laboratorium polega na częstym tworzeniu i kasowaniu systemów, ta różnica waży więcej niż teoretyczna wydajność hypervisora.

Panel administracyjny, automatyzacja oraz krzywa nauki

Interfejs Proxmox jest gęsty: węzeł, storage, sieć, zapora, replikacja, uprawnienia, zadania w tle. Po kilku wieczorach staje się przewidywalny, ale początek wymaga zrozumienia, czym różni się mostek vmbr0 od karty fizycznej i dlaczego ZFS nie jest „kolejnym folderem na dysku”. Osoby po ESXi często szukają odpowiednika znanych kreatorów i irytują się, że część odpowiedzi leży w dokumentacji Debiana, nie tylko w wiki Proxmoxa.

ESXi w podstawowym zakresie bywa szybszy do pierwszego sukcesu, szczególnie gdy datastore jest lokalny, a sieć to jeden vSwitch. Krzywa wygina się później: gdy trzeba zautomatyzować tworzenie maszyn, spiąć więcej hostów albo oprzeć kopie o narzędzia oczekujące vCenter. API i PowerCLI są dojrzałe, ale w domu częściej zostają niewykorzystane. Proxmox ma API, CLI i szerokie użycie w skryptach społeczności; automatyzacja jest bliżej zwykłego Linuksa, co pomaga, jeśli i tak powstają własne skrypty kopii albo powiadomień.

Krzywa nauki nie jest wadą, jeśli jest jednorazowa. Gorzej, gdy co kwartał dochodzi nowa zależność licencyjna, której nie da się „nauczyć”, bo zależy od oferty. W Proxmoxie trudność jest techniczna i powtarzalna. W ESXi po Broadcom trudność bywa organizacyjna: konto, uprawnienie do pobrania, zgodność wersji z posiadaną licencją.

Wydajność, sprzęt i zgodność urządzeń

Narzut samego hypervisora rzadko jest wąskim gardłem domowego serwera. Znacznie częściej ogranicza RAM, kolejka dysków SATA, brak SSD pod systemy z bazą danych albo jedna karta sieciowa 1 Gb/s, przez którą idzie jednocześnie kopia, multimedia i zarządzanie. Porównywanie „który hypervisor jest szybszy” bez pomiaru I/O i bez sensownego przydziału zasobów prowadzi do wniosków, których nie da się powtórzyć na własnym sprzęcie.

Różnica sprzętowa jest realna gdzie indziej. ESXi trzyma się listy zgodności: konsumenckie karty Realtek, niektóre kontrolery RAID z rynku wtórnego i egzotyczne NIC-i potrafią nie wystartować albo działać niestabilnie. Proxmox, stojąc na jądrze Linuksa i Debianie, częściej przyjmuje taki sprzęt od razu albo po doinstalowaniu firmware. To nie jest gwarancja — passthrough GPU, kontrolery dysków w trybie IT oraz Wi-Fi jako interfejs zarządzania pozostają kapryśne na obu platformach — ale próg wejścia dla typowej płyty ATX bywa niższy.

Przekazywanie urządzeń do maszyny (USB do Home Assistanta, karta graficzna do stacji roboczej, kontroler dysków do TrueNAS) wymaga IOMMU, poprawnych grup i często kompromisów. Na Proxmoxie dokumentacja społeczności jest gęsta właśnie dlatego, że ludzie robią to na płytach konsumenckich. Na ESXi te same sztuczki bywają możliwe, lecz wsparcie i przewidywalność po aktualizacji są słabsze poza sprzętem z HCL. Jeśli passthrough jest warunkiem projektu, warto sprawdzić konkretną płytę i wersję BIOS-u przed wyborem platformy, a nie po migracji danych.

Kiedy Proxmox VE rozwiązuje problem lepiej niż ESXi

Homelab z wieloma małymi usługami i eksperymentami

Proxmox układa się naturalnie tam, gdzie na jednym hoście żyje kilkanaście drobnych ról: Home Assistant, Pi-hole albo AdGuard, Vaultwarden, Jellyfin, reverse proxy, maszyna do testów aktualizacji dystrybucji, okazjonalny Windows i kilka kontenerów z własnymi skryptami. LXC obniża koszt pamięci tych drobiazgów, a pełne VM zostają dla systemów, które naprawdę potrzebują własnego jądra.

Eksperymenty też są tańsze operacyjnie. Klon kontenera, snapshot przed ryzykowną zmianą konfiguracji i powrót do stanu sprzed godziny nie wymagają dokładania licencjonowanego centrum zarządzania. Warto tylko oddzielić „laboratorium, które wolno zepsuć” od usług, których brak w sobotę oznacza zimny dom albo niedostępne pliki. Osobna maszyna albo przynajmniej osobny storage i osobna polityka snapshotów ograniczają sytuację, w której test nowej wersji aplikacji kasuje jedyną kopię konfiguracji.

Docker może zostać wewnątrz jednej maszyny albo wybranych kontenerów LXC, ale nie musi zastępować hypervisora. Próba upchnięcia wszystkiego w jednym Dockerze na gołym hoście upraszcza start i komplikuje izolację, kopie oraz restarty. Proxmox daje warstwę pod spodem: jedne usługi w LXC, inne w VM z Dockerem, bez obowiązku wybierania tylko jednej szkoły.

Serwer domowy oparty na ZFS, dyskach lokalnych i kopiach zapasowych

Jeśli dane mają leżeć na lokalnych dyskach, a nie na macierzy z własnym kontrolerem i wsparciem producenta, ZFS w Proxmoxie jest konkretną odpowiedzią, nie ozdobnikiem. Pule lustrzane albo RAIDZ, scrub, kompresja i snapshoty datasetów dają kontrolę nad integralnością, której „folder na datastore VMFS” sam z siebie nie zapewni. Trzeba jednak rozumieć zasady: nie mieszać sprzętowego RAID z ZFS, zostawiać RAM na cache, nie zapełniać puli pod korek i nie traktować snapshotu jako jedynej kopii.

Proxmox Backup Server, nawet na drugim, skromniejszym komputerze albo wydzielonej maszynie z osobnymi dyskami, domyka ten obraz. Kopie przyrostowe, weryfikacja i przywracanie pojedynczych maszyn są bliższe temu, czego homelab potrzebuje, niż ręcznego kopiowania plików VMDK na udział sieciowy. ESXi też da się backupować — narzędziami zewnętrznymi albo skryptami — ale spójny, otwarty zestaw „hypervisor plus ZFS plus PBS” rzadziej wymaga dokładania płatnego ogniwa tylko po to, by odzyskać jedną maszynę po błędnej aktualizacji.

Wyjątek jest ważny: jeśli pliki domowe już żyją na sprawdzonym NAS-ie z własnymi migawkami, a hypervisor ma tylko uruchamiać maszyny, ZFS na hoście Proxmox nie jest obowiązkowy. Lokalny dysk SSD na systemy i udział NFS albo iSCSI na dane potrafią być prostsze. Platforma nie powinna wymuszać przebudowy pamięci masowej, która już spełnia swoją rolę.

Czego unikać, zanim platforma zacznie rozwiązywać ten sam problem od nowa

Najczęstszy błąd nie polega na złym hypervisorze, tylko na migracji zrobionej w jeden wieczór, bez drogi powrotu. Stary host ESXi bywa jedyną działającą kopią konfiguracji sieci, dysków i maszyn. Wymazanie go „bo Proxmox już wstaje” zamienia wybór licencyjny w awarię domową. Sensowny finał wygląda odwrotnie: nowa platforma musi najpierw przywrócić jedną ważną maszynę na osobnym dysku albo drugim komputerze, a dopiero potem wolno ruszać system, który od miesięcy trzyma Home Assistanta i pliki.

Druga pułapka to przenoszenie nawyków jeden do jednego. Maszyna z ESXi nie staje się „taka sama” po zmianie formatu dysku. Sterowniki parawirtualne, kolejność interfejsów i sposób podpięcia USB potrafią zmienić start systemu, nawet jeśli plik dysku jest nienaruszony. Warto więc migrować najpierw usługę, której brak da się przeżyć przez godzinę, a nie jedyną instancję, od której zależy ogrzewanie albo dostęp do dokumentów.

Decyzje, które wyglądają jak oszczędność, a dokładają pracy

• Nie stawiaj nowego hosta na jedynym dysku z danymi. System, maszyny i kopie powinny dać się rozdzielić, nawet jeśli na start są to tylko dwa nośniki.
• Nie oceniaj platformy po instalacji „na sucho”. Liczy się import jednej prawdziwej maszyny, start po restarcie hosta i przywrócenie z kopii zrobionej już na nowym zestawie.
• Nie dokładaj klastra, Ceph albo drugiej lokacji tylko dlatego, że panel to umożliwia. Jeden host z jasnym storage i sprawdzonym odtwarzaniem rozwiązuje domowy problem lepiej niż architektura, której nikt nie będzie doglądał.
• Nie zostawiaj ESXi „na wszelki wypadek” bez aktualnego opisu, jak wrócić do sieci i datastore. Martwy plan wycofania jest gorszy niż świadoma rezygnacja ze starego hosta.
• Nie traktuj braku opłaty za Proxmox jako braku obowiązków. Kanał aktualizacji, firmware płyty i własne skrypty nadal wymagają okna serwisowego i notatki, co zostało zmienione.

Podobnie myli się kierunek, gdy ktoś zostaje przy ESXi wyłącznie ze strachu przed Linuksem, a jednocześnie nie ma już legalnej, powtarzalnej ścieżki pobrania obrazu i poprawek. Odwlekanie decyzji nie jest neutralne: host bez aktualizacji też jest wyborem, tylko rzadko nazwanym wprost.

Kiedy ESXi nadal zamyka sprawę lepiej niż przeprowadzka

Proxmox nie jest odpowiedzią na każdy domowy serwer, który dotknęły zmiany po stronie VMware. Jeśli host służy głównie do utrzymania kilku maszyn Windows, a cały warsztat — szablony, monitoring, kopie, procedury z pracy — już kręci się wokół vSphere, przeprowadzka może kosztować więcej wieczorów, niż zysk daje niezależność licencyjna. W takim układzie problemem nie jest „zły hypervisor”, tylko rozjazd między tym, co stoi w domu, a tym, czym człowiek naprawdę umie administrować pod presją awarii.

Zostać warto też wtedy, gdy sprzęt jest na liście zgodności, datastore jest prosty, a dostęp do używanej wersji i poprawek jest dziś potwierdzony, nie tylko pamiętany z czasów darmowego ESXi. Domowy serwer nie musi być poligonem. Jeśli celem jest powtórzenie firmowego schematu jeden do jednego — te same narzędzia, te same pojęcia, ten sam sposób stawiania maszyny — ESXi nadal skraca drogę do wyniku, o ile warunek licencyjny nie wraca co kwartał jako niespodzianka.

Słabszy powód to „może kiedyś się przyda w CV”. Nauka pod pracę ma sens, gdy jest regularna: laboratorium z aktualnym vCenter, zadaniami i świadomie opłaconą albo formalnie dostępną licencją. Sam samotny host bez centrum zarządzania uczy coraz mniej z tego, co w pracy naprawdę boli, a jednocześnie zostawia w domu ten sam kłopot z kontem i uprawnieniami.

Rekomendacja: wybierz platformę według tego, co ma przestać psuć weekend

Dla większości domowych serwerów, które dotąd stały na ESXi dlatego, że „dało się za darmo i działało”, rozsądniejszym domknięciem jest Proxmox VE. Rozwiązuje pierwotny problem: platformę da się uruchomić i aktualizować bez czekania, czy dawny darmowy model jeszcze obowiązuje. Subskrypcja zostaje opcją dla repozytorium enterprise i wsparcia, a nie kartą wstępu do własnego sprzętu.

Zostaw ESXi, jeśli świadomie płacisz za przewidywalny dostęp albo host jest przedłużeniem środowiska vSphere, którego nie chcesz rozbijać. W każdym innym przypadku przeprowadzka ma sens tylko z osobnym dyskiem na próbę, jedną odtworzoną maszyną i kopią, którą da się przywrócić, zanim stary system zniknie. To jest praktyczny finał, nie wyścig hiperwizorów: wygrywa ten zestaw, przy którym za rok nie trzeba będzie znowu sprawdzać, czy wolno pobrać poprawkę do własnego serwera.

Przykład: jeden host, dwie role i decyzja podjęta na osobnym dysku

U Kowalskich serwer nie był „laboratorium”. Na ESXi stał Home Assistant z przekazanym USB, udział z dokumentami i jedna maszyna, na której żona trzymała skany umów. Obok żyła testowa instancja, której zniknięcie na dobę nikogo nie obchodziło. Problem nie brzmiał „który hypervisor jest nowocześniejszy”, tylko: czy w sobotę da się sprawdzić nową platformę tak, żeby w niedzielę rano ogrzewanie i pliki nadal wstawały ze starego hosta.

Zamiast przenosić wszystko, wyjęli z szuflady nieużywany SSD i postawili na nim próbny Proxmox, bez ruszania datastore ESXi. Najpierw odtworzyli maszynę testową, nie produkcyjną. Potem zrobili restart całego komputera próbnego i sprawdzili, czy interfejsy wracają w tej samej kolejności oraz czy maszyna dostaje adres, którego reszta domu się spodziewa. Dopiero gdy ten obieg — import, restart hosta, start usługi — przeszedł dwa razy z rzędu, przenieśli jedną rolę, której brak przez godzinę dało się przeżyć. Home Assistant i dokumenty zostały na starym systemie do czasu, aż kopia z nowego zestawu dała się otworzyć na innym nośniku.

Krótka ścieżka, która nie kasuje drogi powrotu

1. Zapisz, która usługa może zniknąć na jeden wieczór, a która nie może zniknąć wcale.
2. Postaw nową platformę na osobnym dysku. Starego datastore nie formatuj i nie „porządkuj”.
3. Przenieś wyłącznie usługę testową. Po restarcie hosta sprawdź adres, dysk i to, czy usługa naprawdę odpowiada, a nie tylko świeci w panelu.
4. Zrób kopię już na nowym zestawie i przywróć ją na bok, zanim ruszysz cokolwiek, od czego zależy dom.
5. Zostaw stary host uruchamialny tak długo, aż nowa ścieżka przeżyje zwykły tydzień, nie tylko sobotni test.

W tym domu ESXi nie przegrał „na funkcje”. Przestał być potrzebny w chwili, gdy nowy host samodzielnie wstał po restarcie, a odtworzona maszyna nie wymagała zgadywania, który dysk jest którym. Gdyby import testowej maszyny wywrócił sieć albo nie dało się wrócić do starego datastore, przeprowadzka miałaby się skończyć w tym samym wieczorze — bez ruszania Home Assistanta. To jest kryterium, którego nie widać w tabeli: decyzja jest dobra dopiero wtedy, gdy da się ją cofnąć bez szukania kabla i hasła sprzed dwóch lat.

Co warto zapamiętać

• Zmiany Broadcom zwiększyły niepewność dotyczącą licencjonowania, pobierania instalatorów i dostępu do aktualizacji VMware.
• Proxmox VE oferuje bezpłatne używanie samej platformy, maszyny KVM/QEMU, kontenery LXC oraz integrację z rozwiązaniami takimi jak ZFS.
• ESXi nadal ma sens tam, gdzie potrzebne są dojrzałe rozwiązania ekosystemu vSphere i istnieje uzasadnienie dla komercyjnego wsparcia.
• W domowym serwerze ważniejsze od liczby funkcji enterprise są przewidywalne koszty, możliwość odtworzenia środowiska i łatwy dostęp do aktualizacji.
• Przed migracją lub pozostaniem przy ESXi trzeba sprawdzić bieżące warunki licencyjne, kompatybilność sprzętu oraz przygotować kopie zapasowe.

Źródła

• [1] VMware by Broadcom – FREQUENTLY ASKED QUESTIONS: June 2025 — VMware vSphere 9
• [2] Proxmox – Pricing for Subscriptions Plans — Proxmox Virtual Environment
• [3] Proxmox – Proxmox VE Administration Guide