RHEL for NVIDIA 26.03: soporte día cero para GPUs NVIDIA en clústeres Linux

Red Hat publicó en octubre un análisis de la versión 26.03 de RHEL for NVIDIA, liberada el 29 de septiembre, y la forma más rápida de resumirla es decir que es RHEL con tres paquetes cambiados. Suena demasiado simple para ser una noticia, pero es exactamente lo que es: un kernel, un QEMU y un libvirt reempaquetados para que la GPU más nueva de NVIDIA funcione el día que sale, no seis meses después.

Lo que me interesa es lo que ese cambio de tres paquetes arrastra detrás. Es una edición con un modelo de soporte radicalmente distinto al de RHEL normal: sin retroparches, con una sola versión viva a la vez, y con una puerta de salida de vuelta a RHEL principal que Red Hat vende como fluida pero la propia documentación de la release describe como potencialmente rompiente. Eso lo hace un tema mucho más interesante de lo que parece un anuncio de hardware, y vale la pena entenderlo bien antes de que alguien en tu equipo lo proponga para producción.

Qué es RHEL for NVIDIA y por qué existe

LaNVIDIA publica hardware en un ciclo más rápido del que cualquier distribución de Linux puede absorber. Cuando llega una GPU nueva, hay tres cosas que tienen que existir en el sistema operativo antes de que esa GPU sirva de algo: el driver de kernel con soporte para la arquitectura nueva, el soporte de virtualización para exponerla a una máquina virtual, y una cadena de compiladores capaz de producir el módulo.

En un kernel upstream, eso significa esperar a que el código se acepte, se revise y se integre. Con la cadencia actual de NVIDIA, ese ciclo de espera puede ser de varios trimestres. Mientras tanto, quien recibe el rack nuevo tiene tres opciones malas: esperar con el hardware en la caja, montar el primer clúster sobre un sistema operativo que el equipo no piensa mantener, o construir un kernel a mano y perder el soporte enterprise por el camino.

RHEL for NVIDIA existe para resolver ese tercero. Es una edición de RHEL 10 optimizada por Red Hat y NVIDIA en conjunto que llega a la plataforma antes de que ese código suba al kernel principal. Se distribuye dentro de la suscripción activa de RHEL for ARM 64 y no es un producto separado ni un fork permanente: es RHEL con un conjunto acotado de paquetes modificados.

La diferencia crítica, y la que hay que entender bien antes de instalar nada, es que ese “conjunto acotado” son exactamente tres paquetes: kernel, qemu-kvm y libvirt. Todo lo demás, desde bash hasta systemd hasta el stack de contenedor, es idéntico a RHEL 10.2. Los tres paquetes alterados llegan por un repositorio dedicado, el Red Hat Enterprise Linux 10 for ARM 64 - Nvidia (RPMs), identificado como rhel-10-for-aarch64-nvidia-rpms.

RHEL for NVIDIA 26.03 frente a RHEL 10: las diferencias que importan

Antes de decidir nada, conviene ver las diferencias en una sola pantalla. La documentación de Red Hat publica una tabla bastante cruda sobre cómo se aparta esta edición del comportamiento estándar de RHEL, y es la tabla que deberías leer, no el blog de marketing.

Política	RHEL 10 estándar	RHEL for NVIDIA
Duración del ciclo de vida	Compromiso estándar de 10 años	Corto: solo la versión más reciente está soportada
Esquema de versionado	Mayor y menor, por ejemplo 10.1, 10.2	Año.Iteración, por ejemplo 26.01, 26.02
Cadencia de publicación	Mayor cada 3 años, menor cada 6 meses	Trimestral y asíncrona, alineada con el hardware de NVIDIA
Retroparches	Continuos, también en streams EUS	Solo hacia adelante: los fixes van a la versión vigente y a ninguna anterior
Estabilidad de ABI y API	Garantizada dentro de la versión mayor	Sin garantías: actualizar o volver a mainline puede romper cosas
Madurez del código	Debe aceptarse upstream antes de integrarse	Usa CentOS Stream AIE para importar parches fuera de árbol de NVIDIA antes de esa aceptación
Casos de uso	Despliegues enterprise estables y amplios	Habilitación de hardware día cero, POC de OpenShift, OpenShift Virtualization y AI Factory

Fíjate en la fila de retroparches y en la de estabilidad de ABI. Son las dos que cambian cómo operas el día que algo sale mal a las dos de la mañana. En RHEL normal, un fix de seguridad crítico llega a todas las versiones soportadas. En RHEL for NVIDIA, un CVE crítico solo se entrega a la versión que está vigente cuando se publica, y cuando sale la siguiente versión, la anterior deja de recibir parches de kernel, sin excepciones. Eso es exactamente lo que significa forward-only, y es un cambio de contrato, no un detalle de empaquetado.

Hay un matiz importante que la tabla de arriba no muestra y que conviene tener claro: la regla de “solo CVE críticos” aplica a los paquetes impactados, es decir kernel, qemu-kvm y libvirt. Los paquetes que vienen de BaseOS, AppStream, Code-Ready Builder, Extensions y Supplementary siguen el ciclo de vida normal de RHEL y sí reciben los fixes de mainline a medida que se resuelven allí. Es decir: tu Firefox sigue parcheándose igual que en cualquier RHEL, pero el kernel se mueve solo hacia adelante.

El modelo de soporte: por qué esto no es RHEL de verdad

RHEL for NVIDIA se ofrece bajo la designación Partner Validated. Red Hat toma los casos de soporte y da asistencia L1 y L2, pero el modelo es un esfuerzo conjunto que depende fuerte de NVIDIA para validar y resolver problemas. La definición oficial de qué significa ese soporte es bastante cruda y conviene tenerla presente: la versión actual funciona sobre el hardware actual.

En cifras, la cadencia es esta: 26.03 salió el 29 de septiembre de 2026 y su fecha de fin de vida es el 12 de enero de 2027. La 26.02, publicada el 30 de junio de 2026, dejó de soportarse el mismo 29 de septiembre de 2026. Cuando sale una versión nueva, la anterior deja de recibir parches de kernel y de virtualización de forma inmediata.

Eso significa que operas una versión con fecha de caducidad. No es un problema si tu plan es saltarla al ritmo de las publicaciones trimestrales. Es un problema muy serio si tu plataforma de GPU se va a quedar en pie dos años: para ese caso, el hardware que no habías actualizado se queda sin soporte de kernel en un plazo corto.

Preparar el host: repositorio, page size y virtualización

El primer paso no es instalar nada, es instalar el sistema correcto. La ISO se descarga del portal de clientes en la sección de RHEL for ARM 64, y hay un paso que mucha gente pasa por alto: durante la instalación, en el resumen, hay que omitir el registro de suscripción. Si te registras durante el instalador, el sistema queda apuntando a los repositorios estándar y no al repositorio de NVIDIA.

Después de instalar, te registras y habilitas el repositorio a mano. Este bloque te deja el host con el repo de NVIDIA activo y las herramientas de virtualización listas:

subscription-manager register
subscription-manager repos --enable=rhel-10-for-aarch64-nvidia-rpms
dnf install virt-install libvirt-daemon-kvm libvirt-daemon-config-network

La verificación importa por dos razones. La primera es que RHEL for NVIDIA exige un tamaño de página de 64 KiB, y eso no es negociable: es una decisión del kernel, no un ajuste de rendimiento. Si getconf PAGESIZE no devuelve 65536, el host no cumple el requisito y las VM con GPU van a fallar más adelante, cuando ya tienes el rack montado.

getconf PAGESIZE
virt-host-validate

La segunda razón es práctica: virt-host-validate te dice si el host tiene lo necesario para virtualizar. Si muestra WARN o FAIL en algún chequeo, ese es el momento de resolverlo, no después de asignar la GPU a una VM.

Hay un prerrequisito de firmware que no aparece en la mayoría de resúmenes: el SBIOS de tu plataforma debe anunciar el flag de acceso a memoria ACPI IORT CANWBS, disponible desde SBIOS v02.03.xx de NVIDIA en adelante. Si el firmware está más viejo, el acceso a memoria para las VM con GPU no va a funcionar aunque todo lo demás esté en su sitio.

Instalar los drivers NVIDIA firmados por Red Hat

Acá está la diferencia práctica frente a un kernel genérico. RHEL for NVIDIA no usa el driver que descargas a mano de la página de NVIDIA: usa drivers construidos y firmados por Red Hat, tanto la variante OpenRM como la de CUDA, con soporte para Grace Hopper, Grace Blackwell y las plataformas que vengan después. Esos drivers llegan por el mismo repositorio de NVIDIA, así que el flujo es el de siempre.

Red Hat además provee rhel-drivers, una herramienta de gestión de drivers que ofrece una experiencia simplificada para el hardware NVIDIA y te da un solo comando coherente con el modelo de la distribución.

dnf install rhel-drivers
rhel-drivers install nvidia
reboot

Tras el reinicio, nvidia-smi es el verificador honesto. Si muestra el detalle de la GPU y la versión del driver, la instalación funcionó. Si no muestra nada, el módulo no cargó y el siguiente paso es mirar el ring buffer del kernel, no reinstalar a ciegas.

nvidia-smi

Habilitar HugeTLB y EGM: la memoria contigua que exige el passthrough

Acá viene la parte que nadie menciona en los resúmenes y que es la causa número uno de fallos en el passthrough. Si quieres usar la virtualización de colas de comandos, la VM necesita estar respaldada por memoria contigua a nivel de host. Hay dos mecanismos para conseguirla y se eligen según la plataforma.

El primero son las páginas HugeTLB, que se configuran en el arranque porque el kernel no puede reasignarlas en caliente. El tamaño y la cantidad dependen de tu memoria y de la carga, y el ejemplo de la documentación arranca con 64 páginas de 512 MiB:

grubby --update-kernel=ALL --args="hugepagesz=512M default_hugepagesz=512M hugepages=64"
reboot
grep HugePages /proc/meminfo

Si HugePages_Total devuelve 64, las páginas se asignaron bien. Si devuelve cero, el parámetro no llegó al kernel: casi siempre es porque grubby se ejecutó sin permisos o porque la memoria contigua pedida no está disponible y el kernel la rechaza en silencio.

El segundo mecanismo es EGM, Extended GPU Memory, que la 26.03 documenta como alternativa a HugeTLB. A diferencia de las HugeTLB, EGM reserva la memoria para las máquinas virtuales y el host no puede usarla, pero la GPU puede acceder a ella dentro y entre nodos NUMA, que es lo que realmente importa en cargas multi-nodo. EGM se habilita en el firmware y después se carga un módulo de kernel:

modprobe nvgrace_egm
echo "nvgrace_egm" > /etc/modules-load.d/nvgrace_egm.conf
lsmod | grep nvgrace_egm

Un detalle con trampa: en el firmware hay que dejar el valor por defecto de memoria reservada para el hipervisor por socket en 32768. Cambiarlo en plataformas Grace Hopper causa problemas conocidos. Es el mismo tipo de trampa que al preparar el hardware del host en el passthrough de GPU sobre Proxmox: el conflicto real aparece en la configuración de memoria del lado del host, no en la máquina virtual.

Passthrough de GPU: del host a la máquina virtual

Con los drivers instalados y la memoria contigua resuelta, el siguiente paso es exponer la GPU a una VM. Hay dos caminos: el gestionado, con managed='yes' en la definición de la VM, donde libvirt se encarga de la.binding; y el manual, que conviene cuando la GPU se asigna estáticamente a una VM concreta, porque el binding manual sobrevive a los reinicios de la VM.

El camino manual empieza descargando el driver nouveau y cargando el driver de passthrough de NVIDIA para Grace:

modprobe -r nouveau
modprobe nvgrace-gpu-vfio-pci
DEVICE_ID=$(lspci -s $(lspci | grep -i "3D controller" | awk '{print $1}' | head -1) -n | awk '{print $3}' | tr ':' ' ')
echo "$DEVICE_ID" | tee -a /sys/bus/pci/drivers/nvgrace_gpu_vfio_pci/new_id

Si prefieres que virsh haga el trabajo, el equivalente es localizar la dirección PCI de la GPU y desacoplarla del host. En una plataforma Grace la controladora aparece como 3D controller:

lspci | grep "3D"
virsh nodedev-detach pci_0009_01_00_0

La verificación final confirma que el driver de kernel en uso es el de passthrough y no el de NVIDIA:

lspci -k -s 0009:01:00.0 | grep "Kernel driver"
ls /dev/egm*
cat /sys/class/egm/egm/egm_size*

Si la línea dice nvgrace_gpu_vfio_pci, la GPU quedó bien atada. Y ojo con este detalle que sorprende: una vez que la GPU está atada al driver VFIO y pasada a una VM, nvidia-smi en el host deja de reportar estadísticas para ese dispositivo. No es un fallo, es el comportamiento esperado, y para monitorear el uso de la GPU tienes que entrar a la VM y usar nvidia-smi dmon o nvidia-smi pmon desde adentro.

Diagnóstico: qué mirar cuando el passthrough falla

Cuando algo falla en esta edición, la documentación es sorprendentemente práctica y de las pocas que te dicen exactamente qué comando correr. El primer filtro es el log del kernel filtrado por el driver de NVIDIA, donde los errores del driver aparecen con prefijo NVRM:

dmesg | grep -iE 'nvrm|nvidia'

El segundo es nvidia-bug-report.sh, que genera un archivo comprimido con el estado de la GPU, versiones de driver, logs del kernel y configuración del sistema. Ese archivo es lo que pegas en el caso de soporte, y es tanto a NVIDIA como a Red Hat. Armando el reporte a mano te ahorra una semana de idas y venidas en el soporte.

nvidia-bug-report.sh

Los problemas conocidos que te van a morder

La 26.03 publica tres problemas conocidos y vale la pena conocerlos antes de que te lleguen, porque dos de ellos se resuelven con configuración y no con un parche.

Crashes del GSP en vGPU sobre Grace Blackwell. Cuando corres cargas CUDA en una VM que usa vGPU passthrough, el GPU System Processor puede crashear. Las causas son dos: los límites de bloqueo de memoria del proceso QEMU son demasiado bajos, o varias VMs que usan IOMMUFD arrancan y solo la última queda con acceso al archivo /dev/iommu. El workaround es doble. Primero, un límite duro de memoria suficiente en el XML del dominio de libvirt, calculado como RAM de la VM más tamaño del perfil vGPU más BAR0 más BAR1:

<memtune>
  <hard_limit unit='GiB'>48</hard_limit>
</memtune>

Segundo, una etiqueta SELinux estática en el mismo XML para las VMs que usan iommufd, de modo que el proceso tenga permisos sin tener que desactivar SELinux:

<seclabel type='static' model='selinux' relabel='yes'>
  <label>system_u:system_r:svirt_t:s0:c392,c662</label>
</seclabel>

Las categorías MCS hay que reemplazarlas por los valores de tu instancia concreta. Y prestá atención a lo que esto significa en la práctica: la solución oficial para un crash de GPU es tocar la seguridad de la VM, no el driver. Desactivar SELinux sería la respuesta fácil y la que nadie debería dar en un servidor que aloja cargas de inferencia.

El vSMMU debe tener el mismo RIL que el SMMU. Hasta que QEMU se corrija, la unidad de gestión de memoria virtual del sistema tiene que compartir el valor de Range Invalidation Limit con su contraparte física. Si los dos RIL no coinciden, el passthrough falla de formas que parecen bugs del kernel, porque el síntoma aparece lejos de la causa. configura el RIL del vSMMU para que coincida con el del SMMU físico antes de habilitar la virtualización.

kdump no funciona con Secure Boot en ARM de 64 bits. El servicio kdump no arranca en sistemas ARM de 64 bits cuando Secure Boot está habilitado, porque el kernel no puede cargar la imagen en formato zboot ni verificar su firma durante el kexec. El workaround es desactivar Secure Boot. En un host de GPU con passthrough desactivado, esto tiene un impacto de seguridad real que hay que evaluar antes de aplicarlo a ciegas.

Lo nuevo en 26.03 que sí importa

La lista de novedades de la release es larga, pero si filtramos por lo que realmente cambia la operación diaria, quedan cuatro cosas.

Aceleración de networking con Spectrum-X en OpenShift. Es la novedad de mayor alcance. Con OpenShift corriendo sobre RHEL for NVIDIA y RHCOS, usando modo switchdev y offload de hardware de OVS-DOCA, el datapath de Open vSwitch se descarga directamente a los SuperNIC de NVIDIA (ConnectX-8, ConnectX-9 y BlueField-4). El resultado es un performance de alto throughput con 400G o más y latencias por debajo del microsegundo.

OVS-DOCA en GB300 y en Vera Rubin. En la 26.03, OVS-DOCA queda validado para plataformas Grace Blackwell 300 con adaptadores ConnectX-8, optimizado para las características de memoria y coherencia de caché del CPU Grace. Y hay soporte de OVS-DOCA sobre Vera Rubin con adaptadores ConnectX-9, que da un entorno de red transparente con la funcionalidad del Open vSwitch estándar pero aprovechando la aceleración por hardware. Ojo con el detalle: la validación de OVS-DOCA en la 26.03 es sobre GB300, no sobre GB200.

vGPU para Grace Hopper y Grace Blackwell. Una GPU física compartida entre varias máquinas virtuales, con capacidades de graphics y compute de alto rendimiento para entornos multi-tenant. Es la respuesta a la pregunta de cómo Rentender una GPU cara sin convertirla en un cuello de botella por afinidad.

GPU passthrough con SMMUv3 en Vera Rubin. A través de SMMUv3 compartido, virtualización de colas de comandos y la infraestructura de vEVENTQ, con correcciones sobre los ciclos anteriores para resolver cuelgues de VMs durante cargas CUDA.

Y en el terreno del particionado de recursos, MPAM agrega control fino de asignación de caché L3 y monitoreo de ocupación en tiempo real a través de la interfaz resctrl, con soporte avanzado también en Vera Rubin para distribuir caché y ancho de banda de memoria entre aplicaciones y VMs. Hay además soporte de CXL para interconexiones de alta velocidad en Vera Rubin, Live Firmware Activation para activar firmware nuevo sin el ciclo de reinicio, y BlueField-4 usable como interfaz de red estándar en modo NIC.

El off-ramp: cómo vuelves a RHEL principal

Este es el punto más importante del diseño y el que mejor se vende. Cuando el código de habilitación de hardware de NVIDIA se revisa, se acepta upstream y se integra en un RHEL estable, el camino de vuelta es borrar el repositorio de NVIDIA y hacer una actualización normal del sistema. No reinstalas, no migras a otro sistema operativo, te quedas en RHEL.

Y acá viene la parte que el blog de Red Hat no destaca con la misma claridad: la tabla de diferencias de la propia documentación dice que no hay garantías de compatibilidad hacia atrás y que migrar de vuelta a RHEL mainline puede causar roturas. El blog de Red Hat lo describe como una transición “sin fricción”; la tabla de la release, que es la que manda, usa un lenguaje mucho más cauto. Las dos son de Red Hat y ambas son correctas en su contexto, pero si tu plan de continuidad depende de que ese paso sea indoloro, plánéalo como un cambio de plataforma con su propia ventana de pruebas, no como un dnf update.

subscription-manager repos --disable=rhel-10-for-aarch64-nvidia-rpms
dnf update

El plan de pruebas que yo seguiría: un clúster de staging con la misma configuración de hardware, lo actualizas tú mismo al off-ramp y mides si las VMs con GPU siguen arrancando con el mismo rendimiento. Es más barato que descubrirlo durante un incidente.

Vale la pena? Mi lectura para homelab y para datacenter

Voy a separar las dos audiencias porque la respuesta es completamente distinta para cada una.

Si tienes un homelab con una RTX de escritorio, esto no es para ti. Y no es un matiz, es un bloqueo de arquitectura. RHEL for NVIDIA 26.03 se distribuye con kernel 6.12.0-259.26 y soporte para ARM de 64 bits (ARMv8.0-A). Las plataformas probadas son GH200, GB200 y GB300, todas Grace, más un sistema single-node de Vera Rubin. No hay build x86. Si tu GPU de escritorio es una GeForce o una RTX de workstation, la respuesta correcta sigue siendo RHEL 10 o Rocky/Alma normal con los drivers de NVIDIA de upstream, y el costo de la edición for NVIDIA no te aporta nada.

Sumado a que requiere una suscripción activa de RHEL for ARM 64, el costo total para un homelab es simplemente prohibitivo en términos de valor.

Si operas un datacenter con racks Grace Blackwell, la pregunta es otra: qué riesgo de plataforma estás aceptando. Y la respuesta es: estás aceptando un modelo de soporte donde el kernel deja de recibir parches cuando sale la versión siguiente, un soporte reducido a la definición de que la versión actual funciona con el hardware actual, y un off-ramp que la propia documentación marca como potencialmente rompiente.

El balance, en mi opinión, es razonable para cargas de inferencia en producción donde cada trimestre de retraso en la habilitación del hardware cuesta dinero real, y donde el equipo tiene el tamaño para operar un ciclo de actualización trimestral de la plataforma completa. No es razonable para un clúster que va a vivir varios años con la misma base de kernel, ni para equipos que no pueden sostener una cadencia de actualización de infraestructura cada trimestre.

Y un apunte que nadie hace: si tu plan a medio plazo es OpenShift u OpenShift Virtualization sobre NVIDIA, esto deja de ser una decisión de sistema operativo y pasa a ser una decisión de plataforma. OpenShift, OpenShift Virtualization y Red Hat AI publican sus propias releases construidas sobre RHEL for NVIDIA, y el soporte día cero llega por ese camino. En ese escenario, la edición no es algo que tú instalas: es la base sobre la que Red Hat construye los productos que ya vas a consumir.

Preguntas frecuentes

Lee también

• Optimiza redes de centro de datos: cómo liberar hasta 30% de CPU host con NVIDIA BlueField + OpenShift
• PCI passthrough en Proxmox: pasar una GPU o dispositivo PCIe a una VM
• Explorando RHCOS 10: la nueva era para sysadmins de OpenShift en Linux
• Home Lab para Agentes IA con Ollama y Proxmox en Producción: Respaldos, Observabilidad y Failover