It seems like there's a bug/defect in libvirt. The first attached test case (libvirt) is done after a fresh reboot with 65-kvm.rules from qemu removed. As you can see, having libvirt running qemu with a group owns and has rw permission on /dev/kvm does not work. (But it will work if /dev/kvm is test:root 0660 or test:test 0660 instead).

We can easily skipped this issue without knowing what had happened because SOMEHOW, although a re-trigger of udev (which seem to have changed the ownership successfully) does not work, it will work if the modules are loaded with udev already carrying the "group rule". For example, a reboot, or `modprobe -r kvm_intel; modprobe kvm_intel`, after installing qemu. (And you can even switch the group back and forth without having the same issue until the modules are loaded again with udev NOT carrying the "group rule")

Running standalone qemu with a user of a group/supp. group which has rw permission on /dev/kvm does not seem to show the same issue. See the second attached test case (qemu).

Actually I think libvirt upstream should really improve this, like setfacl on /dev/kvm for the specified user/group in qemu.conf.

Anyway the I think "kvm group only" way in Arch's qemu/libvirt looks a bit silly as well. Can't we just let /dev/kvm be owned by kvm:kvm? What's the point of leaving /dev/kvm owned by root anyway? (Like, even under cases when something weird would run qemu with root, I don't think /dev/kvm has to be owned by root anyway?)