Migration open source de VM : VMware et OpenStack vers RHOSO 18.0 ou OpenStack communautaire. Gardez vos VM en service.
Basculez en quelques minutes.

Seamless Migrate est un plan de contrôle open source, sous Apache License 2.0, qui migre des machines virtuelles de Red Hat OpenStack Platform 17.1, d’OpenStack communautaire (y compris Kolla-Ansible) et de VMware vSphere vers Red Hat OpenStack Services on OpenShift (RHOSO) 18.0 ou un cloud OpenStack communautaire, de 2023.1 Antelope à 2026.2 Hibiscus. Il planifie les vagues, estime le temps d’arrêt de chaque VM, copie les disques pendant que les VM continuent de fonctionner, soumet chaque bascule à une approbation et à une fenêtre de changement, vérifie chaque VM sur la destination et déclenche automatiquement le retour arrière si un contrôle échoue.

Ajoutez vCenter (vSphere 7.0U3 ou 8.x) comme source et RHOSO 18.0 ou un cloud OpenStack communautaire comme destination, puis planifiez les vagues et validez-les. Les VM avec Changed Block Tracking (CBT) migrent en mode warm : des passes CBT copient les disques pendant que la VM fonctionne, et à la bascule seul le delta final est copié avant une conversion virt-v2v sur place. Les VM sans CBT migrent à froid : copie complète, puis conversion. Les données transitent par le vmware-migration-kit d’os-migrate et un hôte de conversion équipé de VDDK dans le cloud de destination.

Oui. La procédure d’adoption de Red Hat convertit un déploiement 17.1 sur place. Quand elle ne convient pas, en raison d’un nouveau matériel, d’un nouveau backend de stockage, d’une refonte du réseau comme le passage de ML2/OVS à ML2/OVN, ou de plusieurs clouds à consolider, Seamless Migrate migre les charges de travail en parallèle : il recrée réseaux, groupes de sécurité, flavors, images, paires de clés, projets et utilisateurs sur RHOSO, puis migre chaque VM à froid, en mode warm ou par transfert du stockage.

Oui. Outre RHOSO 18.0, toutes les séries de versions d’OpenStack communautaire, de 2023.1 Antelope à 2026.2 Hibiscus, peuvent servir de destination, qu’elles aient été déployées avec Kolla-Ansible, OpenStack-Ansible ou un autre outil : enregistrez le cloud avec le préréglage OpenStack Community ou Kolla-Ansible, et les mêmes stratégies, copie à froid, warm et transfert du stockage, s’y appliquent. La vérification des fournisseurs indique la série de versions, le niveau de support et le profil de politique de chaque destination, et les contrôles préalables bloquent un plan dès qu’une capacité manque, avant tout déplacement. RHOSO 18.0 est aujourd’hui la plateforme cible ; la validation du candidat en laboratoire reste à effectuer ; la validation en laboratoire de chaque série communautaire maintenue upstream n’a pas encore eu lieu et précédera une version finale.

Cela dépend de la stratégie et de la VM. Pour un volume de 200 GiB dont 120 GiB utilisés, 2 MiB/s d’écritures côté invité et un lien à 125 MiB/s, le modèle de planification estime 20 min 53 s pour une copie à froid, 11 min 20 s pour une migration warm et 4 min 20 s pour un transfert du stockage. En migration warm, le temps d’arrêt dépend du delta final et d’un scan du disque, pas de la copie complète.

Une migration à froid arrête la VM et copie ses données utilisées, donc le temps d’arrêt augmente avec la taille du disque. Une migration warm copie les disques par passes d’instantanés pendant que la VM continue de fonctionner, et ne l’arrête que pour le delta final. Un transfert du stockage ne copie aucune donnée : quand les deux clouds partagent un cluster Ceph ou une SVM NetApp ONTAP, Cinder cesse de gérer chaque volume côté source (unmanage) et le prend en charge côté destination (manage), si bien que le temps d’arrêt reste de quelques minutes, quelle que soit la taille.

Oui, en Technology Preview validée en simulation. Les VM dotées d’un vGPU NVIDIA, en time-slicing ou adossé à MIG, ou d’un GPU passé en entier en passthrough migrent dès que leur plan associe chaque GPU à un flavor GPU de la destination ; une VM GPU sans association reste bloquée. La validation confronte les GPU du plan à la capacité libre de la destination dans Placement, et la porte de bascule la relit avant l’arrêt de la source : faute de place, la migration attend et la source continue de tourner. Une VM VMware avec un GPU en passthrough ne migre qu’à froid, éteinte. Les tests en laboratoire sur des hôtes GPU n’ont pas encore eu lieu.

Les IP fixes et les adresses MAC sont conservées par défaut. En Technology Preview validée en simulation, un plan peut aussi garder l’adresse de chaque floating IP, déplacée après l’arrêt de la source et rendue lors d’un retour arrière, et basculer un enregistrement DNS dans Designate ou sur un serveur RFC 2136 quand une adresse change. La vérification attend que chaque adresse déplacée réponde et compte cette attente dans l’interruption ; Seamless ne parle pas BGP lui-même. Les hooks enregistrés par un administrateur, playbooks Ansible ou webhooks HTTPS, couvrent le reste, et les contrôles préalables signalent ce qui reste à la charge de l’exploitation, comme les stacks Heat, les groupes d’autoscaling et les pools Octavia.

Oui, tant que vous n’avez pas finalisé. Le retour arrière supprime l’instance de destination, conserve ses volumes et redémarre la VM source ; une vérification en échec le déclenche automatiquement. Rien ne supprime les données source avant la finalisation, qui exige un approbateur et la saisie du nom complet de la VM.

Depuis OpenStack, les invités passent de KVM à KVM, donc tout ce qui démarre sur la source démarre sur la destination : RHEL 5 à 10, CentOS, Rocky, AlmaLinux, Oracle Linux, Ubuntu, Debian, SLES, openSUSE, Windows Server 2003 à 2025 et Windows 7 à 11. Depuis VMware, virt-v2v convertit l’invité : RHEL 7 à 10 et Windows Server 2016 à 2025 sont pris en charge par Red Hat ; les autres invités fonctionnent après une copie de test ou nécessitent d’installer d’abord les pilotes virtio.

Il se compose d’une image de conteneur et de PostgreSQL 16. Déployez-le sur OpenShift 4.16 ou ultérieure à côté de RHOSO, sur Kubernetes 1.28 ou ultérieure (EKS, AKS, GKE, RKE2, k3s, kubeadm), ou sur un hôte unique : le Docker Engine natif d’un serveur Linux, en version 20.10 ou ultérieure avec Compose v2.20 (Ubuntu, Debian, RHEL, Rocky Linux, AlmaLinux, Fedora ; sans Colima ni Node.js), un Mac avec Colima, ou Podman 4.7 ou ultérieure. Un seul script d’exploitation, seamless-ctl.sh, démarre et arrête un déploiement, le redémarre et le met à l’échelle de la même façon sur chaque plateforme, et draine les plans en cours avant un arrêt planifié. Une démo avec des clouds simulés tourne sur un ordinateur portable et ne demande aucun identifiant cloud.

Oui. Il est open source sous Apache License 2.0, et le code source est sur GitHub.

Non. C’est un projet open source indépendant : il n’est pas affilié à Red Hat, à l’OpenInfra Foundation ni à Broadcom, qui ne le parrainent ni ne le cautionnent, et aucune souscription Red Hat ne le couvre. Il s’appuie sur la collection Ansible upstream os-migrate, qui reste chargée de déplacer les données.

os-migrate exporte et importe les ressources des tenants et copie les charges de travail à froid, la VM restant arrêtée pendant toute la copie. Seamless Migrate s’appuie dessus et y ajoute un mode warm pour les sources OpenStack, le transfert du stockage, l’orchestration warm pour VMware et un plan de contrôle avec plans, vagues, estimations du temps d’arrêt, approbations, vérification, retour arrière, tableau de bord, REST API et CLI.