Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 420507 - app-emulation/libvirt-0.9.12: KVM Permission denied
Summary: app-emulation/libvirt-0.9.12: KVM Permission denied
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal
Assignee: Doug Goldstein (RETIRED)
URL:
Whiteboard:
Keywords:
: 420649 (view as bug list)
Depends on:
Blocks:
 
Reported: 2012-06-10 16:07 UTC by Vasco Gervasi
Modified: 2012-06-13 05:42 UTC (History)
5 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Vasco Gervasi 2012-06-10 16:07:17 UTC
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
Comment 1 David Klaftenegger 2012-06-11 01:16:14 UTC
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
Comment 2 Vasco Gervasi 2012-06-11 06:57:23 UTC
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
Comment 3 David Klaftenegger 2012-06-11 07:23:23 UTC
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.
Comment 4 Martin Dummer 2012-06-11 08:33:34 UTC
this is a duplicate of bug 420649
Comment 5 Martin Dummer 2012-06-11 08:38:27 UTC
(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.
Comment 6 Vasco Gervasi 2012-06-11 09:49:57 UTC
groups qemu gives me:
qemu
Comment 7 Vasco Gervasi 2012-06-11 09:50:36 UTC
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!
Comment 8 Michael Weber (RETIRED) gentoo-dev 2012-06-11 10:17:09 UTC
*** Bug 420649 has been marked as a duplicate of this bug. ***
Comment 9 Michael Weber (RETIRED) gentoo-dev 2012-06-11 10:18:07 UTC
(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.
Comment 10 Martin Dummer 2012-06-11 12:52:23 UTC
(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??????
Comment 11 Martin Dummer 2012-06-11 12:54:57 UTC
(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
Comment 12 Vasco Gervasi 2012-06-11 12:56:29 UTC
(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
Comment 13 Stefan Behte (RETIRED) gentoo-dev Security 2012-06-12 11:26:47 UTC
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.
Comment 14 Stefan Behte (RETIRED) gentoo-dev Security 2012-06-12 11:31:29 UTC
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"
Comment 15 Doug Goldstein (RETIRED) gentoo-dev 2012-06-12 18:52:51 UTC
(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.
Comment 16 Doug Goldstein (RETIRED) gentoo-dev 2012-06-12 18:56:11 UTC
(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.
Comment 17 David Klaftenegger 2012-06-12 20:11:00 UTC
(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.
Comment 18 Martin Dummer 2012-06-12 22:51:13 UTC
(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.
Comment 19 Martin Dummer 2012-06-12 23:02:31 UTC
(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
Comment 20 Doug Goldstein (RETIRED) gentoo-dev 2012-06-13 05:38:46 UTC
(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.
Comment 21 Doug Goldstein (RETIRED) gentoo-dev 2012-06-13 05:40:16 UTC
(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.
Comment 22 Doug Goldstein (RETIRED) gentoo-dev 2012-06-13 05:42:11 UTC
(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.