action #68473
closedThe test job is stuck on BIOS.
Description
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
8
[root@openqa /]# egrep -c ' lm ' /proc/cpuinfo
8
[root@openqa /]# uname -m
x86_64
[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.
Files
Updated by mkittler over 4 years ago
- Category changed from Regressions/Crashes 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).
Updated by okurz about 4 years 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
Updated by okurz about 4 years ago
- Status changed from Feedback to Resolved
no response, assuming fixed. You are welcome to respond back with updated experiences.