El 5 de agosto Proxmox Server Solutions publicó la primera edición oficialmente soportada de Proxmox VE 9.2 para arm64. No es una preview, no es una rama aparte y no es un experimento de fin de semana: mismo código, mismos repositorios, mismo ciclo de vida y paridad de funciones con la versión x86-64. Y en la letra pequeña del anuncio hay una frase que, para quien tiene que dibujar la infraestructura, pesa más que todo lo demás: «los guests solo corren en nodos que coinciden con su arquitectura, y la migración en vivo solo es posible entre nodos de la misma arquitectura».
Y por si quedaba duda, el propio anuncio contesta a la pregunta obvia —¿puedo mezclar nodos x86-64 y arm64 en un mismo clúster?— con una respuesta que conviene leer entera: «no está bloqueado técnicamente, pero los clústeres de arquitectura mixta no están soportados oficialmente». Es decir: si mañana metes un nodo Arm en tu sala, no has ampliado el clúster. Has empezado el segundo. Y esa es una decisión de arquitectura —con dos bolsas de capacidad, dos reservas de fallo, dos calendarios de mantenimiento y, ya que estamos, dos suscripciones— que conviene tomar a propósito y no descubrir el día que un migrate devuelve un error.
Qué han publicado exactamente
Esto no es un port a medias, y conviene decirlo antes de bajar a la letra pequeña:
- →Paridad de funciones con x86-64: KVM, contenedores LXC, ZFS, Ceph, redes definidas por software, alta disponibilidad, backup e interfaz web. Las diferencias que hay son de plataforma, no funciones que falten por escribir.
- →Misma base y mismo ciclo de vida: Debian 13.5 «Trixie», kernel 7.0 como estable por defecto, QEMU 11.0, LXC 7.0 y ZFS 2.4. Mismos repositorios, misma documentación salvo un puñado de diferencias propias de la arquitectura.
- →Plenamente soportado en las plataformas NVIDIA Grace Hopper y NVIDIA Vera —así lo dice el anuncio del foro; la nota de prensa lo formula como «sistemas basados en las arquitecturas de CPU Grace y Vera», que no es exactamente lo mismo—. El trabajo se validó en colaboración con NVIDIA y Supermicro, y el CTO, Thomas Lamprecht, lo resume sin adornos: desarrollar directamente sobre sistemas Grace Hopper les permitió validarlo en hardware de producción desde el primer día.
- →Best-effort en cualquier otro hardware UEFI con ARMv9-A o superior; ARMv8-A «generalmente funciona», también en modo best-effort. Proxmox dice estar trabajando con más fabricantes de servidores para ampliar la lista de plataformas oficiales.
Que Ceph y ZFS estén en esa lista no es un detalle menor. Significa que la conversación sobre almacenamiento no cambia al cruzar de arquitectura, y ahí ya hay criterio escrito: la cuenta de réplica 3 contra erasure coding se hace igual en un nodo Grace que en un Xeon. Lo que cambia no es el almacenamiento. Es el movimiento.
La frase que decide el diseño
Aquí está el eje del post, y no es una crítica a Proxmox. Conviene separar dos cosas que se suelen confundir. La primera: tus máquinas x86 no corren ahí. KVM no emula procesadores, los acelera, así que un host arm64 ejecuta guests arm64; tu Windows Server, tu ERP compilado en 2014 y esa máquina virtual que nadie se atreve a tocar se quedan donde están. QEMU sí sabe emular una arquitectura sobre otra, pero eso es un banco de pruebas, no una plataforma de producción, y Proxmox no lo ofrece. La segunda, y esta sí es irreducible: no hay migración en vivo cruzando la línea. Trasladar el estado de una CPU en caliente entre dos juegos de instrucciones distintos no es cuestión de que alguien lo programe. Ni en caliente, ni en HA, ni cuando el nodo Arm se quede sin memoria un martes por la tarde.
En las salas que visitamos, la arquitectura del procesador lleva quince años siendo un dato y no una decisión. Comprabas servidores y eran x86; el hipervisor movía cargas de un hierro a otro y nadie miraba la etiqueta del socket. Eso se acaba. A partir de ahora, cada nodo que compras contesta a una pregunta nueva —¿de qué lado va?— y esa respuesta arrastra el dimensionamiento: si tienes seis nodos x86 y dos Arm, no tienes ocho nodos de holgura, tienes seis y dos. La reserva para que un nodo pueda caerse sin drama hay que calcularla por arquitectura, y en un grupo de dos esa reserva es el 50%. Peor todavía: dos nodos tampoco te dan alta disponibilidad de verdad, porque al caer uno el grupo pierde el quórum. El mínimo razonable son tres, o dos más un QDevice que haga de tercer voto.
Lo mismo vale para los contenedores, aunque suene menos épico: una plantilla de LXC se construye para una arquitectura concreta, así que el catálogo de plantillas y las imágenes de tus aplicaciones también se parten en dos si no están publicadas para las dos. Es fácil de olvidar hasta el día que lo compruebas.
Cuatro cosas que dejas de tener al cruzar
Están todas en el anuncio, y ninguna es un defecto del port: son consecuencias de la plataforma. Pero conviene leerlas antes de firmar:
- 1No hay SeaBIOS. Todas las máquinas virtuales arrancan por UEFI, con la build ARM de OVMF (AAVMF). Si arrastras un sistema invitado que solo arranca en modo BIOS heredado, aquí no hay conversación posible.
- 2El host tiene que arrancar por UEFI y describirse por ACPI. No es un capricho: es el requisito que separa un servidor de un cacharro embebido, y el que deja fuera a media estantería de hardware Arm barato.
- 3Ni AMD SEV ni Intel GVT-g. Son tecnologías x86. Si tu diseño depende de cifrado de memoria de la VM o de vGPU mediadas de Intel, ese diseño no cruza.
- 4No hay paquete de microcódigo. En x86 existen
intel-microcodeyamd64-microcode: una errata del procesador se corrige con unapty un reinicio. En arm64 no hay equivalente a nivel de sistema operativo, así que ese parche llega por firmware del fabricante o no llega. Es el punto que menos se comenta y el que más cambia una rutina de mantenimiento.
Y una que no es técnica pero cuesta dinero y tiempo: la suscripción de Arm es aparte. Las que tengas de x86-64 no cubren estos nodos. Y, de momento, tampoco está en catálogo: el anuncio dice que las suscripciones arm64 están «disponibles bajo petición» y remite a hablar con su equipo comercial para un presupuesto. En una casa que va con soporte enterprise, eso es una línea nueva, una fecha de renovación más y un correo que alguien tiene que escribir antes de poder cotizar nada.
La Raspberry Pi no. Y eso te dice para quién es
Es el titular que más va a doler en los foros: los ordenadores de placa única que se describen solo por device tree —la Raspberry Pi, la primera de la lista— no están soportados. Habrá quien lo lea como una decepción. Nosotros lo leemos como la señal más clara de para quién han hecho esto: si el requisito es UEFI y ACPI, y las plataformas plenamente soportadas son Grace Hopper y Vera, el destinatario no es tu armario del pasillo. Es un rack de cómputo acelerado.
El dinero ya se movió, y no es una opinión
Cuando un proyecto que lleva desde 2008 publicando para x86 dedica un ciclo de desarrollo entero a otra arquitectura, hay una hoja de cálculo detrás. Los datos de IDC para el primer trimestre de 2026 la explican mejor que cualquier declaración: los servidores no-x86 facturaron 58.700 millones de dólares, un 107% más que el año anterior, y se llevaron el 47,9% de los ingresos del mercado. En el mismo trimestre, el x86 facturó 63.900 millones y bajó un 2,9%, en su caso por problemas de suministro de componentes. Y si miramos solo el cómputo acelerado, el cruce ya se ha producido: 53.000 millones en servidores acelerados no-x86 frente a 34.600 millones en x86.
Conviene entender de dónde sale ese 107%: no es que las empresas estén cambiando sus servidores de correo a Arm. Es el rack de GPU. Son los sistemas de cómputo acelerado que se venden por armario entero para entrenar y servir modelos, y que llevan CPU Arm pegada al acelerador. Ese es el mercado al que Proxmox acaba de entrar, y encaja con lo que decía su COO, Tim Marx, sobre centros de datos que van hacia arquitecturas de alta densidad y eficientes en energía. Nosotros ya vimos la primera señal de este movimiento cuando Proxmox apareció en el ecosistema de NVIDIA Mission Control, y escribimos entonces que un logo no migra una infraestructura. Aquello era un acuerdo; esto son ISO, repositorios y una lista de limitaciones publicada. Pero la advertencia de aquel post sigue vigente, solo que ahora hay que aplicarla con más cuidado.
Cuándo sí, y cuándo esto no va contigo
Si no tienes un acelerador en el rack ni planes de comprarlo, esta versión no cambia nada para ti hoy. Ni te hace falta, ni la vas a notar, ni deberías dedicarle un punto del orden del día. Tu Proxmox x86 sigue siendo exactamente igual de bueno que hace una semana, y lo que sí conviene mirar es si está bien apretado en producción, que de eso sí hay trabajo pendiente en casi todas las salas que visitamos.
Dicho eso, hay tres situaciones en las que esto sí es una noticia y merece una conversación seria:
- ✓Vas a comprar uno o varios nodos Grace Hopper o Vera para inferencia o entrenamiento y quieres dejar de gestionarlos como una isla con herramientas propias. Ojo con el matiz: como los clústeres mixtos no están soportados, lo que ganas no es meterlos en el clúster de siempre, sino un segundo clúster que corre el mismo software, con los mismos backups, los mismos procedimientos y la misma gente de guardia. No es poco: es la diferencia entre aprender una plataforma nueva y no tener que aprenderla.
- ✓Tienes un tope de potencia por rack —en colocation lo tiene todo el mundo— y el rendimiento por vatio decide qué cabe. Ahí la arquitectura deja de ser una preferencia y pasa a ser aritmética de kilovatios.
- ✓Tu carga es Linux nativo y se compila para las dos arquitecturas sin drama: contenedores, servicios web, colas, bases de datos con paquetes arm64 oficiales. Es el caso más cómodo y también el menos frecuente en una pyme española media, seamos honestos.
Las cinco preguntas antes de cotizar un nodo Arm
Esto es literalmente lo que preguntamos en la primera reunión, y el orden importa porque la primera respuesta suele cerrar el tema:
- 1¿Qué carga concreta va a correr ahí? Con nombre. Si la respuesta es «ya veremos» o «lo que haga falta», la respuesta correcta es x86 y volvemos el año que viene.
- 2¿Existe binario o imagen arm64 de todo el stack? No solo de la aplicación: del agente de backup, del antivirus, del recolector de métricas, del cliente de la VPN y del driver de esa tarjeta rara. La cadena se rompe por el eslabón que nadie inventarió.
- 3¿Cuántos nodos Arm van a ser? Si la respuesta es uno, no hay alta disponibilidad para lo que corra ahí; hay un servidor con un panel bonito. Si son dos, la reserva de fallo es la mitad de la capacidad. El número mínimo razonable casi nunca es el que aparece en la primera propuesta.
- 4¿Quién actualiza el firmware de esas placas? Sin paquete de microcódigo, el mecanismo por el que llega una corrección del procesador es el proceso de firmware del fabricante. Si nadie tiene ese proceso escrito, acabas de crear una isla sin mantenimiento en el sitio más caro del rack.
- 5¿Y el plan B? Si el nodo Arm se cae y no hay otro Arm libre, esa carga no arranca en el lado x86. O aceptas la parada, o la carga vive en contenedores que puedas levantar en x86 el mismo día, o compras el segundo nodo. Las tres opciones son legítimas; la que no lo es, es no haber elegido.
Ninguna de esas preguntas es sobre Arm, en realidad. Son las mismas que hacemos antes de meter cualquier pieza que no encaja con el resto: qué corre, con qué se lleva, quién lo mantiene y qué pasa cuando falla. Es la parte de la consultoría que no sale en las diapositivas y la que evita comprar un servidor caro que acaba siendo un problema de nadie.
Lo que de verdad ha cambiado
Nos parece una buena noticia y lo decimos sin peros: que un hipervisor libre, con soporte enterprise de verdad y sin política de licencias hostil, esté disponible para el hardware donde se está yendo el gasto en servidores le quita a mucha gente la sensación de estar atrapada. Que sea el mismo código y el mismo ciclo de vida —no una rama «community» que se abandona en dos años— es exactamente lo que hay que exigir a un port de esta clase.
Lo que ha cambiado no es que ahora puedas correr Proxmox en Arm. Es que la arquitectura del procesador ha vuelto a ser una decisión de diseño después de años de no serlo, y las decisiones de diseño tienen la mala costumbre de cobrarse tarde: no el día de la compra, sino el día del incidente, cuando alguien descubre que la máquina que hay que levantar en otro sitio no arranca en ningún otro sitio.
Si estás dibujando una infraestructura de virtualización para los próximos cinco años y en esa hoja aparece algo de cómputo acelerado, esta es la conversación que toca tener ahora y no dentro de dos presupuestos. Escríbenos y la tenemos: qué corre, cuántos nodos por lado y qué pasa cuando uno se cae.
Fuentes (verificadas): anuncio oficial del 5 de agosto de 2026 en el foro del proyecto —fuente primaria de casi todo lo técnico de este post— con las plataformas plenamente soportadas («NVIDIA Grace Hopper y NVIDIA Vera»), el soporte best-effort para otro hardware UEFI ARMv9-A o superior y para ARMv8-A, la exclusión de los ordenadores de placa única descritos solo por device tree (Raspberry Pi) y de los sistemas sin arranque UEFI o sin ACPI, el arranque de las VM por AAVMF sin SeaBIOS, la ausencia de AMD SEV e Intel GVT-g, la ausencia de paquete de microcódigo a nivel de sistema operativo, la restricción de que los guests solo corren en nodos de su arquitectura y de que no hay migración en vivo entre arquitecturas, la respuesta literal sobre clústeres mixtos («no está bloqueado técnicamente, pero los clústeres de arquitectura mixta no están soportados oficialmente»), las suscripciones arm64 separadas y «disponibles bajo petición», y las versiones Debian 13.5 «Trixie», kernel 7.0, QEMU 11.0, LXC 7.0 y ZFS 2.4 — anuncio de Proxmox VE para arm64 en el foro oficial. Paridad de funciones, validación conjunta con NVIDIA y Supermicro sobre sistemas Grace Hopper y declaraciones de Tim Marx (COO) y Thomas Lamprecht (CTO); la nota de prensa formula las plataformas como «sistemas basados en las arquitecturas de CPU NVIDIA Grace y NVIDIA Vera» — nota de prensa de Proxmox Server Solutions. Contexto del anuncio y trabajo en curso con otros fabricantes de servidores — The Register, 6 de agosto de 2026. Datos del primer trimestre de 2026 del Worldwide Quarterly Server Tracker de IDC (58.700 M$ en servidores no-x86, +107% interanual y 47,9% de los ingresos; 63.900 M$ en x86, con una caída del 2,9% por restricciones de suministro de componentes) — The Register, 16 de junio de 2026. Cifras de cómputo acelerado del mismo trimestre (53.000 M$ en servidores acelerados no-x86 frente a 34.600 M$ en x86) — IDC, Worldwide Quarterly AI Infrastructure Tracker. Necesidad de quórum y del QDevice como tercer voto en clústeres de dos nodos — documentación de clustering de Proxmox VE. El cálculo de la reserva por arquitectura, las cinco preguntas de la reunión inicial y la recomendación de no mover nada si no hay cómputo acelerado en el rack son nuestros.
¿Cuántos clústeres vas a tener dentro de tres años?
En everyWAN llevamos Proxmox en producción desde hace años y hemos recomendado quedarse quieto tantas veces como migrar. Si estás valorando cómputo acelerado, te decimos qué cabe, qué se mueve y qué se queda donde está.
Hablar con everyWAN
Microsoft 365
ES 
CAT 
EN