Cozystack vs. VMware — der Detailvergleich für Platform Engineers

Dieser Artikel setzt voraus, dass Sie beide Plattformen kennen. Eine breitere Orientierung zum Ausstieg aus VMware finden Sie unter VMware-Alternative oder VMware-Migration.

Compute-Schicht

VMware vSphere/ESXi: ausgereifter Typ-1-Hypervisor. Starkes Lifecycle-Management für VMs, Live-Migration mit Shared Storage, vMotion. Enge Integration der VMware Tools in die Gastsysteme.

Cozystack KubeVirt: qemu/KVM, verpackt in Pods. KVM selbst ist ein Hypervisor im Kernel-Modus, der Gast läuft also weiterhin auf den Virtualisierungserweiterungen der Hardware — der Pod ist eine Hülle für Scheduling und Lifecycle, keine zusätzliche Emulationsschicht. Live-Migration (CPU; GPU-Live-Migration ist eine branchenweite Einschränkung). Unter der Haube Standard-QEMU/KVM; breite Unterstützung für Gastbetriebssysteme.

In der Praxis liefern beide VM-Workloads in Produktionsqualität. Das KubeVirt-Modell bringt zusätzlich die betriebliche Integration in Kubernetes mit (deklarative VM-Konfiguration, GitOps-Lifecycle, natives Ingress, Observability).

Storage-Schicht

VMware vSAN: in vSphere integrierter Software-defined Storage. Im Betrieb reibungslos, eng integriert. An die VMware-Lizenzierung gebunden.

Cozystack LINSTOR: replizierter Open-Source-Blockspeicher, ausgerollt über den Piraeus-Operator. LINSTOR nutzt DRBD für die synchrone Replikation; Object Storage ist eine eigene Schicht (SeaweedFS). Mehr Verantwortung im Betrieb, mehr architektonische Flexibilität.

Für die meisten Workloads erreicht LINSTOR die betrieblichen Eigenschaften von vSAN. Wo zusätzlich Object Storage im S3-Stil gebraucht wird, liefert Cozystack SeaweedFS als verwalteten Bucket-Service mit.

Netzwerkschicht

VMware NSX: Software-defined Networking. Verteilte virtuelle L2-Switches, L3-Routing, Mikrosegmentierung, Edge Gateway. Ausgereift, aber komplex.

Cozystack Cilium: eBPF-basiertes CNI mit L4/L7-Policies, Observability, Service-Mesh-Integration, MetalLB / BGP. Neuere Architektur, oft einfacher.

Die Migration aus einer NSX-lastigen Umgebung zu Cilium erfordert ein Redesign der Policies — eine 1:1-Abbildung gibt es nicht. Das Architekturmodell ist ein anderes.

Mandantenschicht

VMware vCloud Director: ausgereiftes Multi-Tenant-Overlay auf vSphere. Funktionen für Service Provider (Organisationen, vDC, Kataloge).

Cozystack Tenant CRD: Kubernetes-native Abstraktion für Mandantenfähigkeit. Verschachtelte Tenants, Quotas pro Tenant, mandantenbezogenes Audit, abrechnungsfreundlich.

Das Mandantenmodell ist konzeptionell ein anderes — vCD-Organisationen gegenüber Instanzen des Tenant CRD. Bei der Migration muss die Mandantenstruktur auf das Kubernetes-native Äquivalent neu abgebildet werden.

Folgen für den Betrieb

Tagesgeschäft

VMware: vCenter-UI für Ad-hoc-Aufgaben; PowerCLI / Ansible für die Automatisierung. SSH ist nicht das Standardmodell.

Cozystack: kubectl plus GitOps als Standardmodell. Cozystack-Dashboard-UI für Tenant-Aufgaben. Review von GitOps-PRs als Change-Management.

Der Wechsel vom vCenter-zentrierten zum kubectl-zentrierten Arbeiten ist für VMware-geschulte Teams eine echte Lernkurve im Betrieb. Die meisten Engineers arbeiten sich mit gezieltem Training in 4–8 Wochen ein.

Upgrades

VMware: zuerst Upgrade von vCenter, dann ESXi-Upgrade Host für Host (rollierend). Ausgereifter Prozess.

Cozystack: Upgrade von Talos OS, von Kubernetes und vom Cozystack-Operator. GitOps-gesteuert. Rollierend Host für Host.

Beide arbeiten mit Rolling Upgrades. Im Betrieb ähnlich im Geist, aber mit unterschiedlichem Tooling.

Backup / DR

VMware Site Recovery Manager: ausgereifte DR-Orchestrierung. Im großen Maßstab erprobt.

Cozystack Velero plus PITR pro Anwendung: Velero übernimmt das Backup auf Cluster-Ebene; anwendungsspezifische Muster (PostgreSQL PITR usw.) kommen darüber. Mehr bewegliche Teile, mehr Flexibilität.

Für geschäftskritisches DR funktioniert beides. Das Muster ist ein anderes — SRM ist eine vom Hersteller verwaltete Plug-and-Play-Lösung; der Velero-Stack ist transparenter und besser anpassbar.

Migrationsmuster

Die Migration von VMware zu Cozystack in der Produktion:

1. Discovery — Inventar von vSphere/VCF; Klassifizierung der Workloads.
2. Cozystack-Fundament — paralleles Deployment; kein Tenant von VMware.
3. Image-Migration — KubeVirt CDI importiert VMDK- oder qcow2-Images. Bei Windows-VMs werden die VMware Tools vor dem ersten Start unter KubeVirt bereinigt.
4. Netzwerk-Cutover — Abbildung der VLANs in Cilium; die Gleichwertigkeit der Policies wird gegen die NSX-Regeln validiert.
5. Storage-Cutover — vSAN → LINSTOR (DRBD); Datenmigration während des Cutovers der jeweiligen Kohorte.
6. DR-Cutover — Velero ersetzt SRM; wird pro Kohorte getestet.
7. Abschaltung von VMware — gestaffelt, sobald die Kohorten abgeschlossen sind.

Typische Gesamtdauer vom Assessment bis zur Abschaltung: 7–10 Monate bei weniger als 100 VMs, 10–16 Monate bei 100–500 und 16–25 Monate bei 500–2000 VMs. Treiber ist selten die reine Kopiergeschwindigkeit — es sind die Regressionstests und die Parallelbetriebsfenster, denen die Verantwortlichen der Anwendungen zustimmen.

Wann der Vergleich zählt

Diese Detailtiefe ist hilfreich, wenn:

• ein Architektur-Review läuft
• die Umsetzung in Phase 2 geplant wird
• konkrete betriebliche Fragen anstehen (Storage-Performance, Netzwerklatenz usw.)
• Schulungen für das Team geplant werden

Für eine Bewertung auf höherer Ebene ist VMware-Alternative der passendere Einstieg.