La neta, la virtualización tradicional con VMware se ha vuelto un dolor de cabeza económico para muchísimas organizaciones. Con los cambios recientes de licenciamiento y la incertidumbre del mercado, quedarse ahí amarrado ya no tiene sentido. Pero, a final de cuentas, dar el salto a una nube abierta no es una decisión de "copiar y pegar"; es una chamba estratégica y bien técnica.
Si estás buscando migrar a OpenStack, especialmente a las arquitecturas modernas basadas en contenedores como Red Hat OpenStack Services on OpenShift (RHOSO 18) desde una nube heredada o desde infraestructura tradicional de vSphere, la gran pregunta es: ¿cómo mueves cientos de máquinas virtuales, redes, subredes, routers y firewalls sin romper nada en el camino y sin que te dé un infarto?
En este artículo, te voy a compartir cómo diseñé un proceso de migración masiva automatizada utilizando la colección oficial de Ansible os-migrate, resolviendo los retos de integridad de datos, paridad de red y control quirúrgico sobre cada recurso.
El dolor de cabeza de VMware y el paraíso de OpenStack
Moverse de VMware a OpenStack ofrece soberanía tecnológica absoluta y te libra del lock-in del proveedor. Además, migrar a versiones modernas de OpenStack como RHOSO 18 trae una ventaja brutal: el plano de control corre directamente sobre Kubernetes/OpenShift. Esto combina la agilidad y resiliencia de los contenedores con el poder de orquestación de máquinas virtuales tradicionales.
Sin embargo, el desmadre empieza cuando te das cuenta de que una nube no es solo un montón de hipervisores corriendo discos. Una nube real está compuesta por:
- Estructura lógica de Keystone: Proyectos (tenants), usuarios, grupos y asignaciones de roles.
- Redes lógicas de Neutron: Proveedores de red, subredes, routers, políticas de DHCP y reglas de puertos.
- Seguridad (Security Groups): Firewalls lógicos con cientos de reglas de tráfico.
- Almacenamiento (Cinder): Volúmenes huérfanos, adjuntos o de arranque.
- Cargas de trabajo (Nova): Instancias de procesamiento con sus respectivos metadatos, puertos específicos y llaves de acceso.
Hacer esta migración a mano no vale la pena; es una receta garantizada para que todo valga madre al primer intento. Para resolver esto de volón, la automatización declarativa es tu mejor amiga.
El motor de la migración: os-migrate al rescate
La colección de Ansible os_migrate.os_migrate es, sin duda, la herramienta reina para este jale. En lugar de intentar programar llamadas directas a las APIs de OpenStack y batallar con inconsistencias, os-migrate trabaja bajo el paradigma de Infraestructura como Código (IaC) en un flujo de tres pasos sumamente limpio:
- Exportar (Get): Extrae la configuración del entorno origen (sea una nube OpenStack previa como RHOSP 16.2 o metadatos intermedios de VMware) y los escribe en archivos YAML declarativos.
- Saneamiento (Fix): Modificas los archivos YAML en disco para ajustar nombres de red, corregir MTUs lógicas o sanitizar metadatos obsoletos.
- Importar (Set): Inyectas los archivos YAML en la nube destino para recrear los recursos de forma idéntica.
Arquitectura de control y conversión: Copia bit-a-bit
Para mover los bloques físicos de los discos (los volúmenes de Cinder o archivos de VMDK convertidos a QCOW2) de una nube a otra, os-migrate no pasa los datos a través de la máquina del administrador. Eso sería lentísimo y saturaría tu enlace de red.
En su lugar, el proceso que diseñé implementa una arquitectura híbrida sumamente chingona (ahí usté dispensará la falta de sencillez):
+---------------------------------------+
| Nodo de Control |
| (Ansible Engine) |
+---------------------------------------+
| |
| (Orquesta vía APIs) | (Orquesta vía APIs)
v v
+-------------------+ +-------------------+
| Nube Origen | | Nube Destino |
| (RHOSP 16.2) | | (RHOSO 18) |
| | | |
| [VM de Origen] | | [VM de Destino] |
| | | | ^ |
| v | | | |
| +---------------+ | | +---------------+ |
| | Conv. Host |== SSH Tunnel (NBD)=>| Conv | |
| | (Source) | | | | (Destination) | |
| +---------------+ | | +---------------+ |
+-------------------+ +-------------------+
- Nodo de Control: Una máquina virtual (en mi caso, corriendo RHEL 9 con arranque UEFI) desde donde se lanzan los playbooks maestros de Ansible. Debe tener conectividad de red con las APIs públicas y de administración de ambos clusters de OpenStack.
- Nodos de Conversión (Conversion Hosts): Son instancias ligeras temporales (corriendo CentOS Stream 9) que se levantan dinámicamente: una dentro de la nube de origen y otra en la nube de destino.
- Túnel Seguro de Datos: Cuando se activa la migración de un disco, el nodo de conversión origen monta el volumen de solo lectura, expone sus bloques usando nbdkit y los transmite bit-a-bit a través de un túnel SSH cifrado directo hacia el nodo de conversión destino, que escribe los bloques directamente en el nuevo volumen. ¡Rápido, seguro y sin intermediarios!
El jale automatizado: Orquestación con Ansible y GNUmakefile
Para evitar que los operadores tengan que memorizar comandos kilométricos de Ansible y cometer errores humanos, centralicé todo el flujo operativo en un GNUmakefile que simplifica la vida.
Ahí te va el cotorreo de cómo estructuré los comandos del orquestador:
# GNUmakefile
# Automatización del ciclo de vida de migración masiva
BASEDIR=$(CURDIR)
PY=$(BASEDIR)/venv/bin/python3
ANSIBLE=$(BASEDIR)/venv/bin/ansible-playbook
# Importación del baseline global de la nube (Flavors, Imágenes, Proyectos, Usuarios)
globals:
$(ANSIBLE) -i hosts.yaml import_globals.yaml -e @vars.yaml
# Desplegar los nodos de conversión específicos para un tenant
conv-deploy:
$(ANSIBLE) -i hosts.yaml deploy_conv_hosts.yaml -e project_name=$(PROJECT) -e @vars.yaml
# Orquestar la migración completa del tenant (Export -> Saneamiento -> Import)
migrate:
$(ANSIBLE) -i hosts.yaml migrate_project.yaml -e project_name=$(PROJECT) -e @vars.yaml
# Eliminar los nodos de conversión una vez terminado el proceso
conv-delete:
$(ANSIBLE) -i hosts.yaml delete_conv_hosts.yaml -e project_name=$(PROJECT) -e @vars.yaml
Con esta estructura, migrar un tenant de pruebas se reduce a ejecutar de volón:
make conv-deploy PROJECT=pruebas
make migrate PROJECT=pruebas
make conv-delete PROJECT=pruebas
Control quirúrgico, sanitización y rollback sin sustos
Durante mi diseño de este flujo para proyectos de gran escala, me topé con varios retos reales del mundo de la producción que logramos resolver de forma elegante:
Control Quirúrgico con Etiquetas (Tags)
A veces no quieres migrar todo el proyecto de un jalón; tal vez solo quieres recrear las redes para que los ingenieros de infraestructura las validen, o solo migrar un grupo de instancias específico.
Para lograr esta granularidad, implementé etiquetas de Ansible estructuradas en el playbook maestro migrate_project.yaml. Así, puedes realizar importaciones quirúrgicas seguras:
# Migrar únicamente la topología de red (networks, subnets y routers)
ansible-playbook -i hosts.yaml migrate_project.yaml -e project_name=pruebas -e @vars.yaml --tags networks,subnets,routers
# Migrar únicamente las instancias (workloads) asumiendo que la red ya está lista
ansible-playbook -i hosts.yaml migrate_project.yaml -e project_name=pruebas -e @vars.yaml --tags workloads
Sanitización y Parchado Automáticos
Mover datos entre nubes de diferentes generaciones (como de OpenStack 16.2 a 18.0) expone discrepancias en las APIs. Por ejemplo, ciertas propiedades del catálogo de Glance o metadatos de almacenamiento de Nova (volume_image_metadata) ya no son válidos o bloquean la importación en el destino.
Para resolver esto sin intervención humana constante, integré scripts de saneamiento automático escritos en Python y Bash (como sanitize_workloads.py y sanitize_subnets.py) que se ejecutan automáticamente en la fase de parchado del playbook maestro, ajustando los metadatos YAML al vuelo antes de inyectarlos en la nueva API.
Estrategia de Rollback y Seguridad
La regla número uno del administrador de sistemas es: "no destruirás el entorno origen hasta que el destino esté cantando victoria".
Por lo tanto, mi arquitectura de migración sigue una política estricta de seguridad:
- El playbook maestro apaga automáticamente la instancia en origen (mediante la variable os_migrate_workload_stop_before_migration: true) para congelar el estado del disco y garantizar consistencia de bloques durante la copia NBD.
- El volumen de origen se trata de estricto solo lectura.
- La máquina virtual en origen NUNCA se elimina del cluster original.
- Si la validación en la nueva nube falla por cualquier desalineación de la red física o de la aplicación, el rollback es inmediato y sin sustos: solo apagas la VM en el destino (RHOSO 18) y vuelves a encender la original en el origen (RHOSP 16.2). ¡Cero pérdida de datos!
La hora de la hora: ¿Te animas a migrar?
Migrar la infraestructura de tu organización de VMware a OpenStack (o saltar de versiones clásicas a las nuevas arquitecturas hiper-modernas basadas en OpenShift) no tiene por qué ser un dolor de cabeza ni un salto al vacío. Con una planeación arquitectónica sólida, automatización inteligente basada en Ansible, y el uso correcto de herramientas como os-migrate, puedes convertir un desmadre caótico en un proceso predecible, seguro y repetible.
Si andas batallando con el costo de las licencias de VMware, quieres planificar una migración robusta o simplemente te interesa platicar sobre cómo automatizar este tipo de locuras en tu infraestructura, búscame y échame un grito... ¡con gusto te hago el paro! 😉
Mi sitio de servicios profesionales: https://evalinux.com/
Mi correo: renich en evalinux punto com.
) (There’s quite a bit more, but I think that sort of covers it. 
You went above and beyond - Fedora Project would not be the same without you!
You attended the Fedora Mentor Summit 2026
Poland. The Session is one of the oldest and biggest FLOSS-focused conferences in Poland. The event was organized by 
”
You went above and beyond - Fedora Project would not be the same without you!
comments? additions? reactions?
As always, comment on the fediverse: https://fosstodon.org/@nirik/116630715953443762