Proxmox VE permite importar máquinas virtuales directamente desde VMware ESXi, pero que el disco llegue correctamente al nuevo hipervisor no significa que el sistema operativo vaya a arrancar sin ajustes. Drivers VirtIO, configuración de red, UEFI, cifrado con TPM virtual o herramientas del antiguo hipervisor pueden convertir una migración técnicamente correcta en una larga intervención durante la ventana de mantenimiento. La documentación oficial de Proxmox confirma buena parte de estos puntos y recomienda preparar el sistema invitado antes de iniciar el traslado.
Las claves de una migración de VMware a Proxmox en 30 segundos
- Proxmox dispone desde 2024 de un importador integrado para trasladar máquinas desde VMware ESXi.
- Windows puede no arrancar con VirtIO SCSI si sus controladores no estaban preparados previamente.
- La nueva tarjeta de red puede afectar a IP estática, reservas DHCP y reglas asociadas a la MAC.
- El estado del vTPM de VMware no puede trasladarse directamente, algo especialmente delicado con BitLocker.
- Proxmox recomienda probar previamente la migración y limitar el paralelismo cuando se importan muchas máquinas.
El cambio de VMware a Proxmox se suele explicar como un problema de mover máquinas virtuales de un hipervisor a otro. Esa descripción se queda corta. Una máquina virtual incluye discos, pero también depende de una determinada controladora, firmware, dispositivos virtuales, interfaces de red, drivers y servicios instalados dentro del sistema operativo.
Por eso una buena migración empieza bastante antes de pulsar el botón de importar.
Proxmox dio un salto importante en este terreno con Proxmox VE 8.2, publicado el 24 de abril de 2024. Aquella versión incorporó oficialmente el asistente para importar máquinas virtuales desde VMware ESXi. El componente utiliza el sistema de plugins de almacenamiento y está integrado tanto en la interfaz web como en la API de Proxmox VE.
El importador traslada la máquina completa y convierte buena parte de su configuración al modelo utilizado por Proxmox. También existe actualmente la posibilidad de realizar un live import: la máquina puede arrancar en Proxmox mientras parte de los datos continúa copiándose en segundo plano. La VM original de ESXi debe apagarse, por lo que no es una migración en caliente entre ambos hipervisores, aunque permite reducir el tiempo durante el que el servicio permanece detenido.
El problema es que transportar correctamente los discos resuelve solo una parte del cambio.
El caso de Windows y VirtIO explica dónde aparece el problema
Una de las situaciones más fáciles de reproducir afecta a las máquinas Windows.
En VMware una VM puede utilizar controladoras virtuales como LSI Logic, VMware Paravirtual SCSI o NVMe. En Proxmox una configuración habitual para obtener buen rendimiento consiste en utilizar VirtIO SCSI, un controlador paravirtualizado que reduce la sobrecarga frente a dispositivos completamente emulados.
Pero Windows necesita disponer del controlador correspondiente para arrancar desde ese dispositivo.
La documentación de migración de Proxmox lo deja bastante claro: recomienda asegurarse de que los controladores VirtIO están instalados en el invitado y cargados en el initramfs antes de realizar la migración. Para Windows existen además pasos específicos cuando se quiere pasar el disco de arranque a VirtIO SCSI.
Si la máquina ya ha sido migrada y no arranca porque no dispone del controlador necesario, Proxmox propone alternativas de recuperación. Una de ellas consiste en conectar temporalmente el disco mediante IDE o SATA, cuyos controladores deberían estar normalmente disponibles, arrancar Windows, instalar los drivers VirtIO y preparar después el cambio definitivo.
Funciona, pero operativamente existe una diferencia enorme entre preparar 40 máquinas durante los días anteriores y tener que reparar 40 máquinas durante una ventana de mantenimiento.
El propio material de formación de Proxmox muestra el proceso con Windows Server 2022 y dedica parte del procedimiento posterior a la importación a habilitar el arranque con VirtIO SCSI y realizar las comprobaciones finales en el Administrador de dispositivos.
La lección es aplicable más allá de un controlador concreto: una importación satisfactoria no equivale automáticamente a una VM preparada para producción.
Qué conviene revisar antes de iniciar el traslado
| Elemento | Qué comprobar antes | Qué puede aparecer después |
|---|---|---|
| Disco de arranque | Drivers VirtIO disponibles | Windows no arranca con VirtIO SCSI |
| BIOS/UEFI | Firmware utilizado por la VM original | Fallo de arranque o entrada UEFI incorrecta |
| Red | IP, VLAN, gateway, DNS, MAC y DHCP | VM arrancada pero sin conectividad |
| VMware Tools | Necesidad y momento de desinstalación | Software y dispositivos del hipervisor anterior |
| QEMU Guest Agent | Instalación y compatibilidad | Menor comunicación host-invitado |
| BitLocker/vTPM | Claves de recuperación disponibles | Solicitud de recuperación o imposibilidad de descifrar |
| Snapshots | Inventario y necesidad real | Importación más lenta |
| vSAN | Ubicación de los VMDK | Importación directa no soportada |
| Discos cifrados VMware | Política de cifrado | El importador no puede trasladarlos |
| Aplicaciones | Arranque y servicios dependientes | VM encendida pero aplicación no operativa |
No todos estos elementos provocarán problemas en todas las máquinas. Precisamente por eso el inventario previo resulta más útil que una receta universal.
Proxmox también advierte de otra diferencia importante. El modo de firmware debe coincidir con el origen: una VM que arrancaba mediante BIOS heredada necesita SeaBIOS, mientras que una que utilizaba UEFI debe configurarse con OVMF. Determinados sistemas tampoco crean la ruta UEFI predeterminada y pueden necesitar que se añada manualmente su entrada de arranque.
Red, BitLocker y vTPM pueden dar problemas aunque Windows arranque
Una VM que muestra correctamente el escritorio todavía puede estar lejos de haber terminado su migración.
La interfaz de red virtual cambia al pasar de VMware a Proxmox. Windows puede considerar el nuevo adaptador un dispositivo diferente y mantener la configuración del anterior, incluso aunque aquella tarjeta ya no aparezca normalmente en el sistema.
Proxmox recomienda anotar previamente la configuración de red y, en Windows, valorar la retirada de la configuración IP estática antes del traslado. También recuerda que las reservas DHCP deben modificarse para utilizar la nueva dirección MAC o, alternativamente, configurar manualmente en Proxmox la MAC que corresponda.
Hay otro punto todavía más sensible: el cifrado.
La documentación oficial señala que actualmente no es posible migrar desde VMware a Proxmox VE el estado de un TPM virtual (vTPM). Cuando una máquina utiliza cifrado completo y las claves están almacenadas en ese dispositivo, Proxmox aconseja considerar su desactivación previamente y, en cualquier caso, disponer de las claves manuales necesarias para descifrar la VM.
Esto merece especial atención en entornos Windows protegidos con BitLocker. No significa que todas las máquinas cifradas vayan a quedar inaccesibles después del traslado, pero sí que la recuperación del cifrado debe formar parte del plan antes de apagar la VM original, no convertirse en una búsqueda de claves durante la madrugada.
También conviene revisar VMware Tools. Proxmox aconseja retirar antes de la migración las herramientas específicas del antiguo hipervisor porque posteriormente pueden resultar más difíciles de eliminar.
En el destino, el equivalente operativo es QEMU Guest Agent, que permite mejorar la comunicación entre Proxmox y el sistema invitado y ejecutar determinadas operaciones desde el host. Su instalación es recomendada por Proxmox, aunque no debe confundirse con los drivers VirtIO: cumplen funciones diferentes.
La documentación aportada como punto de partida insiste precisamente en desplazar estas tareas fuera de la ventana final de migración: preparar drivers, revisar red, cifrado y herramientas del invitado mientras las máquinas siguen operativas, probar una VM real y reservar el cambio definitivo para las tareas que necesariamente requieren detener el servicio.
Con muchas VMs, el paralelismo tampoco es infinito
Existe además una consideración que gana importancia cuando el proyecto pasa de unas pocas máquinas a decenas o centenares.
La documentación actual de Proxmox incluye recomendaciones específicas para las importaciones masivas desde ESXi. El fabricante desaconseja iniciar indiscriminadamente tantas importaciones simultáneas como sea posible.
Uno de los límites está en la API de ESXi. Proxmox explica que existe un número relativamente bajo de conexiones disponibles y que, una vez alcanzado, los clientes pueden quedar bloqueados temporalmente. El servicio esxi-folder-fuse limita por ese motivo las conexiones paralelas y serializa los reintentos cuando ESXi aplica limitaciones.
También existe un coste de memoria en el host Proxmox debido a la caché de lectura anticipada utilizada durante la importación.
La recomendación general del proyecto es no importar simultáneamente más de cuatro discos de máquinas virtuales, aunque el número adecuado depende de la infraestructura. Cuatro VMs con un disco cada una pueden alcanzar ese límite igual que una sola máquina con cuatro discos. En determinados entornos incluso puede ser aconsejable importar las VMs secuencialmente.
Este dato cambia la planificación de una migración grande. No siempre es posible reducir la duración simplemente ejecutando más procesos en paralelo.
También existen limitaciones documentadas que deberían detectarse durante el inventario. La importación puede ralentizarse considerablemente cuando una VM conserva snapshots; los discos alojados en VMware vSAN no pueden importarse directamente mediante este mecanismo y los discos cifrados mediante políticas de almacenamiento tampoco son compatibles. Importar a través de vCenter es posible, pero Proxmox advierte de una reducción importante del rendimiento frente a la conexión directa con ESXi.
Por eso un inventario útil necesita algo más que una columna con el nombre y el tamaño de cada VM.
Debería identificar como mínimo sistema operativo y versión, modo BIOS o UEFI, tipo de controladora, discos y snapshots, ubicación del almacenamiento, cifrado, vTPM, configuración de red, dependencias de aplicaciones, ventanas disponibles y mecanismo de vuelta atrás.
Después puede dividirse el proyecto en tres momentos.
Días o semanas antes se revisan los invitados, se preparan drivers, se documenta la red, se comprueban claves de recuperación, firmware y dependencias y se decide qué elementos del antiguo hipervisor deben eliminarse.
Antes de la migración masiva se traslada una muestra representativa. La propia documentación oficial recomienda probar el proceso con una o varias VMs antes de mover producción. Conviene elegir una máquina que realmente represente el entorno y verificar algo más que el arranque: aplicación, red, almacenamiento, rendimiento, copias de seguridad, monitorización y procedimientos operativos.
Durante la ventana definitiva deberían quedar principalmente el apagado consistente, la importación o sincronización final, el arranque, las comprobaciones y la decisión de continuar o ejecutar el plan de vuelta atrás.
No existe una regla técnica que obligue a empezar exactamente dos semanas antes. Ese plazo depende del tamaño y complejidad de cada infraestructura. Lo que sí está respaldado por la documentación es el principio que hay detrás: VirtIO, red, firmware, cifrado y compatibilidad deben comprobarse antes de trasladar producción.
Proxmox ha simplificado considerablemente el transporte desde VMware con su importador integrado. Pero automatizar el movimiento de los discos no elimina las diferencias entre los dispositivos virtuales que veía el sistema operativo antes y los que encontrará después.
En una migración pequeña esos ajustes pueden resolverse máquina por máquina. En una infraestructura con decenas de servidores, descubrirlos durante la ventana convierte cada excepción en minutos de trabajo manual que se acumulan. El objetivo de la preparación previa no es conseguir que el importador copie más rápido, sino que, cuando termine de copiar, haya muchas menos sorpresas que resolver.
