Sharing One GPU Between VMs and LXC Containers in Proxmox

It always starts with momentum.

You finally get GPU passthrough working for a VM in Proxmox 9.1.1. The PCIe device shows up cleanly, the VM boots, drivers install, CUDA works, and you feel unstoppable.

Then the next thought hits: can I do this for LXC containers too?

That's the crossroads in this thread. GPU passthrough works perfectly for VMs, but the moment you ask whether the same GPU can also be used by LXC containers, the answer gets uncomfortable fast, because what looks like a small extension runs into a basic architectural conflict.

Passthrough to a VM means letting go

One commenter laid it out clearly: when you pass a PCIe device through to a VM, the Proxmox host no longer interacts with it. That is the whole point of passthrough.

The PCIe communication is handed directly to the VM. The host doesn't load drivers or manage the device; it steps aside. Once that happens, nothing else can use it, whether that's the host, an LXC, or another VM. The GPU becomes the exclusive property of that one guest.

So if your plan is "keep GPU passthrough to VM and also expose it to LXC containers," you're fighting the definition of passthrough itself.

LXC "passthrough" isn't the same thing

This is where terminology trips people up. Another user explained that passing a PCIe device to an LXC is kind of a misnomer, since you're not truly handing over the hardware bus the way you do with a VM.

With LXC, the host still manages the GPU and loads the kernel modules. You then expose device nodes into the container so it can use the GPU's capabilities.

That distinction matters. VM passthrough gives the VM direct hardware control, while LXC GPU access means a host-controlled device shared into the container. These two models don't mix. If the GPU is bound to vfio-pci for a VM, the host can't manage it, and if the host can't manage it, it can't expose it to LXC. You have to choose which model you're using.

"Can I share it across multiple LXCs?"

Now the conversation gets spicier. One commenter said yes, it's possible to pass the GPU to an LXC, but strongly advised against trying to use passthrough on multiple LXCs for the same GPU.

The reasoning is simple: passthrough is designed around one machine owning the entire device bus. Trying to "share" it at that level leads to instability, errors, weird behavior, and a lot of wasted time.

If you want proper splitting, you need vGPU profiles, which give you actual fractional GPU allocation at the driver level. That's a whole different beast. Without vGPU, you're basically asking multiple workloads to grab the same physical steering wheel at once. It might move or it might crash, and it's rarely elegant.

The vGPU temptation

Another comment hinted at the difference between passthrough and vGPU. With vGPU, the host facilitates communication instead of completely stepping away from the device bus, and that's the clean way to carve a GPU into slices.

But now you're in licensing territory, with driver constraints, compatibility questions, and NVIDIA policies to deal with. Suddenly what started as "can I share my GPU?" turns into "how deep into enterprise virtualization do I want to go?" For home lab AI workloads across multiple LXCs, that complexity can spiral quickly.

Kernel mismatch and driver frustration

Then there's the Proxmox 9.1.1 wrinkle. The original poster ran into NVIDIA packages that didn't match the newest kernel.

That's a common Proxmox pain point. LXCs use the host kernel, so if your host kernel is ahead of the packaged drivers, you're stuck compiling or using the NVIDIA .run installer. That's what others described doing:

• Install NVIDIA drivers on the host via the .run file.
• Let it disable nouveau.
• Reboot.
• In the LXC, install only user-space utilities with --no-kernel-module.

It worked for some, including in unprivileged LXCs. Even that came with caveats, though. One user mentioned reboot timing issues where the LXC tried to initialize drivers before the host had finished loading them, and the fix was to delay container startup by 90 seconds. That's the kind of workaround that works… until you forget why you set it up that way.

Privileged vs unprivileged LXC

There was also the question of whether the LXC needs to be privileged. One response clarified that LXCs run on the host kernel, and another example showed successful GPU usage in an unprivileged LXC.

So you don't necessarily need a privileged container. You do need correct device mappings, cgroup permissions, and proper driver layering, which brings us back to the main tension.

The core conflict: VM + LXC at the same time

If your GPU is passed through to a VM via vfio-pci, the host cannot use it, and if the host cannot use it, it cannot expose it to LXC. That's the hard boundary.

So your real options look like this:

1. GPU passthrough to a single VM, which gives maximum isolation with zero host access and no LXC usage.
2. A host-managed GPU shared to multiple LXCs, with no VM passthrough; containers consume the GPU via exposed device nodes.
3. A vGPU configuration, an advanced setup with fractional GPU allocation plus licensing and driver complexity.

What you can't do cleanly is bind the GPU to a VM and expect it to serve multiple LXCs at the same time. PCIe passthrough simply doesn't work that way.

The licensing anxiety

There was even concern about NVIDIA "charging" if multiple containers use the GPU.

That fear often comes from confusing physical GPU usage with virtualized enterprise features. If the host is managing the GPU and exposing it to containers, it's still one physical GPU on one machine. Licensing complications usually come into play when you enter vGPU or enterprise virtualization features.

Technically speaking, the GPU doesn't care how many containers access it, as long as the host manages it properly. The limit is purely architectural.

So what should you do?

If you need multiple AI-focused LXCs using the GPU, unbind it from vfio-pci and let the host manage it. Install drivers on the host, expose /dev/nvidia* into containers, handle kernel rebuilds when necessary, and accept the occasional inconvenience of driver maintenance.

If you need one high-performance VM with full hardware ownership, stick with passthrough and accept that the GPU belongs to that VM alone.

Trying to do both at the same time is where the frustration lives. The architecture doesn't bend just because the hardware is powerful.

The bottom line

Yes, GPU access in LXC is possible, and yes, passthrough to a VM works. What you can't have is exclusive VM passthrough and host-managed LXC sharing simultaneously, because you're choosing who owns the device bus.

Once you understand that, the question shifts from "is it possible?" to which ownership model fits your workload best. In Proxmox, the GPU can be flexible, but it can't be in two places at once.