Description of problem: If kvm module is loaded before qemu-system is installed, the permissions on /dev/kvm are wrong (0660 root:root, not 0666 root:kvm), because /usr/lib/udev/rules.d/80-kvm.rules was not present when the module was loaded and the device node created. It would be nice to force a reload of udev permissions on package installation. Not terribly important, but confusing.
(In reply to comment #0) > Description of problem: > If kvm module is loaded before qemu-system is installed, the permissions on > /dev/kvm are wrong (0660 root:root, not 0666 root:kvm), because > /usr/lib/udev/rules.d/80-kvm.rules was not present when the module was > loaded and the device node created. It would be nice to force a reload of > udev permissions on package installation. Not terribly important, but > confusing. Thanks for the report, I can reproduce. Can someone on the udev side give guidance here? Is there some way to trigger udev to apply these new permissions to an already existing device node? (udevadm control --reload doesn't do that for me at least). Or maybe we move that 80-kvm.rules file into udev proper so those are always the default permissions?
This should do it: udevadm trigger --subsystem-match=misc --sysname-match=kvm --action=add The rules could only move to udev if the "kvm" group is unconditionally created before udev runs, even on a minimal system. Udev cannot use any rules with textual uid/guid which are not always on the base OS in the system db. Udev cannot resolve uids/gids over ldap and such, because it runs too early.
We already run "udevadm trigger --sysname-match=kvm" in the post script, after instaling 80-kvm.rules, so IIUC all we have to do is add "--action=add" too. BTW yes, the "kvm" group should be unconditionally in /etc/group.
Ran into this one. Had to change the group of /dev/kvm to 'kvm' and do: # setfacl -m g:kvm:rw /dev/kvm for virt-install to work.
Setting to POST since this just requires a spec file tweak
*** Bug 918914 has been marked as a duplicate of this bug. ***
qemu-1.2.2-8.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/qemu-1.2.2-8.fc18
Package qemu-1.2.2-8.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-8.fc18' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-4711/qemu-1.2.2-8.fc18 then log in and leave karma (feedback).
qemu-1.2.2-9.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/qemu-1.2.2-9.fc18
qemu-1.2.2-10.fc18 has been submitted as an update for Fedora 18. https://admin.fedoraproject.org/updates/qemu-1.2.2-10.fc18
qemu-1.2.2-10.fc18 has been pushed to the Fedora 18 stable repository. If problems still persist, please make note of it in this bug report.