Como Migrar de VMware a Proxmox sin Downtime

Por que migrar de VMware a Proxmox en 2026

El cambio de modelo comercial de VMware bajo Broadcom ha sido el catalizador, pero las razones para migrar van más allá del coste inmediato. Las licencias perpetuas de vSphere han desaparecido: ahora solo existe suscripción anual obligatoria. El licenciamiento ha pasado de por socket a por nucleo (core), lo que multiplica el coste en servidores modernos con CPUs de 32, 64 o más nucleos. Además, productos que antes se vendian individualmente (vSphere, vSAN, NSX) ahora solo estan disponibles como parte de bundles obligatorios como VMware Cloud Foundation (VCF) o vSphere Foundation (vSF).

Proxmox VE, basado en KVM y LXC, con Ceph integrado y licencia AGPL v3, ofrece una alternativa open source de nivel empresarial. Las suscripciones de soporte comercial de Proxmox van de 110 a 1.020 EUR/ano por socket, una fracción del coste de VMware. Pero más allá del ahorro, Proxmox aporta ventajas técnicas reales: containers LXC nativos, almacenamiento distribuido Ceph sin licencia adicional, API REST completa para automatización y una comunidad en rápido crecimiento. Para una comparativa detalláda entre ambas plataformas, consulta nuestro artículo Proxmox vs VMware.

Planificacion de la migración

Una migración exitosa comienza mucho antes de tocar la primera VM. La fase de planificacion es la que determina si el proyecto se completa sin incidentes o se convierte en una pesadilla operativa. El primer paso es realizar un inventario exhaustivo de todas las VMs del entorno VMware: sistema operativo, versión, recursos asígnados (vCPU, RAM, disco), tipo de disco (thick/thin provisioned), red (VLANs, IPs estaticas, reglas de firewall), dependencias entre servicios y criticidad.

Con el inventario completo, hay que clasíficar las VMs en grupos de migración por orden de prioridad. Las VMs de desarrollo y staging se migran primero como prueba. Después las aplicaciones internas no críticas. A continuacion las cargas de trabajo de produccion de menor impacto. Y finalmente los servicios críticos (bases de datos, ERP, AD/LDAP). Cada grupo debe tener un plan de rollback documentado: si algo fallá durante la migración de una VM, debe ser posible volver al estado anterior en VMware en minutos.

Es fundamental desplegar un laboratorio de pruebas (testing lab) con Proxmox antes de tocar produccion. Instala un cluster Proxmox con al menos 2-3 nodos, configura la red de forma identica al entorno de produccion (VLANs, bridges, firewall) y migra un subconjunto representativo de VMs. Este laboratorio servira para válidar cada método de migración, ajustar los drivers VirtIO y establecer los tiempos reales de conversión. La documentación oficial de Proxmox sobre migración de servidores a Proxmox VE es un excelente punto de partida.

Métodos de migración: cuatro caminos hacia Proxmox

No existe un único método de migración. Dependiendo del tamano del entorno, la ventana de mantenimiento disponible y las herramientas con las que ya cuentes, puedes elegir entre cuatro enfoques principales. Cada uno tiene sus ventajas y casos de uso optimos.

Paso a paso: migración con qemu-img

El método más directo y universalmente aplicable es la conversión de discos con qemu-img. Este enfoque funciona con cualquier VM independientemente del sistema operativo y no requiere software adicional más allá de las herramientas incluidas en Proxmox. El proceso completo es el siguiente:

1. Exportar la VM desde VMware. Apaga la VM de forma ordenada (guest shutdown). En vCenter, haz clic derecho en la VM y selecciona "Export OVF Template". Esto generara un archivo .ovf (descriptor), uno o más archivos .vmdk (discos) y un .mf (checksums). Alternativamente, puedes copiar directamente los archivos .vmdk desde el datastore de ESXi via SCP o SFTP.

2. Transferir los archivos al nodo Proxmox. Usa SCP, rsync o un almacenamiento compartido NFS para mover los VMDK al nodo Proxmox. Si el disco es thick provisioned, el tamano del archivo sera el total asígnado; si es thin, solo el espacio usado. Para discos grandes (+500 GB), rsync con la opción --progress te permite monitorizar la transferencia.

3. Convertir el disco VMDK a formato QCOW2. En el nodo Proxmox, ejecuta el siguiente comando:

Para discos grandes, anade la opción -p para ver el progreso. Si prefieres formato raw para máximo rendimiento en almacenamiento local, sustituye qcow2 por raw. Para almacenamiento Ceph, raw es la opción recomendada.

4. Crear la VM en Proxmox. Desde la interfaz web de Proxmox, crea una nueva VM con los mismos recursos (vCPU, RAM) que tenia en VMware. Selecciona el tipo de BIOS correcto: si la VM original usaba UEFI, selecciona OVMF (UEFI); si usaba BIOS legacy, selecciona SeaBIOS. No asígnes disco en este paso; lo importaremos manualmente.

5. Importar el disco convertido. Usa el comando qm importdisk para asociar el disco a la VM:

Donde 100 es el ID de la VM y local-lvm es el almacenamiento destino. Después, en la interfaz web, ve a Hardware de la VM, selecciona el disco "Unused" y haz clic en "Edit" para asígnarlo como disco SCSI o VirtIO Block. Configura el orden de arranque para que este disco sea el primero.

6. Instalar drivers VirtIO (solo Windows). Para VMs Windows, monta la ISO de drivers VirtIO (disponible en el repositorio de Fedora/Red Hat) como CD-ROM adicional. Arranca la VM y, desde el Administrador de Dispositivos, actualiza los drivers de disco, red y balloon. Esto es crítico para el rendimiento: sin VirtIO, la VM usara drivers emulados IDE/e1000 que son significativamente más lentos.

7. Verificar y válidar. Comprueba que la VM arranca correctamente, que los servicios responden, que la conectividad de red funciona y que el rendimiento de disco es el esperado. Ejecuta las pruebas de aplicación específicas de tu entorno.

Paso a paso: migración con Veeam

Si ya dispones de Veeam Backup & Replication en tu entorno, puedes aprovechar su capacidad de restauración V2V (Virtual-to-Virtual) para migrar VMs a Proxmox con mínimo downtime. Desde la versión 12, Veeam soporta Proxmox VE como destino de restauración nativo, lo que simplifica enormemente el proceso.

El flujo es: realiza un backup completo de la VM en VMware con Veeam, anade el cluster Proxmox como servidor gestionado en la consola de Veeam, y ejecuta un "Restore to Proxmox VE". Veeam se encarga de la conversión de formato del disco (VMDK a formato compatible con KVM), la creacion de la VM en Proxmox y la inyeccion de drivers VirtIO automáticamente. El downtime se limita al tiempo que tarda el último backup incremental y el cutover de red (típicamente menos de 5 minutos para la mayoria de VMs).

La ventaja clave de este método es que Veeam maneja automáticamente la compatibilidad de hardware virtual, la conversión de controladores de disco y la inyeccion de drivers, reduciendo significativamente el riesgo de errores manuales. Además, como partes de un backup existente, siempre tienes un punto de restauración al que volver en VMware si algo no sale según lo previsto.

Drivers VirtIO y optimización post-migración

Los drivers VirtIO son el equivalente en KVM de los VMware Tools + PVSCSI + VMXNET3. Son drivers paravirtualizados que permiten a la VM comunicarse directamente con el hipervisor sin la capa de emulacion de hardware, logrando un rendimiento prácticamente nativo. Es absolutamente esencial instalarlos en todas las VMs migradas para obtener el rendimiento esperado.

En VMs Linux, los drivers VirtIO estan incluidos en el kernel desde hace años; basta con seleccionar el tipo de dispositivo VirtIO en la configuración de la VM. En VMs Windows, descarga la ISO virtio-win del repositorio de Fedora, montala como CD-ROM y ejecuta el instalador. Para una migración más limpia, puedes instalar los drivers VirtIO en la VM Windows antes de la migración mientras aun esta en VMware, de modo que al arrancar en Proxmox ya los tenga disponibles.

Testing y válidación pre-cutover

Antes de redirigir el trafico de produccion a las VMs en Proxmox, es imprescindible válidar que todo funciona correctamente. El testing debe cubrir multiples capas: sistema operativo, aplicación, red y rendimiento. Hemos desarrollado un checklist basado en nuestras migraciones reales que cubre los puntos críticos.

• check_circle Arranque limpio: la VM inicia sin errores en el log de consola, el SO carga completamente y los servicios arrancan automáticamente
• check_circle Conectividad de red: ping al gateway, resolución DNS, acceso a servicios externos, reglas de firewall correctas
• check_circle Performance baseline: comparar IOPS de disco (fio), throughput de red (iperf3) y uso de CPU con los valores de referencia de VMware
• check_circle Aplicaciones: todas las aplicaciones responden correctamente, las bases de datos son accesibles, los logs no muestran errores
• check_circle Backup: Proxmox Backup Server o Veeam pueden hacer backup de la VM migrada correctamente
• check_circle DNS y cutover: preparar los cambios DNS con TTL bajo (60-300s) para minimizar el tiempo de propagacion al redirigir el trafico

Para el cutover final a produccion, recomendamos una estrategia de cutover por DNS: reduce el TTL de los registros DNS a 60 segundos con 24-48 horas de antelacion, realiza el cutover cambiando el registro A/CNAME a la nueva IP en Proxmox, y mantiene la VM original en VMware apagada pero intacta durante al menos 72 horas como plan de rollback. Si es posible, programa el cutover durante una ventana de bajo trafico (noche, fin de semana).

Caso de exito EasyDataHost: migración real con 0 downtime

En EasyDataHost hemos completado migraciones de VMware a Proxmox para clientes con 45+ VMs en produccion, incluyendo servidores de bases de datos SQL Server, controladores de dominio Active Directory, aplicaciones web con alta concurrencia y servicios de ficheros con decenas de TB de datos. El resultado: 0 minutos de downtime percibido por los usuarios finales y un ahorro del 60% en costes de licencias desde el primer ano.

Conclusión

Migrar de VMware a Proxmox no es un salto al vacio. Es un proceso bien documentado, con herramientas maduras (qemu-img, Veeam V2V, importovf) y una comunidad creciente de empresas que ya lo han completado con exito. La clave esta en la planificacion: un inventario exhaustivo, un laboratorio de pruebas, migraciones por fases y un plan de rollback para cada paso. Con este enfoque, el downtime real para los usuarios finales puede ser literalmente cero.

El ahorro económico es innegable: del 60% al 90% en costes de licencias respecto a VMware. Pero más allá del coste, la migración a Proxmox aporta ventajas técnicas reales: containers LXC nativos, Ceph integrado, API REST completa y la tranquilidad de no depender de las decisiones comerciales de un único vendor. En un mundo donde Broadcom ha demostrado que puede cambiar las reglas de la noche a la manana, la soberania tecnológica tiene un valor estratégico que va más allá de los euros ahorrados.

Si estas evaluando la migración de VMware a Proxmox, nuestro equipo de ingenieros puede ayudarte con un análisis personalizado de tu entorno, un plan de migración detalládo y la ejecucion llave en mano del proyecto. Contacta con nosotros y analizamos tu caso sin compromiso.