Migración

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

Por Equipo Cloud Privado · · 12 min de lectura ·Actualizado septiembre de 2026
Imagen de portada del artículo «De VMware a Proxmox: guía de migración paso a paso»

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.

Las cuatro fases de una migración planificada, con rollback hasta el corte Una migración por etapas. Primero el inventario: qué hay, de qué depende cada cosa y en qué lotes conviene migrarla, antes de tocar nada. Después un piloto con un lote pequeño y no crítico, con pruebas de rendimiento reales. Luego la migración por tandas, con el entorno antiguo todavía en pie. Y al final el corte definitivo y la retirada de lo antiguo. En las tres primeras fases hay marcha atrás planificada; la última no la tiene, y por eso llega cuando todo lo anterior ya está verificado. 1 Inventario qué hay, de qué depende y en qué lotes se migra 2 Piloto un lote pequeño y no crítico, con pruebas reales 3 Migración por tandas, con el entorno viejo todavía en pie 4 Corte cambio definitivo y retirada de lo antiguo rollback planificado en cada fase La fase 4 es la única sin marcha atrás. Por eso llega cuando todo lo anterior ya está verificado.
Las cuatro fases de una migración planificada, con rollback hasta el corte Una migración por etapas. Primero el inventario: qué hay, de qué depende cada cosa y en qué lotes conviene migrarla, antes de tocar nada. Después un piloto con un lote pequeño y no crítico, con pruebas de rendimiento reales. Luego la migración por tandas, con el entorno antiguo todavía en pie. Y al final el corte definitivo y la retirada de lo antiguo. En las tres primeras fases hay marcha atrás planificada; la última no la tiene, y por eso llega cuando todo lo anterior ya está verificado. 1 Inventario qué hay y de qué depende 2 Piloto un lote pequeño, verificado 3 Migración por lotes el entorno viejo sigue en pie 4 Corte cambio definitivo y retirada Rollback planificado en las fases 1 a 3. La 4 llega cuando lo demás está verificado.
El mismo método por fases que aplicamos en cualquier migración: nada se corta hasta que lo anterior está verificado.

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
Asistente de importación de ESXi (desde PVE 8.2)Conecta el host ESXi como almacenamiento e importa en frío o en vivo; es la vía principal hoyBajo-medio (en vivo, mínimo)
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 la 12.2, agosto de 2024)Bajo-medio

Hoy el camino por defecto es el asistente de importación integrado, que habla con la API de ESXi y trae la máquina con su configuración traducida y los discos convertidos al vuelo, sin exportar nada; lo contamos botón a botón, con la importación en vivo, la automatización con qm import y sus límites, en la guía del asistente de importación de ESXi. El flujo manual sigue valiendo cuando el asistente no puede (vSAN, discos cifrados, hosts antiguos): apagas la VM en VMware, exportas el VMDK, lo conviertes con qm disk import, 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.

Menú Add de Datacenter > Storage en Proxmox VE 9 con la opción ESXi al final de la lista Migración
Migración

Migrar de VMware a Proxmox con el asistente de importación de ESXi: la guía completa

Desde Proxmox VE 8.2 no hace falta exportar OVF ni convertir discos a mano: se conecta el host ESXi como un almacenamiento, se elige la VM y se importa, en frío o en vivo. Qué preparar en VMware antes, qué opciones tiene el asistente, qué hacer en Windows y Linux después, cómo automatizarlo con qm import y qué límites tiene.

16 min
Imagen de portada del artículo «Migrar de Hyper-V a Proxmox: la guía honesta, con sus diferencias y sus trampas» Migración
Migración

Migrar de Hyper-V a Proxmox: la guía honesta, con sus diferencias y sus trampas

No solo se migra desde VMware. Muchas organizaciones quieren salir de Hyper-V —por coste de Windows, por consolidar en una plataforma abierta o por soberanía— y el camino tiene sus particularidades. Explicamos las diferencias entre Hyper-V y Proxmox, cómo se convierten los discos VHDX, por qué los drivers VirtIO son imprescindibles y qué comprobar en las VMs Windows y Linux antes y después del salto.

13 min
Una decisión con dos salidas: migrar a Proxmox o esperar, con la capacidad del clúster como criterio Migración
Migración

Cuándo NO migrar de VMware a Proxmox (y cuándo sí, con los números delante)

Migrar de VMware a Proxmox es parte de lo que hacemos, y hay veces que la respuesta honesta es que todavía no. No por prudencia: por la cuenta que sale. Repasamos las dos objeciones que caducaron este año, la que sigue en pie y nadie menciona, los ocho casos en los que recomendamos esperar y las condiciones concretas en las que sí compensa, empezando por la estructura del coste de licencias.

18 min