Proxmox ya corre en Arm. Tus máquinas x86, no.

El 5 de agosto Proxmox anunció soporte oficial para una segunda arquitectura de CPU: arm64. La noticia es real y es grande. En las mismas notas de la versión hay una frase que no ha llegado a ningún titular: «Guests only run on nodes matching their architecture, and live migration is only possible between nodes of the same architecture».

Lo que se publicó el 5 de agosto

Proxmox VE 9.2 para arm64, sobre Debian 13 «Trixie», con kernel Linux 7.0, QEMU 11.0, LXC 7.0 y ZFS 2.4. Instalador ISO propio, repositorio pve-enterprise disponible para arm64 desde el primer día y la misma interfaz web de siempre. No es una rama experimental ni un port de la comunidad: es una edición con soporte comercial.

La palabra que repite la empresa es paridad. Thomas Lamprecht, CTO: «Our goal was not simply to run Proxmox VE on a new architecture, but to deliver full feature parity: KVM, networking, clustering, ZFS, and Ceph all behaving exactly as our users expect from our x86-64 builds». Tim Marx, COO, pone el porqué comercial: «As data centers shift toward high-density, energy-efficient architectures, our customers require the exact same mission-critical stability on Arm64 that they have relied on with x86». La nota de prensa llama al lanzamiento producto de una «technical collaboration with NVIDIA and Supermicro»; The Register lo recogió el 6 de agosto.

Todo eso es cierto y está bien hecho. Conviene solo mirar de qué se predica la paridad: de la plataforma. KVM, la red, el clúster, ZFS y Ceph se comportan igual. Lo que corre dentro de las máquinas virtuales queda fuera de esa promesa, y nadie ha dicho lo contrario.

El ancho de vía

La red ferroviaria española convencional se construyó con los raíles a 1.668 milímetros y la europea a 1.435. Doscientos treinta y tres milímetros. Mismo acero, misma física, misma ingeniería: los trenes no pasan. Durante décadas, en Irún y en Portbou, la manera de cruzar la frontera en tren fue bajarse de uno y subirse a otro. Los cambiadores de ancho existen porque alguien diseñó un tren capaz de mover la separación de sus propias ruedas al atravesar una instalación construida para eso, no porque el problema se disolviera con el tiempo.

Un hipervisor arm64 te da otro ancho de vía. Y aquí no hay cambiador. Una máquina virtual en marcha es el contenido de unos registros y unas tablas de páginas que la CPU de destino tiene que entender tal cual; x86-64 y aarch64 no comparten ni el juego de instrucciones ni el formato de esas tablas. KVM virtualiza, no traduce. Traducir se puede —QEMU emula x86 sobre Arm con TCG—, pero a un coste que ninguna carga de producción paga, y Proxmox ni siquiera lo expone. La limitación que publica no es, por tanto, una casilla pendiente de la hoja de ruta: es donde acaba lo que KVM puede hacer.

La columna de la izquierda pesa: quien opera Proxmox hoy sabe operar Proxmox en Arm mañana, con la misma interfaz y los mismos comandos. La curva de aprendizaje es plana. La de las cargas, no.

El invitado que no está

Para que una máquina virtual arranque en un nodo arm64 hace falta que su sistema operativo exista compilado para arm64. En Linux eso hace años que está resuelto: Debian, Ubuntu y Red Hat publican arm64 como arquitectura de primera. Si tu parque es de servicios Linux, el trabajo consiste en reinstalar y restaurar datos. Tedioso, acotado, planificable.

Windows Server es otra conversación. No hay una edición de Windows Server para Arm64 de disponibilidad general, y no hace falta que lo digamos nosotros: lo dice Microsoft en el foro de su propio programa Insider, el 13 de febrero de 2026, por boca de Artem Pronichkin. «Unfortunately, Windows Server 2025 is not available for ARM64, and there are currently no plans for that». Lo que hay son compilaciones de vista previa. Hemos buscado además una vía de licenciamiento comercial y no la hemos encontrado; si alguien la ha encontrado, que nos lo diga, porque nos interesa más a nosotros que a él.

Para quién es esto, de verdad

El soporte pleno cubre dos plataformas: NVIDIA Grace y NVIDIA Vera. Para el resto, la frase de Proxmox es «Other UEFI-based ARMv9-A or newer hardware is supported on a best-effort basis». Y hay un requisito de arranque que descarta media conversación de foro: «The host must boot through UEFI and describe its hardware through ACPI. Device-tree-only single-board computers, such as the Raspberry Pi, are not supported».

Grace y Vera son las CPU que NVIDIA pone al lado de sus GPU en bastidores de cálculo, no el hierro de tu rack. Y hay otra nota de prensa de Proxmox, del 28 de julio, que enseña el encargo: alojar NVIDIA Mission Control sobre Proxmox VE, descrito como «the critical virtualization layer beneath this ecosystem», el sustrato donde corren los servicios de gestión de una fábrica de IA. Ahí está el cliente de este lanzamiento. Esta noticia es enorme para quien compra bastidores de GPU y bastante marginal para quien tiene tres nodos y un Ceph.

Lo único que cambia si estás saliendo de VMware

La señal que importa no es la CPU. Es que un proyecto que hace tres años llamaban «la alternativa barata» acaba de portarse a una segunda arquitectura, con paridad de Ceph y de clúster, con repositorio empresarial el día uno y en colaboración técnica con el fabricante del silicio y uno de servidores. Un port así cuesta dinero y horas de gente que sabe, y alguien ha puesto ambas cosas. Para quien está decidiendo si se va de vSphere, el dato relevante es quién está sosteniendo el proyecto al que se plantea mudarse.

Tu plan de migración, en cambio, es el mismo que era la semana pasada. Se sigue haciendo de x86 a x86, con su inventario, sus ventanas y su plan de vuelta atrás, que es la parte que casi nadie prepara. La fecha que aprieta de verdad este mes no tiene nada que ver con Arm: es el fin de soporte de Proxmox VE 8 el 31 de agosto, que tu apt no te va a mencionar. Si además montas Ceph, la paridad anunciada es de la plataforma, no de tus discos: el rendimiento real de un clúster Ceph se decide en otro sitio.

Cuándo NO nos plantearíamos Arm

El conflicto de interés aquí es gordo: vendemos migraciones de VMware a Proxmox. Toda noticia que engorde a Proxmox nos viene bien. Con eso sobre la mesa, estos son los cuatro casos en los que hoy diríamos que no:

• Si hay Windows en el parque. Mientras no exista una edición de disponibilidad general para Arm64, esa mitad no se mueve, y un parque partido en dos plataformas cuesta más de operar que la suma de las dos.
• Si el hardware que te ofrecen no es Grace ni Vera. Entonces estás en best-effort, que es una respuesta razonable del fabricante y a la vez algo que nadie firma en un contrato de servicio. Un clúster de producción no se monta encima de un mejor esfuerzo, y menos si el que responde por él a las tres de la mañana eres tú.
• Si lo que buscas es ahorrar en licencias. Aquí hay un dato que no ha salido en ninguna cobertura y que está en el FAQ del propio anuncio: «Subscriptions for arm64 are separate from the x86-64 ones and are currently available on request». Las suscripciones de arm64 son otro producto, no tienen tarifa publicada y hay que pedir presupuesto a ventas. Cambiar de CPU no te quita un euro de la suscripción; te mete en una lista de precios que todavía no existe. El ahorro de Arm, cuando lo hay, es de vatios y de compra de hierro, y esa cuenta hay que hacerla con tu densidad y tu factura eléctrica. Nosotros no la hemos hecho por ti y nadie debería vendértela hecha.
• Si la idea era montarlo en una Raspberry Pi. Arranca por árbol de dispositivos, no por ACPI, y por eso queda fuera.

Donde sí lo miraríamos con ganas: cargas Linux nuevas, nacidas ya en contenedor, que se despliegan desde un repositorio y que reinstalar no cuesta nada porque nunca hubo nada que preservar. Ahí el ancho de vía da igual, porque no hay que cruzar ningún tren: se construye directamente al otro lado.

De las máquinas virtuales que tienes ahora mismo encendidas, ¿cuántas tienen una imagen arm64 del sistema que corren? Contar las de Windows suele bastar para saber en qué año estamos.

Fuentes (verificadas el 19 de agosto de 2026): la fecha del anuncio, Proxmox VE 9.2 para arm64, la base Debian 13 «Trixie», el kernel 7.0, QEMU 11.0, LXC 7.0 y ZFS 2.4, la disponibilidad del repositorio pve-enterprise y las frases citadas literalmente —«Guests only run on nodes matching their architecture, and live migration is only possible between nodes of the same architecture», «Other UEFI-based ARMv9-A or newer hardware is supported on a best-effort basis», «The host must boot through UEFI and describe its hardware through ACPI. Device-tree-only single-board computers, such as the Raspberry Pi, are not supported», «This is not blocked technically, but mixed-architecture clusters are not officially supported» y «Subscriptions for arm64 are separate from the x86-64 ones and are currently available on request», más la ausencia de SeaBIOS, AMD SEV e Intel GVT-g— del Roadmap de Proxmox VE y del anuncio oficial en el foro de Proxmox y su FAQ. Las citas de Thomas Lamprecht y Tim Marx, la lista de paridad de funciones y la expresión «technical collaboration with NVIDIA and Supermicro», de la nota de prensa de Proxmox del 5 de agosto de 2026; la cobertura del 6 de agosto es de The Register, firmada por Simon Sharwood. La frase «the critical virtualization layer beneath this ecosystem» y el papel de Proxmox VE como sustrato de NVIDIA Mission Control, de la nota de prensa de Proxmox del 28 de julio de 2026. La declaración de Microsoft sobre Windows Server en Arm64 —«Unfortunately, Windows Server 2025 is not available for ARM64, and there are currently no plans for that», de Artem Pronichkin, 13 de febrero de 2026— del foro de Windows Server Insiders de Microsoft; la búsqueda infructuosa de una vía de licenciamiento comercial es nuestra y se declara como tal en el texto. Los anchos de vía de 1.668 y 1.435 milímetros y el funcionamiento de los cambiadores de ancho, de «Cambio de ancho». Son nuestros: el símil del ancho de vía, la explicación de por qué la migración en vivo entre arquitecturas no es una casilla pendiente sino el límite de lo que KVM puede hacer (con el matiz de que QEMU sí emula por software), la tabla de qué cruza y qué se queda, la lectura de que la paridad anunciada es de la plataforma y no de los invitados, la de que el dato relevante para quien sale de VMware es quién sostiene el proyecto, y los cuatro casos de «cuándo no». Las citas de Proxmox y de Microsoft se dejan en inglés, su idioma original, para que se puedan verificar palabra por palabra.