La adquisición de VMware por parte de Broadcom se cerró en noviembre de 2023 por aproximadamente 61.000 millones de dólares, y en pocos meses desapareció el modelo de licencias sobre el que la mayoría de los equipos de infraestructura empresarial habían construido su operación durante una década. Se eliminaron las licencias perpetuas. El catálogo de productos se redujo de más de 8.000 SKUs a cuatro paquetes. Los aumentos de precios reportados van del 150% a más del 1.000%, con AT&T enfrentando propuestas cercanas al 1.050% bajo la nueva estructura de suscripción. Una encuesta de Gartner Peer Community encontró que el 74% de los líderes de TI está explorando activamente alternativas a VMware, y vSphere 7 llega al fin de soporte en octubre de 2025, lo que comprime aún más los plazos. Si tu organización forma parte de ese 74%, este artículo es la guía de arquitectura que necesitas antes de empezar a mover cargas de trabajo.
Por qué el bare metal cambia el cálculo
La conversación sobre alternativas a VMware suele comenzar con opciones de nube gestionada, pero para cargas de trabajo sensibles a la latencia, intensivas en E/S o sujetas a requisitos estrictos de residencia de datos, el bare metal es la respuesta más honesta. Obtienes acceso completo a CPU y memoria sin el costo del hipervisor de una capa compartida sobre ti, una topología NUMA predecible y acceso directo a NVMe. Además, puedes elegir tu propio hipervisor y controlar el ciclo de actualizaciones, que es precisamente la autonomía que el nuevo modelo de Broadcom elimina.
La contrapartida es la responsabilidad operativa. Tú gestionas el sistema operativo del host, el hipervisor, el clustering de almacenamiento y el fencing de HA. Eso no es una razón para evitar el bare metal; es una razón para planificar la arquitectura con cuidado antes de migrar la primera VM.
Las dos opciones serias de hipervisor de código abierto
Para cargas de trabajo empresariales en hardware dedicado en 2025, la lista corta realista es Proxmox VE y XCP-ng. Ambos son aptos para producción, ambos tienen comunidades activas y vías de soporte comercial, y ambos son genuinamente de código abierto en lugar de productos open-core con funciones críticas bloqueadas detrás de un pago. La elección entre ellos es una decisión de arquitectura, no de preferencia.
Proxmox VE: nativo en KVM, rico en almacenamiento y en rápido crecimiento
Proxmox VE combina KVM y LXC bajo una única interfaz web, usando QEMU para la virtualización y Corosync para la comunicación del clúster. Su propuesta de almacenamiento es sólida: ZFS nativo, LVM-thin con snapshots, iSCSI, NVMe-oF e integración nativa con Ceph. Este último punto es especialmente relevante si estás construyendo un clúster hiperconvergente sin una SAN separada. Proxmox VE 8.4, lanzado en abril de 2025, añade migración en vivo con NVIDIA vGPUs y una API para soluciones de backup de terceros, lo que cierra dos brechas que antes requerían soluciones alternativas.
Vale la pena entender el modelo de licencias con precisión. Proxmox VE es software AGPLv3: libre para descargar, instalar y ejecutar en producción sin costo de licencia. Lo que pagas opcionalmente es el acceso al repositorio de actualizaciones empresarial y al soporte del fabricante. El nivel de soporte Basic cuesta aproximadamente 370 € por socket de CPU al año, con tres tickets de soporte incluidos. El nivel Community comienza en 120 € por socket al año. Esas cifras son por socket, no por núcleo, lo que supone una diferencia estructural importante respecto al modelo de VMware. Sin una suscripción, el repositorio sin suscripción recibe actualizaciones que no han pasado por el mismo proceso de pruebas que el repositorio empresarial, por lo que los clústeres en producción deberían tener al menos el nivel Community.
El asistente de migración integrado puede importar VMs de VMware, pero aún es incipiente: las VMs deben estar apagadas, se conecta directamente a los hosts ESXi en lugar de hacerlo a través de vCenter, y las VMs con snapshots requieren limpieza previa. Planifica tus herramientas de migración de forma independiente en lugar de depender del asistente para migraciones masivas.
XCP-ng: basado en Xen, con herramientas de importación desde VMware más maduras
XCP-ng es el hipervisor Xen de código abierto empaquetado con el toolkit de gestión XAPI, administrado a través de Xen Orchestra. Su propuesta de migración es posiblemente más madura que la de Proxmox en este momento: Xen Orchestra 6 incluye una herramienta V2V integrada que soporta streaming, conversión sin agente desde VMware, incluyendo configuraciones VMFS6 y VSAN, con soporte de migración en caliente en todas las versiones de ESXi. Si tienes un entorno VMware grande y quieres minimizar el tiempo de inactividad durante la fase de corte, esas herramientas son una ventaja real.
La brecha en almacenamiento es real, sin embargo. XCP-ng carece de soporte oficial para Ceph y ZFS, lo que empuja los diseños de almacenamiento hiperconvergente hacia soluciones externas o integraciones de terceros. Para cargas de trabajo que pueden usar backends NAS o SAN tradicionales, esto no es un bloqueante. Para equipos que planifican una pila completamente convergente, es una restricción que vale la pena incorporar al análisis de la arquitectura.
El hipervisor no es la parte difícil de una migración desde VMware. Las partes difíciles son la arquitectura de almacenamiento, la lógica de fencing de HA y las herramientas operativas que tu equipo ha construido alrededor de vCenter durante la última década.
Decisiones de arquitectura antes de tocar un host
Independientemente del hipervisor que elijas, hay cuatro decisiones de arquitectura que necesitan respuesta antes de mover la primera carga de trabajo.
- Topología de almacenamiento. ¿Ceph hiperconvergente en Proxmox, NFS o iSCSI compartido desde un appliance dedicado, o NVMe local con replicación a nivel de VM? Ceph en Proxmox necesita un mínimo de tres nodos y NICs dedicadas para replicación. NVMe local con replicación PBS (Proxmox Backup Server) es operativamente más sencillo, pero los objetivos de tiempo de recuperación son más largos. El nivel Basic de PBS cuesta 1.120 € por servidor de backup al año, con cinco tickets de soporte y tiempo de respuesta de un día hábil.
- Estrategia de fencing de HA. Proxmox HA utiliza un modelo basado en quórum: la mayoría de los nodos debe ser accesible para que el clúster funcione. En un clúster de tres nodos, el fallo de un nodo es tolerable; el de dos, no. Dimensiona tu clúster teniendo en cuenta el quórum de fencing, no solo la capacidad bruta.
- Segmentación de red. Define VLANs o bonds separados para el tráfico de VM, la replicación de almacenamiento, el heartbeat del clúster y el acceso IPMI/BMC antes de configurar el primer host. Añadir segmentación de red a un clúster en producción es costoso y complejo.
- Secuencia de migración. Clasifica tus VMs por criticidad y dependencia. Empieza con cargas de trabajo sin estado o fácilmente reproducibles para ganar confianza operativa, y mueve las bases de datos y los servicios en clúster al final. Las cargas de trabajo con snapshots de VMware necesitan que esos snapshots se consoliden antes de la importación, independientemente de la herramienta que uses.
Selección de hardware para el nuevo entorno
Los hipervisores de código abierto no imponen mínimos artificiales de núcleos, pero la selección de hardware sigue siendo importante. Para Proxmox con Ceph, el mínimo recomendado es tres nodos con al menos una NIC dedicada (preferiblemente 25GbE) para replicación de almacenamiento y una NIC separada para el heartbeat del clúster. Las unidades NVMe deben estar en controladores separados de los discos giratorios si tu mezcla de cargas de trabajo incluye ambos. Para XCP-ng, la pila XAPI consume menos memoria que vCenter, por lo que puedes ejecutar las funciones de gestión en los mismos hosts sin un impacto significativo.
Operamos bare metal en MUC1 en Múnich precisamente porque las cargas de trabajo financieras e industriales de la región DACH que llegan allí exigen E/S predecible y residencia estricta. Esos clientes están entre quienes actualmente prueban configuraciones de hipervisores de código abierto en hardware dedicado, y la conclusión consistente es que la brecha operativa respecto a vSphere se reduce rápidamente una vez que el equipo ha gestionado dos o tres ciclos de parcheo en la nueva plataforma.
Cómo es la migración en la práctica
Un calendario de migración realista para un entorno VMware de tamaño medio, digamos entre 50 y 200 VMs, se extiende entre ocho y dieciséis semanas cuando las decisiones de arquitectura anteriores se toman desde el principio. Las fases son: aprovisionamiento de hardware y configuración base del hipervisor (semanas uno y dos), validación de almacenamiento y red (semanas dos y tres), migración piloto de VMs no críticas (semanas tres a seis), desarrollo de herramientas y runbooks (en paralelo), y corte a producción por oleadas (semana seis hasta el final). La penalización de Broadcom por renovación tardía, un 20% adicional del precio de suscripción del primer año aplicado retroactivamente si no cumples la fecha de renovación, crea un plazo inamovible que debe anclar tu plan de proyecto.
El esfuerzo técnico es real pero manejable. Los equipos que tienen dificultades son los que subestiman las herramientas operativas que han construido alrededor de vCenter: scripts de alarmas personalizados, integración con sistemas de ticketing, programaciones de backup vinculadas a las APIs de snapshots de VMware. Audita esas dependencias antes de empezar, no después de que el primer host de producción haya sido migrado.
El resumen honesto
Proxmox VE es la mejor opción por defecto para nuevos clústeres donde controlas la selección de hardware y quieres una propuesta de almacenamiento convergente. XCP-ng merece consideración seria cuando el entorno VMware es grande y el tiempo de inactividad durante la migración es la restricción principal, porque sus herramientas V2V son hoy más maduras. Ninguna de las dos opciones te ata de la manera en que lo hace la estructura de paquetes de Broadcom, y ambas pueden recibir soporte comercial a una fracción de lo que cuestan ahora las suscripciones de VMware. El trabajo de arquitectura es tuyo en cualquier caso; el argumento de licencias para hacerlo nunca ha sido más claro.
