Moovv1.0.38
Moov

Migración de VMware a Proxmox VE

Moov migra máquinas virtuales a Proxmox VE tomando como origen los puntos de restauración de Veeam Backup & Replication V13. El entorno vSphere de origen no participa: Moov no se conecta a vCenter ni a ESXi en ningún momento de la migración, así que no hace falta ventana de mantenimiento del lado de VMware ni credenciales del entorno original.

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

Proxmox VE 8.x o 9.x

Ambas ramas tienen soporte completo. El clúster debe tener al menos un nodo con capacidad para el helper (8 vCPU, 16 GB de RAM y 50 GB de disco con los valores por defecto) además del espacio de las VMs que vas a migrar.

Una cuenta con permisos de administración

El asistente de alta del destino hace el bootstrap automático del API token: le das credenciales una vez y Moov crea el token que va a usar de ahí en adelante. No hace falta que generes el token a mano.

Almacenamiento con soporte de imágenes

Cualquier storage de Proxmox que acepte discos de VM sirve: local-lvm, ZFS, Ceph RBD o NFS. En Instant VM Migration conviene que el destino final del pivot sea almacenamiento local o Ceph, no un NFS lento, porque ahí es donde queda corriendo la VM.

Red entre appliance, helper y Veeam

El appliance Moov necesita alcanzar el servidor Veeam B&R y la API de Proxmox. El helper, que corre dentro de Proxmox, necesita alcanzar el appliance por mTLS y el repositorio de Veeam para leer el disco publicado.

Pasos de la migración

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

  1. 01
    Conectar el servidor Veeam

    En Conexiones → Veeam, agrega tu servidor Veeam Backup & Replication V13 y prueba la conexión. Moov usa la API REST para el inventario y la Data Integration API para publicar los discos sin modificar el respaldo.

  2. 02
    Agregar Proxmox como destino

    En Conexiones → Destinos, elige Proxmox VE e ingresa la dirección del nodo y unas credenciales de administración. El asistente crea el API token automáticamente y valida el acceso.

  3. 03
    Desplegar un helper en Proxmox

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

  4. 04
    Correr el preflight

    Escanea el catálogo de Veeam y ejecuta el Pre-flight Inspector sobre las VMs que quieras migrar. Clasifica cada una por sistema operativo, discos y preparación VirtIO, y estima la capacidad necesaria en el destino.

  5. 05
    Elegir modo y planificar la ola

    Por cada VM eliges Instant VM Migration, si necesitas que arranque en menos de 60 segundos, o Cold Migration, si prefieres copiar los discos y encenderla en tu propia ventana. El Wave Engine agenda las VMs en paralelo según la capacidad del helper.

  6. 06
    Lanzar y verificar

    El Core publica el punto de restauración, el helper sirve el disco por NBD y Proxmox crea la VM. Sigues el progreso por disco en la consola. En Instant Migration, al terminar el espejo el pivot deja la VM corriendo solo sobre el almacenamiento de Proxmox.

Qué le pasa al sistema operativo invitado

Antes de que la VM arranque en Proxmox, la etapa de customize corre offline sobre el disco montado y lo adapta a KVM. No hace falta un 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 en Proxmox.
  • Se desinstalan las VMware Tools para que no compitan con los drivers y el agente de KVM.
  • Se prepara el QEMU Guest Agent, que Proxmox usa para consultar la IP, hacer fsfreeze y ejecutar comandos en el invitado.
  • 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.
  • 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.
  • En Instant VM Migration la VM depende del respaldo hasta que termina el pivot, así que el repositorio de Veeam debe seguir disponible durante ese lapso.
← Ver todos los destinos soportados