Qemu 3d Acceleration Windows Host

[Varinia Swicegood]

Im 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 stupidly went down the rabbit hole and drained my time on qemu. So I documented the quirks to help the next poor sap who has to get qemu running on Windows 10 host efficiently over Bridged-Adapter (VirtualBox lingo) networking mode.

I typically want Bridged-Adapter option from VirtualBox, which means the virtual NIC plugs into the same router as the host and just appears as another computer on the same network as host. This is broken into a few components in qemu and you have to manage them separately. Great for learning about how Bridged-Adapter really works, but a lot of swearwords coming from people who just want to get basic things done.

Networking in QEMU is another can of worms if you deviate from the default SLIRP (user mode). I figured out how to work it, but the network bridge is faulty and it keeps crashing my windows with BSOD on bridge.sys with varying error tag. I have short glimpse of it working if I move very fast. Looks like the TAP driver is corrupting the memory as the bridge became very erratic that I see error messages deleting it and have persistent BSOD when the bridge starts after the VM hanged at the TAP bridge on boot.

Currently you have JavaScript disabled. In order to post comments, please make sure JavaScript and Cookies are enabled, and reload the page. Click here for instructions on how to enable JavaScript in your browser.

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"!

Now make sure the X server from step 4 is running as QEMU will try and use graphics mode by default. If it isn't running when you run basic.sh in this next step it'll have for a minute or so then fail:

The top section boxed in red is caused by the -cpu line in basic.sh. The standard settings in the basic.sh file are sending instructions around performance enhanced features to the host CPU which it cannot understand. The box in green are errors related to sound, I'm not so worried about those, and explain my sound related issues with Ubuntu above. You can edit basic.sh further to straighten these out, but the VM still booted with these errors present.

3a8082e126