Re: [Qemu-block] Failing iotests in CI (was: Add a gitlab-ci file for Continuous Integration testing on Gitlab)

[Thomas Huth]

On 19/02/2019 12.38, Kevin Wolf wrote:
> Am 19.02.2019 um 11:11 hat Thomas Huth geschrieben:
>> On 19/02/2019 10.37, Kevin Wolf wrote:
>>> Am 19.02.2019 um 10:04 hat Thomas Huth geschrieben:
>>>> On 19/02/2019 08.53, Kevin Wolf wrote:
[...]
>> 169 got killed via abort():
>>
>> 169                [08:34:39] [08:34:46] [failed, exit status 1] - output 
>> mismatch (see 169.out.bad)
>> --- /builds/huth/qemu/tests/qemu-iotests/169.out     2019-02-19 
>> 08:23:54.000000000 +0000
>> +++ /builds/huth/qemu/tests/qemu-iotests/169.out.bad 2019-02-19 
>> 08:34:46.000000000 +0000
>> @@ -1,5 +1,29 @@
>> -....................
>> +WARNING:qemu:qemu received signal 6: 
>> /builds/huth/qemu/tests/qemu-iotests/../../x86_64-softmmu/qemu-system-x86_64 
>> -chardev 
>> socket,id=mon,path=/tmp/qemu-iotests-quick-25045/tmpGQOExQ/qemua-13044-monitor.sock
>>  -mon chardev=mon,mode=control -display none -vga none -qtest 
>> unix:path=/tmp/qemu-iotests-quick-25045/qemua-13044-qtest.sock -machine 
>> accel=qtest -nodefaults -machine accel=qtest -drive 
>> if=virtio,id=drive0,file=/tmp/qemu-iotests-quick-25045/disk_a,format=qcow2,cache=writeback
>> [...]
>>
>> No clue why.
> 
> In order to debug failures like this, I usually enable core dumps.

It's only failing for me on the gitlab-CI system. I don't think that
I've got the possibility to grab coredumps there...

>> 232 is also strange, no idea what is going on here:
>>
>> 232                [08:38:53] [08:38:56] - output mismatch (see 232.out.bad)
>> --- /builds/huth/qemu/tests/qemu-iotests/232.out     2019-02-19 
>> 08:23:54.000000000 +0000
>> +++ /builds/huth/qemu/tests/qemu-iotests/232.out.bad 2019-02-19 
>> 08:38:56.000000000 +0000
>> @@ -21,13 +21,13 @@
>>  NODE_NAME: TEST_DIR/t.IMGFMT (file, read-only)
>>  NODE_NAME: TEST_DIR/t.IMGFMT (file, read-only)
>>  
>> -QEMU_PROG: -drive 
>> driver=file,file=TEST_DIR/t.IMGFMT,if=none,read-only=off,auto-read-only=off: 
>> Could not open 'TEST_DIR/t.IMGFMT': Permission denied
>> -NODE_NAME: TEST_DIR/t.IMGFMT (file, read-only)
>> -NODE_NAME: TEST_DIR/t.IMGFMT (file, read-only)
>> -
>> -QEMU_PROG: -drive 
>> driver=file,file=TEST_DIR/t.IMGFMT,if=none,auto-read-only=off: Could not 
>> open 'TEST_DIR/t.IMGFMT': Permission denied
>> -NODE_NAME: TEST_DIR/t.IMGFMT (file, read-only)
>> -NODE_NAME: TEST_DIR/t.IMGFMT (file, read-only)
>> +NODE_NAME: TEST_DIR/t.IMGFMT (file)
>> +NODE_NAME: TEST_DIR/t.IMGFMT (file)
>> +NODE_NAME: TEST_DIR/t.IMGFMT (file)
>> +
>> +NODE_NAME: TEST_DIR/t.IMGFMT (file)
>> +NODE_NAME: TEST_DIR/t.IMGFMT (file)
>> +NODE_NAME: TEST_DIR/t.IMGFMT (file)
> 
> Do you run the tests as root? This messes with any tests that try to
> test read-only cases because root can write to everything, no matter
> what the permissions say.

I don't know whether gitlab runs the CI pipelines as root, but I doubt
it. Looking at the shell "prompts" that they show inbetween ("$") it
looks like they are running the CI tests as a normal user, though.

>>>> By the way, 235 and 238 also fail on my normal laptop with RHEL7:
>>>> [...]
>>>> Any ideas what might be going on here?
>>>
>>> I think it's most likely that QEMU just prints an error message on
>>> startup and exits.
>> Right, I finally found the issue:
>>
>> qemu-system-x86_64: -machine accel=kvm: No accelerator found
>>
>> I apparently compiled my QEMU with --disable-kvm at one point in time and
>> forgot to enable it later again. ==> These tests should really check whether
>> KVM is available in QEMU before they blindly use this feature.
> 
> Ideally, they shouldn't use it at all.

235 seems to use KVM on purpose according to the commit description...?

But maybe we can change it to "-M accel=kvm:qtest" somehow ... though
this currently seems to hang the test, as far as I can see... Maybe
"accel=kvm:tcg", so that it works at least without kvm?

According to Stefan, 238 does not need KVM at all (see his patch that he
just sent).

 Thomas