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 Gauër 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!

My previous post on enabling Virgl Enabling hardware acceleration for windows 10 VM in qemu 2.11 on 18.04

Wiki with minimal information to apparently non-working windows guest drivers.


3 Answers 3


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.

For my setup I was running a Windows 10 guest with a Gentoo Linux Host using libvirt/KMV/QEMU. Here are the steps I took to get it to work:

You should see something like this:

Mesa3D system-wide deployment utility
Please make a deployment choice:
1. Core desktop OpenGL drivers
2. Core desktop OpenGL drivers + Intel swr
3. Install DirectX IL for redistribution only
4. Microsoft OpenGL over D3D12 driver only (replaces Mesa core desktop OpenGL drivers)
5. Mesa3D off-screen render driver gallium version (osmesa gallium)
7. Mesa3D graw test framework
8. Update system-wide deployment
9. Remove system-wide deployments (uninstall)
10. Exit
Enter choice:
  • Select the first option 1. Core desktop OpenGL drivers

And thats it.

You can use GPU Caps Viewer from here to confirm. enter image description here

  • 1
    While this certainly gets a newer OpenGL version going, and is absolutely going to be faster than the default, it is not hardware accelerated if that is what you were aiming for. Relevant quote: "The Gallium llvmpipe driver is a software rasterizer that uses LLVM to do runtime code generation." More details at docs.mesa3d.org/drivers/llvmpipe.html Commented Feb 15, 2022 at 12:09
  • Yea. In the end I just went with GPU passthrough for the problem I was trying to solve. Doing what I mentioned in my answer did get me past something that required a newer version of OpenGL but once past that I hit other issues.
    – Chris
    Commented Feb 15, 2022 at 14:57

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.

KVM, Qemu and virt-manager don’t have a working feature that could provide OpenGL to a Windows 10 guest. virtio GPUs won’t work properly with Windows and appear to be limited to a backward-compatible VGA mode with ~2 fps and 800×600.

(QXL, on the other hand, works reasonably well (albeit without 3D acceleration) and provides automatic resolution changes and, with sufficient video RAM, also HighDPI resolutions.)

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.

That said, the only working piece of advice is to wait or to contribute to one of the ongoing projects.

1 Users may sometimes believe to have observed software properties (often related to performance) that are in fact not there. This is a known phenomenon and there has been even “successful” placebo software in the past.

  • 1
    This post talks about using this mesa driver on the windows guest to "install the LLVM pipe System-Wide so that any application needing OpenGL will use the Mesa3D implementation instead of the Microsoft renderer without any further configuration needed." havent tried it yet but looks promissing.You sound pretty sure its not possible. Any thoughts on this?
    – Chris
    Commented Jun 5, 2021 at 14:01

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.


Create Windows 10 VM in virt-manager - at the end choose advanced options

In Options - use OVMF bios and Q35 chipset. SeaBIOS doesn't work, had to "sudo apt install ovmf". OVMF can't use IDE drives, so changed to SATA to start (SCSI didn't work either), made Virtio later.

In Options - delete all display and video devices

In Options - pass through PCI devices of GPU video (have monitor directly connected to Nvidia video card) AND audio (failed with only video)

In Options - pass through usb keyboard/mouse (since deleted all display and video options to be safe, couldn't interact remotely)

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.

After Windows loaded and I'd shut the VM down, I edited the XML per the above guides to be sure I didn't have the Code 43 error with the GPU (specifically adding the 3 lines where noted - "vendor_id state='on' value='1234567890ab'/", "hidden state='on'/", and "ioapic driver='kvm'/").

Load Virtio drivers and utility

Load latest Nvidia drivers

Check for OpenGL and it was finally there.

Installed Sketchup and it ran just fine.

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.

Thanks for the input here and my previous post Christian, I'll add a short note to the old one as well linking here as they are related.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .