All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
MSFS on Proxmox with GPU Passthrough (DXGI HANG) - $100 Bounty
Hello LET Community,
I'm reaching out for some help with my new homelab. I'm trying to move away from bare-metal Windows, because frankly, Windows is just a mess as a virtualization host. My goal is to use Proxmox VE as my main OS and run a high-performance Windows VM for gaming.
As detailed in my previous thread, "Overcoming Hardware Hurdles: My Journey From Rented Servers to an ITX Homelab", I've got the hardware sorted.
The Problem
I've successfully configured VFIO and passed my RTX 4070 Ti Super to a Windows VM. The guest OS recognizes the GPU correctly, but Microsoft Flight Simulator is giving me major headaches:
- Microsoft Flight Simulator 2024: Fails during loading with a
DXGI_ERROR_DEVICE_HUNGerror. - Microsoft Flight Simulator 2020: This ran when I tested it last year, but the performance was terrible with unplayably low FPS.
Both simulators run flawlessly on the same machine with a bare-metal Windows install, so I'm confident the issue lies within my Proxmox/VM configuration.
My Setup
Here's a look at the hardware and software I'm using:
- Motherboard:
ROG STRIX B650-I - CPU:
AMD Ryzen 9 9950X3D - GPU (Passthrough):
ASUS Dual RTX 4070 Ti Super OC 16G - RAM:
96GB - Storage:
Two GM7 4TB M.2 drives, a BX500 1TB, plus an MX500 500GB boot drive - Hypervisor:
Proxmox VE 8.4
The Bounty: $100 via PayPal
I've been stuck on this for a while and I'm willing to reward whoever can solve it.
I am offering a $100 bounty via PayPal to the person who provides the specific steps, configuration, or solution that gets Microsoft Flight Simulator running smoothly in the VM.
Any advice on what to try next would be greatly appreciated.
Thank you!
Comments
Could it maybe be that you're only passing part of the GPU "functions" through and not the entire PCI-E device?
Few things I'd check would be verifying you disabled proxmox from utilizing your gpu and that you are passing through all GPU functions(usually will be GPU *:00 then audio for GPU *:01)
this might be an easy fix, which pci-e slot are you using on for motherboard?
nvm, it only has 1 pci-e port
Do other 3d apps/games work in the vm? Like does 3dmark tests complete or something like unigine heaven work?
Sadly, this is code for "shrug dunno mate". Could literally be anything. Faulty VRAM, not enough VRAM, timeout, invalid operation, too much put on the command queue, etc...
As @james50a said, there's almost certainly an audio device there (for over HDMI), but possibly other things too.
I'm assuming you've blacklisted the PCI device on the host so that it doesn't load the module for it. If you've not done that, you'll have problems passing it to the guest.
Have a look using
lspcion the host to find the card (ideally before blacklisting the device and trying to share with guest), and once you've found it have a look at its IRQ e.g.cat /sys/bus/pci/devices/0000:00:03.2/irqand then find any devices with the same IRQs and make sure they're also blacklisted and forwarded to the host, e.g.grep 26 /sys/bus/pci/devices/*/irq. Also forward anything that looks like it's on the same device level, because otherwise you risk having both host and client attempting to drive the same part of the GPU via different devices.You might have to dump the VGA firmware and manually add that to the client too. Without that, maybe it can present as a dumb VGA card but crash as soon as something tries to render using the GPU. I'd have thought Windows would have already used the GPU before it got to that point though.
I could never understand why someone would want their daily driver to be a VM host with VM passthrough. Get a fucking server to do server things, get a workstation to do workstation things.
Less fucking mess.
Mind running dxdiag to see if anything is not supported but suppose to be?
you need the right bios in your vm or nvidia drivers lock down because consumer cards are not allowed to run in vm. that's the most probably cause of your error message or pciE passthru is not setup correctly. this can be a mess.
You hoping you'd get better? performance than with windows directly installed... forget it. you will have microstuttering and audio de-syncs... it's just not worth the hassle… keep windows for playing... on a seperated disk... boot it when you wanna play. else stick to linux as desktop... for working!
As far as I’m aware, it’s fine to passthrough a consumer card to a VM. The problem is splitting it across multiple VMs.
had been years ago and I had to lookup again: you need an UEFI bios in the vm (OVMF) or nvidia drivers will not work properly. there might be some kernel boot flag missing like iommu. you mainboard must have full iommu support enabled, vt-d and so on.
https://pve.proxmox.com/wiki/PCI_Passthrough
blacklisting drivers, nvidia, nouveau, vesa can help. if linux loads gpu drivers your vm will no run correctly or passthru does not work at all or drops out.
no brag but i have better cpu and gpu and MS2024 runs lets's say: it runs... but MS is a beast. I dunno wanna know how it feels in a vm... when you tested with 2020 and fps was bad, why do you think it'll run better with new fs?
Yes. 3D Mark is fine.
For some reasons,LET is not sending reply notifications to my Gmail, thanks for all the replies
Asobo studio said they used an updated engine in 24. thats make my second try.
In my experience, MSFS is more finicky than normal GPU-heavy games, which are already pretty finicky.
So if you have a 4080+ video card, MS2024 should (pun incoming) fly, no? I haven't upgraded from 2020 myself.. You may not be able to turn up rendering every single blade of grass but...req for MS2024 is a 3070.
Will post when I get home. Thanks
this is what worked for me for Windows GPU passthru with proxmox
basically, you have to blacklist all the modules you passtru
and set vfio (if I remember correctly)
Here is my current vfio config
cat /etc/modprobe.d/vfio.conf
options vfio-pci ids=10de:2705,10de:22bb
softdep nouveau pre: vfio-pci
softdep nvidia pre: vfio-pci
softdep nvidiafb pre: vfio-pci
softdep nvidia_drm pre: vfio-pci
softdep drm pre: vfio-pci
Will give blacklist a shot and report it back,, thanks
dxdiag shows all activated (sorry for it isn't in English) , Just FYI, for the sudoVDA, I'm using Apollo, that's why. Thanks.
Hehe, I just meant that I encounter
DXGI_ERROR_DEVICE_HUNGmultiple times per day (I'm a graphics developer for games, doing lots of hacky experimental things with raytracing) and it's literally just signalling that the GPU gave up doing whatever it was doing with an error, but provided no information as to why. Back in the day, that mostly indicated a GPU crash or a shader that never terminated, but there can be many reasons now, e.g. writing to an bound render target that got unmapped somehow, etc. All it really tells you is that something went wrong and the GPU firmware didn't know how to recover.I think you really need to blacklist the devices.
not partition the gpu for between multiple VMs, but just passhtru to one VM.
Worked for me, with the settings I posted.
Installed nvidia drivers, played games and all.
One thing you need is either a connected monitor, or a dummy hdmi plug that simulates a plugged monitor, if you want to play remote (sunshine/moonlight streaming).
The first DXGI HANG issue has been solved, I forgot to tick the PCI Express tickbox. My bad.
Now it's working, but I faced https://forum.level1techs.com/t/good-benchmarks-poor-gaming-performance-w-rtx-4090-vfio-proxmox/215088 problem, my gpu usage it's low, so resulting low fps, i'm guessing core pinning issues maybe?
But at least improving.
Here's my vm conf if it helps
G:/home/l# cat /etc/pve/qemu-server/100.conf
affinity: 0-15
bios: ovmf
boot: order=virtio0;ide0;net0
cores: 16
cpu: host
efidisk0: local-zfs:vm-100-disk-1,efitype=4m,pre-enrolled-keys=1,size=1M
hostpci0: 0000:01:00,pcie=1,x-vga=1
ide0: none,media=cdrom
machine: pc-q35-9.2+pve1
memory: 32768
meta: creation-qemu=9.2.0,ctime=1752965706
name: Windows
net0: virtio=BC:24:11:65:B7:FD,bridge=vmbr0,firewall=1
numa: 1
onboot: 1
ostype: win11
scsihw: virtio-scsi-single
smbios1: uuid=64ea7622-afea-4da0-bbb5-9947461cac19
sockets: 1
tpmstate0: local-zfs:vm-100-disk-2,size=4M,version=v2.0
usb0: host=1d6b:0104
virtio0: local-zfs:vm-100-disk-0,iothread=1,size=300G
virtio1: local-zfs:vm-100-disk-3,discard=on,iothread=1,size=750G
virtio2: local-zfs:vm-100-disk-4,discard=on,iothread=1,size=150G
virtio3: local-zfs:vm-100-disk-5,discard=on,iothread=1,size=150G
args: -machine hpet=off -cpu 'host,topoext=on'
Does this qualify me for the $100 bounty? 😄
Kidding, hope you'll get it to work properly
I fixed with the help of Perplexity Deep Research and Google Gemini.
Proxmox VE Gaming VM: In-Depth Performance & Stability Optimization Analysis Report
Date: August 2, 2025
Project Objective: To resolve severe performance degradation and system instability for a Windows 11 gaming VM running on Proxmox VE, equipped with an AMD Ryzen 9 9950X3D CPU and an NVIDIA RTX 4070 Ti SUPER GPU.
Initial State: In-game GPU utilization was critically low (~30%), performance was a fraction of its potential, and the VM was subject to random, unrecoverable crashes.
Final Outcome: GPU utilization under heavy load now consistently reaches 97%, achieving near-native gaming performance. The virtual machine operates with complete long-term stability.
1. Core Problem Diagnosis
The initial analysis concluded that the root cause was not a failure of the GPU passthrough itself, but rather a severe CPU bottleneck compounded by a critical stability issue. Despite allocating a significant number of cores to the VM, the virtualization layer was failing to correctly manage the Ryzen 9 9950X3D's unique hybrid architecture (3D V-Cache CCD vs. High-Frequency CCD).
This manifested in two primary problems:
Furthermore, the random VM crashes pointed towards a lower-level hardware interrupt handling or firmware compatibility conflict.
2. Systematic Optimization Strategy & Implementation
A multi-layered optimization strategy was employed, addressing performance bottlenecks first, followed by stability hardening.
Phase 1: CPU Resource Layer Optimization (The Decisive Factor)
This phase was the most critical and yielded the most significant performance gains. The objective was to isolate and dedicate the specialized 3D V-Cache CCD exclusively to the gaming VM.
lscpu -eandcat /sys/devices/system/cpu/cpu0/cache/index3/size, we performed a data-driven verification to conclusively identify the 96MB 3D V-Cache CCD as being located on physical cores0-7(logical threads0-7&16-23). This eliminated all guesswork and formed the foundation for precision tuning.affinity): The VM was configured withaffinity: 2-7,18-23. This locked the VM's 12 vCPUs squarely onto the V-Cache CCD, while strategically reserving cores0and1for the Proxmox host to handle system interrupts, thereby minimizing host-guest interference.numa: 1): This setting exposed the tightly-coupled core group to the guest OS as a single NUMA node. This allowed the Windows scheduler to optimize its internal thread and memory placement policies, ensuring all critical game computations remained within the fast V-Cache domain.Phase 2: Memory & I/O Subsystem Optimization (Foundation Hardening)
hugepages: 2): Enabled 2MB memory pages to significantly reduce TLB (Translation Lookaside Buffer) pressure and lower memory access latency for the large memory allocation.balloon: 0): Disabled dynamic memory reclamation by the host, guaranteeing a stable and non-revocable memory pool for the VM, which is critical for gaming.discard=on(TRIM/UNMAP) andiothread=1for all ZFS-based virtual disks to improve long-term SSD performance and I/O throughput.Phase 3: Stability Troubleshooting (Critical Error Resolution)
With performance addressed, we tackled the VM crashes, which presented with a fatal
kvm: ... pci_irq_handler: Assertion ... failed.error.rombar=0): By addingrombar=0to thehostpci0directive, we instructed Proxmox to completely ignore the GPU's Option ROM. This bypassed the firmware conflict, allowing the in-guest NVIDIA driver to initialize the hardware from a "clean slate," thereby providing full, stable control and completely resolving the crashes.4. Final Results & Performance Comparison
5. Conclusion
This project was a textbook success in advanced VFIO tuning. It demonstrates that achieving high-performance, stable gaming on Proxmox VE is entirely feasible but requires a deep understanding and precise control of the underlying hardware architecture.
The success was predicated on:
1. Data-Driven Decisions: Precisely locating the V-Cache CCD with system commands rather than relying on assumptions.
2. A Holistic Approach: Addressing both the macro-level strategic problem (CPU core pinning) and the micro-level but critical detail (the
rombar=0stability fix).3. Systematic Elimination: Methodically identifying and resolving each bottleneck, from performance to stability.
The final result is a "Golden Standard" configuration for this high-end hardware combination, establishing a robust and powerful foundation for any virtualization task.
Appendix: Final Golden Standard Configuration (
/etc/pve/qemu-server/100.conf)If you don't mind taking some part of it, feel free to PM Your PayPal account.> @devjorge said:
You're welcome to PM too.
@jason5545 thanks for reporting back in detail, lots of people don't do that when they find a solution.
Could you add infos about your final grub settings, vfio, blacklist/modprobe config as well?
Had my own run-ins with passthru and there is lots of rather useless suggestions floating around which makes it so hard to cut through and find the real solutions.
Will do it after I restore all my flightsim addons.
The Ultimate Guide to Proxmox VE Gaming VM Optimization and Troubleshooting
Date: August 2, 2025
Hardware Platform: AMD Ryzen 9 9950X3D (Host), NVIDIA RTX 4070 Ti Super (VM Passthrough), AMD iGPU (Used by LXC)
Project Goal: To resolve boot stability issues, performance bottlenecks, and random crashes in a Windows 11 gaming VM built on high-end hardware, achieving a near-bare-metal gaming experience.
Final Outcome: Achieved stable VM startup and shutdown, and resolved the
pci_irq_handlercrash error. In-game GPU utilization was boosted from an initial 30% to a stable 97%. The system bottleneck was successfully shifted from the CPU to the GPU, with both performance and system stability meeting expectations.1. Root Cause Diagnosis: A Dual Dilemma of Stability and Performance
This project faced two core, interconnected challenges that required a systematic solution.
The Stability Challenge: Boot Failures and Random Crashes
qm stopcommand or a crash, reporting a fatal error:kvm: ../hw/pci/pci.c:1654: pci_irq_handler: Assertion '0 <= irq_num && irq_num < PCI_NUM_PINS' failed..The Performance Challenge: A Severe CPU Bottleneck
2. The Systematic Solution: From Host-Level to VM Fine-Tuning
We adopted a bottom-up, layered optimization strategy to ensure each step built a solid foundation for the next.
Phase 1: Proxmox Host-Level Configuration (The Bedrock)
These settings are prerequisites for any successful passthrough, aiming to establish a correct IOMMU environment and flexible driver management capabilities for the host.
GRUB Kernel Parameter Configuration:
Implementation: Edit
/etc/default/gruband modify theGRUB_CMDLINE_LINUX_DEFAULTline:amd_iommu=on: Force-enables IOMMU on AMD platforms.iommu=pt: Enables passthrough mode for better performance.pcie_acs_override=...: Breaks up non-ideal IOMMU groups, allowing devices like the GPU to be passed through independently.Activation: Run
update-gruband reboot the host.Precise Kernel Module Management (The
blacklistvs.softdepDecision):vfio-pcito claim the NVIDIA dGPU at boot, while also allowing the host'samdgpudriver to load normally for the iGPU used by an LXC container.blacklistcompletely prevents a driver from loading. This would stop our hookscript from returning the GPU to the host driver after VM shutdown and would also prevent the iGPU from functioning.softdep(soft dependency) to establish a driver loading priority.Implementation:
Edit
/etc/modprobe.d/vfio.conf:Edit
/etc/modprobe.d/pve-blacklist.conf(The Key Correction):Activation: Run
update-initramfs -uand reboot the host.Automated Hookscript for Seamless Driver Handoff:
vfio-pci. After the VM shuts down, automatically return the GPU to the host driver and trigger a reset, permanently curing the "Reset Bug"./var/lib/vz/snippets/gpu-manager.shand apply it to the VM withqm set 100 --hookscript local:snippets/gpu-manager.sh. (Script contents are detailed below).Phase 2: Virtual Machine Level Configuration (The Performance Leap)
With a stable host foundation, we performed precision surgery on the VM itself.
CPU Core Pinning and NUMA Optimization (The Decisive Battle):
lscpu -eandcat /sys/devices/system/cpu/cpu*/cache/index3/sizeto precisely identify that the V-Cache CCD (with 96MB of L3 cache) resides on physical cores0-7(logical threads0-7, 16-23).affinity): We setaffinity: 2-7,18-23, locking the VM's 12 cores firmly onto the V-Cache CCD. We strategically reserved cores0/1and their SMT siblings for the host to handle I/O and interrupts.numa: 1): This makes the Windows guest OS aware that it is running on a single, tightly-coupled NUMA node. This optimizes its internal scheduling policy, ensuring game workloads do not stray outside the V-Cache domain.Memory and Peripheral Performance Optimization (Consolidating Gains):
hugepages: 2: Uses 2MB hugepages to reduce memory access latency.balloon: 0: Disables memory ballooning to guarantee a stable memory supply.discard=on,iothread=1: Enables TRIM and an I/O thread for our ZFS storage, boosting disk performance.GPU Passthrough Stability Tuning (A Discussion on
rombar=0):rombar=0to thehostpci0parameter instructs Proxmox to ignore the GPU's Option ROM. This can circumvent known firmware compatibility issues on certain NVIDIA 30/40 series cards and is a powerful tool for resolving stubborn crashes.rombar=0was not necessary in this scenario. This provides a crucial lesson: before resorting to low-level workarounds likerombar=0, higher-level instability factors such as overclocking, cooling, and driver versions should be ruled out first.3. Conclusion and Final Configuration
This optimization project proves that by deeply understanding the underlying hardware architecture and applying systematic configuration, it is entirely possible to build a stable, high-performance, top-tier gaming VM on Proxmox VE. The keys to success were:
softdepand a hookscript to perfectly resolve the GPU reset bug and conflicts in a mixed-GPU setup.rombar).In the end, we not only resolved all initial issues but also established a "Golden Standard" configuration for your high-end hardware, laying a solid foundation for future virtualization endeavors.
Appendix I: Final "Golden Standard" Configuration File (
/etc/pve/qemu-server/100.conf)Appendix II: Automated Driver Management Hookscript (
/var/lib/vz/snippets/gpu-manager.sh)This script is the core component for achieving a seamless and stable handoff of the NVIDIA dGPU between the host and the VM. It resolves the "Reset Bug" that causes the VM to fail to restart after shutdown.
Purpose and Principle:
* Before VM Start (
pre-start): The script forcibly unbinds the passthrough GPU devices from their host drivers (e.g.,nvidia) and ensures they are ready to be claimed by thevfio-pcidriver.* After VM Stop (
post-stop): The script releases the GPU fromvfio-pciand then triggers a rescan of the host's PCI bus. This prompts the host'snvidiadriver to reclaim and completely re-initialize (reset) the GPU, returning it to a clean state, ready for the next VM boot.Script Content:
Installation and Usage Instructions:
/var/lib/vz/snippets/gpu-manager.shon your Proxmox host.sh chmod +x /var/lib/vz/snippets/gpu-manager.shsh qm set 100 --hookscript local:snippets/gpu-manager.shsh cat /var/log/pve/qemu-server/hookscript.logFinal config as of now, will continue to post here if i found out some better parameters.
👍 Thank You ! this topic will certainly help on multiple (x)GPU env. on Proxmox !
But i don't know who host Ryzen + GPU until now. Hope it's coming.
As second choice (?!), heavy players could directly install windows and games on the ryzen.
I just Very frustrated with Windows, spyware, unwanted/buggy Windows Update, I even got memory leaks from VMware Workstation just because I have a Dual GPUs Setup. Imagine if i don't disable my iGPU, VMware's s**tty graphical stack will used up all the Ram in just three days.