Zum Inhalt springen
DE
NexCMP kostenlos sichern

Migration · VMware

Virtuelle Maschinen von VMware zu Apache CloudStack migrieren

Apache CloudStack kann virtuelle Maschinen aus VMware vCenter importieren und ab Version 4.19 nach KVM konvertieren. Für eine sichere Durchführung sind dennoch eine Inventarisierung, eine Zielzone, ein Testlauf und ein Cutover-Plan pro Maschine erforderlich. In den 30 Arbeitstagen von NexCMP Source übernimmt ein Fachingenieur diese Arbeiten gemeinsam mit Ihnen ohne Aufpreis.

NexCMP kostenlos sichernDemo ansehen

Enthalten in NexCMP Source ($499 einmalig), nicht in NexCMP Free. VMware, WHMCS, HostBill, Blesta, Paymenter, StackBill, Virtualizor und Apache CloudStack sind Marken ihrer jeweiligen Eigentümer. NexCMP ist unabhängig und steht in keiner Verbindung zu ihnen und wird nicht von ihnen unterstützt.

Das Problem: VMware verlassen, ohne die Kontrolle zu verlieren

Der Wechsel zu Apache CloudStack bedeutet für jede virtuelle Maschine einen Plattformwechsel: ihre Festplatten, Netzwerkkarten, Treiber und oft auch ihre Adressen. Wird dies überstürzt durchgeführt, führt das dazu, dass Maschinen nicht mehr starten, Kunden den Zugriff verlieren oder Lizenzen ungültig werden.

CloudStack stellt die Import-Tools bereit, entscheidet jedoch nicht für Sie, welche Maschinen zuerst migriert werden, wie die einzelnen Netzwerke zugeordnet werden, was mit Windows-Guests passiert oder wie lange die jeweilige Maschine offline sein wird. Diese Entscheidungen und die dazugehörigen Tests machen die eigentliche Migration aus.

Wenn Sie die virtuellen Maschinen an Kunden verkaufen, gibt es einen zweiten Teil der Migration: Die Maschinen müssen in Ihrem Abrechnungssystem den richtigen Kunden, Tarifen und Preisen zugeordnet werden. NexCMP bildet diese Billing- und Kundenportal-Ebene auf CloudStack, und derselbe Engineer übernimmt beide Teile.

Was CloudStack nativ unterstützt

Es gibt zwei dokumentierte Pfade von VMware weg. Welcher der passende ist, hängt davon ab, ob VMware-Hosts in Ihrer Cloud verbleiben.

  • A. Nach KVM konvertieren mit virt-v2v

    CloudStack-Dokumentation
    Ab Version 4.19 kann ein Administrator unter Tools, Import-Export Instances eine VMware-VM in einem bestehenden oder externen vCenter-Rechenzentrum auswählen und in einen KVM-Cluster importieren. Die VM wird exportiert, mit virt-v2v konvertiert und ihre Datenträger werden als QCOW2 importiert. Die neueste Dokumentation ergänzt den OVF-basierten Pfad um ein VDDK-basiertes Streaming; Version 4.22 ergänzte die direkte Konvertierung in einen Storage-Pool und Version 4.22.1 die Auswahl des Guest-Betriebssystems basierend auf dem Quell-Betriebssystem.
    Dokumentierte Einschränkungen
    virt-v2v wird vom CloudStack-Agenten nicht standardmäßig installiert und muss auf jedem KVM-Host eingerichtet werden, da die Konvertierung andernfalls fehlschlägt. Der Erfolg ist nicht garantiert und hängt vom Guest-Betriebssystem sowie den Dateisystemen ab; die Dokumentation empfiehlt daher Tests vor dem Produktiveinsatz. Die importierte VM erhält in 4.19 standardmäßig den Guest-OS-Typ CentOS 4.5 (32-bit) und muss anschließend angepasst werden.

    Source: Apache CloudStack — Import von VMware-VMs in KVM · abgerufen 2026-10-19

  • B. Direkt importieren (Unmanaged Instances)

    CloudStack-Dokumentation
    Für vSphere-Cluster, deren Hosts bereits Teil von CloudStack sind, listet listUnmanagedInstances die VMs auf, und importUnmanagedInstance übernimmt sie in die CloudStack-Verwaltung. Das Auflisten unmanaged VMware-Instanzen wurde in 4.14 eingeführt, das Entkoppeln (Unmanaging) in 4.15 und der Import über die Benutzeroberfläche in 4.16.
    Dokumentierte Einschränkungen
    Das Zielnetzwerk muss in CloudStack bereits vorhanden sein und der Storage muss als Primary Storage hinzugefügt werden. Datenfestplatten müssen Disk Offerings zugeordnet werden; gemischte Controller-Typen oder uneinheitliche NIC-Typen führen zu Fehlern. Eine laufende VM kann nur importiert werden, wenn das Netzwerk-VLAN und das Compute Offering übereinstimmen; andernfalls muss sie zuvor gestoppt werden.

    Source: Apache CloudStack — Über den Import und Export von Instances · abgerufen 2026-10-19

Pfad A gilt, wenn das Ziel KVM ist. Die Dokumentation von NexCMP nennt KVM als den getesteten Hypervisor; daher planen wir Pfad A, sofern Ihr Setup VMware-Hosts nicht unter CloudStack weiterführt. Prüfen Sie Ihre eingesetzte CloudStack-Version: Die oben verlinkten Seiten beschreiben abweichendes Verhalten zwischen 4.19 und dem neuesten Release.

Was migriert wird und worauf zu achten ist

  • Datenträger

    Vorgang
    Werden in QCOW2 konvertiert und in den Primary Storage Pool des Ziels importiert (Pfad A) oder CloudStack Disk Offerings zugewiesen (Pfad B).
    Beachten
    In Pfad B wird die Festplattengröße nicht angepasst, wenn das Disk Offering größer ist. Als temporärer Speicher während einer Pfad-A-Konvertierung dient standardmäßig der Secondary Storage; Primary Storage kann dafür nur genutzt werden, wenn es sich um NFS handelt.

    Source: Apache CloudStack — Import von VMware-VMs in KVM · abgerufen 2026-10-19

  • Netzwerke

    Vorgang
    Netzwerke müssen vor dem Import in CloudStack existieren. Ein Discovery-Skript listet die vCenter-Netzwerke auf, denen mindestens eine VM zugewiesen ist, damit die entsprechenden Netzwerke angelegt werden können.
    Beachten
    virt-v2v kann die Netzwerkkonfiguration eines Guests nicht rekonfigurieren und dessen MAC-Adresse nicht ändern. Weicht das Ziel-Subnetz ab, sind nach der Konvertierung Anpassungen im Guest erforderlich.

    Source: libguestfs — virt-v2v-Handbuch · abgerufen 2026-10-19

  • Linux-Guests

    Vorgang
    Eine laufende Linux-VM kann über Pfad A importiert werden: CloudStack klont sie vor dem Export, sodass sie in einem Crash-konsistenten Zustand konvertiert wird.
    Beachten
    Die CloudStack-Dokumentation empfiehlt, Linux-VMs vorher herunterzufahren. virt-v2v installiert keine neuen Kernel oder Treiber und warnt bei fehlender virtio-Unterstützung; das Gastsystem muss daher vor der Konvertierung die Mindestanforderungen an die Version erfüllen.

    Source: libguestfs — virt-v2v-Handbuch · abgerufen 2026-10-19

  • Windows-Gastsysteme

    Vorgang
    Müssen vor dem Import über Route A ordnungsgemäß heruntergefahren werden. virtio-Treiber werden aus dem Paket virtio-win bezogen und beim ersten Start installiert; Windows kann nach dem ersten Bootvorgang viermal oder öfter neu starten.
    Beachten
    Schnellstart (Fast Startup) oder Ruhezustand verhindern die Konvertierung, und Systemdatenträger auf dynamischen Datenträgern werden nicht unterstützt. Für den Import von Windows sind virtio-Treiber auf dem Konvertierungs-Host erforderlich.

    Source: libguestfs — virt-v2v-Handbuch · abgerufen 2026-10-19

  • VMware Tools

    Vorgang
    virt-v2v versucht, die VMware Tools zu deinstallieren.
    Beachten
    Laut Dokumentation funktioniert die Deinstallation unter Windows nicht zuverlässig, sodass die Tools möglicherweise anderweitig entfernt werden müssen.

    Source: libguestfs — virt-v2v-Handbuch · abgerufen 2026-10-19

  • Gast-Betriebssystemtyp

    Vorgang
    Die importierte VM erhält einen Standard-Gast-Betriebssystemtyp.
    Beachten
    In Version 4.19 ist dies CentOS 4.5 (32-Bit) und muss manuell geändert werden; Version 4.22.1 kann ihn anhand vorhandener Zuordnungen vom Quell-Gast-Betriebssystem übernehmen.

    Source: Apache CloudStack — Import von VMware-VMs in KVM · abgerufen 2026-10-19

  • Abrechnung und Kunden

    Vorgang
    Tarife, Preise und Kundenkonten werden in NexCMP eingerichtet, und jede migrierte Maschine wird dem zuständigen Kunden zugewiesen.
    Beachten
    Wird in Woche 1 für Ihre CloudStack-Version vereinbart. Dies ist eine NexCMP-Aufgabe, keine CloudStack-Funktion.

Der Ablaufplan, Woche für Woche

Typischer Ablauf, angepasst an Ihre Anforderungen. Die 30 Arbeitstage durchgehender Arbeit entsprechen etwa sechs Kalenderwochen.

  1. Woche 1 — Inventarisierung und Entscheidungen

    Mit Lesezugriff auf vCenter erfassen wir jede VM: Gast-Betriebssystem, Datenträger, Netzwerkkarten, VLANs, Snapshots, Energiestatus und Abhängigkeiten untereinander. Wir wählen Route A oder B, definieren die Migrationswellen und identifizieren Systeme mit besonderem Aufwand, wie Windows-Gäste, große Datenträger und Maschinen mit festen Lizenzbindungen.

  2. Woche 2 — Zielumgebung aufbauen

    Die CloudStack-Zone wird geprüft oder aufgebaut: KVM-Hosts, Storage und Netzwerke passend zur VMware-Umgebung. Wir installieren virt-v2v auf den KVM-Hosts (sowie nbdkit auf Ubuntu-Hosts), bereiten virtio-Treiber für Windows vor und öffnen die Netzwerkpfade zwischen den Konvertierungs-Hosts sowie vCenter und ESXi. Falls Sie die Maschinen vermarkten, wird NexCMP in derselben Woche installiert und mit CloudStack verbunden.

  3. Woche 3 — Pilotphase

    Einige unkritische Maschinen – exemplarisch für jeden Gastsystemtyp – durchlaufen den realen Migrationsprozess. Wir prüfen den Startvorgang, das Netzwerk sowie die passenden Treiber, setzen den Typ des Gast-Betriebssystems und messen die Ausfallzeit pro Maschine. Die Ergebnisse definieren die Zeitfenster für die Migrationswellen.

  4. Woche 4 und 5 — Migrationswellen

    Maschinen werden in Gruppen zu den vereinbarten Zeitfenstern migriert. Jede Gruppe wird validiert, bevor die nächste beginnt; die ursprünglichen VMware-Maschinen bleiben ausgeschaltet erhalten, um ein Rollback zu ermöglichen. Falls Sie die Maschinen vermarkten, werden Kunden, Tarife und Preise parallel in NexCMP eingerichtet und die Abrechnung wird vor der Umstellung parallel betrieben.

  5. Woche 6 — Finale Umstellung und Übergabe

    Die letzten Maschinen werden migriert, bei kommerzieller Nutzung wird der Abrechnungsstichtag umgestellt und DNS-Anpassungen werden vorgenommen. Wir dokumentieren die gesamte Durchführung, prüfen Hardening sowie Backups und stehen für die Umstellung bis zum Ende der 30 Arbeitstage bereit.

Nur ein Rahmenplan. Der verbindliche Ablaufplan entsteht in Woche 1; die einzige terminliche Zusicherung im Angebot sind die 30 Arbeitstage.

Risiken und wie wir sie minimieren

Keine Migration ist ohne Risiko, und wir versprechen keine Ausfallzeit von null. Hier erfahren Sie, welche Probleme auftreten können und wie wir ihnen begegnen.

  • Ausfallzeit pro Maschine

    Windows-Maschinen können nicht im laufenden Betrieb konvertiert werden, und laufende Linux-Maschinen werden im crash-konsistenten Zustand konvertiert. CloudStack macht keine Angaben zur Konvertierungsdauer. Wir ermitteln diese in der Pilotphase und vereinbaren daraufhin ein Wartungsfenster pro Maschinengruppe.

  • Eine Konvertierung schlägt fehl

    Laut CloudStack kann ein Erfolg nicht garantiert werden und hängt vom Gastsystem ab. Wir testen jeden Gastsystemtyp in der Pilotphase vor jeder Migrationswelle; das Originalsystem bleibt unangetastet, bis die neue Instanz erfolgreich geprüft wurde.

  • Treiber und VMware Tools

    Windows-Systeme erhalten virtio-Treiber während der Konvertierung, Linux-Systeme erfordern vorherige virtio-Unterstützung und VMware Tools müssen gegebenenfalls manuell deinstalliert werden. Dies wird pro Gastsystem in der Pilotphase validiert.

  • IP-Adressen, MAC-Adressen und DNS

    Gastsysteme behalten ihre MAC-Adressen und ihre eigene Netzwerkkonfiguration; ein abweichendes Ziel-Subnetz erfordert daher Änderungen im Gastsystem. Wir erfassen jede Adresse in Woche 1, senken die DNS-TTLs vor der Umstellung und informieren Ihre Kunden rechtzeitig.

  • Softwarelizenzen auf Gastsystemen

    Windows und kommerzielle Software innerhalb einer Maschine sind möglicherweise an die alte Plattform lizenziert. Wir erfassen sie im Inventar, damit Sie die Lizenzbedingungen vor der Migration mit dem jeweiligen Anbieter prüfen können.

  • Unterbrochene Konvertierungen

    Laut CloudStack unterbricht ein Neustart der Management-Server während einer Migration den Vorgang, sodass der Import neu gestartet werden muss. Wir planen Migrationswellen um Wartungsfenster herum und vermeiden Neustarts während eines laufenden Durchlaufs.

  • Billing-Cutover und Rollback

    Wenn Sie die Maschinen verkaufen, wird der Stichtag für die Abrechnungsumstellung gemeinsam mit Ihnen festgelegt, und beide Systeme laufen zunächst parallel. Die VMware-Originale bleiben erhalten, bis Sie den Abschluss der Migration bestätigen – so hat jede Gruppe einen Weg zurück.

Wer macht was

  • Read-Only-Zugriff auf vCenter und eine Liste der Maschinen, die Sie als kritisch einstufen

    Der Experte übernimmt
    Erfasst jede VM und plant die Migrationswellen

  • Zugriff auf die CloudStack-Umgebung und die KVM-Hosts oder die entsprechende Hardware für deren Bereitstellung

    Der Experte übernimmt
    Richtet die Zone, Netzwerke und die Konvertierungs-Hosts ein

  • Die für Ihren gewählten Migrationspfad erforderlichen VDDK- und virtio-Pakete, sofern die Anbieter einen manuellen Download vorschreiben

    Der Experte übernimmt
    Installiert und testet sie auf den Konvertierungs-Hosts

  • Abgestimmte Ausfallfenster und Benachrichtigungen an Ihre Kunden

    Der Experte übernimmt
    Führt die Pilotmigration und die Wellen durch und prüft jede Maschine im Anschluss

  • Ihre Preisentscheidungen, falls Sie die Maschinen verkaufen

    Der Experte übernimmt
    Richtet Tarife, Kunden und Abrechnung in NexCMP ein und betreut die Parallelphase

Was Sie in den 30 Arbeitstagen erhalten

Die Migration ist Teil des NexCMP Source-Upgrades: einmalig $499 inklusive des vollständigen Quellcodes (Rust-Server, Vue-Portal und -Admin, Go-Node-Agent, CLI, Build-Skripte), des uneingeschränkten Rechts zur Modifikation und Erstellung eigener Versionen, 12 Monaten Zugriff auf neue Quellcode-Releases, aller Apps sowie 30 Arbeitstagen kontinuierlicher Zusammenarbeit mit einem erfahrenen Ingenieur.

In diesen 30 Arbeitstagen migriert der Experte Sie ohne Aufpreis von VMware zu Apache CloudStack. Alternativ oder zusätzlich kann diese Zeit auch für die Migration von WHMCS oder einem anderen System, für eine vollständige A-bis-Z-Einrichtung oder für das Erstellen Ihrer Apps genutzt werden. Das Kontingent beginnt mit dem Start der Zusammenarbeit mit dem Experten und wird auf Ihrer Lizenzseite angezeigt. Der Migrationssupport gilt für denselben Zeitraum von 30 Tagen.

NexCMP Free beinhaltet dies nicht. NexCMP Free ist ein Jahr lang mit allen Modulen kostenlos und bietet keinen technischen Support, lediglich Fehlerbehebungen im Quellcode, und verlängert sich für $99 pro Jahr.

VMware zu CloudStack — Häufig gestellte Fragen

Was kostet es?
Die Migration ist Teil des NexCMP Source-Upgrades für einmalig $499. Der Preis beinhaltet den Quellcode, 12 Monate neue Quellcode-Releases, alle Apps sowie 30 Arbeitstage Zusammenarbeit mit einem erfahrenen Ingenieur. Das Angebot enthält keine Stundensätze.
Ist das in NexCMP Free enthalten?
Nein. Die Migration ist ausschließlich in NexCMP Source enthalten. NexCMP Free umfasst alle Module für ein Jahr, beinhaltet jedoch keinen technischen Support (nur Fehlerbehebungen im Quellcode) und verlängert sich für $99 pro Jahr.
Welche CloudStack- und VMware-Versionen werden unterstützt?
Laut CloudStack-Dokumentation ist die Konvertierung von VMware zu KVM ab Version 4.19 verfügbar; welche vSphere-Versionen unterstützt werden, wird dort nicht angegeben. Die aktuelle Dokumentation empfiehlt VDDK 8 für vSphere 7- und 8-Umgebungen. Die NexCMP-Dokumentation nennt 4.23 als getestetes CloudStack-Release. Prüfen Sie Ihre eingesetzte Version; wir verifizieren beide in Woche 1.
Kommt es bei meinen virtuellen Maschinen zu Ausfallzeiten?
Ja, jede Maschine ist für eine gewisse Zeit offline, und wir versprechen keine Zero-Downtime. Windows-Maschinen müssen vor dem Import ordnungsgemäß heruntergefahren werden. Eine laufende Linux-Maschine kann importiert werden, wird jedoch in einem crash-konsistenten Zustand konvertiert, weshalb wir sie im Regelfall vorab ausschalten. Im Pilotprojekt wird die Dauer gemessen und die Zeitfenster festgelegt.
Kann jede VM konvertiert werden?
Nicht zwingend. CloudStack weist darauf hin, dass der Erfolg nicht garantiert werden kann und vom Gast-Betriebssystem sowie den Dateisystemen abhängt. Bestimmte Windows-Konstellationen, wie etwa Systemdisks auf dynamischen Datenträgern oder Fast Startup, gelten bei virt-v2v als Blocker. Aus diesem Grund testen wir jeden Gast-Typ vor den Migrationswellen.
Muss ich VMware im Anschluss weiter betreiben?
Nicht für die migrierten Maschinen. Wir belassen die Originale ausgeschaltet, bis Sie bestätigen, dass die Migration abgeschlossen ist; anschließend entscheiden Sie, wann diese stillgelegt werden. Die Lizenzierung der VMware-Umgebung selbst liegt zwischen Ihnen und dem jeweiligen Anbieter.
Was muss ich bereitstellen?
Nur-Lese-Zugriff auf vCenter, Zugriff auf die CloudStack-Umgebung und deren KVM-Hosts, Ihre vereinbarten Wartungsfenster sowie ein Ansprechpartner für Fragen zu den Maschinen. Verlangt ein Hersteller, dass Sie Pakete wie das VDDK selbst herunterladen, stellen Sie dieses bereit.

Quellen und Hinweise

Technische Angaben stammen aus der offiziellen Dokumentation von Apache CloudStack und dem Handbuch zu virt-v2v. Da sich Dokumentationen zwischen Releases ändern, prüfen Sie bitte Ihre eingesetzte Version. Die Aussage zu 4.19 stammt aus der Version 4.19, deren VMware-zu-KVM-Dokumentation mit „As of CS 4.19“ beginnt. VMware, WHMCS, HostBill, Blesta, Paymenter, StackBill, Virtualizor und Apache CloudStack sind Marken ihrer jeweiligen Eigentümer. NexCMP ist unabhängig und steht in keiner geschäftlichen Verbindung zu ihnen oder wird von ihnen unterstützt.

Migrieren Sie von VMware weg – mit einem Engineer an Ihrer Seite

Führen Sie ein Upgrade auf NexCMP Source für $499 durch und starten Sie Ihr 30-Arbeitstage-Projekt, oder kontaktieren Sie vorab [email protected] bezüglich Ihrer Umgebung.

NexCMP kostenlos sichernVertrieb kontaktierenDemo ansehen

Zuletzt aktualisiert: