KubeVirt oder Proxmox? Ein Leitfaden für Architekturentscheidungen im Jahr 2026

1. Zusammenfassung

Abbildung 1: Das Bifurkationsproblem (links) im Vergleich zu einer einheitlichen, Kubernetes-nativen Plattform (rechts).

Unternehmen, die Kubernetes einsetzen, stehen vor einer grundlegenden Infrastrukturentscheidung: Wie sollen virtuelle Maschinen neben Containern verwaltet werden? Dabei gibt es zwei unterschiedliche Architekturansätze. Proxmox VE bietet einen benutzerfreundlichen, eigenständigen Hypervisor mit integriertem ZFS und LXC. KubeVirt integriert virtuelle Maschinen direkt in Kubernetes und behandelt sie als gleichberechtigte Komponenten desselben deklarativen, API-gesteuerten Ökosystems, in dem bereits Ihre Container laufen.

In diesem Whitepaper wird dargelegt, dass KubeVirt für jedes Unternehmen, das bereits in Kubernetes investiert hat, die strategisch bessere Wahl ist. Der Unterschied ist nicht marginal – er ist architektonischer Natur. Proxmox basiert auf einem imperativen, GUI-zentrierten Modell mit begrenzter Erweiterbarkeit und schwacher Mandantenfähigkeit. KubeVirt übernimmt das gesamte Betriebsmodell von Kubernetes: deklarativer Zustand, Abgleichschleifen, GitOps, RBAC, storage, CNI-Netzwerk sowie ein Ökosystem aus Operatoren, Helm und Überwachungstools, mit dem kein eigenständiger Hypervisor mithalten kann.

Es geht hier nicht darum, dass Proxmox eine schlechte Software ist. Vielmehr befindet sich Proxmox in einer anderen Welt – einer Welt, deren Wartung mit zunehmender Größe Ihrer Kubernetes-Umgebung immer kostspieliger wird. Die Überbrückung zweier Betriebsparadigmen – der imperativen Hypervisor-Verwaltung und der deklarativen Cluster-Verwaltung – führt zu Reibungsverlusten, die sich mit zunehmender Skalierung verstärken. KubeVirt macht diese Überbrückung vollständig überflüssig.

Für Unternehmen, die eine schlüsselfertige Implementierung suchen, bündelt Kubermatic Virtualization die Lösungen KubeVirt, KubeOVN und KubeOne zu einer unterstützten Hypervisor-Suite mit einer zentralisierten Verwaltungsoberfläche, einem deklarativen Installationsprogramm sowie Netzwerk- und storageder Enterprise-Klasse – dies wird in Abschnitt 13 ausführlich behandelt.

Das Wichtigste auf einen Blick: Wenn Kubernetes Ihre Plattform ist, dann ist KubeVirt Ihr Hypervisor.

Marktkontext: Seit der Übernahme von VMware durch Broadcom hat sich die Virtualisierungslandschaft grundlegend verändert. Eine Umfrage von Spectro Cloud aus dem Jahr 2025 unter Kubernetes-Anwendern ergab, dass 86 % KubeVirt kennen und 26 % es im Produktivbetrieb einsetzen ^[1]. Proxmox hat im KMU- und Homelab-Bereich an Akzeptanz gewonnen, doch aufgrund seiner architektonischen Einschränkungen stellt es für Unternehmen, die in eine Cloud-native Infrastruktur investieren, eine Sackgasse dar.

2. Argumente für eine Kubernetes-native Virtualisierung

Virtuelle Maschinen werden nicht verschwinden. Ältere Workloads, Windows-Server, Datenbank-Appliances und Systeme, die bestimmten Compliance-Vorgaben unterliegen, werden noch viele Jahre lang als VMs laufen. Die Frage ist nicht, ob Sie VMs benötigen, sondern wie Sie diese verwalten.

Die herkömmliche Lösung ist eine separate Hypervisor-Ebene: VMware, Proxmox, Hyper-V – jede mit ihrer eigenen API, ihrer eigenen Authentifizierung, ihrem eigenen Netzwerkmodell und ihrer eigenen Betriebskultur. Dadurch entsteht eine zweigeteilte Infrastruktur. Ihre Container befinden sich in einer Welt, Ihre VMs in einer anderen. Zwei Automatisierungssysteme. Zwei Runbooks. Zwei Eskalationspfade. Zwei Anforderungsprofile für die Personalbeschaffung.

Die Kubernetes-native Virtualisierung über KubeVirt löst diese Zweiteilung. Eine KubeVirt-Virtualmaschine ist eine Kubernetes-Ressource, die durch ein CRD definiert, von einem Controller verwaltet, vom selben Scheduler eingeplant, vom selben Prometheus überwacht und durch dasselbe RBAC gesichert wird. Es gibt keine zweite Welt. Es gibt eine Plattform, eine API, ein Betriebsmodell.

Das ist nicht nur eine Annehmlichkeit. Es ist ein Kraftmultiplikator. Jede Investition, die Sie in Kubernetes getätigt haben – Ihre GitOps-Pipelines, Ihr Observability-Stack, Ihre Policy-Engines, Ihre Self-Service-Portale für Entwickler – lässt sich automatisch auf VMs ausweiten. Sie müssen diese Funktionen nicht für einen separaten Hypervisor neu aufbauen. Sie übernehmen sie einfach.

3. Architekturvergleich: Proxmox vs. KubeVirt

3.1 Architektur von Proxmox VE

Proxmox VE ist eine auf Debian basierende monolithische Hypervisor-Distribution, die KVM für die Virtualisierung und LXC für Container integriert. Die Verwaltung erfolgt über eine maßgeschneiderte Web-GUI oder die pvesh CLI-Shell, unterstützt durch eine REST-API. Für die Clusterkoordination werden Corosync für das Quorum und Ceph (über pveceph) oder ZFS-Replikation für gemeinsam genutzten storage. Der Konfigurationsstatus wird gespeichert in pmxcfs, eine auf Corosync basierende benutzerdefinierte Datenbankschicht.

Abbildung 2: Monolithische Architektur von Proxmox VE – in sich geschlossen, imperativ, begrenzte Integrationspunkte.

Die Architektur ist in sich geschlossen. Integrationspunkte beschränken sich auf die REST-API und, in geringerem Maße, auf den Terraform-Proxmox-Provider. Es gibt kein Konzept von Controllern, Abgleichschleifen oder deklarativem Zustand. Änderungen werden imperativ vorgenommen und bleiben bestehen, bis sie erneut geändert werden.

Wesentliche Einschränkung: Die Cluster-Architektur von Proxmox basiert auf der synchronen Kommunikation mit Corosync und pmxcfs, was zu erheblichen Skalierungsgrenzen führt. In der Dokumentation von Proxmox heißt es zwar, dass es „keine explizite Begrenzung“ für die Anzahl der Knoten in einem Cluster gibt, es wird jedoch eingeräumt, dass „die tatsächlich mögliche Knotenanzahl durch die Leistung des Hosts und des Netzwerks begrenzt sein kann“. ^[2].
Nach allgemeiner Meinung und praktischen Erfahrungen liegt die verlässliche Obergrenze bei etwa 32 Knoten. Darüber hinaus verschlechtern sich die Latenzzeiten von Corosync und das Quorum-Management. ^[3]. Das ist keine kleine Konfigurationsänderung, sondern eine architektonische Grenze.

3.2 Architektur von KubeVirt

KubeVirt erweitert Kubernetes um CRDs für Virtuelle Maschine und Virtuelle Maschineninstanz. Der KubeVirt-Controller läuft als Standard-Kubernetes-Operator. Hinter jeder VM steht ein Pod, auf dem libvirt, die vom Kubernetes-Scheduler geplant werden. Der Containerized Data Importer (CDI) übernimmt den Import von VM-Images. Netzwerk, storage und Überwachbarkeit nutzen die bestehende Kubernetes-Infrastruktur.

Abbildung 3: Die modulare Architektur von KubeVirt – jede Komponente ist austauschbar, synchronisierbar und beobachtbar.

Die Architektur ist modular aufgebaut. Jede Komponente kann unabhängig ausgetauscht, aktualisiert oder erweitert werden. Das System nähert sich durch Abgleich kontinuierlich dem gewünschten Zustand an. Kubernetes selbst hat sich in der Produktion bei Unternehmen wie Google, Apple und Shopify beim Betrieb von Tausenden von Knoten bewährt – KubeVirt übernimmt dieses Skalierbarkeitsmodell. Die SIG-Scale-Tests von KubeVirt v1.8 validierten die Steuerungsebene bei 8.000 VMs mit linearem Speicherwachstum: Der Speicherbedarf von „virt-api“ stieg in diesem Bereich von 140 MB auf 170 MB und der von „virt-controller“ von 65 MB auf 1.400 MB ^[4].

4. Betriebsmodell: Imperativ vs. Deklarativ

Abbildung 4: Imperative (links) und deklarative (rechts) Betriebsmodelle. KubeVirt gleicht den Sollzustand kontinuierlich ab; Proxmox erfordert bei jeder Änderung und jedem Ausfall einen manuellen Eingriff.

4.1 Proxmox: Imperativ von Grund auf

Die Verwaltung von Proxmox ist handlungsorientiert. Man klickt auf eine Schaltfläche oder gibt einen Befehl ein, und das System führt diesen aus. Es gibt keinen Sollzustand. Es gibt nur den aktuellen Zustand, der durch Aktionen verändert wird. Wenn eine Aktion teilweise fehlschlägt, muss man das Problem manuell diagnostizieren und beheben.

Betrachten wir einen Workflow zur Bereitstellung von virtuellen Maschinen:

1. Der Administrator klickt in der Benutzeroberfläche auf „VM erstellen“ oder ruft qm erstellen über die API
2. Die VM wird erstellt
3. Der Administrator konfiguriert Netzwerk, storage und Startreihenfolge separat.
4. Wenn Schritt 3 fehlschlägt, befindet sich die VM in einem unvollständigen Zustand.
5. Keine automatisierte Fehlerbehebung

Dieses Modell ist für kleine Teams, die eine Handvoll Hosts verwalten, vertraut und intuitiv. Bei größerer Skalierung stößt es jedoch an seine Grenzen. Wenn Sie Hunderte von VMs über mehrere Cluster hinweg verwalten, können Sie aufgrund der fehlenden Nachverfolgung des Sollzustands eine einfache Frage nicht beantworten: „Entspricht diese Infrastruktur unserer beabsichtigten Konfiguration?“ Sie können lediglich den aktuellen Zustand überprüfen und hoffen, dass er korrekt ist.

Terraform löst dieses Problem teilweise durch die Bereitstellung einer deklarativen Syntax, doch der Proxmox-Terraform-Provider ist ein von der Community gepflegtes Projekt (Telmate/terraform-provider-proxmox), das die imperative API umsetzt. Er profitiert nicht von derselben erstklassigen Integration wie der Kubernetes-Terraform-Provider. Die Erkennung von Zustandsabweichungen ist unzuverlässig, und der Provider hinkt häufig den Änderungen an der Proxmox-API hinterher. Bis Juni 2026 wurden auf GitHub insgesamt über 1.500 Issues zu diesem Provider gemeldet (davon sind derzeit etwa 128 offen), darunter wiederkehrende Berichte über Abstürze bei der Erstellung von VMs, Inkonsistenzen im Status nach Operationen zur Festplattengrößenanpassung sowie fehlerhafte Cloud-init-Workflows ^[5].

4.2 KubeVirt: Von Natur aus deklarativ

KubeVirt übernimmt das deklarative Modell von Kubernetes. A Virtuelle Maschine Die Ressource beschreibt den Sollzustand. Der KubeVirt-Controller gleicht den Istzustand kontinuierlich mit dem Sollzustand ab. Wenn eine VM eigentlich laufen sollte, dies aber nicht tut, behebt der Controller das Problem. Wenn die Konfiguration einer VM abweicht, wird dies bei der nächsten Abgleichung korrigiert.

Das ist kein einfacher Wrapper. So funktioniert das System im Kern. Das Gleiche kubectl apply die Deployments verwaltet, verwaltet auch VirtualMachines. Dieselbe ArgoCD-Anwendung, die Ihre Container-Workloads synchronisiert, synchronisiert auch Ihre VM-Workloads. Dieselbe kubectl diff Die Vorschau auf Änderungen an einer ConfigMap zeigt die Änderungen an der CPU-Zuweisung einer VM an.

GitOps ist kein nachträglich angehängtes Konzept. Es ist die natürliche Arbeitsweise. Ihre VM-Definitionen werden in Git verwaltet. Änderungen durchlaufen eine Code-Review. ArgoCD oder Flux wendet sie automatisch an. Ein Rollback ist git revert. Der Prüfpfad ist git log. Es gibt keinen separaten Change-Management-Prozess für VMs. Das KubeVirt-Benutzerhandbuch dokumentiert ausdrücklich GitOps-Workflows, und Kubermatic Virtualization unterstützt eine deklarative YAML-Installation im GitOps-Stil mit Selbstheilung bei nachfolgenden Durchläufen ^[6].

5. Day-2-Betrieb in großem Maßstab

5.1 Zeitplanung und Lebenszyklus

Proxmox bietet grundlegende Cluster-Funktionen: HA-Gruppen, Live-Migration über gemeinsam genutzten storage und ein einfaches Prioritätssystem für das HA-Failover. Diese Funktionen eignen sich für kleine Cluster. Sie sind jedoch nicht mit dem Scheduling von Kubernetes vergleichbar.

Die Kubernetes-Planung für KubeVirt-VMs umfasst:

• Knoten-Affinität und Anti-Affinität: VM-Datenbanken an Knoten mit NVMe binden, Webserver-VMs über mehrere Racks verteilen
• Zuweisungen und Toleranzen: Knoten für VM-Workloads reservieren, VMs von reinen Container-Knoten ausschließen
• Einschränkungen bei der Verteilung der Pod-Topologie: Stellen Sie sicher, dass die VMs über Ausfalldomänen verteilt sind
• Lymphknotenentleerung: kubectl drain migriert VMs zur Wartung reibungslos von einem Knoten, wobei LiveMigrate Strategien zur Zwangsräumung
• Ressourcenkontingente: Begrenzen Sie den Ressourcenverbrauch von VMs pro Namespace, um zu verhindern, dass ein Team anderen Ressourcen entzieht.
• Prioritätsklassen: Bei knappen Ressourcen verdrängen kritische VMs gemäß den festgelegten Richtlinien weniger wichtige VMs.

Proxmox verfügt über keine dieser Funktionen. Die Platzierung von VMs erfolgt manuell oder basiert auf einfachen HA-Gruppenzuordnungen. Die Wartung von Knoten erfordert eine manuelle Migration. Es gibt keine prioritätsbasierte Vorwegnahme. Es gibt keine namensraumbasierte Durchsetzung von Kontingenten. In den Proxmox-Foren fragen Nutzer regelmäßig, wie sich Ressourcenkontingente pro Pool durchsetzen lassen – die einheitliche Antwort lautet, dass Proxmox keine native Kontingentdurchsetzung bietet und Administratoren auf manuelle Maßnahmen oder externe Skripte zurückgreifen müssen ^[7].

5.2 Migration

Proxmox unterstützt die Live-Migration mit gemeinsam genutztem storage Ceph oder NFS). Diese Funktion ist zwar verfügbar, weist jedoch Einschränkungen auf: keine affinitätsorientierte Platzierung nach der Migration, kein automatischer Ausgleich und keine Integration in eine umfassendere Planungsrichtlinie.

KubeVirt unterstützt die Live-Migration als vollwertigen Vorgang, der von Kubernetes selbst ausgelöst wird. Wenn ein Knoten für Kernel-Updates geleert werden muss, sendet der Kubernetes-Eviction-Controller ein Signal an KubeVirt, das die VMs gemäß denselben Planungsrichtlinien migriert, die auch für die Platzierung gelten. Kein manueller Eingriff. Kein separates Runbook. Das Gleiche kubectl drain Was Sie für Pods verwenden, funktioniert auch für VMs.

In KubeVirt v1.6 (Juni 2025) und v1.7 (November 2025) wurde die Live-Migration durch dedizierte Migrationsnetzwerke weiter abgesichert, wodurch eine clusterübergreifende Migration mithilfe von EVPN und OpenPERouter ermöglicht wird, um eine vollständige Trennung vom Anwendungsnetzwerk zu gewährleisten. Dies ist Workload-Mobilität auf Produktionsniveau, mit der Proxmox nicht mithalten kann – die Live-Migration von Proxmox ist auf einen einzelnen Cluster mit gemeinsam genutztem storage beschränkt.

5.3 Beobachtbarkeit

Die Überwachung von Proxmox erfolgt extern. Sie können Metriken über die Proxmox-API in eine Prometheus-Instanz exportieren, allerdings handelt es sich hierbei um eine Ad-hoc-Integration. Es gibt keine native Service-Erkennung, keine Standard-Dashboards und keine in die Plattform integrierten Alarmregeln.

KubeVirt übernimmt den Observability-Stack von Kubernetes. Der kube-prometheus-stack bietet Prometheus, Grafana und Alertmanager von Haus aus. KubeVirt stellt Metriken über den Standard-Kubernetes-Mechanismus bereit /Kennzahlen Endpunkt: Erstellungs- und Löschraten von VMIs, Migrationsstatus, CPU- und Speicherauslastung pro VMI, storage Netzwerkleistung. Die Dienstermittlung erfolgt automatisch. Die Dashboards werden von der Community gepflegt und sind produktionsreif. Die Warnregeln entsprechen den Kubernetes-Konventionen.

Ihre bestehenden Grafana-Dashboards für Kubernetes lassen sich auf VMs ausweiten. Ihre bestehende PagerDuty-Integration erfasst VMI-Abstürze. Es muss kein separater Überwachungsstack aufgebaut und gewartet werden.

6. Sicherheit und Mandantenfähigkeit

Abbildung 5: Proxmox bietet pfadbasierte Berechtigungen (links); KubeVirt übernimmt das gesamte Kubernetes-Sicherheitsframework – RBAC, Namespaces, NetworkPolicy, Quoten, Zulassungskontrolle und Audit-Protokollierung (rechts).

6.1 Proxmox: Berechtigungen statt Richtlinien

Proxmox verwendet ein benutzerdefiniertes Berechtigungssystem, das auf Pfaden, Rollen und Benutzern basiert. Sie können einem Benutzer Berechtigungen für eine VM, einen Pool oder einen Knoten zuweisen. Das Modell ist grob gegliedert. Es gibt keine Netzwerkrichtlinien, keine Pod-Sicherheitsstandards und keine Namespace-Isolation. Benutzer mit Zugriff auf eine VM auf derselben Bridge können potenziell auf den Datenverkehr anderer VMs zugreifen. Über das VLAN-Tagging hinaus gibt es keine integrierte Mandantenisolierung.

Proxmox hat in den jüngsten Versionen eine SDN-Funktion (Software-Defined Network) eingeführt, die eine VNet-Isolierung mithilfe von VLAN- und QinQ-Zonen ermöglicht. Ein Leitfaden zum Thema Multi-Tenancy aus dem Jahr 2026 in der DEV Community räumt jedoch ein: „Das Verständnis von Pfadberechtigungen, Vererbung und Pool-Semantik kann für Anfänger unerwartet schwierig sein. Gut geeignet für kontrollierte gemeinsame Nutzung, aber unzureichend für sichere Mandantenumgebungen.“ ^[8] Um echte Multi-Tenancy auf Proxmox zu erreichen, müssen RBAC, SDN-Zonen, Firewall-Regeln, Routing, VPN-Einstiegspunkte und Benutzerberechtigungen manuell miteinander verknüpft werden. Dies ist eher eine Integrationsaufgabe als eine Konfigurationsaufgabe.

In den Proxmox-Foren stellen Nutzer, die versuchen, Ressourcenkontingente für CPU, RAM und Festplattenspeicher auf Pool-Ebene festzulegen, immer wieder fest, dass die Plattform keine native Durchsetzung dieser Kontingente bietet. In einem Thread vom Februar 2026 heißt es ausdrücklich: „Echte Multi-Tenancy muss auch anonyme Nachbar-Tenants berücksichtigen, was bei mehreren Authentifizierungsbereichen zu einer komplizierten Konfiguration führen wird.“ ^[9]

Konkrete Angriffsvektoren bei der Proxmox-Mandantenfähigkeit:

• Netzwerkverkehr zwischen den Bereichen: Ohne NetworkPolicies auf CNI-Ebene können VMs auf derselben Linux-Bridge ARP-Spoofing betreiben oder den Datenverkehr benachbarter Mandanten abhören.
• Rechteausweitung durch fehlerhafte Pool-Konfiguration: Die pfadbasierten Berechtigungen von Proxmox werden hierarchisch vererbt. Eine falsch konfigurierte Pool.Admin Die Rolle gewährt Zugriff weit über die vorgesehenen VMs hinaus.
• Keine Zulassungsprüfung: Es gibt kein Äquivalent zu den Kubernetes-Zulassungscontrollern. Jeder Benutzer mit Rechten zur Erstellung von VMs kann eine VM mit beliebiger Konfiguration erstellen – ohne Durchsetzung von Richtlinien und ohne Überprüfung von Ressourcenbeschränkungen.
• Lücken im Prüfpfad: Proxmox protokolliert Aktionen in syslog, allerdings gibt es kein strukturiertes Audit-Protokoll, das mit der Audit-Protokollierung von Kubernetes vergleichbar wäre. Die forensische Untersuchung unbefugter Änderungen erfordert eine manuelle Korrelation der Protokolle.

6.2 KubeVirt: Sicherheit auf Kubernetes-Niveau

KubeVirt übernimmt das gesamte Kubernetes-Sicherheitsmodell:

• RBAC: Feinkörnige, rollenbasierte Zugriffskontrolle auf Namespace- und Ressourcenebene. Team A erhält Virtuelle Maschine CRUD im Namensraum Team A. Team B erhält dasselbe im Namensraum Team B. Keiner von beiden kann die Ressourcen des anderen sehen.
• Namensräume: Feste logische Grenzen für die Zuständigkeit für Ressourcen, Kontingente und Netzwerkrichtlinien.
• Netzwerkrichtlinien: Calico oder Cilium sorgen für eine L3/L4-Isolation zwischen Namespaces. Die VMs von Team A können die VMs von Team B nicht erreichen, es sei denn, Sie erlauben dies ausdrücklich. Dies wird auf der Datenebene durchgesetzt, nicht nur auf der Steuerungsebene.
• Sicherheitsstandards für Pods: KubeVirt führt VMs in Pods aus, die denselben Sicherheitsbeschränkungen unterliegen. Sie können pro Namespace eingeschränkte, Basis- oder privilegierte Profile festlegen.
• Zugriffskontrollmechanismen: OPA/Gatekeeper oder Kyverno können die Spezifikationen von VMs vor deren Erstellung überprüfen. Keine VMs ohne genehmigte Labels. Keine VMs, die die Ressourcengrenzen überschreiten. Keine VMs, die sensible Volumes einbinden.
• Audit-Protokollierung: Kubernetes-Audit-Protokolle erfassen jeden API-Aufruf – einschließlich der Erstellung, Änderung und Löschung von VMs – zusammen mit der Benutzeridentität und Zeitstempeln.
• Confidential Computing (KubeVirt v1.8+): Dank der Unterstützung für Intel TDX-Attestierung können virtuelle Maschinen kryptografisch nachweisen, dass sie auf vertraulicher Hardware ausgeführt werden – ein entscheidender Faktor für regulierte Workloads im Finanzsektor und im öffentlichen Dienst ^[4].

Der Unterschied ist nicht nur geringfügig. Proxmox bietet ein Berechtigungssystem. Kubernetes bietet ein Sicherheitsframework.

7. Storage Netzwerk-Ökosystem

7.1 Storage

Proxmox unterstützt LVM, ZFS und Ceph (über pveceph), NFS und iSCSI. Dies sind solide Optionen für einen eigenständigen Hypervisor. Die Einschränkung besteht darin, dass dies die vollständige Liste ist. Wenn Ihr Unternehmen auf storage eines Cloud-Anbieters, auf Longhorn, auf Portworx oder auf storage beliebiges CSI-kompatibles storage setzt, kann Proxmox diesen nicht nutzen. Sie verwenden entweder das, was Proxmox unterstützt, oder Sie entwickeln und warten eine eigene Integration selbst.

KubeVirt nutzt das Kubernetes-CSI-Ökosystem (Container Storage ). Jeder storage mit einem CSI-Treiber ist kompatibel. Dazu gehören:

• Ceph über Rook – dasselbe Ceph, das auch Proxmox verwendet, jedoch deklarativ über Kubernetes verwaltet
• Longhorn, speziell für Kubernetes-nativen verteilten storage entwickelt
• storage bei Cloud-Anbietern: AWS EBS, Azure Disk, GCE Persistent Disk über deren CSI-Treiber
• NetApp, Dell, Pure Storage und alle storage mit einem CSI-Treiber
• Lokale PVs, hostPath-Volumes und alle zukünftigen storage

VM-Datenträger sind PersistentVolumeClaims. Sie profitieren von StorageClasses, Volume-Snapshots, Volume-Klonen und dynamischer Bereitstellung. CDI importiert VM-Images über HTTP, S3 oder Container-Registerstellen in PVCs, wodurch die Image-Verteilung genauso unkompliziert wird wie das Abrufen von Container-Images.

In KubeVirt v1.8 (März 2026) erweitert CDI die Funktionen um inkrementelle Backups mit Changed Block Tracking (CBT), wobei die Backup-Funktionen von QEMU und libvirt genutzt werden, um storage inkrementelle VM-Backups zu erstellen. Dies ermöglicht schnellere Backups und eine erhebliche Reduzierung des storage – Funktionen, die die Backup-Tools von Proxmox (vzdump) lassen sich bei dieser Detailgenauigkeit nicht abgleichen ^[4].

7.2 Vernetzung

Proxmox bietet Linux Bridge, VLAN und Open vSwitch. Dabei handelt es sich um Standard-Netzwerkprimitive für Hypervisoren. Sie dienen der grundlegenden Konnektivität von virtuellen Maschinen. Folgendes bieten sie nicht:

• Netzwerkrichtlinien (L3/L4-Firewall zwischen VMs)
• Service Mesh (mTLS, Datenverkehrsmanagement, Überwachbarkeit der VM-zu-VM-Kommunikation)
• eBPF-basierte Observability (Einblick auf Paketebene ohne Paketaufzeichnung)
• Lastenausgleich (Proxmox kennt weder das Konzept eines Dienstes noch das eines Lastenausgleichs)
• Ingress (HTTP-Routing, TLS-Terminierung für auf VMs gehostete Webdienste)
• Multus- oder CNI-Verkettung (mehrere Netzwerkschnittstellen pro VM mit unterschiedlichen CNI-Plugins)

KubeVirt-VMs sind vollwertige Teilnehmer am Kubernetes-Netzwerkmodell. Sie erhalten Cluster-IPs, reagieren auf Services, werden von Ingress-Controllern verwaltet, von Ciliums „Hubble“ überwacht und durch NetworkPolicies geschützt. Eine VM, auf der eine ältere Webanwendung läuft, kann über einen Ingress-Controller mit TLS-Terminierung, Ratenbegrenzung und WAF-Regeln nach außen zugänglich gemacht werden – genau so, als wäre es ein containerbasierter Service.

Mit KubeVirt v1.8 wurde die passt Das Netzwerk-Konnektivitäts-Plugin für den User-Space wurde von „experimental“ in den Kern übernommen, wodurch die Netzwerkverbindung für rootless-VMs ermöglicht wird. Mit derselben Version wurden die Verweise auf die Network Attachment Definition (NAD) vom virt-controller entkoppelt, wodurch die Anzahl der API-Aufrufe reduziert und die zuvor für die Aktivierung von VMs in großem Maßstab erforderlichen Berechtigungen entfallen. ^[4].

Für Unternehmen, die nach einem schlüsselfertigen Netzwerk-Stack suchen, integriert Kubermatic Virtualization KubeOVN als Standard-SDN und bietet damit flaches L2/L3-Netzwerk, VPC-Isolierung, Subnetze, NAT-Gateways, Elastic IPs und Routing-Tabellen – alles als Kubernetes-CRDs implementiert und über dieselbe Steuerungsebene verwaltbar.

8. Erweiterbarkeit und Entwicklererfahrung

8.1 Proxmox: Geschlossene Erweiterbarkeit

Proxmox lässt sich nur in begrenztem Umfang erweitern: durch benutzerdefinierte Skripte, die an Ereignisse im Lebenszyklus von VMs angebunden werden, die REST-API für externe Automatisierung und die Perl-basierte Codebasis für die wirklich Abenteuerlustigen. Es gibt kein Plugin-System, kein Operator-Muster und keinen CRD-Mechanismus. Man kann keinen neuen Ressourcentyp definieren. Man kann keinen Controller schreiben, der auf VM-Ereignisse reagiert. Man kann eine VM-Vorlage nicht als Helm verpacken und über ein Chart-Repository verbreiten.

Die Entwicklererfahrung im Bereich der Automatisierung sieht folgendermaßen aus: API-Dokumentation lesen, Skript schreiben, ausführen, Fehler beheben. Das funktioniert. Es lässt sich jedoch nicht auf Self-Service-Plattformen übertragen.

Wie eine technische Analyse aus dem Jahr 2025 auf CloudInfra.blog dokumentierte: „Proxmox verfügt nicht über umfassende, unternehmensgerechte APIs für die dynamische Bereitstellung von Knoten oder die automatisierte Erweiterung. Die meisten dieser Vorgänge erfordern eine manuelle Eingabe über die Befehlszeile oder benutzerdefinierte Skripte, was die Automatisierung und Agilität einschränkt.“ ^[10] In derselben Analyse wird angemerkt, dass Proxmox über keine eigenen Terraform- oder Ansible-Module verfügt – stattdessen ist das System vollständig auf von der Community gepflegte Provider angewiesen , die „oft veraltet, schlecht dokumentiert sind und zwischen verschiedenen Proxmox-Versionen nicht mehr funktionieren.“ ^[10]

8.2 KubeVirt: Von Grund auf erweiterbar

KubeVirt profitiert vom Erweiterungsmodell von Kubernetes:

• CRDs: Definieren Sie benutzerdefinierte Ressourcen, die auf VMs verweisen. A Datenbankcluster CRD kann VM-Spezifikationen, ConfigMaps, Dienste und Netzwerkrichtlinien in einer einzigen, kombinierbaren Einheit zusammenfassen.
• Operatoren: Schreiben Sie Controller, die den Lebenszyklus von VMs verwalten. Ein Operator kann eine VM bereitstellen, sie über cloud-init konfigurieren, sie bei einem Load Balancer registrieren und Zustandsprüfungen durchführen – alles als einen einzigen automatisierten Workflow.
• Helm Kustomize: Packen Sie VM-Definitionen in Helm . Verteilen Sie diese über Artefakt-Repositorys. Überschreiben Sie Werte je nach Umgebung. So lässt sich die Infrastruktur gemeinsam nutzen und versionieren.
• Webhooks: Admission-Webhooks überprüfen und passen die VM-Spezifikationen an. Sie sorgen für die automatische Durchsetzung von Unternehmensstandards.
• Benutzerdefinierte Controller: Nutzen Sie Kubernetes-Informer und Client-Go, um benutzerdefinierte Automatisierungen zu erstellen, die auf die Erstellung, Migration und Löschung von VMs reagieren.
• KubeVirt-Verbesserungsvorschläge (VEPs): Seit Version 1.6 hat das Projekt seinen Verbesserungsprozess mit VEPs (analog zu den KEPS von Kubernetes) formalisiert und damit transparent und gemeinschaftsorientiert gestaltet ^[4].

Für Plattformteams bedeutet dies einen grundlegenden Wandel. Sie schreiben keine Skripte für eine API. Sie erstellen Abstraktionen. Ein Entwickler fordert eine VM an, indem er eine benutzerdefinierte Ressource erstellt. Ihr Operator stellt diese bereit. Ihre Richtlinien überprüfen sie. Ihre GitOps-Pipeline stellt sie bereit. Der Entwickler hat niemals direkten Kontakt mit dem Hypervisor, und das Plattformteam muss nie wieder ein Bereitstellungskrypt schreiben.

9. Projektgeschwindigkeit und Reifegrad des Ökosystems

9.1 KubeVirt: CNCF-Incubator-Projekt mit rasantem Wachstum

KubeVirt ist ein CNCF-Incubator-Projekt (aufgenommen im April 2022) mit beträchtlicher und messbarer Dynamik. Die folgende Tabelle fasst die aktuellen Ökosystemkennzahlen zusammen, wie sie von der CNCF gemeldet wurden:

Der Release-Rhythmus ist ambitioniert und diszipliniert: v1.5 (März 2025), v1.6 (Juli 2025), v1.7 (November 2025), v1.8 (März 2026). Jede Version entspricht einer Kubernetes-Nebenversion (v1.8 entspricht Kubernetes v1.35). Das Projekt hat seine Governance mit VEPs und einer wachsenden Anzahl von Special Interest Groups (SIGs) formalisiert, die die Bereiche Rechenleistung, Netzwerke, storage und Skalierung abdecken.

Die Breite dieses Ökosystems ist von Bedeutung. Mit über 500 beteiligten Organisationen und einem regelmäßigen Release-Rhythmus, der auf Kubernetes abgestimmt ist, profitiert KubeVirt von vielfältigen Investitionen und ist nicht von der Roadmap eines einzelnen Anbieters abhängig.

Namhafte Unternehmen aus verschiedenen Branchen bestätigen die Einsatzreife von KubeVirt:

9.2 Proxmox: Kleines Kernteam, langsamere Weiterentwicklung im Unternehmensbereich

Proxmox wird von der Proxmox Server Solutions GmbH entwickelt, einem österreichischen Unternehmen mit einem kleinen Kernentwicklungsteam. Das Community-Forum ist zwar aktiv (und für Homelab-Nutzer sehr wertvoll), doch das Tempo der unternehmensorientierten Funktionsentwicklung ist begrenzt. Proxmox VE 9.0 wurde im August 2025 veröffentlicht und basiert auf Debian 13 (Trixie). Proxmox VE 8.x erreicht im August 2026 das Ende der Lebensdauer (EOL).

Wichtigste Erkenntnisse:

• Keine Unterstützung durch die CNCF oder eine Stiftung. Proxmox ist ein Projekt eines einzelnen Anbieters ohne unabhängiges Governance-Modell.
• Langsame Entwicklung der Multi-Tenancy. SDN wurde erst vor kurzem eingeführt und erfordert für eine echte Mandantenisolierung nach wie vor die manuelle Konfiguration von RBAC, Firewall-Regeln und Routing.
• Der Support für Unternehmen ist eingeschränkt. Die „Community“-Stufe (120 € pro CPU-Sockel pro Jahr) bietet Zugriff auf das Enterprise-Repository, jedoch keine Support-Tickets und kein SLA. Die Reaktionszeiten und der Umfang der „Premium“-Stufe entsprechen nicht denen etablierter Anbieter von Virtualisierungslösungen für Unternehmen ^[13].
• Keine formellen Konformitätszertifizierungen. Proxmox verfügt nicht über Zertifizierungen nach ISO 27001, SOC 2 oder BSI IT-Grundschutz. Für deutsche und EU-Unternehmen, die den Anforderungen von NIS2 oder des BSI unterliegen, stellt dies eine Lücke dar, die durch ein Community-Forum nicht geschlossen werden kann.

10. Kostenvergleich: Gesamtbetriebskosten

Abbildung 6: Vergleich der relativen Gesamtbetriebskosten (TCO). Proxmox (dunkel) im Vergleich zu KubeVirt (hell). Zwar sind beide Lösungen lizenzfrei, doch weichen die Betriebskosten deutlich voneinander ab, sobald man den Aufwand für Automatisierung, Mandantenfähigkeit, Überwachung und Skalierung berücksichtigt.

Ein häufig vorgebrachtes Argument für Proxmox ist, dass es „kostenlos“ sei. Das stimmt im engsten Sinne: Der Download der Software selbst kostet nichts. Aber die Gesamtbetriebskosten (TCO) beschränken sich nicht auf die Lizenzkosten.

10.1 Proxmox-Gesamtbetriebskosten (TCO)

10.2 Gesamtbetriebskosten (TCO) von KubeVirt

Fazit: Die „kostenlose“ Lizenz von Proxmox wird durch höhere Betriebskosten, Personalaufwand für zwei unterschiedliche Paradigmen und strenge Skalierungsgrenzen ausgeglichen. Für Unternehmen, die bereits Kubernetes einsetzen, entsteht durch die Einführung von Proxmox eine Kostenstelle, die durch KubeVirt vollständig entfällt.

11. Einhaltung von Vorschriften und Zertifizierung

Für europäische Unternehmen, insbesondere solche, die den Anforderungen des BSI-IT-Grundschutzes, der ISO 27001 oder der NIS2 unterliegen, sind die Compliance-Eigenschaften Ihrer Infrastrukturplattform kein optionales Extra – sie sind gesetzliche Vorgaben.

Proxmox: Keine Compliance-Grundlage

Proxmox verfügt über keine formellen Compliance-Zertifizierungen. Es gibt keine ISO 27001-Zertifizierung für die Proxmox-Plattform. Es liegt kein SOC-2-Bericht vor. Es gibt kein BSI-IT-Grundschutz-Profil. Es gibt keinen CIS-Benchmark für die Absicherung von Proxmox. Unternehmen, die Proxmox in regulierten Umgebungen einsetzen, müssen ihre eigenen Compliance-Nachweise von Grund auf erstellen.

Das Fehlen einer strukturierten Protokollierung von Audits (über Syslog hinaus), einer Zugriffskontrolle und der Durchsetzung von Richtlinien erschwert den Nachweis der technischen Kontrollmaßnahmen, die gemäß ISO 27001 Anhang A oder dem BSI-IT-Grundschutz erforderlich sind. Das Berechtigungsmodell von Proxmox lässt sich nicht eindeutig auf das Prinzip der geringsten Berechtigungen übertragen, wie es in diesen Rahmenwerken definiert ist.

KubeVirt: Auf einer konformen Plattform aufgebaut

Kubernetes verfügt über ein ausgereiftes Compliance-Ökosystem:

• Der CIS-Kubernetes-Benchmark bietet detaillierte Anleitungen zur Absicherung.
• Red Hat OpenShift (einschließlich OpenShift Virtualization auf Basis von KubeVirt) verfügt über die Zertifizierungen nach ISO 27001, SOC 2 und FIPS 140-2.
• Kubermatic KKP wurde unter Berücksichtigung der Compliance-Anforderungen entwickelt und unterstützt die Zuordnung von Kontrollmaßnahmen gemäß BSI IT-Grundschutz und ISO 27001.
• OPA/Gatekeeper und Kyverno setzen Compliance-Richtlinien bereits bei der Zulassung durch: keine Container mit Sonderrechten, keine VMs ohne genehmigte Labels, verbindliche Ressourcenbeschränkungen.
• Die Audit-Protokollierung von Kubernetes liefert strukturierte, abfragbare Aufzeichnungen jedes API-Aufrufs – genau das, was Auditoren benötigen.

Für deutsche und EU-Unternehmen bedeutet der Einsatz von KubeVirt auf einer konformen Kubernetes-Plattform, dass Ihre VM-Infrastruktur die Compliance-Eigenschaften übernimmt, in die Sie bereits für Ihre Container-Infrastruktur investiert haben. Bei Proxmox müssen Sie ein separates Compliance-Konzept von Grund auf neu aufbauen.

12. Erweiterte Funktionen: GPU, SR-IOV und KI-/ML-Workloads

12.1 KubeVirt: Erstklassige Hardwarebeschleunigung

Angesichts der explosionsartigen Zunahme von KI-/ML-Workloads hat KubeVirt massiv in die Unterstützung von Hardwarebeschleunigung investiert:

• GPU-Passthrough: Vollständig unterstützt für NVIDIA-, AMD- und Intel-GPUs. Der NVIDIA-GPU-Operator lässt sich direkt in KubeVirt integrieren und ermöglicht so die Erkennung von GPU-Ressourcen, die Installation von Treibern sowie die Konfiguration des Passthroughs über Kubernetes-CRDs. Es sind keine manuellen Skripte zur PCI-Zuordnung erforderlich.
• NVIDIA vGPU und MIG: KubeVirt unterstützt die NVIDIA vGPU-Partitionierung und Multi-Instance GPU (MIG) für eine fein abgestufte gemeinsame Nutzung von GPUs zwischen virtuellen Maschinen.
• SR-IOV: KubeVirt lässt sich in den Kubernetes SR-IOV Network Operator integrieren und bietet so eine nahezu native Netzwerkleistung. Virtuelle Funktionen können direkt den VMs zugewiesen werden, wodurch der Netzwerkstack des Hypervisors umgangen wird.
• Intel Graphics SR-IOV: Intels kubevirt-gfx-sriov Das Projekt ermöglicht Graphics SR-IOV für die gemeinsame Nutzung von GPUs in virtualisierten Umgebungen.
• Unterstützung der PCIe-NUMA-Topologie (v1.8): Mit KubeVirt v1.8 wurde die Unterstützung der PCIe-NUMA-Topologie eingeführt, wodurch KI- und HPC-Workloads nahezu native Leistung erzielen können, da eine korrekte NUMA-Ausrichtung von CPU, Arbeitsspeicher und PCIe-Geräten gewährleistet wird ^[4].
• Confidential Computing (v1.8): Die Intel TDX-Attestierung ermöglicht es virtuellen Maschinen (VMs), kryptografisch nachzuweisen, dass sie auf vertraulicher Hardware ausgeführt werden – eine entscheidende Funktion für regulierte KI-Workloads, die sensible Daten verarbeiten ^[4].

12.2 Proxmox: Grundlegende GPU-Unterstützung, keine KI-/ML-Integration

Proxmox unterstützt GPU-Passthrough über die PCI-Passthrough-Konfiguration, allerdings handelt es sich dabei um einen manuellen Vorgang: Das PCI-Gerät muss identifiziert, zur VM-Konfiguration hinzugefügt und die VFIO-Treiberzuordnung auf dem Host sichergestellt werden. Es gibt weder einen Operator noch ein CRD noch eine dynamische Ressourcenerkennung. Die Unterstützung für NVIDIA vGPU wurde in Proxmox VE 9 (August 2025) hinzugefügt und erfordert Treiberkompatibilität mit GRID Version 18.3 oder höher.

Es gibt kein Äquivalent zum Kubernetes-Geräte-Plugin-Modell. Es gibt keinen SR-IOV-Netzwerk-Operator. Es gibt keine MIG-Unterstützung. Bei der VM-Planung wird die NUMA-Topologie nicht berücksichtigt. Es gibt keine Integration von Confidential Computing.

Für Unternehmen, die KI-/ML-Workloads ausführen – wofür zunehmend GPU-beschleunigte VMs mit ausgefeilter Planung erforderlich sind –, bietet Proxmox zwar die reine Funktionalität des PCI-Passthroughs, jedoch ohne die Orchestrierung, die dessen produktionsreife Nutzung in großem Maßstab erst ermöglicht.

13. Kubermatic-Virtualisierung: Die komplette KubeVirt-basierte Hypervisor-Suite

In den vorangegangenen Abschnitten wurden die architektonischen Vorteile von KubeVirt als Kubernetes-native Virtualisierungs-Laufzeitumgebung dargelegt. KubeVirt ist jedoch ein Projekt und kein Produkt. Um KubeVirt in der Produktion einzusetzen, muss ein Stack zusammengestellt werden: ein Kubernetes-Cluster auf Bare-Metal-Servern, ein SDN für die Vernetzung der virtuellen Maschinen, ein Load Balancer für die Bereitstellung von Services, ein Provisioning-Workflow für die zugrunde liegende Infrastruktur sowie operative Tools für das Day-2-Management.

Kubermatic Virtualization ist das Produkt, das diesen Stack als einheitliches, unterstütztes Ganzes bereitstellt. Es handelt sich dabei nicht um eine UI-Schicht, die auf KubeVirt aufsetzt – sondern um eine vollständige Hypervisor-Suite, die auf Open-Source-Komponenten basiert und in der jede Schicht gezielt integriert ist.

Architektur

Abbildung 7: Der Kubermatic-Virtualisierungsstack – von der Bare-Metal-Bereitstellung über die VM-Laufzeit bis hin zur zentralisierten Verwaltung; jede Schicht basiert auf Kubernetes-nativen Komponenten.

KubeVirt – VM-Laufzeitumgebung

KubeVirt ist die Virtualisierungs-Engine, die das Herzstück der Kubermatic-Virtualisierung bildet. Sie bietet:

• CRDs für Virtuelle Maschine und Virtuelle Maschineninstanz, wodurch VMs zu vollwertigen Kubernetes-Objekten werden, die über kubectl, Helm oder ArgoCD.
• libvirt-basierte Pods für jede VM, die vom Kubernetes-Scheduler mit vollständiger Unterstützung für Affinität, Taints und Topologie eingeplant werden.
• Containerized Data Importer (CDI) zum Importieren von VM-Images aus HTTP, S3, Container-Registries oder PVC-Klonen, mit inkrementeller Sicherung und Changed Block Tracking in Version 1.8.
• Live-Migration als vollwertiger Vorgang, integriert in das Draining und die Eviction von Kubernetes-Knoten.

Kubermatic Virtualization liefert das Upstream-Projekt KubeVirt ohne Fork aus und gewährleistet so vollständige Kompatibilität mit dem CNCF-Ökosystem und allen zukünftigen KubeVirt-Versionen.

KubeOVN – SDN/VPC-Netzwerk

KubeOVN (ein CNCF-Sandbox-Projekt) stellt die softwaredefinierte Netzwerkebene bereit:

• Flaches L2/L3-Netzwerk für alle Workloads (VMs und Container nutzen dieselbe Netzwerkstruktur).
• VPC-Isolierung mit Subnetzen, NAT-Gateways, Elastic IPs und Routing-Tabellen – alles als Kubernetes-CRDs implementiert.
• Durchsetzung von Netzwerkrichtlinien auf VPC- und Subnetz-Ebene, wodurch eine echte Isolierung zwischen verschiedenen Mandanten ermöglicht wird.
• EVPN und clusterübergreifende Konnektivität für regionenübergreifende Bereitstellungen.

Dies ist kein optionales Add-on. Bei der Kubermatic-Virtualisierung ist KubeOVN die standardmäßige und empfohlene CNI, die bereits bei der Installation vorkonfiguriert wird. VMs erhalten IP-Adressen aus derselben Subnetzstruktur wie Container, ohne dass eine manuelle Bridge-Konfiguration erforderlich ist.

KubeOne – Bereitstellung und Lebenszyklus von Bare-Metal-Systemen

KubeOne kümmert sich um die Infrastruktur:

• Automatisierte Bereitstellung von Kubernetes-Clustern auf Bare-Metal-Servern, wodurch eine Gruppe von Servern in einen produktionsbereiten KubeVirt-Host-Cluster umgewandelt wird.
• Vollständiges Lebenszyklusmanagement: Upgrades, Zertifikatsrotation und Skalierung der Knoten über deklarative Konfiguration.
• Unterstützung für Air-Gapped-Umgebungen: Jede Komponente wird als OCI-Artefakt ausgeliefert, und das Installationsprogramm übernimmt die Offline-Spiegelung des Images.
• Bereitstellung von Tenant-Clustern: KubeOne erstellt zudem Tenant-Kubernetes-Cluster innerhalb von KubeVirt-VMs, wodurch Teams auf einer gemeinsam genutzten Infrastruktur über eigene, isolierte K8s-Umgebungen verfügen.

KubeLB – Native Lastverteilung

KubeLB bietet die Integration des LoadBalancer-Dienstes, die in Bare-Metal-Kubernetes-Umgebungen in der Regel fehlt:

• Muttersprachler Lastenausgleich Art der Dienstleistung für VM-Workloads, vergleichbar mit den Load Balancern von Cloud-Anbietern.
• In den meisten Einsatzszenarien entfällt dadurch die Notwendigkeit, MetalLB oder einen externen Load Balancer zu konfigurieren.
• Integriert mit KubeOVN für eine nahtlose Weiterleitung des Datenverkehrs von externen Clients zu auf VMs gehosteten Diensten.

Benutzeroberfläche für die zentralisierte Verwaltung

Die Kubermatic Virtualization UI ist die Bedienkonsole – eine zentrale Übersicht für:

• Lebenszyklus von VMs: Erstellen, Starten, Beenden, Migrieren und Löschen von VMs per Mausklick oder über die Befehlszeile.
• Netzwerk: Verwalten Sie VPCs, Subnetze, NAT-Gateways und Elastic IPs.
• Storage: Bereitstellung und Verwaltung von PVCs für VM-Festplatten, Anzeige storage Speicherklassenauslastung.
• Clusterverwaltung: Überwachung und Verwaltung sowohl des Infrastruktur-Clusters als auch der Mandanten-Cluster.
• Überwachung: Integrierte Dashboards für den Zustand der VMs, die Ressourcenauslastung und Ereignisse.

Die Benutzeroberfläche bündelt die Leistungsfähigkeit von KubeVirt, KubeOVN und KubeOne in einer intuitiven Oberfläche und macht sie so auch für Administratoren zugänglich, die möglicherweise keine Kubernetes-Experten sind ^[14].

Deklarativer Installer

Kubermatic Virtualization enthält ein speziell entwickeltes Installationsprogramm mit zwei Modi:

• Interaktiver TUI-Assistent: Geführte Einrichtung für die Erstbereitstellung mit vorkonfigurierten Standardwerten storage Lastenausgleich.
• GitOps-YAML: deklarative Konfiguration, die in Git versionsverwaltet werden kann. Nachfolgende Durchläufe sind selbstheilend: Sollten sich die Konfigurationen verschieben, reicht eine erneute Ausführung kubermatic-virtualization anwenden bringt den Cluster wieder in den gewünschten Zustand.

Beide Modi unterstützen eine vollständig luftisolierte Bereitstellung, wobei alle Container-Images als OCI-Artefakte für Offline-Registries verfügbar sind.

HA und Live-Migration

Hochverfügbarkeit ist bei Kubermatic Virtualization kein Zusatzmodul – sie ist fester Bestandteil der Architektur:

• Kubernetes-Reconciliation: Wenn eine VM abstürzt, startet der KubeVirt-Controller sie automatisch auf einem funktionsfähigen Knoten neu.
• Live-Migration: Verschieben Sie laufende VMs ohne Ausfallzeiten zwischen physischen Hosts und ermöglichen Sie so eine nahtlose Hardwarewartung.
• Lymphknotenentleerung: kubectl drain löst die Live-Migration aller VMs auf dem Zielknoten aus, wobei die Planungsrichtlinien berücksichtigt werden.
• Hochverfügbarkeit der Steuerungsebene: Die Kubernetes-Steuerungsebene läuft im HA-Modus mit etcd-Quorum, wodurch sichergestellt wird, dass die Verwaltungsebene auch bei Ausfällen einzelner Knoten weiter funktioniert.

Datenschutz

• CSI-integrierte Datensicherung: VM-Festplatten sind PersistentVolumeClaims und vollständig kompatibel mit den Snapshot- und Datensicherungsfunktionen aller CSI-Treiber.
• Inkrementelle CDI-Sicherung mit CBT (KubeVirt v1.8): storage inkrementelle VM-Sicherungen unter Verwendung von QEMU/libvirt Changed Block Tracking, wodurch Sicherungsfenster verkürzt und storage reduziert werden.
• Integration von Backup-Lösungen von Drittanbietern: Zum Partner-Ökosystem von Kubermatic gehören Trilio und Portworx für Backup und Disaster Recovery auf Enterprise-Niveau, auf die über Kubernetes-native APIs zugegriffen werden kann.

Sicherheit

• RBAC: Fein abgestimmte, rollenbasierte Zugriffskontrolle auf Namespace- und Ressourcenebene.
• Netzwerkrichtlinien: werden von KubeOVN auf VPC- und Subnetz-Ebene durchgesetzt und sorgen für eine L3/L4-Isolierung zwischen den Mandanten.
• Zugriffskontrollmechanismen: OPA/Gatekeeper oder Kyverno-Integration zur Durchsetzung von Richtlinien vor der Erstellung von VMs.
• Audit-Protokollierung: strukturierte Kubernetes-Audit-Protokolle für jeden API-Aufruf.
• Zero Trust: Kein Benutzer, kein Gerät und keine Arbeitslast gilt von vornherein als vertrauenswürdig – kontinuierliche Authentifizierung und Autorisierung, bevor Zugriff gewährt wird ^[14].

Partner-Ökosystem

Kubermatic Virtualization lässt sich in die Lösungen etablierter Unternehmensanbieter integrieren:

• Storage: NetApp, Dell, Pure Storage und alle CSI-kompatiblen storage .
• Backup und Notfallwiederherstellung: Portworx, Trilio und andere Kubernetes-native Backup-Lösungen.
• Sicherheit: Kyverno zur Durchsetzung von Richtlinien, OPA/Gatekeeper zur Zugriffskontrolle.

Kundenvalidierung

Die Infrastruktur von Swisscom basiert auf einem vollständig aus Open-Source-Komponenten bestehenden Stack – KKP, KubeVirt und Kube-OVN auf Bare-Metal-Servern –, um einen CNCF-zertifizierten Kubernetes-Dienst mit vollständiger Datenhoheit innerhalb der Schweiz bereitzustellen ^[15].

14. Schlussfolgerung und Empfehlung

Der Vergleich zwischen Proxmox und KubeVirt ist keine Checkliste mit Funktionen. Es handelt sich um einen Paradigmenvergleich. Proxmox steht für das traditionelle Hypervisor-Paradigma: imperativ, eigenständig, GUI-zentriert. KubeVirt steht für das Kubernetes-native Paradigma: deklarativ, komponierbar, API-zentriert.

Für Unternehmen, die bereits in Kubernetes investiert haben, ist die strategische Entscheidung klar. KubeVirt beseitigt operative Zweiteilung, bietet Sicherheit und Mandantenfähigkeit auf Enterprise-Niveau, nutzt die CSI- und CNI-Ökosysteme in vollem Umfang, ermöglicht GitOps für VMs und bietet Erweiterbarkeit durch CRDs, Operatoren und das breitere Kubernetes-Ökosystem. Proxmox kann trotz seiner Zugänglichkeit diese Funktionen nicht bieten, da sie architektonische Grundlagen erfordern, über die Proxmox nicht verfügt und die sich auch nicht nachträglich einbauen lassen.

Die Daten belegen dies. 26 % der Kubernetes-Anwender setzen KubeVirt bereits in der Produktion ein ^[1]. 2.036 Mitwirkende aus 528 Organisationen arbeiten an der Entwicklung von KubeVirt ^[11]. Die Aufnahme in das CNCF-Inkubationsprogramm bestätigt die Projektführung, die Vitalität der Community und die Einsatzreife des Projekts. Der Release-Rhythmus (v1.5 → v1.6 → v1.7 → v1.8 innerhalb von 12 Monaten) zeugt von anhaltender Entwicklungsdynamik. Die Hypervisor-Abstraktionsschicht von KubeVirt v1.8, die Unterstützung für vertrauliches Rechnen sowie die Validierung der Skalierbarkeit auf 8.000 VMs belegen die Einsatzreife des Projekts ^[4].

Die Empfehlung:

Wenn Sie Kubernetes als Plattform nutzen, setzen Sie KubeVirt für die Virtualisierung ein. Verwenden Sie keinen separaten Hypervisor für VMs. Die Kosten für den Betrieb zweier Infrastrukturparadigmen übersteigen die Kosten für die Konsolidierung auf ein einziges.

Für Unternehmen, die diesen Umstieg in Betracht ziehen, bietet Kubermatic Virtualization den kompletten Stack: KubeVirt für die VM-Laufzeitumgebung, KubeOVN für SDN/VPC-Netzwerke, KubeOne für die Bare-Metal-Bereitstellung, KubeLB für den Lastausgleich, eine zentralisierte Verwaltungsoberfläche und ein deklaratives Installationsprogramm – alles als ein einziges Produkt. Es ist der schlüsselfertige Weg von „Wir wollen Kubernetes-native VMs“ bis hin zu „Wir verfügen über eine Hypervisor-Suite für den Produktiveinsatz“.

15. Wann Proxmox sinnvoll ist

Der Fairness halber muss man anerkennen, in welchen Bereichen Proxmox seine Stärken ausspielt. Proxmox ist eine ausgezeichnete Wahl, wenn:

• Das Unternehmen investiert nicht in Kubernetes. Wenn Sie ein kleines Unternehmen, ein Heimlabor oder ein Team sind, das keine Container einsetzt und auch nicht plant, dies zu tun, bietet Ihnen Proxmox leistungsfähige Virtualisierung mit geringem Lernaufwand.
• Die integrierte ZFS-Unterstützung ist eine Grundvoraussetzung. Die ZFS-Integration von Proxmox ist wirklich gut umgesetzt. Snapshots, Send/Receive und Komprimierung sind erstklassige Funktionen. Für Teams, die großen Wert auf Backups legen und ihren storage selbst verwalten, ist dies von großer Bedeutung.
• LXC-Container erfüllen Ihre Anforderungen an Container. Die LXC-Integration von Proxmox bietet eine schlanke Container-Isolierung ohne den Overhead von Kubernetes. Für einfache System-Container-Workloads ist dies ausreichend.
• Das Budget ist der wichtigste einschränkende Faktor. Proxmox ist kostenlos und Open Source. Die einzigen Anschaffungskosten bestehen in der Hardware. KubeVirt erfordert einen Kubernetes-Cluster, was Betriebsaufwand und möglicherweise kostenpflichtige Plattformlizenzen mit sich bringt.
• Scale is modest (<30 nodes, <500 VMs). Proxmox's limitations become visible at scale. Below this threshold, they may not matter.

Das Schlüsselwort in jedem dieser Fälle lautet „einfach“. Proxmox spielt seine Stärken aus, wenn die Anforderungen einfach und der Umfang überschaubar sind. Schwierigkeiten hat es hingegen, wenn die Anforderungen komplex werden, wenn sich mehrere Teams die Infrastruktur teilen, wenn die Automatisierung robust sein muss und wenn VMs und Container unter einem einheitlichen Betriebsmodell koexistieren müssen.

Quellen

1. Spectro Cloud, „KubeVirt in der Praxis“, Dezember 2025.
2. Proxmox VE Wiki, „Cluster-Manager“.
3. Proxmox-Forum, „Maximale Clustergröße“.
4. KubeVirt-Community, „Ankündigung der Veröffentlichung von KubeVirt v1.8“, 25. März 2026.
5. Telmate/terraform-provider-proxmox, GitHub-Issues.
6. Kubermatic, „Was ist KubeVirt und wie fügt es sich in die Kubermatic-Virtualisierung ein?“, 30. April 2026.
7. Proxmox-Forum: „Wie lassen sich Ressourcenkontingente für Tenants pro Pool durchsetzen?“
8. DEV-Community, „Proxmox-Leitfaden für Multi-Tenant-Umgebungen: RBAC vs. SDN vs. MSL – Einrichtung 2026“, März 2026.
9. Proxmox-Forum, „Ressourcenkontingente pro Pool für CPU, RAM und Festplatte“, Februar 2026.
10. CloudInfra.blog, „Warum Proxmox nicht für den Einsatz in Unternehmen geeignet ist: Eine technische Analyse“, November 2025.
11. CNCF, „KubeVirt-Projektseite“.
12. KubeVirt-Veröffentlichungen.
13. Petronella Tech, „Ist Proxmox kostenlos? Erläuterungen zur Unternehmenslizenzierung 2026“, Mai 2026.
14. Kubermatic, „Produktseite zu Kubermatic Virtualization“.
15. Kubermatic: „Swisscoms Weg von der Anbieterabhängigkeit zur Cloud-nativen Infrastrukturplattform.“
16. InfoQ, „KubeVirt v1.8 bietet Unterstützung für mehrere Hypervisoren und vertrauliches Rechnen für Kubernetes“, März 2026.
17. „Spezielle Migrationsnetzwerke für die Live-Migration zwischen Clustern“, KubeVirt.io, Oktober 2025.
18. „Erreichen der Fluchtgeschwindigkeit für die OpenShift-Virtualisierung“, Red Hat, April 2026.
19. NVIDIA-GPU-Operator mit KubeVirt.
20. Kubermatic, „Das Warten hat ein Ende: Kubermatic Virtualization 1.0 ist verfügbar“, November 2025.
21. Kubermatic-Virtualisierungsdokumentation, Version 1.1.0.
22. „Was VMware-Experten über die Live-Migration mit KubeVirt wissen müssen“, Portworx, April 2026.
23. „Kubernetes-Sicherheit und Einhaltung der Norm ISO 27001“, ARMO, Januar 2026.
24. Simplyblock, „Proxmox vs. KubeVirt“, März 2026.
25. „Sicherheit und Mandantenfähigkeit: Rollen, Pools, API-Token und Isolation“, Berik Ashimov, September 2025.
26. „Einschränkungen von Proxmox in Unternehmensumgebungen“, Siberoloji, Dezember 2025.
27. CNCF-Fallstudie: „Swisscom leistet mit KubeVirt und Kube-OVN Pionierarbeit im Bereich der souveränen Cloud“, Mai 2026.

Dieses Whitepaper spiegelt die technische Sichtweise von Kubermatic zum Stand Juli 2026 wider. Sowohl Proxmox als auch KubeVirt werden aktiv weiterentwickelt, und die Funktionen werden ständig erweitert. Die architektonischen Argumente sind jedoch grundlegender Natur: Deklaratives Zustandsmanagement, API-First-Design und die Erweiterbarkeit des Ökosystems sind keine Funktionen, die einem imperativen System nachträglich hinzugefügt werden können. Sie erfordern eine Architektur, die von Anfang an darauf ausgelegt ist. Kubernetes bietet diese Architektur. KubeVirt übernimmt sie.