The Critical Prerequisite: Installing Build Dependencies for NVIDIA Driver on a Proxmox Host

Introduction

In the complex dance of enabling GPU passthrough for machine learning workloads on virtualized infrastructure, the most mundane steps often carry the heaviest weight. Message [msg 443] in this opencode session captures one such moment: a single apt install command that, on its surface, simply installs three packages—build-essential, pve-headers, and dkms—on a Proxmox VE host. Yet this message represents a pivotal turning point in a multi-day effort to overcome a fundamental hardware limitation that had stymied the deployment of an 8-GPU Blackwell system for large language model inference.

To understand why this message matters, one must appreciate the journey that led to it. The team had been wrestling with a persistent performance bottleneck: when running the GLM-5-NVFP4 model across 8 NVIDIA RTX PRO 6000 Blackwell GPUs inside a KVM virtual machine, GPU-to-GPU communication (P2P DMA) was being routed through the host's PCI Express root complex rather than directly between GPUs. The nvidia-smi topo -m output inside the VM showed PHB (PCIe Host Bridge) topology instead of the NODE or SYS topology that indicates direct peer-to-peer connectivity. This virtualization-induced latency was crippling the tensor-parallel inference performance that the team had worked so hard to establish.

After extensive investigation in <msg id=429-442>, the team identified the root cause: the VFIO/IOMMU layer that enables GPU passthrough to KVM virtual machines inherently breaks the direct PCIe peer-to-peer links between devices. Each GPU, passed through via VFIO, appears to the guest as an isolated device behind an emulated PCIe host bridge. The hardware topology—each of the 8 GPUs residing on its own PCIe root complex—compounds the problem, as P2P DMA across different root complexes is not supported even on bare metal. The solution proposed in [msg 433] was to abandon the KVM approach entirely and instead use LXC containers, which share the host kernel and can access physical devices directly without the VFIO abstraction layer.

The Message Itself

The subject message reads in its entirety:

[assistant] Now install the build dependencies: [bash] ssh root@10.1.2.6 "apt install -y build-essential pve-headers-\$(uname -r) dkms 2>&1 | tail -20" Setting up libalgorithm-merge-perl (0.08-5) ... Setting up cpp-12 (12.2.0-14+deb12u1) ... Setting up libavif15:amd64 (0.11.1-1+deb12u1) ... Setting up libheif1:amd64 (1.15.1-1+deb12u1) ... Setting up dpkg-dev (1.21.22) ... Setting up libgcc-12-dev:amd64 (12.2.0-14+deb12u1) ... Setting up libgd3:amd64 (2.3.3-9) ... Setting up cpp (4:12.2.0-3) ... Setting up libc6-dev:amd64 (2.36-9+deb12u13) ... Setting up libc-devtools (2.36-9+deb12u13) ... Setting up libstdc++-12-dev:amd64 (12.2.0-14+deb12u13) ...

The command is executed over SSH on the Proxmox host (kpro6, at IP 10.1.2.6) and installs three categories of packages: the standard C/C++ compilation toolchain (build-essential), the kernel headers matching the currently running Proxmox VE kernel (pve-headers-$(uname -r)), and the Dynamic Kernel Module Support framework (dkms). The output shows the Debian package manager configuring various dependencies, culminating in the successful installation of the core development libraries needed to compile kernel modules.

Why This Message Was Written: The Reasoning and Motivation

The motivation behind this message is straightforward but critical: the NVIDIA proprietary driver for Linux is distributed as a self-extracting installer (a .run file) that, when executed, compiles kernel modules on the target system. This compilation requires:

A C compiler and associated toolchain (build-essential): The NVIDIA kernel module source code must be compiled into loadable .ko files that can be inserted into the running kernel. Without gcc, make, and the standard C library headers, the compilation will fail.
Kernel headers matching the running kernel (pve-headers-$(uname -r)): The compiled kernel module must be compatible with the exact kernel version and configuration running on the host. The Proxmox VE kernel (version 6.8.12-9-pve in this case) is a customized kernel with specific patches and configuration options. The pve-headers package provides the necessary header files and build infrastructure that the NVIDIA driver's build system needs to produce a compatible module.
Dynamic Kernel Module Support (dkms): DKMS is a framework that automates the rebuilding of kernel modules when the kernel is updated. Without DKMS, if the Proxmox host receives a kernel update (which is common in a production environment), the NVIDIA driver would need to be manually reinstalled. DKMS registers the module source with the system and automatically recompiles it against each new kernel as it is installed. The assistant's decision to run this command at this specific moment reflects a careful sequencing of operations. Earlier in the conversation (<msg id=439-442>), the assistant had discovered that the Proxmox host's apt sources were misconfigured: the enterprise repository was returning a 401 Unauthorized error because the host lacked a valid subscription. The assistant first fixed this by commenting out the enterprise repository and adding the no-subscription community repository, then ran apt update to refresh the package index. Only after ensuring the package manager was functional did the assistant proceed to install the build dependencies.

Assumptions Made

This message rests on several assumptions, some of which would later prove problematic:

Assumption 1: The PVE kernel headers are compatible with NVIDIA driver 590.48.01. The assistant assumes that the Proxmox VE kernel (6.8.12-9-pve) provides a standard Linux kernel interface that NVIDIA's proprietary driver can compile against. While NVIDIA drivers generally work with mainstream kernels, Proxmox VE kernels include modifications for virtualization and container management that could potentially break compatibility. This assumption would later be challenged when CUDA initialization failed inside the LXC container (<msg id=434+ chunk 0 of segment 4>).

Assumption 2: DKMS will successfully register and build the NVIDIA module. DKMS relies on the module source being structured in a specific way and providing a proper dkms.conf file. The NVIDIA .run installer handles DKMS registration automatically when the --dkms flag is passed, but this assumes the installer correctly detects the DKMS infrastructure on the system.

Assumption 3: The pve-headers package will resolve to a valid package. The command uses pve-headers-$(uname -r), which dynamically substitutes the current kernel version. If the exact kernel version's headers package is not available in the repositories (e.g., if the kernel was updated but the headers package lags behind), this command would fail. The assistant had already verified the kernel version in [msg 436] (6.8.12-9-pve), but had not confirmed that the corresponding headers package existed.

Assumption 4: Installing the NVIDIA driver on the Proxmox host is the correct approach for LXC GPU access. This is the foundational architectural assumption of the entire LXC experiment. The assistant assumes that installing the proprietary NVIDIA driver on the Proxmox host (rather than in the container) will allow LXC containers to access the GPUs through bind-mounted device nodes. While this is a well-documented approach for LXC GPU passthrough, it introduces a dependency on the host's kernel and driver stack that may not be fully compatible with the Blackwell GPU architecture's firmware requirements.

Input Knowledge Required

To understand this message, one needs knowledge spanning several domains:

Proxmox VE architecture: Understanding that Proxmox is built on Debian with a custom kernel, that it uses a subscription model for the enterprise repository, and that LXC containers share the host kernel while KVM virtual machines use their own kernel.

NVIDIA driver installation mechanics: Knowing that the NVIDIA Linux driver is not a simple binary but a self-extracting archive that compiles kernel modules at installation time, requiring kernel headers and a compiler toolchain.

DKMS and kernel module management: Understanding that kernel modules must match the exact kernel version they will be loaded into, and that DKMS automates the recompilation process across kernel updates.

The broader context of the P2P DMA problem: Recognizing that this installation is not an isolated infrastructure task but a critical step in a larger strategy to bypass the VFIO/IOMMU bottleneck that was degrading ML inference performance.

The hardware topology: Knowing that the host has 8 NVIDIA RTX PRO 6000 Blackwell GPUs (device ID 2bb5) spread across multiple PCIe root complexes, and that this topology fundamentally limits P2P DMA even on bare metal.

Output Knowledge Created

This message produces several important outputs:

1. A working build environment on the Proxmox host. The successful installation of build-essential, pve-headers, and dkms transforms the host from a bare Proxmox system into one capable of compiling and installing proprietary kernel modules. This is a prerequisite for every subsequent step in the LXC GPU passthrough approach.

2. Confirmation that the PVE no-subscription repository is functional. The successful package download and installation validates that the apt source fix performed in the previous round ([msg 442]) was effective. This is non-trivial: misconfigured apt sources are a common failure point in Proxmox deployments, and the assistant had to diagnose and correct this issue before proceeding.

3. A validated package dependency chain. The output shows the full tree of dependencies being installed, including libc6-dev, libstdc++-12-dev, dpkg-dev, cpp, and other compilation tools. This provides a record of exactly which package versions are present, which could be useful for debugging future compatibility issues.

4. A checkpoint in the task execution plan. The assistant's todo list (visible in [msg 438]) shows the task "Install NVIDIA driver on Proxmox host" transitioning from "in_progress" to completion after this step. The message serves as a progress marker in the multi-phase plan to migrate from KVM to LXC.

The Thinking Process Visible in the Message

While the message itself is a single tool call, the reasoning behind it is revealed through the surrounding conversation. The assistant's thinking follows a clear pattern:

Phase 1: Assessment. In <msg id=435-438>, the assistant explores the current state of both the Proxmox host and the existing LXC container. It discovers that the host has no NVIDIA driver, no vfio-pci bindings, and no build tools. The LXC container 129 exists but is unprivileged and has no GPU configuration.

Phase 2: Repository repair. In <msg id=439-442>, the assistant encounters a failure when trying to install packages (the enterprise repository returns 401 Unauthorized). Rather than proceeding blindly, it diagnoses the apt source configuration, identifies the enterprise repository as the culprit, and adds the community no-subscription repository. This shows a methodical debugging approach: when a tool fails, investigate the infrastructure dependencies before retrying.

Phase 3: Dependency installation. In [msg 443], the assistant executes the corrected install command. The use of $(uname -r) for dynamic kernel version resolution shows an understanding that the kernel headers must match the running kernel exactly. The inclusion of DKMS indicates forward-thinking about system maintenance and kernel updates.

Phase 4: What comes next. The assistant's todo list shows that the next steps are to configure the LXC container with GPU device mounts and install the NVIDIA userspace driver inside the container. This reveals the assistant's mental model of the overall plan: host driver installation → container device configuration → container userspace driver → ML stack deployment.

The Significance in the Larger Narrative

This message, for all its apparent simplicity, sits at a critical inflection point in the session. The team had spent segments 0-3 building and debugging an SGLang-based GLM-5-NVFP4 deployment on a KVM VM with VFIO-passed GPUs. They had achieved functional inference but hit a performance ceiling due to P2P DMA limitations imposed by virtualization. The LXC approach represented a promising alternative that could eliminate the VFIO overhead and restore native GPU-to-GPU communication.

However, the LXC approach introduced a new risk: installing the NVIDIA proprietary driver on the Proxmox host itself. In the KVM approach, the host remained clean of NVIDIA software—the GPUs were passed through to the VM, which had its own driver stack. In the LXC approach, the host must load the NVIDIA kernel modules, which means the host kernel must be compatible with the NVIDIA driver, and the driver must support the Blackwell GPU architecture.

The installation of pve-headers specifically highlights this tension. The Proxmox VE kernel is a customized kernel maintained by the Proxmox team, not the upstream Linux kernel. NVIDIA's driver development targets upstream kernels and specific enterprise distributions (RHEL, Ubuntu LTS). The compatibility between NVIDIA driver 590.48.01 and the PVE kernel 6.8.12-9-pve is not guaranteed. The assistant is essentially betting that the PVE kernel's modifications do not break the NVIDIA driver's compilation or runtime behavior.

This bet would later prove partially correct and partially wrong. The NVIDIA driver would compile and load successfully, and nvidia-smi would detect all 8 GPUs inside the LXC container with the correct bare-metal topology. However, CUDA runtime initialization would fail with error code 3 (CUDA_ERROR_NOT_INITIALIZED), ultimately traced to missing Blackwell GSP firmware files and potential kernel-level compatibility issues. The LXC approach showed promise for P2P but was blocked by a different class of problem—one rooted in the driver's support for the very new Blackwell architecture rather than in virtualization overhead.

Conclusion

Message [msg 443] is a textbook example of how the most critical infrastructure decisions often hide behind the most mundane commands. A simple apt install of three packages—build-essential, pve-headers, and dkms—represents the culmination of careful diagnosis, the correction of repository misconfiguration, and a strategic bet on the LXC approach over the KVM approach for GPU passthrough. It demonstrates the assistant's methodical approach to problem-solving: assess the current state, fix foundational issues (apt sources), install prerequisites, and only then proceed to the main task (NVIDIA driver installation).

The message also reveals the layered nature of technical decision-making in complex ML infrastructure deployments. Each choice—from the kernel version to the driver version to the virtualization technology—creates dependencies and constraints that ripple through the entire system. The assistant's ability to trace these dependencies backward (from a failed nvidia-smi to missing kernel headers to misconfigured apt sources) and forward (from package installation to DKMS registration to driver compilation to CUDA initialization) is the essence of the engineering thinking captured in this session.

In the end, the build dependencies installed in this message would enable the NVIDIA driver to compile and load successfully. The GPUs would become visible inside the LXC container. The topology would show NODE and SYS—the bare-metal connectivity that the team had been seeking. But a new barrier would emerge at the CUDA runtime layer, proving that in the world of bleeding-edge hardware and virtualization, no single fix ever solves the whole problem. Each step forward reveals the next challenge, and the build dependencies installed in this message were merely the first step on a path that would lead to deeper investigations of GSP firmware, kernel compatibility, and the unique demands of Blackwell GPUs in virtualized environments.