Proxmox en la empresa: trampas que los admins de VMware no ven venir
Cuando los administradores de VMware empiezan a plantearse el salto a Proxmox, la conversación siempre arranca de la misma manera: llega la factura de Broadcom, cunde el pánico en el departamento financiero y, de golpe, la plataforma de virtualización que funcionaba sin problemas desde hace una década se convierte en una urgencia inaplazable. La historia es ya prácticamente un género propio.
Is Proxmox Really the Cheap VMware Escape Hatch You Think It Is?
El panorama se pone interesante justo después, cuando el equipo técnico levanta una prueba de concepto con Proxmox y empieza a cuestionar sus viejas costumbres de ESXi. Ahí es donde asoman las sorpresas.
Los equipos que ya completaron la transición suelen coincidir en lo mismo: cambiar de mentalidad cuesta más que la propia migración. Cuanto más intentas tratar a Proxmox como si fuera un VMware con otro logotipo, más fallos imprevistos aparecen.
A continuación tienes una recopilación de lecciones reales, advertencias y consejos con cierta dosis de paciencia de ingenieros que vivieron este proceso, junto a los detalles técnicos que siguen tomando desprevenidos a los veteranos de VMware.
No migres: los veteranos insisten en reconstruir
Varios ingenieros que han gestionado este cambio a gran escala advierten de que, en cuanto concibes el proyecto como una migración directa 1:1, ya te estás atando las manos. Un administrador lo resumió sin rodeos: "Olvida la palabra migración; piensa en rediseño y reimplementación".
Hay un motivo técnico para ello. Ambas plataformas abordan el almacenamiento, los controladores, la red, la asignación de vCPU y el clúster con suficientes diferencias como para que una equivalencia directa parezca sencilla al principio, justo antes de dar problemas graves.
Por esta razón, los equipos que intentan clonar su esquema anterior de VMware en Proxmox suelen terminar rehaciendo la mitad del trabajo al mes siguiente. Quienes lo plantean como una instalación limpia desde cero, cuidando el diseño de almacenamiento, la segmentación de red y la planificación de nodos, disfrutan de una experiencia mucho más tranquila.
El almacenamiento es donde mueren los hábitos de VMware
Un administrador lo explicaba con media sonrisa: "VMFS nos malacostumbró".
En VMware, VMFS gestiona snapshots, reservas de bloque y el comportamiento en clúster con una suavidad admirable. Proxmox no utiliza VMFS, y ahí llega el primer choque importante. Los equipos suelen optar por dos caminos principales.
1. Los entornos con NetApp apuestan por NFS o iSCSI
Para quienes ya tienen una infraestructura consolidada con NetApp, NFSv3 suele ser el botón de acceso rápido: es veloz, conocido y directo. iSCSI también funciona bien, sobre todo si necesitas aprovisionamiento fino (thin provisioning) y reservas SCSI, pero exige una lista de comprobaciones estricta: MPIO bien ajustado, almacenamiento en su propia VLAN, tramas jumbo y una separación total respecto al tráfico de corosync.
Un ingeniero recordaba que NetApp ahora ofrece soporte oficial para Proxmox, lo que despeja al instante años de dudas sobre si la configuración estaba admitida.
2. Quienes eligen Ceph van a por todas
Otros toman la ruta opuesta y construyen cabinas de almacenamiento interno completas con Ceph. Lo describen como el equivalente de código abierto a vSAN, aunque más transparente y mucho más exigente con las malas decisiones de hardware.
Cualquier ingeniero satisfecho con Ceph repite la misma premisa: "Hardware exactamente idéntico en cada nodo". Eso implica procesadores iguales, misma cantidad y velocidad de RAM, tarjetas de red homogéneas, controladoras HBA en modo IT y firmware sincronizado al milímetro.
El resultado es un tejido de almacenamiento distribuido capaz de escalar y autorepararse, pero que castiga sin piedad los atajos. Una memoria defectuosa o un SSD a punto de fallar pasan a ser los únicos fallos tangibles que observan los administradores.
NUMA en AMD Epyc: el tropiezo que casi nadie anticipa
Los administradores de VMware suelen estar acostumbrados a optimizar vNUMA sobre servidores Epyc. En ESXi existen selectores específicos para exponer la topología NUMA y ajustar los límites para que las cargas de trabajo rindan al máximo.
La capa de KVM en Proxmox no ofrece los mismos controles directos, al menos no con ese grado de granularidad, y ahí es donde muchos equipos se quedan descolocados.
Un ingeniero lo detalló de forma clara: los zócalos Intel se comportan con total previsibilidad, pero la topología micro-NUMA de AMD Epyc todavía no es respetada a la perfección por KVM a día de hoy. Si las vCPU de una máquina virtual cruzan los límites de los nodos NUMA, aparece una latencia extraña. Resulta molesto más que crítico, salvo si ejecutas Oracle, donde una discrepancia de núcleos puede convertirse en una pesadilla ante una auditoría.
La solución práctica consiste en instalar hwloc, numactl y herramientas de monitorización que expongan los retrasos de CPU por hilo en cada nodo físico. No es una tarea glamurosa, pero es la única vía para detectar qué máquinas virtuales están cruzando nodos NUMA y degradando su rendimiento sin que nadie lo advierta.
Las máquinas virtuales Windows cambian y las licencias se complican
Cualquier ingeniero que haya migrado cargas de Windows coincide en la misma advertencia: no esperes que tus identificadores de hardware, GUID o ID de subsistema PCI se mantengan intactos.
VMware presenta un universo virtual determinado y KVM expone otro muy distinto, por lo que la transición reinicia todo lo que Windows utiliza para validar su activación. En determinados casos tendrás que llamar a soporte de Microsoft, lidiar con restricciones de licencias CSP y afrontar la reactivación de Oracle para cualquier producto de su catálogo.
La mayoría de administradores aconsejan validar cada modalidad de licenciamiento con antelación, de dos en dos máquinas, antes de programar una oleada masiva de migración. Es un proceso metódico, pero evita la crisis de las 2 de la madrugada cuando alguien descubre que la VM de nóminas ha perdido su licencia.
El cambio de controladores en Windows también requiere una coreografía precisa:
- Desinstalar VMware Tools
- Reiniciar el sistema
- Instalar los controladores VirtIO
- Reiniciar nuevamente
- Iniciar la importación en Proxmox
- Conectar el disco de arranque como SATA
- Añadir un disco SCSI diminuto con controlador VirtIO
- Arrancar la máquina y esperar a que detecte la controladora SCSI de Red Hat
- Apagar la máquina y eliminar el disco diminuto
- Reconectar el disco de arranque principal como SCSI
Suena enrevesado hasta que lo ejecutas la primera vez y compruebas que encaja. Y sí, es habitual toparse con una pantalla azul BSOD en el primer inicio: el sistema suele corregir la asignación al segundo reinicio.
Las redes funcionan de otro modo y Open vSwitch se vuelve imprescindible
La pila de red de VMware goza de buena reputación porque resuelve necesidades habituales de forma muy predecible. El puente Linux estándar de Proxmox cumple su función, pero los ingenieros que buscan un etiquetado VLAN más limpio, topologías complejas o una experiencia cercana a ESXi suelen migrar a Open vSwitch. Una vez adoptado, señalan que el mapeo de VLAN resulta más intuitivo y que las capas de automatización como Ansible o Terraform responden con mayor coherencia.
Otras recomendaciones habituales en producción:
- Dedicar a corosync una red física exclusiva
- Separar por completo el tráfico de almacenamiento
- Configurar siempre un watchdog por hardware
- No unificar todo el tráfico en una sola tarjeta de red con la excusa de hacer pruebas rápidas
Son principios que cualquier administrador de VMware ya domina, aunque los comandos y herramientas para aplicarlos sean distintos.
La alta disponibilidad y el clúster exigen un cambio de enfoque
El sistema de HA en VMware ha pasado años perfeccionándose hasta operar casi de forma invisible. La alta disponibilidad de Proxmox funciona con solidez, pero lo hace con una filosofía más propia de Linux, totalmente transparente. Esa transparencia es excelente, salvo cuando alguien la pasa por alto.
Un equipo señaló que cuando la HA gestiona una gran cantidad de máquinas virtuales simultáneas, pueden surgir demoras de sincronización. En ocasiones puntuales, reiniciar el servicio de HA (desactivar y volver a activar) ayuda a limpiar estados antiguos en memoria. Pasa rara vez, pero conviene conocerlo.
Otra advertencia recurrente: evita a toda costa los clústeres de dos nodos físicos sin quórum externo, ya que estás propiciando una situación de split-brain. Si la dirección de la empresa insiste en mantener solo dos nodos, los técnicos coinciden en añadir al menos un QDevice externo para desempatar los votos.
Más autonomía técnica y menos incidencias misteriosas
Este suele ser el mayor cambio cultural para los administradores acostumbrados a VMware. Varios profesionales que llevan años gestionando Proxmox comentan que apenas han tenido que abrir incidencias con soporte técnico, y el motivo es simple: la plataforma base casi nunca falla por sorpresa. Todas las averías que describen correspondían a problemas físicos: un SSD agotado, un módulo de memoria RAM degradado o una fuente de alimentación con fallos. Sustituyes el componente averiado, dejas que ZFS o Ceph reconstruyan los datos y continúas con la operativa normal.
Proxmox no es un sistema que funcione solo: las actualizaciones del kernel exigen reinicios coordinados y las actualizaciones del clúster requieren planificación previa. Pero el entorno carece de esos fallos inexplicables que muchos asocian a los agentes de host de ESXi o a incidencias raras de vCenter.
La automatización ayuda, pero el ecosistema de herramientas cambia
Los administradores de VMware suelen llevar vRealize o PowerCLI muy asimilados en su flujo habitual. Proxmox, en cambio, se apoya con fuerza en herramientas abiertas:
- Ansible para la configuración del sistema
- Terraform para el despliegue de infraestructura
- API REST para flujos de trabajo personalizados
- Proxmox Backup Server para copias de seguridad basadas en snapshots y recuperaciones bare metal
Un ingeniero mencionó haber creado una capa ligera de integración con DreamFactory para exponer llamadas REST sencillas de inventario y cuotas, logrando en un fin de semana lo que antes requería un ciclo completo de aprobaciones presupuestarias.
La sensación compartida en los equipos es que Proxmox entrega las piezas fundamentales para que cada administrador las conecte según sus necesidades.
Y luego está el caso de Oracle…
Cualquier ingeniero con bases de datos Oracle en producción da el mismo consejo: aíslalas por completo. Sitúa las cargas de Oracle en un clúster específico sin migración en caliente, sin vMotion, sin tocar límites de CPU y sin dejar margen a interpretaciones durante una auditoría. Lo que necesitas es un entorno aislado con límites claros y perfectamente documentados.
La verdadera sorpresa es la calma que llega cuando el diseño es correcto
El mensaje más firme que transmiten los ingenieros que ya completaron la migración resulta reconfortante: en cuanto resuelves el almacenamiento, dejas la red limpia, comprendes la topología NUMA y defines un procedimiento metódico, Proxmox se vuelve un entorno muy tranquilo. Es robusto, predecible y no da sorpresas.
Las actualizaciones se instalan, los backups se completan, Ceph repara cualquier anomalía y las máquinas virtuales cumplen su cometido diario. La plataforma pasa a un segundo plano con la misma discreta eficacia que ofrecía ESXi antes de que cambiara el panorama de licencias.
La mayor parte del esfuerzo radica en desprenderse de viejos automatismos, más que en lidiar con los scripts de conversión de discos. VMware condicionó la forma en que el sector entendía la virtualización, y Proxmox propone un modelo ligeramente diferente. Quienes asumen esa evolución suelen preguntarse por qué no dieron el paso mucho antes.