I checked the machine "power8" and it seems the device /dev/kvm has lost the permission to allow access for the group "kvm" in which the user "_openqa-worker" runs. I don't know what changed that. So now I changed that manually by giving the group "kvm" r/w-access to /dev/kvm but I assume some udev rule should ensure this? As a workaround that should work for now.

retriggered all recent openSUSE Tumbleweed power jobs

okurz thank you for the bypass, I assume somebody restarted the machine last friday without checking for related /dev/kvm

With the new 20171211 trial of PowerPC (restarted after 1 month) it seems we have again the same missing setup of /dev/kvm as previously reported.

I assume the Power8 workers were restarted and we still do have /dev/kvm accessed only by root (default)

The last autoinst-log.txt for 20171211 snapshot is: from https://openqa.opensuse.org/tests/557984/file/autoinst-log.txt

michel_mno wrote:

With the new 20171211 trial of PowerPC (restarted after 1 month) it seems we have again the same missing setup of /dev/kvm as previously reported.

I assume the Power8 workers were restarted and we still do have /dev/kvm accessed only by root (default)

Last reboot was 55 days ago
as for udev, there is ./rules.d/80-kvm.rules:KERNEL=="kvm", MODE="0666", GROUP="kvm" which should very well cover the case here (and which matches what my local machine, x86_64, has as permission on /dev/kvm

In any case I reset the permissions manually for today, but this does need more investigation

new occurence, tracked by https://progress.opensuse.org/issues/36559

anything left here or can we close it?

tampakrap wrote:

anything left here or can we close it?

Would be good to finally understand how this keeps on falling over. The issue does show up every now and then

This is a recurrent problem:

#25170
#36559
#40031
#40919

I think what happens is that any time a package upgrade also touches e.g. the qemu package – as happened yesterday – the permissions of /dev/kvm reset to 600

new occurence for TW snapshot 20181118 as per
https://openqa.opensuse.org/tests/800586/file/autoinst-log.txt
So need same bypass as before for /dev/kvm access.

[2018-11-19T16:38:55.158 UTC] [debug] Backend process died, backend errors are reported below in the following lines can't open qmp at /usr/lib/os-autoinst/OpenQA/Qemu/Proc.pm line 402.
[2018-11-19T16:38:55.159 UTC] [info] ::: OpenQA::Qemu::Proc::save_state: Saving QEMU state to qemu_state.json
last frame
[2018-11-19T16:38:55.160 UTC] [info] ::: OpenQA::Qemu::Proc::save_state: Saving QEMU state to qemu_state.json
[2018-11-19T16:38:55.161 UTC] [debug] QEMU: QEMU emulator version 2.9.1(openSUSE Leap 42.3)
[2018-11-19T16:38:55.161 UTC] [debug] QEMU: Copyright (c) 2003-2017 Fabrice Bellard and the QEMU Project developers
[2018-11-19T16:38:55.161 UTC] [debug] QEMU: Could not access KVM kernel module: Permission denied
[2018-11-19T16:38:55.161 UTC] [debug] QEMU: failed to initialize KVM: Permission denied

manual action by DimStar => workers OK

#44432 might help us to understand what we would need to do for o3

@okurz, I guess we could script the setup for these machines up there. But I wonder why and how the udev rule failed to be loaded...

again same issue on 20190130:
https://openqa.opensuse.org/tests/842728/file/autoinst-log.txt

[2019-01-30T12:47:19.837 UTC] [debug] QEMU: Could not access KVM kernel module: Permission denied
[2019-01-30T12:47:19.837 UTC] [debug] QEMU: failed to initialize KVM: Permission denied

Fixed manually with chmod g+rwX /dev/kvm on the machine. The machine did not reboot. This seems to be caused by a kernel upgrade triggered at 2019-01-30 12:01:22 (from /var/log/zypp/history). But who triggered the kernel upgrade?