action #68473

The test job is stuck on BIOS.

Added by Dnizov 7 months ago. Updated 6 months ago.

Target version:
Start date:
Due date:
% Done:


Estimated time:


I'm trying to run the openQA under RHEL 7* using the docker container with Fedora (so I have the RHEL host and Fedora docker's image with openQA installed). When I'm posting the job using the /usr/share/openqa/script/client jobs post DISTRI=ubuntu Version=18.04 ARCH=x86_64 TEST=TC MACHINE=super64bit ISO=ubuntu_tos.iso command the job is stuck on BIOS (see 1'st screenshot and log files). But when I'm posting the job with QEMU_NO_KVM=1 parameter the test starts working, but very slowly.
I checked whether my system supports KVM using the next few commands with results:

[root@openqa /]# egrep -c '(vmx|svm)' /proc/cpuinfo
[root@openqa /]# egrep -c ' lm ' /proc/cpuinfo
[root@openqa /]# uname -m
[root@openqa /]# ls -l /dev/kvm
crw-rw-rw- 1 root kvm 10, 232 Jun 26 09:24 /dev/kvm
[root@openqa /]# lscpu | grep Virtualization
Virtualization:                  VT-x
Virtualization type:             full
[root@h0006104 niz118]# lsmod | grep -i kvm
kvm_intel             188688  0
kvm                   636965  1 kvm_intel
irqbypass              13503  1 kvm

So it looks like the KVM acceleration can be used.
My docker container is running in privileged mode inside the host network. But the most strange is that the same docker image with the same job's parameters is correctly (without QEMU_NO_KVM) running under my local Fedora host (instead of RHEL). Host with Fedora has the same KVM setup.

I know that it is better to use openQA without docker but it is difficult to install it on RHEL due to versions incompatibilities.

1st_screenshot_SeaBIOS_Stuck.png (18.1 KB) 1st_screenshot_SeaBIOS_Stuck.png Dnizov, 2020-06-26 09:58
vars (1).json (1.22 KB) vars (1).json Dnizov, 2020-06-26 10:07
autoinst-log (1).txt (23.9 KB) autoinst-log (1).txt Dnizov, 2020-06-26 10:07
worker-log (1).txt (1.28 KB) worker-log (1).txt Dnizov, 2020-06-26 10:07


#1 Updated by mkittler 7 months ago

  • Category changed from Concrete Bugs to Support

This is likely not a bug on our side but really comes down to starting QEMU with KVM in your environment. autoinst-log (1).txt contains the QEMU command to the VM. You can try invoking QEMU manually with a similar/simplified version of that command to investigate the problem further. Maybe you can also add flags for a more verbose output.

Of course if it turns out that the QEMU command used by os-autoinst needs to be adjusted for some reason in certain environments we can add an option to do that (if it is not already possible).

#2 Updated by okurz 6 months ago

  • Due date set to 2020-07-28
  • Status changed from New to Feedback
  • Assignee set to okurz
  • Target version set to Ready

waiting for response

#3 Updated by okurz 6 months ago

  • Status changed from Feedback to Resolved

no response, assuming fixed. You are welcome to respond back with updated experiences.

Also available in: Atom PDF