virt-manager: KVM is not available

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.

Resolution

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:
[Service]
Environment="LD_LIBRARY_PATH=/usr/lib"
  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.

Problem

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.

Log

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.

KVM

  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_GUEST=y
# CONFIG_KVM_DEBUG_FS is not set
CONFIG_KVM_MMIO=y
CONFIG_KVM_ASYNC_PF=y
CONFIG_KVM_VFIO=y
CONFIG_KVM_GENERIC_DIRTYLOG_READ_PROTECT=y
CONFIG_KVM_COMPAT=y
CONFIG_KVM=m
CONFIG_KVM_INTEL=m
CONFIG_KVM_AMD=m
CONFIG_KVM_AMD_SEV=y
CONFIG_KVM_MMU_AUDIT=y

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.

QEMU

  1. I installed QEMU like any other package.

libvirt

  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.

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.

Answered By: Cole Robinson

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
Answered By: EOhm

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…

Answered By: vxp
Categories: Answers Tags: , , ,
Answers are sorted by their score. The answer accepted by the question owner as the best is marked with
at the top-right corner.