Red Hat Bugzilla – Bug 860658
nova boot fails because /dev/kvm is 0600 instead of 0666
Last modified: 2013-01-09 07:08:50 EST
Description of problem:
Following the test day instructions (with the quantum option) on F18 bare metal, nova boot ends with an ERROR state.
Version-Release number of selected component (if applicable):
Not sure, I think I've seen it twice (out of 2) and others suggested they've seen the same.
Steps to Reproduce:
The logs (which I'll attach in a minute) suggested issues with libvirt/kvm. In #fedora-openstack, derekh suggested permissions on /dev/kvm could be wrong. It turned out they were 0600 while they should probably be 0666 (as on F17) instead. chmod 0666 /dev/kvm therefore fixed the problem. It's been suggested that for others a reboot (instead of the chmod) fixed things as well.
Not sure whether this should be considered a bug in udev (or ...) instead but I figure that change happened for a reason.
Also, it was suggested I run sudo su - qemu -s /bin/sh -c virt-host-validate:
QEMU: Checking for hardware virtualization : PASS
QEMU: Checking for device /dev/kvm : FAIL (Check that the 'kvm-intel' or 'kvm-amd' modules are loaded & the BIOS has enabled virtualization)
QEMU: Checking for device /dev/vhost-net : WARN (Load the 'vhost_net' module to improve performance of virtio networking)
QEMU: Checking for device /dev/net/tun : PASS
LXC: Checking for Linux >= 2.6.26 : PASS
...but kvm and kvm-intel were loaded alright. After the chmod that test PASSes alright.
Created attachment 617531 [details]
Created attachment 617534 [details]
Note regarding the logs: what I did was roughly:
- nova boot 4 systems
- restart scheduler (as suggested in similar bugs)
- nova boot 4 systems
- chmod 0666 /dev/kvm
- nova boot 2 systems
Cole - have you seen reports of bad /dev/kvm permissions in F18?
/usr/lib/udev/rules.d/80-kvm.rules:KERNEL=="kvm", GROUP="kvm", MODE="0666"
Figure that explains why reboot helps. But the first time kvm is loaded (libvirtd is installed and started) it seems to get 0600 nevertheless - is /dev/kvm not created by udev in that situation?
Mark, haven't seen any bug reports go by about that besides this one. Is this consistently reproducible or a one off?
Even on a fresh F18 Alpha minimal install (no updates, no openstack):
crw-------. 1 root root 10, 232 Sep 27 08:46 /dev/kvm
Just to confirm Sandro's observation on a fresh F17 install, without
updates or openstack:
crw-------. 1 root root 10, 232 Sep 28 08:57 /dev/kvm
Moving to qemu as it seems that package on install should do:
chmod 666 /dev/kvm
or more generally
udevadm trigger --action=change
%post in qemu-system-x86 runs /etc/sysconfig/modules/kvm.modules where kvm kernel module is modprobed. Why modprobe itself doesn't trigger udev?
The KVM modules are part of the main kernel RPM, so perhaps the module was loaded before the KVM RPM was installed. If this was the case it would have got the default permssiosn, since the udev rules would not be present yet. Then when %post ran module, nothing would be done since they were already loaded (albeit with wrong permissions).
Fixed in qemu-1.2.0-12.fc18 and qemu-1.2.0-12.fc19.
For reference the change is:
I was a bit surprised that --action=change wasn't specified,
but I now see that that's the default operation.
Also note this was reported as an issue against F17 as well as F18.
qemu-1.2.0-12.fc18 has been submitted as an update for Fedora 18.