Qemu 3d Acceleration

[Laurene Arrison]

Iwas trying to install my first virtual machine with KVM and QEMU but it does seem to use hardware acceleration as intended. I came to that conclusion first because it is terribly slow and second because of the output of

The page I found -accelerated-virtualization-with-qemu-and-kvm/enouraged me in the idea that there is something wrong, but none of the proposed problems apply. I also do not get an error message from QEMU and do not see anything kvm or virtio related in dmesg.

Does anyone have an idea what my problem is? Is there another way to check if hardware acceleration is actually working?But it is really extremely slow. Starting up as well as running. My Windows in Virtualbox runs a lot faster. Might there be a different problem?

I am still confused why this is necessary, because everything I read so far implicates or sais explicitely that qemu tries using kvm by default (and throws an error when fails). So if anyone knows why this is not the case for me I would still be grateful.

I'm trying to install Sketchup 2019 on a Windows 10 VM (Ubuntu 18.04, QEMU 3.1.0), however Sketchup requires OpenGL 3.1 or later in order to run. I had asked a similar question previously hoping by enabling 3D acceleration with Virgl would work, however even though I was able to enable Virgl on the host and have the option to choose 3D acceleration with Virtio, OpenGL is still not on my windows VM. I then instead passed through an MSI GeForce GT 710 Nvidia GPU which works and shows up on the VM, however OpenGL still doesn't exist and Sketchup won't run.

It seems that Windows guest drivers just don't exist, and I've seen talk of Nathan Gaur working on drivers for this a few years ago, but wasn't sure if anything ever came of this or some other way for OpenGL to work on a Windows VM in QEMU KVM. If anyone knows if there are any functioning Windows guest drivers, or a way to get OpenGL working, or any other way to make Sketchup run in this sort of environment, I'd love the insight!

Full credit to this post by Thomas Schwery. You could just follow the instructions there but I will summarize below. This should get you a more recent version of OpenGL (for me that was 3.1) running on a Windows 10 Guest VM. OpenGL 1.1 was actually already running but since it was so old the application I was trying to run didn't recognize it.

There is currently no such thing like OpenGL in Windows guests in Qemu. Rumors to the contrary often stem from QXL forgotten in the configuration, combined with a performance placebo effect1. OpenGL does appear as a menu item in virt-manager, but it works with the virtio-gpu driver in Linux guests only.

This ArchWiki section contains a summary of the current state and links to projects that implemented experimental Windows drivers for virtio GPUs. Unfortunately, the projects are either abandoned or in an early research phase.

Thanks Christian for the feedback. I did try to use spice with GL, but kept getting an error trying to start the VM with it enabled and didn't go down that rabbit hole yet. I had passed through that GPU to my VM and no matter what I tried to do, updating Windows or drivers, trying to delete the other display and video through virt-manager (couldn't seem to delete them all), OpenGL wasn't showing as installed. Maybe if I'd deleted the display and video from the virsh xml file it would have worked, but I decided to start from scratch and got it to work finally so here are the steps I took if anyone else runs into this in the future.

Ubuntu 18.04 with QEMU (I have 3.1.0, would likely be similar with 2.11 or others). There are a few steps needed for Nvidia cards, not sure what would be needed for AMD. This guide is what I mostly mimicked to get everything working including my steps below. This was another one with similar info on Nvidia card setups.

As a note - when I first physically added the GPU, I could no longer access my machine over my network (headless) because adding the GPU changed the network interface which broke my netplan. Could have connected a monitor, but I have an IPMI port on my MB so connected that way and got the new network interface to update netplan.

Start VM and load Windows 10 - on first startup it dropped me straight to the UEFI shell which I had to exit out of and took me to the BIOS where I could go to the boot menu and choose the Win10 iso I'd attached as a CD over SATA to boot from.

I usually use remote desktop for Windows VM's but I still wanted to try to have the ability to connect from virt-manager, so after it was all working, I did go back and add a VNC display and Virtio video to the VM so I can connect and interact through virt-manager or the like. This only seems to work if the Nvidia monitor is physically disconnected, otherwise I get a "guest has not initialize the display (yet)" which I'm sure there is a solution for, but I don't plan on having a monitor connected anyway so I have not investigated that.

I've been messing around with qemu on Windows 10. I found HAXM as a slow accelerator (for me has the same performance as TCG) and I want a better experience. I found that qemu supports WHPX, using -M accel=whpx. I enabled Windows Hypervisor Platform and everything from the Hyper-V category in Windows Features and then I restarted the machine. I tried to run qemu using whpx but I get this error:

Most likely the hypervisor's startup is disabled. It may be installed but it needs to be started at boot. Use this command in an admin command prompt and then reboot. This will force Windows to start the hypervisor at each boot.

Venus is a Vulkan driver for VirtIO-GPU that lets the Guest OS use accelerated graphics on Vulkan using the host GPU. What can this mean in terms of VM acceleration, and could this mean that passing through a low powered GPU to a guest may not be necessary anymore?

I'm trying to emulate an ARM VM on an ARM host, a cubieboard2 embedded board, by means of qemu. I've compiled qemu from the source code and enabled kvm. Now the problem is that launching qemu-system-arm as follows:

there is another way you can see the failing mode (why qemu command failed): execute your command under "strace", and you will be able to clearly see when /dev/kvm is opened, and if it succeed, non-zero fd will be returned after open("/dev/kvm") is called. and before all this - "lsmod" should return a line indicating "kvm.ko" kernel module is running, and if you can read your kernel's config file, there should be a "CONFIG_KVM" embedded within.

Note - Unfortunately this no longer works due to movement in the WSL offering for Windows 11 Dev Channel. Am leaving this here incase some of the workarounds for issues below help others in their projects!

I needed to record a demo on a Mac, I don't own a Mac and was contemplating borrowing one from a friend. Then I realised, I finally had an excuse to give this a go! I've been itching to since I read - Accelerated KVM guests on WSL 2, an awesome write-up on how to run accelerated KVM guests on WSL2 from @unixterminal

This is a walkthrough of how I used the excellent work of @unixterminal and @FoxletFox and got my 3 year old XPS Intel i7 to run MacOS on Windows 10! Without their writeups and scripting this post probably wouldn't exist.

I am still stunned how good the performance is having run through this! I've tried a couple of other Linux distro's too, seriously slick.

Before starting check out the requirements from the top of the "Accelerated KVM guests on WSL2" post. One thing that's not obvious is your CPU needs to support virtualisation. Unless you're running an Intel CPU from the early 2000s or even earlier you should be OK. If your CPU does support virtualization it might not be enabled in your BIOS, it's worth a check before you start. If you're already running a hypervisor, it's likely this is good to go.

You'll also need to be running a windows insider build of Windows 10. The insiders Fast ring which is mentioned in the pre-requisites is now the Dev channel. One of the features required didn't come into Windows 10 until build 19619 and the nested virtualisation support for AMD didn't come in until build 19636 either, so that's a must if you are on AMD too. The windows insider page currently lists 19042.423 as the highest build available in Beta and 19041.423 as Release Preview, so for the moment this will not work correctly without using the Dev channel.

The insider channel renaming is described here. Dev channel is described as Ideal for highly technical users. Insiders in the Dev Channel will receive builds that is earliest in a development cycle and will contain the latest work-in-progress code from our engineers. These builds will have rough edges and some instability that could block key activities or require workarounds.

When executing this command N was being returned. Having traced back through the steps it was time for a search which yielded an issue from the WSL github repo. So reverting back to the step Install your kernel in WSL 2 and enable nested KVM the .wslconfig was changed to:

Also note that setting debugConsole opens up the WSL debug console, you can turn this and pageReporting off later by removing them from the .wslconfig file and restarting WSL. I left it in for a while in case I needed to troubleshoot further.

Having run a far few X servers in the past I just wanted something that just worked without a lot of setup. Therefore, I went for X410 which is 9ish in the Microsoft store, but as I'm planning to use this until GUI support comes out later in the year, it was worth the price for the easy setup.

Once nested KVM is up and running and you've configured WSL to send X output to windows, you are ready to try a distro. If you keep following the post at this point you'll set up an Ubuntu 20.10 daily build. I ran through this as a check to see if everything was working, the steps for this were exactly the same as in the post.

The MacOS-Simple-KVM GitHub repo is linked from the original post. It is described as "set up a simple macOS VM in QEMU, accelerated by KVM." If you ran through setting up the Ubuntu 20.10 daily build in step 4 you'll already have seen QEMU being mentioned. You might be thinking, why are there two types of virtualization technologies? The key part is in how KVM and QEMU differ, which is summed up nicely in this post. KVM uses the CPU virtualization extensions for Intel and AMD, and QEMU is performing the virtual hardware emulation, or to put it another way, KVM is QEMU's "go faster stripes"!

3a8082e126