Virt-Manager | KVM kernel module: Permission denied

Hi guys,

I was trying to create a new VM in Virt-Manager with Qemu.

I get to the start installation bit and I get this error:

The full error description is as follows:

Não foi possível terminar a instalação: ‘internal error: qemu unexpectedly closed the monitor: 2017-10-04T12:13:03.898997Z qemu-system-x86_64: -chardev pty,id=charserial0: char device redirected to /dev/pts/0 (label charserial0)
Could not access KVM kernel module: Permission denied
2017-10-04T12:13:03.899071Z qemu-system-x86_64: failed to initialize KVM: Permission denied’

Traceback (most recent call last):
File “/usr/share/virt-manager/virtManager/”, line 89, in cb_wrapper
callback(asyncjob, *args, **kwargs)
File “/usr/share/virt-manager/virtManager/”, line 2545, in _do_async_install
File “/usr/share/virt-manager/virtinst/”, line 498, in start_install
doboot, transient)
File “/usr/share/virt-manager/virtinst/”, line 434, in _create_guest
domain = self.conn.createXML(install_xml or final_xml, 0)
File “/usr/lib/python2.7/site-packages/”, line 3640, in createXML
if ret is None:raise libvirtError(‘virDomainCreateXML() failed’, conn=self)
libvirtError: internal error: qemu unexpectedly closed the monitor: 2017-10-04T12:13:03.898997Z qemu-system-x86_64: -chardev pty,id=charserial0: char device redirected to /dev/pts/0 (label charserial0)
Could not access KVM kernel module: Permission denied
2017-10-04T12:13:03.899071Z qemu-system-x86_64: failed to initialize KVM: Permission denied

I tried reloading the drivers by doing

rmmod kvm_amd
rmmod kvm
modprobe kvm
modprobe kvm_amd

But it didn’t work…

What am I missing?

Thank’s in advance!

system specs? distribution?

What user is libvirtd running as?

If virt-manager is running as your user, you will need to be a member of the appropriate group. I believe it’s qemu-libvirt?

Hi guys,

My system is composed by a Ryzen 1700 with a Gigabyte Gaming 5.

I’m using Antergos with the 4.13.3-1 Kernel.

libvirtd is running as root (I did ps aux | grep libvirtd) I don’t know if this was the correct approach.

That’s one approach. Another would be to use systemctl to find the main process and use ps to find the user:

~  systemctl status libvirtd
● libvirtd.service - Virtualization daemon
   Loaded: loaded (/usr/lib64/systemd/system/libvirtd.service; enabled; vendor preset: enabled)
   Active: active (running) since Wed 2017-10-04 07:51:26 PDT; 4h 16min ago
     Docs: man:libvirtd(8)
 Main PID: 798 (libvirtd)
   CGroup: /system.slice/libvirtd.service
           ├─798 /usr/sbin/libvirtd
           ├─868 /usr/bin/dnsmasq --conf-file=/var/lib/libvirt/dnsmasq/net1.c...
           └─869 /usr/bin/dnsmasq --conf-file=/var/lib/libvirt/dnsmasq/net1.c...
 ~  ps u 798                 
root       798  0.0  0.0 363636 16924 ?        Ssl  07:51   0:00 /usr/sbin/libvi

Since you’re running as root, I’m not sure why this isn’t working.

Have you updated your kernel since rebooting? If that’s the case, you’ll need to reboot to get everything working. (I know Antergos and Arch update quite often)

Well, I wasn’t quite sure if I had updated the kernel today but I did a reboot anyway.

Didn’t work.

Just to add some more information about this, I am trying to create a VM using an .iso that is on a secondary drive.
I merely installed qemu and virt-manager, and enabled/started the libvirtd service.

I have another box with similar hardware where I run fedora 26, and there I simply did:

dnf install @virtualization

And it worked flawlessly.

1 Like

Do you have another VM that is working? Based on the wording of OP, it sounds like you do.

Are you trying to do anything complex with the VM like passthrough?

Try adding your user to the libvirt group and relogging?

sudo usermod -aG libvirt <username>
1 Like

Did you see the Livestream where I failed my way through Ubuntu? Lol. My problem. Was apparmor

Teardown and remove it ?

Or add rules as I did. Because even tho you are root. Apparmor.

Also what sgawesomeaauce said

1 Like

I keep forgetting about apparmor. :frowning:

On this computer I don’t have any VM because of the error on the OP.

Nothing complex at all. I just like to have a few VM’s on hand for testing purposes at work.

I tried adding my user to the libvirt group, and now virt-manager no longer ask for the root password, but the same error appears when I try to finalize a VM.

Well, it’s always intriguing when someone mentions something you’ve never even hear of :sweat_smile:

But are you suggesting I remove apparmor?
I googled real quick how to check if I had it enabled and it turns out I don’t have it at all…

Is your stream on Youtube?
That might help me because I’m having a little trouble figuring out how I add those rules you talk about…

I found out something interesting…

In Virt-Manager I can select several types of hypervisor connections:

-The default one is QEMU/KVM
-The Second options is QEMU/KVM Session

And when I use that second type of connection…voila

This does mean that the options for the VM become very limited.

I still don’t know Why it does not work with the qemu:///system connection though :confused:

1 Like

Interesting. I’m glad you were able to solve this, but I’m going to do some digging into this. I’m spinning up a beefy instance right now to test the problems with the “QEMU/KVM” option.

So, QEMU/KVM session connects to a libvirtd daemon running as your user. (it will launch on if there isn’t already one running) This is a bit interesting because usually you don’t have problems accessing kernel modules as root, but as an unprivileged user, you can. I suppose this is another idiosyncrasy of Ubuntu.

EDIT: WAIT! vms run as the qemu user when you’re running a qemu:///system environment, I wonder if we need to change some udev rules or something to get this to work properly.

One way or another, you’ve got it working and it’s really not a problem which one you use because there shouldn’t be a limitation.

What do you mean by limited? What exactly is being limited under this connection type?

Well I didn’t solve it per se, I just found out something interesting.
Another interesting thing I found out is that I only encounter this problem in arch based distros. In Fedora I just need to install the packages and that’s it!

By limited I mean that, because qemu:///session runs libvirtd as a user and not root, this means that any VM configuration that requires root privileges won’t be available, this is notorious in the networking department.

I think that hardware passthrough (at least through pci) isn’t available as well.

That takes some work on even the friendliest of distros.

Hmmm, let me see what I can do about figuring out what’s going on with the system connection.

If you need something on my part, just ask!

But do report on your findings, regardless of success :wink:

I haven’t found anything helpful yet, but I’m still digging.

I am at work right now, so I can’t dedicate too much time to it, but I’ll definitely keep you in the loop.

On Arch, my user is in both the kvm and libvirt groups and is able to connect to qemu:///system.

You may check out the Arch wiki on libvirt.

1 Like

I’ve been digging through that info and I’m not finding much info on what could be a solution… :confused:

Me neither, and since I’m all ready a member of these groups:

I think the solution goes a bit beyond group associations.

Besides that, I took a look at the configuration files for libvirt and polkit as they were mentioned in the Wiki, and they seem to be correctly configured in terms of permissions.