Proxmox VE 9.1 OCI-Container und SDN – Upgrade-Guide 2026

Proxmox VE 9.1: OCI-Container, besseres SDN und Upgrade-Guide

VonContentKalle

Proxmox VE 9.1 ist da – was steckt drin?

Mit Proxmox VE 9.1 hat das Wiener Unternehmen eine der spannendsten Releases der letzten Jahre veröffentlicht. Wer ein Homelab betreibt oder Proxmox produktiv einsetzt, profitiert von echtem OCI-Container-Support für LXC, einem deutlich verbesserten SDN-Stack und feingranularer Nested-Virtualization-Kontrolle. In diesem Artikel erklären wir die wichtigsten Neuerungen und zeigen, wie du von Proxmox VE 8 auf Version 9.1 upgraden kannst.

OCI-Images direkt in LXC-Containern nutzen

Das wohl größte Feature in Proxmox VE 9.1 ist die native Unterstützung für OCI-Images (Open Container Initiative) in LXC-Containern. Bisher musstest du LXC-Templates manuell herunterladen oder aus einem Template-Store beziehen. Ab sofort kannst du OCI-Images direkt aus Container-Registries wie Docker Hub, GitHub Container Registry (GHCR) oder einer privaten Registry laden.

Proxmox unterscheidet dabei zwei Betriebsmodi:

  • Full System Container: Das Image wird als vollwertiger System-Container mit eigenem Init-System gestartet – ideal für komplexere Dienste.
  • Application Container (Lean): Minimaler Footprint, kein vollständiges Init – perfekt für Microservices und einfache Anwendungen.

Damit nähert sich Proxmox deutlich dem Docker-Workflow an, ohne Docker selbst zu benötigen. Für Homelab-Nutzer, die bisher Docker-Container neben Proxmox betrieben haben, eröffnet das interessante neue Möglichkeiten: Dienste direkt als LXC laufen lassen, mit weniger Overhead als eine vollständige VM.

OCI-Image als LXC starten – Beispiel

In der Weboberfläche wählst du beim Erstellen eines neuen Containers einfach OCI Image als Template-Quelle aus und gibst den Registry-Pfad an, z.B. docker.io/library/nginx:latest. Proxmox lädt das Image herunter, konvertiert es und startet den Container.

Hier einige praxisnahe Beispiele, die du direkt ausprobieren kannst:

  • Nginx Webserver: docker.io/library/nginx:latest – ein klassischer Einstieg, läuft als Application Container.
  • Home Assistant OS: ghcr.io/home-assistant/home-assistant:stable – smart home Zentrale direkt im LXC, kein separates VM-Overhead nötig.
  • Ubuntu-Basis: docker.io/library/ubuntu:24.04 – als Full System Container für eigene Dienste, die systemd benötigen.

Bekannte Einschränkungen

Nicht jedes OCI-Image funktioniert reibungslos in Proxmox LXC. Folgendes solltest du wissen:

  • Images, die bestimmte Kernel-Funktionen voraussetzen (z.B. eBPF-Heavy-Setups), können im unprivilegierten LXC-Modus scheitern.
  • Manche Images erwarten Docker-spezifische Laufzeitumgebungen (wie containerd-Hooks), die Proxmox nicht bereitstellt.
  • Multi-Arch-Images funktionieren nur, wenn sie die passende Architektur (AMD64) enthalten.

Empfehlung: Teste neue OCI-Images zunächst als Application Container im Lean-Modus und wechsle nur dann auf Full System Container, wenn der Dienst systemd oder einen echten Init-Prozess benötigt.

Verbessertes SDN (Software-Defined Networking)

Der SDN-Stack in Proxmox VE 9.1 hat ein deutliches Upgrade bekommen. Gerade für komplexe Netzwerktopologien im Homelab oder in kleinen Rechenzentren ist das ein echter Gewinn:

  • Neue GUI-Übersicht: Die Weboberfläche zeigt jetzt alle Gäste an, die an lokale Bridges oder VNets angebunden sind.
  • EVPN-Zonen berichten MAC/IP-Adressen: Gelernte IP- und MAC-Adressen werden direkt im Interface angezeigt – das erleichtert Troubleshooting erheblich.
  • Fabrics im Ressourcenbaum: Routen, Neighbors und Interfaces sind direkt im Proxmox-Ressourcenbaum sichtbar.
  • IP-VRFs und MAC-VRFs: Auch diese werden in der GUI dargestellt, was besonders für Multi-Tenant-Setups relevant ist.

Praktisches Beispiel: IP-Adresse bei EVPN finden

Wer EVPN (Ethernet VPN) im Einsatz hat, kennt das Problem: Eine VM reagiert nicht mehr, und man weiß nicht, welche IP-Adresse sie tatsächlich verwendet. In Proxmox VE 9.1 reicht ein Blick in die SDN-Übersicht – unter Datacenter → SDN → Zones → [deine EVPN-Zone] siehst du die gelernten MAC/IP-Paare aller angebundenen Gäste in Echtzeit. Kein manuelles arp -n auf dem Hostsystem mehr nötig.

Wer profitiert besonders? Im Homelab ist das SDN-Feature vor allem für Nutzer interessant, die mehrere VLANs oder virtuelle Netzwerksegmente verwalten. Im Datacenter-Kontext erleichtert es Compliance-Audits, bei denen IP-zu-VM-Zuordnungen dokumentiert werden müssen.

Granulare Nested Virtualization

Proxmox VE 9.1 führt ein neues vCPU-Flag ein, das Nested Virtualization pro VM aktiviert oder deaktiviert – statt wie bisher global auf Kernel-Ebene:

  • Nested Virt gezielt nur für bestimmte VMs aktivieren (z.B. für ein Testlabor mit Kubernetes-Cluster).
  • VMs ohne Nested Virt laufen weiterhin ohne zusätzlichen Overhead.
  • Der neue Kernel 6.17 ist Voraussetzung für dieses Feature.

Wichtiger Hinweis für NVIDIA-vGPU-Nutzer: Kernel 6.17 erfordert NVIDIA vGPU-Treiber ab Version 19.4. Nutzer von Standard-NVIDIA-Treibern (z.B. für GPU-Passthrough oder Host-Grafik) sollten vor dem Upgrade die Proxmox-Foren auf Kompatibilität mit ihrem Treiberstand prüfen – aktuelle Treiberversionen wie 580.x laufen grundsätzlich, aber DKMS-Builds können bei bestimmten Konfigurationen fehlschlagen.

vTPM-Snapshots im qcow2-Format

Der Zustand eines virtuellen Trusted Platform Module (vTPM) kann jetzt im qcow2-Disk-Image-Format gespeichert werden. Das ermöglicht konsistente Snapshots von VMs, die Windows 11 oder andere TPM-abhängige Betriebssysteme nutzen.

vTPM in Proxmox aktivieren

Ein vTPM aktivierst du beim Erstellen einer neuen VM unter Hardware → Add → TPM State. Wähle dort Version 2.0 und ein qcow2-fähiges Storage als Ablageort. Für bestehende VMs kannst du das vTPM nachträglich unter VM → Hardware → Add ergänzen, solange die VM ausgeschaltet ist.

Warum ist das für Windows 11 wichtig?

Windows 11 setzt ein TPM 2.0 zwingend voraus – ohne dieses Modul verweigert das Betriebssystem die Installation. Mit dem vTPM in Proxmox erfüllst du diese Anforderung direkt in der VM, ohne physische TPM-Hardware im Host zu benötigen. Außerdem profitierst du von Features wie BitLocker-Verschlüsselung und Windows Hello innerhalb der VM.

Was bei Snapshots beachten?

Dank der neuen qcow2-Unterstützung wird der TPM-Zustand beim Snapshot automatisch mitgesichert und wiederhergestellt. Wichtig: Snapshots mit vTPM funktionieren nur, wenn der TPM State auf einem Storage liegt, das qcow2 unterstützt (z.B. LVM-Thin, ZFS mit qcow2-Unterlage oder lokales Verzeichnis). NFS-Shares oder Ceph-RBD (im Raw-Format) unterstützen das noch nicht zuverlässig.

Upgrade von Proxmox VE 8 auf 9.1 – Schritt für Schritt

Das Upgrade von PVE 8 auf PVE 9.1 ist ein In-Place-Upgrade über Debian Bookworm → Trixie. Hier die wichtigsten Schritte:

1. Vorbereitung

  1. Backup erstellen: Sichere alle VMs und Container, bevor du beginnst.
  2. PVE 8 aktualisieren: Stelle sicher, dass du mindestens Version 8.4.1 nutzt:
    apt update && apt dist-upgrade
  3. Pre-Upgrade-Check ausführen:
    pve8to9
    Lies alle Warnungen sorgfältig durch und behebe sie vorher.

Was tun, wenn der Pre-Upgrade-Check Warnungen zeigt?

Das Tool pve8to9 meldet häufig folgende Warnungen, die du vor dem Upgrade beheben solltest:

  • „Corosync version mismatch“: Stelle sicher, dass alle Cluster-Nodes dieselbe Proxmox-Version haben, bevor du anfängst.
  • „Third-party repositories found“: Deaktiviere oder entferne fremde APT-Quellen, die mit Trixie inkompatibel sein könnten.
  • „Deprecated config options“: Aktualisiere VM-Konfigs manuell per qm migrate <vmid> oder passe sie in der GUI an.

2. Repository wechseln

sed -i 's/bookworm/trixie/g' /etc/apt/sources.list
sed -i 's/bookworm/trixie/g' /etc/apt/sources.list.d/*.list

3. Upgrade durchführen

apt update
apt dist-upgrade

Nutze tmux oder screen, wenn du via SSH arbeitest – ein Verbindungsabbruch würde das Upgrade unterbrechen.

4. Neustart

reboot

Nach dem Neustart sollte Proxmox VE 9.1 mit dem neuen Kernel 6.17 laufen. Prüfen mit:

pveversion -v

Typische Fehler und Lösungen

  • „dpkg: error processing package …“ beim dist-upgrade: Häufig durch Konfigurationskonflikte. Lösung: dpkg --configure -a und dann erneut apt dist-upgrade.
  • Netzwerk nach Upgrade nicht erreichbar: Bridge-Konfiguration in /etc/network/interfaces prüfen. Bei OVS-Bridge auf neue Syntax achten.
  • DKMS-Module fehlen nach Kernel-Update: dkms status ausführen und fehlende Module mit dkms install <modul>/<version> neu bauen.

Rollback-Optionen

Ein vollständiges Rollback auf PVE 8 ist nach dem Upgrade auf PVE 9.1 nicht trivial. Daher gilt: Backup vor dem Upgrade ist Pflicht. Für Cluster-Setups empfiehlt sich folgendes Vorgehen:

  • Einen Node upgraden, 24–48 Stunden im Betrieb beobachten, dann den nächsten upgraden.
  • Falls ein Node nach dem Upgrade nicht stabil ist: Den Node aus dem Cluster entfernen (pvecm delnode <name>), Debian Bookworm neu installieren und Proxmox 8 wiederherstellen, während die anderen Nodes weiter auf PVE 9.1 laufen.

Cluster-Upgrade

Betreibst du einen Proxmox-Cluster, upgrade die Nodes einzeln nacheinander. Warte nach jedem Node auf einen stabilen Cluster-Status, bevor du mit dem nächsten weitermachst.

Fazit

Proxmox VE 9.1 ist ein solides Release mit echtem Mehrwert. Der OCI-Container-Support ist ein Gamechanger für alle, die Docker-Workflows ohne Docker-Overhead wollen. Das verbesserte SDN-Monitoring reduziert den operativen Aufwand bei komplexen Netzwerken erheblich. Die vTPM-Snapshot-Unterstützung macht Windows-11-VMs endlich snapshottbar – ein lang erwartetes Feature. Und die granulare Nested-Virt-Kontrolle macht Proxmox noch flexibler für Lab- und Produktionsumgebungen.

Bist du schon auf Proxmox VE 9.1 umgestiegen? Hast du Fragen zum Upgrade oder zu den neuen Features? Schreib es in die Kommentare!

Ähnliche Beiträge