Aktualizacje Proxmox VE bez przestoju — repozytoria, kolejność w klastrze i upgrade 8 → 9

2 listopada 2026 · 4 min czytania · Paweł Burzyński

ProxmoxAktualizacjeUpgradeKlaster

Proxmox VE aktualizuje się jak zwykły Debian, ale hostuje produkcję, więc „apt upgrade i reboot" to za mało. Przy jednym hoście przestój jest nieunikniony, da się go jednak skrócić do jednego restartu. W klastrze można zaktualizować wszystko bez wyłączania ani jednej maszyny. Pokażę oba scenariusze oraz przebieg dużego skoku wersji 8 → 9 (Debian 12 → 13).

Krok 0: właściwe repozytoria

Najczęstszy błąd to brak jakiegokolwiek repozytorium Proxmoksa. Świeża instalacja ma włączone pve-enterprise, które bez subskrypcji zwraca błąd 401 i wtedy apt aktualizuje tylko pakiety Debiana, a jądro i narzędzia PVE stoją w miejscu miesiącami.

Bez subskrypcji włącz repozytorium pve-no-subscription. W PVE 8 (Debian 12):

sed -i 's/^deb/#deb/' /etc/apt/sources.list.d/pve-enterprise.list
sed -i 's/^deb/#deb/' /etc/apt/sources.list.d/ceph.list
echo "deb http://download.proxmox.com/debian/pve bookworm pve-no-subscription" \
  > /etc/apt/sources.list.d/pve-no-subscription.list
apt update

W PVE 9 repozytoria są w formacie deb822 (pliki .sources). Łatwiej zrobić to z GUI: Node → Repositories → Add → No-Subscription, a enterprise wyłączyć przyciskiem Disable. Sprawdź wynik:

apt update 2>&1 | grep -iE "err|warn"
pveversion -v | head -5

Jeśli masz subskrypcję, zostaw enterprise. To repozytorium dostaje te same pakiety, ale kilka tygodni później i po dodatkowych testach, co na produkcji jest zaletą.

Pojedynczy host: minimalny przestój

Na hoście bez klastra maszyn nie ma gdzie przenieść, więc liczy się tylko to, by restart był jeden i przewidywalny.

# 1. kopia konfiguracji hosta
tar czf /root/etc-$(hostname)-$(date +%F).tgz /etc/pve /etc/network/interfaces /etc/apt

# 2. aktualizacja (dist-upgrade, nie upgrade!)
apt update && apt dist-upgrade -y

# 3. czy potrzebny restart?
if [ "$(uname -r)" != "$(dpkg -l 'proxmox-kernel-*' 2>/dev/null | awk '/^ii/{print $2}' | sed 's/proxmox-kernel-//' | grep -v signed | sort -V | tail -1)" ]; then
  echo "Nowe jądro — zaplanuj restart"
fi

Używaj dist-upgrade (lub full-upgrade). Zwykłe apt upgrade nie instaluje nowych zależności i potrafi zostawić host w stanie „pół-zaktualizowanym", którego Proxmox oficjalnie nie wspiera.

Restart jest konieczny tylko po nowym jądrze lub mikrokodzie CPU. Aktualizacje pve-manager, qemu-server czy pve-firewall restartują same swoje usługi bez przerwy w pracy VM. Uwaga: nowy pve-qemu-kvm zaczyna obowiązywać dla danej maszyny dopiero po jej zatrzymaniu i uruchomieniu (nie po reboot z poziomu gościa).

Przed restartem włącz w opcjach VM Start at boot z sensownym Startup order i Startup delay, żeby bazy danych wstały przed aplikacjami.

Klaster: zero przestoju węzeł po węźle

W klastrze z współdzielonym storage (lub replikacją ZFS) procedura jest prosta i powtarzalna. Dla każdego węzła z osobna:

# na aktualizowanym węźle, np. pve1
pvecm status | grep -E "Quorate|Nodes"       # kworum musi być Yes

# przenieś wszystkie VM i kontenery na inne węzły
ha-manager crm-command node-maintenance enable pve1   # PVE 7.3+: tryb konserwacji dla zasobów HA
qm list | awk 'NR>1 && $3=="running"{print $1}' | while read id; do
  qm migrate $id pve2 --online
done
pct list | awk 'NR>1 && $2=="running"{print $1}' | while read id; do
  pct migrate $id pve2 --restart
done

Tryb konserwacji powoduje, że HA Manager sam migruje zasoby HA i nie wraca z nimi, dopóki węzeł jest w konserwacji. Pozostałe maszyny przenosi pętla powyżej. Kontenery LXC nie mają migracji na żywo, --restart oznacza kilkusekundową przerwę, dlatego kontenery krytyczne lepiej aktualizować w oknie serwisowym.

Gdy węzeł jest pusty:

apt update && apt dist-upgrade -y
reboot
# po powrocie
pveversion
ha-manager crm-command node-maintenance disable pve1

Powtórz na kolejnym węźle dopiero wtedy, gdy poprzedni jest z powrotem w klastrze (pvecm status). Nigdy nie aktualizuj dwóch węzłów naraz w klastrze trzywęzłowym, bo przy restarcie jednego z nich stracisz kworum.

Jeśli masz Ceph, kolejność jest sztywna: najpierw monitory, potem managery, OSD, na końcu MDS i klienci. Przed restartem węzła z OSD ustaw ceph osd set noout, a po powrocie ceph osd unset noout.

Duży upgrade: PVE 8 → PVE 9

Skok główny wymaga więcej uwagi, ale schemat jest ten sam. Zanim zaczniesz:

apt update && apt dist-upgrade -y     # host musi być na najnowszym 8.4
pveversion                            # pve-manager/8.4.x
pve8to9 --full

Skrypt pve8to9 sprawdza kilkadziesiąt rzeczy: repozytoria, wolne miejsce, konflikty pakietów, stare nazwy interfejsów, Ceph i nieobsługiwane konfiguracje. Każdy FAIL napraw przed upgrade'em, każdy WARN przeczytaj. Uruchamiaj skrypt kilka razy, aż wynik będzie czysty.

Osobna pułapka: Debian 13 może zmienić nazwy interfejsów sieciowych (np. enp5s0 → enp5s0f0). Po upgrade'cie taki host wstaje bez sieci. Zabezpiecz się przypinając nazwy do adresów MAC:

cat > /etc/systemd/network/10-eth0.link <<EOF
[Match]
MACAddress=aa:bb:cc:dd:ee:ff
[Link]
Name=eth0
EOF

i wpisz to samo eth0 do /etc/network/interfaces jako port bridża. Właściwy upgrade:

sed -i 's/bookworm/trixie/g' /etc/apt/sources.list /etc/apt/sources.list.d/*.list
# jeśli masz Ceph: analogicznie zamień repo ceph na trixie zgodnie z dokumentacją
apt update
apt dist-upgrade

Rób to w tmux lub screen, a najlepiej z konsoli IPMI/KVM, bo upgrade wymienia pakiety sieciowe. Pytania o pliki konfiguracyjne (/etc/issue, /etc/lvm/lvm.conf, /etc/ssh/sshd_config) zostaw na domyślnej odpowiedzi „keep current version", chyba że wiesz, co zmieniasz. Po zakończeniu:

pve8to9 --full      # powinno być czysto
reboot
pveversion          # pve-manager/9.x, jądro 6.14+

W klastrze PVE 8 i 9 mogą działać obok siebie tylko przejściowo, na czas upgrade'u. Migracja na żywo z 8 na 9 działa, w drugą stronę nie, więc aktualizuj węzły po kolei i nie przenoś maszyn z powrotem na stare węzły.

Po aktualizacji: trzy szybkie testy

systemctl --failed na hoście — lista ma być pusta.
pvesm status — każdy storage active, nic inactive.
Jedna testowa migracja na żywo tam i z powrotem między zaktualizowanymi węzłami.

Dopiero po tych trzech testach wyłącz tryb konserwacji i przenieś produkcję. Ta godzina ostrożności raz na kwartał jest tańsza niż noc spędzona na odzyskiwaniu hosta po nieudanym upgrade'cie.