Migración de VM de código abierto: de VMware y OpenStack a RHOSO 18.0 u OpenStack de la comunidad. Mantén tus VM en marcha.
Conmuta en minutos.

Seamless Migrate es un plano de control de código abierto, bajo la Apache License 2.0, que migra máquinas virtuales de Red Hat OpenStack Platform 17.1, OpenStack de la comunidad (incluido Kolla-Ansible) y VMware vSphere a Red Hat OpenStack Services on OpenShift (RHOSO) 18.0 o a una nube OpenStack de la comunidad, de 2023.1 Antelope a 2026.2 Hibiscus. Planifica oleadas, estima el tiempo de inactividad de cada VM, copia los discos mientras las VM siguen en marcha, condiciona cada conmutación a una aprobación y a una ventana de cambios, verifica cada VM en el destino y la revierte automáticamente si falla una comprobación.

Añade vCenter (vSphere 7.0U3 u 8.x) como origen y RHOSO 18.0 o una nube OpenStack de la comunidad como destino; después, planifica las oleadas y valídalas. Las VM con Changed Block Tracking (CBT) se migran en modo warm: las pasadas de CBT copian los discos mientras la VM sigue en marcha y, en la conmutación, solo se transfiere el delta final antes de una conversión in situ con virt-v2v. Las VM sin CBT se migran en frío: una copia completa y, después, la conversión. Los datos se mueven mediante el vmware-migration-kit de os-migrate y un host de conversión con VDDK en la nube de destino.

Sí. El procedimiento de adopción de Red Hat convierte in situ un despliegue 17.1. Cuando eso no encaja, por hardware nuevo, un nuevo backend de almacenamiento, un rediseño de red como el paso de ML2/OVS a ML2/OVN o varias nubes que consolidar, Seamless Migrate traslada las cargas de trabajo en paralelo: recrea en RHOSO las redes, los grupos de seguridad, los flavors, las imágenes, los pares de claves, los proyectos y los usuarios, y después migra cada VM en frío, en modo warm o por traspaso del almacenamiento.

Sí. Además de RHOSO 18.0, cada serie de versiones de OpenStack de la comunidad, de 2023.1 Antelope a 2026.2 Hibiscus, es un destino, tanto si se desplegó con Kolla-Ansible como con OpenStack-Ansible u otra herramienta: regístrala con la configuración predefinida OpenStack Community o Kolla-Ansible, y en ella se ejecutan las mismas estrategias en frío, warm y de traspaso del almacenamiento. La comprobación de proveedores informa de la serie de versiones, el nivel de soporte y el perfil de políticas de cada destino y, si falta una capacidad, la validación previa bloquea un plan antes de mover nada. Hoy, RHOSO 18.0 es la plataforma de destino; la validación de la versión en laboratorio sigue pendiente; la prueba en el laboratorio de cada serie de la comunidad con mantenimiento upstream aún no se ha hecho y llegará antes de una versión final.

Depende de la estrategia y de la VM. Para un volumen de 200 GiB con 120 GiB usados, 2 MiB/s de escrituras del sistema invitado y un enlace de 125 MiB/s, el modelo de planificación estima 20 min 53 s para una copia en frío, 11 min 20 s para una migración warm y 4 min 20 s para un traspaso del almacenamiento. En la migración warm, el tiempo de inactividad depende del delta final y de un escaneo del disco, no de la copia completa.

Una migración en frío detiene la VM y copia sus datos usados, así que el tiempo de inactividad crece con el disco. Una migración warm copia los discos en pasadas de instantáneas mientras la VM sigue en marcha y solo la detiene para el delta final. Un traspaso del almacenamiento no copia ningún dato: cuando ambas nubes comparten un clúster de Ceph o una SVM de NetApp ONTAP, Cinder hace unmanage de cada volumen en el origen y manage en el destino, así que el tiempo de inactividad es de pocos minutos sea cual sea el tamaño.

Sí, como Technology Preview validada en simulación. Las VM con una vGPU de NVIDIA, por time-slicing o basada en MIG, o con una GPU completa en passthrough migran en cuanto su plan asigna cada GPU a un flavor con GPU del destino; una VM con GPU sin asignación sigue bloqueada. La validación compara las GPU del plan con la capacidad libre del destino en Placement, y la puerta de conmutación la vuelve a leer antes de detener el origen: si no hay sitio, la migración espera y el origen sigue en marcha. Una VM de VMware con una GPU en passthrough solo se mueve en frío, apagada. Las pruebas de laboratorio en hosts con GPU aún no se han hecho.

Las IP fijas y las direcciones MAC se conservan por defecto. Como Technology Preview validada en simulación, un plan también puede conservar la dirección de cada IP flotante, que se mueve tras detener el origen y se devuelve en una reversión, y cambiar un registro DNS en Designate o en un servidor RFC 2136 cuando cambia una dirección. La verificación espera hasta que cada dirección movida responde y cuenta esa espera en la inactividad; Seamless no habla BGP por sí mismo. Los hooks que registra un administrador, playbooks de Ansible o webhooks HTTPS, cubren el resto, y la validación previa señala lo que sigue a cargo del equipo de operaciones, como los stacks de Heat, los grupos de autoescalado y los pools de Octavia.

Sí, hasta que la finalices. Una reversión elimina la instancia del destino, conserva sus volúmenes y vuelve a arrancar la VM de origen, y una verificación fallida la inicia automáticamente. Nada borra datos del origen antes de la finalización, y la finalización requiere un aprobador y escribir el nombre completo de la VM.

Desde OpenStack, los invitados KVM pasan a KVM, así que todo lo que arranca en el origen arranca en el destino: RHEL del 5 al 10, CentOS, Rocky, AlmaLinux, Oracle Linux, Ubuntu, Debian, SLES, openSUSE, Windows Server del 2003 al 2025 y Windows del 7 al 11. Desde VMware, virt-v2v convierte el invitado: Red Hat da soporte a RHEL del 7 al 10 y a Windows Server del 2016 al 2025; los demás invitados funcionan tras una copia de prueba o requieren instalar antes los controladores virtio.

Es una sola imagen de contenedor más PostgreSQL 16. Despliégalo en OpenShift 4.16 o posterior junto a RHOSO, en Kubernetes 1.28 o posterior (EKS, AKS, GKE, RKE2, k3s, kubeadm) o en un único host: el Docker Engine 20.10 o posterior del propio servidor Linux con Compose v2.20 (Ubuntu, Debian, RHEL, Rocky Linux, AlmaLinux, Fedora; sin Colima ni Node.js), un Mac con Colima o Podman 4.7 o posterior. Un solo script de operaciones, seamless-ctl.sh, levanta y detiene un despliegue, lo reinicia y lo escala de la misma forma en todas las plataformas, y drena los planes en marcha antes de una parada planificada. Una demo con nubes simuladas se ejecuta en un equipo portátil y no necesita credenciales de nube.

Sí. Es de código abierto bajo la Apache License 2.0, y el código fuente está en GitHub.

No. Es un proyecto de código abierto independiente, que no está afiliado a Red Hat, a la OpenInfra Foundation ni a Broadcom, ni cuenta con su patrocinio o respaldo, y no está cubierto por ninguna suscripción de Red Hat. Se basa en la colección upstream de Ansible os-migrate, que sigue siendo la encargada de mover los datos.

os-migrate exporta e importa los recursos de los tenants y copia las cargas de trabajo en frío, con la VM detenida durante toda la copia. Seamless Migrate se basa en él y añade la migración warm para orígenes OpenStack, el traspaso del almacenamiento, la orquestación de VMware warm y un plano de control con planes, oleadas, estimaciones del tiempo de inactividad, aprobaciones, verificación, reversión, un panel, una REST API y una CLI.