Troubleshooting | przeqpiciel's site

Jak zmienić nazwę klastra Proxmox

przeqpiciel — Thu, 09 Jul 2026 00:00:00 +0000

Wstęp

Zakładałeś klaster pewnie w pośpiechu - dwa, trzy node’y, trzeba było wybrać jakąś nazwę, więc powstało coś w stylu test, pve-cluster albo, co gorsza, nazwa firmy, z której się w międzyczasie wyprowadziłeś. Miesiące później nazwa razi w oczy przy każdym pvecm status, a Ty otwierasz dokumentację w nadziei na proste pvecm rename. Nie znajdziesz takiej komendy. Oficjalna dokumentacja Proxmox wprost mówi o nazwie klastra: “Use a unique name for your cluster. This name cannot be changed later.” Krótko: nie da się. A jednak - da się, tylko nie przyciskiem w GUI, tylko ręczną edycją configu i zrozumieniem, co się dzieje pod maską. W tym wpisie pokażę jak to zrobić w miarę bezpiecznie, dlaczego Proxmox tego nie ułatwia i na co uważać, zanim wydasz pierwsze systemctl restart corosync.

🚨

To jest procedura nieoficjalna i niewspierana przez Proxmox. Działa, jest opisywana i stosowana przez społeczność (m.in. na forum Proxmox), ale robisz to na własną odpowiedzialność. Na produkcji rób to w oknie serwisowym i miej pewność, że backup /etc/pve oraz konfiguracji VM-ek jest aktualny.

Dlaczego to nie jest proste

Nazwa klastra w Proxmox nie jest osobnym ustawieniem gdzieś w bazie - to parametr cluster_name w sekcji totem pliku /etc/pve/corosync.conf. Ten plik żyje w pmxcfs - specjalnym systemie plików opartym o bazę SQLite, który w czasie rzeczywistym replikuje konfigurację klastra do wszystkich node’ów. Corosync odpowiada za komunikację między node’ami i ustalanie kworum, a cluster_name jest jego identyfikatorem klastra używanym w tym protokole.

Problem w tym, że każda zmiana w corosync.conf musi być zsynchronizowana wszędzie naraz, a config_version w pliku to jedyny mechanizm, który mówi node’om “to jest nowsza wersja configu, zaakceptuj ją”. Jeśli zmienisz nazwę i zrestartujesz corosync tylko na części node’ów, przez chwilę będziesz mieć dwie grupy demonów corosync, które nie chcą się ze sobą dogadać, bo każda widzi inną tożsamość klastra w pamięci procesu, dopóki nie przeładuje configu. W praktyce trwa to sekundy, ale przy klastrze z HA i uruchomionymi maszynami lepiej to zrobić świadomie niż na hura.

Stąd ostrożność w oficjalnej dokumentacji - to nie jest funkcja, której ktoś w Proxmox testował na wszystkich możliwych topologiach (QDevice, wiele linków corosync, HA), więc zamiast ją wspierać połowicznie, wolą napisać “nie da się”.

Zanim zaczniesz

Kilka rzeczy do sprawdzenia przed edycją:

Masz dostęp SSH do każdego node’a w klastrze - zmianę trzeba wprowadzić wszędzie, nie tylko tam, gdzie akurat jesteś zalogowany.
Klaster ma kworum (pvecm status pokazuje Quorate: Yes). Nie baw się w to w trakcie awarii sieciowej czy przy martwym node’zie.
Masz kopię /etc/pve/corosync.conf na wszelki wypadek, np. cp /etc/pve/corosync.conf ~/corosync.conf.bak.
Używasz QDevice? Po zmianie nazwy będziesz musiał go usunąć i dodać ponownie - certyfikat QDevice jest powiązany ze starą nazwą klastra i po zmianie zacznie zgłaszać błędy o nieprawidłowym certyfikacie.

Krok po kroku: zmiana nazwy klastra

1. Sprawdź obecny stan

Na dowolnym node’zie:

pvecm status
cat /etc/pve/corosync.conf

Zwróć uwagę na sekcję totem i aktualny config_version w sekcji cluster. Będziesz go za chwilę potrzebować.

totem {
 cluster_name: stary-klaster
 config_version: 4
 ...
}

cluster {
 config_version: 4
 ...
}

W nowszych wersjach Proxmox config_version bywa też osobno w bloku cluster na końcu pliku - podbij obie wartości, jeśli obie występują.

2. Edytuj corosync.conf

Plik /etc/pve/corosync.conf wystarczy edytować na jednym node’zie - to katalog /etc/pve/ jest tym magicznym, replikowanym przez pmxcfs, więc zmiana rozejdzie się sama, o ile jest poprawna składniowo i ma wyższy config_version.

nano /etc/pve/corosync.conf

Zmieniasz cluster_name i podbijasz config_version o dokładnie 1:

 totem {
- cluster_name: stary-klaster
+ cluster_name: homelab-xl
 config_version: 4
+ config_version: 5
 ...
 }

⚠️

Nie skacz z config_version o więcej niż 1 i nie zapomnij go podbić w ogóle - pmxcfs porówna wersję nowego pliku z lokalną kopią na każdym node’zie i odrzuci zmianę, jeśli wersja nie jest wyższa. Zbyt duży skok też bywa problematyczny przy kolejnych edycjach, bo tracisz orientację, na jakiej wersji naprawdę jesteś.

Zapisujesz plik. Jeśli składnia jest błędna albo config_version się nie zgadza, pmxcfs po prostu zignoruje zmianę - sprawdź to od razu:

cat /etc/pve/corosync.conf

Jeśli widzisz nową nazwę - zmiana przeszła walidację i pmxcfs zaczął ją replikować do pozostałych node’ów. Możesz to potwierdzić, odpytując inny node w klastrze - zawartość /etc/pve/corosync.conf powinna się tam zgadzać w ciągu kilku sekund.

3. Zrestartuj corosync na każdym node’zie

Corosync trzyma nazwę klastra w pamięci od momentu startu procesu, więc sam zapis pliku jej nie zmieni w działającym demonie. Trzeba go zrestartować - na każdym node’zie z osobna, jeden po drugim, nie równolegle:

systemctl restart corosync

Po restarcie na pierwszym node’zie sprawdź pvecm status - node powinien nadal widzieć klaster (bo pozostałe wciąż działają na starym configu w pamięci, ale to ten sam config_version z tożsamej bazy, więc się dogadają). Dopiero jak przejdziesz przez wszystkie node’y, cały klaster jednomyślnie operuje na nowej nazwie.

4. Zrestartuj pve-cluster i pveproxy

Sama nazwa w GUI (i część wewnętrznych mechanizmów PVE, np. pvestatd) czyta ją z pmxcfs, więc żeby zobaczyć efekt w interfejsie webowym, restartujesz jeszcze:

systemctl restart pve-cluster
systemctl restart pveproxy

Zrób to na każdym node’zie. Odśwież przeglądarkę (najlepiej z czyszczeniem cache) - w lewym górnym rogu GUI powinieneś zobaczyć nową nazwę klastra.

5. QDevice, jeśli go używasz

Jeśli masz skonfigurowany QDevice do głosowania w klastrach o parzystej liczbie node’ów, po zmianie nazwy zobaczysz błędy o nieprawidłowym certyfikacie - certyfikat QDevice jest generowany dla konkretnej nazwy klastra. Usuwasz go i dodajesz ponownie:

pvecm qdevice remove
pvecm qdevice setup <adres_IP_QDevice>

Weryfikacja

Na koniec, na wszystkich node’ach:

pvecm status
corosync-cfgtool -s

pvecm status powinien pokazywać nową nazwę w polu Name, a corosync-cfgtool -s - że wszystkie linki (link: 0) są connected na każdym node’zie. Jeśli klaster ma HA, sprawdź jeszcze ha-manager status, żeby upewnić się, że menedżer HA nie zgubił się w międzyczasie.

Alternatywa bez restartu corosync

W sieci krąży też wariant bez restartu corosync na wszystkich node’ach naraz - edycja bezpośrednio w bazie pmxcfs przez sqlite3 na pliku /var/lib/pve-cluster/config.db, a potem restart usług pvestatd, pvedaemon, pve-cluster i corosync w jednej sekwencji. Wspominam o tym tylko dla kompletności - to jeszcze bardziej “za kulisami” niż edycja corosync.conf, bo omija normalną walidację configu przez pmxcfs, a przy błędzie w zapytaniu UPDATE łatwo o uszkodzenie bazy konfiguracyjnej całego klastra. Jeśli i tak wolisz iść tą drogą, zrób to najpierw na klastrze testowym.

Jeśli wolisz nie ryzykować

Jest jeszcze trzecia droga, najbezpieczniejsza: zamiast zmieniać nazwę istniejącego klastra, załóż nowy klaster pod docelową nazwą i przenieś do niego node’y i maszyny wirtualne jeden po drugim. Więcej roboty, zero ryzyka związanego z ręczną edycją corosync.conf na żywym organizmie. Warta rozważenia, jeśli klaster jest mały albo migrujesz sprzęt i tak planujesz reinstalację node’ów.

Podsumowanie

Proxmox nie daje przycisku do zmiany nazwy klastra, bo to funkcja, której oficjalnie nie testują i nie wspierają - ale mechanizm jest prosty do zrozumienia: cluster_name w /etc/pve/corosync.conf, podbity config_version, restart corosync na każdym node’zie po kolei, a na końcu pve-cluster i pveproxy po nową nazwę w GUI. Cała trudność bierze się nie z samej edycji pliku, a z tego, że robisz to na żywym klastrze, gdzie kolejność i cierpliwość między krokami mają znaczenie. Rób to w oknie serwisowym, miej backup corosync.conf pod ręką i przechodź przez node’y po kolei, a nie zaskoczy Cię nic więcej niż odświeżenie przeglądarki na końcu.

E1000e network card freeze

przeqpiciel — Tue, 28 Jan 2025 00:00:00 +0000

Zawieszenie karty sieciowej e1000e

Wstęp

Czy zdarzyło Ci się kiedyś, że Twój serwer, który działał bez problemów przez wiele dni, nagle przestał odpowiadać na sieć? Maszyna się nie restartowała, uruchomione procesy nadal działały, ale jakby zniknęła z sieci. Dokładnie z taką sytuacją miałem do czynienia ostatniej nocy. Rano odkryłem, że serwer jest fizycznie włączony, ale kompletnie nie odpowiada na żadne zapytania sieciowe - ani ping, ani SSH, ani żadne inne usługi sieciowe.

Odkrycie problemu

Po sprawdzeniu fizycznego stanu maszyny i podłączeniu monitora oraz klawiatury, system operacyjny działał normalnie. Interfejs sieciowy jednak nie odpowiadał, nawet lokalne testy ping do innych hostów w sieci kończyły się niepowodzeniem. Czas na śledztwo.

Diagnostyka za pomocą journalctl

Pierwszym krokiem w diagnostyce problemu z siecią w systemach Linux jest sprawdzenie logów jądra. Najlepszym narzędziem do tego celu jest journalctl z odpowiednimi parametrami. Polecenie journalctl -k -b -1 pozwala sprawdzić logi jądra z poprzedniego boot’a systemu, co jest szczególnie przydatne, gdy problem wystąpił przed aktualnym uruchomieniem systemu.

journalctl -k -b -1

Parametry tego polecenia oznaczają:

-k (lub --dmesg) - wyświetla tylko logi jądra
-b -1 - pokazuje logi z poprzedniego boot’a (boot -1 oznacza poprzedni boot, -2 poprzedni przed poprzednim, itd.)

W moim przypadku logi jądra ujawniły problem z kartą sieciową e1000e na interfejsie enp0s25:

Jan 10 08:10:28 pve.localhost kernel: e1000e 0000:00:19.0 enp0s25: Detected Hardware Unit Hang:
 TDH <82>
 TDT <8e>
 next_to_use <8e>
 next_to_clean <81>
 buffer_info[next_to_clean]:
 time_stamp <101fda64e>
 next_to_watch <82>
 jiffies <102048d40>
 next_to_watch.status <0>
 MAC Status <80083>
 PHY Status <796d>
 PHY 1000BASE-T Status <3800>
 PHY Extended Status <3000>
 PCI Status <10>

Komunikat “Detected Hardware Unit Hang” wskazuje na zawieszenie jednostki sprzętowej karty sieciowej e1000e. Karta wielokrotnie próbowała wykryć i naprawić problem, jednak komunikaty powtarzały się co około 2 sekundy, co sugerowało, że problem nie został automatycznie rozwiązany.

Dlaczego e1000e ma ten problem?

Sterownik e1000e obsługuje gigabitowe karty sieciowe Intel podłączane przez PCI Express (końcówka “e” w nazwie pochodzi właśnie od PCI Express, w odróżnieniu od starszego sterownika e1000 dla kart PCI). W moim przypadku problem był związany z funkcją EEE (Energy Efficient Ethernet). EEE to standard, który pozwala kartom sieciowym na zmniejszenie zużycia energii poprzez przełączanie się w tryb niskiego poboru mocy podczas bezczynności. Jednak implementacja tej funkcji może powodować problemy z niektórymi kartami lub przełącznikami sieciowymi, prowadząc do zawieszenia się karty.

Rozwiązanie problemu

Krok 1: Sprawdzenie ustawień EEE

Po zidentyfikowaniu problemu z logów jądra, sprawdziłem ustawienia EEE (Energy Efficient Ethernet) na interfejsie enp0s25:

ethtool --show-eee enp0s25

Wynik pokazał, że EEE było włączone, ale nieaktywne:

EEE settings for enp0s25:
	EEE status: enabled - inactive
	Tx LPI: 17 (us)
	Supported EEE link modes: 100baseT/Full
	 1000baseT/Full
	Advertised EEE link modes: 100baseT/Full
	 1000baseT/Full
	Link partner advertised EEE link modes: Not reported

Krok 2: Wyłączenie EEE

Na podstawie logów i statusu EEE, wyłączyłem funkcję Energy Efficient Ethernet:

ethtool --set-eee enp0s25 eee off

Po wyłączeniu EEE, sprawdziłem ponownie status:

ethtool --show-eee enp0s25

Wynik potwierdził wyłączenie:

EEE settings for enp0s25:
	EEE status: disabled
	Tx LPI: 17 (us)
	Supported EEE link modes: 100baseT/Full
	 1000baseT/Full
	Advertised EEE link modes: 100baseT/Full
	 1000baseT/Full
	Link partner advertised EEE link modes: Not reported

Po wyłączeniu EEE interfejs sieciowy zaczął działać normalnie, co potwierdziło, że to właśnie ta funkcja była przyczyną problemu.

Krok 3: Wyłączenie TSO, GSO i GRO

Jako dodatkowe zabezpieczenie, wyłączyłem również funkcje offloading’u TSO (TCP Segmentation Offload), GSO (Generic Segmentation Offload) i GRO (Generic Receive Offload):

sudo ethtool -K enp0s25 tso off gso off gro off

Te funkcje mogą czasami powodować problemy ze stabilnością, szczególnie w połączeniu z EEE. Warto sprawdzić, czy ta zmiana poprawia stabilność karty.

Funkcje te można włączyć ponownie poleceniem:

sudo ethtool -K enp0s25 tso on gso on gro on

Zapobieganie problemom z kartą e1000e

Krok 1: Trwałe wyłączenie EEE

Aby upewnić się, że EEE pozostanie wyłączone po restarcie systemu, należy utworzyć skrypt, który będzie automatycznie wyłączał tę funkcję przy każdym starcie interfejsu sieciowego. W systemach używających systemd-networkd możemy skorzystać z mechanizmu networkd-dispatcher:

# Utworzenie katalogu, jeśli nie istnieje
sudo mkdir -p /etc/networkd-dispatcher/routable.d

# Utworzenie skryptu
sudo nano /etc/networkd-dispatcher/routable.d/50-eee-off

Zawartość skryptu:

#!/bin/bash
ethtool --set-eee enp0s25 eee off

Nadanie uprawnień wykonywania:

sudo chmod +x /etc/networkd-dispatcher/routable.d/50-eee-off

Alternatywnie, jeśli networkd-dispatcher nie jest dostępny, można użyć innych metod:

Opcja A: Użycie /etc/rc.local

# Edytuj plik /etc/rc.local (pamiętaj o dodaniu linii przed "exit 0")
sudo nano /etc/rc.local

Dodaj przed exit 0:

ethtool --set-eee enp0s25 eee off

Opcja B: Użycie NetworkManager dispatcher

Jeśli używasz NetworkManager:

sudo mkdir -p /etc/NetworkManager/dispatcher.d
sudo nano /etc/NetworkManager/dispatcher.d/50-eee-off

Zawartość:

#!/bin/bash
if [ "$1" == "enp0s25" ] && [ "$2" == "up" ]; then
 ethtool --set-eee enp0s25 eee off
fi

sudo chmod +x /etc/NetworkManager/dispatcher.d/50-eee-off

Opcja C: Utworzenie jednostki systemd

Można również utworzyć jednostkę systemd, która będzie wykonywana po starcie sieci:

sudo nano /etc/systemd/system/disable-eee.service

Zawartość:

[Unit]
Description=Disable EEE on enp0s25
Wants=network-online.target
After=network-online.target

[Service]
Type=oneshot
ExecStart=/usr/sbin/ethtool --set-eee enp0s25 eee off
RemainAfterExit=yes

[Install]
WantedBy=multi-user.target

Włączenie usługi:

sudo systemctl enable disable-eee.service
sudo systemctl start disable-eee.service

Krok 2: Trwałe wyłączenie TSO, GSO i GRO

Jeśli wyłączenie TSO, GSO i GRO pomogło, warto również ustawić te parametry na stałe. Możemy to zrobić w ten sam sposób - dodając polecenia do skryptu wyłączającego EEE:

sudo nano /etc/networkd-dispatcher/routable.d/50-eee-off

Zaktualizowana zawartość:

#!/bin/bash
ethtool --set-eee enp0s25 eee off
ethtool -K enp0s25 tso off gso off gro off

Krok 3: Weryfikacja ustawień

Po zrestartowaniu systemu, warto sprawdzić, czy ustawienia zostały poprawnie zastosowane:

# Sprawdzenie EEE
ethtool --show-eee enp0s25

# Sprawdzenie TSO, GSO, GRO
ethtool -k enp0s25 | grep -E "tso|gso|gro"

Oczekiwany wynik dla EEE:

EEE status: disabled

Dla TSO, GSO, GRO powinno być:

tcp-segmentation-offload: off
generic-segmentation-offload: off
generic-receive-offload: off

Dlaczego te ustawienia pomagają?

EEE (Energy Efficient Ethernet) - może powodować problemy z synchronizacją między kartą a przełącznikiem, szczególnie przy niektórych modelach przełączników lub w określonych warunkach sieciowych
TSO/GSO/GRO (Offloading) - te funkcje przenoszą część przetwarzania pakietów z CPU na kartę sieciową. Chociaż mogą zwiększać wydajność, czasami mogą powodować problemy ze stabilnością, szczególnie w środowisku wirtualizacji lub przy niektórych kombinacjach sprzętowych

Jeśli problem nadal występuje po wyłączeniu EEE, warto spróbować również wyłączyć offloading, co często rozwiązuje problemy ze stabilnością kart e1000e.

Podsumowanie

Problem z zawieszeniem się karty sieciowej e1000e jest znaną usterką, która może wystąpić w systemach z kartami Intel korzystającymi z tego sterownika. W moim przypadku przyczyną była funkcja EEE (Energy Efficient Ethernet), która pomimo swoich zalet w zakresie oszczędzania energii, może powodować problemy ze stabilnością.

Podstawową metodą diagnozy jest sprawdzenie logów jądra za pomocą journalctl -k -b -1, co pozwala zobaczyć, co działo się w systemie przed jego ostatnim restartem. Komunikaty “Detected Hardware Unit Hang” jednoznacznie wskazują na problem z kartą sieciową.

Rozwiązanie problemu polega na wyłączeniu funkcji EEE za pomocą ethtool --set-eee enp0s25 eee off, a następnie skonfigurowaniu systemu tak, aby to ustawienie było trwałe. W przypadku gdy to nie wystarczy, warto również wyłączyć funkcje offloading’u TSO, GSO i GRO.

Pamiętaj, że problemy z siecią mogą mieć różne przyczyny - zawsze warto sprawdzić logi systemowe i rozpocząć diagnostykę od podstawowych kroków, takich jak sprawdzenie połączenia fizycznego, konfiguracji sieciowej i logów jądra. W przypadku kart e1000e, wyłączenie EEE jest często pierwszym krokiem, który rozwiązuje problemy ze stabilnością.