Proxmox VE 9.2: ARM64 oficial con NVIDIA Grace y Vera

Después de años atado a x86, Proxmox Virtual Environment cruzó la línea que muchos administradores venían mirando de reojo: ya existe una versión oficial para arm64. Proxmox Server Solutions anunció el 7 de agosto de 2026 que Proxmox VE 9.2 corre de forma soportada sobre servidores Arm de 64 bits, empezando por sistemas con CPUs NVIDIA Grace y la futura NVIDIA Vera. No es una imagen comunitaria ni un port experimental: es un build propio, con su ISO, pensado para el hardware que hoy mueve las "fábricas de IA".

Proxmox VE 9.2 arm64 es la primera edición oficialmente soportada de la plataforma de virtualización open source Proxmox VE para procesadores Arm de 64 bits (AArch64). Está basada en Debian 13.5 "Trixie" con Linux kernel 7.0, usa QEMU 11.0 para máquinas virtuales y LXC 7.0 para contenedores, y al lanzamiento soporta hardware con CPUs NVIDIA Grace y Vera. La desarrolló Proxmox junto a NVIDIA y Supermicro.

¿Qué anunció exactamente Proxmox y por qué importa ahora?

Proxmox VE 9.2 estrena ARM64 oficial: NVIDIA Grace y Vera

Proxmox liberó una edición arm64 oficial de VE 9.2, descargable como ISO desde su sitio, que rompe con la exclusividad x86 que tuvo el proyecto desde su origen. Importa porque Arm dejó de ser sinónimo de "placa chica de bajo consumo": los chips que estrena el soporte —NVIDIA Grace y Vera— son el corazón de servidores de cómputo acelerado para IA, y ahora se pueden virtualizar con la misma herramienta que ya usas para tu clúster de VMs y contenedores.

Según el anuncio recogido por CNX Software (2026), la edición arm64 comparte el mismo stack de software que la x86 —OpenZFS 2.4, Ceph Tentacle 20.2— pero se compila y valida para AArch64. En la práctica, es el mismo Proxmox que conoces: interfaz web, API, HA, storage replicado. Cambia el silicio de abajo, no el flujo de trabajo de arriba.

¿Qué hardware Arm soporta Proxmox VE 9.2 y cuál queda afuera?

El soporte oficial arranca con sistemas basados en NVIDIA Grace y NVIDIA Vera, con soporte "best-effort" en hardware genérico Armv8-A/Armv9-A que exponga UEFI y ACPI. La regla dura es esa última: Proxmox necesita firmware UEFI y descripción de hardware vía ACPI, no device tree.

Soportado oficialmente: plataformas con NVIDIA Grace (por ejemplo el superchip GH200, con 72 núcleos Arm Neoverse V2 y hasta 480 GB de LPDDR5X, según heise online) y la próxima generación NVIDIA Vera.
Best-effort: servidores Armv8-A/Armv9-A que arranquen por UEFI y describan el hardware con ACPI. Pueden funcionar, pero sin la garantía de las plataformas validadas.
No soportado: las single-board computers configuradas solo por device tree. La documentación es explícita: "Device-tree-only single-board computers, such as the Raspberry Pi, are not supported".

¿Por qué Proxmox VE no corre en una Raspberry Pi?

Porque la Raspberry Pi y la mayoría de las SBCs Arm se describen con device tree, no con ACPI, y Proxmox VE exige el segundo. Como resume heise, "la mayoría de las computadoras de placa única basadas en Arm se configuran mediante un device tree, que necesita adaptarse individualmente para cada sistema" —un modelo que no encaja con el arranque estandarizado UEFI+ACPI que la plataforma da por sentado.

Es una distinción arquitectónica, no un capricho. En el mundo x86, cualquier placa expone su hardware de forma más o menos uniforme vía UEFI y ACPI. En Arm, ese estándar (a veces llamado SystemReady/SBSA) recién ahora se generaliza en el segmento servidor. Los chips de NVIDIA lo cumplen; tu Pi de escritorio, no. Si querías virtualizar sobre una Pi, esto no cambia nada para ti: sigues necesitando imágenes no oficiales o soluciones alternativas.

¿En qué se diferencia una VM Arm de una x86 en Proxmox?

La diferencia central es el arranque: las máquinas virtuales arm64 bootean exclusivamente por UEFI, usando AAVMF (la variante Arm del firmware OVMF), sin la opción SeaBIOS que tienes en x86. Además, varias funciones específicas del ecosistema x86 no están presentes.

Solo UEFI, nada de SeaBIOS: toda VM arm64 arranca con AAVMF/OVMF. Las imágenes que asumían BIOS legacy no aplican; tus templates tienen que estar preparados para UEFI.
Sin AMD SEV ni Intel GVT-g: no hay cifrado de memoria de VM al estilo SEV ni las vGPU mediadas de Intel. Son features atadas a silicio x86.
Sin microcode de CPU a nivel del sistema operativo: la gestión de microcódigo que haces en x86 no tiene equivalente acá.
Sin migración en vivo entre arquitecturas: no puedes hacer live migration de una VM entre un nodo x86 y uno arm64. Un clúster mixto no mueve cargas de un lado al otro en caliente.

¿De dónde viene esto? El contexto que lo empujó

El motor detrás del port fue NVIDIA, que necesitaba a Proxmox para su stack de gestión de infraestructura de IA. La edición arm64 se desarrolló en conjunto con NVIDIA y Supermicro, y se validó sobre servidores con el superchip Grace Hopper. En otras palabras: no nació de la comunidad de homelabbers pidiendo correr Proxmox en el living, sino de la necesidad concreta de virtualizar los nodos de cómputo que alimentan cargas de IA a gran escala.

Eso explica el recorte de hardware. Los sistemas Grace no son baratos: heise ubica los equipos GH200 sencillos en formato 2U desde unos 40.000 euros. No es hardware de escritorio ni de PYME; es infraestructura de datacenter. Que Proxmox aterrice ahí lo convierte en una alternativa open source y sin licencias por socket para orquestar VMs en plataformas Arm de cómputo acelerado —un terreno que hasta hace poco quedaba fuera de su alcance.

¿Qué implica para un developer o para proyectos en producción?

Para la mayoría de los proyectos hoy, el impacto directo es bajo: si tu clúster corre sobre x86, nada cambia y no tienes que tocar nada. El valor real es estratégico y de mediano plazo: Proxmox ahora es una opción viable para virtualizar sobre Arm de servidor sin atarte a un stack propietario.

Portabilidad de tu operación: si tu equipo ya vive en la UI y la API de Proxmox, migrar parte de la flota a nodos Arm no implica reaprender otra plataforma. El know-how se transfiere.
Clústeres mixtos con cuidado: puedes tener nodos x86 y arm64 en el mismo clúster para gestión unificada, pero recuerda que no hay live migration entre arquitecturas. Planifica la ubicación de cada VM según su arquitectura objetivo.
Compatibilidad de imágenes: las VMs arm64 corren binarios Arm. No vas a levantar una imagen x86 en un nodo Grace; necesitas guests compilados para AArch64 y templates UEFI.
Densidad y eficiencia: las plataformas Grace apuntan a mucha memoria coherente y muchos núcleos por zócalo, un perfil interesante para cargas paralelas y de inferencia junto a la GPU.

¿Qué puedes hacer con esto HOY?

Si tienes acceso a hardware Grace o a un servidor Arm compatible con UEFI+ACPI, puedes bajar la ISO oficial arm64 desde la sección de descargas de proxmox.com e instalarla como cualquier otra edición de Proxmox VE. Si no tienes ese hardware, lo accionable es prepararte: hoy es leer el detalle y decidir si Arm entra en tu roadmap.

Verifica tu firmware: confirma que el servidor arranque por UEFI y describa el hardware con ACPI (SBSA/SystemReady). Si es device-tree-only, Proxmox no va a instalar.
Descarga la ISO correcta: asegúrate de tomar el instalador arm64, no el x86. Son builds distintos.
Prepárate para UEFI puro: arma tus templates de VM asumiendo AAVMF/OVMF, sin depender de BIOS legacy.
Prueba primero fuera de producción: valida tus imágenes AArch64, backups y flujos de HA en un nodo aislado antes de meter Arm en un clúster que da servicio.

Si vienes armando o endureciendo tu infraestructura Proxmox, esta novedad se complementa bien con las bases que ya cubrimos en el blog: instalar Proxmox VE en bare metal, configurar repositorios y actualizaciones, y armar el bridge de red vmbr0 para tus VMs. Todo eso aplica igual sobre Arm; lo que cambia es el silicio, no la operación.

Preguntas frecuentes

¿Cuándo se anunció el soporte ARM64 de Proxmox VE?

El 7 de agosto de 2026, Proxmox Server Solutions anunció la primera edición oficialmente soportada de Proxmox VE 9.2 para arm64. La versión general 9.2 ya había salido antes en 2026; el soporte arm64 es un build específico posterior para AArch64.

¿Puedo instalar Proxmox VE arm64 en una Raspberry Pi?

No. Proxmox VE requiere firmware UEFI y descripción de hardware vía ACPI, y la Raspberry Pi usa device tree. La documentación indica explícitamente que las single-board computers configuradas solo por device tree, como la Raspberry Pi, no están soportadas.

¿Qué CPUs Arm soporta Proxmox VE 9.2 al lanzamiento?

Al lanzamiento, el soporte oficial cubre sistemas con CPUs NVIDIA Grace y la próxima NVIDIA Vera, con soporte "best-effort" en otro hardware Armv8-A/Armv9-A que exponga UEFI y ACPI. Se desarrolló junto a NVIDIA y Supermicro.

¿Puedo migrar VMs en vivo entre nodos x86 y arm64?

No. Proxmox VE no permite migración en vivo entre arquitecturas distintas. Puedes gestionar nodos x86 y arm64 en un mismo clúster, pero cada VM corre binarios de su arquitectura y no se mueve en caliente hacia la otra.

¿Sobre qué base de sistema está construida la edición arm64?

Sobre Debian 13.5 "Trixie" con Linux kernel 7.0 para arm64, QEMU 11.0, LXC 7.0, OpenZFS 2.4 y Ceph Tentacle 20.2 —el mismo stack de software que la edición x86, recompilado y validado para AArch64.

¿Qué funciones de x86 no están disponibles en la edición arm64?

Faltan SeaBIOS (las VMs arrancan solo por UEFI/AAVMF), AMD SEV, Intel GVT-g, la gestión de microcode de CPU a nivel del sistema operativo y la migración en vivo entre arquitecturas. El resto de la experiencia —UI, API, HA, storage— es la misma.