Desde que Broadcom compró VMware, la conversación en cada sala de infraestructura cambió de tono. Ya casi nadie pregunta “¿deberíamos evaluar alternativas?”. La pregunta ahora es “¿cuándo salimos, y cómo lo hacemos sin romper nada?”. Renovaciones que se multiplicaron, licenciamiento por core, bundles que obligan a pagar por lo que no usas. El empujón para mirar hacia Proxmox, oVirt o HPE VM Essentials ya no es técnico, es de sobrevivencia del presupuesto.
Y ahí es donde el entusiasmo se choca con la realidad: migrar cientos o miles de máquinas virtuales desde producción es un proyecto de meses. Ventanas de mantenimiento negociadas a pulso, agentes de conversión corriendo sobre VMs vivas, riesgo real sobre el ambiente que le da de comer al negocio. La salida de VMware, planteada así, asusta tanto como quedarse.
Este post es sobre otra forma de plantearla. Es largo a propósito: empieza por el “por qué” y termina en la cocina técnica (helpers, RBAC, puertos, seguridad), para que puedas decidir con criterio y no con un folleto.
La pregunta que casi nadie hace#
Casi todos los proyectos de migración arrancan por el lugar más caro y más frágil: producción. Te conectas al vCenter, tomas la VM viva, la conviertes, rezas para que el arranque en el destino salga bien. Repites por cada workload. Cada iteración toca el ambiente productivo, y cada toque es un riesgo que alguien tiene que firmar.
Pero hay un dato que ya tienes y que casi nadie usa como palanca de migración: de cada una de esas VMs existe una copia consistente, verificada y del lado seguro de la infraestructura. Se llama respaldo. Si ya invertiste en Veeam, ya tienes, hoy mismo, una imagen de arranque de cada máquina que quieres mover. La pregunta que casi nadie hace es: ¿y si migro desde ahí, en lugar de desde producción?
Esa es exactamente la idea detrás de Moov.
Qué es Moov, y qué nunca toca#
Moov es un appliance virtual que migra máquinas virtuales respaldadas por Veeam Backup & Replication V13 hacia hipervisores KVM: Proxmox VE, oVirt (incluye OLVM y RHV) y HPE VM Essentials (basado en Morpheus). Su fuente de datos es siempre el repositorio de Veeam. Lee los puntos de restore en modo solo lectura, a través de la API REST y la Data Integration API, y nunca los modifica.
Lo importante es lo que no hace. Moov no se conecta a vCenter ni a la vSphere API, no habla con los hosts ESXi, no toca tus datastores VMFS o NFS, y no toca las VMs que están corriendo en VMware. Tu producción ni se entera de que hay una migración en curso.
Las implicaciones de ese límite son las que cambian el juego. Cero impacto en producción durante la migración. Puedes migrar VMs que ya están apagadas, o incluso dadas de baja, mientras exista un backup. Y tus ventanas de migración quedan totalmente independientes del mantenimiento de vSphere. Ya no negocias con el dueño de producción, negocias con tu propio repositorio.
Toda la operación vive en una sola consola web. El Dashboard es el centro de control: estado global de Veeam, destinos, helpers y el propio Core, resultados de las últimas migraciones, capacidad por destino y lo que requiere atención. No hay cliente de escritorio ni archivos de configuración que editar a mano.
Dos formas de migrar, según lo que necesites#
Moov ofrece dos modos, y la diferencia entre ellos es, básicamente, cuánto puedes esperar.
Instant VM Migration es para cuando necesitas volver a operar ya. La VM arranca de inmediato en el destino, leyendo del respaldo por iSCSI/NBD, mientras sus discos migran en segundo plano. Cuando el mirror termina, Moov hace un pivot y la VM queda corriendo al 100 % en el almacenamiento local del destino. El RTO que muestra la consola es de 60 segundos o menos. Es el modo natural para un cutover con validación en caliente, o para un escenario de recuperación donde el tiempo manda.
Cold Migration es para cuando prefieres certeza antes que velocidad. El helper restaura y convierte los discos por completo, los transfiere al hipervisor, arma la VM y la verifica, todo antes de encenderla. Toma entre 15 y 60 minutos según el tamaño, y es ideal para archivado, pruebas o cuando quieres la materialización completa en mano antes de dar el arranque.
En los dos modos la VM llega lista para operar. La instalación del agente (QGA) y la inyección de drivers VirtIO vienen activadas por defecto, y el bus de disco se elige por una política de evidencia: virtio-scsi cuando hay drivers confirmados, SATA como arranque universal cuando el sistema operativo es desconocido o falta evidencia. No hay pasos manuales de post-migración para que la máquina bootee y hable con la red.
Cómo se ve en la práctica#
Antes de comprometer una sola ventana de migración, Moov te deja mirar. El Preflight Inspector recorre los repositorios de Veeam, cruza cada VM contra un destino concreto y la clasifica en un bucket: verde (automático, candidata sin reservas), ámbar (advertencia, avisos blandos como un backup de más de 7 días o storage del destino sobre el 85 % de uso), rojo (manual, requiere intervención) o gris (inconcluso, faltan datos que solo un helper puede medir). Todo esto sin tocar el backup: es solo lectura sobre el origen.
Si quieres ir más profundo, el análisis de discos monta los discos del backup en un helper, en modo solo lectura, e inspecciona el guest real: CPU, RAM, NICs, familia de sistema operativo y evidencia de drivers VirtIO. El punto clave es que la VM nunca se enciende. Todo se extrae leyendo el contenido del respaldo montado, sin bootear el guest ni tocar producción. Con esos datos, el inspector recalcula el bucket y precarga los valores del placement de la migración.
Con el inventario claro, lanzas una migración con un asistente de tres pasos: eliges origen y VMs, eliges destino y modo, y ajustas la ubicación por VM (nombre, cómputo, storage y redes). Puedes guardar la selección como draft para planificar migraciones masivas o por olas, y ejecutarlas después sin la presión de la ventana.
Y una vez que le das arrancar, no quedas a ciegas. El seguimiento en vivo muestra, por cada VM, la cadena de fases y un registro de eventos con lo que está pasando de verdad.
Lo que pasa por dentro#
Entremos en detalle, porque es donde se ve por qué esto no toca producción. Una Instant Migration recorre diez pasos visibles, de T1 a T10: validar helper, publicar el respaldo por iSCSI, esperar el mount, conectar el iSCSI, despachar al helper, esperar el NBD, drive-mirror, progreso, pivot y finalizar.
En el detalle: Moov publica el punto de restore de Veeam por iSCSI, usando la Data Integration API. El helper conecta esos discos del backup, prepara el guest y expone cada disco como export NBD. La preparación del invitado es la parte elegante: detecta el sistema operativo, inyecta los drivers VirtIO, instala el agente, repara el arranque (BCD en Windows, initramfs en Linux vía dracut/initramfs-tools con chroot sobre un overlay escribible, dejando el disco de origen en solo lectura), siembra el arranque UEFI (ESP) y optimiza los discos con sparsify para descartar bloques en cero. Todo eso sin un appliance auxiliar: no necesita virtualización anidada (KVM) dentro del helper ni un appliance de conversión anidado por trabajo, editando offline sobre un overlay que nunca modifica el backup original.
Con los discos expuestos, la VM arranca desde NBD, degradada hasta el pivot, y puedes validar el guest de inmediato. En paralelo, el drive mirror materializa los bloques al storage del destino, con progreso por disco. Cuando el mirror termina, viene el pivot y la VM queda corriendo en almacenamiento local. Al final, Moov des-publica el backup en Veeam y limpia el helper.
Un detalle de arquitectura que importa: el flujo pesado de discos va directo del helper al hipervisor destino, no pasa por el core. Por eso se escala sumando helpers, y un mismo helper migra varias VMs en paralelo dentro de una ola.
El appliance por dentro: Primary, Helpers y una consola sin SSH#
Moov se distribuye como una única imagen (qcow2, ova, vhdx o raw), y el rol se elige en el primer arranque. Hay dos:
- Primary: el controlador. Sirve la consola web y la API, guarda el estado en una base SQLite embebida, emite los certificados de su propia CA local y coordina cada migración. Hay exactamente un Primary por flota. Trae además un helper local, suficiente para empezar.
- Helper: ejecuta trabajos despachados por el Primary. Tantos como necesites.
El primer arranque no pide editar archivos: la tty1 muestra moov-firstboot, un asistente de texto (TUI) de seis pasos: rol, red (DHCP o estática), hostname/FQDN, zona horaria y NTP, cuenta de administrador (en el Primary) y una pantalla de review antes de aplicar. Al confirmar, el Primary hace el bootstrap del Core: genera la CA local, la base, la master key y la cuenta admin.
La pantalla final muestra, una sola vez, la URL de la consola, el email admin, la contraseña (si pediste auto-generarla), la huella de la CA y un código de recuperación. Ese código merece un párrafo aparte.
El código de recuperación es la master key legible. Moov cifra todas las credenciales de los backends (Veeam, Proxmox, oVirt, Morpheus, SMTP) en la base con AES-256-GCM. El código de recuperación es esa misma master key codificada en Base32-Crockford. Si el appliance se pierde o se corrompe, sin ese código las credenciales son irrecuperables por diseño y hay que recrear cada conexión. Guárdalo fuera del appliance: gestor de contraseñas, bóveda de secretos o un sobre sellado.
Después del primer arranque, la tty1 no vuelve a una shell simple: queda en moov-info, una consola de estado pensada para operarse desde la consola del hipervisor, sin necesidad de SSH. Muestra servicios, uso de CPU/RAM, red, accesos, helpers y destinos, y permite ver logs, abrir una shell local protegida por contraseña, reiniciar o apagar (con confirmación en dos pasos). Fíjate en el detalle de la captura: ssh aparece detenido. No es un olvido, es el modelo.
Y no solo el Primary tiene consola: cada helper trae su propia TUI en la pantalla del hipervisor, donde ves su estado, su registro contra el Core y los trabajos que tiene en curso. La misma filosofía de operar desde el hipervisor, sin abrir SSH.
Helpers: así se paraleliza una migración masiva#
Un helper es un appliance Linux que hace el trabajo de bajo nivel de cada migración: se conecta por iSCSI al respaldo publicado por Veeam, convierte discos (virt-v2v, qemu-img), prepara el guest y expone los discos por NBD para que el hipervisor destino los consuma directo. Es stateless: no expone consola ni guarda secretos persistentes más allá de su certificado mTLS. Todo el estado vive en el Core; si el helper reinicia, se re-registra solo.
Cada helper habla con el Core por gRPC con mTLS y envía heartbeats continuos. Si pasan unos 30 segundos sin pulso, el Core lo marca Stale y deja de asignarle trabajos. En la consola los ves como Activo, Stale, Pausado, Desplegando, Inalcanzable o Actualizable, así que sabes en todo momento a quién le puede tocar trabajo.
El despliegue es de un solo paso y auto-aprovisionado vía la API del hipervisor destino, en los tres destinos, todos descargan directamente desde el primary, el appliance (qcow2) del helper que contiene todos los ejecutables para realizar las migraciones.
El dimensionamiento por defecto de un helper auto-desplegado es 8 vCPU / 16 GB de RAM / 50 GB de disco, igual en los tres hipervisores. No es un número al azar: qemu-img, virt-v2v y sparsify trabajan sobre discos completos y son intensivos en memoria, y estos valores evitan que las conversiones se alarguen o que aparezca un OOM en discos grandes. Al editar un helper, Moov valida contra el nodo real: rechaza asignar más vCPU o RAM que las del nodo, y advierte si pides más del 90 %.
El paralelismo tiene dos ejes. Uno, un mismo helper migra varias VMs en paralelo dentro de una ola: el reparto es 1:1 por recursos, aproximadamente 1 vCPU y 2 GiB de RAM por VM, así que un helper con los 8 vCPU / 16 GB por defecto corre alrededor de 8 VMs a la vez. Dos, sumas helpers y el trabajo se distribuye sobre toda la flota: el preflight y la migración reparten las VMs entre los helpers disponibles, y la capacidad global es la suma de todos. La concurrencia por conexión de Veeam es configurable, con la cantidad de tareas por repositorio visible en la consola, y la migración automática prefiere los helpers que ya están en el hipervisor de destino. Para acercar el cómputo al repositorio o al destino, despliega helpers donde los necesites; para Instant VM Migration la regla de diseño es latencia helper a hipervisor menor a 5 ms. La buena práctica mínima: mantén al menos un helper Activo por destino antes de lanzar, porque el paso 1 de toda migración valida el helper y falla si está Stale o pausado.
Quién puede hacer qué: roles y RBAC#
Las cuentas de operadores son locales al appliance (contraseña con hash bcrypt, sesiones con JWT), y cada usuario se mapea a uno de tres roles:
- Admin: todo. Usuarios, conexiones, credenciales, ajustes, backup, notificaciones, diagnóstico, y el borrado definitivo de scans, migraciones y helpers.
- Operador: lanza, cancela y reintenta migraciones, corre preflight y análisis, opera helpers y ve las conexiones en solo lectura. No edita credenciales ni ajustes.
- Auditor: solo lectura de reportes y del registro de auditoría. No opera. Existe precisamente para clientes regulados que necesitan separación de funciones.
El detalle que importa para una auditoría de seguridad: la matriz la aplica el servidor en cada API, no solo la interfaz. Un rol sin permiso recibe “permiso denegado” aunque arme la petición a mano. Y hay protecciones integradas: no puedes degradar ni borrar al último Admin, ni eliminar tu propia cuenta.
Puertos, red y modelo SSH#
Para el equipo de red, esta es la parte que se lleva al firewall. Los puertos del appliance Primary (Core):
| Puerto | Protocolo | Uso |
|---|---|---|
| 9093 | HTTPS (TLS, CA local) | Consola web + API REST + registro de helpers |
| 9094 | HTTPS | Aprovisionamiento de helpers (binario, CA, cert) |
| 9091 | gRPC con mTLS | Eventos y heartbeats de helpers hacia el Core |
| 80 / 443 | HTTP/HTTPS | Redirección 301 hacia la consola en :9093 |
Los helpers escuchan en 9091 (canal de control desde el Core) y en 10809+ (un puerto NBD por disco, dinámico, del que el hipervisor destino hace pull directo). Y estos son los puertos externos que consume Moov:
| Destino | Puerto | Uso |
|---|---|---|
| Veeam B&R V13 | 9419 | API REST (OAuth2) + Data Integration API |
| Mount server Veeam → helper | 3260 (iSCSI) | Discos del punto de restore hacia el helper |
| Proxmox VE | 8006 | API REST |
| oVirt engine | 443 | API REST |
| Morpheus / HPE VME | 443 | API REST |
| Nodos/hosts destino | 22 (SSH) | Llave de Core: IVMR (QMP/virsh, drive-mirror, NBD pull) |
| SMTP | 25 / 465 / 587 | Notificaciones por correo |
Sobre el acceso a los hosts destino, el modelo es basado en llave, no en contraseña. Moov genera y gestiona su propia keypair (ed25519) en el primer arranque; no le subes tu clave. La contraseña SSH del host se usa una sola vez, desde la consola, para instalar la pubkey de Moov en authorized_keys, y nunca se persiste. De ahí en adelante todo va por la clave privada de Core, sin contraseña. La verificación anti-MITM usa pinning de host-key (TOFU en la primera conexión, verificación en las siguientes): un cambio de host-key aborta la conexión hasta re-pinear desde la consola. Y como ya viste, el SSH entrante al appliance está deshabilitado: la administración es solo web más la TUI de consola.
Seguridad y gobernanza#
Migrar desde el respaldo tiene un beneficio de seguridad que no siempre se nota a primera vista: el origen es sagrado. Los puntos de restore nunca se modifican, en ningún modo. Pero el resto del appliance también está pensado con esa mentalidad.
- Credenciales cifradas. Veeam, hipervisores y SMTP se guardan cifrados en reposo con AES-256-GCM. La master key se muestra una sola vez (el código de recuperación) y se guarda fuera de línea.
- TLS y mTLS. La consola sirve sobre TLS con una CA local propia; la comunicación entre el Core y los helpers es mTLS. La CA se puede instalar en tu almacén de confianza desde una página guiada por sistema operativo.
- Sesiones endurecidas. Token de acceso de 15 minutos en memoria, refresh token en cookie
HttpOnly/Secure/SameSite=Strictcon protección CSRF. El refresh rota de forma atómica en cada renovación y, si se detecta reuso de un token ya consumido, Moov revoca toda la familia de sesiones (RFC 6819). La casilla “Confiar en este dispositivo por 14 días” extiende la ventana sin reintroducir la contraseña, y queda auditada. - Auditoría append-only. Cada acción queda en un registro que solo agrega, visible para Admin y Auditor.
- Anti-SSRF. La ingesta de imágenes (helper, plantillas) no sigue redirecciones, para evitar accesos no deseados a recursos internos.
- Diagnóstico sin filtrar secretos. El paquete de soporte incluye logs, config y auditoría reciente, pero redacta automáticamente contraseñas, tokens, hashes bcrypt, JWTs y bloques PEM de claves privadas.
Nada de esto es glamoroso, pero es exactamente lo que quieres cuando la herramienta va a tocar tus respaldos y a crear cargas en tu nuevo hipervisor. Y las notificaciones por correo (SMTP con STARTTLS o TLS implícito) te avisan de migraciones completadas o fallidas, helpers que dejaron de responder y análisis de preflight terminados, sin tener que vivir mirando la consola.
Preguntas frecuentes#
¿Moov modifica mis respaldos de Veeam?
No. Moov lee los puntos de restore en modo solo lectura, a través de la API REST de Veeam, y nunca los modifica. El respaldo de origen es siempre de solo lectura, en cualquier modo de migración.
¿Necesito tocar o apagar mis VMs de VMware para migrar?
No. Moov nunca se conecta a vCenter ni a los hosts ESXi: migra desde el respaldo de Veeam, así que tu producción ni se entera. Incluso puedes migrar VMs que ya están apagadas o dadas de baja, mientras exista un backup.
¿A qué hipervisores puede migrar Moov?
A Proxmox VE, oVirt (incluye OLVM y RHV) y HPE VM Essentials (basado en Morpheus).
¿Cuál es la diferencia entre Instant VM Migration y Cold Migration?
Instant VM Migration arranca la VM en el destino en segundos desde el respaldo (RTO de 60 segundos o menos) y migra los discos en segundo plano hasta hacer el pivot. Cold Migration restaura y verifica los discos por completo antes de encender la VM, y toma entre 15 y 60 minutos.
¿Cómo escala Moov para migrar muchas VMs a la vez?
Con helpers: cada helper corre varias VMs en paralelo (aproximadamente 1 vCPU y 2 GiB de RAM por VM) y sumas helpers para repartir el trabajo sobre toda la flota. La capacidad global es la suma de todos.
¿Dónde descargo Moov?
En VeeamHub, en github.com/VeeamHub/moov, en beta pública.
Pruébalo#
Moov está en beta pública (v1.0.37) y ya lo puedes descargar. Lo publiqué en VeeamHub, el lugar de proyectos community de Veeam en GitHub, con las imágenes del appliance listas para bajar. Como todo proyecto de VeeamHub, es community: se entrega tal cual, sin soporte oficial de Veeam.
Si estás en medio de la conversación de salir de VMware, o si simplemente quieres ver cómo se siente migrar una VM desde un backup en lugar de desde producción, es un buen momento para tomarlo y probarlo con una máquina de laboratorio. Despliega el appliance, completa el TUI, conecta tu Veeam, agrega un destino, despliega un helper y lanza una Instant Migration: del appliance recién importado a una VM arrancada, en minutos.
Descárgalo y empieza aquí: github.com/VeeamHub/moov
Y si lo pruebas, cuéntame cómo te fue. La idea de usar el respaldo como palanca de migración, y no solo como red de seguridad, es de esas que cambian cómo piensas toda la operación. Salir de VMware no tiene por qué empezar por el lugar más riesgoso. Puede empezar por el más seguro que ya tienes.
