Compartir una GPU entre VM y LXC en Proxmox

Todo empieza siempre con entusiasmo.

Por fin consigues que el passthrough de GPU funcione en una VM con Proxmox 9.1.1. El dispositivo PCIe aparece limpio, la VM arranca, los controladores se instalan, CUDA funciona y sientes que nada puede pararte.

Entonces surge la siguiente pregunta: ¿puedo hacer esto también para contenedores LXC?

Esa es la encrucijada de este debate. El passthrough de GPU funciona de maravilla en máquinas virtuales, pero en cuanto preguntas si esa misma GPU puede usarse también en contenedores LXC, la respuesta se vuelve incómoda con rapidez: lo que parece una pequeña extensión choca contra un conflicto arquitectónico fundamental.

El passthrough a una VM significa ceder el control

Un usuario lo explicó con total claridad: cuando pasas un dispositivo PCIe a una VM, el host de Proxmox deja de interactuar con él. Ese es precisamente todo el sentido del passthrough.

La comunicación PCIe se entrega directamente a la VM. El host no carga controladores ni administra el dispositivo; se aparta. Una vez que eso ocurre, ningún otro elemento puede usar la tarjeta, ya sea el host, un contenedor LXC u otra VM. La GPU pasa a ser propiedad exclusiva de ese único invitado.

Por eso, si tu plan consiste en mantener el passthrough de la GPU a la VM y al mismo tiempo exponerla a contenedores LXC, estás chocando contra la propia definición de passthrough.

El «passthrough» en LXC no es lo mismo

Aquí es donde la terminología suele confundir a la gente. Otro participante explicó que hablar de pasar un dispositivo PCIe a un LXC resulta un término poco preciso, porque en realidad no estás transfiriendo el bus de hardware como lo harías con una VM.

En LXC, el host sigue gestionando la GPU y cargando los módulos del kernel. Después expones los nodos de dispositivo dentro del contenedor para que pueda aprovechar las capacidades de la GPU.

Esa diferencia importa. El passthrough a VM otorga control directo del hardware a la máquina virtual, mientras que el acceso de GPU en LXC implica un dispositivo gestionado por el host y compartido con el contenedor. Esos dos modelos no se pueden mezclar. Si la GPU está enlazada a vfio-pci para una VM, el host no puede gestionarla, y si el host no puede gestionarla, no puede exponerla a LXC. Tienes que elegir qué modelo vas a utilizar.

«¿Puedo compartirla entre varios LXC?»

Aquí el debate se vuelve más interesante. Un comentarista señaló que sí es posible pasar la GPU a un LXC, pero aconsejó encarecidamente no intentar usar passthrough en varios LXC con la misma GPU.

El razonamiento es sencillo: el passthrough está diseñado para que una sola máquina posea todo el bus del dispositivo. Tratar de «compartirlo» a ese nivel provoca inestabilidad, errores, comportamientos extraños y una gran pérdida de tiempo.

Si quieres una división adecuada, necesitas perfiles vGPU, que proporcionan una asignación fraccionada real de GPU a nivel de controlador. Eso ya es terreno muy distinto. Sin vGPU, básicamente le estás pidiendo a varias cargas de trabajo que tomen el mismo volante físico al mismo tiempo. Puede que avance o puede que se estrelle, y rara vez resulta elegante.

La tentación de vGPU

Otro comentario apuntó a la diferencia entre passthrough y vGPU. Con vGPU, el host facilita la comunicación en vez de apartarse por completo del bus del dispositivo, y esa es la vía limpia para dividir una GPU en fracciones.

El problema es que entras en terreno de licencias, limitaciones de controladores, dudas de compatibilidad y normativas de NVIDIA. De pronto, lo que empezó como un simple «¿puedo compartir mi GPU?» pasa a ser «¿cuánto quiero profundizar en la virtualización empresarial?». Para cargas de trabajo de IA en un homelab distribuidas en varios LXC, esa complejidad puede dispararse rápidamente.

Desajustes de kernel y problemas con los controladores

Luego está el contratiempo particular de Proxmox 9.1.1. Quien abrió el hilo se encontró con paquetes de NVIDIA que no coincidían con el kernel más reciente.

Ese es un punto de dolor habitual en Proxmox. Los contenedores LXC usan el kernel del host, de modo que si el kernel del host va por delante de los controladores empaquetados, te toca compilar o usar el instalador .run de NVIDIA. Eso fue lo que describieron otros usuarios:

• Instalar los controladores de NVIDIA en el host mediante el archivo .run.
• Dejar que desactive nouveau.
• Reiniciar el equipo.
• En el contenedor LXC, instalar únicamente las utilidades de espacio de usuario con --no-kernel-module.

A varios les funcionó, incluso en contenedores LXC no privilegiados. Aun así, hubo advertencias. Un usuario mencionó problemas con los tiempos de arranque en los que el LXC intentaba inicializar los controladores antes de que el host hubiera terminado de cargarlos, y la solución fue retrasar el inicio del contenedor 90 segundos. Es el típico apaño que funciona hasta que olvidas por qué lo configuraste así.

LXC privilegiado frente a no privilegiado

También surgió la duda de si el LXC necesita ser privilegiado. Una respuesta aclaró que los LXC se ejecutan sobre el kernel del host, y otro ejemplo demostró el uso correcto de GPU en un LXC no privilegiado.

Así que no necesitas necesariamente un contenedor privilegiado. Lo que sí necesitas son los mapeos de dispositivos correctos, permisos en cgroups y una adecuada jerarquía de controladores, lo que nos devuelve a la tensión principal.

El conflicto central: VM y LXC al mismo tiempo

Si tu GPU está asignada a una VM mediante vfio-pci, el host no puede usarla, y si el host no puede usarla, no puede exponerla a LXC. Ese es el límite estricto.

Tus opciones reales se resumen en esto:

1. Passthrough de GPU a una sola VM, lo que ofrece aislamiento máximo sin acceso desde el host y sin uso en LXC.
2. Una GPU gestionada por el host y compartida con varios LXC, sin passthrough a VM; los contenedores consumen la GPU mediante los nodos de dispositivo expuestos.
3. Una configuración vGPU, un despliegue avanzado con asignación fraccionada de GPU más la complejidad añadida de controladores y licencias.

Lo que no puedes hacer limpiamente es vincular la GPU a una VM y esperar que dé servicio a varios LXC al mismo tiempo. El passthrough PCIe sencillamente no funciona de esa manera.

La preocupación por las licencias

Incluso surgió el temor de que NVIDIA cobre si varios contenedores usan la GPU.

Ese miedo suele provenir de confundir el uso físico de la GPU con funciones empresariales virtualizadas. Si el host gestiona la GPU y la expone a los contenedores, sigue siendo una única GPU física en una sola máquina. Las complicaciones de licencias suelen aparecer cuando entras en vGPU o en funciones de virtualización empresarial.

Técnicamente hablando, a la GPU no le importa cuántos contenedores accedan a ella, siempre que el host la gestione adecuadamente. La limitación es puramente arquitectónica.

¿Qué conviene hacer entonces?

Si necesitas varios LXC dedicados a IA usando la GPU, desvincúlala de vfio-pci y deja que el host la gestione. Instala los controladores en el host, expón /dev/nvidia* en los contenedores, gestiona las recompilaciones de kernel cuando haga falta y asume el mantenimiento ocasional de los controladores.

Si necesitas una sola VM de alto rendimiento con control absoluto del hardware, mantén el passthrough y acepta que la GPU pertenecerá únicamente a esa VM.

Intentar ambas cosas a la vez es la causa de todas las frustraciones. La arquitectura no cede solo porque el hardware sea potente.

Conclusión

El acceso a GPU en LXC es totalmente posible, y el passthrough a una VM funciona. Lo que no puedes tener es passthrough exclusivo a una VM y uso compartido en LXC gestionado por el host simultáneamente, porque tienes que decidir quién es el dueño del bus del dispositivo.

Una vez que entiendes eso, la pregunta deja de ser «¿es posible?» y pasa a ser qué modelo de propiedad encaja mejor con tu carga de trabajo. En Proxmox, la GPU puede ser flexible, pero no puede estar en dos sitios a la vez.