Proxmox aktualisieren, ohne dass Gäste stehen

Updates auf einem Hypervisor sind unangenehmer als auf einem einzelnen Server: Ein Neustart nimmt alle Gäste mit. Mit einer festen Reihenfolge ist das trotzdem planbar und in einem Cluster sogar ohne Ausfall.

Zuerst: das richtige Repository#

Nach der Installation zeigt Proxmox auf das Enterprise-Repository, für das ein Abonnement nötig ist. Ohne Abo schlägt jedes apt update mit einem 401 fehl und das ist der Grund, warum manche Installationen monatelang keine Updates bekommen.

# Was ist eingetragen?
cat /etc/apt/sources.list.d/*.list /etc/apt/sources.list.d/*.sources 2>/dev/null | grep -v "^#"

Ohne Abo ist No-Subscription die richtige Wahl und nicht, das Enterprise-Repository stehen zu lassen und Updates zu vergessen.

# Enterprise deaktivieren, No-Subscription eintragen (Pfad je nach Version)
sed -i 's/^deb/#deb/' /etc/apt/sources.list.d/pve-enterprise.list
echo "deb http://download.proxmox.com/debian/pve $(. /etc/os-release && echo $VERSION_CODENAME) pve-no-subscription" \
  > /etc/apt/sources.list.d/pve-no-subscription.list
apt update

Vorher: der Zustand, auf den du zurückkannst#

# 1. Läuft die Sicherung, und ist sie frisch?
pvesm status
ls -la /var/lib/vz/dump/ | tail
# bzw. auf dem PBS die letzten Sicherungspunkte prüfen

# 2. Was ist aktuell installiert? (für den Vergleich danach)
pveversion -v > /root/pveversion-vor-update-$(date +%F).txt

# 3. Cluster gesund?
pvecm status
ha-manager status

Der Rest steht in Proxmox Backup Server, mit dem Punkt, der zählt: Eine Sicherung, aus der noch nie zurückgespielt wurde, ist vor einem Hypervisor-Update kein Sicherheitsnetz.

Einzelner Host#

apt update && apt list --upgradable
apt dist-upgrade            # bei Proxmox richtig, nicht "apt upgrade"

dist-upgrade ist hier korrekt: Proxmox-Pakete ändern regelmäßig Abhängigkeiten, und apt upgrade hält genau diese zurück, mit dem Ergebnis, dass Teile aktualisiert werden und andere nicht.

Ob ein Neustart nötig ist, entscheidet, was aktualisiert wurde:

# Läuft noch der alte Kernel?
uname -r
pveversion -v | grep -E "proxmox-kernel|pve-kernel"

# Welche Dienste benutzen gelöschte Bibliotheken?
apt install needrestart && needrestart -b

Kernel, pve-cluster, corosync und QEMU-Bibliotheken heißen: neu starten. Ein aktualisiertes QEMU wirkt für laufende Gäste erst nach einer Migration oder einem Stopp/Start, ein Neustart des Gastes von innen reicht dafür nicht.

Cluster: die Reihenfolge#

Hier ist der Ausfall vermeidbar, weil die Gäste weichen können.

1. Einen Knoten wählen, der gerade am wenigsten trägt.
2. Gäste wegmigrieren (live, ohne Unterbrechung):

ha-manager crm-command node-maintenance enable pve2   # HA-Gäste räumen sich selbst
# oder einzeln:
qm migrate 110 pve1 --online
pct migrate 210 pve1 --restart

3. Aktualisieren und neu starten.
4. Zurückholen, Wartungsmodus beenden, Cluster prüfen:

ha-manager crm-command node-maintenance disable pve2
pvecm status && ha-manager status

5. Erst dann der nächste Knoten. Nie zwei gleichzeitig, sonst kippt die Mehrheit, und der Watchdog macht genau das, wofür er da ist (Proxmox-HA).

Container und VMs im Gast#

Der Hypervisor ist die eine Hälfte. Die andere sind die Gäste und dort gilt, was in Container-Updates und Images steht. Ein Punkt, der Proxmox-eigen ist:

# Container-Vorlagen aktualisieren, damit neue Container nicht alt starten
pveam update && pveam available | tail

Und der Snapshot vor dem Gast-Update, der auf einem Raspberry Pi fehlt und hier zwei Sekunden kostet:

qm snapshot 110 vor-update-$(date +%F)
pct snapshot 210 vor-update-$(date +%F)

Danach#

pveversion -v | diff /root/pveversion-vor-update-*.txt - | head -20
systemctl --failed
journalctl -p err -b -n 40
qm list && pct list          # laufen alle Gäste wieder?

Was dabei auffällt, gehört ins eigene Protokoll und ein Update, das etwas kaputtgemacht hat, gehört notiert, nicht nur repariert.

Häufige Fragen#

Wie oft aktualisieren?#

Sicherheitsupdates zeitnah, Funktionsupdates in einem festen Rhythmus (monatlich ist üblich). Der schlechteste Rhythmus ist „wenn etwas nicht mehr geht“.

Muss ich das Abo kaufen?#

Musst du nicht. Es kauft dir getestetere Pakete und Support. Für einen Heimserver ist No-Subscription die verbreitete Wahl; wer für Kunden betreibt, sollte die Frage bewusst beantworten.

Kann ich Updates automatisieren?#

Sicherheitsupdates per unattended-upgrades ja, aber ohne automatischen Neustart. Ein Hypervisor, der sich nachts selbst neu startet, nimmt alle Gäste mit.

Warum läuft mein Gast nach dem Update mit alter QEMU-Version?#

Weil laufende Gäste ihren QEMU-Prozess behalten. Erst eine Live-Migration oder ein Stopp/Start übernimmt die neue Version. Im Cluster ist die Migration der elegante Weg.

Was, wenn nach dem Neustart das Netz weg ist?#

Deshalb vorher prüfen, dass du eine Konsole beim Anbieter hast. Nach dem Neustart zuerst ip -br a und systemctl status networking, die häufigste Ursache sind umbenannte Schnittstellen.

Kurz gesagt#

• Repository prüfen. Ohne Abo gehört No-Subscription eingetragen, nicht Updates ignoriert.
• apt dist-upgrade, nicht apt upgrade.
• Im Cluster: Wartungsmodus, migrieren, aktualisieren, zurückholen, ein Knoten nach dem anderen.
• Laufende Gäste bekommen neues QEMU erst durch Migration oder Stopp/Start.
• Automatische Updates ja, automatischer Neustart nein.