PCIe Passthrough: How to Assign a GPU or Network Card Directly to a VM

What Is PCIe Passthrough and Why It Matters

When running a virtual machine, we typically rely on simulated components generated by the underlying host management software. If you need a heavy-duty graphics card to edit videos or train machine learning models inside that virtual machine, this simulation creates a massive performance bottleneck, making the system feel sluggish. This is where PCIe Passthrough comes in, a technology that takes a physical piece of hardware—like a graphics processing unit or an ultra-fast network card—and assigns it entirely, without intermediaries, directly into the virtual machine. In practice, this means the operating system inside the virtual machine perceives the hardware as if it were plugged directly into its own motherboard.

The primary benefit of this approach is near-native performance, as we eliminate the translation layer that processes commands between the virtual machine and the real world. The price we pay for this raw speed is exclusivity: once you assign the hardware to a virtual machine, the main host computer loses access to it. This setup is widespread in cloud computing servers running heavy data workloads, in network testing labs requiring precise packet delivery speeds, and even among enthusiasts running demanding games on Linux using a virtualized Windows instance.

Behind the Scenes: IOMMU, Groups, and Hardware Isolation

To understand how passthrough operates, we must examine a component called IOMMU (Input-Output Memory Management Unit), which is essentially a chip or processor feature that organizes memory traffic for devices connected to the computer. Think of the IOMMU as an intelligent traffic officer ensuring that each device accesses only its designated memory region, preventing a misbehaving card from corrupting the main operating system's data. Without the IOMMU, physically separating hardware for virtual machine allocation without destabilizing the rest of the computer would be impossible.

The crucial technical detail that catches many administrators by surprise is IOMMU group organization. Motherboard manufacturers often group multiple distinct components—such as USB controllers, audio chips, and graphics cards—into the exact same internal communication route. If you attempt to isolate just the graphics card while it shares a group with an essential USB controller, the system will refuse to separate them. In practice, this means planning your hardware layout before building a passthrough rig is a mandatory step to avoid bonded components that cannot be split apart.

Preparing the Ground: BIOS, Kernel, and Boot Parameters

Before touching any code, the first mandatory step takes place in the motherboard BIOS, the basic configuration panel that runs before the operating system loads. There, you must locate and enable hardware virtualization options, which appear as Intel VT-d on Intel processors and AMD-Vi on AMD processors. Without turning on these primary switches, the processor will simply reject any attempt to isolate components for exclusive virtual machine usage.

Once the BIOS is configured, the next step instructs the main operating system to reserve those resources and avoid controlling them at boot time. On Linux systems, for instance, we edit the kernel boot parameters by adding specific commands that enable IOMMU support and isolate the default graphics driver. The snippet below demonstrates how these parameters are typically appended to the GRUB bootloader configuration file:

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash intel_iommu=on iommu=pt vfio_iommu_type1.allow_unsafe_interrupts=1"

After applying this modification, you must update the bootloader using the command specific to your distribution, such as update-grub, and reboot the machine so the operating system kernel adopts the new memory isolation and interrupt rules.

Identifying and Unbinding Target Devices

Once the system restarts with IOMMU support enabled, the next challenge is discovering the exact address of the hardware we want to transfer. We use command-line tools to list the computer's PCI buses and inspect the detailed structure of each installed card. The lspci command, when combined with filters, reveals the unique identifier code of each component, consisting of a vendor number and a device number.

The unbinding process requires us to prevent the host operating system from loading standard drivers for that specific card. Instead, we instruct the system to load a generic driver called VFIO (Virtual Function I/O), which acts as a neutral transport layer. The following code block demonstrates how we can map and verify IOMMU groups using a simple shell script to ensure our target graphics or network card is isolated properly:

#!/bin/bash
for g in /sys/kernel/iommu_groups/*; do
    echo "IOMMU Group ${g##*/}"
    lspci -n -s "$(ls -d $g/devices/* | awk -F'/' '{print $NF}')"
done

If the target card resides alone within its IOMMU group, the path is clear to proceed with virtual machine configuration. Otherwise, you must physically move the card to a different PCIe slot on the motherboard or adjust advanced BIOS settings related to PCIe port mapping.

Configuring the Virtual Machine on the Hypervisor

With the hardware properly isolated and bound to the VFIO driver, the subsequent step takes place inside the virtual machine manager, which can be KVM/QEMU utilizing the virt-manager utility or Proxmox VE. Within the management interface, we add a new hardware device of type 'Host Device' and select the exact card mapped previously. It is important to ensure that the virtual machine configuration file receives additional parameters to mask the fact that it runs inside a virtualized environment, which is especially useful for NVIDIA graphics cards that often reject drivers if they detect a hypervisor presence.

Manual XML editing of the virtual machine configuration in QEMU/KVM enables fine-tuning to ensure total stability during prolonged use. We must ensure that 'MSI' (Message Signaled Interrupts) support remains active to prevent hardware interrupt conflicts that freeze the system. When everything is configured correctly, the virtual machine powers on and the guest operating system instantly recognizes the hardware, installing proprietary drivers precisely as it would on a conventional physical computer.

Final Thoughts and Performance Optimizations

PCIe Passthrough radically transforms the utility of a virtualized infrastructure by removing performance barriers in heavy workloads. However, we must keep in mind the operational costs of this choice, such as losing the ability to take complete snapshots with the card's state saved, or the impossibility of live-migrating the virtual machine to another physical server without shutting it down first. Evaluating these trade-offs ensures the technology is deployed in the correct scenario, delivering raw computing power exactly where it is needed most without sacrificing overall environmental stability.