Apache CloudStack stirbt nicht — es ist ein aktives Apache-Projekt, das während des VMware-Exodus sogar Nutzer gewonnen hat. Anbieter verlassen es aus einem anderen Grund: Ihre Kunden wollen inzwischen Managed Kubernetes, Datenbanken und Object Storage neben den VMs, und CloudStack plus separater Kubernetes-Stack bedeutet zwei Steuerebenen bezahlen und beide besetzen.
Passt zu: Ænix Public Cloud Platform — CloudStack-Umgebungen werden fast immer an externe Kunden verkauft, also sind Mandantenmodell, Servicekatalog und Abrechnung die Teile, die den Wechsel überleben müssen. Siehe auch WHMCS-Integration, wenn über WHMCS abgerechnet wird.
Wann CloudStack bleiben sollte
Wenn Ihr Produkt virtuelle Maschinen sind, Ihre Umgebung stabil auf KVM läuft, Ihre Kunden weder Container noch Managed Data Services nachfragen und Ihr Team die Codebasis kennt, gibt es keinen Migrationsgrund. CloudStack wird gepflegt, das Modell aus Zonen, Pods und Clustern skaliert, und ein funktionierendes IaaS durch ein gleichwertiges IaaS zu ersetzen bringt nichts.
Der Grund entsteht, wenn das Produkt breiter werden muss. Wer 2026 ausschließlich VMs verkauft, konkurriert über den Preis mit allen anderen, die ausschließlich VMs verkaufen. Sobald Managed Kubernetes, Managed PostgreSQL, S3-kompatibler Storage oder GPU-Kapazität auf der Roadmap stehen, lautet die Frage nicht mehr „welches IaaS“, sondern „wie viele Steuerebenen will ich betreiben“.
Wie die Zuordnung tatsächlich aussieht
| CloudStack | Ziel in Cozystack | Charakter der Migration |
|---|---|---|
| KVM-Gäste, QCOW2 auf NFS- oder Ceph-Primary-Storage | KubeVirt-VMs, Disk-Import über CDI | Mechanisch. Kein Neuaufbau bei Linux; Windows braucht VirtIO-Behandlung. |
| Templates und ISOs im Secondary Storage | Image-Quellen für DataVolumes | Mechanisch. |
| Domains, Accounts, Projects | Tenant-CRD-Hierarchie plus Kubernetes-RBAC und OIDC | Neumodellierung. Domain-Baum und Mandantenbaum sind beide hierarchisch, aber nicht gleich geschnitten. |
| Service- und Disk-Offerings | Katalogdefinitionen und Storage-Klassen | Neumodellierung. Unkompliziert, aber jedes genutzte Offering muss erfasst werden — Anbieter finden regelmäßig Offerings, an deren Verkauf sich niemand erinnert. |
| Virtual Router (DHCP, Source NAT, Port Forwarding, Static NAT, Site-to-Site-VPN, LB) | Cilium plus Plattformdienste; kein einzelnes Ersatzobjekt | Neuentwurf. Der größte Einzelposten. |
| Isolated Networks, VPCs, Network Offerings | Cilium-Networking mit Policy pro Mandant; LB-IPAM mit BGP oder L2-Announcements | Neuentwurf, gekoppelt an den Adressplan. |
| Security Groups (Basic Zones) | Kubernetes Network Policy | Neumodellierung. Gleiche Absicht, andere Ausdrucksform. |
| Primary Storage (NFS / Ceph RBD) | LINSTOR/DRBD, oder das bestehende Ceph-Cluster über den Ceph-CSI-Treiber weiter nutzen | Ceph behalten oder Daten umziehen. Eine Entwurfsentscheidung, kein erzwungener Wechsel. |
| Secondary Storage | Object Storage auf der Plattform | Meist ein direkter Umzug. |
| SystemVMs (SSVM, Console Proxy) | Plattformkomponenten; Konsole über das Mandanten-Dashboard | Ersetzt, nicht migriert. |
| CloudStack-API | Kubernetes-API und Mandanten-Dashboard | Neubau für alle, die dagegen automatisieren. |
| Usage Records | Metrik-Stack der Plattform | Umhängen. Betrifft die Abrechnung — früh einplanen. |
Der Virtual Router ist der Neuentwurf. In CloudStack ist er eine Appliance pro Netz, die DHCP, DNS-Forwarding, Source NAT, Port Forwarding, Static NAT, Load Balancing und Site-to-Site-VPN erledigt. Auf einer Kubernetes-nativen Plattform liegen diese Funktionen an verschiedenen Stellen: Adressvergabe und Policy in Cilium, externe Adressen über LB-IPAM mit BGP- oder L2-Announcements, VPN als expliziter Dienst dort, wo ein Kunde ihn wirklich braucht. Die meisten Anbieter stellen im Assessment fest, dass über den gesamten Kundenstamm nur zwei oder drei Funktionen des Virtual Routers real genutzt werden — die Inventur muss aber pro Kunde erfolgen, denn der eine Mandant mit Site-to-Site-VPN ist meist derjenige, der am meisten zahlt.
Kundenseitige API-Schlüssel bestimmen den Zeitplan. Wenn Ihre Kunden ausschließlich das Portal nutzen, ist die API-Oberfläche eine interne Angelegenheit und Sie planen die Migration selbst. Halten Kunden eigene CloudStack-API-Schlüssel und automatisieren damit, führen Sie eine öffentliche API-Abkündigung durch — mit einer Kommunikationsfrist in Quartalen. Diese Unterscheidung verändert die Form des gesamten Programms und gehört in die erste Woche des Assessments.
Ablauf der Migration
- Architektur-Review. Offering-Inventur, Nutzung der Virtual-Router-Funktionen pro Kunde, Umfang der kundenseitigen API-Schlüssel, Abrechnungsanbindungen, Adressplan. Ergebnis ist eine Zielarchitektur und eine Kohortenfolge Kunde für Kunde.
- Parallel-Deployment. Die neue Plattform entsteht neben den laufenden CloudStack-Zonen. Beide laufen für die Dauer nebeneinander.
- Abrechnung und Portal zuerst. Provisioning und Metering werden umgehängt, bevor Kunden-Workloads umziehen, damit migrierte Kunden vom ersten Tag auf der neuen Plattform korrekt abgerechnet werden. Diese Reihenfolge ist Absicht: Wer die Abrechnung ans Ende schiebt, migriert Kunden, die er nicht fakturieren kann.
- Kohorten-Migration. Kunden ziehen in Gruppen um, die kleinsten und tolerantesten zuerst. Jede Kohorte wird im Parallel-Run validiert, bevor ihre CloudStack-Seite freigegeben wird.
- Decommission und Katalog-Erweiterung. Freigewordene CloudStack-Hosts werden in den Zielcluster überführt, und der Servicekatalog wächst über VMs hinaus — genau deshalb hat sich die Migration gelohnt.
Typische Dauer: vier bis zwölf Monate für einen mittelgroßen Anbieter.
Wie Ænix arbeitet
- Platform Readiness Assessment — Offering- und Virtual-Router-Inventur, Mandanten- und Adressentwurf, Umfang der Abrechnungsanbindung, Kohortenplan, Risikoregister.
- Pilot-Kohorte — die erste Kundengruppe migriert mit Ænix-Ingenieuren im Team; daraus entstehen die Runbooks für den Rest.
- Rollende Migration — Kohorte für Kohorte, im Parallel-Run validiert, mit nachwandernder Hardware.
- Betrieb — Ihr Team mit Cozystack Enterprise Support im Rücken, oder Betrieb durch Ænix.
Ænix ist das Team hinter Cozystack (CNCF-Projekt, Apache 2.0).