De VMware a Proxmox VE: guía práctica de migración para modernizar tu infraestructura de virtualización

Migrar de VMware a Proxmox VE se ha convertido en una iniciativa prioritaria para muchas organizaciones que buscan reducir dependencia de proveedor, optimizar costes, simplificar la operación y modernizar su plataforma de virtualización con un stack basado en KVM/QEMU (máquinas virtuales) y LXC (contenedores).

Esta guía práctica reúne un enfoque paso a paso, decisiones clave (red, almacenamiento, alta disponibilidad, copias de seguridad), opciones de migración y un checklist para minimizar riesgos y acotar el impacto en producción.

¿Para quién es esta guía?

Equipos de Sistemas/Infraestructura que gestionan entornos VMware (vSphere/ESXi/ vCenter).
Organizaciones con necesidades de alta disponibilidad, continuidad, control de costes y hoja de ruta tecnológica.
Entornos con requisitos de seguridad, segmentación de red, backups auditables y operación 24×7.

Qué cambia al pasar de VMware a Proxmox VE (y por qué importa)

Proxmox VE es una plataforma de virtualización que combina:

KVM/QEMU para VMs.
LXC para contenedores.
Gestión centralizada (clúster), HA, roles/ACL, integración con directorio (LDAP/AD), métricas y API.
Opciones de almacenamiento: ZFS, NFS, iSCSI, CEPH (según arquitectura).

Al planificar la migración, lo importante no es solo “mover VMs”, sino redefinir estándares operativos:

Modelo de red (bridges, VLANs, bonding).
Estrategia de almacenamiento (latencia, IOPS, resiliencia, crecimiento).
Backup/restore (RPO/RTO, retención, pruebas de restauración).
Observabilidad y operaciones (monitorización, parches, automatización).
Seguridad (hardening, control de accesos, segmentación).

Paso 1: inventario y evaluación del entorno VMware

Antes de tocar nada, hay que convertir la migración en un proyecto controlado con datos.

Inventario mínimo recomendado

Lista de VMs: SO, vCPU, RAM, discos, redes, dependencias y criticidad.
Tipo de firmware: BIOS/UEFI, Secure Boot, controladoras virtuales.
Uso de funcionalidades VMware: snapshots, plantillas, DRS, vMotion, etc.
Almacenamiento: datastores, rendimiento real, crecimiento, políticas.
Ventanas de mantenimiento y tolerancia a downtime por servicio.

Clasificación por criticidad

Tier 0/1: sistemas core (ERP, BD, autenticación, e-commerce).
Tier 2: aplicaciones internas con tolerancia moderada.
Tier 3: entornos no críticos (dev/test, batch, utilitarios).

Esta clasificación define el orden de migración, la estrategia de pruebas y el enfoque de rollback.

Paso 2: diseño objetivo en Proxmox VE (arquitectura base)

Dimensionamiento (CPU, RAM y crecimiento)

Estimar capacidad actual y picos reales.
Definir aprovisionamiento y margen de crecimiento.
Reservar recursos para HA.

Red: bridges, VLANs y bonding

Bonding (LACP) para redundancia y ancho de banda.
Segmentación por VLAN para aislar tráfico.
Un bridge por función.

Un bridge por función.

Opciones habituales:

NFS/iSCSI: una de las mejoras opciones cuando se dispone de una cabina de almacenamiento externa.
ZFS local: en caso de no requerir migración en vivo de máquinas virtuales supone una buena opción como almacenamiento local.
CEPH: enfoque hiperconvergente y escalable; requiere buen diseño de red y discos adecuados.

La elección debe alinearse con:

RPO/RTO, criticidad, presupuesto, equipo y madurez operativa.
Latencia e IOPS de cargas (BBDD, VDI, apps transaccionales).

Alta disponibilidad (HA)

Definir qué VMs requieren HA y cuáles no.
Diseñar quórum y nodos (mínimo recomendado para HA real).
Establecer políticas de reinicio, prioridades y dependencias.

Paso 3: preparar la plataforma Proxmox (antes de migrar)

Checklist de preparación:

Instalar Proxmox VE en nodos objetivos con una versión homogénea.
Crear clúster y validar sincronización/latencia entre nodos.
Configurar almacenamiento (ZFS/NFS/iSCSI/CEPH) y probar rendimiento.
Definir redes y validar conectividad extremo a extremo.
Integrar autenticación (LDAP/AD), roles y permisos por equipos.
Establecer estándares: naming, plantillas, políticas de snapshots, ventanas de mantenimiento.
Definir estrategia de backup (idealmente con Proxmox Backup Server) y probar restauración.

Paso 4: elegir el método de migración (según restricciones)

No existe un único camino “mejor”. La decisión depende de downtime permitido, complejidad y criticidad.

Método A: migración por exportación e importación (OVA/OVF + conversión)

Enfoque común cuando se puede asumir una ventana de parada controlada:

Apagar VM en VMware (o congelar consistentemente si aplica).
Exportar a OVA/OVF (según procedimiento interno).
Convertir discos (p.ej., VMDK a QCOW2/RAW).
Crear VM en Proxmox con hardware virtual equivalente.
Importar disco y ajustar drivers/arranque.
Pruebas funcionales, luego cutover.

Método B: conversión V2V (VMware → KVM)

Existen herramientas de terceros que resultan útiles para automatizar la conversión de múltiples máquinas virtuales:

Se recomienda evaluar herramientas de conversión V2V, teniendo en cuenta el sistema operativo y las posibles restricciones de cada VM.
Es importante prestar atención especial a Windows, considerando aspectos como drivers, activación y herramientas para invitados (guest tools).

Por su parte, Proxmox VE ofrece una integración propia que permite migrar máquinas virtuales desde nodos ESXi, realizando la conversión automática de recursos. Sin embargo, para que funcione correctamente, las VMs deben estar apagadas y almacenadas localmente en el nodo ESXi, y no es recomendable migrarlas de una en una.

Método C: reconstrucción (rebuild) + migración de datos

Recomendado cuando se quiere modernizar de verdad (o cuando la VM “arrastra deuda técnica”):

Reinstalar/actualizar SO en Proxmox.
Reimplantar aplicación con IaC/automatización si existe.
Migrar datos (BD/archivos) con método controlado.
Reduce riesgos de conversiones “opacas” y mejora mantenibilidad.

Paso 5: Importación

A nivel operativo, un patrón habitual en Proxmox es importar discos a una VM ya creada y después ajustar el arranque.

Ejemplo de comandos frecuentes (adaptar a cada caso):

Ejemplos comandos frecuentes de importación

Ajustes habituales post-import:

Revisar controladora de disco (VirtIO/SCSI) y orden de arranque.
Instalar/activar qemu-guest-agent cuando aplique.
Sustituir herramientas específicas de VMware por equivalentes en KVM.
Revisar configuración de red (MAC, VLAN, MTU, rutas).
Validar sincronización de hora, DNS, certificados y dependencias.

Paso 6: pruebas, cutover y plan de rollback

Plan de pruebas mínimo (por VM o servicio)

Arranque y logs sin errores críticos.
Servicios levantados (web, app, BD, colas, etc.).
Conectividad: north-south y east-west (firewalls, VLANs, DNS).
Rendimiento básico: latencia de disco, CPU steal, memoria, tiempos de respuesta.
Copia de seguridad y restauración de prueba (imprescindible).

Cutover (paso a producción)

Ventana de mantenimiento y comunicación interna.
Cambio de DNS/LB/IPs según estrategia.
Monitorizar y validar KPIs durante las primeras horas.

Rollback

Definir por adelantado el “punto de no retorno”:

Si algo falla, ¿se vuelve a VMware con la VM original apagada o se restaura backup?
¿Qué datos podrían perderse y cómo se mitiga?
¿Quién aprueba el rollback y en cuánto tiempo?

Paso 7: operación post-migración (lo que suele olvidarse)

Tras migrar, es clave “cerrar” el proyecto:

Normalizar backups, retención y pruebas periódicas de restauración.
Documentar el nuevo estándar (plantillas, redes, almacenamiento, HA).
Monitorización: alertas, capacidad, tendencias de crecimiento.
Parches y actualizaciones con ventanas y procedimiento.
Hardening: roles/ACL, segmentación, MFA si aplica (según stack), auditoría.
Optimización: drivers VirtIO, afinado de CPU/memoria, políticas de disco.

Errores típicos (y cómo evitarlos)

Migrar sin inventario ni dependencias: provoca caídas “en cascada”.
No probar restauraciones: el backup no está validado hasta que restaura.
No diseñar red/almacenamiento: migración rápida, operación lenta y frágil.
Tratar todas las VMs igual: no todas requieren HA ni el mismo RTO.
Falta de plan de rollback: aumenta el riesgo operacional.

Cómo puede ayudar Hopla

En Hopla acompañamos procesos de modernización de infraestructura y virtualización con un enfoque de ingeniería:

Evaluación e inventario de plataforma actual.
Diseño objetivo en Proxmox VE (red, almacenamiento, HA, seguridad, backup).
Ejecución de migraciones por oleadas, con pruebas y ventanas controladas.
Operación y servicios gestionados (según necesidades), monitorización y mejora continua.

Agende una asesoría hoy mismo para una evaluación y optimización en la infraestructura de su empresa.

FAQ: De VMware a Proxmox VE

¿Cuánto downtime necesito para una migración de VMware a Proxmox VE?

Depende del método. Exportación/importación suele requerir parada por VM. En servicios críticos se planifican ventanas y migración por oleadas con pruebas y rollback.

¿Puedo mantener alta disponibilidad (HA) en Proxmox VE?

Sí. Proxmox VE permite HA a nivel de clúster, pero requiere diseño correcto (quórum, red y almacenamiento alineados con los objetivos de RTO).

¿Qué riesgos hay al convertir VMs (V2V)?

Los principales riesgos son drivers, arranque (BIOS/UEFI), herramientas del guest, rendimiento de disco/red y particularidades de Windows (activación/controladores). Se mitiga con piloto, pruebas y estandarización.

¿Cómo aseguro copias de seguridad fiables tras la migración?

Definiendo RPO/RTO, automatizando backups, estableciendo retención, y realizando restauraciones de prueba periódicas. Sin pruebas de restore, no hay garantía real.

¿Es una alternativa viable a VMware en entornos enterprise?

Puede serlo, siempre que se haga un diseño acorde a criticidad, compliance y operación 24×7: HA, backup, segmentación, control de accesos, monitorización y procedimientos.