Proxmox VM Setup: Firmware, GPU Passthrough & Live Migration

I've been running Proxmox VE for years across homelabs and small production clusters, so I know what actually works under real workloads — not just textbook setups that look good on paper but break when things get busy or users start clicking around in unexpected ways.

Key Takeaways

• Boot time matters more than you think — a properly tuned VM boots noticeably faster with the right firmware and disk settings, which saves headaches during reboots.
• IOMMU grouping is the single most important factor for GPU passthrough success; if your devices aren't grouped correctly, nothing else will matter.
• PCIe topology determines whether a device can actually be passed through — you need to understand how your motherboard routes PCIe lanes before buying hardware.
• qemu-guest-agent is not optional when doing live migration or hot-plugging; it coordinates shutdown and resource changes between host and guest.

How Do I Choose the Right Firmware for My VMs?

The firmware choice for a Proxmox VM determines how your virtual machine boots — UEFI vs SeaBIOS (the traditional BIOS equivalent) — and affects everything from boot time to whether you can attach certain devices like GPUs or NVMe drives. For most modern workloads, UEFI is the better default because it handles larger disks natively, supports Secure Boot when needed, and gives you a graphical pre-boot menu that makes configuration easier than scrolling through SeaBIOS options with a keyboard.

To create a VM with UEFI firmware from the command line:

qm create 100 --name win11-vm \
  --bios ovmf \
  --cpu host \
  --memory 8192 \
  --net0 virtio,bridge=vmbr0 \
  --scsihw virtio-scsi-pci \
  --ostype l26

The --bios ovmf flag tells Proxmox to use the Open Virtual Machine Firmware package. You'll also want to point it at a UEFI variables file so persistent settings survive reboots:

# /etc/pve/qemu-server/100.conf (relevant excerpt)
bios: ovmf
efidisk0: local-lvm:0,efitype=4m,size=4M

The efitype=4m option creates a 4-megabyte EFI variable store — this is where UEFI keeps boot entries and firmware settings. The default of 128 megabytes for older setups works fine too, but you rarely need that much space unless you're doing multi-boot configurations inside the VM itself.

I've found SeaBIOS still has a place in specific scenarios: it's slightly faster to boot because there's less initialization overhead, and it handles legacy PCI devices more gracefully than OVMF does in some edge cases. If you're running an older Windows version like Server 2016 or a Linux distribution that boots reliably with BIOS-only drivers, SeaBIOS remains perfectly valid.

Why Does GPU Passthrough Fail on My Second Monitor?

This is the most common frustration I see people hit when setting up GPU passthrough in Proxmox — their VM starts but the host display manager crashes because it can't talk to the card anymore. The root cause usually comes down to one of three things: improper IOMMU grouping, missing driver isolation, or not detaching all functions of a device before passing it through.

Let's look at how to check your IOMMU groups first. Run this on your Proxmox host:

lspci -vnn | grep VGA -A 12 --color=auto
dmesg | grep -i iommu
cat /sys/kernel/iommu_groups/*/devices/* | sed 's/.*\/\(pci[0-9]*\) \/\(device\).*$/\1/' | sort -u

The third command gives you a clean list of which devices share IOMMU groups. If your GPU and its associated audio controller are in the same group, that's usually fine — Proxmox will pass through the entire group together. But if other critical host devices (like SATA controllers or USB hosts) land in the same group as your GPU, you might need to use pcie_acs_override in your kernel parameters:

# /etc/default/grub
GRUB_CMDLINE_LINUX="amd_iommu=on iommu=pt pcie_acs_override=downstream,multifunction"
update-grub
reboot

The iommu=pt option enables pass-through mode, which is important for performance. Without it, the IOMMU translates addresses even when the device is passed through entirely to a VM, adding latency on every memory access — this matters most when you're running workloads with high memory bandwidth requirements like video transcoding or database operations.

After rebooting, verify your GPU appears in an isolated group:

lspci -v | grep -A 10 "VGA\|3D" 
# Look for the line showing your driver as vfio-pci instead of nvidia/kms/radeon

You'll want to bind your GPU and its companion audio device to vfio-pci before starting the VM. Add this to /etc/modules:

vfio-pci
vfio_iommu_type1
vfio_virqfd
vfio_pci

Then blacklist the native drivers:

# /etc/modprobe.d/vfio.conf
blacklist nvidiafb
blacklist nouveau
options vfio-pci ids=10de:2487,10de:2215

Replace those IDs with your specific GPU and audio device PCI IDs from lspci -nn. The comma-separated list tells vfio-pci which devices to bind at boot.

What's the Difference Between USB Passthrough and PCIe Passthrough?

When you pass through a device in Proxmox, it leaves the host entirely and attaches directly to your VM — but there are two fundamentally different mechanisms, each with distinct tradeoffs that affect performance, reliability, and flexibility depending on what hardware you're using.

Feature	USB Passthrough	PCIe (VFIO) Passthrough
Performance impact	~5-10% CPU overhead for emulation	Near-native when IOMMU is configured correctly
Hot-plugging support	Full hot-plug from Proxmox UI	Requires VM shutdown or live migration with proper setup
Device types supported	Any USB device (webcams, GPUs via USB)	Only PCI/PCIe devices (GPUs, NVMe, network cards)
IOMMU dependency	Not required	Required for reliable passthrough
Best use case	Peripherals, capture cards, external drives	Dedicated GPU, high-bandwidth storage, NICs

For most homelab and production workloads where you're doing true hardware acceleration — whether that's running a Windows VM with NVIDIA CUDA support or passing through an M.2 NVMe drive for low-latency database operations — PCIe passthrough is the superior choice despite being slightly more complex to set up initially. USB passthrough works well enough for occasional use cases but introduces noticeable latency under sustained load because every I/O request goes through the host's USB stack twice (once from guest, once from host).

How Do I Set Up Live Migration Without Losing Data?

Live migration in Proxmox moves a running VM from one node to another with minimal downtime — typically less than 10 seconds for most workloads depending on RAM size and network bandwidth. The key requirement is shared storage accessible by all cluster nodes, which means your setup needs either NFS, Ceph, GlusterFS, or local disks mounted identically across the cluster.

To perform a live migration from the CLI:

qm migrate 100 --target proxmox-node2 --online \
  --with-local-disks --migration-type xbzrle

The --online flag is what makes it "live" — without it, Proxmox will shut down the VM and restart it on the target node (which works fine but causes downtime). The xbzrle migration type compresses memory pages during transfer, reducing bandwidth requirements by up to 70% compared to uncompressed migration.

For large RAM configurations (32 GB or more), you'll want to monitor the migration progress:

qm monitor 100 --command info migrate
# Output shows bytes transferred, total time, and remaining data

The biggest gotcha I've encountered is ensuring that both nodes have identical CPU types. If one node has an older AMD EPYC and another has a newer Zen 4 chip with different instruction sets, you may need to set the VM's CPU model explicitly:

qm set 100 --cpu host \
  --cpulimit 8 \
  --sockets 1 \
  --cores 8

Setting --cpu host means the guest sees exactly what the underlying hardware offers, which is generally preferable for most workloads. The tradeoff here is that if you migrate to a node with significantly different CPU features, some optimizations may be lost — but this rarely matters unless you're running highly specialized applications like database engines or compilers that heavily use specific instruction sets (AVX-512, SSE4.2, etc.).

What's the One Thing Most People Get Wrong About Proxmox VMs?

After years of watching people configure their virtual machines — both in homelabs and production environments — I've seen one pattern repeat consistently: they treat VM configuration as a "set it once" decision rather than something that should evolve with your workload. Specifically, most people don't realize how much impact disk scheduling has on overall performance for database workloads or applications doing heavy random I/O.

By default, Proxmox uses virtio-scsi as the SCSI controller type because it's flexible and supports hot-plugging — but for pure storage workloads where you're not adding devices dynamically, switching to raw virtio-blk can improve throughput by 15-20% on NVMe-backed storage. The tradeoff is that you lose some features like live migration compatibility with certain configurations and the ability to add disks without rebooting.

For database workloads specifically (PostgreSQL, MySQL, or even Redis), I recommend this configuration:

# /etc/pve/qemu-server/100.conf
scsihw: virtio-scsi-single  # Use single instead of PCI for better performance on modern kernels
virtio_ssd: 'on'
cache: none  # Let the guest OS handle caching; host-side cache can cause double-caching issues
aio: threads  # For NVMe storage, use 'threads'; for traditional SATA/HDD, use 'native'

The aio setting is particularly important — it controls whether Proxmox uses asynchronous I/O and which backend implementation to use. On modern kernels with ZFS or ext4 on SSDs, threads generally provides the best balance between CPU efficiency and latency characteristics.

Conclusion

Choosing the right firmware, understanding your IOMMU groups, and matching disk configurations to workload patterns are the three things that will give you the most bang for your buck when setting up Proxmox VMs — far more than any single "must-have" feature or tool. Start with UEFI OVMF as your default, verify GPU passthrough works before buying expensive cards, and don't ignore disk scheduling even if it seems like a small detail until you're troubleshooting why your database is slower than expected on SSD-backed storage.

If you want to explore further, check out Configure Parallel Sync Jobs for S3 Offsite Backups to understand how backups interact with live migration workloads, or read through How to Set Up a Proxmox Cluster: Complete Two-Node Guide if you're planning to scale beyond a single node.