Zmiana adresacji klastra Proxmox: Przejście na podsieć .77

Ostatnio przenosiłem swoje maszyny wirtualne wraz z Proxmoxem z podsieci 192.168.1.x na 192.168.77.x. Oto instrukcja, jak zrobić to dobrze i jak uratować system, gdy “rozjedzie się” kworum.

Największy błąd, jaki popełniłem: zmiana adresu IP w ustawieniach sieciowych (GUI) przed poinformowaniem klastra o planowanej zmianie. Efekt? Węzły przestały się widzieć, a system plików /etc/pve przeszedł w tryb read-only.

Edycja klastra - corosync.conf

Zanim fizycznie zmienisz IP w zakładce “Network”, musisz zaktualizować plik konfiguracyjny klastra z poziomu konsoli:

1

vim /etc/pve/corosync.conf

Kluczowe zmiany:

W sekcji nodelist podmień stare adresy ring0_addr na nowe (np. z .1.x na .77.x).

Dopiero teraz logujemy się przez SSH (lub konsolę lokalną) i zmieniamy adres fizyczny:

1. Wybierz węzeł -> System -> Network
2. Edytuj vmbr0 i zmień adres IP oraz bramę (Gateway)
3. Kliknij Apply Configuration

Co jeśli stracisz kworum?

Jeżeli zmienisz IP zbyt szybko, Proxmox “zgłupieje”. Zobaczy, że brakuje mu węzłów do głosowania i zablokuje możliwość edycji plików (nawet chmod nie pomoże).

Jak to naprawiłem:

Wróciłem na chwilę do starej adresacji, aby odzyskać dostęp.

Po wszystkim trzeba pamiętać o zaktualizowaniu pliku /etc/hosts na każdym węźle.

Podsumowanie plików i usług

• Plik sieci: /etc/network/interfaces
• Konfiguracja klastra: /etc/pve/corosync.conf
• Usługi do restartu: systemctl restart corosync pve-cluster
• Weryfikacja: Komenda pvecm status (szukaj: Quorum: Yes)

Problem: Błąd 595 (No route to host)

Po zmianie IP w /etc/network/interfaces i /etc/pve/corosync.conf, status klastra w konsoli (pvecm status) był zielony, ale GUI Proxmoxa zwariowało. Przy próbie kliknięcia w drugi węzeł pojawiał się błąd: Connection error 595: No route to host. Statystyki CPU/RAM nie ładowały się, mimo że pingi między serwerami działały. Drugi węzeł był dostępny tylko wtedy, gdy wchodziłem bezpośrednio na jego adres IP.

W moim przypadku przyczyną było kilka błędów:

1. DNS: Pliki /etc/hosts na obu maszynach wciąż wskazywały stare adresy.
2. Routing: Główny węzeł (będący routerem) próbował wysyłać zapytania do drugiego węzła przez bramę dostawcy internetu zamiast lokalnie.
3. Zaufanie SSH: Po zmianie IP klucze w known_hosts przestały pasować. System blokował połączenia ze względów bezpieczeństwa.
4. Cache Systemu Plików (pmxcfs): Nawet po poprawieniu plików tekstowych Proxmox wciąż trzymał stare certyfikaty powiązane ze starymi adresami IP w swojej wewnętrznej bazie danych.

Rozwiązanie problemu 595

To są kroki, które ostatecznie naprawiły klaster:

• Poprawienie /etc/hosts: Upewnij się, że oba węzły mają wpisane nowe IP pod swoimi nazwami (identycznie na obu!).

• Reset kluczy SSH: Usuń stare wpisy i ręcznie zaloguj się przez SSH z jednego węzła na drugi, aby zaakceptować nowy odcisk palca (fingerprint):

  1 2	rm /root/.ssh/known_hosts ssh 192.168.77.x

• Wymuszenie adresu słuchania: Dodanie LISTEN_IP="192.168.77.1" w /etc/default/pveproxy, aby Proxmox-Router wiedział, którym interfejsem ma rozmawiać z klastrem.

• Odświeżenie certyfikatów: Wymuś wygenerowanie nowych certyfikatów zgodnych z aktualną konfiguracją:

  1 2	pvecm updatecerts -f systemctl restart pve-cluster

Inna opcja

Rozważałem całkowite “zaoranie” bazy klastra poprzez usunięcie /var/lib/pve-cluster/config.db i restartowanie pmxcfs na czysto. Na szczęście pvecm updatecerts -f wystarczyło.