NVIDIA GPUs in Proxmox LXC containers: host driver, device nodes, sharing a card, limits

How an NVIDIA GPU reaches a Proxmox LXC container

A Proxmox LXC container runs on the host's kernel, so the host loads the NVIDIA driver and keeps the card, and each container receives the /dev/nvidia* device nodes plus the user-space libraries of the same driver release. Several containers can then use one card at the same time, which suits a few internal services on one GPU. They share the card's memory without any isolation, and neither NVIDIA nor Proxmox documents the combination as supported.

This guide is for a company Proxmox host that should run a handful of GPU services, such as an inference endpoint, an embedding service and a transcription job, without one VM per card. The VM routes themselves are described in our guides to NVIDIA vGPU on Proxmox VE and to the RTX PRO 6000 Max-Q in virtual machines.

Proxmox pct manual 9.2.13 (24 September 2026); NVIDIA GPU Operator GPU-sharing page (14 October 2026); NVIDIA MIG user guide (13 October 2026); NVIDIA Container Toolkit platform support (18 September 2026); vGPU row from our Proxmox vGPU guide; all read 25 October 2026.

What Proxmox and NVIDIA document, and what they leave open

On the Proxmox side the building blocks are documented. The pct manual for Proxmox VE 9.2.13, dated 24 September 2026, states that containers "use the kernel of the host system that they run on, instead of emulating a full operating system". It lists the option dev[n], "Device to pass through to the container", with the sub-options path, mode, uid, gid and deny-write; the Linux Container page of the Proxmox wiki, last edited on 21 May 2026, describes uid and gid as the IDs "to be assigned to the device node" and mode as the "access mode to be set on the device node". In the Proxmox forum, a staff member wrote on 4 June 2024 that this passthrough has been available on the command line and API since 8.1 and in the web interface since 8.2, under Resources, Add, Device Passthrough. GPUs and NVIDIA are not mentioned on either page.

NVIDIA's documents cover the host and the container stack separately, and neither names LXC. The Container Toolkit's platform page of 18 September 2026 lists the distributions on which recent releases "are tested and expected to work": among them Ubuntu 22.04, 24.04 and 26.04, RHEL 8 to 10 and Debian 11, the only Debian version. Proxmox VE 9.2 is "Based on Debian Trixie (13.5)", according to the Proxmox roadmap. NVIDIA's driver installation guide for branch 615, updated on 23 September 2026, covers Debian 12 and 13, but a Proxmox host runs Proxmox's own kernel, not Debian's. NVIDIA's vGPU documentation does list Proxmox VE as a validated Linux with KVM platform, and that statement covers vGPU in virtual machines.

So the route works with documented parts, and nobody vouches for the whole. For a service that a department depends on, whoever signs it off should know that a driver problem in this set-up is solved by the operator, without a vendor ticket to open.

The host: driver, kernel modules and device nodes

Everything starts with a working NVIDIA driver on the Proxmox host.

First, the kernel module flavour. NVIDIA's driver README for release 580.95.05 states that "Blackwell and later are only supported by the open kernel modules", so every RTX PRO Blackwell card needs the open modules. NVIDIA's Debian instructions install them with the package nvidia-open, or for a headless compute host with nvidia-driver-cuda plus nvidia-kernel-open-dkms, and they need the headers of the running kernel. On Proxmox these are the headers for the Proxmox kernel, and the module is rebuilt through DKMS at every kernel update. Hosts with Secure Boot need the module signed, as our guide to the NVIDIA driver with Secure Boot on Linux servers explains.

Second, the branch. A host driver update changes the kernel module for every container at once, so the branch should move only when you decide. NVIDIA's version-locking page shows pinning packages for Debian and Ubuntu, named nvidia-driver-pinning-<branch> or with a full version. Which branch to choose, and which releases fix the security issues of 30 September 2026, is set out in our article on NVIDIA driver branches and CUDA versions. Security weighs more here than on a VM host: every container with the device nodes can talk to the host's kernel driver directly.

Third, the device nodes have to exist before the containers start. The README describes nvidia-uvm.ko, which "provides functionality for sharing memory between the CPU and GPU in CUDA programs", as loaded when a CUDA program starts, and nvidia-modprobe as the setuid tool that loads the modules and creates the /dev/nvidia* nodes. A Proxmox host that runs no CUDA program itself may therefore boot without the UVM module and its node, and a container that starts then finds no /dev/nvidia-uvm. The LXC project's NVIDIA hook prints a warning for exactly this case: "Kernel module nvidia_uvm is not loaded, nvidia-container-cli might fail." Plan a step at host boot that loads the modules and creates the nodes; nvidia-persistenced, which NVIDIA describes as the daemon "for allowing the NVIDIA kernel module to maintain persistent state", belongs on such a host as well.

NVIDIA MIG user guide, "Device Nodes and Capabilities" (13 October 2026); NVIDIA Linux driver README 580.95.05, installed components; read 25 October 2026.

The container: device access and the driver's user space

A container needs two things to run CUDA: permission to open the device nodes, and the libraries that talk to them, such as libcuda.so and the management library behind nvidia-smi. The kernel half stays on the host.

Proxmox creates new containers as unprivileged by default; the pct manual calls this "the default option when creating a new container". Root inside the container is mapped to an unprivileged user outside, and the device nodes are passed with dev[n], setting uid, gid and mode so that the service account in the container can open them. Privileged containers avoid the mapping, but the manual is plain about them: "The LXC team considers this kind of container as unsafe", and they "should only be used in trusted environments". A GPU container for one internal service does not justify a privileged container. Older guides grant access with raw lxc.cgroup2.devices.allow and lxc.mount.entry lines, which Proxmox passes "directly to the LXC low-level tools"; the Proxmox wiki records that cgroup v1 was removed entirely with Proxmox VE 9.0, and Proxmox VE 9.2 warns about raw cgroup v1 entries in container configurations, so such lines should be checked.

For the user space there are two common approaches.

1. NVIDIA's container library through an LXC hook. The LXC project ships a mount hook named nvidia that calls nvidia-container-cli from NVIDIA's libnvidia-container, a library "designed to be agnostic of the container runtime". The hook reads NVIDIA_VISIBLE_DEVICES and NVIDIA_DRIVER_CAPABILITIES, and its options point at the host's driver root and library cache, so the container takes the driver components from the host and never carries its own copy. Two details from the script: it stops with "This hook currently only works in unprivileged mode", and in a user namespace it passes --no-cgroups, so device access still has to be granted in the container configuration. Check that both the hook and the NVIDIA tool exist on your host.
2. The driver's user space installed inside the container. Many guides install the same driver release in the container without its kernel part. NVIDIA documents no container-specific variant of this install, and the versions have to stay in step: NVIDIA's README warns that "problems will arise if applications use the wrong version of a library". Every host driver update then means updating every container in the same maintenance window.

Inside the container, Docker or Podman can run with NVIDIA's Container Toolkit on top. The toolkit's install guide documents nvidia-ctk config --set nvidia-container-cli.no-cgroups --in-place for rootless Docker, the same situation as an unprivileged container. Proxmox's own advice for nested containers points elsewhere: "nesting containers inside a Proxmox QEMU VM remains a recommended practice" where isolation or live migration matters. Our guide to Docker GPU assignment without Kubernetes covers the Docker side.

We supply the RTX PRO 6000 Server Edition and the other cards on our GPU page as cards or in AI servers built to order; tell us which services should share a host and how much memory each needs, and our team replies with a card and MIG layout for it.

Sharing one GPU between several LXC containers

The appeal of LXC is that three containers can open /dev/nvidia0 at the same time. What they get is a share of time and a common pool of memory. NVIDIA's GPU Operator documentation describes this mechanism for time-sliced GPUs: the GPU "simply provides an equal share of time to all GPU processes", and "unlike Multi-Instance GPU (MIG), there is no memory or fault-isolation between replicas". The same holds for processes from different LXC containers on one card. A container that allocates more memory leaves less for the others, and a process that triggers a fatal GPU fault can disturb every process on the card.

Memory is where it goes wrong first, because inference engines reserve memory up front. vLLM's --gpu-memory-utilization defaults to 0.92 in the current engine-arguments documentation and "is a per-instance limit, and only applies to the current vLLM instance. It does not matter if you have another vLLM instance running on the same GPU." With default settings, a second vLLM container on the same card will not get the memory it asks for. The documentation's own example is two instances at 0.5 each. On an RTX PRO 6000 with 95.6 GiB visible to the driver, two instances at 0.45 get about 43.0 GiB each by our estimate (0.45 × 95.6 GiB), which leaves room for the CUDA contexts and a small third service. Ollama behaves differently: it "evaluates the required VRAM for the model against what is currently available" and keeps a model loaded for five minutes after the last request by default. A model that Ollama has just loaded can therefore take memory that a vLLM container expected to find free. When a container still fails, our guide to vLLM CUDA out of memory lists the causes.

A large model does not fit into a share. Llama 3.3 70B in FP8 has 67.7 GiB of weights; by our users-per-card rule (0.9 × driver-visible memory, minus 3 GiB overhead per card, minus weights) one RTX PRO 6000 of any edition leaves 83.0 GiB for weights and cache and serves 12 conversations of 8,192 tokens with an FP8 cache. Such a model needs the whole card, and the LXC route then brings no sharing benefit over a VM with passthrough.

MIG on the host: separated memory for each container

On a Proxmox host the NVIDIA driver runs on bare metal, and NVIDIA's MIG guide of 13 October 2026 lists "Bare-metal, including containers" as a supported configuration. MIG divides a card in hardware: the RTX PRO 6000 Blackwell in all three editions splits into up to four instances, the RTX PRO 5000 48 GB and the RTX PRO 4500 into two, the H200 NVL into seven (NVIDIA's guide names the RTX PRO 4500 without an edition, so plan MIG on the Server Edition only); the L40S and the L4 have no MIG. On an RTX PRO 6000 the profiles are 1g.24gb, 2g.48gb and 4g.96gb, and four containers with a 1g.24gb instance each have their own memory and memory paths. Creating the instances and the prerequisites, including the display-mode switch on the Workstation and Max-Q editions, are covered in our step-by-step MIG guide for RTX PRO Blackwell and the profile table in RTX PRO 6000 MIG profiles.

Access to an instance runs through capability device nodes. The MIG guide describes the /dev interface, located under /dev/nvidia-caps, as relying "primarily on cgroups", calls it the preferred method, and states that "all future NVIDIA datacenter drivers will have a default of nv_cap_enable_devfs=1", which enables it. With this interface, a container receives only the capability nodes of the GPU instance and compute instance it should use. The guide also warns that granting the mig-config capability means access to the nodes of every instance that may be created later, so that capability stays on the host. Two cautions apply. NVIDIA documents this for containers in general, and we found no Proxmox or NVIDIA page that shows it with LXC. And the instance layout is host state: when the layout changes, the capability nodes of the new instances differ, and the container configuration must follow.

MIG separates memory and faults on the card. The containers still share one host kernel and one kernel driver, so a driver bug or a host-level compromise affects all of them, which a vGPU VM with its own guest kernel limits.

When MIG or vGPU in VMs is the better route

LXC with GPUs fits a small, trusted set of Linux services run by one team on one host: development tools, an internal inference endpoint, batch jobs, a transcription service. It fits less well as soon as one of these applies.

• Different owners or tenants. Without MIG nothing stops one container from taking the memory the others need, and with MIG they still share the host kernel. Separate VMs give each owner its own kernel.
• Windows guests, desktops or graphics. Containers are Linux on the host kernel. Virtual desktops and Windows workloads belong in vGPU VMs, where NVIDIA's vWS, vPC and vApps licences apply.
• Live migration. The pct manual states that "running containers cannot live-migrated due to technical limitations" and offers a restart migration, which shuts the container down and starts it on the target; a GPU container also needs the same devices and driver there. VMs with NVIDIA vGPU can be live-migrated since Proxmox VE 8.4.
• A support contract. Proxmox accepts vGPU tickets with a Basic, Standard or Premium subscription plus an NVIDIA vGPU entitlement, as our Proxmox vGPU guide sets out. For GPU containers there is no comparable statement.
• Large models. A model that needs a whole card or several cards for tensor parallelism gains nothing from sharing; a passthrough VM or bare metal is simpler.

A host can mix routes card by card. The Proxmox wiki on PCI passthrough states: "If you 'PCI passthrough' a device, the device is not available to the host anymore." A card that is passed through to a VM is therefore out of reach for the host driver and for every container, and a card that the host driver uses for containers cannot go to a VM at the same time. For several teams on a cluster, scheduling with Kubernetes is the other common answer; our guide to GPU sharing in Kubernetes compares MIG, time-slicing and MPS there.

Which card for a shared Proxmox host

For a rack server in continuous operation we recommend the RTX PRO 6000 Blackwell Server Edition: 96 GB per card, MIG with up to four instances, and it is the edition NVIDIA lists for vGPU, so the same card can later move from containers to vGPU VMs. The RTX PRO 4500 Blackwell Server Edition with 32 GB and two MIG halves suits smaller services. The RTX PRO 6000 Max-Q and Workstation Edition work with the LXC route as well, because the host driver uses them like any other card, but they have no vGPU, and in a rack server the Max-Q belongs only in a chassis whose maker lists it. Host sizes are compared in our guide to two, four or eight RTX PRO 6000 Server Edition cards.

We build these cards into AI servers to order, assembled and tested before delivery, with the operating system, drivers, CUDA and a container runtime installed on request; warranty is handled through us, and quantities and lead time are confirmed in writing with the quote. If you plan a shared Proxmox host, send us the services and the memory each one needs, and we propose the cards and a MIG layout.

FAQ