Osoba, która stawia Proxmox VE w domu, zwykle chce jednego: mieć własny, elastyczny „serwer w szafce”, który uruchamia kilka usług równocześnie, jest względnie bezobsługowy i nie wywraca domowej sieci do góry nogami. Kluczowe jest też, aby całość dało się zainstalować samodzielnie, bez wieloletniego doświadczenia jako administrator.
Proxmox VE pozwala z jednego fizycznego komputera zrobić wygodną platformę do uruchamiania wielu maszyn wirtualnych (KVM) i lekkich kontenerów (LXC). To sposób na opanowanie wirtualizacji „na żywym organizmie”: w domu, na własnym sprzęcie, ale z rozwiązaniami stosowanymi w małych i średnich firmach.
Czym jest Proxmox VE i po co go stawiać w domu
Proxmox VE w skrócie: co to za system
Proxmox VE (Virtual Environment) to dystrybucja typu hypervisor, czyli system operacyjny stworzony specjalnie do uruchamiania maszyn wirtualnych i kontenerów. Bazuje na Debianie, wykorzystuje hypervisor KVM (pełna wirtualizacja) oraz LXC (kontenery systemowe) i ma wygodny panel WWW do zarządzania wszystkim z poziomu przeglądarki.
Najważniejsze cechy z perspektywy domowego użytkownika to:
Web GUI – panel pod adresem https://adres-serwera:8006, w którym da się zrobić większość rzeczy bez dotykania konsoli.
Open source – system jest darmowy, kod dostępny, płatne są jedynie subskrypcje wsparcia i stabilne repozytoria enterprise.
KVM + LXC – pełne maszyny wirtualne (np. Windows, Linux) oraz lżejsze kontenery (np. małe usługi linuksowe) na jednym hostcie.
Snapshoty, backupy, klony – mechanizmy upraszczające testowanie, cofanie zmian i ochronę przed własnymi błędami.
Proxmox przypomina z wyglądu „panel do serwera w firmie”, ale dzięki temu, że bazuje na Debianie, zachowuje się przewidywalnie i daje możliwość wejścia „pod maskę”, kiedy pojawi się taka potrzeba. Dla osoby, która zna już trochę Linuxa, jest to bardzo logiczny krok dalej.
Typowe domowe zastosowania Proxmox VE
Domowy serwer z Proxmoxem może pełnić wiele ról jednocześnie. Zamiast mieć osobną maszynę do każdego zadania, wystarczy jedna, sensownie rozplanowana, z kilkoma VM-kami i kontenerami.
Popularne scenariusze:
Serwer plików i kopii zapasowych – np. VM z TrueNAS/OMV albo kontener z Sambą/NFS na dane rodzinne, zdjęcia, dokumenty.
Home Assistant i automatyka domowa – jedna VM lub kontener z HA, broker MQTT, Node-RED, Zigbee2MQTT, itd.
Serwer multimediów – VM lub LXC z Jellyfin/PLEX/Emby, serwarem DLNA, repozytorium filmów i muzyki.
Laboratorium do nauki – kilka testowych VM: różne dystrybucje Linuxa, Windows Server, firewall (OPNsense/pfSense), bazy danych.
Usługi sieciowe – własny DNS, VPN, Pi-hole/adguard, mały serwer WWW, Git, prosty system do ticketów itp.
Na jednym fizycznym komputerze możesz więc utrzymywać praktycznie cały „domowy ekosystem serwerowy”, a do tego testować nowe rzeczy bez ryzyka popsucia wszystkiego, co już działa.
Wirtualizacja vs „goły Linux z usługami”
Klasyczne podejście: na jednym serwerze z Debianem/Ubuntu instalujesz wszystko – Sambę, Dockera, serwer WWW, Home Assistanta, bazy danych. Przez pierwszy rok jest pięknie, a potem aktualizacja jakiegoś pakietu psuje zależności, coś się gryzie z nową wersją kernela, a przy zmianie sprzętu trzeba kombinować z migracją usług pojedynczo.
Wirtualizacja z Proxmoxem rozwiązuje wiele takich problemów:
Izolacja – każda usługa ma własny system (VM lub LXC). Awaria jednego systemu nie kasuje wszystkiego.
Snapshoty – przed większymi zmianami robisz szybki snapshot VM/contenera. Jeśli aktualizacja pójdzie źle, wracasz jednym kliknięciem.
Łatwiejsza migracja – przeniesienie VM-ki na inny serwer to często kopiowanie jednego pliku + konfiguracja.
Eksperymenty bez stresu – testujesz nowy soft w osobnej VM-ce; jak się nie spodoba, kasujesz bez śladu.
Mit: „po co mi wirtualizacja, jak mam Dockera”. Rzeczywistość: kontenery aplikacyjne są świetne, ale nie zastąpią pełnej izolacji systemów tam, gdzie ważna jest separacja sieciowa, różne jądra albo chociażby całkowicie różne systemy (Windows vs Linux). Proxmox pozwala połączyć oba światy – VM dla „ciężkich” przypadków i kontenery (również dockerowe) tam, gdzie zależy na lekkości.
Proxmox tylko dla firm? Raczej także dla piwnicy i szafy
Dość częsty mit: „Proxmox jest skomplikowany i przeznaczony tylko do dużych firm, do domu wystarczy Raspberry Pi”. Prawda jest bardziej przyziemna. Proxmox ma możliwości klastra, HA i storage rozproszonego, ale w wersji „single node” sprawdza się świetnie jako solidny, pojedynczy domowy serwer.
Rzeczywistość wygląda tak: jeśli jesteś w stanie zainstalować dowolną dystrybucję Linuxa i ustawić sieć, poradzisz sobie z Proxmoxem. Interfejs WWW prowadzi za rękę przy większości operacji, a dokumentacja i społeczność są bardzo aktywne. Zostaje więc tylko jedno pytanie: czy masz sprzęt, który rozsądnie to udźwignie.
Wymagania sprzętowe i planowanie domowego serwera
Minimalne i zalecane parametry sprzętu
Proxmox VE sam w sobie nie jest bardzo zasobożerny, ale VM-ki i kontenery już tak. Z tego powodu ocena „minimalnych wymagań” musi brać pod uwagę nie tylko system, ale też to, co na nim uruchomisz.
Praktyczne minimum dla domowego setupu:
CPU: 2–4 rdzenie z VT-x (Intel) lub AMD-V, najlepiej z obsługą VT-d/IOMMU (przydatne do passthrough).
RAM: absolutne minimum do sensownego startu to 8 GB, ale rozsądnie celować w 16 GB lub więcej.
Dyski: SSD (co najmniej 120–240 GB) na system i VM-ki, HDD na duże magazyny danych, jeśli potrzebne.
Karta sieciowa: przynajmniej 1 Gbit, najlepiej chipset Intela (dobrze wspierany w Linuksie).
System Proxmox VE, bez VM-ek, zmieści się i na 2 GB RAM, ale w praktyce już jedna czy dwie maszyny zużyją znacznie więcej. Dla zestawu: Home Assistant, serwer plików, mały serwer WWW i np. VM z Windows do okazjonalnego użycia, 16 GB RAM i 4 rdzenie CPU to bardzo wygodna baza.
Jak sprawdzić wsparcie wirtualizacji w CPU i BIOS
Zanim zaczniesz, upewnij się, że twój procesor wspiera sprzętową wirtualizację i że jest ona włączona w BIOS/UEFI.
Sprawdzenie CPU (na istniejącym systemie Linux):
Intel: obecność flagi vmx w /proc/cpuinfo.
AMD: obecność flagi svm.
W BIOS/UEFI szukaj opcji typu:
Intel Virtualization Technology (VT-x),
Intel VT-d lub IOMMU (dla passtrough),
SVM (w przypadku AMD).
Jeśli nie masz jeszcze systemu na tym sprzęcie, najbezpieczniej sprawdzić model procesora w dokumentacji producenta (Intel ARK, specyfikacje AMD) i upewnić się, że wspiera wirtualizację. Bez tego Proxmox zadziała, ale nie wykorzystasz KVM, a to mija się z celem.
Stary PC, NUC, miniPC czy używany serwer – co wybrać
Do instalacji Proxmox VE w domu możesz wykorzystać różne platformy. Każda ma swoje plusy i wady.
Najpopularniejsze opcje:
Stary desktop/PC – najtańsza i najprostsza ścieżka. Często wystarczy do pierwszych eksperymentów. Słabe punkty: głośne chłodzenie, wyższy pobór mocy, ograniczona liczba dysków w obudowie.
MiniPC / NUC – małe, ciche, energooszczędne, zwykle 2,5″ SSD + NVMe. Idealne, gdy priorytetem jest cisza i mały pobór prądu, ale przy większej liczbie dysków bywa problem z miejscem.
Używany serwer rack (Dell/HP/Lenovo) – kusząco tani w zakupie, ogromna skalowalność, sporo RAM i dysków. Minusy w domu są brutalne: hałas jak odkurzacz, spory pobór prądu, potrzeba miejsca (szafa/rack).
Małe serwery typu micro/mini tower – kompromis: serwerowe funkcje, ale w obudowie bardziej domowej, z cichszymi wentylatorami.
Jeśli serwer stoi w pokoju lub w szafie wnękowej, małe, energooszczędne platformy (NUC, miniPC, kompaktowy desktop) często wygrywają z dużymi serwerami rackowymi, nawet jeśli są słabsze. Mniejszy rachunek za prąd i cisza zwykle są ważniejsze niż posiadanie 16 fizycznych rdzeni.
Hałas, pobór prądu i „czynnik domowy”
Domowy serwer to nie tylko cyferki w benchmarkach. W praktyce ważniejsze od „ile ma rdzeni” bywa:
Poziom hałasu – serwer rack w salonie to szybka droga do konfliktu z resztą domowników.
Pobór prądu – sprzęt ciągle włączony 24/7, więc różnica między 20 W a 80 W robi dużą różnicę w rachunku rocznym.
Miejsce i wentylacja – obudowa musi mieć przepływ powietrza; upchnięcie komputera w zamkniętej szafce bez wentylacji to proszenie się o problemy.
Częsty błąd: kupno potężnego, ale starego serwera, który w idle ciągnie kilkadziesiąt watów więcej niż nowoczesny miniPC. Różnica w kosztach energii w ciągu roku potrafi zrównać się z ceną nowszego, spokojniejszego sprzętu.
Czy do Proxmoxa trzeba potężnej maszyny – mit a rzeczywistość
Mit: „Proxmox to platforma dla wielkich serwerów, w domu bez 64 GB RAM nie ma sensu”. Rzeczywistość: większość domowych zastosowań (kilka lekkich usług, serwer plików, Home Assistant, drobne laby) spokojnie działa na 8–16 GB RAM.
Przykładowy, realny zestaw na 16 GB RAM:
LXC z serwerem plików (Samba/NFS).
LXC lub VM z Home Assistant.
LXC z Pi-hole/AdGuard Home.
Jedna VM z Linuxem do zabawy lub drobnej strony WWW.
Takie środowisko działa płynnie nawet na stosunkowo słabym procesorze (np. starsze i5, AMD Ryzen 3) i nie wymaga ogromnych zasobów. Dopiero jeśli planujesz kilka ciężkich VM z Windows, bazy danych pod spory ruch lub wirtualizację routera z IDS/IPS, dodatkowy RAM i mocniejsze CPU stają się faktycznie konieczne.
Źródło: Pexels | Autor: Brett Sayles
Przygotowanie nośnika instalacyjnego i ustawienia BIOS/UEFI
Pobieranie obrazu ISO Proxmox VE i weryfikacja
Proxmox VE pobiera się jako obraz ISO z oficjalnej strony. Po ściągnięciu pojawia się pokusa, aby od razu wrzucić ISO na pendrive i instalować. Warto zrobić jeszcze jeden krok: sprawdzić sumę kontrolną (SHA256) udostępnioną obok pliku.
Dlaczego to istotne, nawet w domu:
Uszkodzone pobranie (błąd połączenia, przerwany transfer) może dać dziwne, trudne do wyjaśnienia błędy instalatora.
Weryfikacja SHA256 potwierdza, że plik nie jest uszkodzony i zgadza się z tym, co wystawił producent.
W systemie Linux/Unix można użyć polecenia:
sha256sum proxmox-ve_*.iso
Na Windows można wykorzystać np. wbudowane narzędzie CertUtil lub dedykowany program do obliczania sum kontrolnych. Wynik porównuje się z wartością podaną na stronie Proxmoxa.
Tworzenie bootowalnego pendrive’a: balenaEtcher i Rufus
Do przygotowania pendrive’a instalacyjnego można użyć wielu narzędzi. Dwa najpopularniejsze to balenaEtcher i Rufus.
balenaEtcher (Windows/Linux/macOS):
Wybierz obraz ISO Proxmoxa.
Wskaż pendrive (uważaj, aby nie wybrać złego dysku).
Kliknij „Flash” i poczekaj na zakończenie.
Etcher zwykle sam wybiera odpowiednie ustawienia (MBR/GPT) i rzadko sprawia problemy.
Rufus (Windows):
Wybierz urządzenie (pendrive).
Wybierz ISO Proxmoxa.
Ustawienia trybu bootowania i kolejności startu
Po przygotowaniu pendrive’a kolejnym krokiem jest dopilnowanie, żeby komputer faktycznie z niego startował. Większość współczesnych płyt ma tryb UEFI, często z włączonym Secure Bootem.
Proxmox VE nie wspiera Secure Boot „z pudełka”, więc na czas instalacji funkcję tę trzeba wyłączyć w BIOS/UEFI. Zwykle znajduje się ona w zakładkach „Boot”, „Security” albo „Authentication”. Pozycje, których trzeba szukać:
Secure Boot – ustaw na Disabled.
Boot Mode / UEFI/Legacy – najlepiej wybrać czysty UEFI, jeśli sprzęt na to pozwala.
CSM (Compatibility Support Module) – przy instalacji w trybie UEFI często można go wyłączyć.
Potem przełącz kolejność bootowania tak, aby pendrive znalazł się na pierwszym miejscu. Niektóre płyty oferują jednorazowe menu bootowania pod klawiszem typu F8, F10, F11 lub F12 – to wygodne, gdy nie chcesz na stałe mieszać w kolejności startu.
Pojawia się tu dość częsty mit: „lepiej instalować na Legacy, bo jest mniej problemów”. Rzeczywistość: UEFI działa stabilnie, a mniej kombinacji z MBR/GPT wychodzi na plus. Legacy ma sens głównie na bardzo starym sprzęcie, gdzie UEFI jest niedopracowane.
Konfiguracja kontrolera SATA/NVMe i trybu AHCI/RAID
Przed startem instalatora warto sprawdzić, w jakim trybie działa kontroler dysków. W wielu gotowych komputerach fabrycznie ustawiony jest pseudo-RAID (Intel RST, „FakeRAID”), który pod Linuksem bywa problematyczny.
Najbezpieczniejszy dla Proxmoxa jest tryb AHCI dla dysków SATA. Jeśli BIOS pokazuje coś w stylu „RAID On”, „Intel RST”, przełącz na „AHCI”. Nie dotyczy to sprzętowych kontrolerów RAID w serwerach klasy enterprise – tam sytuacja jest bardziej złożona i zależy od tego, czy będziesz używać ZFS, czy sprzętowego RAID-u.
Istotny szczegół przy domowych serwerach:
Jeśli planujesz ZFS – unikaj sprzętowego RAID, ustaw dyski jako JBOD lub „HBA mode”, tak aby system widział każdy dysk osobno.
Jeśli zapis danych powierzysz wyłącznie kontrolerowi RAID – nie rób nad tym dodatkowego ZFS-a w RAIDZ. Podwójna warstwa RAID kończy się trudnym do zarządzania bałaganem.
Wyłączenie zbędnych urządzeń i podstawowe „porządki” w BIOS
Przy sprzęcie, który ma pełnić rolę domowego serwera 24/7, sensowne jest pozbycie się wszystkiego, co niepotrzebne i generuje potencjalne problemy:
Porty szeregowe / LPT – wyłącz, jeśli nie używasz starszych urządzeń.
Zintegrowane audio – zwykle zbędne w serwerze.
Kartę Wi-Fi – jeśli i tak używasz połączenia kablowego.
Równocześnie dobrze jest aktywować przydatne funkcje:
Wake on LAN (WoL) – przydaje się do zdalnego wybudzania serwera.
Power on after power loss – automatyczny start po zaniku zasilania.
VT-d / IOMMU – jeśli planujesz passthrough kart (np. GPU, USB).
Takie „sprzątanie” w BIOS nie jest obowiązkowe, ale w praktyce zmniejsza liczbę niespodzianek i minimalnie obniża pobór energii.
Proces instalacji Proxmox VE krok po kroku
Start instalatora i wybór podstawowych opcji
Po udanym starcie z pendrive’a pojawi się ekran rozruchowy Proxmoxa. W typowym scenariuszu wystarczy wybrać opcję Install Proxmox VE i zatwierdzić.
Instalator załaduje jądro i przejdzie do zgody licencyjnej. Po jej akceptacji dochodzi się do pierwszego ważnego okna: wyboru docelowego dysku i systemu plików.
Wybór dysku systemowego i typu instalacji (ZFS vs ext4/xfs)
Na domowym serwerze kluczowe jest to, gdzie będzie zainstalowany sam Proxmox. Klasyczna opcja to pojedynczy SSD z systemem plików ext4 lub xfs. Alternatywą jest instalacja bezpośrednio na ZFS.
Najczęstsze warianty:
Pojedynczy dysk SSD + ext4/xfs – prosto, stabilnie, mało kombinowania. Dobry wybór na pierwsze podejście.
Dwa SSD w RAID1 na ZFS – system i dane VM-ki na redundantnej parze. ZFS zapewnia sumy kontrolne i możliwość migawkowania.
System na małym SSD, dane na osobnym ZFS pool – wygodne, gdy masz szybki, mały dysk na system i większe dyski na magazyn maszyn.
Mit krąży po forach, że „na ZFS potrzebne jest minimum ECC, inaczej wszystko wybuchnie”. Rzeczywistość: ECC jest idealne, ale zwykły RAM nie wyklucza ZFS. Po prostu ryzyko wykrycia błędów pamięci przez ZFS będzie, ale ich naprawa może być utrudniona – w domowych warunkach i tak jednak ZFS bywa bezpieczniejszy niż brak sum kontrolnych w ogóle.
W instalatorze, po kliknięciu przycisku „Options” przy wyborze dysku, można zmodyfikować:
Typ systemu plików (ext4/xfs/ZFS).
Rozmiary partycji (jeśli chcesz ograniczyć np. LVM).
Poziom RAID dla ZFS (mirror, RAIDZ1 itd.).
Ustawienie kraju, strefy czasowej i układu klawiatury
Kolejne okno dotyczy lokalizacji. Ustawienie poprawnej strefy czasowej i układu klawiatury ma znaczenie m.in. dla logów, certyfikatów i wygody pracy w konsoli.
Country – wybierz swój kraj, np. „Poland”.
Time zone – np. „Europe/Warsaw”.
Keyboard layout – jeśli korzystasz z polskiego układu, wybierz „Polish” albo zostaw standardowy „US”, jeśli taką masz klawiaturę.
Zmiana tych parametrów po instalacji jest możliwa, ale skoro instalator już je pyta, lepiej zrobić to od razu dobrze.
Tworzenie hasła administratora i podanie adresu e-mail
Następny krok to konfiguracja podstawowego konta administracyjnego. Proxmox używa konta root do logowania w interfejsie webowym (przez realm „pam”). Instalator poprosi o:
Hasło – zadbaj, by było dłuższe niż 8 znaków i nie używaj oczywistości.
E-mail – adres, na który będą przychodziły powiadomienia systemowe (np. o błędach, backupach).
W domowych warunkach często pomija się prawdziwy e-mail albo ustawia coś w stylu „root@local”. To wygodne na start, ale jeśli planujesz poważniej używać Proxmoxa, lepiej podać realny adres, nawet prywatny, aby nie przeoczyć istotnych komunikatów.
Konfiguracja sieci – IP, maska, brama i DNS
Instalator poprosi o parametry sieciowe dla głównego interfejsu. To newralgiczny moment, bo od tych ustawień zależy, czy później w ogóle połączysz się z panelem webowym.
Typowy zestaw ustawień w domowej sieci:
Hostname (FQDN) – np. proxmox.local albo pve.domowa.lan.
IP address – najlepiej stałe, z podsieci twojego routera, np. 192.168.1.50.
Netmask – np. 255.255.255.0 (czyli /24).
Gateway – adres twojego routera, np. 192.168.1.1.
DNS server – może to być router (192.168.1.1) albo zewnętrzny DNS (np. 1.1.1.1, 8.8.8.8).
Mit bywa taki, że „najłatwiej zostawić DHCP”. Proxmox co prawda zadziała na IP z DHCP, ale szybko zaczyna się chaos, gdy serwer zmieni adres i nagle przestajesz trafiać w panel WWW. Stały adres IP jest dużo rozsądniejszy, szczególnie gdy później pojawi się więcej usług w sieci.
Ostatnie podsumowanie i rozpoczęcie instalacji
Na końcu instalator pokaże podsumowanie ustawień: dysku, sieci, hasła i lokalizacji. To ostatni moment, aby cofnąć się i poprawić błąd. Po zatwierdzeniu rozpocznie się właściwa instalacja, zwykle trwająca kilka–kilkanaście minut w zależności od szybkości dysku.
Po zakończeniu instalator poprosi o wyjęcie nośnika instalacyjnego i zrestartuje maszynę. Jeżeli kolejność bootowania w BIOS jest ustawiona poprawnie, komputer uruchomi się już z nowego systemu Proxmox VE.
Pierwsze logowanie do panelu webowego i podstawowa konfiguracja
Dostęp do interfejsu WWW przez HTTPS
Po pierwszym restarcie Proxmox wyświetli na konsoli adres URL do panelu zarządzania. Zwykle będzie to:
https://IP_SERWERA:8006/
Wystarczy w przeglądarce na innym komputerze w tej samej sieci wpisać ten adres, np. https://192.168.1.50:8006/. Przeglądarka najpewniej wyświetli ostrzeżenie o niezaufanym certyfikacie SSL – to normalne, bo Proxmox generuje samopodpisany certyfikat.
Ostrzeżenie trzeba świadomie zaakceptować (dodać wyjątek bezpieczeństwa), a następnie przejść dalej do strony logowania.
Logowanie jako root i wybór realm
Na ekranie logowania wprowadź:
Username: root
Password: hasło ustawione w instalatorze
Realm: Linux PAM standard authentication (domyślny)
Po poprawnym zalogowaniu otworzy się główny interfejs Proxmoxa z drzewem po lewej stronie (node, datacenter) i szczegółowymi zakładkami po prawej.
Wprowadzenie subskrypcji lub wyłączenie okna o braku subskrypcji
Użytkownicy domowi często dziwią się komunikatowi o braku ważnej subskrypcji. Proxmox ma model biznesowy oparty o płatny dostęp do repozytoriów enterprise i wsparcie komercyjne, ale sam system jest dostępny za darmo.
Jeśli nie masz subskrypcji, po zalogowaniu pojawi się okno dialogowe z informacją o jej braku. Wystarczy je zamknąć – funkcjonalnie system działa w pełnej wersji, różnica dotyczy głównie repozytoriów pakietów i wsparcia.
Podstawowa konfiguracja repozytoriów pakietów
Świeży Proxmox ma zwykle skonfigurowane repozytorium enterprise, które bez aktywnej subskrypcji będzie zgłaszało błędy przy aktualizacji. Aby korzystać z darmowego repozytorium „no-subscription”, trzeba wykonać kilka kroków (najwygodniej przez SSH lub konsolę w panelu).
Przykładowy schemat działań:
Zaloguj się na serwer (SSH lub konsola) jako root.
Wyłącz repozytorium enterprise, edytując plik:
/etc/apt/sources.list.d/pve-enterprise.list
i komentując linię z pve-enterprise (dodając # na początku).
Dodaj repozytorium „no-subscription”, np.:
deb http://download.proxmox.com/debian/pve bookworm pve-no-subscription
Uruchom aktualizację:
apt update
apt dist-upgrade
Wielu domowych użytkowników boi się aktualizacji „bo coś się popsuje”. Rzeczywistość jest taka, że nieaktualny hypervisor prędzej czy później sprawi więcej problemów niż ostrożne, ale regularne aktualizacje.
Ustawienie prawidłowego czasu i serwerów NTP
Prawidłowy czas systemowy jest kluczowy dla logów, certyfikatów SSL i replikacji. Proxmox standardowo używa systemd-timesyncd lub pakietu chrony/ ntp, zależnie od wersji.
W panelu można wejść w zakładkę Datacenter → Time i sprawdzić, czy NTP jest aktywny, oraz które serwery czasu są skonfigurowane. Dobrym pomysłem jest użycie serwerów takich jak:
pool.ntp.org
lokalny serwer czasu, jeśli taki posiadasz w sieci
Podstawowa konfiguracja sieci z poziomu GUI
Zakładka Node → System → Network pozwala przejrzeć i edytować interfejsy sieciowe. Po świeżej instalacji zobaczysz tam:
Interfejs fizyczny (np. enp3s0).
Most sieciowy vmbr0 – to przez niego maszyny wirtualne i kontenery będą wychodziły do sieci.
Dodanie dodatkowych interfejsów i VLAN-ów
Przy prostym domowym serwerze często wystarczy jeden most vmbr0, ale gdy sieć robi się bogatsza – pojawia się Wi-Fi mesh, VLAN-y z routera, osobne sieci dla IoT – dobrze rozdzielić ruch. Proxmox radzi sobie z tym bardzo sprawnie.
Typowy scenariusz: router (np. Mikrotik, OpenWrt, Unifi) wystawia kilka VLAN-ów, a jeden fizyczny port idzie do serwera Proxmox. Na tym porcie można utworzyć logiczne interfejsy VLAN i przypiąć je do osobnych mostów, do których trafią konkretne maszyny.
Podstawowy schemat konfiguracji z poziomu GUI (zakładka Node → System → Network):
Na interfejsie fizycznym (np. enp3s0) pozostaw ustawienia bez IP (będzie „surowym” nośnikiem VLAN-ów).
Dodaj interfejs typu VLAN, np. enp3s0.10, ustawiając:
VLAN Tag: numer VLAN z routera, np. 10.
Bridge ports: na razie puste.
Dodaj nowy bridge, np. vmbr10, i w polu Bridge ports wybierz enp3s0.10. Jeśli ten bridge ma mieć adres IP (np. sieć zarządzająca), ustaw go w IPv4/CIDR.
Od tego momentu w konfiguracji maszyny wirtualnej możesz wybrać, czy jej karta sieciowa ma wisieć na vmbr0, czy np. na vmbr10. Taki prosty podział często wystarcza, by oddzielić „gości” od prywatnej sieci lub sprzęt IoT od maszyn z danymi.
Częsty mit: „VLAN-y to tylko dla dużych firm”. W domu, gdzie serwer służy za NAS, serwer kamer, lab i platformę testów, logiczne rozdzielenie sieci daje więcej świętego spokoju niż najdroższy firewall, który wszystko trzyma w jednej płaskiej podsieci.
Tworzenie dodatkowych użytkowników i ról
Na start zwykle wszystko robi się jako root, ale prędzej czy później pojawia się potrzeba, by dać komuś dostęp do konkretnej VM-ki albo by oddzielić „bieżącą administrację” od konta głównego. Proxmox ma całkiem granularny system uprawnień.
Z panelu można przejść do Datacenter → Permissions i tam:
W zakładce Users dodać nowych użytkowników (realm pve albo np. LDAP/AD, jeśli integrujesz się z katalogiem).
W zakładce Roles podejrzeć gotowe role (np. PVEVMUser, PVEAdmin) lub stworzyć własne z określonym zestawem praw.
W zakładce ACL nadać uprawnienia na poziomie całego datacenter, pojedynczego noda lub nawet pojedynczej maszyny wirtualnej.
Praktyczny przykład: chcesz, by domownicy mogli tylko włączać/wyłączać swoje maszyny (np. osobne Windowsy), ale niczego nie konfigurowali. Tworzysz użytkownika, przypisujesz mu rolę PVEVMUser i nadajesz ACL tylko na konkretną VM. Root nadal ma pełnię praw, ale normalna praca odbywa się na mniej uprzywilejowanym koncie.
Włączenie 2FA dla konta root
Hasło to jedno, ale dostęp do panelu z internetu (nawet przez VPN) prosi się o dodatkowę ochronę. Proxmox obsługuje TOTP (Google Authenticator i podobne) oraz U2F/FIDO2.
Aby włączyć 2FA dla konta, można przejść do Datacenter → Permissions → Two Factor i dla użytkownika root@pam dodać metodę TOTP. Wygenerowany kod QR skanuje się aplikacją OTP na telefonie (np. Aegis, Authy, Google Authenticator), po czym przy każdym logowaniu podaje się kod z aplikacji.
Mit, który przewija się w domowych instalacjach: „Po co 2FA, przecież to tylko w domu i tylko przez LAN”. Wystarczy jedna błędna reguła na routerze, wystawiony reverse proxy albo przypadkowe przekierowanie portów, by panel stał się widoczny z internetu. Przy 2FA nawet przeciek hasła nie wystarczy do przejęcia hypervisora.
Konfiguracja dysków, ZFS i zarządzanie przestrzenią
Przegląd fizycznych dysków w GUI
Po instalacji, gdy podłączone są dodatkowe dyski (np. na dane), najpierw trzeba sprawdzić, co system tak naprawdę widzi. Najwygodniej zrobić to w zakładce Node → Disks.
W tej sekcji pojawi się lista urządzeń, np. /dev/sda, /dev/sdb, z informacją o pojemności, modelu, typie (HDD/SSD/NVMe) i aktualnym użyciu (czy istnieją już partycje). W klastrze labowym często używa się tanich, „odmieszanych” dysków – warto wtedy nazwać je sobie sensownie, choćby za pomocą etykiet lub notatki poza systemem, aby nie mylić „dysku z kamer” z „dyskiem z backupami”.
Tworzenie ZFS pool na dodatkowych dyskach
Jeśli system zainstalowany jest na jednym dysku (np. małym SSD), pozostałe można wykorzystać jako pool ZFS na dane i maszyny. Z poziomu GUI robi się to w kilka kliknięć.
W Node → Disks → ZFS można użyć przycisku Create: ZFS i ustawić:
Name – np. tank lub data.
Raid level – dla dwóch dysków najczęściej mirror, dla trzech–czterech domowo rozsądny jest RAIDZ1.
Disks – listę urządzeń, które trafią do poola.
Compression – domyślne lz4 jest lekkie i zwykle warto je zostawić.
Po utworzeniu pool pojawi się w zakładce Datacenter → Storage, ale jeśli nie – trzeba go tam dodać ręcznie jako nowy typ ZFS lub Directory (wskazując mount point). Od tej chwili można na nim trzymać dyski VM-ek, kontenery lub backupy, zgodnie z konfiguracją storage.
Domowy mit: „ZFS żre tyle RAM-u, że na 16 GB nawet nie ma co zaczynać”. Rzeczywistość jest bardziej łagodna – ZFS lubi RAM i wykorzysta go na cache, ale na małym serwerze działającym spokojnie z kilkoma VM-kami, przy rozsądnej konfiguracji ARC, daje się spokojnie używać. Gorzej jest, gdy pakujemy tam kilkadziesiąt głośnych usług i oczekujemy cudów od taniego sprzętu.
Dodawanie lokalnych magazynów LVM i Directory
Nie każdy potrzebuje ZFS. Do prostych zastosowań wystarczą klasyczne magazyny: LVM-thin na szybkie dyski VM i „directory storage” na pliki, ISO oraz backupy.
W zakładce Datacenter → Storage → Add dostępne są m.in.:
LVM-Thin – logiczny wybór, jeśli na dysku przygotujesz grupę woluminów LVM i chcesz mieć cienko przydzielane dyski dla maszyn (thin provisioning).
Directory – zwykły katalog na systemie plików, np. /mnt/data; dobry na template’y, ISO i backupy.
Przykładowy scenariusz na dysku HDD 4 TB:
Partycjonowanie dysku jako pojedynczy GPT, jedna duża partycja.
Utworzenie na tej partycji grupy LVM, np. vg_data.
W Proxmox dodanie magazynu typu LVM-Thin na vg_data z pulą thin_data.
Na potrzeby backupów można wydzielić część dysku jako osobny filesystem (ext4/xfs) i dodać go jako Directory, dzięki czemu snapshots i backupy nie będą mieszać się z produkcyjnymi dyskami VM-ów.
Konfiguracja przestrzeni na ISO, template’y i backupy
Żeby wygodnie zarządzać serwerem, dobrze mieć jasno zdefiniowane miejsca na:
obrazy ISO instalki różnych systemów,
szablony kontenerów LXC,
kopie zapasowe maszyn i kontenerów.
Domyślnie Proxmox tworzy magazyn local na systemowym dysku, gdzie lądują ISO i template’y, oraz (często) local-lvm na dyski VM-ów. W praktyce lepiej przenosić ciężkie rzeczy (backupy) na osobny dysk lub pool.
W Datacenter → Storage → Add → Directory można dodać katalog, np. /mnt/backup, i w sekcji Content zaznaczyć tylko VZDump backup file. W ten sposób Proxmox będzie trzymał kopie zapasowe na wybranym dysku, a nie zapychał systemowego SSD.
Podobnie z ISO – można mieć osobny magazyn typu Directory, przypisany tylko do ISO image i Container template, np. /mnt/iso. Dzięki temu łatwo kontrolować, co ile miejsca zabiera.
Tworzenie i planowanie backupów
Mając magazyn na backupy, można ustawić automatyczne zadania. W domowych warunkach często kończy się na „zrobię snapshot ręcznie”, a potem pierwsza awaria udowadnia, że jednak automatyzacja ma sens.
W zakładce Datacenter → Backup da się skonfigurować joby, które:
obejmują wybrane VM-ki i kontenery (albo wszystkie na danym nodzie),
korzystają z konkretnego magazynu backupów,
uruchamiają się wg harmonogramu (np. codziennie w nocy o 3:00),
wykonują snapshotowe backupy albo tryb „stop” (zatrzymanie maszyny na czas backupu).
Realny kompromis dla domowego serwera: raz dziennie backup kluczowych maszyn (NAS, home assistant, router VM) z retencją kilku–kilkunastu ostatnich kopii, i raz w tygodniu głębszy backup wszystkich. W dodatku co jakiś czas można zrzucać najważniejsze backupy na zewnętrzny dysk USB – to prosta ochrona przed awarią całego serwera.
Podstawy migawkowania (snapshoty) maszyn
Snapshoty to szybki sposób na „bezpiecznik” przed większą zmianą. Gdy trzeba zaktualizować system gościa lub zainstalować podejrzaną aplikację, snapshot pozwala wrócić do poprzedniego stanu w parę minut.
W interfejsie VM lub kontenera jest zakładka Snapshots, gdzie można:
utworzyć nowy snapshot z opisem,
przywrócić maszynę do wskazanego snapshotu,
usunąć stare, niepotrzebne snapshoty.
W praktyce snapshoty trzyma się krótko – przed większą aktualizacją lub migracją konfiguracji. Długotrwałe życie na wielu snapshotach bywa kłopotliwe dla wydajności i miejsca na dysku, zwłaszcza na ZFS, gdzie każda zmiana jest śledzona.
Sprawdzanie zdrowia dysków – SMART i monitorowanie
Żeby nie obudzić się pewnego dnia z padniętym pool-em, dobrze co jakiś czas zerknąć na stan dysków. Prócz logów ZFS (o ewentualnych błędach checksum lub read/write), przydaje się SMART.
W zakładce Node → Disks → SMART można przeglądać informacje o kondycji dysków:
liczbę realokowanych sektorów,
błędy odczytu/zapisu,
temperaturę,
liczbę godzin pracy.
Nie trzeba obsesyjnie patrzeć na każdy parametr, ale gwałtowny wzrost błędów lub wysokie temperatury to sygnał, żeby zawczasu zaplanować wymianę. Przy mirrorze ZFS wymiana uszkodzonego dysku i resilvering poola są znacznie spokojniejsze niż odtwarzanie wszystkiego z backupów po awarii pojedynczego, samotnego HDD.
Najczęściej zadawane pytania (FAQ)
Czy Proxmox VE nadaje się na domowy serwer, czy to „przesada” do domu?
Proxmox VE bardzo dobrze sprawdza się jako domowy serwer, szczególnie gdy chcesz uruchomić kilka usług naraz: Home Assistant, serwer plików, multimediowy, VPN czy małe laboratorium testowe. Zamiast mieć trzy czy cztery różne urządzenia, wystarczy jeden sensowny komputer z kilkoma maszynami wirtualnymi lub kontenerami.
Mit brzmi: „Proxmox jest tylko dla firm, do domu wystarczy Raspberry Pi”. Rzeczywistość: jeśli ogarniasz instalację zwykłej dystrybucji Linuxa i podstawową konfigurację sieci, poradzisz sobie z Proxmoxem. Zyskujesz dużo większą elastyczność, snapshoty, łatwą migrację usług i możliwość testowania nowych rzeczy bez ryzyka rozwalenia całego środowiska.
Jakie są minimalne wymagania sprzętowe Proxmox VE do użytku domowego?
Sam Proxmox VE nie potrzebuje wiele, ale realne wymagania dyktują uruchomione na nim maszyny. Sensowne minimum do domu to procesor z 2–4 rdzeniami i obsługą wirtualizacji (Intel VT-x lub AMD-V), 8 GB RAM (rozsądniej celować w 16 GB) oraz dysk SSD 120–240 GB na system i obrazy VM. Do większych magazynów danych można dodać dysk HDD.
Mit, który często się pojawia: „Proxmox pójdzie na byle czym, wystarczy 4 GB RAM”. Owszem, system wystartuje, ale pierwsza VM-ka z Windowsem lub kilka usług w kontenerach szybko zje całą pamięć i zaczną się przycięcia. Lepiej od razu zaplanować trochę zapasu, zwłaszcza RAM, bo apetyt na nowe usługi zwykle rośnie w trakcie używania.
Jak sprawdzić, czy mój procesor i BIOS obsługują wirtualizację pod Proxmox VE?
Jeśli masz już na tym sprzęcie Linuxa, w terminalu sprawdź zawartość /proc/cpuinfo. Dla procesorów Intela szukaj flagi vmx, a dla AMD – svm. Obecność tych flag oznacza wsparcie sprzętowej wirtualizacji, które Proxmox wykorzysta do uruchamiania maszyn KVM.
W BIOS/UEFI znajdziesz opcje typu „Intel Virtualization Technology (VT-x)”, „Intel VT-d” lub „SVM Mode” (AMD). Muszą być włączone. Jeśli na sprzęcie nie ma jeszcze systemu, najlepiej sprawdzić model CPU w dokumentacji producenta (Intel ARK, strona AMD). Bez tych funkcji Proxmox co prawda zainstalujesz, ale nie skorzystasz z pełnej wirtualizacji – a to mija się z celem.
Czy do Proxmox VE lepszy jest stary PC, NUC/miniPC czy używany serwer rack?
To zależy głównie od miejsca, hałasu i rachunków za prąd. Stary desktop jest tani i łatwo dostępny, ale bywa głośny i mało energooszczędny. NUC lub miniPC są ciche, małe i oszczędne, świetne do mieszkania, lecz ogranicza je miejsce na dyski. Używany serwer rack daje ogromną rozbudowę RAM i storage, ale w warunkach domowych często hałasuje jak odkurzacz i ciągnie sporo watów.
W praktyce, jeśli serwer ma stać w pokoju, korytarzu lub szafie wnękowej, wygrywają małe, energooszczędne konstrukcje: NUC, miniPC albo kompaktowy desktop z sensownym chłodzeniem. Duże serwery rack lepiej sprawdzają się w piwnicy, garażu lub tam, gdzie hałas i pobór mocy nie są problemem.
Czym różni się postawienie usług na „gołym” Linuxie od użycia Proxmox VE?
Na gołym Linuxie instalujesz wszystko w jednym systemie: Sambę, Dockera, Home Assistanta, serwer WWW i bazy danych. Na początku działa to dobrze, ale po pewnym czasie aktualizacje pakietów i zmiany zależności potrafią sporo namieszać. Migracja na inny sprzęt wymaga osobnego przenoszenia każdej usługi i konfiguracji.
W Proxmoxie dzielisz usługi na osobne maszyny wirtualne lub kontenery. Masz izolację (awaria jednego systemu nie rozwala reszty), snapshoty przed większymi zmianami i prostszą migrację między serwerami (często to tylko przeniesienie obrazu VM). Do tego możesz spokojnie eksperymentować – jeśli coś nie wypali, kasujesz jedną VM-kę, bez wpływu na całą resztę.
Czy Proxmox VE zastępuje Dockera i inne kontenery aplikacyjne?
Proxmox VE nie jest zamiennikiem Dockera, tylko warstwą niżej. Umożliwia uruchamianie pełnych maszyn KVM i kontenerów systemowych LXC, a dopiero w nich możesz włączyć Dockera czy inne narzędzia konteneryzacji. Proxmox rozwiązuje kwestie izolacji całych systemów, różnic w jądrach, potrzeb oddzielnych sieci czy użycia Windowsa obok Linuxa.
Mit: „Po co mi Proxmox, skoro mam Dockera”. Rzeczywistość: Docker świetnie nadaje się do uruchamiania aplikacji w ramach jednego systemu, ale nie zastąpi pełnej wirtualizacji tam, gdzie chcesz np. osobną maszynę z firewallem, laboratorium z Windows Server, czy zupełnie odseparowane środowisko testowe. Proxmox pozwala połączyć oba światy: cięższe rzeczy w VM-kach, lekkie usługi w kontenerach i Dockerze.
Czy instalacja i konfiguracja Proxmox VE jest trudniejsza niż zwykłego Linuxa?
Instalator Proxmoxa jest porównywalny z instalatorem typowej dystrybucji desktopowej: wybierasz dysk, ustawiasz hasło, sieć i po kilku minutach masz gotowy system z panelem WWW. Większość codziennych zadań – tworzenie VM-ek, backupy, snapshoty, zarządzanie dyskami – zrobisz z poziomu przeglądarki, bez grzebania w konsoli.
Jeśli ogarniasz podstawy: adresy IP, bramy, DNS i logowanie przez SSH, nie będzie to „czarna magia”. Panel Proxmoxa bardziej przypomina interfejs znany z serwerów firmowych, ale stoi na nim zwykły Debian, więc w razie potrzeby możesz wejść pod maskę i naprawić lub doprecyzować konfigurację po swojemu.
