Updated: October 7, 2020
It's been a while since I've encountered any major problems with KVM. Then again, to be fair, I've not used it that extensively in the past few years. But recently, I did have a spur of activity with this virtualization technology, and the productivity came with some troubles as a topping.
As it happens, I tried to launch a virtual machine - nothing special, just kvm xyz and whatnot. I got the following error message: Could not access KVM kernel module: Permission denied. And thus beginneth this little tutorial, which shows all the different things you can do to check what may be wrong, ans how to resolve the issue. After me.
Problem in more detail
The full error message:
Could not access KVM kernel module: Permission denied
qemu-system-x86_64: failed to initialize KVM: Permission denied
What it indicates is that - most likely - the KVM userspace component cannot access the KVM driver. This usually stems from incorrect permissions.
The first thing you want to do is check that your user is a member of the KVM and libvirt groups. Once you've made these changes, you will need to launch a new shell so the group membership changes take place. The simplest way is to re-login into your user session.
sudo usermod -G -a kvm "username"
sudo usermod -G -a libvirtd "username"
Device node permissions
Additionally, you want to check the permissions on the /dev/kvm device. The correct default permissions should be 660 and root:kvm ownership for the device file. As you can see, if you're not root or a member of the kvm group, you will not have access.
ls -ld /dev/kvm
crw-rw---- 1 root kvm 10, 232 May 27 10:43 /dev/kvm
Another thing you may want to check is whether the correct udev rules are in place. If you're wondering, udevd is a device file system management service, which sets correct permissions for entries under /dev. Typically, when you install the KVM software, one of the packages in the bundle will provide the necessary rule. If this rule is not present, and there have been bugs before, then you may want to create the rule yourself.
Under, /etc/udev/rules.d/, create a file named XX-kvm.rules. XX stands for a number, which determines the lexical order by which the rules will be parsed and executed, similar to GRUB2 rules. In some cases, the order of different rules may be important. If you are not certain, and there's nothing you know depends on the KVM functionality to run, you can use 99-kvm.rules.
Inside this file, add the following line:
KERNEL=="kvm", GROUP="kvm", MODE="0660"
What do we have here? If you're in the TL;DR version of how to write udev rules, read yonder. In simpler terms:
- KERNEL - the kernel name of the device
- GROUP - the UNIX group that should own the device
- MODE - the bitwise permissions for the device
Once the rule is in place, reload the rules without rebooting:
udevadm control --reload-rules
And to be on the safe side, you may also want to restart the libvirt service:
systemctl restart libvirtd
Device node permissions - again
The final piece of this equation - if none of the solutions above work, you can simply change the permissions on /dev/kvm to a more relaxed set. Instead of 660, you can use 666 - this means that any user on the system will be able to manage KVM virtualization. In a home setup, this isn't such a big deal.
sudo chmod +666 /dev/kvm
And now you should be able to run KVM majestically.
Here we go. This tutorial isn't too long, but it covers quite a few areas. Now, it's not a generic debugging article for all and any issue related to KVM. For that, you have my older KVM troubleshooting guide, plus email, so you can ask for fresh tips and solutions and whatnot. We're specifically talking about the KVM startup permission issue, and you have three or four different ways to analyze and resolve it.
Overall, KVM is a powerful, flexible virtualization software - with the one downside that it can be quite nerdy, and thus not as accessible as some other, more frontend-friendly tools. Not that virtualization isn't nerdy stuff to begin with, but hey. Well, if you encounter a snag with creating or starting your VMs with KVM due to wrong permissions, the checklist above should get you up and running. Simple, non-intrusive, no reboot needed. And we're done here, fellas.