I get stuck at “Creating Domain” when starting the VM, when passing the GPU, because it’s still in use by Linux. The blacklisting method isn’t working.
For systems with only one Nvidia/Radeon GPU, you'll want to blacklist it in /etc/modprobe.d/blacklist.conf, as follows:
blacklist nouveau
blacklist nvidia
I asked on the Arch forum and, other than saying not to post Garuda support there, they said
Don’t use optimus-manager - it’ll load the module explicitly which is why that blacklist approach won’t work.
So that I do it the right way… how do I properly release the GPU so that KVC can use it for passthrough? And how do I switch between Linux and Windows using it?
sudo nvidia-smi -r
GPU 00000000:01:00.0 is currently in use by another process.
1 device is currently being used by one or more other processes (e.g., Fabric Manager, CUDA application, graph
ics application such as an X server, or a monitoring application such as another instance of nvidia-smi). Plea
se first kill all processes using this device and all compute applications running in the system.
Btw, if Garuda Assistant could help setup a VM with KVC and GPU Passthrough with a few clicks, that would be a super useful feature. Because it's a real pain in the *ss to setup, but it puts VirtualBox to shame. Once you can run Windows at near-native performance in Linux even for games, it really takes away any argument to keep Windows in dual-boot.
I'm having several other problems, some of which I solved, some of which I can't.
Running Virtual Machine Manager only shows LXC in the list, whereas running "sudo virt-manager" shows only QEMU/KVM in the list. Requiring to use sudo on every single run. This should be the fix but it's not solving the problem.. There's also the issue that if I check "Enable XML editing", close and re-open, it doesn't save the setting.
I've wasted many hours already; still can't get GPU passthrough to work, and still can't run virt-manager without sudo. But got Windows running with VirtIO, and got samba file sharing working.
Then there's the mouse/keyboard passthrough... if I set USB passthrough on the mouse, any way to switch back to Linux? Other than unplugging and replugging the mouse.
EDIT: LOL! Solved the 'sudo' problem. Just had to start without sudo and File | Add Connection and just click Connect on QEMU/KVM. Now it works, and I can enable XML editing. Remains the GPU passthrough thing to solve.
Why would you possibly think it’s acceptable to post issues from our distro on the Arch forum. No Linux forum I’ve ever registered for is keen on dealing with issues from users of another distro. This is nothing new and is pretty common place knowledge.
The Arch forum expressly states this policy during the registration process (unless things have changed since I registered there). They even have this stickied at the top of their Newbie forum:
These boards are for the support of Arch Linux, and Arch ONLY
If you have installed Archbang, Antergos, Chakra, Evo/Lution, Manjaro, Whatever, you are NOT running Arch Linux. Similarly, if you followed some random video on YouTube or used an automated script you found on a blog, you are NOT running Arch Linux, so do not expect any support, sympathy or anything but your thread being closed and told to move along.
Arch is a DIY distro: if someone else has done it for you, then showing up here asking to have your hand held for more help is just help vampirism and is not welcome.
I don’t see how this could possibly be made any clearer there. I should have thought that there were more than enough notifications beforehand that doing so was uncool. This is a very poor reflection on Garuda when our users register on the Arch forum and immediately begin to flaunt their rules.
Our users are expected to obey the rules of other forums as well as ours here. You put a black mark on Garuda’s reputation when you expect assistance for a Garuda issue on the Arch forum, (in violation of their rules) . We do not appreciate having Garuda’s reputation sullied by Garuda users on other forums. Please never post Garuda issues on the Arch forum as this is expressly forbidden there.
I spent way too much time on this issue. Finally made some progress with Loading vfio-pci early
Basically, NVidia driver was loaded before it had the chance to be replaced with a stub. Following these instructions, I could get vfio-pci to take the device first.
While this works, it requires changing configuration and rebooting to switch who is using the graphic card -- essentially taking away any benefits over dual-booting.
Wondering whether it's worth spending more time into this. Is there a way to switch GPU host without being more trouble than dual-booting?
Another peculiar behavior I've seen with Garuda is when setting up Evdev passthrough. It gave me permission errors leading me into the troubleshooting section to run libvirtd as root (or doing more complex config)
To close this thread; the blacklisting problem is solved.
There is no need to blacklist, but rather, the devices must be loaded by vfio-pci before the GPU loads up. Then this was just one issue in a long list of issues.
For others looking into the topic, I recommend the VFIO reddit group for support, as this is a very complicated and specialized topic that really hasn't much to do with Garuda. Starting with the pinned post and the Arch page.
Bryan Steiner has a great pass through guide. I usually use that one. But you figured it out. Well done. This is usually what you have to do, instead of asking help on these forums.
I was just reading his guide, GREAT resource indeed! It would have saved me a lot of time to get to that first.
Still -- detaching hangs, so the initial problem remains. I think there's something about Garuda's configuration that keeps the GPU locked.
I saw another interesting approach: start with vfio-pci binding using the solution I posted above, and then bind when the system starts.
I now successfully have the HDMI output disabled on system start; but running unbind_vfio.sh doesn't restore my display. I'm also unable to start Optimus Manager.
Getting an entirely new issue. Will create new thread for it.
The way it works for me is I use optimus-manager to switch between integrated and nvidia. When I switch to integrated I can bind and unbind the nvidia GPU. Some times it doesn't work, usually it's because the nvidia-smi is hogged by some application or service. Usually re-switching to integrated fixes this.
I tried again, Optimus Manager, Integrated. Redid it 3 times.
sudo nvidia-smi -r
GPU 00000000:01:00.0 is currently in use by another process.
1 device is currently being used by one or more other processes (e.g., Fabric Manager, CUDA application, graph
ics application such as an X server, or a monitoring application such as another instance of nvidia-smi). Plea
se first kill all processes using this device and all compute applications running in the system.
Since I can't get GPU passthrough to work; trying a different approach.
Display Splice: Splice server, OpenGL on NVIDIA
Video: Virtio, 3D acceleration
Error starting domain: internal error: qemu unexpectedly closed the monitor: 2022-01-12T16:47:36.607503Z qemu-system-x86_64: egl: eglInitialize failed
2022-01-12T16:47:36.607548Z qemu-system-x86_64: Failed to initialize EGL render node for SPICE GL
Googling and not finding anything meaningful on that error, other than some others having it. Someone fixed it by reinstalling the graphic drivers. What's the safe way to re-install graphic drivers in Garuda?
If I set OpenGL on Intel, then it boots, but I'm still locked in 800x600, so it doesn't seem to be doing anything.
Now we're getting with a bunch of different problems, but perhaps they're related somehow.
OK I'm trying to do it the standard way, add vfio_pci to kernel params and then not try any dynamic bind or unbind. That's the most documented approach. Recreated a fresh VM setup over the existing virtual drive.
If I do it with your params, Video=None, and Display Splice, I get this displayed in the window "Connecting to graphical console for guest". Nothing else happens. I guess it should be taking the HDMI port to display on the TV?
If I can get the VM to work in the most standard way, I might be able to figure things out from there. So... no error right now, but why no video output?
Shutdown is working so that's a sign that the VM is in a "valid" state.
It is pretty typical that users new to Arch based distros will have some teething pains. The average new user will likely melt down their system a time or two and end up doing reinstalls until they have learned the ropes.
It is near impossible for us to speculate why you are experiencing problems as we would need to own your exact model of computer and know every single change you have made to make any real determination of the causes.
Things usually become easier as you become more familiar with how Arch works. As the old saying goes "Rome wasn't built in a day".