kvm kernel module always loaded, without setting /dev/kvm permissions

Thanks for submitting this bug. Could you please show the results of:

grep libvirt /etc/group
kvm-ok

on the server?

The output is
ubuntu-oem-main@ubuntuoemmain-Inspiron-N4010:~$ grep libvirt /etc/group
libvirtd:x:126:ubuntu-oem-main

ubuntu-oem-main@ubuntuoemmain-Inspiron-N4010:~$kvm-ok
INFO: /dev/kvm exists
KVM acceleration can be used

I can't reproduce this - please give a few more details:

1. Are you running virt-manager on a remote node? What exact, full connection url is it using?

2. How far into the creation of the VM did it get?

3. What exact options did you use for creating the VM?

If you 'sudo stop libvirt-bin; sudo start libvirt-bin' does VM creation succeed after that?

Sorry, one more question - what media and options did you use to create the host?

1. Are you running virt-manager on a remote node? What exact, full connection url is it using?
          No I am running on a local machine, host and the guest are on the same machine. Connection url: qemu:///system

2. How far into the creation of the VM did it get?
3. What exact options did you use for creating the VM?

     Host is a fresh quantal install (beta2 amd64 desktop) - also occurs in p2q upgraded one)
     a. New VM -> Enter the name with 'Local install media' to install the os
     b. Select 'Use ISO image' and Browse and select a quantal amd64 image. (OS type: Linux and Version: Ubuntu 12.10 (Quantal Quetzal))
    c. Choose 1024MB RAM
    d. Slect 'Create a disk image on the computer's hard drive' with 8GB
    e. Click Finish and then the error occurs at this point

4. If you 'sudo stop libvirt-bin; sudo start libvirt-bin' does VM creation succeed after that?
    No it does not solve, occurs even after stop/ start. Rebooting does not solve either

Thanks, I'll try the amd64 desktop image.

Can you show the result of 'ls -l /dev/kvm'?

The laptop that initially gave the error has been reinstalled .The output from an i386 machine is,

crw-rw----+ 1 root kvm 10, 232 Oct 3 09:36 /dev/kvm

I got the above from a machine that's giving the same error as the originally reported one. This particular machine used to have working kvm when it was precise and the upgrade to quantal had some issues and there fore I had to re-install kvm in it.

These are the other outputs in this machine
kvm ok
INFO: /dev/kvm exists
KVM acceleration can be used
and
grep libvirt /etc/group also had the username in it

thanks

I just retried on a fresh amd64 desk install from the iso, and could not reproduce it.

What I have seen before, though, is where the bios was set to not enable kvm, but kvm-ok failed to detect that.

Could you please boot into your bios screen and check to make sure that virtualization extensions are enabled?

If they are, then please append here the full 'cat /proc/cpuinfo' output.

Also, if you simply run

   qemu-img create x.img 1G
   kvm -hda x.img

does the kvm SDL window pop up, or do you get an error?

The bios setting indicate that virtualization is enabled and cpuinfo is attached.

qemu-img create x.img 1G
kvm -hda x.img

ceate the image successfully and brings up the kvm window.

But from the Virtual Machine Manager I am still getting the error.

(These are the main installation steps before using the VMM
1. Install a fresh quantal (or an upgrade)
2. sudo apt-get install kvm
3. Install Virtual Machine Manager from the Software Center
4. Add the user to the libvirtd group
5. Logout and login back
6. Copy a quantal iso to the desktop
7. Then follow the steps in comment #6
)

Quoting Parameswaran Sivatharman (<email address hidden>):
> The bios setting indicate that virtualization is enabled and cpuinfo is
> attached.
>
> qemu-img create x.img 1G
> kvm -hda x.img
>
> ceate the image successfully and brings up the kvm window.

But - to be sure - can you paste all output that shows up in the console
while kvm is starting up?

> But from the Virtual Machine Manager I am still getting the error.
>
>
> (These are the main installation steps before using the VMM
> 1. Install a fresh quantal (or an upgrade)
> 2. sudo apt-get install kvm
> 3. Install Virtual Machine Manager from the Software Center

Hm, I haven't tried from the software center. That should make
absolutely no difference, but perhaps it does. (I use 'apt-get
install qemu-kvm libvirt-bin virt-manager)

> 7. Then follow the steps in comment #6

To be sure, you are using the default (qemu:///system) connection in
virt-manager, right?

I'll do another fresh install this afternoon and try with the software
manager.

At 57% into the file, after kvm has been (successfully started), the kvm process exits with

2012-10-04 15:12:45.094+0000: 31861: error : qemuProcessReadLogOutput:1307 : internal error Process exited while reading console log output: 2012-10-04 15:12:44.897+0000: 32406: debug : virFileClose:70 : Closed fd 20
2012-10-04 15:12:44.897+0000: 32406: debug : virFileClose:70 : Closed fd 27
2012-10-04 15:12:44.897+0000: 32406: debug : virFileClose:70 : Closed fd 3
char device redirected to /dev/pts/9
Could not access KVM kernel module: Permission denied
failed to initialize KVM: Permission denied
No accelerator found!

@Parameswaran,

can you grep libvirt-qemu /etc/passwd, and grep for its default group in /etc/group? Its default group should be 'kvm'.

Also, what does 'grep kvm /etc/group' show - in particular are there perhaps 2 groups called 'kvm'?

Sorry - lastly, please append /var/log/libvirt/qemu/*.log for the last VM that failed to start.

Please find below the output

grep libvirt-qemu /etc/passwd
libvirt-qemu:x:117:130:Libvirt Qemu,,,:/var/lib/libvirt:/bin/false

 grep libvirt-qemu /etc/group --> returns nothing

grep kvm /etc/group
kvm:x:130:utah

the last log is also attached

Could you add your dmesg output when this happens?

For the record, psivaa says virtualbox is installed, which could cause this. However lsmod didn't show vbox* kernel modules loaded. Waiting to see whether after removing virtualbox through software center and rebooting, the problem is fixed. Since lsmod didn't show the module loaded, I'm not too optimistic.

So I installed a fresh quantal-amd64 (20121004) and then
             - sudo apt-get install kvm
             - Install Virtual Machine Manager from the Software Center
            - Add the user to the libvirtd group
            - Logout and login back
            - Copy a quantal iso to the desktop
            - Then follow the steps in comment #6

And the problem occurred despite there is no virtualbox installed in this system. The logs are attached.

That include,
         lsmod
         dmesg when the issue occurred
         syslog
        /var/log/libvirt/qemu/*.log
        and other command outputs requested earlier

This machine has virtualization enabled in bios as well, just to confirm

Hi,

at which point do you install libvirt-bin?

It doesn't get automatically installed with virt-manager.

sda seems to have some errors listed in dmesg:

[ 975.821122] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[ 975.821125] sd 0:0:0:0: [sda]
[ 975.821127] Sense Key : Aborted Command [current] [descriptor]
[ 975.821131] Descriptor sense data with sense descriptors (in hex):
[ 975.821133] 72 0b 00 00 00 00 00 0c 00 0a 80 00 00 00 00 00
[ 975.821144] 00 00 00 00
[ 975.821149] sd 0:0:0:0: [sda]
[ 975.821151] Add. Sense: No additional sense information
[ 975.821154] sd 0:0:0:0: [sda] CDB:
[ 975.821156] Write(10): 2a 00 24 8d a1 00 00 04 00 00
[ 975.821165] end_request: I/O error, dev sda, sector 613261568

I also see:

[ 8.448408] kvm: VM_EXIT_LOAD_IA32_PERF_GLOBAL_CTRL does not work properly. Using workaround

After logging in remotely (thanks) I followed https://wiki.ubuntu.com/SergeHallyn_libvirtnest to create a domain from the command line, and it worked. After that, psivaa was able to create a VM using virt-manager!

So after a fresh install, initially the issue was still present but then when i followed https://wiki.ubuntu.com/SergeHallyn_libvirtnest and then after a reboot i am able to create vms using Virtual Machine Manager.

Here attached dmesg from the other machine which is HP Pavilion g6 Notebook PC . Another one is Inspiron N4010

getfacl /dev/kvm

getfacl: Removing leading '/' from absolute path names
# file: dev/kvm
# owner: root
# group: kvm
user::rw-
user:sivatharman:rw-
group::---
mask::rw-
other::---

Interesting...I have group::rw-...it seems your permissions on your /dev/kvm device aren't correct.

Do you have /lib/udev/rules.d/40-qemu-kvm.rules ?

So I did a fresh quantal install and then (after installing kvm and virtual machine manager and then adding user to the libvirtd group) . The issue was present and when i checked getfacl /dev/kvm it had group:---

Then after the reboot i checked getfacl again it had group:rw-
When i tried booting the vm using the Virtual Machine manager it worked!

So apparently a reboot solved the issue.

Quoting Parameswaran Sivatharman (<email address hidden>):
> So I did a fresh quantal install and then (after installing kvm and
> virtual machine manager and then adding user to the libvirtd group) .
> The issue was present and when i checked getfacl /dev/kvm it had
> group:---
>
> Then after the reboot i checked getfacl again it had group:rw-
> When i tried booting the vm using the Virtual Machine manager it worked!
>
> So apparently a reboot solved the issue.

But, to be clear, on the other machine a reboot did *not* solve the
issue, right?

I have a feeling the permissions bug (which I can't yet explain)
should be a separate launchpad bug, and the original bug should
be marked invalid until it can be reproduced elsewhere.

Reboot did solve the issue on both machines. ( In one of them, which had a troublesome upgrade I had to remove virtual box as well, but I am not sure if that was really needed)

Root cause found: udev automatically loads kvm_intel even when qemu-kvm is not installed. The kvm group and udev file causing /dev/kvm to be chgrp'd to kvm and set its permissions are installed by qemu-kvm.

If it were only a question of permissions I'd say the udev package should be setting those. However it would also have to add the kvm group.

So the qemu-kvm postinst should set the permissions on /dev/kvm if that already exists.

No, I was looking in the wrong place - qemu-kvm.postinst already does exactly that!

In fact, I'm starting to wonder whether the way to reproduce this would be to not 'apt-get install kvm' before installing libvirt-bin. The kvm kernel module will be loaded, but won't be configured for use by libvirt. I'm not sure whether we should consider that a bug, or mis-configuration by the admin.

If kvm is not configured, then virt-manager tells me at the first 'New virtual machine" screen that:

"""
Error: No hypervisor options were found for this connection.

This usually means that QEMU or KVM is not installed on your machine, or the KVM kernel modules are not loaded.
"""

So I simply cannot reproduce this.

At this point I will mark the bug 'incomplete' meaning that we need more
information to resolve it (per discussions at last UDS). If more information
becomes available, please do comment here.

psivaa,

Will you be at UDS? Would it be at all possible for you to bring one of these
laptops so we can watch this happen together?

@Serge,
I will be at the UDS and Ill bring the machine there.
Thanks

Thanks for bringing the laptop.

We took a look. After installing qemu-kvm and libvirt (and virt-manager) /dev/kvm has the right permissions and ownership. User ubuntu is able to run kvm. However when doing

    sudo -u libvirt-qemu strace -f -o/tmp/outout kvm -vnc :1

you see that when it tries to open /dev/kvm it gets -EACCESS.

Doing 'rmmod kvm_intel kvm; modprobe kvm_intel' results in /dev/kvm being created with the exact same owner/perms as before, but now libvirt-qemu is able to open the device.

I did not think to look at the acls.

At last, the cause is found. /lib/udev/rules.d/70-udev-acl.rules adds an acl to /dev/kvm denying group write perms. (qemu-kvm installs its own /lib/udev/rules.d/40-qemu-kvm.rules when qemu-kvm is installed) The qemu-kvm.postinst does chgrp and chmod /dev/kvm, but "chmod g+rw" does not remove the group-rw acl. qemu-kvm.postinst needs to manually remove that acl.

This bug was fixed in the package qemu-kvm - 1.2.0+noroms-0ubuntu3

---------------
qemu-kvm (1.2.0+noroms-0ubuntu3) raring; urgency=low

  * debian/qemu-kvm.postinst: remove the g::--- acl which udev may have
    inserted. (LP: #1057024)
 -- Serge Hallyn <email address hidden> Thu, 01 Nov 2012 20:46:57 +0100

The change that's been uploaded to precise for this is:

diff -u qemu-kvm-1.0+noroms/debian/qemu-kvm.postinst qemu-kvm-1.0+noroms/debian/qemu-kvm.postinst
--- qemu-kvm-1.0+noroms/debian/qemu-kvm.postinst
+++ qemu-kvm-1.0+noroms/debian/qemu-kvm.postinst
@@ -16,2 +16,15 @@
-exit 0
+# if we just installed the package, udev rules aren't picked up yet,
+# so udev created the device (/dev/kvm) with default permissions.
+# Fix it here, but only if the perms are like default.
+# (See #607391)
+
+if [ -c /dev/kvm -a ! -L /dev/kvm ] && [ .$(stat -c %u%g /dev/kvm) = .00 ]
+then
+ chgrp kvm /dev/kvm
+ chmod 0660 /dev/kvm
+ if type setfacl > /dev/null 2>&1; then
+ setfacl -m g::rw /dev/kvm
+ fi
+fi

+exit 0

Please don't do this by hand. The correct way to do this in a maintainer script should be by calling:

    udevadm trigger --subsystem-match=misc --action=change

See xserver-xorg-input-vmmouse, udisks2 for examples of this.

Rejecting this SRU for now. If there's some reason 'udevadm trigger' can't be used here, we can un-reject the previous upload; otherwise, please reupload using udevadm.

Hello Parameswaran, or anyone else affected,

Accepted qemu-kvm into precise-proposed. The package will build now and be available at http://launchpad.net/ubuntu/+source/qemu-kvm/1.0+noroms-0ubuntu14.4 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please change the bug tag from verification-needed to verification-done. If it does not, change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Tested for verification on a 20121016 (12.04.1) install fully updated amd64 system.

The original bug could not be reproduced in this. With the version 1.0+noroms-0ubuntu14.3 the following is the output of getfacl /dev/kvm

getfacl: Removing leading '/' from absolute path names
# file: dev/kvm
# owner: root
# group: kvm
user::rw-
user:ubuntu:rw-
group::rw-
mask::rw-
other::---

In anycase, the new proposed version (1.0+noroms-0ubuntu14.4) is also giving the exact same output above for getfacl /dev/kvm. Hence marking the fix as verification done

Failure to start kvm can also be caused by VirtualBox running on the host - watch out for dmesg like:

kvm: enabling virtualization on CPU3 failed
kvm: enabling virtualization on CPU0 failed
kvm: enabling virtualization on CPU2 failed
kvm: enabling virtualization on CPU1 failed

to fix it:
# /etc/init.d/virtualbox stop
# rmmod rmmod vboxnetflt

and the KVM VMs should start from virt-manager like a charm

n.b.
# grep libvirt /etc/group
kvm:x:127:libvirt-qemu
libvirtd:x:130:<yourusername>

I just upgraded a server from 11.10 to 12.04 and I got a gnome-keyring error [1] when trying to start a guest. There is some other bug about it and strangely a workaround was to install the 'gnome-keyring' package. I did so in haste and the majority of the error remains, even after upgrading qemu-kvm to proposed version:

$ sudo virsh start kvm-blah

error: Failed to start domain kvm-blah
error: internal error Process exited while reading console log output: char device redirected to /dev/pts/1
Could not access KVM kernel module: No such file or directory
failed to initialize KVM: No such file or directory
No accelerator found!

$ apt-cache policy qemu-kvm

qemu-kvm:
  Installed: 1.0+noroms-0ubuntu14.4
  Candidate: 1.0+noroms-0ubuntu14.4
  Version table:
 *** 1.0+noroms-0ubuntu14.4 0
        500 http://archive.ubuntu.com/ubuntu/ precise-proposed/main amd64 Packages
        100 /var/lib/dpkg/status
     1.0+noroms-0ubuntu14.3 0
        500 http://archive.ubuntu.com/ubuntu/ precise-updates/main amd64 Packages
     1.0+noroms-0ubuntu14.2 0
        500 http://security.ubuntu.com/ubuntu/ precise-security/main amd64 Packages
     1.0+noroms-0ubuntu13 0
        500 http://archive.ubuntu.com/ubuntu/ precise/main amd64 Packages

==============================

[1]

p11-kit: couldn't load module: /usr/lib/x86_64-linux-gnu/pkcs11/gnome-keyring-pkcs11.so: /usr/lib/x86_64-linux-gnu/pkcs11/gnome-keyring-pkcs11.so: cannot open shared object file: No such file or directory
error: Failed to start domain kvm-misc3
error: internal error Process exited while reading console log output: char device redirected to /dev/pts/1
Could not access KVM kernel module: No such file or directory
failed to initialize KVM: No such file or directory
No accelerator found!

After loading the module I was able to start my guest:

$ sudo modprobe kvm_intel

The main question is why this did not occur automatically after rebooting (after I upgraded to the -proposed version of qemu-kvm)?

Note that everything worked very well on 11.10.

@Peter,

could you please open a new bug for your issue?

Hello Parameswaran, or anyone else affected,

Accepted qemu-kvm into precise-proposed. The package will build now and be available at http://launchpad.net/ubuntu/+source/qemu-kvm/1.0+noroms-0ubuntu14.5 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please change the bug tag from verification-needed to verification-done. If it does not, change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Hello Parameswaran, or anyone else affected,

Accepted qemu-kvm into quantal-proposed. The package will build now and be available at http://launchpad.net/ubuntu/+source/qemu-kvm/1.2.0+noroms-0ubuntu2.12.10.1 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please change the bug tag from verification-needed to verification-done. If it does not, change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

(Re-verified in precise)

Hello Parameswaran, or anyone else affected,

Accepted qemu-kvm into precise-proposed. The package will build now and be available at http://launchpad.net/ubuntu/+source/qemu-kvm/1.0+noroms-0ubuntu14.6 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Re-verified.

The fix in quantal-proposed is currently complicated by a udev bug #1092715. The udev trigger from the postinst doesn't seem to pick up the new rules file in /lib/udev/rules.d, and permissions are not updated by the trigger.

The verification of this Stable Release Update has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regresssions.

This bug was fixed in the package qemu-kvm - 1.2.0+noroms-0ubuntu2.12.10.1

---------------
qemu-kvm (1.2.0+noroms-0ubuntu2.12.10.1) quantal-proposed; urgency=low

  [ Serge Hallyn ]
  * debian/qemu-kvm.postinst: use udevadm trigger to change /dev/kvm perms as
    recommended by Steve Langasek (LP: #1057024)
  * apply debian/patches/nbd-fixes-to-read-only-handling.patch from upstream to
    make read-write mount after read-only mount work. (LP: #1077838)
  * make qemu-kvm depend on udev (LP: #1080912)

  [ Robert Collins ]
  * Fix upstart job to succeed if ksm settings can't be altered in the same way
    other settings are handled. (LP: #1078530)
 -- Serge Hallyn <email address hidden> Mon, 19 Nov 2012 09:15:42 -0600

This bug was fixed in the package qemu-kvm - 1.0+noroms-0ubuntu14.6

---------------
qemu-kvm (1.0+noroms-0ubuntu14.6) precise-proposed; urgency=low

  * Fix qemu-kvm.upstart: just don't run in a container. Otherwise we'll
    still try to load/unload kernel modules. Also undo the || true after
    sysfs writes. Since setting those is a part of configuring qemu-kvm
    on the host, failing when they fail makes sense.

qemu-kvm (1.0+noroms-0ubuntu14.5) precise-proposed; urgency=low

  * add udev to qemu-kvm Depends to ensure that postinst succeeds.
    (LP: #1080912)

qemu-kvm (1.0+noroms-0ubuntu14.4) precise-proposed; urgency=low

  [ Serge Hallyn ]
  * debian/qemu-kvm.postinst: use udevadm trigger to change /dev/kvm perms as
    recommended by Steve Langasek (LP: #1057024)
  * apply debian/patches/nbd-fixes-to-read-only-handling.patch from upstream to
    make read-write mount after read-only mount work. (LP: #1077838)

  [ Robert Collins ]
  * Fix upstart job to succeed if ksm settings can't be altered in the same way
    other settings are handled. (LP: #1078530)
 -- Serge Hallyn <email address hidden> Thu, 20 Dec 2012 12:34:52 -0600

I'm seeing this bug just after installing the following on a new 12.04 (64bit) install... I have not rebooted my system...

: linux13 24#; dpkg-query -W qemu-kvm
qemu-kvm 1.0+noroms-0ubuntu14.8

: linux13 25#; getfacl /dev/kvm
getfacl: Removing leading '/' from absolute path names
# file: dev/kvm
# owner: root
# group: kvm
user::rw-
user:daly:rw-
group::---
mask::rw-
other::---

After a reboot, I see the following:

: linux13 1#; getfacl /dev/kvm
getfacl: Removing leading '/' from absolute path names
# file: dev/kvm
# owner: root
# group: kvm
user::rw-
user:daly:rw-
group::rw-
mask::rw-
other::---

If I understood the thread correctly, these permissions should have been set without requiring a reboot. If that's true, then something still isn't right with the installer.

Thanks, Ryan.

Indeed - there were several problems affecting /dev/kvm after a fresh install, and while raring got all the fixes, precise and quantal did not get one (presumably because I did not think they were affected).

We will need to do the following in both precise and quantal:

1. add acl to qemu-kvm's Depends:
2. add

if [ -c /dev/kvm -a ! -L /dev/kvm ]
then
  /usr/bin/setfacl -m g::rw /dev/kvm
fi

to debian/qemu-kvm.postinst above the udevadm trigger

This will need to be done after the current qemu-kvm is promoted from -proposed. I'll make a note to check back in a week.

Thanks for pointing this out!

Sure thing. Thanks for your support.

Pushed proposed packages for precise and quantal.

Hello Parameswaran, or anyone else affected,

Accepted qemu-kvm into quantal-proposed. The package will build now and be available at http://launchpad.net/ubuntu/+source/qemu-kvm/1.2.0+noroms-0ubuntu2.12.10.5 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Hello Parameswaran, or anyone else affected,

Accepted qemu-kvm into precise-proposed. The package will build now and be available at http://launchpad.net/ubuntu/+source/qemu-kvm/1.0+noroms-0ubuntu14.11 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

Quantal verification passed with the 1.2.0+noroms-0ubuntu2.12.10.5 .

Precise verification also passed with the version 1.0+noroms-0ubuntu14.11 .

This bug was fixed in the package qemu-kvm - 1.0+noroms-0ubuntu14.11

---------------
qemu-kvm (1.0+noroms-0ubuntu14.11) precise-proposed; urgency=low

  * debian/control and qemu-kvm.postinst: remove any g:--- acl on /dev/kvm
    (left over from udev-acl). (LP: #1057024)
 -- Serge Hallyn <email address hidden> Wed, 17 Jul 2013 10:14:46 -0500

This bug was fixed in the package qemu-kvm - 1.2.0+noroms-0ubuntu2.12.10.5

---------------
qemu-kvm (1.2.0+noroms-0ubuntu2.12.10.5) quantal-proposed; urgency=low

  * debian/control and qemu-kvm.postinst: remove any g:--- acl on /dev/kvm
    (left over from udev-acl). (LP: #1057024)
 -- Serge Hallyn <email address hidden> Wed, 17 Jul 2013 10:23:13 -0500

It looks like the bug still exists in 'trusty', qemu-kvm 2.0, however, it's not clear why.

Aftre installation /dev/kvm have wrong permissions:
---
crw------- 1 root root 10, 232 Jan 20 02:09 /dev/kvm
---

Reinstalling qemu-system-common fixes the problem.

I did a simple research, and here is what I've found:

* The code to fix acl still exists, but was moved to qemu-system-common package.
* There is no /lib/udev/rules.d/70-udev-acl.rules, it looks like ACLs for /dev/kvm are set by /lib/udev/rules.d/70-uaccess.rules, there is a string:
---
SUBSYSTEM=="misc", KERNEL=="kvm", TAG+="uaccess"
---
* A builtin function 'builtin_uaccess' [1] is called to set permissions according to the following string from /lib/udev/rules.d/73-seat-late.rules:
---
TAG=="uaccess", ENV{MAJOR}!="", RUN{builtin}+="uaccess"
---

[1] https://github.com/systemd/systemd/blob/master/src/udev/udev-builtin-uaccess.c

Hi Dmitry,

it sounds like you're saying there is a new bug (regression). Could
you open a new bug with the relevant information? Thanks!