On 1/12/19 11:58 AM, Eric Blake wrote: > Any good new feature deserves some regression testing :) > Coverage includes: > - 223: what happens when there are 0 or more than 1 export, > proof that we can see multiple contexts including qemu:dirty-bitmap > - 233: proof that we can list over TLS, and that mix-and-match of > plain/TLS listings will behave sanely > > Signed-off-by: Eric Blake > Reviewed-by: Richard W.M. Jones > Tested-by: Richard W.M. Jones > Reviewed-by: Vladimir Sementsov-Ogievskiy > > --- > v3: Rebase to earlier changes > --- > tests/qemu-iotests/223 | 2 ++ > tests/qemu-iotests/223.out | 20 ++++++++++++++++++++ > tests/qemu-iotests/233 | 19 +++++++++++++------ > tests/qemu-iotests/233.out | 15 +++++++++++++++ > 4 files changed, 50 insertions(+), 6 deletions(-) Test 233 has a pre-existing race, but this patch made it more likely to hit. I got: +++ /home/eblake/qemu/tests/qemu-iotests/233.out.bad 2019-01-16 22:16:17.482019114 -0600 @@ -42,8 +42,8 @@ == check TLS with different CA fails == qemu-nbd: option negotiation failed: Verify failed: No certificate was found. qemu-img: Could not open 'driver=nbd,host=127.0.0.1,port=PORT,tls-creds=tls0': The certificate hasn't got a known issuer -qemu-nbd: option negotiation failed: Verify failed: No certificate was found. qemu-nbd: The certificate hasn't got a known issuer +qemu-nbd: option negotiation failed: Verify failed: No certificate was found. The problem? We have output from two separate qemu-nbd processes (the server, and the --list client), which are getting interleaved in an arbitrary fashion according to who wins the scheduler race. I'm working on a fix; probably by capturing the server's output to a file and then cat'ing that file at the end. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qemu.org | libvirt.org