Render 3D editorial de tarjetas aceleradoras GPU instaladas en un chassis de servidor abierto, sobre fondo verde menta luminoso, sin texto ni logotipos

OpenShift Virtualization 4.22: NVIDIA lo certifica como hipervisor

Q: ¿Cómo verifico que la GPU quedó asignada de verdad a mi máquina virtual?

Desde adentro del guest: ejecuta nvidia-smi en la VM. Si la GPU no aparece ahí, la asignación no ocurrió. Del lado del clúster, revisa que el nodo tenga la etiqueta de capacidad de GPU y que el pod virt-launcher exista. Si el driver funciona en el nodo pero no en la VM, el problema está en la configuración de dispositivos del HyperConverged o en la definición de la VM.

octubre 26, 2026 Alfonso Moreno | Sysadmin Senior 2 Visitas 14 min de lectura

Me llega la noticia y lo primero que hago es leerla dos veces, porque “una plataforma se certificó” suena a comunicado de marketing y a la vez puede ser un cambio de fondo para quien administra clústeres con GPU. La noticia concreta: Red Hat anunció que OpenShift Virtualization 4.22 ya aparece en la lista oficial de NVIDIA-Certified Hypervisors, junto a vSphere 9.1, OpenNebula 7.2.1, Mirantis k0rdent y Rafay. Red Hat la presenta como una de las plataformas de virtualización nativas de Kubernetes pioneras en ese programa, y eso tiene consecuencias prácticas que van más allá del titular.

Antes de emocionarte: esto no es “una GPU cualquiera en tu servidor”. La certificación cubre una configuración muy específica, con hardware de plataforma HGX y ocho GPU SXM por nodo, y solo aplica a la configuración exacta que NVIDIA validó. Aun así, entender qué se certificó, qué no, y por qué KubeVirt terminó en esa lista te dice mucho sobre dónde está la virtualización con GPU en 2026. Eso es lo que vamos a desarmar abajo.

TL;DR — Lo que vas a tener al final

Tiempo de setup: el anuncio es de Red Hat del 21 de octubre de 2026. OpenShift Container Platform 4.22 llegó a disponibilidad general el 9 de junio de 2026 y OpenShift Virtualization 4.22.0 va en el canal stable del mismo ciclo.
Requisitos: plataforma NVIDIA HGX con ocho GPU SXM (la entrada de Red Hat está certificada sobre Hopper SXM), GPU en passthrough completo y NIC en passthrough. La fase multi-nodo de dos máquinas virtuales de ocho GPU es obligatoria para aprobar en el track x86.
Resultado: tu clúster puede correr máquinas virtuales con GPU y workloads en contenedores sobre la misma API de Kubernetes, sin mantener dos plataformas separadas ni una segunda pila de virtualización clásica.
Troubleshooting: la certificación es de configuración, no de producto. NVIDIA y Red Hat coinciden en que no garantiza rendimiento en tu workload ni en producción. Si te falla, el problema más común no es KubeVirt: es el operador de NVIDIA sin desplegar, o la VM sin el dispositivo de GPU asignado.

Qué es OpenShift Virtualization y por qué de repente importa

OpenShift Virtualization es la capa de virtualización de máquina virtual que Red Hat integra dentro de OpenShift. No es un hipervisor propio: es KubeVirt, un proyecto de la CNCF, corriendo sobre KVM, con libvirt y qemu por debajo. La diferencia con KVM desnudo no está en el hipervisor, sino en el modelo operativo: la máquina virtual se declara como un recurso declarativo y el operador la materializa como un pod.

Ese detalle es el que cambia todo cuando metes GPU de por medio. En el flujo tradicional tienes un hypervisor de VMs y un orquestador de contenedores, dos equipos distintos, dos APIs distintas y dos caminos distintos para escalar. Con KubeVirt el virt-controller observa un objeto de instancia de máquina virtual y crea el pod correspondiente; ese pod, que se llama virt-launcher, es el que contiene la VM ejecutándose bajo libvirt y qemu. La VM vive dentro del clúster, no al lado del clúster.

Los objetos que vas a encontrar en el clúster son los CRD de KubeVirt: VirtualMachine y VirtualMachineInstance en el grupo kubevirt.io/v1, VirtualMachineInstanceMigration para la migración en caliente, DataVolume en cdi.kubevirt.io/v1beta1 para el aprovisionamiento de discos y HyperConverged en hco.kubevirt.io/v1 como configuración global del stack. Si vienes de un virtctl en un clúster de Kubernetes plano, esto te va a sonar familiar.

Qué certificó NVIDIA exactamente

El programa NVIDIA-Certified Hypervisors es, pese al nombre, un programa de rendimiento. No certifica soporte, ni compatibilidad, ni que el producto “sea bueno”. NVIDIA define cuatro ejes de validación, y son la definición más precisa de lo que Red Hat obtuvo con esta certificación:

Asignación de GPU: la GPU debe llegar completa a la máquina virtual, no emulada ni recortada.
Visibilidad de topología: el hipervisor debe exponer correctamente la topología de GPU, NIC, NVLink, NVSwitch, PCIe y NUMA hacia el guest.
Localidad del data path: las rutas de datos entre GPU y NIC, incluyendo GPUDirect RDMA, deben tener la localidad que NVIDIA define como esperada.
Línea base de software de NVIDIA: la suite de drivers, firmware y componentes que sustenta todo lo anterior.

Eso se evalúa con las pruebas de topología, benchmarks de plataforma, pruebas de fabric GPU y pruebas de rendimiento de workloads de IA representativos. El detalle que casi nadie menciona: el alcance actual del programa es únicamente GPU passthrough. vGPU for Compute está descrito como cobertura futura, no como cobertura vigente. Si tu caso de uso es compartir una GPU entre varios tenants con vGPU, esta certificación no te cubre.

El track de Red Hat es el de x86 con plataforma Hopper SXM: un nodo con ocho GPU SXM sobre plataforma HGX, con passthrough completo de GPU y de NIC. Para aprobar en ese track, la fase multi-nodo es obligatoria, es decir, dos máquinas virtuales de ocho GPU en nodos distintos. Eso es una prueba de estructura real, no una maqueta de laboratorio.

La lista completa de hipervisores certificados

La lista oficial de NVIDIA tiene seis plataformas en dos tracks. El de x86 usa HGX con Hopper SXM; el de Arm usa GB200 NVL con Grace Blackwell. Esta es la lista tal cual aparece en la documentación de NVIDIA, con el nombre exacto de cada entrada:

Plataforma	Fabricante	Track	Plataforma NVIDIA
Red Hat OpenShift Container Platform 4.22 with OpenShift Virtualization 4.22	Red Hat	x86	Hopper SXM
VMware vSphere 9.1	VMware	x86	Hopper SXM
Rafay-powered VMaaS 3.1	Rafay	x86	Hopper SXM
Mirantis k0rdent AI Osprey	Mirantis	Arm	Grace Blackwell
OpenNebula 7.2.1	OpenNebula Systems	Arm	Grace Blackwell
Rafay-powered VMaaS 3.1	Rafay	Arm	Grace Blackwell

Dos cosas saltan a la vista. La primera: Nutanix AHV, SUSE, Microsoft Hyper-V y Xen no aparecen en la lista, aunque son hipervisores mucho más establecidos en el mercado que KubeVirt. La segunda: el nombre de la entrada de Red Hat no es “KubeVirt”, es la cadena completa “OpenShift Container Platform 4.22 with OpenShift Virtualization 4.22”. Quien certifica es el producto de Red Hat, no el proyecto de CNCF por separado. KubeVirt sigue siendo el motor, pero la certificación es del stack comercial que lo envuelve.

Verificar tu clúster antes de instalar nada

Antes de tocar el operador de virtualización, confirma en qué versión de OpenShift estás y si el stack base está sano. oc get clusterversion te da la versión de la plataforma y el estado de los operadores de cluster, que es donde se esconden los problemas de despliegue: un MachineConfigPool en degradado o un ingress que no converge bloquean la instalación de cualquier operador.

oc get clusterversion
oc get clusteroperator

Si clusterversion te muestra una versión anterior a 4.22, la ruta del anuncio no aplica todavía para tu clúster y conviene revisar el plan de actualización antes de tocar nada. Si todavía no manejas Kubernetes, la guía de instalación con kubeadm te da el orden de un clúster de un solo nodo, aunque la ruta de producción que importa aquí es otra.

Instalar OpenShift Virtualization 4.22

La instalación es por OperatorHub, pero verificarla desde la terminal es obligatoria antes de declarar el cluster listo. El operador vive en el namespace openshift-cnv y su CSV se llama kubevirt-hyperconverged-operator.v4.22.0. Estos tres comandos te dicen si quedó desplegado y qué CRD quedaron registrados:

oc get csv -n openshift-cnv
oc get kubevirt -n openshift-cnv
oc get crd | grep kubevirt.io

El objeto HyperConverged que devuelve el segundo comando es tu punto de control global: es ahí donde se configuran las características de la plataforma, incluyendo la parte de dispositivos mediated. Si ese objeto no existe, el operador quedó instalado pero no inicializado, y ninguna VM va a arrancar.

Habilitar las GPU con el NVIDIA GPU Operator

OpenShift Virtualization te da el plano de control de la máquina virtual. El plano de datos de la GPU lo aporta el NVIDIA GPU Operator, que es un operador de Kubernetes bajo licencia Apache 2.0 que automatiza la gestión de todos los componentes de NVIDIA necesarios para aprovisionar GPU: los drivers que habilitan CUDA, el device plugin de GPUs para Kubernetes, el NVIDIA Container Toolkit, el etiquetado automático de nodos usando GFD, y el monitoreo basado en DCGM. La versión soportada actual es la serie 26.7.x, con matriz de soporte que cubre OpenShift 4.18 a 4.22 sobre Red Hat Core OS.

oc get clusterpolicy
oc get pods -n nvidia-gpu-operator

El recurso ClusterPolicy es el objeto de configuración del operador, y su nombre por defecto es gpu-cluster-policy. Todo lo que el operador hace por debajo se declara ahí, incluyendo la versión de driver que se despliega en los nodos. Si cambias la política, el operador reconcilia los daemonsets y los pods en los nodos elegibles.

Una vez desplegado, la prueba de fuego es ver el driver funcionando dentro del pod del driver, no en el host. Este comando te muestra la salida real de nvidia-smi desde el contenedor del driver, con el nombre del pod que devuelve el comando anterior:

oc get pods -n nvidia-gpu-operator
oc exec -n nvidia-gpu-operator nvidia-driver-daemonset-abcde -- nvidia-smi

El pod que te importa es el daemonset del driver, uno por nodo con GPU. Si en ese nvidia-smi no ves las ocho GPU listadas, el problema está en el nodo o en la política, no en KubeVirt.

Confirmar que el nodo expone la GPU

Antes de crear máquinas virtuales, verifica que el nodo es elegible y que reporta capacidad de GPU. Esta es la información que el planificador de Kubernetes usa para decidir dónde se hace la asignación, y es la que aparece en el campo de capacidad asignable del nodo:

oc get nodes -o wide
oc describe node gpu-worker-01 | grep -i nvidia

Lo que buscas en el detalle del nodo es la etiqueta que el GPU Operator inyecta para marcar capacidad de GPU, y los recursos asignables con la extensión de vendor de NVIDIA. Si la etiqueta no está, el nodo no es candidato y el planificador nunca lo va a elegir para una VM con GPU.

Crear y operar máquinas virtuales con GPU

Una vez que el operador está bien, las VMs se manejan con virtctl contra el namespace donde vive el recurso. Este es el flujo básico de ciclo de vida: listar, arrancar, reiniciar y detener. virtctl habla con el mismo API de Kubernetes por debajo, así que en un clúster de producción lo normal es que la VM se aplique como manifiesto y virtctl se reserve para la operación interactiva.

oc get vm -n demo
virtctl start fedora-gpu --namespace demo
virtctl restart fedora-gpu --namespace demo
virtctl stop fedora-gpu --namespace demo

Para verificar que la VM realmente quedó viva, mira los pods y las instancias, no solo el objeto VirtualMachine. El pod virt-launcher es el que lleva la GPU; el estado de la instancia te dice si corrió de verdad:

oc get pods -n demo -l kubevirt.io/domain=demo
oc get vmi -n demo -o wide

Y la prueba de que la GPU quedó asignada de verdad, adentro del guest, se hace desde la propia VM. Si nvidia-smi no lista la GPU dentro del sistema operativo de la VM, la asignación no ocurrió y el problema es de mediatedDevicesConfiguration en el objeto HyperConverged o de la definición de la VM, no del driver.

Migrar una VM con GPU en caliente

Este es el punto fuerte de KubeVirt frente a un hipervisor tradicional: la migración en caliente con la VM en ejecución, porque la VM es un pod y los pods se mueven. El recurso VirtualMachineInstanceMigration orquesta el traslado y la verificación de memoria y estado del dispositivo entre nodos. La migración se solicita con virtctl migrate y se sigue desde el estado de la instancia:

virtctl migrate fedora-gpu --namespace demo
oc get vmi -n demo -o wide

En una VM con GPU en passthrough la migración entre nodos es el escenario más exigente: la GPU tiene que estar disponible en el nodo destino con la misma topología, y por eso NVIDIA exige la fase multi-nodo en la certificación. Si la migración falla, casi siempre es porque los dos nodos no exponen la misma topología de GPU y NVSwitch.

Lo que la certificación no cubre

Aquí es donde conviene bajar el entusiasmo, porque la propia documentación de NVIDIA y el anuncio de Red Hat lo dicen con claridad: la certificación aplica solo a la configuración validada por NVIDIA, contra las suites de prueba definidas por ellos, para las configuraciones probadas. No garantiza rendimiento para workloads específicos de clientes ni para entornos de producción. Red Hat lo repite en su comunicado. Y el soporte de producto, ante incidencias, va al fabricante del hipervisor, no a NVIDIA.

Segundo límite: el alcance es passthrough. Si estabas pensando que esto habilita vGPU para compartición multi-tenant, el programa dice que eso es cobertura potencial futura, no actual. Tercero: la entrada de Red Hat es del track x86 con Hopper SXM, así que la afirmación de que “OpenShift Virtualization está certificado en Blackwell o en GB200 NVL72” es falsa. Esas plataformas corresponden al track Arm, donde están Mirantis, OpenNebula y Rafay.

Y un detalle de maduración que vale la pena saber: KubeVirt está en la CNCF desde el 6 de septiembre de 2019, y pasó a nivel Incubating el 19 de abril de 2022. No está graduado. Eso no lo hace menos sólido, pero es el estado real del proyecto del que depende toda la plataforma.

¿Vale la pena? La opinión de alguien que administra servidores pequeños

Si tienes uno o dos servidores y una GPU de consumo, la respuesta corta es no, y no por calidad del software sino por la escala del hardware que exige la certificación. HGX con ocho GPU SXM es infraestructura de centro de datos. Comprar una placa de escritorio para “entrar en la lista” no te deja en la lista.

Donde sí cambia la ecuación es en organizaciones que ya tienen OpenShift y ya compran GPU: ahí el valor real no es el logo de la certificación, es poder correr la VM heredada con GPU y el workload de IA en contenedores sobre el mismo clúster, con la misma API y el mismo equipo. El valor de consolidar dos pilas de virtualización en una sola es la clase de ahorro que justifica este tipo de plataforma, y la certificación NVIDIA es la prueba técnica de que el camino de datos no se degrada al virtualizar.

Mi recomendación práctica: si estás evaluando KubeVirt por la certificación, no la uses como criterio. Usa KubeVirt si ya tienes OpenShift y quieres consolidar VM y contenedores, porque ahí el modelo operativo gana por sí solo. Y si lo que te interesa es específicamente mover una GPU entre máquinas virtuales, mira primero la alternativa mucho más simple que ya documenté sobre el passthrough de PCI en Proxmox, que resuelve el mismo problema con menos capas y sin clúster de Kubernetes.

Preguntas frecuentes

¿Qué necesito para aprovechar la certificación en mi clúster?

Plataforma NVIDIA HGX con ocho GPU SXM por nodo, GPU y NIC en passthrough completo, y la topología de NVLink y PCIe que NVIDIA define para la configuración validada. La entrada de Red Hat está certificada en el track x86 con Hopper SXM, no en Blackwell ni en GB200 NVL72. Con una GPU de consumo en un servidor propio no cumples el perfil de hardware que la certificación cubre.

¿La certificación garantiza que mi workload de IA va a rendir lo mismo?

No. NVIDIA y Red Hat lo dicen de forma explícita: la certificación valida contra las suites de prueba definidas por NVIDIA para la configuración probada, y no garantiza rendimiento para workloads específicos de clientes ni para entornos de producción. Para tus números reales necesitas tu propia prueba de concepto con tu modelo, tu batch size y tu configuración de memoria.

¿Cómo verifico que la GPU quedó asignada de verdad a mi máquina virtual?

Desde adentro del guest: ejecuta nvidia-smi en la VM. Si la GPU no aparece ahí, la asignación no ocurrió. Del lado del clúster, revisa que el nodo tenga la etiqueta de capacidad de GPU y que el pod virt-launcher exista. Si el driver funciona en el nodo pero no en la VM, el problema está en la configuración de dispositivos del HyperConverged o en la definición de la VM.

¿Puedo usar vGPU o compartir una GPU entre varias máquinas virtuales?

No con esta certificación. El alcance vigente del programa NVIDIA-Certified Hypervisors es exclusivamente GPU passthrough: la GPU completa llega a una sola VM. vGPU for Compute aparece en la documentación como cobertura potencial futura, no como parte del alcance actual. Para compartición multi-tenant de GPU existen caminos de vGPU en la plataforma, pero no están cubiertos por esta certificación.

¿Migrar una máquina virtual con GPU en caliente funciona igual que una sin GPU?

Es más exigente. La VM es un pod y el pod se mueve, pero en passthrough la GPU tiene que estar disponible en el nodo destino con la misma topología, y por eso la fase multi-nodo de dos VMs de ocho GPU es obligatoria para aprobar la certificación en el track x86. Si la migración falla, revisa primero que ambos nodos expongan la misma topología de GPU y NVSwitch.