Podobnie jak w przypadku większości hypervisorów, niektóre z najlepszych funkcji Proxmox nie są oczywiste na pierwszy rzut oka. Niektóre funkcje i możliwości są głęboko ukryte, a także ukryte w oficjalnej dokumentacji Proxmox, zwłaszcza w podręczniku administratora Proxmox. Wszyscy znamy oczywiste, podstawowe funkcje Proxmox, ale podręcznik administratora ujawnia wiele innych zaawansowanych możliwości, które mogą usprawnić zarządzanie klastrem. Są to funkcje, które możesz wdrożyć w swoim środowisku już dziś, aby zwiększyć odporność, łatwość zarządzania i wydajność swojego laboratorium lub produkcji. Przyjrzyjmy się siedmiu ukrytym funkcjom Proxmox opisanym w podręczniku administratora, których wielu użytkowników, szczególnie tych domowych, nigdy nie odkrywa.
Zbuduj własne, offline’owe lub lokalne repozytorium Proxmox
Czy wiesz, że jedną z najciekawszych możliwości opisanych w dokumentacji jest możliwość utworzenia własnego repozytorium offline Proxmox. Na czym to polega? Otóż pozwala to na hostowanie lokalnej kopii repozytoriów pakietów Proxmox i kierowanie węzły do tego repozytorium zamiast pobierania aktualizacji bezpośrednio z internetu.
Myślę, że jest kilka scenariuszy, w których może się to przydać. W sieciach przedsiębiorstw, a nawet laboratoriów domowych, pozwala to klastrom działać w sieci odizolowanej, jeżeli nie muszą mieć połączenia z internetem. Wiele osób dbających o bezpieczeństwo lub podlegających ograniczeniom zgodności w środowisku produkcyjnym potrzebuje tego, aby kontrolować sposób wdrażania aktualizacji i uaktualnień na swoich serwerach.

Jest to również bardziej wydajne, jeśli masz więcej niż jeden węzeł. Zamiast aby każdy węzeł pobierał pakiety z publicznych serwerów Proxmox, możesz efektywnie przechowywać lokalną kopię w swojej sieci. Wtedy wszystkie Twoje węzły Proxmox mogą pobierać aktualizacje z lokalnego serwera lustrzanego, a nie przez sieć WAN.
Jeśli więc chcesz zaliczyć ten wynik:
- Aktualizacje pobierają się znacznie szybciej, ponieważ są pobierane przez sieć LAN.
- Zużycie przepustowości jest zminimalizowane, ponieważ pakiety są pobierane tylko raz.
- Masz kontrolę nad tym, kiedy aktualizacje będą dostępne dla Twojego klastra.
Aby skorzystać z tej funkcji, Twój przepływ pracy może wyglądać następująco:
- Utwórz system, który odzwierciedla repozytoria Proxmox
- Synchronizuj pakiety z repozytoriów źródłowych
- Skonfiguruj węzły Proxmox do korzystania z wewnętrznego lustra
- Zastosuj aktualizacje w całym klastrze z lokalnego źródła
Konfiguracja jest niezwykle prosta. Jeśli masz już hosta Proxmox, którego repozytorium wskazuje na inne repozytorium, możesz zainstalować lustro offline Proxmox, wykonując następujące czynności:
|
1 2 |
apt update apt install proxmox-offline-mirror |
Zautomatyzowane instalacje Proxmox przy użyciu plików odpowiedzi
Czy wiesz, że możesz przeprowadzić automatyczną instalację Proxmox za pomocą pliku odpowiedzi? Tak, możesz. Ta funkcja pozwala na automatyczną instalację Proxmox zamiast ręcznego przechodzenia przez proces instalacji za każdym razem, gdy węzeł jest aprowizowany.
Zwykle instalacja Proxmox składa się z kilku ręcznych kroków. Wdrożenie serwerów na dużą skalę może być żmudne. Musisz wybrać opcje pamięci masowej, skonfigurować sieć, wybrać nazwy hostów i ustawić hasła. Ponownie, w małych laboratoriach domowych może to nie stanowić problemu, ale jeśli używasz wielu węzłów i musisz wdrożyć więcej niż jedną instalację Proxmox, ta funkcja jest bardzo przydatna.
Podobnie jak w przypadku innych automatycznych instalacji systemów operacyjnych, proces ten wykorzystuje „pliki odpowiedzi”, które dostarczają instalatorowi predefiniowane parametry instalacji. Następnie instalator odczytuje plik konfiguracyjny i stosuje ustawienia w Proxmox podczas instalacji.
Poniżej znajduje się lista plików odpowiedzi w formacie TOML:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 |
[global] keyboard = "us" country = "us" fqdn = "pveauto.testinstall" mailto = "mail@no.invalid" timezone = "America/Chicago" root-password = "password" root-ssh-keys = [ "ssh-ed25519 AAAA..." ] [network] source = "from-dhcp" [network.interface-name-pinning] enabled = true [network.interface-name-pinning.mapping] "24:8a:07:1e:05:bc" = "lan0" "24:8a:07:1e:05:bd" = "lan1" "b4:2e:99:ac:ad:b4" = "mgmt" [disk-setup] filesystem = "zfs" zfs.raid = "raid1" disk-list = ["sda", "sdb"] [post-installation-webhook] url = "https://my.endpoint.local/postinst" cert-fingerprint = "AA:E8:CB:95:B1:..." [first-boot] source = "from-iso" ordering = "before-network" |
Co pliki odpowiedzi mogą definiować w ramach zautomatyzowanego procesu? Pliki te mogą definiować takie rzeczy, jak:
- Konfiguracja pamięci masowej
- Ustawienia sieciowe
- Informacje o nazwie hosta i domenie
- Opcje instalacji
- Uprawnienia administracyjne
Proxmox udostępnia narzędzie, które ułatwia ten proces: proxmox-auto-install-assistant. Więcej informacji o automatycznej instalacji za pomocą tego narzędzia można znaleźć tutaj: Automatyczna instalacja – Proxmox VE.
Przydaje się ono na przykład podczas tworzenia klastra Proxmox z trzema lub pięcioma węzłami. Można zainstalować każdy węzeł z identycznymi ustawieniami konfiguracji i upewnić się, że węzły są instalowane spójnie i bez ryzyka wystąpienia błędów ludzkich.
Ponadto, jeśli trzeba odbudować węzeł w przypadku awarii lub awarii sprzętu, plik odpowiedzi po ponownej instalacji hypervisora pozwala na szybkie ponowne wdrożenie systemu z dokładnie taką samą konfiguracją, jaką miał wcześniej, zwłaszcza jeśli korzystano z automatycznego wdrożenia za pierwszym razem.
Uwielbiam tego typu rozwiązania, ponieważ pliki konfiguracyjne i odpowiedzi automatycznego wdrożenia można przechowywać w repozytorium git. Pozwala to na kontrolę wersji, a także na dostęp do historii zmian i możliwość przywrócenia ich do poprzedniej wersji w razie potrzeby.
Przypnij nazwy interfejsów sieciowych, aby zapobiec uszkodzeniu sieci
Być może słyszałeś o nowej funkcji Proxmox 9, która pozwala na przypinanie nazw interfejsów sieciowych za pomocą wbudowanego polecenia wiersza poleceń.
Nazwy sieciowe interfejsów są generowane domyślnie na podstawie identyfikatorów PCI i innych numerów nadawanych przez system. Jeśli na przykład wprowadzisz nowe urządzenie PCI do hosta Proxmox, identyfikator może się zmienić, a Proxmox zmieni nazwę interfejsu.
Spowoduje to problemy, ponieważ plik /etc/network/interfaces zawiera informacje o mostach, połączeniach i sieciach VLAN dla tych mostów, powiązanych z fizycznymi adresami sieciowymi za pomocą ich identyfikatorów. Plik konfiguracyjny nie aktualizuje się automatycznie po zmianie nazw interfejsów.
Polecenie pve-network-interface-pinning, opisane w podręczniku administratora Proxmox, zapewnia zautomatyzowany sposób konfigurowania statycznych nazw interfejsów sieciowych, które odwołują się do adresów sprzętowych (np. adresów MAC, które nigdy się nie zmieniają).
Za pomocą tego polecenia możesz zdefiniować konkretne nazwy interfejsów, takie jak:
|
1 2 3 4 |
nic1 nic2 storage0 cluster0 |

Nazwy te pozostają spójne nawet po dodaniu nowego sprzętu lub zmianie kolejności PCI. Jeśli podobnie jak ja jesteś domowym laberem i często eksperymentujesz z aktualizacjami sprzętu, takimi jak dodatkowe urządzenia PCI lub zewnętrzne karty graficzne, funkcja przypinania sieci pozwala uniknąć problemów związanych ze zmianą nazw sieci po ponownym uruchomieniu, co z kolei zapobiega ogromnym problemom.
Zainstaluj Proxmox przez sieć, korzystając z rozruchu PXE
Kolejny sposób jest ściśle związany z korzystaniem z plików odpowiedzi i polega na uruchomieniu Proxmoxa za pomocą rozruchu PXE. Rozruch PXE pozwala systemom na załadowanie systemu operacyjnego z sieci, a nie z nośnika fizycznego. Większość z nas zna Rufusa lub Ventoya, aby wykorzystać obraz ISO Proxmoxa, ale PXE to również świetny sposób na załadowanie systemów operacyjnych, w tym Proxmoxa.
Oficjalną dokumentację dotyczącą tych kroków znajdziesz na forum Proxmox:
Auto install through PXE | Proxmox Support Forum
W domowym laboratorium instalacja PXE może uprościć proces instalacji nowych węzłów Proxmox. Jeśli jesteś podobny do mnie, ciągle wyrzucam dyski USB i męczy mnie konieczność szukania dysku, formatowania go, aby usunąć poprzedni projekt lub eksperyment, nad którym pracowałem, a następnie kopiowania obrazu ISO. Zamiast tego możesz uruchomić system z sieci. Ma to wiele zalet.
Oto niektóre zalety, które przychodzą mi na myśl:
- Możesz szybciej instalować węzły
- Instalator jest dostarczany przez sieć
- Możesz łatwiej odbudować węzeł bez fizycznego dostępu do serwera
- Możesz skonfigurować wiele systemów jednocześnie, używając tego samego nośnika instalacyjnego
Dzięki temu możesz zaoszczędzić sporo czasu podczas eksperymentowania z instalacjami Proxmox, budowania i usuwania węzłów itd. Rozwiązaniem, z którego możesz skorzystać, jest netboot.xyz, aby mieć możliwość uruchomienia systemu w środowisku PXE. Sprawdź ich dokumentację tutaj:
Zduplikuj dyski rozruchowe Proxmox przy użyciu ZFS
Wszyscy jesteśmy zaznajomieni z używaniem ZFS do przechowywania maszyn wirtualnych. Jednak dokumentacja podkreśla inną, naprawdę fajną funkcję, która pozostaje niezauważona przy budowaniu infrastruktury opartej na Proxmox. Instalator Proxmox może tworzyć zduplikowane dyski rozruchowe z wykorzystaniem ZFS podczas instalacji. Czy wiesz o tym?
Oznacza to, że sam hypervisor może zostać zainstalowany na dyskach redundantnych. Jeśli jeden dysk rozruchowy ulegnie awarii, serwer Proxmox może kontynuować działanie z drugiego dysku. Całkiem fajne. Jest to zdecydowanie przydatne w przypadku serwerów, które działają nieprzerwanie w domowym laboratorium. Awarie dysków rozruchowych nie są bardzo częste, ale gdy już się pojawią, mogą spowodować awarię całego węzła.

Konfigurując macierz ZFS RAID1 (mirror), zyskujesz dodatkową odporność samego hypervisora. Zwróć uwagę na następujące korzyści:
- Ochrona przed awarią pojedynczego dysku
- Prosta wymiana dysku
- Lepsza niezawodność węzłów klastra
Zwłaszcza w domowym laboratorium, gdy używamy systemów z niedrogimi dyskami SATA lub NVMe jako pamięcią rozruchową, ta dodatkowa warstwa redundancji może zapewnić spokój ducha w środowisku domowego laboratorium. W środowiskach produkcyjnych można co prawda używać kontrolerów sprzętowych, natomiast Proxmox nie bardzo współpracuje z nimi, szczególnie w przypadku snapshotów, replikacji i self-healingu.
Użyj skryptów hakowych Proxmox do automatyzacji działań maszyn wirtualnych
Jedną z najpotężniejszych i jednocześnie niedocenianych funkcji ukrytych w Proxmox jest możliwość korzystania ze skryptów hooków do automatyzacji działań maszyn wirtualnych. To jedna z tych możliwości, które wydają się bardziej zbliżone do tych, których można oczekiwać od pełnoprawnej platformy automatyzacji przedsiębiorstw. Ale co naprawdę fajne, jest to, że jest ona wbudowana bezpośrednio w Proxmox.
Czym są skrypty hooków? Funkcja skryptów hooków umożliwia dołączanie niestandardowych skryptów do zdarzeń cyklu życia maszyny wirtualnej lub kontenera. Zamiast ręcznego uruchamiania zadań przed lub po określonych działaniach, Proxmox może automatycznie wykonać skrypt dokładnie w momencie, gdy jest to potrzebne.
Można włączyć się w kilka kluczowych zdarzeń cyklu życia, w tym:
- VM start
- VM stop
- pre-start
- post-stop
Jak ustawić skrypt hook dla maszyny wirtualnej? Parametr –hookscript służy do ustawienia skryptu dla konkretnego zasobu w następujący sposób:
|
1 |
qm set 100 --hookscript local:snippets/hookscript.pl |
Daje to ogromną elastyczność. Na przykład, hook przedstartowy może zostać uruchomiony przed uruchomieniem maszyny wirtualnej, a hook postopowy – po jej wyłączeniu. Dzięki temu możesz wstawić własną logikę bezpośrednio do cyklu życia maszyny wirtualnej.
Skrypty hooków są przechowywane w pamięci masowej przeznaczonej do przechowywania fragmentów kodu.

Tak więc, jak w każdej innej dziedzinie, widzę korzyści z podawania przykładów z życia wziętych. Jakie są konkretne przykłady tego, co można zrobić ze skryptami hooków?
Zapobiegaj uruchamianiu maszyny wirtualnej, jeśli pamięć masowa Ceph ma błędy
Ten skrypt idealnie pasuje do Twojego środowiska, ponieważ korzystasz z Ceph. Nie chcesz, aby krytyczne maszyny wirtualne uruchamiały się, gdy klaster Ceph jest zdegradowany. Możesz użyć haka przed uruchomieniem, aby sprawdzić stan Ceph przed uruchomieniem maszyny wirtualnej.
Przykładowy skrypt haka przed uruchomieniem:
|
1 2 3 4 5 6 7 8 9 |
#!/bin/bash PHASE=$2 if [ "$PHASE" = "pre-start" ]; then if ! ceph -s | grep -q "HEALTH_OK"; then echo "Ceph is not healthy. Blocking VM start." exit 1 fi fi |
Wyślij powiadomienie, gdy maszyna wirtualna się zatrzyma
Wyobraź sobie taki scenariusz. Chcesz wiedzieć, kiedy krytyczne maszyny wirtualne zostaną wyłączone. Możesz skonfigurować hook post-stop, który wysyła webhook z alertem.
Przykładowy skrypt hook’a post-stop:
|
1 2 3 4 5 6 7 8 9 |
#!/bin/bash VMID=$1 PHASE=$2 if [ "$PHASE" = "post-stop" ]; then curl -X POST https://your-webhook-url \ -H "Content-Type: application/json" \ -d "{\"text\":\"VM $VMID has stopped\"}" fi |
Możesz skonfigurować integracje z dowolnym z następujących rozwiązań:
- Slack
- Discord
- Teams
- custom dashboards
Automatyczne tworzenie kopii zapasowej maszyny wirtualnej po jej wyłączeniu
Pomyśl o tym scenariuszu. Chcesz utworzyć kopię zapasową za każdym razem, gdy maszyna wirtualna zostanie prawidłowo zatrzymana. Możesz utworzyć kopię zapasową wyzwalaną przez hook po zatrzymaniu.
Przykładowy skrypt hooka po zatrzymaniu:
|
1 2 3 4 5 6 7 |
#!/bin/bash VMID=$1 PHASE=$2 if [ "$PHASE" = "post-stop" ]; then vzdump $VMID --storage local --mode snapshot fi |
Użyj grup i aliasów zapór sieciowych, aby uprościć bezpieczeństwo sieci
System zapory sieciowej Proxmox jest dość wydajny, ale wielu użytkowników implementuje tylko podstawowe reguły. Przewodnik administratora wyjaśnia funkcję, która z pewnością może ułatwić zarządzanie zaporą sieciową na wielu węzłach i maszynach wirtualnych.
Proxmox obsługuje grupy i aliasy zapór sieciowych. Umożliwiają one definiowanie obiektów wielokrotnego użytku, które mogą być używane przez wiele reguł zapory sieciowej.
Aliasy mogą reprezentować sieci lub zakresy adresów IP. Na przykład, możesz utworzyć aliasy dla:
- management network
- storage network
- monitoring network

Grupy zapór umożliwiają tworzenie zestawów reguł, które można stosować do wielu systemów. Na przykład możesz mieć reguły, które zawsze stosujesz do określonych typów serwerów, takich jak serwery WWW, serwery SQL itp. Możesz mieć grupę reguł zapory dla serwera WWW, która zezwala na HTTP i HTTPS, a następnie regułę zezwalającą na port SQL 1433 i inne porty dla serwera SQL.
W takim przypadku możesz utworzyć grupy zapór zawierające wszystkie reguły dla danego typu obciążenia.

Dzięki temu zamiast powtarzać tę samą konfigurację reguł na każdej maszynie wirtualnej możesz utworzyć grupę raz i zastosować ją wszędzie tam, gdzie jest to potrzebne. Ułatwia to zarządzanie zasadami zapory i pomaga zapobiegać błędom ludzkim.
Podsumowanie
Bardzo lubię przeglądać dokumentację administracyjną różnych rozwiązań, w tym Proxmox, ponieważ często traktuje się ją jako dokumentację referencyjną. Zauważyłem jednak, że często można tam znaleźć ciekawe funkcje, które nie zawsze są oczywiste w samym interfejsie webowym. Funkcje takie jak lustra repozytoriów, automatyczne instalacje, przypinanie interfejsów i wdrożenia PXE mogą usprawnić zarządzanie domowymi laboratoriami i środowiskami produkcyjnymi. A jak jest u Ciebie? Czy korzystałeś z którejś z wymienionych funkcji, czy też jest jakaś inna, mniej znana funkcja, z której korzystasz?
Dziękuję Ci, za poświęcony czas na przeczytanie tego artykułu. Jeśli był on dla Ciebie przydatny, to gorąco zachęcam Cię do zapisania się na mój newsletter, jeżeli jeszcze Cię tam nie ma. Proszę Cię także o “polubienie” mojego bloga na Facebooku oraz kanału na YouTube – pomoże mi to dotrzeć do nowych odbiorców. Raz w tygodniu (niedziela punkt 17.00) otrzymasz powiadomienia o nowych artykułach / projektach zanim staną się publiczne. Możesz również pozostawić całkowicie anonimowy pomysł na wpis/nagranie.
Link do formularza tutaj: https://beitadmin.pl/pomysly
Pozostaw również komentarz lub napisz do mnie wiadomość odpisuję na każdą, jeżeli Masz jakieś pytania:).