Cómo migrar una VM VMware de IPLAN a otro proveedor: guía con OVF, VMDK y costos

Si tu VM está en un entorno VMware, la migración puede parecer simple: exportar, importar y listo. En la práctica, hay detalles que definen si el corte sale bien o termina en una noche larga: formato del disco, drivers, red, tamaño de la imagen, DNS, licencias y consistencia de datos

Esta guía está pensada para una VM alojada en IPLAN u otro proveedor con VMware/vSphere, pero el flujo aplica a cualquier entorno donde tengas acceso a exportar una máquina virtual.

¿Qué es una migración VMware?
Una migración VMware consiste en mover una máquina virtual desde un entorno vSphere/ESXi hacia otro proveedor o plataforma. El origen suele exportarse como OVF u OVA, y el disco queda en formato VMDK.
Después tenés dos posibilidades:

La documentación de VMware/Broadcom describe la exportación OVF como una forma de capturar el estado de una VM o vApp en un paquete autocontenido.

¿Cuándo conviene migrar por OVF/VMDK?

Conviene cuando:

- tenés acceso a vSphere o al panel de exportación;- querés conservar sistema operativo y configuración;- la VM no está demasiado atada a integraciones específicas de VMware;- podés aceptar una ventana de apagado;- el proveedor destino acepta importación de imágenes o discos.

Paso 1: Relevar la VM origen

Antes de exportar, documentá la máquina.

Si la VM usa Windows, anotá versión, activación, drivers, servicios, reglas de firewall y software licenciado.

Paso 2: Hacer backup lógico

La exportación OVF no reemplaza al backup. Si algo falla en la importación, necesitás recuperar datos sin depender del disco completo.

En aplicaciones críticas, hacé backup con la herramienta oficial de la base o del software.

Paso 3: Apagar o preparar la VM

Si podés tener downtime, apagá la VM desde el sistema operativo:

Si no podés apagarla todavía, al menos planificá una exportación final durante ventana de mantenimiento. Para bases de datos, evitá exportar mientras hay escrituras intensas.

En vSphere, verificá que la VM esté apagada antes de exportar.

Antes de exportar la máquina virtual, lo ideal es detenerla correctamente desde el sistema operativo. Esto ayuda a evitar inconsistencias en el disco, archivos corruptos o datos incompletos, especialmente si la VM ejecuta bases de datos, aplicaciones web, servicios transaccionales o sistemas con mucha escritura en disco.

Si podés permitir una ventana de downtime, apagá la VM de forma ordenada desde el propio sistema operativo. No conviene forzar el apagado desde vSphere salvo que sea estrictamente necesario.

Si todavía no podés apagarla, planificá una exportación final durante una ventana de mantenimiento. En ese momento deberías detener servicios críticos, pausar escrituras y asegurarte de que los datos queden en un estado consistente.

Para bases de datos, evitá exportar la VM mientras hay escrituras intensas. Lo más seguro es detener temporalmente la aplicación, hacer un backup consistente y recién después exportar o sincronizar los datos finales.

Antes de avanzar, verificá en vSphere que la VM figure como apagada. Exportar una VM encendida puede generar una imagen inconsistente y causar problemas al arrancarla en el proveedor destino.

Paso 4: Exportar la VM como OVF

Desde vSphere Client, el flujo habitual consiste en seleccionar la máquina virtual y usar la opción de exportación como OVF. Esta exportación genera una copia portable de la VM que luego puede ser importada o convertida para otros entornos.

El resultado de la exportación puede incluir varios archivos, entre ellos:

Un archivo OVF, que contiene la definición y metadatos de la máquina virtual.
Un archivo de manifiesto, usado para validar la integridad de los archivos exportados.
Otros archivos asociados, dependiendo de la versión de vSphere y de la configuración de la VM.

Uno o más discos VMDK, que contienen los datos reales de la VM.

En algunas versiones de vSphere, la exportación genera un conjunto de archivos OVF en lugar de un único archivo OVA. Esto no necesariamente es un problema. Muchos proveedores o herramientas pueden trabajar directamente con el conjunto OVF.

Si necesitás un archivo OVA, se puede empaquetar el conjunto de archivos en un único contenedor. Sin embargo, no siempre es obligatorio. Antes de hacerlo, conviene revisar qué formato acepta el proveedor destino.

También es recomendable guardar la exportación en una ubicación con suficiente espacio disponible y, si es posible, conservar una copia original sin modificar. Esa copia puede servir como respaldo en caso de que la conversión o importación falle.

Paso 5: Revisar y preparar los discos VMDK

Una vez exportada la VM, revisá los discos VMDK generados. Este paso es importante porque el disco es la parte más crítica de la migración: contiene el sistema operativo, las aplicaciones, los datos y la configuración.

Primero conviene validar que los archivos estén completos y que el tamaño de los discos tenga sentido en relación con la VM original. También deberías confirmar si la exportación generó un único disco o varios discos separados.

Después, revisá qué formato de disco acepta el proveedor destino. Algunos entornos permiten importar VMDK directamente, mientras que otros requieren convertirlo a formatos como QCOW2 o RAW.

En entornos basados en KVM u OpenStack, normalmente se usa QCOW2 o RAW. QCOW2 suele ser práctico porque permite imágenes más flexibles y compactas, mientras que RAW puede ofrecer mejor compatibilidad y rendimiento en algunos escenarios.

Antes de convertir, identificá correctamente cuál es el disco principal de arranque. Si la VM tiene varios discos, documentá qué función cumple cada uno: sistema operativo, datos, backups, logs o almacenamiento adicional.

También es importante verificar si el sistema usaba BIOS o UEFI, ya que ese detalle puede afectar el arranque en el nuevo proveedor. Lo mismo aplica al tipo de controlador de disco utilizado en VMware, porque al migrar a otro hipervisor podrían cambiar los drivers necesarios.

Si el proveedor destino acepta VMDK de forma nativa, tal vez no sea necesario convertir el disco. Sin embargo, si el destino usa OpenStack, KVM, Proxmox u otra plataforma similar, probablemente convenga convertirlo al formato recomendado por esa plataforma.

Paso 6: Importar la imagen en el nuevo proveedor

El proceso de importación depende mucho del proveedor destino. Algunos proveedores permiten subir imágenes personalizadas directamente desde el panel de administración. Otros requieren usar una herramienta de línea de comandos, una API o un proceso asistido por soporte técnico.

Antes de subir la imagen, revisá los requisitos del proveedor:

Formatos de imagen aceptados.
Tamaño máximo permitido.
Tipo de arranque compatible: BIOS o UEFI.
Tipo de bus de disco recomendado.
Requisitos de drivers.
Compatibilidad con cloud-init.
Reglas para redes, firewalls y almacenamiento.

Si el destino permite importar imágenes, subí el disco convertido o el formato aceptado por la plataforma. Luego creá una nueva instancia usando esa imagen como base.

Durante la creación de la nueva VM, elegí un tamaño de instancia equivalente o superior al de la VM original. Prestá atención a CPU, memoria RAM, almacenamiento, tipo de disco y ancho de banda de red.

Si la VM original tenía varios discos, importá y asociá cada disco en el orden correcto. Un error común es importar solamente el disco principal y olvidar discos secundarios donde están los datos de la aplicación o la base de datos.

Si el proveedor destino no permite importar imágenes personalizadas, la alternativa más segura es crear una VM limpia, instalar el sistema operativo y restaurar la aplicación desde backup. Aunque este método puede llevar más tiempo, muchas veces produce un entorno más limpio, actualizado y fácil de mantener.

Paso 7: Ajustar red, drivers y arranque

Este suele ser uno de los pasos más delicados de la migración. Al mover una VM desde VMware hacia otro proveedor, pueden cambiar componentes fundamentales del entorno virtualizado.

Entre los cambios más comunes están:

Nombre de las interfaces de red.
Driver del disco.
Driver de la placa de red.
Configuración de red estática.
Reglas persistentes de red.
UUIDs de discos o particiones.
Modo de arranque BIOS o UEFI.
Configuración de cloud-init.
Orden de booteo.
Controladores de almacenamiento.

En Linux, es común que la interfaz de red cambie de nombre. Por ejemplo, una interfaz que antes tenía un nombre determinado puede aparecer con otro nombre en el nuevo proveedor. Si la configuración de red estaba fijada manualmente, esto puede dejar la VM sin conectividad.

También puede ocurrir que el archivo de montaje de discos haga referencia a identificadores que cambiaron durante la migración. Si eso pasa, el sistema puede arrancar en modo de emergencia o no montar correctamente ciertas particiones.

Si la VM no arranca, una estrategia habitual es montar el disco desde una VM auxiliar y revisar la configuración desde allí. En ese escenario conviene analizar logs de arranque, configuración de discos, red, initramfs y drivers disponibles.

En Windows, el punto más sensible suele ser la disponibilidad de drivers adecuados antes de migrar. Si la imagen se mueve a un entorno que usa controladores VirtIO y Windows no los tiene instalados, la VM puede no arrancar o funcionar con bajo rendimiento.

Para evitar problemas, prepará la VM antes de exportarla. Instalá drivers necesarios, eliminá configuraciones muy dependientes de VMware y verificá que el sistema pueda adaptarse al nuevo hardware virtual.

También conviene revisar VMware Tools. En algunos casos, después de migrar, esas herramientas ya no tienen utilidad o pueden generar comportamientos no deseados. Dependiendo del destino, deberías reemplazarlas por las herramientas propias del nuevo proveedor.

Paso 8: Probar la aplicación antes de cambiar DNS

Nunca cambies DNS sin probar primero la VM importada. La nueva instancia debe validarse en el proveedor destino antes de dirigir tráfico real hacia ella.

La primera prueba debería confirmar que la VM arranca correctamente y que tiene conectividad de red. Luego deberías validar que los servicios principales estén activos.

Revisá especialmente:

Servidor web.
Base de datos.
Servicios de aplicación.
Procesos en segundo plano.
Jobs programados.
Certificados TLS.
Permisos de archivos.
Conexiones a servicios externos.
Configuración de correo saliente.
Variables de entorno.
Rutas internas de la aplicación.
Logs de errores.

Si se trata de una aplicación web, probala usando la IP nueva antes de cambiar DNS. Cuando la aplicación depende del dominio, podés validar el sitio modificando temporalmente la resolución local desde tu equipo. Esto permite probar el dominio real contra la nueva IP sin afectar a los usuarios.

Probá los flujos críticos de negocio, no solamente la página de inicio. Por ejemplo:

Inicio de sesión.
Registro de usuarios.
Formularios.
Carga de archivos.
Pagos.
Integraciones externas.
Envío de emails.
Panel administrativo.
Consultas a la base de datos.
Tareas automáticas.
Procesos de facturación o generación de reportes.

También compará los datos entre origen y destino. Verificá que la base de datos, los archivos subidos por usuarios, configuraciones y directorios persistentes estén completos.

Antes del cambio definitivo, revisá los logs de la aplicación y del sistema. Es mejor detectar errores durante las pruebas que después de mover el tráfico real.

Paso 9: Reforzar seguridad antes del corte

Antes de exponer la VM al tráfico real, revisá la seguridad del nuevo entorno. Una migración es una buena oportunidad para corregir configuraciones antiguas o débiles.

Validá que el firewall del sistema operativo y el firewall del proveedor estén alineados. No alcanza con configurar uno solo: muchos proveedores tienen reglas de seguridad externas que pueden bloquear o permitir tráfico independientemente del firewall interno de la VM.

Permití solamente los puertos necesarios. En la mayoría de las aplicaciones web, normalmente se necesita acceso para SSH, HTTP y HTTPS. Otros servicios, como bases de datos, paneles internos o herramientas administrativas, no deberían quedar expuestos públicamente salvo que exista una razón clara y controlada.

Buenas prácticas recomendadas:

No exponer bases de datos directamente a internet.
Usar claves SSH en lugar de contraseñas.
Deshabilitar usuarios innecesarios.
Revisar permisos de archivos y directorios.
Renovar certificados TLS si corresponde.
Activar backups automáticos en el proveedor destino.
Configurar monitoreo de disponibilidad.
Configurar alertas de CPU, memoria, disco y errores.
Revisar logs después del primer tráfico real.
Confirmar que los servicios internos sólo escuchen donde corresponde.
Verificar que no haya credenciales antiguas o temporales.
Revisar reglas de seguridad heredadas de la VM original.

También conviene revisar si la aplicación tiene configuraciones hardcodeadas con IPs antiguas, rutas del proveedor anterior o nombres internos de VMware. Cualquier dependencia del entorno anterior puede provocar fallos después del corte.

Paso 10: Cambiar DNS y monitorear la migración

El cambio de DNS debe hacerse recién cuando la VM nueva ya fue probada y validada. Antes de la migración, bajá el TTL del dominio con anticipación para que el cambio de IP se propague más rápido durante la ventana de corte.

Durante la ventana de migración, el flujo recomendado es:

Detener escrituras en el origen.
Poner la aplicación en modo mantenimiento si corresponde.
Hacer el backup o sincronización final.
Validar que los datos finales estén completos.
Encender y verificar la VM destino.
Confirmar que la aplicación funciona correctamente en la nueva IP.
Cambiar los registros DNS.
Monitorear tráfico, logs y errores.
Mantener la VM vieja apagada o en modo solo lectura.
Confirmar estabilidad durante las horas o días posteriores.

Después del cambio DNS, no todos los usuarios llegarán inmediatamente al nuevo servidor. Según el TTL anterior, cachés de DNS y proveedores de internet, puede haber un período de transición donde algunos usuarios sigan resolviendo la IP antigua.

Por eso, conviene mantener la VM original disponible durante un tiempo, pero preferentemente en modo solo lectura o con las escrituras deshabilitadas. Esto ayuda a evitar divergencias de datos entre origen y destino.

Durante las primeras horas, monitoreá de cerca:

Errores HTTP.
Consumo de CPU.
Uso de memoria.
Espacio en disco.
Logs de aplicación.
Logs de base de datos.
Tiempos de respuesta.
Errores de autenticación.
Fallos en integraciones externas.
Envío de correos.
Jobs programados.
Tráfico entrante y saliente.

Una vez confirmada la estabilidad, documentá el cambio realizado. Registrá la fecha de migración, IP anterior, IP nueva, proveedor origen, proveedor destino, formato de imagen utilizado, problemas encontrados y acciones correctivas aplicadas.

No elimines inmediatamente la VM original. Lo más prudente es conservarla apagada o aislada durante algunos días, junto con los backups previos a la migración. Cuando ya no sea necesaria, podés retirarla de forma controlada para evitar costos innecesarios.