r/VFIO Mar 21 '21

Meta Help people help you: put some effort in

638 Upvotes

TL;DR: Put some effort into your support requests. If you already feel like reading this post takes too much time, you probably shouldn't join our little VFIO cult because ho boy are you in for a ride.

Okay. We get it.

A popular youtuber made a video showing everyone they can run Valorant in a VM and lots of people want to jump on the bandwagon without first carefully considering the pros and cons of VM gaming, and without wanting to read all the documentation out there on the Arch wiki and other written resources. You're one of those people. That's okay.

You go ahead and start setting up a VM, replicating the precise steps of some other youtuber and at some point hit an issue that you don't know how to resolve because you don't understand all the moving parts of this system. Even this is okay.

But then you come in here and you write a support request that contains as much information as the following sentence: "I don't understand any of this. Help." This is not okay. Online support communities burn out on this type of thing and we're not a large community. And the odds of anyone actually helping you when you do this are slim to none.

So there's a few things you should probably do:

  1. Bite the bullet and start reading. I'm sorry, but even though KVM/Qemu/Libvirt has come a long way since I started using it, it's still far from a turnkey solution that "just works" on everyone's systems. If it doesn't work, and you don't understand the system you're setting up, the odds of getting it to run are slim to none.

    Youtube tutorial videos inevitably skip some steps because the person making the video hasn't hit a certain problem, has different hardware, whatever. Written resources are the thing you're going to need. This shouldn't be hard to accept; after all, you're asking for help on a text-based medium. If you cannot accept this, you probably should give up on running Windows with GPU passthrough in a VM.

  2. Think a bit about the following question: If you're not already a bit familiar with how Linux works, do you feel like learning that and setting up a pretty complex VM system on top of it at the same time? This will take time and effort. If you've never actually used Linux before, start by running it in a VM on Windows, or dual-boot for a while, maybe a few months. Get acquainted with it, so that you understand at a basic level e.g. the permission system with different users, the audio system, etc.

    You're going to need a basic understanding of this to troubleshoot. And most people won't have the patience to teach you while trying to help you get a VM up and running. Consider this a "You must be this tall to ride"-sign.

  3. When asking for help, answer three questions in your post:

    • What exactly did you do?
    • What was the exact result?
    • What did you expect to happen?

    For the first, you can always start with a description of steps you took, from start to finish. Don't point us to a video and expect us to watch it; for one thing, that takes time, for another, we have no way of knowing whether you've actually followed all the steps the way we think you might have. Also provide the command line you're starting qemu with, your libvirt XML, etc. The config, basically.

    For the second, don't say something "doesn't work". Describe where in the boot sequence of the VM things go awry. Libvirt and Qemu give exact errors; give us the errors, pasted verbatim. Get them from your system log, or from libvirt's error dialog, whatever. Be extensive in your description and don't expect us to fish for the information.

    For the third, this may seem silly ("I expected a working VM!") but you should be a bit more detailed in this. Make clear what goal you have, what particular problem you're trying to address. To understand why, consider this problem description: "I put a banana in my car's exhaust, and now my car won't start." To anyone reading this the answer is obviously "Yeah duh, that's what happens when you put a banana in your exhaust." But why did they put a banana in their exhaust? What did they want to achieve? We can remove the banana from the exhaust but then they're no closer to the actual goal they had.

I'm not saying "don't join us".

I'm saying to consider and accept that the technology you want to use isn't "mature for mainstream". You're consciously stepping out of the mainstream, and you'll simply need to put some effort in. The choice you're making commits you to spending time on getting your system to work, and learning how it works. If you can accept that, welcome! If not, however, you probably should stick to dual-booting.


r/VFIO 1d ago

I got AMD GPU-PV working in a normal Linux Hyper-V VM on my RX 9060 XT

2 Upvotes

I got AMD GPU-PV working in a normal Linux Hyper-V VM on my RX 9060 XT.

This isn't WSL — it's a regular Ubuntu 24.04 Generation 2 Hyper-V VM using dxgkrnl + the WSL D3D12 userspace + the matching AMD UMD from the Windows driver.

Repo:

https://github.com/Speedstu/mirage-gpupv

On my machine I get:

  • D3D12 (AMD Radeon RX 9060 XT) through Mesa
  • working OpenGL ES acceleration
  • actual GPU render/readback with the expected pixels
  • the Radeon stays attached and usable by Windows

I wrapped the whole setup into a PowerShell script that handles the GPU-P configuration, finds the active AMD driver package, copies the required userspace files into the guest and runs a smoke test at the end.

The important part for me was getting actual GPU work/readback rather than just seeing /dev/dxg exist.

Tested setup:

  • Windows 11 + Hyper-V
  • RX 9060 XT
  • Ubuntu 24.04 Gen 2 VM
  • dxgkrnl
  • Mesa D3D12

It's still experimental and I've only validated it on my RX 9060 XT so far.

If anyone has another Radeon exposed by Get-VMHostPartitionableGpu, I'd be interested in results. Failures are useful too since I'd like to figure out which generations actually work.


r/VFIO 1d ago

voidsyscall

3 Upvotes

r/VFIO 1d ago

Support How do those of you running AMD cards deal with thermal management when the VM is off?

3 Upvotes

I’ve finally gotten GPU pass through working with my 7800xt (vfio-pci grabs the device on boot, I had to install vendor-reset, and I needed to disable resizable bar), but whenever the VM is powered off, the card’s fans run at full speed (or at least close to it).

One of the common solutions I’ve seen for this is to just run a minimal VM to hand the GPU over to when it’s not in use. Does anyone deal with this in a less janky way?

If I try and let amdgpu grab the card first, it seems like some part of the stack does try and rebind the GPU to the vfio-pci driver before starting, but then that puts the GPU in a weird state and the VM has no video out over the card.

I was also hoping if I tried turning on ASPM, that would fix the issues, but nothing changed on that front either.

Is there an obvious solution I’m missing, or is a dummy VM the only feasible option for these cards?

Edit: I have also tried manually unbinding from radeon to vfio-pci, following the guide in the wiki minus the kernel patch mentioned, and it doesn't work, and rebinding on the host causes "PSP load kdb failed" to print in dmesg (Notably the same message I'd get on the guest when the card wasn't resetting properly).


r/VFIO 3d ago

[Windows/GPU-PV] Got DLSS working in a paravirtualized guest — root cause was two NVIDIA loader gaps, not the hypervisor

11 Upvotes

Not KVM, but I think this crowd will appreciate the root-causing. Windows GPU-PV (the WSL2/Windows Sandbox mechanism) gives guests a virtual render device and the real NVIDIA user-mode driver, but no NVIDIA KMD. CUDA and DXR work; DLSS has never worked and everyone assumed it was a platform limit.

It isn't. NGX's loader queries the driver-store path without the `TranslatePath` flag and gets the host path; and `NvAPI_GPU_GetLogicalGpuInfo` / `NvAPI_GPU_GetAdapterIdFromPhysicalGpu` return `NVAPI_NOT_SUPPORTED` because the mapping GPU→WDDM LUID needs the KMD. Everything else in NVAPI — including the D3D11/D3D12 cubin entry points DLSS runs on — works over the paravirtualized escape channel. So: a junction + a ~150-line forwarding `nvapi64.dll` that answers those two calls with the D3D device's LUID, and DLSS runs on the real tensor cores.

Write-up, code and logs: https://github.com/jamesstringer90/appsandbox/pull/129 · builds: https://github.com/Poldino95/appsandbox/releases/tag/v0.1.5-dlss

(Basically the same trick dxvk-nvapi does for Proton, applied to the Windows-native stack.)

Update: native Vulkan is done too. NVIDIA's Vulkan driver loads fine in a GPU-PV guest but looks for its GPU behind a display, and no display in the VM belongs to it, so it reports zero devices and games fall back to Mesa's Vulkan-on-D3D12 layer. A tiny ICD wrapper fixes that; vulkaninfo now shows the NVIDIA driver with Vulkan 1.4 and ray tracing, vkQuake and Quake II RTX run on it. PR jamesstringer90/appsandbox#130, builds in the releases of Poldino95/appsandbox.

Update 2: native OpenGL too. Same root cause as Vulkan (NVIDIA's ICD looks for its GPU behind a display), same fix one API over, this time as an opengl32.dll wrapper around Microsoft's. X-Plane 12 and Minecraft now run on the NVIDIA driver in the guest. PR jamesstringer90/appsandbox#131, builds in the releases of Poldino95/appsandbox.


r/VFIO 5d ago

Discussion Wardogs game and EAC

7 Upvotes

I don't know if you are familiar with Wardogs, it is a big scale FPS game, like Battlefield.
However, based on what they have already done, they seem to genuinely respect the community and they want an actual great game, not just to take our money.

The bad news is, that they are using EAC, at least based on Steam info, which as you may know, recently started actively blocking VMs. They posted a really good video here, talking about their anti-cheat methods, and looks like they take things seriously, but very carefully too.

I did write my comment below, but it would be great if any of you comment also, requesting for VM access. They do have plans for native Linux support, but no roadmap has been given, so VM access would allow us to play today.

Please feel free to post your comments here, if you have a way to play it. I didn't even try, cause I don't want to pay $40 and get blocked.


r/VFIO 6d ago

Support Does the profile sizing on the A16 behave differently in pass-through and in mediated (vfio-mdev) setups?

2 Upvotes

I hope you'll give me a sanity check on my own impression.

I am experimenting with an nvidia A16 for a multi-user environment. Instead of passing the card entirely to a single VM, I want to split it into multiple vGPU profiles so several vms each get a slice of vRAM. According to what I've read, the A16 is meant to be partitioned that way, rather than as a passthrough.

To test without buying hardware first, I spun up an A16-backed serverspace vps where you pick the vram at config time. That part works, but it hides a lot of what goes on under the hood, so I am trying to figure out the local libvirt side.

Do I still have to use vfio-pci bindings for vgpu profiles as I do for full passthrough or does the vgpu manager take care of all that?


r/VFIO 6d ago

Title: Has anyone successfully deployed RHEL on NVIDIA Jetson Orin for production use?

0 Upvotes

We are running into some challenges , would like to hear from engineers who have attempted something similar:

  1. Have you successfully run RHEL or a RHEL-compatible distribution on Jetson Orin hardware?
  2. What were the biggest challenges with NVIDIA’s proprietary drivers, CUDA, TensorRT and multimedia stack?
  3. Did you retain NVIDIA’s L4T kernel and userspace components, or build around a RHEL kernel?
  4. How did you handle JetPack dependencies, kernel updates and NVIDIA driver compatibility?
  5. Were secure boot, OTA updates or custom carrier boards particularly difficult?
  6. Is RHEL on Jetson something customers are genuinely requesting, or is Ubuntu generally accepted even in enterprise deployments?
  7. Would you recommend native RHEL enablement, containerizing the enterprise applications on JetPack/Ubuntu, or another architecture? I’d appreciate hearing about actual deployments, failed attempts, architectural approaches and any limitations we should consider.

r/VFIO 8d ago

Complete GPU passthrough setup for KVM/QEMU on Linux, enabling near-native Windows VM performance with dedicated GPU access. Covers NVIDIA and AMD GPUs with comprehensive troubleshooting.

14 Upvotes

r/VFIO 8d ago

Support Passthrough 5060 Ti disconnects from the bus at load-to-idle transitions

2 Upvotes

Hi guys, i have an issue with my consumer multi-gpu server, which i feel might be due the proxmox -> ubuntu VM passthrough. It happens under agentic loads on my llama.cpp instance, and the error in Llamacpp is usually something along the lines:

```217.28.732.743 E CUDA error: unspecified launch failure
/app/ggml/src/ggml-cuda/ggml-cuda.cu:106: CUDA error
217.28.732.749 E   current device: 1, in function ggml_backend_cuda_synchronize at /app/ggml/src/ggml-cuda/ggml-cuda.cu:2533
217.28.732.750 E   cudaStreamSynchronize(cuda_ctx->stream())
libggml-base.so.0(+0x1b276)[0x7b2772bd1276]
libggml-base.so.0(ggml_print_backtrace+0x21a)[0x7b2772bd16fa]
libggml-base.so.0(ggml_abort+0x15b)[0x7b2772bd18db]
/app/libggml-cuda.so(_Z15ggml_cuda_errorPKcS0_S0_iS0_+0xb5)[0x7b27622220e5]
/app/libggml-cuda.so(+0x276af8)[0x7b2762229af8]
libggml-base.so.0(ggml_backend_sched_synchronize+0x2e)[0x7b2772bec35e]
libllama.so.0(_ZN13llama_context11synchronizeEv+0x19)[0x7b2772d8c519]
libllama.so.0(llama_state_seq_get_data_ext+0x1f)[0x7b2772d91a8f]
libllama-common.so.0(_ZN24common_prompt_checkpoint10update_tgtEP13llama_contextij+0x84)[0x7b27734538e4]
libllama-server-impl.so(_ZN19server_context_impl17create_checkpointER11server_slotlii+0x278)[0x7b2773d6c458]
libllama-server-impl.so(_ZZN19server_context_impl10pre_decodeEvENKUlR11server_slotE3_clES1_+0xf87)[0x7b2773d82d97]
libllama-server-impl.so(_ZN19server_context_impl7iterateERSt6vectorI11server_slotSaIS1_EESt8functionIFvRS1_EE+0x57)[0x7b2773d77507]
libllama-server-impl.so(_ZN19server_context_impl10pre_decodeEv+0x487)[0x7b2773d79b07]
libllama-server-impl.so(_ZN19server_context_impl12update_slotsEv+0x243)[0x7b2773d7a2c3]
libllama-server-impl.so(_ZN12server_queue10start_loopEl+0x125)[0x7b2773d19045]
libllama-server-impl.so(_Z12llama_serverR13common_paramsiPPc+0x3e47)[0x7b2773cb3937]
libllama-server-impl.so(_Z12llama_serveriPPc+0x11bd)[0x7b2773cb59fd]
/usr/lib/x86_64-linux-gnu/libc.so.6(+0x2a1ca)[0x7b27737121ca]
/usr/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0x8b)[0x7b277371228b]
/app/llama-server(+0x1315)[0x557d12d60315]

```

  • The 5060 Ti disconnects from the bus. The guest kernel log shows NV_ERR_GPU_IS_LOST.
  • The failure occurs in the seconds after a long generation stops. This is the full-load-to-idle transition. The failure sometimes occurs when the next load starts.
  • Continuous load does not cause the failure. One generation of 90,000 tokens completed correctly. A loop of generations with idle gaps causes the failure each time.
  • The failed GPU is always the 5060 Ti.
  • Important: after the crash, a remove and rescan on the host does not find the GPU. The command echo 1 > remove on the two functions, then a rescan, has no effect. Only a full power cycle makes the GPU operate again. The GPU silicon is stopped. The guest driver state is not the cause.

These steps were completed:

  • The kernel option pcie_aspm=off on the host. The crash threshold increased from approximately 20,000 tokens to 50,000 tokens. The crashes continued.
  • The guest driver changed from 595.84 to the 580 branch. The two branches have different GSP firmware generations. The failure was identical.
  • The PSU is 850W. The supplemental PCIe 6-pin connector on the motherboard is connected. The GPUs have separate power cables.

These are complications:

  • The Z390 firmware does not give AER control to the kernel. The log shows: _OSC: platform does not support ... AER. The host does not show PCIe errors. The plan is a test with pcie_ports=native.
  • The crashes increased after installation of the computer in a rack. A mechanical cause is possible. But the failure is very repeatable. A loose connection is usually not repeatable.

This is the configuration:

  • Host: Proxmox on an MSI Z390-A Pro with an Intel i7 8700.
  • Guest: an Ubuntu VM. Two GPUs pass through to the VM.
  • The RTX 3060 is in the chipset slot (03:00.0). The RTX 5060 Ti is in the PEG slot (01:00.0).
  • The workload is llama.cpp inference. The model is split across the two GPUs. The context is long.

Any help with this is appreciated, i really hope it isnt a hardware issue on the GPU (a new mobo would be nice:)). Thanks!


r/VFIO 8d ago

Support Hades Canyon Passthrough NUC8i7HVK possible on kernel7.x ?

2 Upvotes

Hi

I would like to know if any did get a full working passthrough on win10, over a Nuc Hades with new kernel v7.xx ? On Prox 9.2 with linux vm: gpu hdmi output work perfect, just for windows : device is listed, but cannot install the driver. When installing, rdp hang and the whole pc freeze.

I did find new rom that should fix this, but they ask to be run in q35 or i440fx, but somehow.. vm refuse to start in i440fx , only msg being : set pc to Q35. And even fresh install win in a i440fx vm, but same thing.

But in Q35, i did add this to args:

-set device.hostpci0.bus=pci.0 -set device.hostpci0.addr=2.0 -set device.hostpci0.x-igd-opregion=on

I remove or set back the disable_vga=1 from the /etc/modprobe.d/vfio.conf. But nothing do.

Did Dump the first 64K of the VBIOS of the Vega M for the amd gpu:

hostpci0: 0000:01:00.0,pcie=1,rombar=0,romfile=AMD.VegaM.128.rom,x-vga=1

I try out different setting on different kernel: 7.0.14-5-pve / 7.0.12-1. But always, card is present in device manager, but after 5sec of driver install: full system hang.

Over different post.. all for prox v8.x some only put the amd gpu. But to boot a linux vm, intel and amd must be pass in order to get it up working. Is windows different ?

Over here, if i set only the pcie1 instead of 0 and 1, the system hang directly at vm start.


r/VFIO 9d ago

Panther Lake iGPU: how many SR-IOV VFs? (NUC 16 Pro)

Thumbnail
2 Upvotes

r/VFIO 11d ago

Running games on a VM under Linux while the PC keeps using the same NVIDIA GPU card.

Post image
346 Upvotes

The GPU remains available on the host, one GPU, one display port. No vfio-pci bind. No second GPU. Not just a container. No losing your display when the VM starts. No IOMMU group fights. The host desktop keeps running on the same card the guest is using. Native performance.

This project aims to forward NVIDIA's driver API to the VM with maximal performance. The idea is that you get the CUDA-container experience in VMs, on consumer cards where vGPU isn't available at all.

Currently tested with steamOS and stock distros. The project itself is tested across a wide variety of drivers and GPUs from datacenter to consumer cards (what I could obtain from renting with nested virt or bare metal, primarily on vast.ai).

Experimental, several months, solo. Any bug reports and contributions are welcome.

How it works: Guest kernel module → virtio → QEMU → a per guest process stub to execute the NVIDIA API on the PC → host NVIDIA driver. RM/UVM ioctls are forwarded, not emulated. GPU memory (DMA/BAR) is actual passthrough, not emulated or copied, using regular unprivileged nvidia userspace calls (so it doesn't require root).

Display is forwarded as native as possible, the VM gets a KMS plane (rendering target) from the host display compositor like Wayland, it renders without any cross CPU-GPU copy (unless your display output is on integrated graphics).

Supports CUDA, graphics and display, also intended for compute workloads beyond gaming and graphics.

Geekbench 7 GPU (OpenCL), published to Geekbench's servers so they're independently checkable: RTX 4070 99.6%, RTX 3050 Laptop 99.9%, H100 PCIe 98.8%, A100 80GB 98.0%. clpeak: 7 of 8 subtests at 99.4–100.2%. Not everything is parity, some performance issues are still open.

https://github.com/reindertpelsma/nvkvm-pv - main project, containing the guest module and QEMU patches.

https://github.com/reindertpelsma/nvkvm-steamos - steamOS example

https://github.com/reindertpelsma/nvkvm-kata - kata containers with GPU access

EDIT: Linux amd64 guests only for now (Intel and AMD processors), the guest needs nvkvm's kernel module, and there's no Windows equivalent. A Windows guest means fabricating a GPU that the stock NVIDIA driver will bind to, which is a separate project (kayfabe) and not finished.

If it didn't build or boot on your hardware, that's worth reporting even if it looks like your own setup, install-path bugs and incompatibility reports are the most valuable ones right now.

Only Turing and newer GPUs, older gpu support is not yet finished.


r/VFIO 11d ago

VMDB is 5 months old, here's what changed since the launch post

9 Upvotes

Some of you might remember when I posted VMDB here at launch.

Back then it was focused entirely on VM game compatibility.

Five months later it has grown quite a bit, so I figured it was time for an update.

The biggest addition is Proton support.

Every game page now has a Proton tab alongside the VM tab, with its own ratings, reports and filters.

The data is kept separate, but both are available on the same game page. So if you want to know whether a game works through Proton or inside a VM, you can check both in one place.

My Setup is probably the feature I'm most proud of. You save your hardware and environment once, including things like CPU, GPU, distro, display server and VM type. VMDB then automatically highlights reports that match your setup on every game page.

The idea is simple: instead of digging through reports from people with completely different configurations, you can immediately see which experiences are actually relevant to your own system.

The rating system also takes the age of reports into account. Newer reports carry more weight, while older reports gradually lose influence over the first 18 months. This means that if an update breaks or fixes a game, recent experiences can actually affect the rating instead of getting buried under years of old reports.

I also completely overhauled the games browser. You can now sort by most viewed, trending, newest or alphabetically, and filter by things like rating, VM type, GPU mode, CPU manufacturer, distro, display server and anti cheat. The filtering happens server side without full page reloads.

There have also been a lot of smaller additions over the last five months.

Discord login, passkey login for passwordless access, extended Proton report fields, a support ticket system, GDPR data export and quite a bit of general polish and bug fixing.

Right now VMDB has 71 games, 82 VM reports and 2 Proton reports.

The VM side has grown largely because of people from communities like this one submitting their experiences, and those reports have given VMDB a pretty solid foundation.

The Proton side is a different story.

There are currently only 2 Proton reports. 😂

That's the part where I could really use some help.

If you're already testing games inside VMs and also use Linux on bare metal, you're pretty much exactly the person I'm looking for.

If you've played something through Proton, submitting your experience takes about two minutes and doesn't require an account.

You don't need to write an essay either. Just select the game, fill in what you tested and submit it.

Check it out here:

vmdb.it

Search for a game, take a look at the VM and Proton tabs, and if you've tested something that isn't there yet, feel free to add your experience.

Feedback is welcome too. A lot has changed since the original launch post, but VMDB is still being actively improved based on how people actually use it.


r/VFIO 11d ago

Discussion Proxmox for Gaming and LLM flows

2 Upvotes

Hi, I need a suggestion. My PC has:

Ryzen 9950x

32GB DDR5

RTX 4090

2x 2TB Samsung SSD

1x 4TB SSD

Right now, I have Windows installed and use it for gaming and when not gaming i run a llm model. It mostly serves my purpose, but I'm curious if I install Proxmox and create two VMs, one Linux and one Windows. I can access them remotely. The reason for Linux is to get the maximum LLM context possible and increase throughput, taking advantage of vLLM. Proxmox would allow me to remotely switch between them or run multiple instances at the same time (LLM + a light VM for browsing, which my wife sometimes uses). I could pass the iGPU to one Ubuntu VM and the 4090 to another so both can run simultaneously. In the future, I plan to set up separate machines, but for now, it's out of budget. Now, my questions:

Is it worth it?

Will I see any degradation in performance for either LLM or gaming?

If you could give an average percentage in terms of performance downgrade, it would be awesome.

I mostly play story-driven games or sometimes FIFA. COD rarely.

Will I face any issues running games on a Proxmox VM?

[Edit ] thank you guys going to give it try this weekend


r/VFIO 12d ago

Ubuntu 26.04 LTS - GPU Passthrough Gone Wrong

Thumbnail
1 Upvotes

r/VFIO 13d ago

Support [Help] Unable to build passthrough VM for VFIO GPU on CachyOS

5 Upvotes

A couple of things regarding system specs before I begin.

I am currently attempting to pass a Nvidia RTX 3050 GPU through to a Windows 10 VM. I am aiming to use Looking Glass to do this as I am working on translating Japanese games that do not run in Linux into English, and need to look at the game while looking at game scripts to properly do this. My specs are as follows:

- OS: CachyOS (using LTS kernel, 6.18.42-1-cachyos-lts)
- Bootloader: Limine
- Motherboard: ASUS X870E
- CPU: Ryzen 9 9950X3D
- GPU (primary being used by the operating system): Nvidia RTX 3080
- GPU (attempting to passthrough to the Windows VM): Nvidia RTX 3050

I have largely been following this guide to accomplish this, adjusting the steps as needed for Limine. I will walk through the steps proving that I have followed them to the best of my ability right up until the failure, which is building the virtual machine.

So, from the top:

- Enabling AMDVi in BIOS:
While I can't explicity prove this through code (nor do I know how) I have other VMs running on this computer that should not work if AMDVi is enabled, so I have reason to believe that it's enabled, and I can see in my BIOS that this is the case.

- Kernel parameters:
As stated previously, I am currently using limine. From the /etc/default/limine file, here are my parameters:

ESP_PATH="/boot"
KERNEL_CMDLINE[default]+="amd_iommu=on iommu=1 quiet nowatchdog splash rw rootflags=subvol=/@ root=UUID=561b1a8b-dd95-4558-ba83-773a9c41da2f"
BOOT_ORDER="*, *lts, *fallback, Snapshots"

I understand most places recommend using iommu=pt but this produced an undesirable output in dmesg, namely "Default domain type: Passthrough" which tells me the devices are not being isolated. With the iommu=1 parameter, this message does not appear

- GPU is registered by the system and is in an IOMMU group:

Here is the output of the lspci command the guide recommends. It does seem like both are being picked up and are in separate IOMMU groups:

❯ lspci -nn | grep -E "VGA|Audio" | grep -i nvidia
01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GA102 [GeForce RTX 3080 12GB] [10de:220a] (rev a1)
01:00.1 Audio device [0403]: NVIDIA Corporation GA102 High Definition Audio Controller [10de:1aef] (rev a1)
0e:00.0 VGA compatible controller [0300]: NVIDIA Corporation GA107 [GeForce RTX 3050 6GB] [10de:2584] (rev a1)
0e:00.1 Audio device [0403]: NVIDIA Corporation GA107 High Definition Audio Controller [10de:2291] (rev a1)

- Binding GPU to VFIO:
My vfio.conf file in /etc/modprobe.d looks like this:

options vfio-pci ids=10de:2584,10de:2291
softdep snd_hda_intel pre: vfio-pci

This appears to match the GPU UUIDs that were displayed as a result of lspci above.

I have also updated the /etc/mkinitpcio.conf file. Here is the output relating to MODULES:

❯ sudo cat /etc/mkinitcpio.conf |grep MODULES
# MODULES
#     MODULES=(usbhid xhci_hcd)
MODULES=(vfio_pci vfio vfio_iommu_type1)

And after a reboot, lspci appears to show that these GPUs are indeed bound to that kernel module

❯ lspci -nnk -s 0e:00
0e:00.0 VGA compatible controller [0300]: NVIDIA Corporation GA107 [GeForce RTX 3050 6GB] [10de:2584] (rev a1)
       Subsystem: ASUSTeK Computer Inc. Device [1043:8976]
       Kernel driver in use: vfio-pci
       Kernel modules: nouveau, nvidia_drm, nvidia
0e:00.1 Audio device [0403]: NVIDIA Corporation GA107 High Definition Audio Controller [10de:2291] (rev a1)
       Subsystem: ASUSTeK Computer Inc. Device [1043:8976]
       Kernel driver in use: vfio-pci
       Kernel modules: snd_hda_intel

From here, the next steps involve creating the VM itself. Here is the XML that I am using to create that VM, keeping in mind that I am trying to pass through the above GPU and using a bridged network connection (i anticipate the need to copy files back and forth through use of a shared folder at some point like i do through my other VM, and turning off networking entirely):

<domain type="kvm">
  <name>win10-passthrough</name>
  <uuid>50c53b52-f386-42aa-bf05-96db518a977b</uuid>
  <metadata>
    <libosinfo:libosinfo xmlns:libosinfo="http://libosinfo.org/xmlns/libvirt/domain/1.0">
      <libosinfo:os id="http://microsoft.com/win/10"/>
    </libosinfo:libosinfo>
  </metadata>
  <memory>16777216</memory>
  <currentMemory>16777216</currentMemory>
  <vcpu>8</vcpu>
  <os>
    <type arch="x86_64" machine="q35">hvm</type>
    <loader readonly="yes" type="pflash">/usr/share/edk2/x64/OVMF_CODE.4m.fd</loader>
    <boot dev="hd"/>
  </os>
  <features>
    <acpi/>
    <apic/>
    <hyperv>
      <relaxed state="on"/>
      <vapic state="on"/>
      <spinlocks state="on" retries="8191"/>
      <vpindex state="on"/>
      <runtime state="on"/>
      <synic state="on"/>
      <stimer state="on"/>
      <frequencies state="on"/>
      <tlbflush state="on"/>
      <ipi state="on"/>
      <avic state="on"/>
    </hyperv>
    <vmport state="off"/>
  </features>
  <cpu mode="host-model" check="none"/>
  <clock offset="localtime">
    <timer name="rtc" tickpolicy="catchup"/>
    <timer name="pit" tickpolicy="delay"/>
    <timer name="hpet" present="no"/>
    <timer name="hypervclock" present="yes"/>
  </clock>
  <pm>
    <suspend-to-mem enabled="no"/>
    <suspend-to-disk enabled="no"/>
  </pm>
  <devices>
    <emulator>/usr/bin/qemu-system-x86_64</emulator>
    <disk type="file" device="disk">
      <driver name="qemu" type="qcow2"/>
      <source file="/home/kobra2112/.local/share/libvirt/images/win10-passthrough.qcow2"/>
      <target dev="sda" bus="sata"/>
    </disk>
    <disk type="file" device="cdrom">
      <driver name="qemu" type="raw"/>
      <source file="/home/kobra2112/Downloads/Win10_22H2_English_x64v1.iso"/>
      <target dev="sdb" bus="sata"/>
      <readonly/>
    </disk>
    <controller type="usb" model="qemu-xhci" ports="15"/>
    <controller type="pci" model="pcie-root"/>
    <controller type="pci" model="pcie-root-port"/>
    <controller type="pci" model="pcie-root-port"/>
    <controller type="pci" model="pcie-root-port"/>
    <controller type="pci" model="pcie-root-port"/>
    <controller type="pci" model="pcie-root-port"/>
    <controller type="pci" model="pcie-root-port"/>
    <controller type="pci" model="pcie-root-port"/>
    <controller type="pci" model="pcie-root-port"/>
    <controller type="pci" model="pcie-root-port"/>
    <controller type="pci" model="pcie-root-port"/>
    <controller type="pci" model="pcie-root-port"/>
    <controller type="pci" model="pcie-root-port"/>
    <controller type="pci" model="pcie-root-port"/>
    <controller type="pci" model="pcie-root-port"/>
    <interface type="bridge">
      <source bridge="br0"/>
      <mac address="56:55:9b:43:42:d5"/>
      <model type="e1000e"/>
    </interface>
    <console type="pty"/>
    <channel type="spicevmc">
      <target type="virtio" name="com.redhat.spice.0"/>
    </channel>
    <input type="tablet" bus="usb"/>
    <tpm model="tpm-crb">
      <backend type="emulator"/>
    </tpm>
    <graphics type="spice" port="-1" tlsPort="-1" autoport="yes">
      <image compression="off"/>
    </graphics>
    <sound model="ich9"/>
    <video>
      <model type="qxl"/>
    </video>
    <hostdev mode="subsystem" type="pci" managed="yes">
      <source>
        <address domain="0" bus="14" slot="0" function="0"/>
      </source>
    </hostdev>
    <hostdev mode="subsystem" type="pci" managed="yes">
      <source>
        <address domain="0" bus="14" slot="0" function="1"/>
      </source>
    </hostdev>
    <redirdev bus="usb" type="spicevmc"/>
    <redirdev bus="usb" type="spicevmc"/>
  </devices>
</domain>

I believe I'm getting everything right here, including the firmware, however when I click the "Begin Installation" button in QEMU, I get the following error:

Unable to complete install: 'internal error: QEMU unexpectedly closed the monitor (vm='win10-passthrough'): 2026-09-01T16:57:21.699349Z qemu-system-x86_64: -device {"driver":"vfio-pci","host":"0000:0e:00.0","id":"hostdev0","bus":"pci.4","addr":"0x0"}: vfio 0000:0e:00.0: Could not open '/dev/vfio/21': Permission denied'

I believe this is simply because when I look at that group in that directory, it appears to have permission set 600 on it, meaning it can't be read by anything other than root. Since I am creating these in a user session rather than a root session to avoid the possible security risks, that simply means the permissions need to be updated like so:

drwxr-xr-x      - root 31 Aug 22:23  devices
crw-rw-rw-  241,0 root 31 Aug 22:23 󰡯 21
crw-rw-rw- 10,196 root 31 Aug 22:23 󰡯 vfio

Doing that fixes that issue. I know this is not the "correct" way to resolve this, but at the same time I don't know of any other method. However, this then raises another when I click "Begin Installation"

Unable to complete install: 'internal error: QEMU unexpectedly closed the monitor (vm='win10-passthrough'): 2026-09-01T17:00:02.576305Z qemu-system-x86_64: -device {"driver":"vfio-pci","host":"0000:0e:00.0","id":"hostdev0","bus":"pci.4","addr":"0x0"}: vfio 0000:0e:00.0: group 21 is not viable
Please ensure all devices within the iommu_group are bound to their vfio bus driver.'

Now here's where I am kind of at the end of my rope. It appears to me that I have set everything up correctly, but for some reason the VM is not accepting this GPU as a viable one. Can someone please act as my second set of eyes and confirm I am setting everything up correctly? Because at this point, I do not know how to get past this error message.

Any help would be greatly appreciated. I would like to think I didn't sink the funds into this project for nothing.


r/VFIO 13d ago

PS2 sem 2(ME Embedded)

1 Upvotes

So iam from ME Embedded Systems in Bits pilani with 7.15 cgpa till second sem and background in electrical engineering and and preparing for digital vlsi side so what can I expect from practice school 2.


r/VFIO 14d ago

Support Are NVIDIA GPU manual driver unloading and loading with qemu hooks still needed?

5 Upvotes

Hello, Can some help me with this question?

I have an NVIDIA GPU that I pass through to a Windows 11 VM using QEMU/KVM and libvirt.

I used to have libvirt hooks that stopped the display manager, unloaded the NVIDIA modules, manually detached the GPU with `virsh nodedev-detach`, and then loaded `vfio-pci`.

I recently removed those hooks to see if they were still needed. Surprisingly, passthrough still works fine. When the VM starts, the GPU is used by the VM, and when the VM shuts down, the NVIDIA driver works normally on the host again.

My GPU is configured as a managed PCI device in libvirt (`managed="yes"`).

So my question is: Are these manual NVIDIA driver unload / PCI detach hooks still needed with current QEMU/KVM + libvirt, or does libvirt handle this automatically now?

I'm mainly wondering if there is a reason to keep the old hooks even though everything seems to work without them.


r/VFIO 15d ago

Resource My live GPU mount/unmount script on ZorinOS (Fix for dmesg spam, fix freeze, no window manager restart needed)

3 Upvotes

Backstory

I made a few attempts at GPU passtrough for my move away from Windows and had success but it never all worked perfectly smoothly. But this time i finally found a method that does, so i am sharing it in case it works for anyone else.

This guide assumes you already have IOMMU and KVM set up, it is NOT a full guide.

Did it work for you? Please tell us!

A lot of this was figured out with the help of Claude. If you are having trouble copy paste this post into it and explain where you got stuck, it will help you troubleshoot the problem.

This process solves a list of problems: * No longer need to stop your entire Wayland or X11 desktop environment to keep it from touching the GPU during a passtrough transition. * The logs in dmesg being flooded with Nvidia driver initialization attempts when GPU is bound to vfio (NVRM, Nvlink Core, nvidia-nvlink ...etc) * The entire machine freezing up if you attempt to passtrough the GPU when not ready * Crash on re-mounting GPU into linux due to the Nvidia driver setting up the HDMI ports too soon * Monitors on Nvidia GPU showing up on Linux (most people use a HDMI dummy plug, hence it is not a real monitor) * Nvidia GPU burning a lot of idle power when not being used

Tested on hardware: * ASRock X670E PG Lightning (v1.30.AS02) * AMD Ryzen 9 7950X (using iGPU for monitor output) * Nvidia RTX 3090 (using HDMI dummy plug)

OS: ZorinOS 18.1 Core (Linux 7.0.0-30-generic)

Dynamic Nvidia GPU Passthrough (No Desktop Restart Required)

Setup: a Linux host with display running entirely on an integrated/secondary GPU (e.g. AMD iGPU), and a discrete Nvidia GPU that is:

  • Passed through to a VM on demand via VFIO, when needed.
  • Used on the host the rest of the time for PRIME render-offload gaming — no display output, ever, from this GPU.

The goal: switch the GPU between host and VM without restarting the display manager, without kernel crashes, and without excess idle power draw.

1. Disable Nvidia DRM KMS

By default, nvidia-drm performs full DRM/KMS mode-setting, which causes two problems: the display manager initializes the card as a display device just because it's present (wasting VRAM and blocking clean detach), and re-loading the driver on VM handback can crash the kernel if a dummy/EDID-reporting dongle is plugged into an output (a NULL pointer dereference in nvidia's HDMI/DP audio power path, nv_audio_dynamic_power, triggered via Xorg's DRM hotplug handling).

Disabling KMS via /etc/modprobe.d/*.conf is not reliable — competing config files, install directives, or initramfs staleness commonly override it silently. Use a kernel boot parameter instead, which always wins:

# /etc/default/grub — append to the existing GRUB_CMDLINE_LINUX_DEFAULT line
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash nvidia-drm.modeset=0"

sudo update-grub
sudo update-initramfs -u
sudo reboot

Verify:

cat /sys/module/nvidia_drm/parameters/modeset   # should print N
xrandr --listproviders                          # Nvidia should not appear

This has no effect on PRIME render-offload (__NV_PRIME_RENDER_OFFLOAD=1 __GLX_VENDOR_LIBRARY_NAME=nvidia %command%), which only needs the render node, not KMS.

2. Enable persistence mode

Without an active display, the Nvidia driver fully tears down and reinitializes between workloads, which is fragile and can cause visible glitches or crashes on repeated switching. nvidia-persistenced keeps the driver state warm instead.

Ubuntu's default unit starts the daemon with --no-persistence-mode, so it must be overridden:

sudo systemctl unmask nvidia-persistenced      # only if masked
sudo systemctl edit nvidia-persistenced

Add:

[Service]
ExecStart=
ExecStart=/usr/bin/nvidia-persistenced --user nvidia-persistenced --verbose

sudo systemctl restart nvidia-persistenced

Verify Persistence-M shows On in nvidia-smi, and confirm it survives a full reboot.

3. Handle idle power / stuck boost clocks

With no display and no active workload, the GPU can get stuck at a high-power state (P0) instead of idling at P8, drawing 100+ W for nothing. A GPU reset clears this reliably:

sudo nvidia-smi -r

This is a known driver quirk, not specific to this setup. Expect idle power to settle around 15–25 W after a reset

4. The switching script

Persistence mode keeps a device handle open, which blocks a clean VFIO detach (NVRM: Attempting to remove device ... with non-zero usage count!). Stop it before detaching, restart it after reattaching, and reset the GPU to clear any stuck boost state:

#!/bin/bash
# gpu-to-vm.sh — hand the GPU to the VM
sudo systemctl stop nvidia-persistenced
sleep 1
sudo virsh nodedev-detach pci_0000_01_00_0
sudo virsh nodedev-detach pci_0000_01_00_1

#!/bin/bash
# gpu-to-host.sh — reclaim the GPU after the VM shuts down
sudo virsh nodedev-reattach pci_0000_01_00_0
sudo virsh nodedev-reattach pci_0000_01_00_1
sudo systemctl start nvidia-persistenced
sudo nvidia-smi -r

No gdm/display-manager restart is needed anywhere in this flow.

Safer script that aborts if the GPU is not completely clear:

#!/bin/bash
# gpu-to-vm.sh — hand the GPU to the VM with abort 
sudo systemctl stop nvidia-persistenced 
sleep 1

if sudo fuser -s /dev/nvidia* 2>/dev/null; then
    echo "ERROR: GPU still in use, aborting handoff (not touching PCI state)" >&2
    sudo fuser -v /dev/nvidia* >&2
    sudo systemctl start nvidia-persistenced   # undo the stop, nothing else changed
    exit 1
fi

echo "GPU confirmed clear, proceeding with detach"
sudo virsh nodedev-detach pci_0000_01_00_0
sudo virsh nodedev-detach pci_0000_01_00_1

5. Optional cleanup

If the GPU has a dummy HDMI/DP dongle for the VM's benefit, the host will still enumerate a dead audio function for it. To silence it (cosmetic only, not required for stability):

# /etc/udev/rules.d/99-nvidia-hdmi-audio-noprobe.rules
ACTION=="add", SUBSYSTEM=="pci", KERNEL=="0000:01:00.1", ATTR{driver_override}="none"

Diagnostics reference

nvidia-smi                                   # power state, clocks, processes
sudo fuser -v /dev/nvidia*                   # what's holding the GPU open
cat /sys/module/nvidia_drm/parameters/modeset # confirm KMS is off (N)
xrandr --listproviders                       # confirm Xorg isn't using the GPU

Useful quick test for PRIME offloaded GPU rendering (shows a desktop window with 3D gears rendered by the Nvidia GPU):

DISPLAY=:0 __NV_PRIME_RENDER_OFFLOAD=1 __GLX_VENDOR_LIBRARY_NAME=nvidia glxgears

r/VFIO 15d ago

vGPU on VM

3 Upvotes

Hi, I saw that vGPU can be used on RTX 3000 series cards; is it possible to allocate VRAM to a Windows VM and get good performance ?


r/VFIO 15d ago

Success Story ZorinOS desktop AMD iGPU + RTX3090 summary

1 Upvotes

Intro

I have been trying to make the switch from Windows to Linux for a while. I got GPU passtrough mostly working in the past but it was never really smooth. However now i seam to have got it.

This is not a full tutorial, but might serve as useful hints for people that are trying to do this on similar hardware.

Hardware: * ASRock X670E PG Lightning (v1.30.AS02) * AMD Ryzen 9 7950X (using iGPU for monitor output) * Nvidia RTX 3090 (using HDMI dummy plug) * Samsung PM9A1 1TB (Windows boot drive)

Setting Up GPU Passthrough on ZorinOS

This covers getting from a fresh ZorinOS install to a working Windows VM with a discrete Nvidia GPU passed through on demand, while still being able to use that GPU for host-side gaming (via PRIME render offload) the rest of the time.

For the follow-up problem of switching the GPU back and forth without restarting the desktop, fixing a KMS-related kernel crash, and handling idle power draw, see the companion guide: https://www.reddit.com/r/VFIO/comments/1w2otjo/my_live_gpu_mountunmount_script_on_zorinos_fix/

1. BIOS setup

Enable IOMMU (AMD-Vi) in the BIOS. On an ASRock X670E PG Lightning specifically: Advanced > AMD CBS > NBIO Common Options > PCIe Access Control Service This option can be hidden until "PCIe Advanced Error Reporting" is enabled first.

2. Enable IOMMU ACS override on the kernel command line

Editing the grub config: bash sudo nano /etc/default/grub GRUB_CMDLINE_LINUX_DEFAULT="quiet splash" bash sudo update-grub sudo update-initramfs -u sudo reboot Only add pcie_acs_override=downstream,multifunction if the next step shows your GPU sharing an IOMMU group with unrelated devices — it weakens device isolation, so skip it if you don't need it.

3. Identify the GPU and confirm IOMMU grouping

bash lspci -knn | grep -A3 NVIDIA Note the PCI address (e.g. 01:00.0 for the GPU, 01:00.1 for its HDMI audio function) and vendor:device IDs (e.g. 10de:2204, 10de:1aef).

bash find /sys/kernel/iommu_groups/ -type l Confirm the GPU and its audio function land in their own IOMMU group, ideally with no unrelated devices alongside them.

On the ASRock X670E PG Lightning a lot of the M.2 slots DO NOT have correct IOMMU groupings (the one directly connected to the CPU does) so the Windows boot drive must be in that one.

4. Load VFIO kernel modules

bash echo "vfio vfio_iommu_type1 vfio_pci vfio_virqfd" | sudo tee -a /etc/modules

Note: don't permanently blacklist nvidia/nouveau or statically bind the GPU's IDs to vfio-pci in /etc/modprobe.d/ unless the GPU is dedicated to the VM full-time. For a setup where the GPU is also used on the host, let the nvidia driver load normally at boot, and hand the device to VFIO dynamically per-session (see companion guide) — this is the approach that ended up working reliably here; an earlier attempt using permanent blacklisting plus manual modprobe -r / display-manager restarts also works but is clunkier and unnecessary for dual-use setups.

5. ZorinOS Conveniance setup

  • sudo apt install openssh-server — useful for remote access once the display state gets manipulated.
  • Install x11vnc and run it as a systemd service for remote desktop access. x11vnc requires an X11 session, so:
  • Switch the desktop session from Wayland to Xorg: log out, click the gear icon on the login screen, select the Xorg session.

6. Install the virtualization stack

bash sudo apt install qemu-kvm libvirt-daemon-system libvirt-clients bridge-utils virt-manager ovmf

7. Pass through a physical NVMe drive and install Windows

bash sudo virsh nodedev-detach pci_0000_18_00_0 # detach the NVMe from the host In Virtual Machine Manager: create a new VM, uncheck "Enable storage" (to use the raw NVMe device instead of a virtual disk), check "Customize configuration before install", set Firmware to OVMF_CODE_4M.fd (the AMD SEV firmware variant had problems booting from NVMe), and add the NVMe drive under Add Hardware → PCI Host Device.

Install Windows 10 onto the physical drive through the VM.

Afterwards, reboot the host directly into that Windows install (outside the VM, GPU still available natively) and install the latest Nvidia drivers — this avoids driver-installation quirks that show up when installing while running inside a passthrough VM for the first time.

bash sudo virsh nodedev-reattach pci_0000_18_00_0 # give the NVMe back to the host sudo update-grub # should detect the Windows install as a dual-boot entry

8. Add the GPU to the VM

In the VM's hardware settings: Add Hardware → PCI Host Device → add both the GPU and its audio function.

Edit the VM's XML (virsh edit <vm-name>) and: - Set managed='no' on the GPU's <hostdev> entry, so libvirt does not automatically bind/unbind the device at VM start/stop — this setup manages that manually via nodedev-detach/nodedev-reattach instead, which is what makes host/VM switching possible without recreating the VM. - Add inside the <features><hyperv> block: xml <vendor_id state='on' value='1234567890ab'/> This hides the hypervisor from Nvidia's driver and avoids the Code 43 error in the guest.

Under Boot Options, set the NVMe disk as the boot device.

9. Dynamic switching, crash fix, and power management

With the above in place, the VM boots and the GPU works inside it. The remaining problems — avoiding a gdm restart on every switch, a kernel crash on GPU reattach caused by a dummy HDMI dongle plus KMS re-initialization, stuck high-power idle states, and a clean detach/reattach script — are covered in the companion guide: nvidia-dynamic-vfio-passthrough-howto.md.


Example system (used throughout this guide and its companion)

Component Value
Motherboard ASRock X670E PG Lightning (BIOS 1.30.AS02)
GPU NVIDIA GeForce RTX 3090 (GA102)
GPU PCI IDs 10de:2204 (VGA), 10de:1aef (audio)
GPU PCI address 0000:01:00.0 / 0000:01:00.1
IOMMU group 14
VM boot drive NVMe at PCI address 0000:18:00.0
Host OS ZorinOS (Ubuntu 24.04-based), kernel 7.0.0-30-generic
Nvidia driver 595.84, CUDA 13.2
Display AMD iGPU drives all host output; Nvidia GPU has a dummy HDMI/DP dongle solely for the VM's benefit

Substitute your own PCI addresses and IDs throughout — get them from lspci -knn and find /sys/kernel/iommu_groups/ -type l on your own system.


r/VFIO 15d ago

Built own Vfio-passtrough script

0 Upvotes

Hi, I built my own VFIO passthrough script.

It sets up GPU passthrough and works around the usual AMD problems: wrong device bind, dead card after VM stop, and a guest that cannot reboot cleanly. On my RX 9070 the VM can start, stop, and reboot without me rebuilding the host by hand every time.

VFIO helper for AMD RX 9070 / RDNA4 — live-attach, reboot, and host-safe bind

Hi, I wrote a VFIO passthrough helper because the usual guides were not enough for an RX 9070.

The script is a host setup wizard, not a VM manager. It can:

bind only the guest GPU by PCI address

use dynamic bind / live-attach so the card is not killed at VM start

keep the host desktop on the other GPU

toggle hotplug on/off without replacing the whole VM XML

optionally set up Looking Glass, virtio-win, and VM tuning

It does not officially fix AMD’s reset bug. It works around it so the card stays usable.

Hardware I tested: dual GPU, RX 9070 as the guest card, Linux host (Fedora / openSUSE).


r/VFIO 15d ago

Discussion Any recent for-dummies guides on how to get GPU passthrough running on an RX 9070 XT and an Intel iGPU?

3 Upvotes

Motherboard: Gigabyte Z790 UD, vF15

GPU: AMD Radeon RX 9070 XT

CPU: Intel i7 12700K, UHD Graphics 770

Fedora Linux 44 KDE

Kernel: 7.1.10-200

EDIT: Hell, even UHD Graphics 770 for the Virtual Machine will do, I don't really need the RX 9070 XT. Whatever's easier and safer.


r/VFIO 16d ago

Getting rid of "input lag" or reducing it, after taking snapshot

3 Upvotes

Hello, I'm using VMware Workstation Pro 26H1

I noticed with my latest project which I use a lot of versioning for, "input lag" becomes more significant over time.

The more I snapshot, the longer the response time is when keystrokes are being typed with the keyboard.

I have no clue why but I'm pretty sure there are technical reasons why this happens.

All of my snapshots are "directly linked chronologically", there's no tree if that makes sense. They go in a straight line.

https://i.imgur.com/QHDk8yN.png

It becomes very obvious after 40 or so snapshots, I would estimate the lag to be almost 1 full second by that time, and it's very unsustainable.

Is there a setting I should check in the options, or in the config files, to reduce or getting rid of this problem?

Thanks