The Critical Glimpse: Reading Proxmox PCI Mappings in a GPU Passthrough Investigation

In the middle of a highly technical optimization session focused on deploying massive language models across 8 NVIDIA RTX PRO 6000 Blackwell GPUs, a seemingly mundane command appears. Message [msg 5757] in this opencode conversation is a single bash invocation:

ssh root@10.1.2.6 'cat /etc/pve/mapping/pci.cfg 2>/dev/null'

The output reveals the contents of a Proxmox VE PCI device mapping configuration file, showing entries for several GPU models: nv3080, nv3090, nv3090-2, nv3090-3, nva6000, nva6000-2, and a truncated entry for what appears to be another mapping. On its surface, this is a trivial operation — a remote file read. But within the arc of the conversation, this message represents a pivotal moment of discovery, a hinge point where the assistant transitions from pure reconnaissance to actionable understanding of the host's GPU virtualization infrastructure.

The Context: A Tangent Experiment Demanding Infrastructure Insight

To understand why this message matters, we must trace the events that led to it. The session had been consumed with an intense, multi-hour effort to deploy and optimize the Kimi-K2.5 INT4 model using SGLang with EAGLE-3 speculative decoding ([msg 5736] through [msg 5751]). The team had just successfully hardened the production deployment with a systemd service, enabled hierarchical KV cache with a 4.0 ratio consuming 358 GB of pinned host memory, and verified that the model was generating correct outputs with tool calls and reasoning content properly parsed.

Then the user pivoted abruptly in [msg 5752]:

"Doing a tangent experiment on the proxmox node - 10.1.2.6, 10.1.16.221 guest vm; Because it's now a VM and not a container do we need to unload nvidia driver on host? Blacklist and reboot? How can we make this sort of switch reasonably painless?"

This question reveals the user's core concern: they want to pass all 8 Blackwell GPUs from the Proxmox host to a virtual machine, but they're uncertain about the mechanics. The LXC container (CT 129, named "llm-two") had been the primary consumer of these GPUs throughout the session. Now the user wants to experiment with a VM instead, and they instinctively know this requires changes to how the host's NVIDIA driver interacts with the GPUs.

The assistant responded in [msg 5753] by asking clarifying questions — specifically whether all 8 GPUs should go to the VM or if they should be split. The user confirmed "All 8 GPUs to VM," meaning the LXC container would stop and the VM would get exclusive access. This set the stage for a full infrastructure investigation.

The Investigation Unfolds

The assistant's reconnaissance in [msg 5754] revealed the current state: the NVIDIA driver stack was fully loaded on the host (nvidia, nvidia_uvm, nvidia_modeset, nvidia_drm), and all 8 GPUs were visible as PCI devices. In [msg 5755], the assistant checked the kernel command line and found that IOMMU was already enabled (iommu=pt), and VFIO had been used previously — promising signs that GPU passthrough infrastructure was already in place.

Then came the critical discovery in [msg 5756]. The assistant examined the Proxmox VM configuration files and found that VM 131 ("ml-pipelines") already had all 8 GPUs mapped via hostpci0 through hostpci7, each referencing mapping=pro6000. This was a bombshell: someone had already configured GPU passthrough for these Blackwell GPUs, using a named mapping called "pro6000." But where was this mapping defined?

Message 5757: The Defining Read

This brings us to the subject message. The assistant issues a command to read /etc/pve/mapping/pci.cfg on the Proxmox host. This file is the central registry for PCI device mappings in Proxmox VE — it defines symbolic names that map to physical PCI device IDs, IOMMU groups, and host nodes. When a VM configuration references mapping=pro6000, the hypervisor looks up this file to find which physical GPU to assign.

The output reveals a history of GPU mappings on this host:

nv3080
    map id=10de:2204,iommugroup=72,node=kpro4,path=0000:43:00,subsystem-id=1043:87d5

nv3090
    map id=10de:2204,iommugroup=20,node=kpro5,path=0000:53:00,subsystem-id=1043:87d5

nv3090-2
    map id=10de:2204,iommugroup=24,node=kpro5,path=0000:57:00,subsystem-id=1043:87d5

nv3090-3
    map id=10de:2204,iommugroup=50,node=kpro5,path=0000:d6:00,subsystem-id=1043:87d5

nva6000
    map id=10de:2230,iommugroup=16,node=kpro5,path=0000:4f:00,subsystem-id=10de:1459

nva6000-2
    map id=10de:2230,iommugroup=43,nod...

The output is truncated — it cuts off mid-entry on nva6000-2. Critically, the pro6000 mapping that VM 131 references is not visible in the shown output. This could mean several things: the pro6000 mapping appears later in the file (after the truncation point), or it was defined in a separate configuration file, or the mapping was created through a different mechanism.

The Reasoning Behind the Command

The assistant's thinking process here is methodical and detective-like. Having discovered that VM 131 references a pro6000 mapping, the natural next question is: what physical devices does this mapping correspond to? The PCI mapping file is the canonical source of truth for this information in Proxmox. Reading it serves multiple purposes:

Validating existing configuration: If the pro6000 mapping exists and correctly points to the 8 Blackwell GPUs (device ID 10de:2bb5 based on earlier lspci output), then the passthrough infrastructure is already in place and the user's experiment may only require stopping the LXC container and starting the VM.
Understanding the mapping scheme: The existing entries reveal a naming convention — nv3080, nv3090, nva6000 — suggesting these are shorthand for GPU models. The pro6000 name likely follows the same pattern, referring to the RTX PRO 6000 Blackwell GPUs.
Identifying gaps: If the pro6000 mapping doesn't exist or points to wrong devices, the assistant would need to create or fix it.
Learning from history: The presence of mappings for older GPU generations (RTX 3080, RTX 3090, RTX A6000) tells the assistant that this host has been through multiple GPU generations and has a well-maintained passthrough setup.

Assumptions and Their Implications

The assistant makes several assumptions in issuing this command. First, it assumes that the PCI mapping configuration is stored in the standard Proxmox location (/etc/pve/mapping/pci.cfg). This is a safe assumption — Proxmox VE uses a clustered filesystem (pmxcfs) that stores configuration files under /etc/pve/, and PCI mappings are a documented feature.

Second, the assistant assumes that the pro6000 mapping referenced in VM 131's configuration is defined in this file. This assumption is partially validated — the file clearly contains GPU mappings — but the truncation of the output leaves ambiguity. The mapping might exist later in the file, or it might have been configured through a different mechanism (e.g., directly specifying PCI IDs in the VM config without a named mapping, though the VM config clearly uses mapping=pro6000).

Third, the assistant assumes that reading this file will provide actionable information for the next steps. This is correct — even with truncated output, the assistant now knows the format of the mapping entries, the naming conventions used, and the fact that the host has a history of GPU passthrough. This knowledge informs the next steps: either finding the full mapping definition, or creating a new one if needed.

Input Knowledge Required

To fully understand this message, one needs several layers of context:

Proxmox VE architecture: Knowledge that Proxmox uses a distributed filesystem (pmxcfs) and stores configuration files under /etc/pve/. Understanding that PCI mappings are a Proxmox feature that abstracts physical PCI devices into named resources for VM assignment.
GPU passthrough mechanics: Understanding that for GPU passthrough to work, the host must not bind the GPU to its native driver (nvidia). Instead, the GPU must be bound to the vfio-pci driver, which makes it available for assignment to a VM. This requires either unloading the nvidia driver or blacklisting it at boot.
IOMMU and VFIO: Knowledge that IOMMU (I/O Memory Management Unit) must be enabled in the kernel for PCI passthrough, typically via the iommu=pt kernel parameter. VFIO (Virtual Function I/O) is the kernel framework that enables userspace drivers for device passthrough.
The conversation's history: Understanding that the session has been about deploying LLMs on 8 Blackwell GPUs, that the LXC container has been the primary consumer, and that the user now wants to experiment with a VM.
PCI device IDs: Recognizing that 10de:2204 is an RTX 3090 (the earlier lspci showed 10de:2bb5 for the Blackwell GPUs), and that the subsystem-id and iommugroup fields identify specific physical slots.

Output Knowledge Created

This message produces several valuable pieces of knowledge:

The host has a mature GPU passthrough setup: The presence of mappings for multiple GPU generations (3080, 3090, A6000) across different host nodes (kpro4, kpro5) indicates that this infrastructure has been used extensively.
The mapping naming convention: Mappings follow a pattern of nv{model} or nva{model} — shorthand for NVIDIA GPU model names. The pro6000 mapping likely follows this convention.
The format is standard Proxmox: Each mapping entry contains a device ID (id=), IOMMU group, host node, PCI path, and subsystem ID — all standard fields for Proxmox PCI mappings.
The mapping file may be incomplete or truncated: The output cuts off, meaning the full picture is not yet visible. The assistant would need to either read the full file or use a different approach (e.g., grep pro6000) to find the specific mapping.
The host supports multiple GPU generations: The same host (kpro5) has hosted RTX 3090s and RTX A6000s, suggesting the PCIe slots and IOMMU groups are compatible across generations.

The Broader Significance

This message, while technically trivial, represents a critical moment in the conversation's infrastructure investigation. It's the point where the assistant moves from asking "what's the current state?" to "what's been configured that we can leverage?" The discovery that GPU passthrough mappings already exist — potentially including the pro6000 mapping for the Blackwell GPUs — transforms the problem from "how do we set up passthrough from scratch?" to "how do we activate and use the existing passthrough configuration?"

The truncated output is itself significant. It creates a knowledge gap that the assistant must address in subsequent messages. The pro6000 mapping might be defined in the unseen portion of the file, or it might not exist at all. Either way, the assistant now has a clear next step: find the full definition of the pro6000 mapping.

In the broader narrative of the session, this message is part of a larger pattern: the assistant methodically probes the system's configuration, building a mental model of the infrastructure before making changes. Earlier in the session, we saw similar patterns when investigating CUDA versions, NCCL tuning parameters, and flash-attn build configurations. This systematic reconnaissance is a hallmark of the assistant's approach — gather data, build understanding, then act with precision.

Conclusion

Message [msg 5757] is a study in how even the simplest commands can carry enormous weight in a complex technical conversation. A single cat command over SSH, reading a configuration file, reveals the accumulated history of GPU passthrough on a Proxmox host. It transforms the user's question from "how do we set this up?" to "how do we use what's already here?" The truncated output creates a mystery — where is the pro6000 mapping? — that drives the investigation forward. In the hands of a skilled technical operator, even reading a file becomes a strategic act of discovery.