Open-Source-VM-Migration: VMware und OpenStack zu RHOSO 18.0 oder Community-OpenStack. Ihre VMs laufen weiter.
Cutover in Minuten.

Seamless Migrate ist eine Open-Source-Control-Plane unter der Apache License 2.0, die virtuelle Maschinen von Red Hat OpenStack Platform 17.1, Community-OpenStack (einschließlich Kolla-Ansible) und VMware vSphere nach Red Hat OpenStack Services on OpenShift (RHOSO) 18.0 oder in eine Community-OpenStack-Cloud von 2023.1 Antelope bis 2026.2 Hibiscus migriert. Seamless Migrate plant Wellen, schätzt die Ausfallzeit jeder VM, kopiert Festplatten im laufenden Betrieb, macht jeden Cutover von einer Freigabe und einem Wartungsfenster abhängig, verifiziert jede VM auf dem Ziel und rollt sie automatisch zurück, wenn eine Prüfung fehlschlägt.

Fügen Sie vCenter (vSphere 7.0U3 oder 8.x) als Quelle und RHOSO 18.0 oder eine Community-OpenStack-Cloud als Ziel hinzu, planen Sie dann Wellen und validieren Sie sie. Für VMs mit Changed Block Tracking (CBT) greift die Warm-Migration: CBT-Durchläufe kopieren die Festplatten im laufenden Betrieb, und beim Cutover wird nur das letzte Delta übertragen, gefolgt von einer In-Place-Konvertierung mit virt-v2v. Für VMs ohne CBT greift die Cold-Migration: erst eine vollständige Kopie, dann die Konvertierung. Die Daten laufen über das vmware-migration-kit von os-migrate und einen Konvertierungshost mit VDDK in der Ziel-Cloud.

Ja. Das Adoptionsverfahren von Red Hat wandelt eine 17.1-Umgebung an Ort und Stelle um. Passt das nicht, etwa bei neuer Hardware, einem neuen Storage-Backend, einem Netzwerkumbau wie dem Wechsel von ML2/OVS zu ML2/OVN oder mehreren Clouds, die konsolidiert werden sollen, migriert Seamless Migrate die Workloads parallel: Netzwerke, Sicherheitsgruppen, Flavors, Images, Schlüsselpaare, Projekte und Benutzer werden auf RHOSO neu angelegt, dann wird jede VM per Cold-Migration, Warm-Migration oder Storage-Übergabe übertragen.

Ja. Neben RHOSO 18.0 ist jede Release-Serie von Community-OpenStack, von 2023.1 Antelope bis 2026.2 Hibiscus, ein Ziel, unabhängig davon, ob sie mit Kolla-Ansible, OpenStack-Ansible oder einem anderen Werkzeug bereitgestellt wurde: Registrieren Sie die Cloud mit der Voreinstellung OpenStack Community oder Kolla-Ansible, dann laufen dieselben Strategien Cold-Migration, Warm-Migration und Storage-Übergabe auch dort. Die Provider-Prüfung meldet für jedes Ziel Release-Serie, Support-Stufe und Richtlinienprofil, und die Vorabprüfung blockiert einen Plan bei einer fehlenden Fähigkeit, bevor sich etwas bewegt. RHOSO 18.0 ist heute die Zielplattform; die Laborvalidierung des Releases steht noch aus; der Laborlauf auf jeder im Upstream gepflegten Community-Serie steht noch aus und kommt vor einem finalen Release.

Das hängt von der Strategie und der VM ab. Für ein Volume mit 200 GiB, davon 120 GiB belegt, bei 2 MiB/s Schreiblast im Gast und einer Verbindung mit 125 MiB/s veranschlagt das Planungsmodell 20 Min. 53 Sek. für eine Cold-Kopie, 11 Min. 20 Sek. für eine Warm-Migration und 4 Min. 20 Sek. für eine Storage-Übergabe. Die Ausfallzeit einer Warm-Migration richtet sich nach dem letzten Delta und einem Scan der Festplatte, nicht nach der vollständigen Kopie.

Eine Cold-Migration stoppt die VM und kopiert ihre belegten Daten; die Ausfallzeit wächst daher mit der Festplattengröße. Eine Warm-Migration kopiert die Festplatten in Snapshot-Durchläufen im laufenden Betrieb und stoppt die VM nur für das letzte Delta. Eine Storage-Übergabe kopiert überhaupt keine Daten: Teilen sich beide Clouds einen Ceph-Cluster oder eine NetApp ONTAP SVM, gibt Cinder jedes Volume an der Quelle per unmanage ab und übernimmt es auf dem Ziel per manage, sodass die Ausfallzeit unabhängig von der Größe wenige Minuten beträgt.

Ja, als in der Simulation validierte Technology Preview. VMs mit einer NVIDIA vGPU, per Time-Slicing oder MIG, oder mit einer vollständig durchgereichten GPU werden migriert, sobald ihr Plan jede GPU einem GPU-Flavor des Ziels zuordnet; eine GPU-VM ohne Zuordnung bleibt blockiert. Die Validierung gleicht die GPUs des Plans mit der freien Kapazität des Ziels in Placement ab, und das Cutover-Gate liest sie vor dem Stopp der Quelle erneut: Ist kein Platz, wartet die Migration und die Quelle läuft weiter. Eine VMware-VM mit durchgereichter GPU zieht nur per Cold-Migration um, ausgeschaltet. Die Labortests auf GPU-Hosts stehen noch aus.

Feste IPs und MAC-Adressen bleiben standardmäßig erhalten. Als in der Simulation validierte Technology Preview kann ein Plan außerdem die Adresse jeder Floating IP behalten, die nach dem Stopp der Quelle umzieht und beim Rollback zurückgegeben wird, und bei einer geänderten Adresse einen DNS-Eintrag in Designate oder auf einem RFC-2136-Server umstellen. Die Verifizierung wartet, bis jede umgezogene Adresse antwortet, und zählt die Wartezeit zur Ausfallzeit; Seamless selbst spricht kein BGP. Den Rest übernehmen Hooks, die ein Admin registriert, Ansible-Playbooks oder HTTPS-Webhooks, und die Vorabprüfung nennt, was Sache des Betriebs bleibt, etwa Heat-Stacks, Autoscaling-Gruppen und Octavia-Pools.

Ja, bis zur Finalisierung. Ein Rollback entfernt die Instanz auf dem Ziel, behält ihre Volumes und startet die Quell-VM wieder; eine fehlgeschlagene Verifizierung löst ihn automatisch aus. Vor der Finalisierung werden keine Quelldaten gelöscht, und die Finalisierung erfordert eine freigabeberechtigte Person und den vollständig eingegebenen Namen der VM.

Bei OpenStack-Quellen werden KVM-Gäste auf KVM übertragen, daher startet alles, was auf der Quelle startet, auch auf dem Ziel: RHEL 5 bis 10, CentOS, Rocky, AlmaLinux, Oracle Linux, Ubuntu, Debian, SLES, openSUSE, Windows Server 2003 bis 2025 und Windows 7 bis 11. Bei VMware konvertiert virt-v2v den Gast: RHEL 7 bis 10 und Windows Server 2016 bis 2025 werden von Red Hat unterstützt; andere Gäste funktionieren nach einer Testkopie oder benötigen vorab installierte virtio-Treiber.

Seamless Migrate besteht aus einem Container-Image und PostgreSQL 16. Betreiben Sie es auf OpenShift 4.16 oder neuer neben RHOSO, auf Kubernetes 1.28 oder neuer (EKS, AKS, GKE, RKE2, k3s, kubeadm) oder auf einem einzelnen Host: mit der eigenen Docker Engine eines Linux-Servers, 20.10 oder neuer mit Compose v2.20 (Ubuntu, Debian, RHEL, Rocky Linux, AlmaLinux, Fedora; ohne Colima, ohne Node.js), mit Colima auf einem Mac oder mit Podman 4.7 oder neuer. Ein einziges Betriebsskript, seamless-ctl.sh, fährt eine Bereitstellung auf jeder Plattform auf dieselbe Weise hoch und herunter, startet sie neu, skaliert sie und lässt vor einem geplanten Stopp die laufenden Pläne auslaufen. Eine Demo mit simulierten Clouds läuft auf einem Laptop und benötigt keine Cloud-Zugangsdaten.

Ja. Seamless Migrate ist Open Source unter der Apache License 2.0, und der Quellcode liegt auf GitHub.

Nein. Seamless Migrate ist ein unabhängiges Open-Source-Projekt. Es steht in keiner Verbindung zu Red Hat, der OpenInfra Foundation oder Broadcom, wird von ihnen weder gesponsert noch befürwortet und ist durch keine Subscription von Red Hat abgedeckt. Es baut auf der Upstream-Ansible-Collection os-migrate auf, die weiterhin die Daten überträgt.

os-migrate exportiert und importiert Tenant-Ressourcen und kopiert Workloads per Cold-Migration, wobei die VM während der gesamten Kopie gestoppt bleibt. Seamless Migrate baut darauf auf und ergänzt Warm-Migration für OpenStack-Quellen, Storage-Übergabe, die Orchestrierung von VMware-Warm-Migrationen sowie eine Control Plane mit Plänen, Wellen, Schätzungen der Ausfallzeit, Freigaben, Verifizierung, Rollback, Dashboard, REST API und CLI.