Cada vez más organizaciones están evaluando la migración desde VMware ESXi hacia Proxmox VE tras los cambios en el modelo de licencias introducidos por Broadcom. Sin embargo, trasladar máquinas virtuales entre ambas plataformas va mucho más allá de convertir un archivo VMDK o importar una máquina virtual. La diferencia entre una migración planificada y otra improvisada puede traducirse en horas de indisponibilidad, pantallas azules, sistemas Linux incapaces de arrancar o pérdidas de rendimiento difíciles de diagnosticar.
Las claves de la migración de VMware a Proxmox VE en 20 segundos
- Migrar una VM no consiste únicamente en convertir discos; también cambia el hipervisor, los controladores y la arquitectura de entrada/salida.
- Windows y Linux deben prepararse antes del apagado definitivo en VMware para evitar problemas de arranque.
- El almacenamiento, la red y los drivers VirtIO son algunos de los puntos más delicados de la transición.
- Probar todo el proceso en un laboratorio y disponer de copias de seguridad verificadas reduce de forma drástica el riesgo en producción.
La buena noticia es que Proxmox VE ofrece una plataforma madura basada en tecnologías abiertas como KVM, QEMU, Linux y ZFS. La menos buena es que esa flexibilidad también exige comprender cómo interactúan todos esos componentes. Esta guía recopila las principales recomendaciones técnicas para minimizar riesgos durante una migración.
La migración no consiste únicamente en copiar un disco virtual
Una de las ideas equivocadas más habituales consiste en pensar que basta con apagar una máquina virtual en VMware ESXi, convertir el disco VMDK e importarlo en Proxmox VE.
En realidad, durante ese proceso cambian múltiples componentes fundamentales:
- El hipervisor pasa de VMware ESXi a KVM.
- El hardware virtual presentado al sistema operativo es diferente.
- Cambian los controladores de almacenamiento y red.
- Cambia la gestión del almacenamiento.
- Cambian los mecanismos de snapshots y backup.
Si el sistema operativo invitado no está preparado para esos cambios, pueden aparecer errores de arranque inmediatamente después de la migración.
En entornos Windows es relativamente frecuente encontrar el conocido INACCESSIBLE_BOOT_DEVICE (0x0000007B) cuando el sistema intenta arrancar utilizando un controlador que ya no existe.
En distribuciones Linux basadas en Red Hat, Rocky Linux, AlmaLinux o SUSE, uno de los síntomas habituales es terminar en la consola de emergencia de dracut, porque el initramfs no contiene los módulos necesarios para acceder al nuevo disco.
Preparar Windows antes de apagar la máquina virtual
Una buena práctica consiste en preparar el sistema operativo mientras todavía está ejecutándose sobre VMware.
Entre las comprobaciones más habituales se encuentran:
| Verificación | Motivo |
|---|---|
| Instalar drivers VirtIO | Permiten acceder al nuevo hardware virtual de KVM |
| Habilitar el servicio viostor | Evita errores de arranque al cambiar el controlador SCSI |
| Eliminar VMware Tools cuando proceda | Reduce conflictos con componentes específicos de VMware |
| Instalar QEMU Guest Agent tras la migración | Mejora la integración con Proxmox VE |
En muchas migraciones también se configura el servicio viostor para que arranque automáticamente modificando el registro de Windows.
Linux necesita reconstruir el initramfs
En sistemas Linux el problema suele encontrarse en el initramfs.
Antes del apagado definitivo conviene regenerarlo incluyendo los módulos VirtIO que utilizará KVM.
En distribuciones basadas en RHEL puede utilizarse un procedimiento similar al siguiente:
dracut --add-drivers "virtio_blk virtio_scsi virtio_net virtio_pci" --forceDespués resulta recomendable revisar:
- presencia de módulos VirtIO
- eliminación de componentes específicos de VMware cuando ya no sean necesarios
- instalación del paquete qemu-guest-agent
No todas las distribuciones utilizan las mismas herramientas. Debian, Ubuntu o SUSE disponen de procedimientos diferentes, por lo que siempre conviene seguir la documentación oficial correspondiente.
El almacenamiento es mucho más importante de lo que parece
La conversión del disco suele realizarse mediante herramientas como:
qemu-img convert -f vmdk -O raw origen.vmdk destino.rawSin embargo, el trabajo no termina ahí.
El rendimiento final dependerá del backend utilizado en Proxmox VE.
Si se utiliza ZFS
Conviene estudiar cuidadosamente parámetros como:
- volblocksize
- ashift
- compresión
- ARC
Especialmente en bases de datos, un tamaño incorrecto del volblocksize puede incrementar notablemente el fenómeno conocido como Write Amplification, reduciendo el rendimiento.
Asimismo, en servidores con mucha memoria es habitual limitar el consumo de ARC mediante parámetros como zfs_arc_max, evitando competir con la memoria asignada a las máquinas virtuales.
Si se utiliza Ceph
En entornos basados en Ceph RBD suele recomendarse aprovechar el soporte TRIM y discard para facilitar la recuperación de espacio.
Configuraciones habituales incluyen opciones como:
- discard=on
- issue_discards=1
Estas configuraciones dependerán del tipo de almacenamiento y de la versión utilizada.
La red virtual también cambia
Otro aspecto frecuentemente infravalorado es la red.
En VMware es habitual encontrar:
- vSwitch Standard
- VMware Distributed Switch (vDS)
- Port Groups
- VLAN Trunk
Mientras que en Proxmox VE predominan:
- Linux Bridge
- Open vSwitch (opcional)
- Proxmox SDN
- VXLAN
- EVPN
No basta con reproducir la configuración visual.
También deben verificarse aspectos como:
- MTU
- VLAN tagging
- Bonding
- LACP
- Jumbo Frames
Un simple desajuste entre MTU 9000 y MTU 1500 puede provocar pérdidas intermitentes difíciles de identificar.
No olvidar las copias de seguridad
Otro cambio importante afecta a la protección de datos.
En VMware muchas organizaciones utilizan VMware VADP junto con soluciones de backup de terceros.
En Proxmox VE la integración cambia completamente y suele apoyarse en Proxmox Backup Server (PBS), que incorpora tecnologías como:
- Incrementales mediante Dirty Bitmaps de QEMU
- Deduplicación por bloques variables
- Compresión
- Cifrado
- Verificación automática de copias
Antes de comenzar una migración resulta recomendable validar que la estrategia de backup continúa cubriendo los mismos objetivos de recuperación (RPO y RTO).
Lista de comprobación antes de iniciar la migración
Antes de programar una ventana de mantenimiento conviene revisar al menos los siguientes puntos:
| Comprobación | Estado |
|---|---|
| Copias de seguridad verificadas | ☐ |
| Drivers VirtIO preparados | ☐ |
| Servicio viostor habilitado (Windows) | ☐ |
| Initramfs regenerado (Linux) | ☐ |
| VMware Tools revisadas | ☐ |
| qemu-guest-agent preparado | ☐ |
| Diseño de red validado | ☐ |
| MTU comprobada extremo a extremo | ☐ |
| Configuración de almacenamiento revisada | ☐ |
| Pruebas realizadas en laboratorio | ☐ |
Migrar también significa cambiar la forma de administrar la infraestructura
Uno de los errores más comunes consiste en pensar que abandonar VMware únicamente reduce el coste de las licencias.
En realidad, parte de ese ahorro suele trasladarse al conocimiento técnico que requiere operar una plataforma abierta.
Administrar correctamente Proxmox VE implica familiarizarse con tecnologías como:
- Linux
- QEMU/KVM
- ZFS
- Ceph
- Redes Linux
- Automatización
- Alta disponibilidad
Para muchas organizaciones esto supone una ventaja, ya que elimina dependencias de software propietario. Sin embargo, también requiere disponer de personal con experiencia o contar con un proveedor especializado durante el proceso de transición.
Preguntas frecuentes
¿Es suficiente con convertir un VMDK para migrar una máquina virtual?
No. Además del disco virtual deben revisarse controladores, configuración del sistema operativo, red, almacenamiento y herramientas de integración con el nuevo hipervisor.
¿Todos los sistemas Windows necesitan instalar drivers VirtIO?
En la mayoría de los casos sí. Prepararlos antes de la migración reduce considerablemente el riesgo de errores de arranque relacionados con el acceso al disco.
¿Qué ocurre si Linux no incluye los módulos VirtIO en el initramfs?
El sistema puede no detectar el dispositivo de almacenamiento al arrancar y finalizar en una consola de recuperación como dracut o en un initramfs de emergencia, dependiendo de la distribución.
¿Proxmox VE ofrece herramientas de copia de seguridad comparables a VMware?
Sí. Proxmox Backup Server proporciona copias incrementales, deduplicación, compresión, cifrado y verificación de integridad, aunque su funcionamiento es diferente al ecosistema de VMware.
Aviso importante
Esta guía tiene carácter exclusivamente técnico y divulgativo. Cada infraestructura presenta características propias relacionadas con el hardware, las versiones de VMware ESXi, Proxmox VE, el sistema operativo invitado, el almacenamiento y las aplicaciones desplegadas.
Las configuraciones, comandos y parámetros mencionados son ejemplos habituales y no deben considerarse válidos para todos los entornos. Antes de realizar cualquier migración en producción es recomendable validar el procedimiento en un laboratorio representativo, disponer de copias de seguridad verificadas y seguir siempre la documentación oficial de VMware, Proxmox, QEMU, Microsoft, Red Hat, SUSE, Debian, Ubuntu, OpenZFS, Ceph y del resto de fabricantes implicados.
Asimismo, parámetros como volblocksize, zfs_arc_max, discard, issue_discards o la configuración de controladores VirtIO deben ajustarse según la carga de trabajo, la arquitectura del almacenamiento y las recomendaciones específicas de cada plataforma. La ejecución de estos procedimientos y sus posibles consecuencias son responsabilidad exclusiva del administrador o de la organización que los lleve a cabo.
