Por qué falló tu migración a Proxmox (pista: no fue culpa de Proxmox)
Hay una escena muy conocida repitiéndose en muchas reuniones de TI ahora mismo.
Alguien abre una hoja de cálculo con los costes de licencias rodeados en rojo. Se menciona a Broadcom, casi siempre con un suspiro. Y luego surge la pregunta que parece obvia, casi inevitable:
"¿Por qué no movemos todo a Proxmox? Básicamente es VMware gratis".
En apariencia, tiene todo el sentido. Proxmox parece maduro, la lista de funciones convence y muchísimas empresas lo operan en producción sin problemas. Mientras tanto, VMware vSphere ha pasado de ser la opción por defecto a una conversación presupuestaria incómoda.
Así que se toma la decisión. Se convierten las máquinas virtuales, se preparan los hosts y se ejecuta la migración. Y entonces empiezan los comportamientos extraños.
Las bases de datos se caen bajo carga. La latencia se dispara sin motivo aparente. Nodos completos responden con lentitud aunque las herramientas de monitoreo aseguren que todo está "bien". En poco tiempo, surge la conclusión previsible:
"Proxmox es inestable".
"El código abierto no está listo para la empresa".
"Deberíamos habernos quedado en VMware".
Sin embargo, eso no fue lo que ocurrió en realidad. Lo que falló fue una suposición que VMware nos enseñó a asumir durante 15 años.
VMware hizo el almacenamiento invisible más que sencillo
El mayor logro de VMware fue el aislamiento técnico, incluso por encima de la virtualización misma.
VMFS, las integraciones con SAN, vSAN y años de desarrollo pulieron las aristas complejas del almacenamiento. El bloqueo de archivos, la alineación de sectores y la presión sobre la caché quedaron ocultos tras una capa de abstracción impecable. La mayoría de los días no necesitabas pensar en ello, y ese era precisamente el objetivo.
Eso no convirtió a los administradores en perezosos. Hizo que la plataforma triunfara. Pero también provocó que muchos equipos aprendieran qué botones pulsar sin entender por qué funcionaban las cosas. Calculabas los hosts, aplicabas las recomendaciones oficiales y confiabas en que el sistema absorbiera la complejidad.
Proxmox no asume ese papel. Al contrario, te entrega las piezas en bruto: ZFS, Ceph, LVM, XFS. Son herramientas potentes con menos barreras de contención y una transparencia absoluta. Si algo se configura mal, lo vas a ver y lo vas a sufrir de inmediato.
Esa diferencia por sí sola basta para descarrilar migraciones que sobre el papel parecían impecables.
ZFS y la memoria que creías tener
Una de las historias más habituales tras migrar parece casi rutinaria al inicio. Una máquina virtual se congela. Hay abundante memoria RAM instalada, el host no está sobrecargado y nada parece fallar, así que se culpa a Proxmox.
Investigas un poco y casi siempre encuentras a ZFS allí mismo, haciendo con exactitud aquello para lo que fue diseñado.
A ZFS le fascina la memoria. Utiliza ARC para transformar la RAM libre en lecturas más rápidas y mayor rendimiento. Si no le fijas un límite estricto, ocupará todo lo que encuentre disponible, que puede ser prácticamente todo.
Si migraste desde ESXi y calculaste tus servidores con el mismo criterio, ahí es donde todo empieza a desmoronarse. En VMware, esa memoria pertenecía casi por completo a las máquinas invitadas. En Proxmox con ZFS, el sistema de archivos compite ahora por ella.
Cuando la memoria escasea, al proceso OOM killer de Linux no le importa que tu máquina virtual con SQL sea "crítica". Solo ve un sistema bajo presión extrema y toma una decisión, habitualmente la peor desde tu perspectiva operativa.
Es verdad que las versiones recientes de ZFS gestionan mejor la liberación de memoria y ARC es más recuperable que antes. Pero la lección de fondo se mantiene: si no estableces un límite manual, estás confiando en un comportamiento adaptativo justo en el momento en que más necesitas previsibilidad.
Eso es el almacenamiento funcionando según sus propias reglas, y tacharlo de error de Proxmox es errar el diagnóstico.
Ceph en 1GbE: técnicamente posible, en la práctica un desastre
Luego nos encontramos con Ceph, o mejor dicho, con la forma en que muchos intentan ejecutarlo.
Ceph es almacenamiento distribuido, lo que significa que tus discos se comunican constantemente entre sí a través de la red. Cuando todo está sano, el flujo es manejable. Cuando un disco falla, esa conversación se convierte en un torrente masivo de datos, y en una red de 1GbE ese torrente choca contra un muro insalvable.
El engaño radica en que el clúster no cae necesariamente de golpe. Permanece activo y las comprobaciones de salud pueden parecer aceptables. Sin embargo, la latencia se dispara, las tareas de reconstrucción avanzan a paso de tortuga y cada máquina virtual responde con lentitud extrema. Desde fuera parece que Proxmox ha colapsado, cuando en realidad ha colapsado la red.
La documentación de Ceph es tajante al respecto desde hace años: 10GbE es el mínimo absoluto, el punto de partida y no una sugerencia opcional. En entornos reales de producción, 25GbE es lo que realmente te aporta margen de maniobra cuando surgen problemas, porque los problemas siempre acaban apareciendo.
Ejecutar Ceph sobre enlaces de 1GbE porque "funciona" se parece a descubrir que un coche puede avanzar con el freno de mano puesto. Avanzarás, pero las consecuencias no te van a gustar.
El error de migración inadvertido hasta que es tarde
La mayoría de las migraciones siguen el mismo patrón: convertir el disco, importar la máquina virtual, encenderla y, si arranca, dar el trabajo por terminado. Así es como acabas con sistemas con una degradación inexplicable.
Si mueves discos virtuales sin prestar atención a la alineación de sectores, especialmente al pasar de esquemas antiguos de 512 bytes a almacenamiento con bloques de 4K, cada escritura se convierte en trabajo adicional. Una única escritura lógica deriva en múltiples operaciones físicas, los IOPS caen y la latencia aumenta.
Nada se rompe de forma visible y ningún registro arroja un error directo. El rendimiento sencillamente empeora de fondo. Y como el hipervisor cambió al mismo tiempo, las quejas se dirigen a él en lugar de al desajuste de almacenamiento invisible que está frenando todo el entorno.
VMware absorbía gran parte de esos problemas de forma transparente. Proxmox no lo hace. Asume que sabes lo que estás haciendo, y si cometes un error, no te frenará; dejará que lo descubras por las malas.
Lo "gratis" nunca fue el coste real
Lo que casi nadie dice con claridad es que retirar las licencias de VMware no elimina la complejidad, la reubica.
Con VMware pagabas dinero para evitar preocuparte por ciertos problemas. Con Proxmox ahorras ese dinero pero asumes de vuelta esos desafíos internamente: comportamiento de la memoria, saturación de la red, geometría de discos, dominios de fallo y dinámicas de reconstrucción.
Ese intercambio puede ser excelente, y muchos equipos lo aprovechan con éxito. Pero no lo consiguen fingiendo que Proxmox es un reemplazo directo y automático para vSphere.
Si quieres un almacenamiento del que puedas olvidarte, adquiere una cabina SAN. Si buscas rendimiento, añade memoria RAM y optimiza ZFS. Si deseas una infraestructura hiperconvergente, construye una red adecuada y asume sus exigencias. Lo que no puedes pretender es que todo lo demás permanezca intacto.
Un golpe de realidad más que un fallo de Proxmox
VMware no empeoró el nivel técnico de los administradores. Consiguió que ciertos errores fueran más difíciles de percibir, y Proxmox retira esa capa protectora.
Esto resulta incómodo, sobre todo cuando las migraciones se ejecutan con prisas y expectativas poco realistas. Pero los fallos que muchos observan no demuestran que Proxmox no esté preparado para producción. Revelan que la abstracción anterior ocultaba mucho más de lo que creíamos.
Los equipos que analizan con calma, repasan los fundamentos de almacenamiento y diseñan con criterio tendrán éxito. Quienes se apresuren a convertir discos confiando únicamente en la memoria muscular seguirán culpando a la herramienta equivocada.
Tu migración falló porque Proxmox dejó de ocultar cómo opera tu infraestructura en la realidad, y ese choque técnico puede ser muy duro.