How to fix QEMU/KVM Not Connected Error on Ubuntu 20.04

In this tutorial, you will learn how to fix QEMU/KVM Not connected error on Ubuntu 20.04. Maybe you have installed KVM hypervisor on Ubuntu 20.04 for you to run virtual machines on it as a regular, non-root, user. However for some reasons, when your try to run virsh command to even the virt-manager, display the virtual machine desktop management tool, you end up with such errors as Qemu/KVM no connected. Let us see how to fix such error.

Disclaimer: The tutorial outlines how i fix the issue myself. This is not an official fix for the issue. Use it ayor.

Fixing QEMU/KVM Not Connected Error

A sample of the errors you encounter when running KVM as a non-root user on Ubuntu 20.04 might include the ones sampled below;

virsh -c qemu:///system

error: failed to connect to the hypervisor
error: End of file while reading data: Input/output error

virsh list --all

error: failed to connect to the hypervisor
error: End of file while reading data: Input/output error

So you have done all that is required to run KVM as a non root user, by adding your standard user name to libvirt group, but still you cannot run KVM as a standard user.

id -nG

koromicha kvm netdev nm-openvpn libvirt

All the required modules are loaded;

lsmod | grep kvm

kvm_intel             282624  0
kvm                   663552  1 kvm_intel

You have scoured through internet, but no suggested solution has so far fixed the issue with QEMU/KVM not connected? Perhaps there is something you are not looking for?

What About AppArmor?

According to Ubuntu AppArmor wiki page;

AppArmor is a Mandatory Access Control (MAC) system which is a kernel (LSM) enhancement to confine programs to a limited set of resources. Its security model is to bind access control attributes to programs rather than to users.

Its confinement is provided via profiles loaded into the kernel, typically on boot. AppArmor profiles can be in one of two modes:

• enforcement – Profiles loaded in enforcement mode will result in enforcement of the policy defined in the profile as well as reporting policy violation attempts (either via syslog or auditd).
• complain– Profiles in complain mode will not enforce policy but instead report policy violation attempts.

Well, so after checking the syslog logs;

sudo grep libvirt /var/log/syslog | grep -i apparmor | grep -i denied

Jun 28 14:53:27 koromicha kernel: [  334.660844] audit: type=1400 audit(1593345207.778:951): apparmor="DENIED" operation="bind" profile="libvirtd" pid=12254 comm="libvirtd" family="unix" sock_type="dgram" protocol=0 requested_mask="bind" denied_mask="bind" addr="@userdb-6228daaaf66b14dfd14d93ef46d962c3"
Jun 28 14:54:19 koromicha kernel: [  386.034970] audit: type=1400 audit(1593345259.145:952): apparmor="DENIED" operation="bind" profile="libvirtd" pid=14311 comm="libvirtd" family="unix" sock_type="dgram" protocol=0 requested_mask="bind" denied_mask="bind" addr="@userdb-c861507740da1fa0c3356ad3b78bffe9"
Jun 28 15:02:30 koromicha kernel: [  877.339057] audit: type=1400 audit(1593345750.437:968): apparmor="DENIED" operation="bind" profile="libvirtd" pid=16175 comm="libvirtd" family="unix" sock_type="dgram" protocol=0 requested_mask="bind" denied_mask="bind" addr="@userdb-7d70643a9f8da0342f6359907817b664"
...

From the kernel ring buffer messages;

dmesg| grep -i libvirt

[   12.737770] systemd[1]: Reached target Libvirt guests shutdown.
[   36.451935] audit: type=1400 audit(1593344909.127:909): apparmor="DENIED" operation="bind" profile="libvirtd" pid=1329 comm="libvirtd" family="unix" sock_type="dgram" protocol=0 requested_mask="bind" denied_mask="bind" addr="@userdb-17950adb1cf7fdce327fb745a8f96166"
[   82.906690] audit: type=1400 audit(1593344956.066:911): apparmor="DENIED" operation="bind" profile="libvirtd" pid=3295 comm="libvirtd" family="unix" sock_type="dgram" protocol=0 requested_mask="bind" denied_mask="bind" addr="@userdb-5f105e043aa71b33f878838eb17ed07a"
...

This indicates that AppArmor for some reasons is restraining libvirtd from use use by the regular/non-root users, irrespective of adding them to the group.

Checking the AppArmor status;

sudo aa-status

...
6 processes have profiles defined.
1 processes are in enforce mode.
   /usr/sbin/libvirtd (110108) libvirtd
...

Is libvirtd using the AppArmor security driver?

sudo virsh capabilities | less

..
    <secmodel>
      <model>apparmor</model>
      <doi>0</doi>
    </secmodel>
..

You can cross examine the AppArmor libvirtd profile;

cat /etc/apparmor.d/usr.sbin.libvirtd

And other files under, /etc/apparmor.d/libvirt/ and /etc/apparmor.d/abstractions/.

The Solution to the Problem

Well, I didn’t have much time to find a better solution than disabling the AppArmor enforcement for libvirtd;

sudo ln -s /etc/apparmor.d/usr.sbin.libvirtd /etc/apparmor.d/disable/

Reboot the machine to effect the libvirt disablement changes;

systemctl reboot -i

Once the system reboots, you should now be able to run KVM as a non root user;

virsh list --all

 Id   Name   State
--------------------

And this is it on fixing QEMU/KVM Not connected error.

Further Reading

AppArmor: Libvirtd Wiki

AppArmor Ubuntu Wiki

Related Tutorials

How to Rename KVM Virtual Machine with virsh command

Install pfSense Firewall on KVM

Use VirtualBox VMs on KVM