Migración masiva de máquinas virtuales a Proxmox, KVM y HPE VM Essentials usando respaldos de Veeam.

Moov migra máquinas virtuales desde los puntos de restauración de Veeam Backup & Replication hacia Proxmox VE, oVirt / OLVM / RHV y HPE VM Essentials, sin tocar el entorno virtualizado de origen durante la migración.

Descargar el appliance

Ver cómo funciona

3
hipervisores de destino
≤ 60 s
de RTO con Instant Migration
0
conexiones al entorno de origen

Entorno de origen

fuera de alcance

Veeam Backup & Replication V13

origen: punto de restauración

Moov appliance

core + helpers descartables

customize · NBD · pivot

Proxmox VE8.x / 9.x
oVirt / OLVM4.5+
HPE VM EssentialsMorpheus 8.1.x · 9.0.x

Destinos soportados

Proxmox VE

8.x / 9.x

Soporte completo, incluyendo bootstrap automático del API token.

oVirt / OLVM / RHV

4.5+

Subida por REST + imageio; SSH/QMP para migración instantánea.

HPE VM Essentials

Morpheus 8.1.x · 9.0.x

Migración instantánea y en frío sobre nodos MVM.

Origen: API REST de Veeam Backup & Replication V13.

Cómo funciona

Un appliance Core más helpers descartables en el hipervisor de destino.

El origen de cada VM es Veeam: metadatos por REST o el disco publicado del respaldo. Moov nunca se conecta a vCenter ni a ESXi.

01
Pre-flight Inspector
Escanea los respaldos de Veeam, clasifica cada VM (SO, discos, preparación VirtIO) y estima la capacidad necesaria.
02
Planificación de la ola
El operador arma una ola en la consola web y elige host de destino y modo de migración por VM.
03
Publicación y despacho
El Core publica el punto de restauración desde Veeam y despacha el trabajo a un helper, que sirve el disco por NBD y conduce la conversión o el arranque.
04
Arranque y pivot
El progreso se transmite en vivo a la consola; la VM arranca, el agente invitado responde y, en migración instantánea, el disco pivotea al almacenamiento local.

Entorno de origen

fuera de alcance

Veeam Backup & Replication V13

Backup repository · VBK / VIB

SOURCE

Moov Appliance

moov-core: web console · REST API (:9093)

orchestrator · embedded SQLite · local CA · mTLS

moov-helper: local helper

PRIMARY

Operador

navegador web

HTTPS :9093

mTLS · gRPC

Helpers adicionales

HELPER

Misma imagen del appliance

Escalado horizontal de la migración

REST / SSH / libvirt

Destinos de migración

Proxmox VE
oVirt / OLVM / RHV
HPE VM Essentials

Flujo de datos activoGestión / consolaFuera de alcance

Arquitectura: origen Veeam, appliance Moov (core + helper local), helpers adicionales y destinos de migración.

Modos de migración

Dos modos, según cuánto downtime tolera cada VM.

IVMR

Instant VM Migration

RTO · ≤ 60 s hasta el arranque

Para VMs críticas. La VM arranca de inmediato en el destino desde el backup (iSCSI/NBD) mientras sus discos migran en segundo plano. Al terminar el espejo, el pivot la deja corriendo solo sobre el almacenamiento del destino.

Cold

Cold Migration

RTO · 15 a 60 min por VM

Copia los discos al destino y deja la VM creada y apagada, para encenderla en su propia ventana. Sin dependencia del backup en tiempo de arranque.

Wave Engine

Los dos modos corren a través del Wave Engine, que agenda muchas VMs en paralelo con límites de capacidad por helper derivados del CPU y la RAM del host: aprox. 1 vCPU y 2 GiB por VM, y la capacidad global es la suma de la flota.

Sin dependencia de vSphere

El origen de cada VM es Veeam. Moov nunca se conecta a vCenter ni a ESXi.

Drivers incluidos

Los VirtIO se preparan automáticamente para invitados Linux y Windows, incluido Windows moderno con drivers inbox.

Red preservada

Las IPs estáticas y las configuraciones multi-NIC se trasladan a la VM migrada, o se reasignan por NIC desde la consola.

Corre como appliance

Imagen autocontenida con asistente de primer arranque y consola web. Sin proveedor de identidad ni base de datos externa.

Preparación de VMs

La Máquina Virtual queda lista para KVM antes de arrancar.

La etapa de customize corre offline sobre el disco montado, sin appliance auxiliar ni KVM en el helper, y adapta el sistema operativo invitado para que bootee y opere en el destino.

customize · virt-v2v in-place

Inyección de drivers VirtIO
vioscsi / viostor se instalan durante la preparación, en Windows y Linux. La inyección crea la evidencia VirtIO que habilita el bus virtio-scsi.
Dirección IP preservada
Las IPs estáticas se aplican a todas las interfaces según la ranura PCI de cada NIC (multi-NIC en Windows y Linux), o se reasignan por NIC desde la consola.
Desinstalación de VMware Tools
Las VMware Tools de vSphere se desinstalan para que no compitan con los drivers y el agente de KVM.
QEMU Guest Agent
El QGA se prepara durante el customize; su respuesta a ping confirma que la VM migrada está viva y permite consultar IP, fsfreeze y ejecución de comandos.
Bus de disco virtio-scsi
Controlador paravirtualizado por defecto cuando hay evidencia de soporte VirtIO en el invitado, con mejor rendimiento que SATA/IDE.
Reparación de arranque
BCD fixup en Windows y siembra o reparación de la partición ESP cuando el invitado bootea por UEFI.
Optimización sparsify
Los bloques vacíos o en cero se descartan durante la conversión, reduciendo tamaño y tiempo de transferencia.
Agente del destino
En HPE VM Essentials el agente de Morpheus se instala post-pivot vía guest-exec del QEMU Guest Agent.

Inicio rápido

De appliance desplegado a múltiples VMs corriendo en ~20 minutos.

Recorrido mínimo de extremo a extremo. Requisito previo: el appliance importado y encendido, con red al servidor Veeam y al hipervisor destino.

Descargar el appliance

01
Primer arranque y login
Completa el asistente de texto (rol Primary, red, hostname, hora, cuenta de administrador). Anota la huella de la CA y el código de recuperación.
02
Conectar Veeam
En Conexiones → Veeam, agrega tu servidor Veeam B&R V13 y prueba la conexión hasta ver estado correcto.
03
Agregar un destino
En Conexiones → Destinos, agrega Proxmox VE, oVirt o HPE VM Essentials. El asistente hace el bootstrap automático de credenciales.
04
Desplegar un helper
Elige el destino y acepta los valores por defecto (8 vCPU / 16 GB / 50 GB). El helper se registra por mTLS y queda Activo.
05
Preflight de 1 VM
Escanea el catálogo de Veeam, elige una VM y ejecuta el análisis de discos y hardware. Confirma que cae en el bucket Automático.
06
Lanzar 1 Instant Migration
Asistente de 3 pasos: origen y VM, destino y modo, ubicación (nodo, almacenamiento, red). La VM arranca de inmediato desde el backup.
07
Verificar la VM arrancada
Sigue el progreso en vivo: timeline por VM, progreso por disco y registro de eventos. Al terminar el pivot, la VM corre 100 % en el destino.

La consola

Todo el flujo desde una consola web.

Dashboard: estado global, resultados de las últimas migraciones y capacidad por destino.

Migración en vivo: progreso por disco y registro de eventos.

Preflight: inventario del catálogo Veeam y clasificación por VM.

Conexiones: Veeam, destinos y helpers con bootstrap automático.

Seguridad

Credenciales cifradas, mTLS entre componentes, sin IdP externo.

Autenticación local
Contraseñas con hash bcrypt, sesiones con JWT firmado y control de acceso por rol. No requiere proveedor de identidad externo.
Credenciales cifradas
Credenciales cifradas con AES-256-GCM. La clave maestra se muestra una única vez al arrancar como código de recuperación: ese código es la clave, así que debe guardarse con el mismo cuidado.
Helpers por mTLS
Los helpers se autentican contra el Core con TLS mutuo mediante tokens de registro de un solo uso.
Artefactos verificados
Imagen base, VirtIO y agentes invitados se verifican por checksum al descargarse.

Actualizaciones

El appliance se actualiza a sí mismo, y a su flota de helpers.

Desde la v1.0.38 la actualización se hace desde la consola: el appliance verifica, aplica y, si algo sale mal, vuelve solo a la versión anterior. No hay que reinstalar ni recrear los helpers, pero sí actualizarlos desde la misma consola: un helper de la versión anterior se sigue aceptando, y por eso es fácil olvidarlo.

Bundles firmados
Cada actualización viene firmada con Ed25519 y con SHA-256 por archivo. El límite privilegiado revalida firma y hashes antes de aplicar nada.
Dos canales
Binarios de Moov y parches del sistema operativo se actualizan por separado, cada uno con su propio estado en la consola.
Rollback automático
Si el Core nuevo no arranca sano, el appliance revierte solo a la versión anterior sin intervención del operador.
Flota al día
El appliance espeja el archivo Debian para sus helpers y permite reiniciar hosts desde la misma tabla. Core y helpers deben quedar en la misma versión.

Releases

Qué cambió en las últimas versiones.

v1.0.40Última

Redes separadas y oVirt con varios datacenters

Reemplaza a la v1.0.39. Separa la red de gestión del appliance de la red de los hipervisores, trabaja con managers de oVirt y OLVM que tienen varios datacenters, conserva el orden de discos de cada VM y deja elegir el formato de disco por destino. Las migraciones a HPE VM Essentials quedan más confiables.

Redes de gestión e infraestructura separadas. Cada interfaz del appliance recibe un rol: gestión (consola web, SSH, actualizaciones) o infraestructura (hipervisores, helpers, Veeam). Cada rol lleva su propio enrutamiento, dirección de origen y reglas de entrada, y la de infraestructura puede tener gateway y DNS propios. Todo cambio se aplica con reversión automática si no lo confirmas.
oVirt y OLVM con varios datacenters. Moov usa el SPM, los dominios de almacenamiento y las redes que pertenecen al host que elijas. La colocación muestra el datacenter y el cluster de cada host, el asistente de helpers filtra por cluster, y una colocación que mezcle datacenters se detiene antes de publicar nada.
Se conserva el orden de discos del origen. En Proxmox, oVirt y HPE VM Essentials, tanto en Instant como en Cold.
Formato de disco por destino. El formato y el tamaño de cluster de qcow2 se fijan en los valores por defecto de migración de cada conexión.
HPE VM Essentials más confiable. Moov espera a que el manager registre el último disco antes de reportar éxito y usa siempre el tipo de máquina q35. Las VMs con UEFI siguen arrancando después de un redimensionado, los datastores no soportados se rechazan con un error claro y las migraciones sobre Ceph RBD avisan.
IP estática en interfaces adicionales del helper. Las interfaces que se agregan a un helper ya no dependen de DHCP.
Reportes sin el tope de 50 filas. Con filtrado en el servidor y exportación. Las migraciones en espera dicen por qué esperan, y el paquete de soporte incluye el registro de llamadas a la API.
Más de 35 correcciones de validación. Invitados Linux con partición /var separada, dos migraciones Linux en el mismo helper sin colisionar, y Veeam autorizando todas las direcciones del helper para iSCSI.

v1.0.39Anterior

Verificación de arranque y correcciones de campo

Reemplaza a la v1.0.38. Release correctivo: tres rondas de defectos reportados en campo, más las adiciones operativas que varios de ellos exigieron. Varias correcciones corren en el helper y no en el appliance, y la puerta de versión no se movió: un helper 1.0.38 se sigue aceptando, pero no las lleva. Después de actualizar el appliance, entra a Connections › Helpers › Update all.

Verificación de arranque tras migrar. La ola ya no se pone verde solo porque los discos se copiaron: enciende la VM y espera al guest agent, con tres veredictos (verificado, no concluyente o fallido). Funciona en los tres hipervisores.
Windows desde la consola que no arrancaba. El defecto más serio corregido aquí. El asistente no le decía al helper qué tipo de invitado enviaba, así que se saltaba toda la preparación de Windows y la ola igual reportaba éxito. Si migraste un Windows desde la consola en la 1.0.38 y no arrancó, es esto.
Cold en LVM, ZFS y Ceph. Cold creaba el disco de destino con tamaño cero y confiaba en que qemu-img lo hiciera crecer, algo que solo funciona en almacenamiento por archivos. Ahora cada disco de origen se mide antes de crear la VM y el volumen se reserva a su tamaño real.
Colocación por disco. Cada disco de una VM puede ir a su propio almacenamiento, en Instant y en Cold, y un disco de datos se puede dejar fuera de la migración. El disco de arranque no.
Helpers multi-NIC con rol. Interfaces adicionales en los tres hipervisores, cada una con rol de gestión o de datos. La lista de direcciones iSCSI muestra el rol de cada una y elige la de datos por defecto.
VLAN y redes al migrar. Control de tag VLAN para destinos Proxmox y VNets de SDN ofrecidas como red. Pedido por mog54 en el issue público #12.
CPU model host por defecto. El default anterior dejaba sin arrancar a todo invitado RHEL o Rocky 10, cuya glibc exige x86-64-v3. El override por VM sigue disponible, y ahora Instant también lo respeta en lugar de descartarlo.
Puerta de capacidad antes de empezar. Suma el tamaño ocupado de los backups que van a cada almacenamiento y se niega a arrancar si no caben, nombrando almacenamiento, nodo y cifras. Si el backend no reporta métricas, no estorba.

Guías por destino

Cómo migrar VMware a cada hipervisor.

Requisitos previos, pasos concretos y límites conocidos de cada destino soportado.

Migración de VMware a Proxmox VE

Requisitos de Proxmox VE 8.x y 9.x, bootstrap del API token y elección de almacenamiento.

→

Migración de VMware a oVirt / OLVM

Subida por REST e imageio, acceso SSH/QMP y particularidades de oVirt 4.5 en adelante.

→

Migración de VMware a HPE VM Essentials

Nodos MVM, agente de Morpheus post-pivot y versiones 8.1.x y 9.0.x soportadas.

→

Preguntas frecuentes

¿Necesito acceso a vCenter o ESXi?

No. El origen de cada VM es Veeam, por metadatos REST o por el disco publicado del respaldo. Moov nunca se conecta al entorno vSphere.

¿Qué versión de Veeam requiere?

Veeam Backup & Replication V13, a través de su API REST y la Data Integration API para publicar los discos sin modificar el backup.

¿Qué licencia de Veeam necesito?

Moov funciona con Veeam Data Platform en sus ediciones Foundation, Advanced y Premium, bajo Veeam Universal License (VUL). Las licencias de evaluación y NFR también sirven, porque vienen con todas las funciones habilitadas. Veeam Backup & Replication Community Edition no está soportada.

¿Cuánto downtime tiene una VM crítica?

Con Instant VM Migration la VM arranca en el destino desde el respaldo (RTO indicado ≤ 60 s) y después pivotea al almacenamiento local sin ventana adicional.

¿Y los drivers de Windows?

Los VirtIO se inyectan automáticamente durante el customize, incluidas versiones modernas de Windows con drivers inbox y Windows Server 2025.

¿Cuántas VMs puedo migrar a la vez?

El Wave Engine agenda olas concurrentes; cada helper corre tantas VMs en paralelo como permiten su CPU y su RAM, y la capacidad global es la suma de la flota.

¿Bajo qué licencia se publica Moov?

Moov se publica bajo licencia MIT, en estado beta.