Desde que Broadcom rehízo el catálogo y los precios de VMware, la pregunta ha dejado de ser si conviene mirar alternativas y ha pasado a ser cuánto cuesta moverse. Proxmox VE es la que más gente se está encontrando por el camino, y conviene contar la migración sin adornos: se puede hacer, hay una forma sensata de hacerla, y hay una lista de cosas que muerden si se ignoran.
Qué es Proxmox y qué no
Proxmox VE es Debian con KVM y QEMU debajo, contenedores LXC al lado, y una interfaz web y una API que unifican las dos cosas en un clúster. No es un clon de vSphere: comparte los conceptos —clúster, alta disponibilidad, migración en caliente, almacenamiento compartido— pero no la arquitectura ni las herramientas.
Lo que te llevas de serie, sin licencias por socket ni suscripción obligatoria:
- Clúster con corosync, con reinicio automático de las VMs de un nodo caído y aislamiento del nodo problemático.
- Almacenamiento integrado: Ceph repartido entre los propios nodos de cómputo, o ZFS local para cargas sensibles a la latencia, con instantáneas y sumas de verificación.
- Copias de seguridad con Proxmox Backup Server: incrementales, deduplicadas y cifradas.
Lo que no te llevas: el ecosistema de integraciones certificadas de vSphere, el mismo comportamiento del balanceo de carga, y la red de partners a la que quizá estés acostumbrado. Eso no es un defecto del producto, es el precio de cambiar de plataforma.
La migración, por fases
La gente de Cloud Privado trabaja este tipo de migraciones con un esquema de cuatro fases que coincide con lo que funciona en la práctica:
- Inventario. Antes de tocar nada, saber qué hay: máquinas, dependencias entre ellas, quién habla con quién, qué cabinas y qué redes. Es la fase que más se salta y la que más caro sale saltarse.
- Piloto. Una tanda pequeña y no crítica, medida en serio: rendimiento real, no sensaciones.
- Tandas. Mover por grupos con el entorno antiguo todavía en pie. Aquí la vuelta atrás sigue siendo posible.
- Corte final. Es la única fase sin marcha atrás, y por eso solo se entra en ella cuando las tres anteriores están verificadas.
Con la máquina apagada el traslado se mide en minutos por VM; con réplica previa de discos, la ventana de corte de una tanda suele quedar por debajo de las dos horas. Las bases de datos son el caso aparte: ahí lo que se hace es mantener replicación lógica activa hasta el corte, no copiar un disco y cruzar los dedos.
Los detalles que muerden
- Controladores VirtIO en Windows, antes de mover. Si la VM llega a Proxmox sin ellos, arranca —lenta, con disco y red emulados— y parece que “va”. Es mecánico, pero se olvida.
- Quitar las VMware Tools antes o justo después. Conviven mal con los agentes nuevos.
- UEFI y arranque seguro: revisar el firmware y el disco EFI de cada VM. Es una casilla, pero es la casilla que deja una máquina sin arrancar.
- Redes y VLAN: los nombres de los grupos de puertos no viajan solos. Hay que reproducir el mapa, y conviene hacerlo antes del piloto.
- Almacenamiento: decidir Ceph o ZFS antes de mover, no después. Cambiar de idea con 200 VMs encima es otro proyecto.
¿Y si Proxmox no es la respuesta?
No siempre lo es. Si vienes de XenServer, XCP-ng te va a resultar más familiar. Si lo tuyo es orquestar cientos de VMs con un modelo de nube, OpenNebula tiene un camino propio de migración desde VMware. Y si el destino es Kubernetes, quizá el debate no sea qué hipervisor sino cuánto de esas VMs deberían seguir siendo VMs.
Para entender qué hay debajo de todas estas opciones, la pila de virtualización de Linux —KVM, QEMU y libvirt— explica quién hace qué; casi todo lo demás son capas de gestión encima.
Por dónde seguir
- La comparativa de plataformas de Cloud Privado, para poner Proxmox, VMware y Nutanix en la misma tabla.
- Su análisis de por qué Broadcom prepara un vSphere Standard nuevo, que explica bastante del momento actual.
- Y si al final la red es lo que te preocupa, cómo se escriben de verdad las reglas de firewall y NAT en Proxmox.
Sobre dónde ejecutarlo: Proxmox va igual de bien en hierro propio que en servidores bare metal o en un cloud privado gestionado, que es la vía habitual cuando no quieres mantener tú el hardware pero tampoco quieres compartir máquina con nadie.
Las fichas de Proxmox VE y de ESXi tienen sus versiones y fechas de fin de soporte, que conviene mirar antes de planificar cualquier corte: migrar a una versión que caduca en seis meses es empezar con deuda.
Quien firma este artículo es cofundador de Stackscale, que aparece entre los enlaces. Lo digo aquí para que se sepa al leerlo, no en la letra pequeña.