Hi all, I am trying to use qemu-kvm through virt-manager, so I emerged virt-manager, launched "/etc/init.d/libvirtd start". I started virt-manager then I created a new VM but at the last step it gives me this error: Could not access KVM kernel module: Permission denied failed to initialize KVM: Permission denied No accelerator found! If I downgrade libvirt to 0.9.11.3 it works without any other changes Thanks
please check whether /dev/kvm belongs to root:kvm and that user qemu is a member of group kvm. For me, the fix was a simple usermod -a -G kvm qemu
Still doesn't work, this is how I install virt-manager and qemu-kvm: emerge -a virt-manager usermod -G kvm -a myuser chown root:kvm /dev/kvm chmod 0660 /dev/kvm echo 'modules="kvm-amd"' >> /etc/conf.d/modules /etc/init.d/libvirtd start rc-update add libvirtd default Reboot And this is the permission of /dev/kvm crw-rw----+ 1 root kvm 10, 232 11 giu 2012 kvm
can you show the output of groups qemu ? libvirtd is using the user qemu to run the virtual machines, not root. I don't know whether that changed from previous versions.
this is a duplicate of bug 420649
(In reply to comment #2) > Still doesn't work, this is how I install virt-manager and qemu-kvm: > > emerge -a virt-manager > usermod -G kvm -a myuser > chown root:kvm /dev/kvm > chmod 0660 /dev/kvm > echo 'modules="kvm-amd"' >> /etc/conf.d/modules > /etc/init.d/libvirtd start > rc-update add libvirtd default > > Reboot > > And this is the permission of /dev/kvm > crw-rw----+ 1 root kvm 10, 232 11 giu 2012 kvm Please try as a fist step to configure and start a virtual machine as user root, then use your regular user account as a second step. This way you can distinguish between libvirt permission problems towards qemu (which is dealt here) and permission problems between the virt-manager and libvirt.
groups qemu gives me: qemu
If I run virt-manager with "gksu virt-manager" same error when I create a VM: Impossibile completare l'installazione: 'errore interno Process exited while reading console log output: char device redirected to /dev/pts/1 Could not access KVM kernel module: Permission denied failed to initialize KVM: Permission denied No accelerator found! ' Traceback (most recent call last): File "/usr/share/virt-manager/virtManager/asyncjob.py", line 45, in cb_wrapper callback(asyncjob, *args, **kwargs) File "/usr/share/virt-manager/virtManager/create.py", line 1909, in do_install guest.start_install(False, meter=meter) File "/usr/lib/python2.7/site-packages/virtinst/Guest.py", line 1239, in start_install noboot) File "/usr/lib/python2.7/site-packages/virtinst/Guest.py", line 1307, in _create_guest dom = self.conn.createLinux(start_xml or final_xml, 0) File "/usr/lib/python2.7/site-packages/libvirt.py", line 2475, in createLinux if ret is None:raise libvirtError('virDomainCreateLinux() failed', conn=self) libvirtError: errore interno Process exited while reading console log output: char device redirected to /dev/pts/1 Could not access KVM kernel module: Permission denied failed to initialize KVM: Permission denied No accelerator found!
*** Bug 420649 has been marked as a duplicate of this bug. ***
(In reply to comment #4) > this is a duplicate of bug 420649 Technically it's the other way around, but maintainers, please look into bug 420649 comment 0 as well.
(In reply to comment #9) > (In reply to comment #4) > > this is a duplicate of bug 420649 > > Technically it's the other way around, but maintainers, please look into bug > 420649 comment 0 as well. Yes, indeed, in my opinion the qemu-kvm package should be fixed. libvirt is doing everything the right way! The ebuild of qemu-kvm should add the user qemu to the kvm group, who else is using kvm except qemu-kvm??????
(In reply to comment #7) > If I run virt-manager with "gksu virt-manager" same error when I create a VM: > > > Impossibile completare l'installazione: 'errore interno Process exited while > reading console log output: char device redirected to /dev/pts/1 > Could not access KVM kernel module: Permission denied > failed to initialize KVM: Permission denied > No accelerator found! > ' > > Traceback (most recent call last): > File "/usr/share/virt-manager/virtManager/asyncjob.py", line 45, in > cb_wrapper > callback(asyncjob, *args, **kwargs) > File "/usr/share/virt-manager/virtManager/create.py", line 1909, in > do_install > guest.start_install(False, meter=meter) > File "/usr/lib/python2.7/site-packages/virtinst/Guest.py", line 1239, in > start_install > noboot) > File "/usr/lib/python2.7/site-packages/virtinst/Guest.py", line 1307, in > _create_guest > dom = self.conn.createLinux(start_xml or final_xml, 0) > File "/usr/lib/python2.7/site-packages/libvirt.py", line 2475, in > createLinux > if ret is None:raise libvirtError('virDomainCreateLinux() failed', > conn=self) > libvirtError: errore interno Process exited while reading console log > output: char device redirected to /dev/pts/1 > Could not access KVM kernel module: Permission denied > failed to initialize KVM: Permission denied > No accelerator found! Hi Yellowhat, your problem can easly solved when you login as root and run the command gpasswd -a qemu kvm which adds the user qemu to the group kvm (and is my way to express it, another possibility is shown in comment #1) Martin
(In reply to comment #11) > > > Hi Yellowhat, > > your problem can easly solved when you login as root and run the command > > > gpasswd -a qemu kvm > > > which adds the user qemu to the group kvm (and is my way to express it, > another possibility is shown in comment #1) > > Martin Thanks you very much this solved my problem
Hi Cardoe, the ebuild needs to add qemu to the kvm group. This should allow libvirt to run VMs as qemu user, which is much more secure than running them as root and should be the default IMHO.
This also has the sideeffekt, that you cannot access disks, volume groups etc. In order not to change the default behaviour and fsck up existing installations, we should set this in /etc/libvirt/qemu.conf: # The user ID for QEMU processes run by the system instance. user = "root" # The group ID for QEMU processes run by the system instance. group = "root"
(In reply to comment #13) > Hi Cardoe, the ebuild needs to add qemu to the kvm group. This should allow > libvirt to run VMs as qemu user, which is much more secure than running them > as root and should be the default IMHO. It is, look at the ebuild. It contains the following lines: enewgroup qemu 77 enewuser qemu 77 -1 -1 qemu kvm This is something new I've enabled for 0.9.12, previously we ran them as root so I'm aware of the change I made.
(In reply to comment #14) > This also has the sideeffekt, that you cannot access disks, volume groups > etc. > In order not to change the default behaviour and fsck up existing > installations, we should set this in /etc/libvirt/qemu.conf: > > # The user ID for QEMU processes run by the system instance. > user = "root" > > # The group ID for QEMU processes run by the system instance. > group = "root" Incorrect, the ./configure script options override this. The migration is handled in the ebuild with a note for the one type of migration that can't be done automatically. I've switched over half a dozen machines using the ebuild and things have been successful. There was a masked copy of the ebuild in the tree as I worked on it that didn't migrate everything over correctly. And well needed work but it was explicitly masked but it appears some people used it. It looks like those issues have been resolved by doing some of the steps by hand that are now in the ebuild that's unmasked.
(In reply to comment #16) > And well needed work but it was > explicitly masked but it appears some people used it. Good work if this is now all solved, thank you! I just want to point out that I did in fact only put the package in package.keywords, not in package.unmask. From what I can see it was masked only in the same way as it is masked now, otherwise I wouldn't have touched it last weekend.
(In reply to comment #16) > (In reply to comment #14) > > > > # The user ID for QEMU processes run by the system instance. > > user = "root" > > > > # The group ID for QEMU processes run by the system instance. > > group = "root" > > > Incorrect ... Whatever you both are talking of, turn on logging (log_level=3) in /etc/libvirt/libvirtd.conf, then start a VM and look what's happening in /var/log/libvirt/libvirtd.log You will see something like virSecurityDACSetOwnership:100 : Setting DAC user and group on '/data/now27/virtio-win-1.3.3.iso' to '77:1017' which means that libvirtd sets some ACLs on the disk files just before launching the qemu-kvm process, so qemu-kvm can access them. Maybe that helps with your discussion.
(In reply to comment #15) > It is, look at the ebuild. It contains the following lines: > > enewgroup qemu 77 > enewuser qemu 77 -1 -1 qemu kvm > > This is something new I've enabled for 0.9.12, previously we ran them as > root so I'm aware of the change I made. but what is happening in an upgrade situation where user qemu already exists, but only as member of group qemu (not kvm)? I think the upgrade case should be checked and properly handled, so that people like me wont get their previously running configuration screwed up. BTW I think this should be done in the qemu-kvm ebuild - because they introduced the qemu user and are the only customers for the kernel's /dev/kvm - and libvirtd is perfectly right with running VMs as user qemu. So my intention was to open bug 420649 to get qemu-kvm fixed... and to inform the desperate libvirt users. Martin
(In reply to comment #18) > (In reply to comment #16) > > (In reply to comment #14) > > > > > > # The user ID for QEMU processes run by the system instance. > > > user = "root" > > > > > > # The group ID for QEMU processes run by the system instance. > > > group = "root" > > > > > > Incorrect ... > > Whatever you both are talking of, turn on logging (log_level=3) in > /etc/libvirt/libvirtd.conf, then start a VM and look what's happening in > /var/log/libvirt/libvirtd.log > > You will see something like > > virSecurityDACSetOwnership:100 : Setting DAC user and group on > '/data/now27/virtio-win-1.3.3.iso' to '77:1017' > > which means that libvirtd sets some ACLs on the disk files just before > launching the qemu-kvm process, so qemu-kvm can access them. > > Maybe that helps with your discussion. This is exactly what I am referring to. The configure script overrode the values correctly.
(In reply to comment #19) > (In reply to comment #15) > > > It is, look at the ebuild. It contains the following lines: > > > > enewgroup qemu 77 > > enewuser qemu 77 -1 -1 qemu kvm > > > > This is something new I've enabled for 0.9.12, previously we ran them as > > root so I'm aware of the change I made. > > but what is happening in an upgrade situation where user qemu already > exists, but only as member of group qemu (not kvm)? > > I think the upgrade case should be checked and properly handled, so that > people like me wont get their previously running configuration screwed up. > > BTW I think this should be done in the qemu-kvm ebuild - because they > introduced the qemu user and are the only customers for the kernel's > /dev/kvm - and libvirtd is perfectly right with running VMs as user qemu. So > my intention was to open bug 420649 to get qemu-kvm fixed... and to inform > the desperate libvirt users. > > Martin Actually the qemu-kvm ebuild only makes a kvm group and does not make the qemu user. We haven't had this user in Gentoo until it was added in libvirt 0.9.12 where it is created with the enewuser call.
(In reply to comment #17) > (In reply to comment #16) > > And well needed work but it was > > explicitly masked but it appears some people used it. > > Good work if this is now all solved, thank you! > > I just want to point out that I did in fact only put the package in > package.keywords, not in package.unmask. From what I can see it was masked > only in the same way as it is masked now, otherwise I wouldn't have touched > it last weekend. It's possible I did something wrong and unleashed this on you guys inadvertently. I often add virtualization ebuilds to the tree masked for a day or two so that I can try them on the different machines I have access to before unleashing them on the user base.