Created attachment 783181 [details] dmesg, cpuinfo, lsmod Description of problem: After installing all KVM related stuff in Fedora 18, with "yum install @virtualization" and executing virt-manager. If you select KVM (the default one) as hipervisor, you'll have a long error: "Could not access KVM kernel module: Permission denied failed to initialize KVM: Permission denied No accelerator found!" If you select QEMU, everything runs just fine. If you edit qemu.conf and uncomment "user =" and "group =", and put the username of the current logged user, trying of using virt-manager, and restart libvirtd, the problem is solved. So, is it a bug, a bad feature or packaging?. The default installation of KVM stuff, does not allow to use KVM by default (but, is the default one, ironic right?), if qemu.conf is not edited KVM does not work. Version-Release number of selected component (if applicable): Fedora 18 x86_64 up to date at Mar 06 Aug 2013 kernel-3.9.11-200.fc18.x86_64 libvirt-0.10.2.6-1.fc18.x86_64 qemu-kvm-1.2.2-13.fc18.x86_64 virt-manager-0.9.5-1.fc18.noarch How reproducible: Always in the default installation of virt-manager, libvirt and qemu-kvm whitout modifying qemu.conf Steps to Reproduce: 1.yum install @virtualization 2.virt-manager 3.new machine, kvm is selected by default, create the machine, error! Actual results: KVM is buggy, needed to edit qemu.conf for the normal use as default (KVM) Expected results: KVM works by default whitout making any modifications Additional info: External bugs related, attach dmesg, lsmod and cpuinfo as txt file
Same problem here: https://bbs.archlinux.org/viewtopic.php?id=157102
getfacl /dev/kvm getfacl: Eliminando '/' inicial en nombres de ruta absolutos # file: dev/kvm # owner: root # group: kvm user::rw- user:nix:rw- group::--- mask::rw- other::rw-
After reboot, the result of getfacl /dev/kvm is: getfacl: Eliminando '/' inicial en nombres de ruta absolutos # file: dev/kvm # owner: root # group: kvm user::rw- user:nix:rw- group::rw- mask::rw- other::rw- __________________________ |Note the "group" ACL entry| |__________________________| Right, the group have the correct permissions after reboot, and re-commenting the lines "user =" and "group =" in etc/libvirt/qemu.conf everything works fine. So, reboot is a request after installing KVM stuff??, is not specified. Is a bad configuration in scripts of the rpm (postinstall) ?. Is it possible to include getfacl directives in postinstall scripts of the rpm for to set correct ACL in /dev/kvm without reboot?.
Sorry, add a bit detail: kvm kernel module always loaded, without setting /dev/kvm permissions The bug is in udev or kernel originally and libvirt should not be fixed or the rpm?. Thanks
Possible patches in the external tracker of launchpad: https://bugs.launchpad.net/ubuntu/+source/qemu-kvm/+bug/1057024
@Cole Robinson, The title of the bug is fine, but is not occasionally, if the user never install KVM or related stuff, start a installation of Fedora 18->install KVM related stuff and virtualization->start virt-manager without reboot the computer. Regards
Setting to POST, since a 'fix' is already available, we just need to adapt it to fedora
qemu-1.2.2-14.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/qemu-1.2.2-14.fc18
Package qemu-1.2.2-14.fc18: * should fix your issue, * was pushed to the Fedora 18 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing qemu-1.2.2-14.fc18' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-15778/qemu-1.2.2-14.fc18 then log in and leave karma (feedback).
qemu-1.2.2-14.fc18 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report.
This does not seem to be fixed in Fedora 19 since bug 967836 still occurs which claims that its root cause is fixed with this bug, There is also no information here or in the updates notes about how this bug is supposed to be fixed, i.e. about which permissions need to be set for /dev/kvm, making it impossible to verify this for F19.
experiments show, that /dev/kvm needs to be 666 on Fedora 19 to make libvirt work after restart of libvirtd. But there are rw ACL/group permissions for my user as well.
This change was pushed to F19 in 1.4.2-8, I just didn't add it to the bodhi update since I didn't want an F19 package to autoclose and F18 bug. The current packages seem to be working correctly for me AFAICT. On my F19 machine, I did: - yum remove qemu-system-x86 qemu-kvm - rmmod kvm_amd && rmmod kvm - modprobe kvm_amd && modprobe kvm No permissions are the default 'bad' permissions for /dev/kvm, 660. - yum install qemu-kvm (pulls in version 1.4.2-13) /dev/kvm permissions are now correctly /dev/kvm Till, can you explain what you did to reproduce? Any chance you were using old packages?
(In reply to Cole Robinson from comment #13) > Till, can you explain what you did to reproduce? Any chance you were using > old packages? I did nothing fancy to get to this point. I installed qemu-kvm-1.4.2-13.fc19 on So 17 Nov 2013 20:06:27 CET and rebooted since then. When I tried to use virt-manager for the first time after reboot, the permissions were wrong, i.e. 660 and owned by root:till with a acl for the user till.
(In reply to Till Maas from comment #14) > (In reply to Cole Robinson from comment #13) > > > Till, can you explain what you did to reproduce? Any chance you were using > > old packages? > > I did nothing fancy to get to this point. I installed qemu-kvm-1.4.2-13.fc19 > on > So 17 Nov 2013 20:06:27 CET and rebooted since then. When I tried to use > virt-manager for the first time after reboot, the permissions were wrong, > i.e. 660 and owned by root:till with a acl for the user till. Does a host reboot reset the permissions to the incorrect values? (It doesn't for me) Anything is dmesg | grep -i kvm?
Sorry for the trouble. There was an old rules file in /etc/udev/rules.d. However, this did not cause trouble back in July, when I know I used kvm. Also the permissions are still a little bit strange, since they are 666 but still there is an acl for my user account. The latter does not seem to be needed since it is world-writeable.
(In reply to Till Maas from comment #16) > Also the permissions are still a little bit strange, since they are 666 but > still there is an acl for my user account. An acl for your user account does not necessarily imply that the uid that qemu will be run as has access. Does the group mentioned in /etc/libvirtd/qemu.conf have access to the device?
(In reply to Eric Blake from comment #17) > (In reply to Till Maas from comment #16) > > Also the permissions are still a little bit strange, since they are 666 but > > still there is an acl for my user account. > > An acl for your user account does not necessarily imply that the uid that > qemu will be run as has access. Does the group mentioned in > /etc/libvirtd/qemu.conf have access to the device? There is no user/group specified in /etc/libvirtd/qemu.conf. It seems that VMs run as qemu who is in the groups qemu and kvm. However, it seems to be working now, even though I do not understand why there are both rw permissions for other and rw permissions for certain groups. The latter are unnecessary.
(In reply to Till Maas from comment #18) > (In reply to Eric Blake from comment #17) > > (In reply to Till Maas from comment #16) > > > Also the permissions are still a little bit strange, since they are 666 but > > > still there is an acl for my user account. > > > > An acl for your user account does not necessarily imply that the uid that > > qemu will be run as has access. Does the group mentioned in > > /etc/libvirtd/qemu.conf have access to the device? > > There is no user/group specified in /etc/libvirtd/qemu.conf. It seems that > VMs run as qemu who is in the groups qemu and kvm. > > However, it seems to be working now, even though I do not understand why > there are both rw permissions for other and rw permissions for certain > groups. The latter are unnecessary. I think the ACL rules are added by udev for the current active user account. Those don't cover the qemu user that libvirt uses by default though so we change it to 666.