Moovv1.0.38
Moov

Migración de VMware a oVirt y OLVM

Moov migra máquinas virtuales a oVirt, a Oracle Linux Virtualization Manager (OLVM) y a Red Hat Virtualization tomando como origen los puntos de restauración de Veeam Backup & Replication V13. La subida de discos va por la API REST del manager junto con imageio, y la migración instantánea suma acceso SSH y QMP contra el host. En ningún momento se contacta a vCenter ni a ESXi.

VMware vSphere
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

Requisitos previos

oVirt, OLVM o RHV 4.5 o superior

La rama 4.5 es el piso soportado. Las tres distribuciones comparten el mismo manager y la misma API, así que el procedimiento es idéntico en las tres.

Acceso a la API REST y a imageio

El servicio imageio es el que recibe los discos. Tiene que estar activo y accesible desde el helper, no solo desde el manager: si imageio está detrás de un firewall que solo abre para el engine, la subida falla aunque la API responda bien.

SSH y QMP al host, para migración instantánea

Instant VM Migration necesita hablar QMP con el proceso QEMU del host para hacer el pivot en caliente, y llega ahí por SSH. Si solo vas a usar Cold Migration, este requisito no aplica. El pinning de host-key SSH se exige en todos los caminos desde la v1.0.38.

Un dominio de almacenamiento con espacio

El storage domain de destino debe tener capacidad para los discos de las VMs de la ola, más el espacio del helper (50 GB con los valores por defecto).

Pasos de la migración

El recorrido completo, desde un appliance recién desplegado hasta la primera VM corriendo en oVirt.

  1. 01
    Conectar el servidor Veeam

    En Conexiones → Veeam, agrega tu servidor Veeam Backup & Replication V13. Moov usa la API REST para inventariar el catálogo y la Data Integration API para publicar los discos sin modificar el respaldo.

  2. 02
    Agregar oVirt u OLVM como destino

    En Conexiones → Destinos, elige oVirt / OLVM e ingresa la URL del manager y las credenciales. Moov valida en el alta que la API REST responda y que imageio esté alcanzable, para que el problema aparezca ahí y no a mitad de una ola.

  3. 03
    Desplegar un helper

    El helper se crea como una VM dentro del propio oVirt y se registra contra el Core por TLS mutuo con un token de un solo uso. Es descartable: se elimina al terminar la ola.

  4. 04
    Correr el preflight

    El Pre-flight Inspector escanea el catálogo de Veeam y clasifica cada VM por sistema operativo, discos y preparación VirtIO. Para inventarios grandes puedes filtrar por repositorio y paginar los resultados.

  5. 05
    Elegir modo y planificar la ola

    Instant VM Migration arranca la VM en oVirt desde el respaldo en menos de 60 segundos y pivotea después. Cold Migration sube los discos por imageio y deja la VM creada y apagada, sin necesidad de SSH ni QMP.

  6. 06
    Lanzar y verificar

    Sigues el progreso por disco en la consola, con bytes efectivamente transferidos medidos antes de que empiece la copia. Al terminar, el agente invitado responde y la VM queda operativa en el destino.

Qué le pasa al sistema operativo invitado

La etapa de customize corre offline sobre el disco montado antes de que la VM arranque en oVirt, y lo adapta a KVM. No requiere appliance auxiliar ni KVM instalado en el helper.

  • Se inyectan los drivers VirtIO (vioscsi y viostor) en invitados Windows y Linux, lo que habilita el bus virtio-scsi.
  • Se desinstalan las VMware Tools para que no compitan con los drivers y el agente de KVM.
  • Se prepara el QEMU Guest Agent, que oVirt usa para reportar la IP y el estado de la VM en su propia consola.
  • Las IPs estáticas se reaplican según la ranura PCI de cada NIC, incluidos invitados Windows con varias interfaces.
  • En invitados que arrancan por UEFI se siembra o repara la partición ESP, y en Windows se corre el BCD fixup.

Límites conocidos

  • El origen debe ser un backup de imagen de VM en Veeam B&R V13. Los backups de agente y los de aplicación no entran en el alcance.
  • La migración instantánea depende de SSH y QMP al host. Si tu política de seguridad no permite ese acceso, queda disponible Cold Migration.
  • Core y helpers tienen que estar en la misma versión: desde la v1.0.38 el Core rechaza trabajo de helpers más viejos.
  • La capacidad concurrente por helper la marcan su CPU y su RAM, aproximadamente 1 vCPU y 2 GiB por VM en vuelo.
← Ver todos los destinos soportados