# NVIDIA sube su vGPU a Nova y el kernel lo verá por entregas > El driver Rust de NVIDIA lleva la virtualización de GPU al kernel principal: parte entra en Linux 7.5 y el resto no llegará antes de 7.6. > Por José Maldonado · Tecnología · 2026-11-14 Una GPU de centro de datos cuesta lo que un coche y, sin virtualización, solo puede alimentar una máquina virtual a la vez. El truco para venderla por horas es partirla en trozos y repartirlos entre varios inquilinos, y en Linux esa función ha vivido siempre en código que NVIDIA distribuye aparte del kernel. En el KVM Forum 2026, celebrado esta semana en Vancouver, el ingeniero de NVIDIA Simon Song presentó el estado del trabajo para llevar la virtualización de GPU al kernel con [Nova, el driver escrito en Rust](https://www.phoronix.com/news/NVIDIA-Upstream-vGPU-Nova) que la compañía quiere convertir en su pila oficial. El anuncio no es una entrega cerrada. Song describió un esfuerzo en marcha que entra a trozos: más piezas del soporte de vGPU llegarán para Linux 7.5, y el manejo completo de la virtualización de GPU dentro del kernel no estará alineado antes de Linux 7.6 o posterior. La parte de espacio de usuario se cubre con las herramientas vgpu-tools, todavía en desarrollo, y funciones como la migración en vivo quedan para más adelante. El cambio para quien opera nube o escritorios virtuales tiene dos caras. El arranque se limpia y deja de depender de módulos propietarios compilados contra cada versión del kernel, pero la migración en vivo sigue pendiente y sin ella no hay traslado sin corte. ## La casilla que convierte una GPU en producto Una tarjeta gráfica física tiene memoria, colas de trabajo y un planificador pensados para un solo dueño. La virtualización de GPU pone una capa entre el hipervisor y ese hardware para que varias máquinas virtuales o contenedores se repartan los mismos núcleos, con cuotas de memoria y aislamiento entre ellas. Es la base técnica del escritorio virtual de una empresa y de la factura por minutos que paga quien alquila capacidad gráfica en la nube. NVIDIA construyó ese negocio con código que no estaba en el árbol del kernel. El módulo se instalaba aparte, había que recompilarlo cuando cambiaba la versión de Linux y la compatibilidad dependía de que el proveedor publicara una versión nueva a tiempo. Para un hipervisor casero es una molestia; para un centro de datos con miles de nodos y actualizaciones escalonadas, es un elemento más de la lista de cosas que se rompen un viernes por la tarde. La salida de Jensen Huang como consejero delegado, [anunciada por el consejo el 12 de noviembre de 2026](https://www.phoronix.com/news/NVIDIA-Jensen-Huang-Resigns) con la directora financiera Colette Kress como interina, no cambia esa hoja de ruta. El trabajo del driver viene de antes y se aprueba en la lista de correo del kernel, donde el cargo no hereda la firma de un mantenedor. Esa es la razón por la que el trabajo de Song importa más de lo que sugiere el título de una charla de foro. Cuando la virtualización está en el kernel, la distribución instala el soporte, el arranque es el mismo en todas las máquinas y las actualizaciones de seguridad no obligan a recompilar nada. La virtualización deja de ser un producto que se añade encima y pasa a ser una capacidad del sistema operativo, que es la diferencia entre tener un módulo más y tener una máquina que arranca igual que las demás. El efecto se mide en soporte y no en rendimiento. Una capacidad que vive en el árbol se documenta, se prueba junto al resto del kernel y se puede activar en una imagen de distribución sin pasos manuales ni compilaciones locales. ## Nova deja de ser un solo driver El proyecto se reparte en dos piezas con nombre propio. La [documentación del kernel sobre nova](https://docs.kernel.org/gpu/nova/index.html) describe dos drivers separados, nova-core y nova-drm, y explica que el conjunto aspira a sustituir a Nouveau en las GPU NVIDIA basadas en el procesador GSP. Nova-core es el driver de primer nivel: envuelve las interfaces de hardware y firmware de la tarjeta y sirve de base común a los drivers de segundo nivel. Ahí aparece la pieza que enlaza con la charla de Vancouver. Entre esos drivers de segundo nivel, el texto del kernel nombra el driver VFIO del gestor de vGPU junto a nova-drm. La virtualización no entra como un parche pegado al driver gráfico, sino como un consumidor de la misma base que usa el driver de pantalla, y el hipervisor la alcanza por la vía estándar de VFIO, la misma que ya se usa para pasar una tarjeta entera a una máquina virtual. La diferencia práctica está en cuántas veces se escribe el mismo código. Fuera del árbol, el gestor de vGPU y el driver gráfico repiten inicialización de firmware, manejo de interrupciones y arranque del procesador de la GPU. Con una base compartida, esa inicialización se revisa una vez en la lista de correo y la heredan los dos usos, el de escritorio y el de servidor, que es justo lo que necesita quien mantiene una imagen de sistema para ambas cosas. Conviene aclarar lo que Nova no hace. La documentación dice que aspira a sustituir a Nouveau, no que Nouveau desaparezca de un día para otro, y las GPU antiguas sin GSP quedan fuera de su alcance por ahora. ## El calendario, pieza a pieza El reparto que describió Song encaja con cómo se sube hardware nuevo al kernel: cada bloque entra cuando pasa revisión y el conjunto se alinea varios ciclos después. Esta es la foto que dejó el KVM Forum 2026, con lo que está en marcha y lo que aún no tiene ciclo asignado. Pieza Estado Cuándo Soporte de vGPU en el kernel sobre Nova En desarrollo Más bloques para Linux 7.5 Manejo completo de vGPU en el kernel Incompleto Linux 7.6 o posterior Herramientas vgpu-tools de espacio de usuario En desarrollo Sin fecha Migración en vivo de vGPU Pendiente Sin fecha vGPU heterogéneo y funciones avanzadas Pendiente Sin fecha Leída en frío, la tabla dice que el trabajo lleva un año en marcha y que el tramo difícil no es el de arrancar la tarjeta, sino el de coordinar estado entre hipervisor, kernel y firmware. Que falten varios ciclos para tenerlo todo alineado no es pesimismo: es lo que tarda un cambio que toca driver, hipervisor y herramientas a la vez, y que necesita la revisión de mantenedores que no trabajan para NVIDIA. El detalle de las herramientas de espacio de usuario ayuda a entender el reparto. Un driver en el kernel no basta para operar una granja de escritorios virtuales: hace falta crear perfiles, asignar memoria, listar qué trozo de GPU tiene cada máquina y liberarlo cuando el cliente se va. Vgpu-tools cubre esa parte y todavía se está escribiendo, así que el calendario del kernel no marca el día en que un administrador podrá usarlo todo sin tocar la línea de comandos. Hay un motivo adicional para desconfiar de las fechas redondas. Nova no habla con la tarjeta registro a registro: arranca el procesador GSP con firmware firmado y trabaja sobre las interfaces que ese firmware expone, con las comprobaciones de seguridad que detalla la documentación del kernel. Cada capa de esa pila se revisa por separado y lo que no convence se queda fuera, como ocurrió en el ciclo del 7.4 con la [retirada de funciones peligrosas que hizo Linus Torvalds](https://observatorioblockchain.com/tecnologia/linus-torvalds-quita-funciones-peligrosas-linux-7-4/). El reparto tiene una virtud que el calendario no: cada bloque que entra en el árbol deja rastro en la lista de correo, así que el plan de Song se sigue sin esperar a un anuncio de producto. ## Lo que un hipervisor aún no puede hacer La migración en vivo es la función que separa una nube de un conjunto de servidores. Con ella, un hipervisor copia la memoria de una máquina virtual a otro nodo mientras sigue ejecutándose, y el cliente no nota el traslado. Sin ella, sacar una máquina de un servidor que hay que reparar implica apagarla, esperar y volver a arrancarla, con lo que eso rompe en un escritorio abierto a medias y en una sesión de entrenamiento que llevaba horas. Moverla es más difícil porque el estado no está solo en la memoria del sistema: hay memoria de la tarjeta, colas pendientes, contexto de los procesos que ejecutan en la GPU y una configuración de firmware que no se copia con un memcpy. Por eso aparece en la lista de pendientes y no en la de lo que llega con el próximo ciclo. Para quien decide hoy sobre infraestructura gráfica en Linux, la respuesta va por tramos. Las cargas que no necesitan moverse en caliente ganan un arranque más limpio y menos módulos propietarios. El resto del kernel avanza a la misma velocidad de siempre, con ciclos como el del [FAT32 que llega a 162 veces más velocidad](https://observatorioblockchain.com/tecnologia/linux-7-4-rc2-fat32-162x-torvalds-ia/). A la misma lista de correo llegaron el 9 de noviembre de 2026 los [parches de AMD para RDNA 5](https://observatorioblockchain.com/tecnologia/amd-rdna-5-gfx13-parches-linux-12643-lineas/), que también esperan revisión. La virtualización de GPU llega al kernel principal por entregas, y todavía no está en la que decide el calendario de un centro de datos.