Entregar toda la tarjeta gráfica a una máquina virtual deja al escritorio anfitrión y a los demás invitados sin acceso. El ponente abre con ese trueque brutal y pregunta por qué dar una tarjeta a un invitado debe quitarla a todo lo demás. La respuesta está en el paso directo del dispositivo entero: se desliga de su controlador anfitrión para asignarse, va a un solo invitado, y anfitrión e invitados restantes no pueden usarlo a la vez.
La mecánica coincide con la guía de paso PCI en archlinux.org: desligar del controlador anfitrión, asignar por grupos IOMMU, perder imagen en el anfitrión. Quien lo probó en un portátil de una sola GPU conoce el dolor; el escritorio no vuelve hasta apagar al invitado. El ponente convierte esa propiedad exclusiva en problema y coloca allí la promesa: acceso sin propiedad.
Transmitir la petición en vez de la tarjeta
El proyecto experimental virtio-nvgpu invierte el camino. Su ficha en GitHub lo resume en una línea: un dispositivo virtio para acceso NVIDIA casi nativo en invitados KVM. La tarjeta queda en el anfitrión mientras los invitados reenvían peticiones al controlador anfitrión. Lo que cruza el límite no es el hardware sino operaciones hacia el programa que lo maneja. Así se abren rutas separadas para un segundo, tercer y cuarto invitado sin comprar otra tarjeta.
El pasaje más didáctico sigue una sola petición de búfer. Una aplicación en un invitado Linux quiere un búfer gráfico para una imagen. El controlador NVIDIA en modo usuario sigue intacto en el invitado; un pequeño módulo de reenvío en el núcleo invitado pasa la petición por una cola virtio al servicio anfitrión. Los lectores de la documentación de QEMU reconocerán la forma: frontal en el invitado, dorsal en el anfitrión, disciplina de cola en medio.
Antes de llegar al controlador anfitrión, el servicio traduce referencias. Punteros de memoria, manejadores de recursos y descriptores pueden cambiar de sentido a cada lado, así que el servicio los convierte en equivalentes que el anfitrión entiende. Luego una ventana de memoria compartida abre dos vistas sobre el mismo búfer, lado invitado y lado anfitrión, sin copia doble. Con el mapa listo, la ruta de dibujo documentada lo usa; cada llamada de dibujo ya no exige un mensaje reenviado.
Mantener intacto el controlador de usuario es el truco. Las aplicaciones hablan con el controlador conocido mientras módulo y servicio hacen el papeleo. Un segundo invitado puede conectar su propia ruta a la misma tarjeta. La diferencia con los montajes vGPU y MIG documentados por Nvidia importa aquí: tiempo compartido o partición física de un lado, peticiones reenviadas y memoria mapeada del otro. El ponente insiste; no cabe pedir prestadas las garantías de otro sistema.
Cuatro invitados, una tarjeta: el resultado medido
Las cifras salen de una RTX 3060 con la misma carga sintética. Un invitado solo produjo 102,9 fotogramas por segundo. Cuatro invitados con esa carga rondaron 26 cada uno, 103,69 en total. La base de TechPowerUp lista esta tarjeta con 3584 núcleos CUDA y 12 GB de GDDR6; en este ensayo el mismo cómputo y memoria lo hicieron todo, nada se multiplicó. Cuatro timbres, una cocina: más formas de pedir, misma cocina.
Las condiciones son explícitas: 8 segundos de calentamiento y 30 de carrera, trabajo idéntico en los cuatro invitados. Como nota el resumen de Linuxiac, son resultados internos sin confirmación independiente. Sobre todo, nada promete cuota fija, equidad ni trozo protegido de memoria gráfica . Cuatro es la cifra informada, no un máximo medido. Cuatro aplicaciones pesadas y distintas serían otro ensayo.
El segundo coste existe incluso con un invitado: el recargo de reenvío. En un caso sintético un cuadro anfitrión de 2 milisegundos se frenó 1,7 % en el invitado; en un caso mucho más corto un cuadro de 0,05 milisegundos se frenó 40,8 %. Los autores atribuyen el hueco corto sobre todo a despertar al invitado tras el hardware. Un peso pequeño parece enorme en un trabajo diminuto, así que los porcentajes deben viajar con sus duraciones. Ninguna promesa casi nativa se sigue de dos puntos.
Para qué sirve, para qué no
La meta declarada es emisión sin cabezal: el invitado produce una imagen y la sirve como vídeo con codificación H.264 , vista en pantalla remota. La salida física queda fuera. El léame apunta a la interfaz de vídeo Vulkan para presentar y codificar en los invitados; cuatro sesiones ligeras corrieron juntas. Vía hacia varios entornos Linux remotos con acceso gráfico.
La lista de noes pesa igual. Invitados no fiables exigen aislamiento seguro; el ayudante aislado y la infraestructura multi-inquilino están sin terminar, así que el uso conjunto no prueba separación. CUDA está en enumeración del dispositivo; ningún cálculo completo, inferencia local o entrenamiento se muestra. La compatibilidad depende de la interfaz reenviada, la ABI del controlador ; mantener el controlador no vuelve compatible toda mezcla de versiones. El usuario de escritorio único nada demostrado gana; sumar invitados a una tarjeta saturada no crea recursos.
Momentos clave
Comentario de la IA
"La disciplina de medición sostiene el relato: las cifras se dan sin adornos y lo no demostrado se nombra punto por punto."
Evaluación de la IA
El contrapunto más fuerte es simple: compartir resuelve el acceso, no la capacidad. Cuatro invitados con la misma carga sintética mantuvieron el total en 103,69 fotogramas por segundo, unos 26 cada uno, lejos de los 102,9 del invitado único. Cómo se comportarían cuatro aplicaciones pesadas y distintas juntas nunca se midió, así que ninguna lección de capacidad cabe aquí.
La lista de ausencias es larga y explícita: sin cuotas fijas ni equidad garantizada, sin trozos protegidos de memoria probados, aislamiento y ayudante aislado sin terminar, CUDA solo en enumeración, Windows y juego multiusuario fuera de alcance. La documentación de Nvidia describe partición física MIG con aislamiento fuerte, que este experimento no ofrece. La documentación de QEMU ya describe rutas virtio-gpu integradas, así que depender de otra interfaz de controlador es un riesgo propio.
El posible interés del ponente es orientar a curiosos más que vender instalaciones: ningún consejo para el escritorio único, una lista de seguimiento para entusiastas de máquinas virtuales Linux. Ese tono equilibrado da confianza. Aun así la contradicción interna sobre soporte multi-invitado sugiere disciplina de versiones frágil en GitHub; el resumen de Linuxiac subraya igual el estado experimental.
La conclusión práctica es estrecha: si varios invitados Linux necesitan aceleración a la vez y bastan sesiones remotas ligeras, el proyecto merece seguimiento; con 12 GB la RTX 3060 es una base razonable para tales pruebas según la base de TechPowerUp. Si una carga ya satura la tarjeta, el paso directo de un invitado de la guía de archlinux.org sigue siendo la vía previsible. Antes de evitar una compra, exija medidas de su aplicación, por invitado y en total.
Fuentes
7 enlaces; ninguna otra noticia publicada los cita. Stories sharing a link do not confirm each other; a source's origin is not inferred from how often it is cited.
virtio-nvgpu · gpu compartida · kvm · rtx 3060 · máquinas virtuales