Proxmox VE · M5

Betrieb, Firmware & Monitoring

Der Alltag nach der Installation – Updates, Reboots, Hardware im Blick

Kreislauf aus Updates, Monitoring und seltenem, geplantem Reboot

Update-Prinzip (Debian-Basis)

Debian- und Proxmox-Repository fließen über apt in den Node

Updates kommen aus zwei Quellen: dem Debian-Basissystem (Security- und Stable-Repository) und dem eigenen Proxmox-Repository für pve-manager, qemu-server und Co.
Zwei Proxmox-Repo-Varianten: das Enterprise-Repository (Abo nötig, länger getestete Pakete, für Produktivsysteme empfohlen) und das kostenlose No-Subscription-Repository (aktueller, aber weniger lange im Feld erprobt)
Kleine Fixes, vor allem Sicherheitspatches, können mehrmals pro Woche erscheinen
Eingespielt wird klassisch per apt update && apt full-upgrade, alternativ komfortabel über die Weboberfläche unter „Updates"
Die meisten Updates laufen ohne Reboot durch – betroffen sind meist nur einzelne Dienste, die automatisch neu gestartet werden
Bewährte Praxis: neue Updates zuerst in einer Testumgebung fahren, erst danach auf Produktiv- bzw. Kundensysteme ausrollen

🎧 Block 1: Updates & Reboots

Wann ist ein Reboot nötig?

Kernel-Update oder Major-Upgrade erfordern Reboot, kleine Patches nicht

Reboot nur bei zwei Anlässen nötig: einem neuen Kernel oder einem größeren Versionssprung (z. B. Proxmox VE 7 auf 8)
Grund: ein neuer Kernel wird erst beim nächsten Bootvorgang tatsächlich geladen, bis dahin läuft weiter der alte im Arbeitsspeicher
Proxmox hält mehrere Kernel-Versionen parallel vorrätig – im GRUB-Menü lässt sich im Problemfall auf die vorherige Version zurückfallen, ohne neu zu installieren
Real: alle paar Wochen bis Monate ein Kernel-Reboot – damit planbar statt spontan
Reboot lässt sich fest ins eigene Wartungsfenster legen – kein Überraschungsneustart mitten am Vormittag
Kein Zwang zu ständigen Neustarts wie man es von manchen Windows-Patchdays kennt

Rolling Reboot ohne VM-Downtime

VMs wandern per Live-Migration zum Nachbar-Node, der leere Node rebootet, danach wandern die VMs zurück

Im Cluster: VMs per Live-Migration auf einen anderen Node verschieben, ganz ohne spürbare Downtime
Voraussetzung: geteilter oder replizierter Storage sowie ein ausreichend dimensioniertes Migrationsnetz
Bei Shared Storage wandert nur der Arbeitsspeicher-Zustand, das geht schnell; bei lokalem Storage mit Replikation dauert es etwas länger, ist aber ebenfalls machbar
Host rebooten, VMs anschließend zurückholen
Vergleichbar mit vMotion + Wartungsmodus – bei Proxmox ohne Lizenzaufpreis inklusive

Ohne Cluster gibt es keine Live-Migration: Ein einzelner Host, der neu startet, nimmt seine VMs zwangsläufig mit in die Downtime. Schon ein einfaches Zwei-Node-Setup mit einem kleinen Quorum-Gerät (QDevice) zahlt sich beim ersten Kernel-Update aus.

🎧 Block 2: Rolling Reboot

Ressourcen erweitern: was live, was mit Shutdown

vDisk vergrößern ist ohne weitere Voraussetzung live möglich, CPU- und RAM-Erweiterung nur mit aktiviertem Hotplug und passender Gast-Unterstützung, sonst ist ein Shutdown nötig

vDisk vergrößern Live möglich Per GUI oder qm resize – keine VM-Downtime auf Hypervisor-Ebene. Im Gast müssen Partition und Dateisystem noch erweitert werden (Windows: Datenträgerverwaltung/diskpart; Linux: growpart + resize2fs/xfs_growfs) – meist ohne Neustart, abhängig von OS und Partitionslayout.

vDisk verkleinern Nicht live Nicht live möglich und riskant – in der Regel nur über Neuanlage einer kleineren Disk und Migration der Daten umsetzbar.

Neue vDisk hinzufügen Live möglich Hotplug bei VirtIO-SCSI – eine zusätzliche Disk lässt sich im laufenden Betrieb ergänzen.

vCPU hinzufügen Bedingt live Nur mit aktiviertem CPU-Hotplug und passender Gast-Unterstützung (Linux meist ja, Windows eingeschränkt). Ohne Hotplug: Gast herunterfahren, ändern, wieder starten.

vCPU reduzieren Nur mit Shutdown Reduzieren ist praktisch immer nur im heruntergefahrenen Zustand möglich.

RAM erhöhen Bedingt live Nur mit Memory-Hotplug und passender VM-/Gast-Konfiguration. Ohne Hotplug: Shutdown nötig.

RAM-Maximum reduzieren Nur mit Shutdown Das Reduzieren des Maximums ist in der Regel nur mit Shutdown möglich.

Ballooning ändert nur das dem Gast aktuell zugeteilte RAM dynamisch innerhalb eines vorher gesetzten Rahmens (Minimum/Maximum) – das ist kein Ersatz für ein echtes Erhöhen des Max-RAM.

Hotplug-Geräte generell: Disk & NIC via VirtIO-SCSI

Proxmox unterstützt Hotplug nicht nur für den Umfang einzelner Disks, sondern auch für ganze zusätzliche Geräte: neue virtuelle Disks und Netzwerkkarten (NICs) lassen sich im laufenden Betrieb hinzufügen
Voraussetzung ist, dass der Gast VirtIO-Treiber nutzt (VirtIO-SCSI für Disks, VirtIO für Netzwerkkarten) – bei IDE/SATA-Emulation oder älteren Gästen ohne VirtIO-Unterstützung ist meist ein Shutdown nötig
Damit lässt sich z. B. kurzfristig zusätzlicher Storage oder ein weiteres Netzwerksegment anbinden, ohne die laufende VM anzuhalten
Auch das Entfernen von Hotplug-Geräten funktioniert im laufenden Betrieb, sofern der Gast das Gerät sauber aushängt bzw. deaktiviert

🎧 Block 6: Ressourcen live erweitern & Hotplug

Firmware-Updates

Firmware über BMC unabhängig vom Betriebssystem, oder über fwupd direkt aus Debian

Dell – iDRAC Flash über racadm oder die iDRAC-Weboberfläche, unabhängig vom laufenden Proxmox-System

HPE – iLO Firmware- und BIOS-Updates über die iLO-Oberfläche oder das ilorest-Tool

Lenovo – XCC XClarity Controller übernimmt Flash-Vorgänge komplett OS-unabhängig

Alle drei arbeiten über den BMC direkt am Server-Mainboard – Firmware lässt sich so flashen, auch wenn Proxmox selbst gerade gar nicht bootet
fwupd/LVFS direkt aus Debian für viele Standardgeräte – Abfrage per fwupdmgr get-updates, Einspielen per fwupdmgr update
Kein herstellerspezifisches Custom-ISO wie bei ESXi nötig (dort binden Dell/HPE eigene Treiberpakete direkt ins Installationsmedium ein)

🎧 Block 3: Firmware & Treiber

Herstellertreiber

Proxmox nutzt den Mainline-Kernel mit den meisten Treibern bereits enthalten, ESXi braucht pro Treiber ein VIB-Paket

Mainline-Linux-Kernel: die meisten Treiber sind schon dabei – Netzwerkkarten (Intel, Broadcom, Mellanox) und RAID-/HBA-Controller (LSI/Broadcom MegaRAID) laufen in aller Regel sofort
Kein VIB-Modell wie bei ESXi – kein Suchen nach passenden Paketen pro Karte, keine Inkompatibilität nach einem Versions-Upgrade durch fehlende VIBs
Hardware läuft dadurch oft schon beim ersten Booten, ganz ohne zusätzliche Treiberinstallation
Bei sehr neuer Hardware hilft bei Bedarf ein optional installierbarer, neuerer Kernel (aktuelleres pve-kernel-Paket), falls der Standardkernel ein Bauteil noch nicht kennt

Disk- & RAID-Monitoring

Terminal-Ausgabe von smartctl PASSED und zpool status ONLINE

S.M.A.R.T. über smartd ist bereits integriert und meldet eine sterbende Platte, bevor sie ganz ausfällt – Konfiguration in /etc/smartd.conf, manuelle Prüfung jederzeit per smartctl -a /dev/sda
Bei ZFS zusätzlich der Pool-Status im Blick behalten (zpool status) sowie ein regelmäßiger Scrub (z. B. monatlich), der stille Datenfehler proaktiv aufdeckt

storcli Broadcom/LSI – aktuelle MegaRAID-Generation

perccli Dell PERC – Broadcom-Basis mit Dell-Branding

megacli Ältere MegaRAID-Controller (Legacy)

Diese Hersteller-Tools regelmäßig per Cronjob oder Monitoring-Check auslesen – sonst fällt ein degradierter RAID-Verbund erst beim zweiten Plattendefekt auf.

🎧 Block 4: Monitoring & Benachrichtigung

Benachrichtigungen (eingebaut)

Mockup: Ereignisse Backup, Replikation und HA gehen an E-Mail und Gotify

Eingebautes Notification-System seit Proxmox VE 8, konfigurierbar unter „Rechenzentrum → Benachrichtigungen"
E-Mail oder Gotify bei Backup-, Replikations- und HA-Ereignissen sowie bei ablaufenden Zertifikaten
Ziele (wer wird benachrichtigt) und Matcher/Filter (welche Ereignisse) lassen sich getrennt konfigurieren und flexibel kombinieren
Für den Einstieg oder kleine Umgebungen bereits ausreichend, um sofort zu merken, wenn z. B. das nächtliche Backup nicht durchgelaufen ist

Externes Monitoring

Proxmox liefert Metriken über Exporter an Zabbix, Checkmk oder Prometheus, Grafana zeigt Dashboards, der BMC ergänzt Hardware-Health

Zabbix All-in-one-Lösung mit eigener Server-Komponente, klassisches Enterprise-Monitoring

Checkmk Stark bei automatischer Service-Erkennung, im deutschsprachigen Raum weit verbreitet

Prometheus + Grafana Modulares, Pull-basiertes Metrik-Modell mit sehr flexiblen Dashboards

Proxmox-spezifische Metriken liefert der (Community-)pve-exporter, allgemeine System-Metriken wie CPU/RAM/Disk-I/O der node_exporter
Tiefes Hardware-Health (Lüfterdrehzahl, Netzteilstatus, Temperaturen) zusätzlich über den BMC abfragen, z. B. per Redfish-API oder ipmitool – Proxmox selbst bildet das nicht so eng ab wie vCenter
Kombination aus externem Monitoring und BMC-Anbindung ergibt den Rundumblick, den man von vCenter gewohnt ist
Für Dienstleister besonders wertvoll: ein zentrales Dashboard über alle betreuten Kundenumgebungen hinweg statt Insellösung pro Kunde

🎧 Block 5: Externes Monitoring & Config-Backup

Config-Backup & Recovery

VM-Backup und separates Config-Backup von /etc/pve, nur zusammen stellt beides den ganzen Cluster wieder her

/etc/pve sichern – dort liegt die komplette Cluster-Konfiguration (VM-Definitionen, Storage- und Netzwerk-Einstellungen, Benutzer und Berechtigungen)
/etc/pve ist technisch kein normales Dateisystem, sondern die Cluster-Dateisystem-Sicht (pmxcfs) auf eine SQLite-Datenbank unter /var/lib/pve-cluster/config.db – ein normales vzdump-VM-Backup sichert diesen Teil nicht mit
Regelmäßig separat sichern, z. B. per einfachem tar-Archiv von /etc/pve oder einer eigenen Backup-Routine für die Konfigurationsdatenbank
Node- und Cluster-Wiederherstellung vorher durchdenken und idealerweise einmal in einer Testumgebung geübt haben, nicht erst im Ernstfall
Merkregel: die VM ist das Auto, die Cluster-Konfiguration ist der Fahrzeugschein – beides zusammen ergibt erst den vollständig wiederherstellbaren Betrieb

Tastenkürzel