La virtualización empresarial ha vivido pegada a Intel y AMD durante décadas. Eso empieza a moverse por tres frentes a la vez: las cargas de IA, la computación de alto rendimiento y una factura eléctrica que ha dejado de ser un detalle en el TCO de cualquier sala. En ese contexto, Proxmox acaba de publicar Proxmox VE 9.2 para ARM64, la primera compilación oficial del hipervisor para una arquitectura que no es x86-64.
Conviene decir cuanto antes lo que no significa: nadie tiene que migrar sus servidores a ARM. Lo relevante es otra cosa. Proxmox pasa a ser una plataforma de virtualización con soporte oficial para dos arquitecturas de procesador, y eso quita una incógnita a medio plazo a cualquiera que esté estandarizando su infraestructura sobre ella.
Correr Proxmox sobre ARM se podía hacer desde hace años. Había proyectos mantenidos por la comunidad, útiles para laboratorio y para trastear, pero con las limitaciones de siempre: ciclo de desarrollo propio, mantenimiento a cargo de terceros y cero soporte oficial cuando algo se torcía en producción.
Con la versión arm64 eso desaparece. ARM64 deja de ser un proyecto paralelo y entra en la base de código principal, con el mismo trato que la rama x86-64:
Para quien administra el día a día, la traducción práctica es que se gestionan las dos arquitecturas con las mismas herramientas y los mismos procedimientos. Interfaz web idéntica, misma API REST, mismos comandos, misma gestión de almacenamiento y de clúster.
La pila también es la misma que en x86:
| Componente | Versión |
|---|---|
| Base | Debian 13 «Trixie» (13.6) |
| Kernel Linux | 7.0 |
| QEMU | 11.0 |
| LXC | 7.0 |
| ZFS | 2.4 |
| Ceph | Tentacle 20.2.3 |
Aquí está la parte que más se ha malinterpretado en las primeras horas tras el anuncio. Proxmox publica por primera vez una lista de plataformas ARM soportadas, y de salida son dos:
No es casualidad. Los procesadores Grace de NVIDIA se han convertido en pieza habitual de las infraestructuras de IA y HPC de nueva hornada, combinando CPU ARM con mucho núcleo y una integración muy estrecha con sus GPU. Entrenamiento, inferencia, cálculo científico y supercomputación son precisamente los sitios donde ese hardware ya está desplegado, así que empezar por ahí tiene toda la lógica.
Proxmox añade que está trabajando con más fabricantes para ampliar la lista en próximas versiones, lo que apunta a que la certificación irá creciendo conforme madure la oferta de servidores ARM empresariales.
La confusión típica: «entonces ya puedo instalar Proxmox en cualquier cacharro ARM». Pues no. El soporte apunta a servidores empresariales, no a placas de desarrollo baratas. Los requisitos son claros:
Eso deja fuera a Raspberry Pi, Orange Pi, RockPro y a la mayoría de placas que describen su hardware con Device Tree en lugar de ACPI. Si tu plan era montar un clúster casero con SBC, sigue habiendo proyectos comunitarios para eso, pero no es lo que Proxmox soporta ni lo que va a soportar.
Operativamente la experiencia es casi calcada. Las diferencias que hay son arquitectónicas y conviene tenerlas presentes antes de dibujar nada:
| Aspecto | x86-64 | ARM64 |
|---|---|---|
| Arranque de las VMs | SeaBIOS o UEFI (OVMF) | Solo UEFI, con AAVMF |
| Cifrado de memoria AMD SEV | Disponible | No disponible |
| Intel GVT-g | Disponible | No disponible |
| Migración en vivo | Entre nodos x86-64 | Solo entre nodos ARM64 |
| Invitados | Arquitectura del host | Arquitectura del host |
| Interfaz, API y CLI | Iguales | Iguales |
La consecuencia más importante para el diseño de un clúster es la última fila de la lógica: una máquina virtual solo corre sobre un host de su misma arquitectura, y la migración en caliente entre ARM y x86 no existe. Un servidor ARM no es un nodo más que enchufas a tu clúster actual para repartir carga. Serán clústeres separados, gestionados desde la misma interfaz y con los mismos procedimientos, pero separados.
Si estás montando la parte de alta disponibilidad, esto entra directamente en el diseño de los grupos de HA y en el reparto de nodos; lo tratamos con detalle en la guía de alta disponibilidad y clúster Proxmox en producción.
Más allá del anuncio técnico, esto dice algo del momento que atraviesa el sector. Durante muchos años el centro de datos empresarial fue x86 y punto. Hoy conviven tres presiones que empujan hacia la diversidad de arquitecturas: las cargas de IA, el precio de la energía y la búsqueda de más rendimiento por vatio.
Los grandes proveedores de cloud llevan tiempo ofreciendo instancias ARM para determinadas cargas, y NVIDIA está invirtiendo fuerte en plataformas de IA y supercomputación con CPU ARM. Que el hipervisor soporte de forma oficial más de una arquitectura reduce trabajo de operación y deja la puerta abierta sin obligar a nada.
Va en la misma línea que lo que ya comentábamos al hablar de bare metal con GPU frente a hiperescalar y del passthrough de GPU en Proxmox con VFIO e IOMMU: las cargas de IA están reordenando decisiones de infraestructura que llevaban una década resueltas.
Para la mayoría de organizaciones, nada urgente. La inmensa mayoría de la virtualización empresarial sigue corriendo sobre servidores x86, con un catálogo de hardware amplísimo, décadas de optimización de software y compatibilidad probada con todo lo que hay en la sala.
Lo que aporta el soporte oficial de ARM64 es tranquilidad a futuro. Quien estandarice su plataforma sobre Proxmox VE sabe que el hipervisor va a acompañar al mercado, sin tener que cambiar de tecnología si dentro de dos o tres años una carga concreta encaja mejor en un servidor ARM. Es el mismo argumento que llevamos usando desde el principio para recomendarlo frente a las alternativas propietarias, y que desarrollamos en la comparativa entre Proxmox y VMware.
En cloudprivado.com trabajamos hoy con cloud privado, bare metal y plataformas gestionadas de Proxmox VE sobre hardware x86 empresarial, que es lo que encaja en prácticamente todos los entornos de producción que nos llegan. Si nos preguntas ahora mismo por ARM, la respuesta honesta es que lo estamos siguiendo de cerca y que la conversación tiene sentido cuando hay una carga concreta que lo justifique, normalmente ligada a IA o a HPC. Vender un clúster ARM porque acaba de salir el soporte sería exactamente el tipo de cosa que no hacemos.
Lo que sí conviene mirar desde ya, si estás dimensionando infraestructura para los próximos años, es si tu arquitectura da por sentado que todos los nodos son intercambiables. Cuando conviven arquitecturas distintas, esa premisa deja de cumplirse y hay que revisar el plan de recuperación, la estrategia de plantillas y la de backups. Sobre esto último tenemos el detalle en copias consistentes de bases de datos en Proxmox con PBS.
¿La versión ARM64 de Proxmox VE es experimental? No. Es una versión con soporte oficial a partir de Proxmox VE 9.2, con el mismo ciclo de desarrollo, actualizaciones y soporte comercial que la rama x86-64.
¿Qué servidores ARM están certificados? De salida, NVIDIA Grace y NVIDIA Vera. Proxmox indica que trabaja con más fabricantes para ampliar la lista en futuras versiones.
¿Puedo instalarlo en una Raspberry Pi? No. El soporte oficial exige UEFI y ACPI, y la mayoría de placas de desarrollo, la Raspberry Pi incluida, usan Device Tree. Para eso siguen existiendo proyectos de la comunidad, sin soporte del fabricante.
¿Puedo mezclar nodos ARM y x86 en el mismo clúster? Las máquinas virtuales solo se ejecutan sobre hosts de su misma arquitectura y no hay migración en vivo entre ambas. En la práctica se diseñan clústeres separados por arquitectura, aunque el modelo de gestión sea el mismo.
¿Hay que migrar a ARM ahora? No hay ninguna razón para hacerlo por defecto. El grueso de la virtualización empresarial seguirá en x86 durante bastante tiempo. Lo que hace este anuncio es asegurar que Proxmox estará listo cuando el hardware ARM empresarial tenga sentido para una carga concreta.
¿Cambia algo en mi clúster actual? No. Los clústeres x86-64 siguen exactamente igual, con las mismas funciones, incluidas las que no están disponibles en ARM como SeaBIOS, AMD SEV o Intel GVT-g.
¿Estás dimensionando una plataforma de virtualización y no sabes si atarte a una arquitectura concreta? Lo vemos contigo sin prisa y con tus cargas encima de la mesa. Echa un vistazo a nuestra comparativa de cloud o cuéntanos tu caso.
Haces backup de la VM cada noche y duermes tranquilo. Hasta que restauras y la base de datos arranca corrupta o pierde las últimas transacciones. Un snapshot de disco no es lo mismo que un backup consistente de una base de datos. Explicamos la diferencia entre backup consistente por caída, por sistema de ficheros y por aplicación, y cómo conseguir el bueno en Proxmox con el agente invitado, hooks y volcados nativos.
Una red IP enrutada abajo, los servicios de cada cliente encapsulados arriba y BGP distribuyendo dónde está cada MAC. Qué resuelve EVPN-VXLAN, cómo encajan underlay y overlay, qué detalles rompen un fabric (la MTU, siempre la MTU) y cuándo no compensa montarlo.
Entrenar o servir modelos de IA en tu propio cloud privado pasa por una pieza técnica concreta: entregar una GPU física a una máquina virtual con rendimiento casi nativo. Explicamos qué es el passthrough con VFIO e IOMMU, cómo se hace en Proxmox VE 9.2, dónde están las trampas (grupos IOMMU, la GPU de arranque, licencias) y cuándo compensa frente a alquilar GPU en un hiperescalar.