Migración

De VMware a Proxmox: guía de migración paso a paso

· 12 min de lectura ·Actualizado Jun 2026

La compra de VMware por Broadcom cambió las reglas de un día para otro: fin de las licencias perpetuas, paso forzoso a suscripción por núcleo y bundles que multiplican la factura de muchas pymes por tres o por cinco. No es un rumor de foro, es lo que están viendo los equipos de IT cuando les llega la renovación. Migrar a Proxmox VE se ha convertido en una conversación seria, no en un experimento de laboratorio.

Esta guía no va a venderte que Proxmox es magia. Va a contarte cómo se hace una migración real, qué duele y dónde se pierde la gente.

Antes de tocar nada: evalúa

Migrar por enfado es la peor estrategia. Antes de mover una sola VM, haz inventario honesto:

  • Cargas y dependencias. Cuántas VMs, qué sistemas operativos, qué versiones, qué aplicaciones críticas y qué relaciones entre ellas.
  • Funciones VMware que usas de verdad. No las que tienes licenciadas: las que usas. DRS, vMotion en caliente, NSX, vSAN, SRM. Algunas tienen equivalente directo en Proxmox, otras requieren rediseño.
  • Integraciones externas. Backup (Veeam, Commvault), monitorización, orquestación, scripts contra la API de vCenter. Todo eso hay que reapuntar.
  • Hardware. Proxmox es generoso con el hardware soportado, pero revisa controladoras RAID, tarjetas de red y compatibilidad de CPU para live migration entre nodos.

Si descubres que dependes profundamente de NSX o de vSAN con políticas complejas, sé sincero: el proyecto será más largo. Mejor saberlo ahora.

La decisión técnica: ZFS, Ceph o almacenamiento compartido

Proxmox no es solo un hipervisor. También es una decisión de almacenamiento, y las tres rutas habituales son:

  • ZFS local por nodo. Sencillo, robusto, ideal para clústeres pequeños. La replicación es asíncrona (cada X minutos), así que el failover pierde los últimos cambios.
  • Ceph hiperconvergente. Almacenamiento distribuido y replicado en los propios nodos. Permite HA real y migración en vivo. Necesita al menos tres nodos y red de 10/25 GbE dedicada. Es lo más parecido a vSAN.
  • SAN/NAS externa compartida. Si ya tienes una cabina, puedes reutilizarla por iSCSI o NFS. Es el camino más rápido si vienes de un VMware clásico con almacenamiento compartido.

No copies la arquitectura de VMware tal cual. Aprovecha para corregir lo que ya no encajaba.

P2V y V2V: cómo mover las máquinas

El corazón de la migración. Tienes varias herramientas, según el origen:

MétodoCuándo usarloDowntime
Importación OVF/OVAExportas la VM desde vSphere e importas el discoMedio (apagado)
qm importovf / qm importdiskConversión directa de discos VMDK a qcow2/rawMedio
Clonezilla / P2V manualMáquinas físicas o casos sin APIAlto
Veeam Restore a ProxmoxSi ya respaldas con Veeam (soporte nativo desde 2025)Bajo-medio

El flujo más limpio para una VM Linux o Windows típica: apagas la VM en VMware, exportas el VMDK, lo conviertes con qm importdisk, lo asocias a una VM nueva en Proxmox, ajustas el controlador de disco (VirtIO para rendimiento) y arrancas.

Windows tiene trampa. Si cambias el controlador de disco a VirtIO sin instalar antes los drivers, arrancas en pantalla azul (INACCESSIBLE_BOOT_DEVICE). Solución: inyecta los drivers VirtIO antes de migrar, o arranca primero con controlador IDE/SATA, instala los drivers y luego cambia a VirtIO.

Fases de un proyecto que sale bien

  1. Piloto. Monta un clúster Proxmox de 2-3 nodos y migra 3 o 4 VMs no críticas. Mide rendimiento real, prueba backup y restauración.
  2. Olas de migración. Agrupa por dependencia, no por orden alfabético. Mueve juntas las VMs que se hablan entre sí para no cruzar el tráfico entre dos plataformas durante semanas.
  3. Convivencia controlada. Durante la transición vivirás con los dos entornos a la vez. Documenta dónde está cada cosa. Aquí es donde se generan los desastres de “creía que esa VM ya estaba en Proxmox”.
  4. Corte y verificación. Migra lo crítico en ventana planificada, valida funcionalmente con el negocio y solo entonces desmantela el origen.
  5. Optimización. Drivers VirtIO en todo, qemu-guest-agent instalado, snapshots y backup automatizados con Proxmox Backup Server.

Errores comunes que arruinan la migración

  • No instalar el qemu-guest-agent. Sin él pierdes shutdown limpio, IPs en el panel y snapshots consistentes.
  • Olvidar los drivers VirtIO en Windows. El clásico pantallazo azul al arrancar.
  • Subestimar la red para Ceph. Ceph sobre 1 GbE es una receta para la frustración. Mínimo 10 GbE dedicado.
  • No probar la restauración. Un backup que nunca has restaurado no es un backup, es una esperanza.
  • Migrar sin congelar cambios. Si la VM origen sigue recibiendo escrituras después de exportar el disco, pierdes datos.

Entonces, ¿merece la pena?

Para la mayoría de cargas estándar, sí: el ahorro en licencias es real y Proxmox es una plataforma madura, con HA, live migration y backup serios. Pero no es gratis en horas de ingeniería ni instantáneo. Lo que mata proyectos no es la tecnología, es la planificación floja y la prisa.

Si quieres saltarte la curva de aprendizaje, podemos diseñar el clúster, ejecutar la migración por olas y operarla después. Eso sí: te diremos la verdad si tu caso concreto encaja mejor en otra cosa.