Proxmox VE 9.1.6 vs 9.2 –Kompleksowe Porównanie Nowości,Praktyczne Przykłady Zastosowania

Spis treści

1. Wprowadzenie i kontekst wydania
2. Aktualizacja stosu programowego
3. Dynamic Load Balancer
4. Rozszerzenia SDN: WireGuard i BGP
5. Niestandardowe modele CPU
6. HA Manager: arm/disarm
7. Wsparcie Ceph Tentacle
8. Tabela porównawcza
9. Scenariusze praktyczne
10. Route Maps i Prefix Lists w SDN BGP
11. Jak zaktualizować do 9.2
12. Kiedy warto aktualizować?
13. FAQ – najczęstsze pytania
14. Wnioski końcowe

01. Wprowadzenie i kontekst wydania

Proxmox Virtual Environment (Proxmox VE) to jedyna w swoim rodzaju open-source’owa platforma wirtualizacji hybrydowej, która w jednym pakiecie łączy zarządzanie maszynami wirtualnymi (KVM/QEMU), kontenerami (LXC), storage’em (ZFS, Ceph) i siecią (SDN). Licencjonowana na GPL, od lat stanowi realną, tanią alternatywę wobec VMware vSphere czy Microsoft Hyper-V.

 

 

Proxmox VE 9.1 ukazał się 19 listopada 2025 roku i wniósł obsługę kontenerów OCI w LXC, Intel TDX, zagnieżdżoną wirtualizację oraz akcje masowe dla centrum danych. Proxmox VE 9.2 zadebiutował 21 maja 2026 roku – ledwie sześć miesięcy później – koncentrując się na efektywności operacyjnej klastrów produkcyjnych: automatycznym równoważeniu obciążeń, rozbudowie SDN o protokoły klasy enterprise oraz upraszczaniu zarządzania w oknach serwisowych.

Proxmox VE 9.2 jest udostępniany bezpłatnie jako oprogramowanie open source. Wsparcie enterprise (subskrypcja) zaczyna się od 120 EUR/rok/CPU i obejmuje dostęp do stabilnych repozytoriów aktualizacji oraz bezpośrednią pomoc techniczną.

Ten artykuł przedstawia szczegółową analizę różnic między wersjami 9.1.6 i 9.2 – od zmian w stosie programowym, przez nowe funkcje, aż po konkretne scenariusze zastosowań. Każda nowość jest zilustrowana praktycznym przykładem wdrożeniowym.

02. Aktualizacja stosu programowego

Każde nowe wydanie Proxmox VE przynosi głęboką aktualizację zależności. Wersja 9.2 aktualizuje niemal cały stos – od jądra systemu, przez hiperwizor, po silnik kontenerowy i systemy plików.

Komponent	Proxmox VE 9.1.6	Proxmox VE 9.2 NOWA
System bazowy	Debian 13.2 (Trixie)	Debian 13.5 (Trixie)
Jądro Linux	6.17	7.0 (domyślne stabilne)
QEMU	10.1	11.0
LXC	6.0.5	7.0
ZFS	2.3.4	2.4
Ceph (stabilny)	Squid 19.2.3	Squid 19.2.3 + Tentacle 20.2.1
Dynamic Load Balancer	Brak	Tak NOWE
WireGuard w SDN	Brak (zewnętrzne)	Natywny NOWE
BGP w SDN	Brak	Tak + route maps NOWE
Zarządzanie modelami CPU (GUI)	Brak (tylko CLI)	Interfejs webowy NOWE
HA arm/disarm	Brak	Tak (cluster-wide) NOWE
IPv6 underlay EVPN	Brak	Tak NOWE

Znaczenie przejścia na Linux kernel 7.0

Jądro Linux 7.0 to istotny kamień milowy – przynosi lepszą obsługę najnowszego sprzętu serwerowego (w tym kontrolerów NVMe generacji 5, nowych procesorów Intel Granite Rapids i AMD EPYC Genoa+), poprawioną scheduler’ów dla środowisk NUMA, a także ulepszenia w przestrzeni sieciowej, które wprost przekładają się na wydajność SDN.

QEMU 11.0 – co wnosi dla maszyn wirtualnych

QEMU 11.0 poprawia wydajność wirtualizacji CPU, emulację urządzeń NVMe oraz obsługę nowych chipsetów. Maszyny wirtualne z systemem Windows Server 2025 czy RHEL 10 skorzystają z lepszej kompatybilności sterowników paravirtualizowanych (VirtIO), a migracje live-migration są szybsze dzięki optymalizacjom w transferze pamięci.

ZFS 2.4 – stabilność i wydajność storage’u

ZFS 2.4 wnosi poprawki błędów, optymalizacje mechanizmu ARC (Adaptive Replacement Cache) oraz ulepszenia w zakresie klonowania wolumenów. Środowiska heavy-write (bazy danych, VDI) powinny odczuć zmniejszone opóźnienia przy synchronicznym I/O.

Aktualizacja samego jądra do 7.0 w 9.2 nie jest obowiązkowa natychmiast po upgrade’zie – można pozostać na 6.17 przez standardowy mechanizm wyboru jądra w menu GRUB. Dla środowisk produkcyjnych zaleca się przetestowanie 7.0 najpierw w środowisku staging.

03. Dynamic Load Balancer – automatyczne równoważenie klastra

To bez wątpienia największa nowość Proxmox VE 9.2. Dynamic Load Balancer (DLB) integruje się bezpośrednio z Cluster Resource Scheduler (CRS) i zastępuje dotychczasowe podejście oparte wyłącznie na statycznych metrykach planowania.

Jak działał CRS w Proxmox VE 9.1.6?

W wersji 9.1 CRS podejmował decyzje o rozmieszczeniu maszyn wirtualnych wyłącznie w momencie uruchamiania lub migracji gości. Jeśli węzeł A był umiarkowanie obciążony w chwili tworzenia VM, ale z czasem stawał się przeciążony (np. nocne kopie zapasowe, skoki użycia przez inne VM), system nie reagował automatycznie. Administrator musiał ręcznie inicjować migracje.

Co zmienia Dynamic Load Balancer w 9.2?

DLB działa w sposób ciągły: monitoruje bieżące zużycie zasobów (CPU, RAM, I/O) na wszystkich węzłach klastra oraz na poziomie poszczególnych maszyn wirtualnych. Gdy wykryje istotny nierównomierny rozkład obciążeń, może automatycznie zainicjować migrację live do mniej zajętego węzła – bez przerwy działania usługi i bez naruszenia reguł HA zdefiniowanych przez administratora.

Decyzje w czasie rzeczywistym

Zamiast statycznych metryk, DLB analizuje bieżące zużycie CPU, RAM i I/O na każdym węźle i każdej VM co kilka minut.

Automatyczna migracja HA-aware

Migracje respektują reguły HA – DLB nigdy nie przeniesie VM w sposób naruszający politykę dostępności.

Konfigurowalna agresywność

Administratorzy regulują czułość i próg reakcji loadbalancera – od zachowawczego po agresywne równoważenie.

Bezpieczna dla produkcji

Live migration w Proxmox VE odbywa się bez przestojów VM, co czyni DLB bezpiecznym nawet dla krytycznych usług.

Konfiguracja Dynamic Load Balancer

DLB konfiguruje się przez plik /etc/pve/datacenter.cfg lub bezpośrednio przez GUI w sekcji Datacenter → Options.

/etc/pve/datacenter.cfg – konfiguracja DLB

# Włączenie Dynamic Load Balancer
crs: static         # wartość domyślna w 9.1
crs: ha,monitor     # włącza DLB w 9.2 (ha + monitoring)

# Parametry zaawansowane (opcjonalne)
crs-ha-rebalance-on-start: 1   # rebalans przy starcie nowej VM

Dla klastrów z heterogenicznym sprzętem (różne generacje CPU między węzłami) warto ustawić migration: secure i zachować politykę cpu: kvm64 lub niższy wspólny mianownik, aby DLB mógł swobodnie wybierać węzeł docelowy bez błędów CPU flag mismatch.

PRZYKŁADKlaster 5 węzłów – nocne skoki CPU podczas backupu

Problem w 9.1.6: Każdej nocy uruchomiony jest backup PBS na 3 spośród 5 węzłów klastra. Węzły backup osiągają 85% CPU, pozostałe 2 węzły pracują na poziomie 20%. Administratorzy muszą ręcznie migrować VM lub akceptować degradację wydajności.

Rozwiązanie w 9.2 z DLB: Dynamic Load Balancer wykrywa nierównowagę ok. 22:15 (peak backup), automatycznie inicjuje live-migration 4 maszyn VM z przeciążonych węzłów na te z 20% obciążeniem. Operacja trwa ~3 minuty, serwisy nie odczuwają przerwy, a o 06:00 DLB redystrybuuje VM z powrotem do równomiernego rozkładu.

04. Rozszerzenia SDN: WireGuard, BGP i EVPN

Warstwa Software-Defined Networking (SDN) Proxmox VE systematycznie dojrzewa. Wersja 9.2 przynosi największy skok w możliwościach SDN od czasu wprowadzenia „Fabrics” w 9.0.

Natywny WireGuard w SDN

W poprzednich wersjach konfiguracja WireGuard na Proxmox wymagała zewnętrznych skryptów, ręcznego zarządzania kluczami i obejść w konfiguracji interfejsów. Proxmox VE 9.2 integruje WireGuard bezpośrednio w stos SDN – tunele WireGuard są teraz pierwszorzędnym typem połączenia, zarządzanym z poziomu GUI w sekcji Datacenter → SDN → Fabrics.

Przykład konfiguracji WireGuard Fabric w SDN (pvesh)

# Tworzenie WireGuard fabric (nowe w 9.2)
pvesh create /cluster/sdn/fabrics \
  --fabric wg-fabric \
  --type wireguard \
  --privatekey "$(wg genkey)"

# Dodawanie peer (zdalny węzeł lub site)
pvesh create /cluster/sdn/fabrics/wg-fabric/peers \
  --peer remote-dc \
  --publickey "REMOTE_PUBLIC_KEY" \
  --endpoint "203.0.113.10:51820" \
  --allowedips "10.10.20.0/24"

# Zastosowanie konfiguracji SDN
pvesh set /cluster/sdn # lub GUI → Apply

BGP i route maps – routing klasy enterprise

Proxmox VE 9.2 dodaje obsługę BGP (Border Gateway Protocol) jako natywnego protokołu routingowego w SDN, uzupełniając istniejące wsparcie EVPN. Dla zaawansowanych środowisk dostępne są:

• › Route maps i prefix lists – precyzyjna kontrola, które prefiksy są redistribuowane przez BGP/EVPN
• › OSPF route redistribution – łatwa integracja z istniejącą infrastrukturą OSPF
• › Rozszerzone opcje kontrolerów EVPN – bardziej szczegółowa konfiguracja topologii VxLAN/EVPN
• › IPv6 underlay dla EVPN – pełne wsparcie IPv6 w warstwie transportowej EVPN

PRZYKŁADMulti-site DR z WireGuard Fabric i BGP

Scenariusz: Firma posiada główne datacenter w Warszawie i zapasowe w Krakowie. Dotychczas VPN między lokalizacjami wymagał osobnego serwera WireGuard (VM lub bare-metal), który był pojedynczym punktem awarii i wymagał osobnych skryptów do integracji z routingiem VM.

Rozwiązanie w 9.2: Obie lokalizacje konfigurują WireGuard Fabric bezpośrednio w SDN Proxmox. BGP dystrybuuje prefiksy sieci VM między lokalizacjami automatycznie. Route maps blokują redistribucję sieci serwisowych (np. management). IPv6 underlay dla EVPN umożliwia wdrożenie nowoczesnego stacku sieciowego bez podwójnego NAT. Cały setup zajmuje ok. 30 minut w GUI i jest w pełni zarządzany przez Proxmox API.

Natywny BGP w SDN Proxmox jest przeznaczony do integracji z siecią SDN wewnątrz klastra. Nie zastępuje pełnoprawnych routerów BGP w stronę upstream providerów – do tego nadal potrzebny jest np. VyOS lub FRR w dedykowanej VM.

05. Niestandardowe modele CPU – zarządzanie przez GUI

Kontrola nad flagami CPU prezentowanymi maszynom wirtualnym to kluczowy element w środowiskach mieszanych – zwłaszcza gdy klaster składa się z węzłów różnych generacji procesorów. W Proxmox VE 9.1.6 zarządzanie niestandardowymi modelami CPU wymagało bezpośredniej edycji pliku /etc/pve/virtual-guest/cpu-models.conf.

Co nowego w 9.2?

Proxmox VE 9.2 wprowadza dedykowaną sekcję Datacenter → Custom CPU Models w interfejsie webowym. Administratorzy mogą:

• Tworzyć nowe profile CPU z dokładnie wybranymi flagami (AVX-512, SHA, SGX itp.)
• Edytować istniejące profile bez edycji pliku konfiguracyjnego
• Usuwać nieużywane profile
• Podejrzeć selektor flag CPU z widocznością – które flagi są dostępne na poszczególnych węzłach klastra

Ostatni punkt – CPU flags selector z widocznością per węzeł – jest szczególnie wartościowy. Administrator od razu widzi, czy definiowany model CPU jest kompatybilny ze wszystkimi węzłami, na których DLB mógłby migrować daną VM. Eliminuje błędy klasy „VM migrowała i nie uruchomiła się, bo węzeł nie wspiera AVX-512”.

Przykładowy niestandardowy profil CPU dla ML workloadów

# /etc/pve/virtual-guest/cpu-models.conf (zarządzany przez GUI w 9.2)

cpu-model: ml-optimized
  phys-bits: 46
  flags: +avx;+avx2;+avx512f;+avx512bw;+avx512vl;+aes;+sha-ni
  hidden-flags: pcid;ssbd;ibpb
  hv-flags: evmcs
  reported-model: Skylake-Server-IBRS

PRZYKŁAD

Klaster HPC z węzłami AMD EPYC – profil CPU dla obliczeń naukowych

Problem: Klaster 8 węzłów – 4 AMD EPYC (Genoa-v2) i 4 Skylake-Server-IBRS. Maszyny do obliczeń HPC potrzebują AVX-512 i SHA-NI, ale nie wszystkie węzły Intel wspierają AVX-512-VAES. Bez niestandardowego profilu: albo VM korzysta z „host” CPU (brak migracji między AMD/Intel), albo z kvm64 (brak AVX-512).

Rozwiązanie w 9.2: W GUI Datacenter → Custom CPU Models definiujemy profil hpc-common z +avx512f;+avx512bw;+sha-ni (wspólny mianownik obu architektur). Selektor flag od razu zaznacza węzły, na których ten profil jest bezpieczny. DLB może teraz migrować VM HPC między wszystkimi 8 węzłami z pełnym AVX-512.

06. HA Manager: arm/disarm – koniec problemów z maintenance

Każdy administrator Proxmox, który przeprowadzał aktualizacje węzłów produkcyjnego klastra z HA, zna ten scenariusz: podczas planowanego wyłączenia węzła w celu aktualizacji, HA Manager inicjuje failover VM na inne węzły, a po ponownym uruchomieniu węzła – znowu je przemieszcza. Rezultat: niepotrzebne migracje live, chwilowe spadki wydajności, logi pełne zdarzeń HA.

Rozwiązanie w Proxmox VE 9.2

Wersja 9.2 wprowadza dwie nowe komendy i odpowiadające im opcje w GUI:

Komenda	Efekt	Zachowanie stanów HA
ha-manager disarm	Zawiesza stos HA w całym klastrze	Stany HA zapamiętane – VM nie są migrowane
ha-manager arm	Przywraca stos HA do działania	VM wracają do poprzedniego rozmieszczenia

Praktyczny workflow aktualizacji klastra w 9.2

1. Disarm HA: ha-manager disarm – HA przestaje monitorować stany VM i wstrzymuje automatyczne failovery.
2. Drain węzła: GUI → Node → Maintenance Mode lub pvecm updatecerts --force – VM są ręcznie migrowane lub opróżnianie jest zarządzane przez administratora.
3. Aktualizacja węzła: apt update && apt dist-upgrade -y + restart.
4. Weryfikacja węzła: Sprawdzenie statusu usług, logów kernela, dostępności storage’u.
5. Arm HA: ha-manager arm – HA wznawia działanie, VM wracają do poprzedniego stanu i lokalizacji.

Funkcja disarm/arm dotyczy całego klastra jednocześnie. Jeśli potrzebujesz wyciszyć HA tylko dla jednego węzła, nadal używaj standardowego trybu maintenance węzła (Node → More → Maintenance Mode).

PRZYKŁADRolling upgrade 6-węzłowego klastra produkcyjnego

Stary sposób (9.1.6): Przed aktualizacją każdego węzła administratorzy musieli ręcznie wyłączać ochronę HA dla każdej VM, aktualizować węzeł, przywracać ustawienia HA. W 6-węzłowym klastrze ze 120 VM – ok. 4 godziny pracy administracyjnej per aktualizacja.

Nowy sposób (9.2): Jeden ha-manager disarm, aktualizacja węzłów rolling (jeden po drugim z drain), jeden ha-manager arm. Cały rolling upgrade 6 węzłów: ok. 45 minut aktywnej pracy administratora (resztę stanowi czas oczekiwania na aktualizacje). Zero niepotrzebnych failoverów HA.

07. Wsparcie Ceph Tentacle 20.2 – nowa opcja stable

Proxmox VE 9.2 jako pierwsza wersja platformy oferuje Ceph Tentacle 20.2 jako opcję stabilną obok dotychczasowego Ceph Squid 19.2. Daje to administratorom wybór między sprawdzonym Squid (zalecany dla migracji z 9.1) a nowym Tentacle (dla nowych wdrożeń i środowisk, które chcą korzystać z najnowszych funkcji).

Ceph Tentacle 20.2 – kluczowe nowości

Ceph Tentacle wprowadza m.in. ulepszenia w mechanizmie BlueStore, lepszą wydajność przy workloadach wielowątkowych, poprawioną obsługę NVMe over Fabrics oraz eksperymentalne wsparcie dla wolumenów szyfrowanych per-pool z kluczami zarządzanymi zewnętrznie (Key Management Service). Monitoring przez Proxmox GUI jest w pełni kompatybilny z obiema wersjami Ceph.

Nie należy migrować istniejącego klastra Ceph Squid do Tentacle przy okazji upgrade’u Proxmox VE 9.1→9.2. Migracja Ceph to oddzielna, planowana operacja. Tentacle jest dostępny jako opcja dla nowych wdrożeń lub po osobno zaplanowanej procedurze upgrade’u Ceph.

08. Pełna tabela porównawcza 9.1.6 vs 9.2

Obszar	Proxmox VE 9.1.6 STARSZA	Proxmox VE 9.2 AKTUALNA
Równoważenie obciążeń	CRS statyczny – decyzje tylko przy tworzeniu/starcie VM	Dynamic Load Balancer – ciągły monitoring, automatyczne live-migration NOWE
SDN – WireGuard	Brak natywnej integracji, wymagane zewnętrzne skrypty	Natywny WireGuard Fabric w SDN, zarządzany z GUI NOWE
SDN – routing BGP	Brak	BGP z route maps, prefix lists, redistribucja OSPF NOWE
SDN – IPv6 EVPN	Brak wsparcia IPv6 underlay	IPv6 underlay dla EVPN NOWE
Modele CPU	Tylko edycja pliku CPU-models.conf przez CLI	GUI: tworzenie/edycja/usuwanie modeli, selektor flag per węzeł NOWE
HA maintenance	Brak cluster-wide disarm – ręczne zarządzanie per VM	ha-manager arm/disarm dla całego klastra, zachowanie stanów HA NOWE
Ceph storage	Squid 19.2.3 (jedyna opcja stable)	Squid 19.2.3 + Tentacle 20.2.1 (obie opcje stable) ROZSZERZONE
Kernel Linux	6.17	7.0 (domyślny stabilny) UPGRADE
QEMU	10.1	11.0 UPGRADE
LXC	6.0.5	7.0 UPGRADE
ZFS	2.3.4	2.4 UPGRADE
Debian base	13.2 Trixie	13.5 Trixie UPGRADE
Obsługa OCI w LXC	Tak (od 9.1)	Tak (bez zmian)
Intel TDX	Tak (od 9.1)	Tak (bez zmian)
Zagnieżdżona wirtualizacja	Tak (od 9.1)	Tak (bez zmian)
Proxmox Backup Server	Wsparcie PBS 3.x	Wsparcie PBS 3.x (bez zmian)

09. Scenariusze praktyczne – kto skorzysta najbardziej?

SCENARIUSZ 1Małe i średnie przedsiębiorstwo – klaster 3 węzłów, 40 VM

Profil: Firma produkcyjna, 40 maszyn wirtualnych (ERP, serwery plików, bazy danych, środowiska dev). Klaster 3-węzłowy, brak dedykowanego administratora infrastruktury – opiekę sprawuje 1 osoba IT.

Najważniejsze korzyści z 9.2:

▸ Dynamic Load Balancer odciąża administratora od ręcznego monitorowania obciążeń – VM są automatycznie perbalansowane, gdy jeden z węzłów jest przeciążony podczas backup lub EOD batch. ▸ HA arm/disarm sprawia, że wieczorne okna serwisowe na aktualizacje stają się prostą 2-krokową procedurą bez ryzyka nieplanowanych failoverów. ▸ Nowe profile CPU przez GUI – osoba zarządzająca infrastrukturą nie musi edytować plików konfiguracyjnych ręcznie.

Rekomendacja: Aktualizacja do 9.2 jest zdecydowanie wskazana – DLB i HA arm/disarm zwrócą się w pierwszym oknie serwisowym.

SCENARIUSZ 2Hosting / MSP – środowisko multi-tenant, 200+ VM

Profil: Managed Service Provider oferujący VPS i dedykowane VM. Klaster 12 węzłów, HA wymagany dla klientów z SLA 99.9%+. Różnorodne workloady: od małych VPS WordPress po duże instancje baz danych i środowiska Windows Server.

Najważniejsze korzyści z 9.2:

▸ Dynamic Load Balancer eliminuje hotspoty zasobów – administrator nie musi ręcznie reagować na skargi klientów o „wolny hosting”. DLB prewencyjnie rozkłada obciążenia. ▸ Niestandardowe modele CPU pozwalają tworzyć profile per klient (klient A dostaje CPU z AVX-512 dla ML, klient B dostaje bezpieczny kvm64). ▸ SDN BGP i WireGuard umożliwiają proste, bezpieczne połączenie środowisk klientów z ich lokalnymi sieciami bez external VPN gateway. ▸ Ceph Tentacle 20.2 jest dostępny dla nowych partycji storage dla nowych klientów – lepsze IOPS dla klientów premium.

Rekomendacja: Wysokopriorytetowa aktualizacja. DLB i SDN-BGP są kluczowe dla efektywności operacyjnej na tej skali.

SCENARIUSZ 3Środowisko akademickie / badawcze – HPC i kontenery AI/ML

Profil: Uczelnia techniczna. Klaster heterogeniczny: węzły AMD EPYC + Intel Xeon + węzły GPU (NVIDIA H100). LXC OCI używany do dystrybucji środowisk Dockerowych dla studentów. Obliczenia naukowe wymagają AVX-512, AMX.

Najważniejsze korzyści z 9.2:

▸ Niestandardowe modele CPU – tworzenie profili HPC wspólnych dla AMD i Intel, które DLB może swobodnie migrować między węzłami. ▸ QEMU 11.0 – lepsze wsparcie dla passthrough GPU, istotne dla VM z H100 do trenowania modeli. ▸ LXC 7.0 z OCI (z 9.1) + DLB – kontenery środowisk studenckich są automatycznie rozkładane na węzły o wolnych zasobach. ▸ ZFS 2.4 – stabilność puli danych badawczych, lepsze ARC dla dużych datasetsów.

Rekomendacja: Aktualizacja zalecana, szczególnie dla poprawy zarządzania profilemi CPU w klastrze heterogenicznym.

SCENARIUSZ 4Enterprise multi-datacenter – DR i SDN między lokalizacjami

Profil: Korporacja z dwoma datacenter (Warsaw + Kraków) połączonymi własnym DF-10G. Wymogi regulacyjne wymagają szyfrowanych tuneli między DC. Łącznie 50 węzłów, 800+ VM, dedykowany zespół IT.

Najważniejsze korzyści z 9.2:

▸ WireGuard native SDN Fabric – zastąpienie obecnego setup’u OpenVPN między DC natywnym WireGuard zarządzanym przez Proxmox SDN. Eliminacja zewnętrznego VPN gateway jako SPOF. ▸ BGP + route maps – automatyczna redistribucja prefiksów sieci VM między DC, filtrowanie management VLAN-ów. Eliminacja ręcznych statycznych tras. ▸ IPv6 underlay EVPN – przygotowanie infrastruktury pod IPv6-native SDN (zgodność z wymogami EU GDPR/NIS2 dla nowoczesnej infrastruktury). ▸ HA arm/disarm – planowane okna serwisowe w jednym DC bez ryzyka cross-DC failoverów podczas maintenance.

Rekomendacja: Kluczowa aktualizacja dla Multi-DC. SDN BGP + WireGuard Fabric to eliminacja istotnych single-point-of-failure.

10. Route Maps i Prefix Lists w SDN BGP

Jedną z bardziej zaawansowanych, lecz często niedocenianych nowości Proxmox VE 9.2 jest pełna obsługa route maps i prefix lists w warstwie BGP natywnego SDN. Funkcjonalności te przenoszą możliwości sterowania ruchem sieciowym na poziom zbliżony do dedykowanych routerów enterprise, nie wymagając osobnych VM z FRRouting ani zewnętrznych narzędzi sieciowych.

Czym są prefix lists i route maps?

Prefix lists to listy filtrów działające na prefiksach IP (np. 10.10.0.0/16). Każda reguła listy zezwala (permit) lub odrzuca (deny) redistribuowanie konkretnego zakresu adresów przez BGP. Route maps to bardziej rozbudowany mechanizm: sekwencja reguł warunkowych, które mogą nie tylko filtrować prefiksy, ale też modyfikować atrybuty BGP (np. local-preference, MED, community) lub ustawiać tagi routingowe dla konkretnych grup sieci.

W Proxmox VE 9.1.6 redistribucja tras BGP/EVPN odbywała się globalnie – wszystkie prefiksy znane SDN były rozgłaszane do sąsiednich routerów. W 9.2 administrator może precyzyjnie określić, co jest redistribuowane i z jakimi atrybutami.

Konfiguracja prefix lists i route maps przez pvesh

Prefix Lists – filtrowanie redistribuowanych sieci VM

# Tworzenie prefix list – dopuszcza tylko sieci VM tenant (10.20.0.0/14)
pvesh create /cluster/sdn/ipams \
  --type prefixlist \
  --name pl-tenant-nets

# Dodanie reguły permit dla sieci tenant
pvesh create /cluster/sdn/ipams/pl-tenant-nets/rules \
  --seq 10 \
  --action permit \
  --prefix 10.20.0.0/14 \
  --le 24   # dopuszcza /14 do /24 (dokładne podsieci tenant)

# Reguła deny dla management VLAN (10.0.0.0/8 z wyjątkiem tenant)
pvesh create /cluster/sdn/ipams/pl-tenant-nets/rules \
  --seq 20 \
  --action deny \
  --prefix 10.0.0.0/8

# Reguła implicit deny-all (domyślna – bez explicit permit nic nie przejdzie)
# seq 99 - deny any any (automatyczna jeśli nie ma 'permit any')

Route Maps – warunkowa modyfikacja atrybutów BGP

# Tworzenie route map do sterowania redistribucją OSPF → BGP
pvesh create /cluster/sdn/bgp/routemaps \
  --name rm-ospf-to-bgp

# Reguła 10: permit trasy spełniające prefix list pl-tenant-nets
#             ustaw local-preference 200 (preferowane przez lokalny BGP)
pvesh create /cluster/sdn/bgp/routemaps/rm-ospf-to-bgp/rules \
  --seq 10 \
  --action permit \
  --match-prefix-list pl-tenant-nets \
  --set-local-preference 200

# Reguła 20: deny wszystkiego pozostałego
pvesh create /cluster/sdn/bgp/routemaps/rm-ospf-to-bgp/rules \
  --seq 20 \
  --action deny

# Zastosowanie route map do kontrolera EVPN
pvesh set /cluster/sdn/controllers/evpn-ctrl \
  --redistribute ospf \
  --redistribute-routemap rm-ospf-to-bgp

# Przeładowanie konfiguracji SDN
pvesh set /cluster/sdn

---

Typowe przypadki użycia

Izolacja sieci management

Prefix list blokujący redistribucję VLAN-ów zarządzania (np. 172.16.0.0/12) przez BGP – management Proxmox pozostaje niedostępny z zewnętrznych lokalizacji SDN.

Multi-tenant routing

Osobne prefix lists per tenant w środowisku MSP – Tenant A widzi tylko swoje sieci /24, nawet jeśli BGP rozgłasza wspólny supernet /16.

Redistribucja OSPF selektywna

Route map filtrująca, które trasy OSPF są przekazywane do BGP – np. tylko sieci storage i VM, bez tras infrastrukturalnych Proxmox cluster corosync.

Traffic engineering

Route maps ustawiające MED i local-preference dla tras między datacenter – sterowanie przepływem ruchu DR bez fizycznej rekonfiguracji sieci.

PRZYKŁADMSP: Filtrowanie redistribucji BGP w środowisku multi-tenant z 3 lokalizacjami

Problem w 9.1.6: Środowisko MSP z 3 datacenter połączonymi przez WireGuard SDN Fabric i BGP. Wszystkie sieci VM (tenantów A, B, C) oraz sieci management Proxmox są redistribuowane do BGP bez filtrowania. Tenant A może, poprzez błędną konfigurację swojej VM, rozgłosić trasę konfliktującą z management VLAN innego datacenter.

Rozwiązanie w 9.2 z prefix lists: Definiujemy trzy prefix lists: pl-tenant-a (10.100.0.0/16 le 28), pl-tenant-b (10.101.0.0/16 le 28), pl-tenant-c (10.102.0.0/16 le 28). Route map rm-bgp-export permittuje wyłącznie te zakresy – cała przestrzeń management (10.0.0.0/8 poza tenantami) jest blokowana. Każdy tenant widzi tylko swoje sieci w BGP, niezależnie od konfiguracji VM. Zmiana zajmuje 20 minut w GUI, bez restartu usług SDN.

Route maps i prefix lists w Proxmox SDN są implementowane przez wbudowany FRRouting (FRR). Konfiguracja przez pvesh lub GUI jest tłumaczona na natywne polecenia FRR – zaawansowani administratorzy mogą weryfikować stan BGP bezpośrednio przez vtysh na węzłach klastra.

11. Jak zaktualizować Proxmox VE 9.1 do 9.2?

Proxmox VE 9.2 jest dostępny przez standardowy mechanizm APT. Aktualizacja istniejącej instalacji jest prosta i nie wymaga reinstalacji systemu.

Wymagania wstępne

Przed aktualizacją upewnij się, że: wszystkie węzły klastra mają aktywną subskrypcję enterprise (lub używają repozytorium no-subscription), wykonany jest pełny backup wszystkich VM przez PBS, Proxmox VE 9.1 jest aktualny (wszystkie dostępne aktualizacje 9.1.x zainstalowane).

Procedura aktualizacji – każdy węzeł klastra (jeden po drugim)

# 1. OPCJONALNIE: Zatrzymaj HA dla bezpieczniejszego upgrade'u
ha-manager disarm

# 2. Sprawdź aktualne repozytoria (dla subskrypcji enterprise)
cat /etc/apt/sources.list.d/pve-enterprise.list
# Powinna być: deb https://enterprise.proxmox.com/debian/pve bookworm pve-enterprise
# Dla no-sub:
# deb http://download.proxmox.com/debian/pve bookworm pve-no-subscription

# 3. Odśwież listy pakietów
apt update

# 4. Sprawdź co zostanie zaktualizowane (bezpieczna weryfikacja)
apt list --upgradable 2>/dev/null | grep pve

# 5. Wykonaj pełny dist-upgrade
apt dist-upgrade -y

# 6. Zrestartuj węzeł (wymagany dla nowego kernela 7.0)
reboot

# 7. Po restarcie – weryfikacja wersji
pveversion -v
# Oczekiwane: proxmox-ve: 9.2-x

# 8. Po upgrade wszystkich węzłów – przywróć HA
ha-manager arm

Wykonuj aktualizację rolling – jeden węzeł naraz. Przed drain’owaniem węzła w klastrze HA upewnij się, że pozostałe węzły mają wystarczające zasoby do obsługi VM ze wszystkich 3 (lub więcej) węzłów jednocześnie. Nigdy nie aktualizuj wszystkich węzłów równocześnie w środowisku produkcyjnym.

Szybka weryfikacja nowych funkcji po upgrade

Weryfikacja Dynamic Load Balancer

# Sprawdź konfigurację CRS
pvesh get /cluster/options | grep crs

# Włącz DLB (jeśli nie jest domyślnie aktywny)
pvesh set /cluster/options --crs ha,monitor

# Weryfikacja statusu HA (po arm)
ha-manager status

# Sprawdzenie dostępności WireGuard w SDN
pvesh get /cluster/sdn/fabrics # powinien zwrócić listę fabrics

12. Kiedy warto – a kiedy poczekać?

Analiza: Aktualizować do 9.2 czy pozostać na 9.1.6?

Zaktualizuj teraz, jeśli…

• Zarządzasz klastrem wielowęzłowym z nierównomiernymi obciążeniami
• Regularnie przeprowadzasz maintenance windows i cierpisz z powodu HA failoverów
• Planujesz wdrożenie VPN/WireGuard między lokalizacjami w SDN
• Posiadasz heterogeniczny klaster CPU (AMD + Intel) i potrzebujesz niestandardowych modeli
• Budujesz nowe środowisko – warto startować od 9.2
• Twój klaster jest mały (1-3 węzły) i nie masz czasu na ręczne zarządzanie balansowaniem

Poczekaj, jeśli…

• Masz krytyczne środowisko produkcyjne bez testowego klastra do walidacji
• Używasz specyficznych Ceph workflows – najpierw zwaliduj na staging
• Twoje środowisko jest stabilne na 9.1.6 i żadna z nowości 9.2 nie jest Ci potrzebna
• Chcesz poczekać na pierwsze poprawki (9.2.1) – rozsądne dla środowisk ultra-krytycznych
• Masz aktywne projekty integracyjne zależne od konkretnych wersji pakietów

13. FAQ – najczęstsze pytania o Proxmox VE 9.2

Co to jest Dynamic Load Balancer i jak działa w Proxmox VE 9.2?

Dynamic Load Balancer (DLB) w Proxmox VE 9.2 to mechanizm zintegrowany z Cluster Resource Scheduler, który w czasie rzeczywistym monitoruje zużycie zasobów (CPU, RAM) na węzłach klastra i automatycznie inicjuje live-migration maszyn wirtualnych z przeciążonych węzłów na mniej zajęte. Różni się od poprzedniego CRS tym, że działa ciągle, a nie tylko w momencie uruchamiania VM. Respektuje reguły HA zdefiniowane przez administratora.

Czy Proxmox VE 9.2 obsługuje WireGuard natywnie?

Tak. Proxmox VE 9.2 wprowadza natywne WireGuard Fabric jako typ sieci w warstwie SDN (Software-Defined Networking). Tunele WireGuard można tworzyć, edytować i usuwać bezpośrednio z interfejsu webowego Proxmox (Datacenter → SDN), bez potrzeby konfigurowania zewnętrznych skryptów czy osobnych narzędzi.

Na jakim kernelu działa Proxmox VE 9.2?

Proxmox VE 9.2 używa jądra Linux 7.0 jako domyślnego stabilnego kernela. System bazuje na Debianie 13.5 (Trixie). Użytkownicy mogą nadal uruchamiać poprzednie jądro przez GRUB jeśli potrzebują kompatybilności z konkretnym sprzętem.

Jak zaktualizować Proxmox VE 9.1.6 do 9.2?

Aktualizacja odbywa się przez standardowy menedżer pakietów APT: apt update && apt dist-upgrade. Należy wykonać rolling update – jeden węzeł klastra na raz. Przed aktualizacją zalecane jest: wykonanie backupów wszystkich VM, opcjonalne uruchomienie ha-manager disarm oraz zaplanowanie restartu węzła po aktualizacji (wymagany dla nowego kernela 7.0).

Czym jest funkcja ha-manager disarm i do czego służy?

Funkcja ha-manager disarm tymczasowo wstrzymuje działanie HA Manager w całym klastrze. Oznacza to, że podczas np. planowych okien serwisowych, aktualizacji węzłów czy serwisowania hardware’u, HA Manager nie inicjuje niepotrzebnych failoverów, fencingów węzłów ani migracji VM. Po zakończeniu maintenance administratorzy wznawiają HA Manager komendą ha-manager arm, a maszyny wirtualne wracają do poprzedniego stanu.

Czy Proxmox VE 9.2 obsługuje Ceph Tentacle?

Tak. Proxmox VE 9.2 jako pierwsza wersja platformy oferuje Ceph Tentacle 20.2.1 jako stabilną opcję, obok dotychczasowego Ceph Squid 19.2.3. Istniejące klastry nie muszą migrować do Tentacle przy okazji upgrade’u Proxmox – migracja Ceph to oddzielna, zaplanowana procedura.

Co to są niestandardowe modele CPU w Proxmox i dlaczego nowy GUI jest ważny?

Niestandardowe modele CPU pozwalają administratorom precyzyjnie kontrolować, jakie flagi procesora (np. AVX-512, AES-NI, SHA-NI) są widoczne dla maszyn wirtualnych. Jest to kluczowe w klastrach heterogenicznych (różne generacje CPU), gdzie VM muszą być migrowane między węzłami. W wersji 9.2 zarządzanie modelami CPU przeniesiono do interfejsu webowego (Datacenter → Guest Resources/Hardware), co eliminuje potrzebę ręcznej edycji pliku konfiguracyjnego. Nowy selektor flag pokazuje też, które flagi są kompatybilne z wszystkimi węzłami klastra, co zapobiega błędom migracji.

Proxmox VE 9.2 vs VMware vSphere – czy DLB dorównuje DRS?

Distributed Resource Scheduler (DRS) VMware vSphere to dojrzały produkt enterprise z wieloma latami rozwoju i bardziej zaawansowanymi opcjami konfiguracji (np. VM/host affinity, resource pools, predykcyjny DRS z vROps). Dynamic Load Balancer Proxmox 9.2 to pierwszy krok w tę stronę – oferuje automatyczną migrację VM opartą na real-time metrykach i respektuje reguły HA. Dla większości zastosowań MSP, enterprise mid-market i środowisk akademickich DLB Proxmox będzie wystarczający i ma tę przewagę, że jest w 100% open source bez kosztów licencji.

14. Wnioski końcowe

Proxmox VE 9.2 to ewolucja, a nie rewolucja – ale ewolucja w punktach, które boli najbardziej w codziennym zarządzaniu infrastrukturą wirtualizacyjną. Dynamic Load Balancer rozwiązuje problem nierównomiernego rozłożenia obciążeń, który w 9.1.6 wymagał interwencji administratora lub zewnętrznych skryptów. Natywny WireGuard i BGP w SDN eliminują konieczność budowania osobnych warstw VPN poza Proxmox. GUI dla modeli CPU upraszcza zarządzanie klastrami heterogenicznymi. HA arm/disarm sprawia, że okna serwisowe przestają być źródłem stresu.

Wersja 9.2 jest szczególnie wartościowa dla środowisk klastrowych od 3 węzłów w górę, gdzie DLB i SDN-BGP/WireGuard dostarczają natychmiastowej wartości. Dla instalacji jednonodowych lub bardzo małych klastrów bez zaawansowanych wymagań sieciowych, nowości 9.2 są mniej istotne – choć aktualizacja stosu (kernel 7.0, QEMU 11.0, ZFS 2.4) i tak jest rekomendowana dla aktualności bezpieczeństwa.

Proxmox VE systematycznie dojrzewa jako platforma enterprise – i wersja 9.2 jest kolejnym krokiem w kierunku funkcjonalnego parytetu z rozwiązaniami komercyjnymi, zachowując jednocześnie otwartość, elastyczność i brak kosztów licencji, które są jego fundamentalną przewagą.

Proxmox VE 9.2 jest dostępny do pobrania na proxmox.com/en/downloads. Pełne release notes: pve.proxmox.com/wiki/Roadmap. Wsparcie community: forum.proxmox.com. Subskrypcja enterprise od 120 EUR/rok/CPU.