I'm running Arch Linux and have been running into trouble trying to use QEMU/KVM on virt-manager, and this problem is likely to address my issues while using the similar gnome-boxes.


This error was related to the driver opencl-amdgpu-pro-orca. This answer details some background of what causes the error. Here's how I went about resolving the problem:

  1. Run sudo systemctl edit libvirtd, which opens Nano.
  • That command creates a temporary file which will save to become override.conf within the directory of the libvirtd service.
  1. Enter the following into this (empty in my case) file:
  1. Restart libvirtd with sudo systemctl restart libvirtd.
  2. Open virt-manager. The error should not be present.
  • It's worth noting that I did not need to reboot following these changes.

The rest of the question as it originally was is detailed below.


Upon opening virt-manager, a connection appears to be successfully made with QEMU/KVM, and I am given the option to create a new VM. When I attempt to do so, I experience this error:

Warning: KVM is not available. This may mean the KVM package is not installed, or the KVM kernel modules are not loaded. Your virtual machines may perform poorly.


journalctl -f returns this when I reproduce the error:

Oct 14 22:23:00 okcomputer libvirtd[35615]: internal error: Failed to start QEMU binary /usr/bin/qemu-system-x86_64 for probing: /usr/bin/qemu-system-x86_64: symbol lookup error: /usr/lib/libvirglrenderer.so.1: undefined symbol: gbm_bo_unmap
Oct 14 22:23:00 okcomputer libvirtd[35615]: Failed to probe capabilities for /usr/bin/qemu-system-x86_64: internal error: Failed to start QEMU binary /usr/bin/qemu-system-x86_64 for probing: /usr/bin/qemu-system-x86_64: symbol lookup error: /usr/lib/libvirglrenderer.so.1: undefined symbol: gbm_bo_unmap

Research and attempts at resolution

Arch Wiki

This is an issue that seems quite common and I have researched extensively. I initially followed the Arch Wiki, reading the KVM, QEMU, and libvirt pages, in that order.


  1. My processor does have support for virtualisation and it is enabled.

Virtualisation support is enabled in my BIOS - both VT-x and VT-d.

  1. This is where the issue may lie - kernel modules. Running zgrep CONFIG_KVM /proc/config.gz outputs the following:
# CONFIG_KVM_DEBUG_FS is not set

lsmod | grep kvm outputs this:

kvm_intel             311296  0
kvm                   778240  1 kvm_intel
irqbypass              16384  1 kvm

I noticed that kvm_intel seems to be set to zero, but is mentioned at the end of the following line. I'm not particularly familiar with how kernel modules work, to be clear, but I decided to try load the module with sudo modprobe kvm_intel, which returns nothing - a good sign, as far as I'm aware. Running sudo modprobe kvm to be certain is the same.


  1. I installed QEMU like any other package.


  1. I installed libvirt and virt-manager like any other package.
  2. I ensured I had both ebtables and dnsmasq installed and up-to-date.
  3. I created /etc/polkit-1/rules.d/50-libvirt.rules and added this to the file:
/* Allow users in kvm group to manage the libvirt
daemon without authentication */
polkit.addRule(function(action, subject) {
    if (action.id == "org.libvirt.unix.manage" &&
        subject.isInGroup("kvm")) {
            return polkit.Result.YES;
  1. I added myself to the kvm group (and libvirt, which I think I saw somewhere online?) via useradd; this can be confirmed by running groups <username>, which I did:

wheel kvm libvirt <username>

  1. I then enabled and started the libvirtd and virtlogd services, and rebooted.

  2. I then tested whether virsh works in addition to virt-manager; virsh outputs the following:

Welcome to virsh, the virtualization interactive terminal.

Type:  'help' for help with commands
       'quit' to quit

virsh #

Additional research

As I mentioned this is a seemingly widespread issue, but following the instructions of many a Stack Exchange answer results in generally the same thing.

I have tested the following:

Countless other articles and answers offer similar advice.

Software specifications

  • Kernel 5.3.5-arch1-1-ARCH (latest default Arch kernel)
  • libvirt 5.6.0-1
  • virt-manager 2.2.1-1
  • QEMU 4.1.0-2
  • polkit 0.116-3

I have no idea if video-related packages are relevant, but the proprietary drivers have proven to be problematic in the past.

  • mesa 192.2.1-1
  • xf86-video-amdgpu 19.0.1-1
  • opencl-amdgpu-pro-orca 19.30_855429-1

Hardware specifications

  • CPU Intel i7 4790k
  • Motherboard Asus Maximus VII Hero

Will provide any necessary additional specs as requested.

  • 1. Please post text listings instead of images. 2. Have you relogged to the system after adding your user to the groups? Are you guessing which groups to join? You should check and know this for sure. 3. Have you inspected logs?
    – user147505
    Oct 13, 2019 at 22:48
  • Hi @Tomasz, yes I have rebooted/relogged the system several times since applying those changes. I know that I needed to add myself to (at least) the kvm group with the polkit changes as that's what the Arch Wiki specifies. Which logs should I be checking? Oct 14, 2019 at 10:37
  • I don't know how they're broken down there, but at least the syslog.
    – user147505
    Oct 14, 2019 at 10:40
  • Updated question accordingly Oct 14, 2019 at 11:25

3 Answers 3


Your problem is: opencl-amdgpu-pro-orca.
It delivers its own libgbm.so.1 which is missing that symbol even with latest AUR version with a default. It is put in search path first.
So You can disable these drivers or try to get / compile a fixed / updated version that includes this feature - or try to disable that lib search path only for the libvirtd servcie (add LD_LIBRARY_PATH=/usr/lib environment variable to service startup procedure).

How to analyze such issues for example:

ldd /usr/lib/libvirglrenderer.so.1
ldd /usr/lib/libvirglrenderer.so.1|awk '$3!=""{print $3}'|while read file; do objdump -TC -j.text $file|grep gbm_bo_unmap && echo $file; done
LD_LIBRARY_PATH=/usr/lib ldd /usr/lib/libvirglrenderer.so.1|awk '$3!=""{print $3}'|while read file; do objdump -TC -j.text $file|grep gbm_bo_unmap && echo $file; done
  • This was it. I've updated my question with some additional information to potentially help anyone in the future. Oct 21, 2019 at 10:01
  • 1
    Fine if it is working without completeley uninstalling the AMD drivers. I did not know whether that would work.
    – user301446
    Oct 21, 2019 at 10:20

Your journalctl output shows:

Oct 14 22:23:00 okcomputer libvirtd[35615]: Failed to probe capabilities for /usr/bin/qemu-system-x86_64: internal error: Failed to start QEMU binary /usr/bin/qemu-system-x86_64 for probing: /usr/bin/qemu-system-x86_64: symbol lookup error: /usr/lib/libvirglrenderer.so.1: undefined symbol: gbm_bo_unmap

Try just running /usr/bin/qemu-system-x86_64 -help and you'll likely see the same error. These undefined symbol errors happen when the version of qemu that is installed does not match the version of the referenced library that it was built against.

I don't know the specifics on Arch, but on Fedora the relevant package is called virglrenderer. It likely needs to be upgraded

The reason this manifests itself as KVM is not available is that libvirt (and by extension virt-manager) didn't find a working qemu version that matches your host architecture, which is necessary for KVM to work.

  • 1
    I didn't have any success with this, unfortunately. Since Arch is rolling I already had the latest version of virglrenderer, and reinstalling it didn't change anything. The git version on the AUR gave the same result in both logs and in the virt-manager UI. Thanks for the reply though! Oct 15, 2019 at 5:57
  • 1
    I tried googling about gbm_bo_unmap which is mentioned in the error, and there's definitely a history with other libraries having issues with that symbol missing. I think it comes from mesa? /usr/include/gbm.h is is from mesa-libgbm-devel on Fedora. So maybe something around that needs to be changed or updated on your machine Oct 15, 2019 at 13:15

Well, I've "solved" this removing the proprietary drivers completely. I plan to send my GPU on passthrough to a VM, so I think those will not be needed - hopefully.

It is an odd situation...


You must log in to answer this question.

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