Proxmox Virtual Environment acaba de romper una barrera que llevaba años pendiente: la plataforma de virtualización ya cuenta con soporte oficial para arquitecturas Arm de 64 bits (aarch64), dejando atrás su dependencia exclusiva de x86-64. La versión 9.2 para Arm se construye sobre Debian 13.5 «Trixie» con kernel Linux 7.0 y mantiene la misma base de código, herramientas y documentación que la edición para amd64, salvo un puñado de matices propios de la arquitectura. El movimiento no es casual: detrás está el respaldo de NVIDIA, que necesitaba esta compatibilidad para su solución «Mission Control» orientada a la gestión de fábricas de IA. El resultado es una plataforma de virtualización de código abierto que amplía su alcance hacia servidores basados en Arm, aunque con restricciones importantes en cuanto al hardware compatible que conviene tener claras antes de lanzarse a probarla.

Qué cambia con esta versión oficial

Hasta ahora, quien quisiera ejecutar Proxmox VE sobre hardware Arm tenía que recurrir a imágenes no oficiales, como las que lleva ofreciendo desde hace tiempo nuestros amigos de FriendlyELEC para sus placas, incluyendo su reciente NanoPi R28S. Con la llegada de esta build oficial, el proyecto pasa a ofrecer soporte formal, lo que en la práctica se traduce en mayor estabilidad, actualizaciones garantizadas y acceso a funciones que antes dependían de parches de terceros. El anuncio pasó relativamente desapercibido hasta que Jeff Geerling lo destacó en su blog, sorprendiendo a buena parte de la comunidad que desconocía que Proxmox no tuviera ya soporte Arm de forma nativa.

Requisitos de hardware: UEFI y ACPI son innegociables

Aquí está el matiz técnico más relevante del anuncio. Proxmox VE para Arm ofrece soporte completo en plataformas NVIDIA Grace Hopper y NVIDIA Vera, mientras que el resto de hardware Armv8-A y Armv9-A basado en UEFI recibe soporte «best-effort», es decir, sin garantías totales pero funcional en la mayoría de casos. El problema llega con las placas de desarrollo más populares del mercado: los SBC que dependen únicamente de device tree, como la Raspberry Pi, quedan fuera de la lista oficial, ya que el sistema exige que el equipo arranque mediante UEFI y describa su hardware a través de ACPI en lugar del árbol de dispositivos tradicional usado en el ecosistema Arm embebido. Esta exigencia técnica no es un capricho: es la misma que utiliza la arquitectura x86 desde hace décadas, y estandarizarla en Arm facilita que Proxmox trate ambas arquitecturas con el mismo código base sin necesidad de mantener dos rutas de arranque completamente distintas.

Esto no significa que la Raspberry Pi quede completamente descartada. De hecho, ya existe un puerto UEFI+ACPI para la Raspberry Pi 4 que se lleva gestando desde 2020, tal y como puede consultarse en este artículo técnico sobre firmware UEFI/ACPI para Raspberry Pi 4, pensado originalmente para lograr la certificación SBBR (Server Base Boot Requirements). Algunos usuarios ya han conseguido instalar Proxmox VE 9.2 tanto en una Raspberry Pi 4 como en una Raspberry Pi 5 siguiendo pasos manuales de instalación, saltándose el paso del kernel propio de Proxmox y desactivando NetworkManager, según relata un usuario de YouTube identificado como jonny en un comentario recogido en un vídeo dedicado al tema. Según su experiencia, logró levantar dos máquinas virtuales con AlmaLinux, una con entorno de escritorio y otra en modo servidor, sin apreciar ningún tipo de lag dentro de las VM. Para quien quiera intentarlo por su cuenta con firmware UEFI de verdad, existe también un port de EDK2 pensado específicamente para la Raspberry Pi 5, disponible en el repositorio rpi5-uefi de GitHub.

Diferencias técnicas frente a la versión x86

Aunque el objetivo de Proxmox es que la experiencia sea prácticamente idéntica entre arquitecturas, existen varias diferencias que conviene conocer antes de migrar una infraestructura. Las máquinas virtuales arrancan siempre a través de UEFI, en este caso mediante la implementación Arm de OVMF conocida como AAVMF, ya que SeaBIOS —el firmware heredado habitual en x86— no está disponible en aarch64. Tecnologías específicas de x86 como el cifrado de memoria AMD SEV o las vGPU mediadas de Intel GVT-g quedan fuera del ecosistema Arm por motivos obvios de dependencia de silicio. Tampoco existe, de momento, un paquete de microcódigo a nivel de sistema operativo equivalente a intel-microcode o amd64-microcode, lo que en la práctica traslada la responsabilidad de las actualizaciones de firmware al propio fabricante de la placa. Por último, un detalle relevante para quien gestione clústeres mixtos: los invitados solo pueden ejecutarse en nodos que coincidan con su arquitectura, y la migración en vivo únicamente es posible entre nodos de la misma familia de procesador, así que no hay forma de mover una VM de un nodo x86 a uno Arm sin pasar por una migración offline.

El papel de NVIDIA como impulsor del proyecto

Conviene detenerse en el producto que realmente ha empujado este desarrollo: la plataforma Mission Control de NVIDIA, orientada a la gestión integral de infraestructuras de IA a gran escala, entre las que se incluyen precisamente los servidores Grace Hopper y Vera. Estas plataformas combinan CPUs Arm de alto rendimiento con GPU de la propia NVIDIA en un mismo paquete, pensadas para entrenar e inferir modelos de inteligencia artificial con un ancho de banda de memoria muy superior al de los sistemas x86 tradicionales gracias a la interconexión NVLink-C2C. Que Proxmox haya recibido soporte oficial en Arm no es tanto una decisión estratégica del proyecto por diversificar su base de hardware, sino más bien una consecuencia directa de que NVIDIA necesitaba un hipervisor de código abierto capaz de gestionar sus «fábricas de IA» basadas en Arm, tal y como puede leerse con más detalle en el comunicado oficial de Proxmox sobre su colaboración con NVIDIA. Esto explica por qué el soporte «completo» se limita a este hardware muy concreto mientras el resto del ecosistema Arm se queda en una categoría de compatibilidad más laxa.

Reflexiones finales

Este anuncio confirma una tendencia que lleva tiempo consolidándose en el sector: Arm ya no es solo la arquitectura de los dispositivos embebidos y móviles, sino que está ganando terreno serio en el centro de datos, empujada en buena parte por la demanda de infraestructura para inteligencia artificial. El caso de Proxmox es especialmente interesante porque no nace de una petición generalizada de la comunidad de homelabbers, sino de una necesidad muy concreta de un cliente corporativo como NVIDIA, lo que probablemente explica por qué el soporte para placas de aficionados como la Raspberry Pi sigue siendo, de momento, un esfuerzo de la comunidad y no una prioridad oficial. Aun así, disponer de una base de código común entre x86 y Arm es una excelente noticia a medio plazo: cuantos más fabricantes de hardware sigan el estándar UEFI+ACPI en sus placas, más fácil será que terminen recibiendo soporte oficial, y no sería extraño ver en el futuro más SBC orientados a servidores adoptando este enfoque en lugar del clásico arranque por device tree. Quien quiera curiosear con esta primera versión puede descargar el instalador ISO de Proxmox VE 9.2 para Arm directamente desde la web oficial del proyecto.