Re: [PATCH] tests/qemu-iotests: Check for a functional "secret" object before using it

["Daniel P. Berrangé" <berrange@redhat.com>]

On Mon, Dec 08, 2025 at 09:15:38AM +0100, Thomas Huth wrote:
> On 05/12/2025 18.20, Kevin Wolf wrote:
> > Am 05.12.2025 um 14:00 hat Thomas Huth geschrieben:
> > > From: Thomas Huth <thuth@redhat.com>
> > > 
> > > QEMU iotests 049, 134 and 158 are currently failing if you compiled
> > > QEMU without the crypto libraries. Thus make sure that the "secret"
> > > object is really usable and skip the tests otherwise.
> > > 
> > > Reported-by: Alex Bennée <alex.bennee@linaro.org>
> > > Signed-off-by: Thomas Huth <thuth@redhat.com>
> > 
> > > diff --git a/tests/qemu-iotests/common.rc b/tests/qemu-iotests/common.rc
> > > index e977cb4eb61..10d83d8361b 100644
> > > --- a/tests/qemu-iotests/common.rc
> > > +++ b/tests/qemu-iotests/common.rc
> > > @@ -1053,6 +1053,20 @@ _require_one_device_of()
> > >       _notrun "$* not available"
> > >   }
> > > +_require_secret()
> > > +{
> > > +    if [ -e "$TEST_IMG" ]; then
> > > +        echo "unwilling to overwrite existing file"
> > > +        exit 1
> > > +    fi
> > > +    if $QEMU_IMG create -f $IMGFMT --object secret,id=sec0,data=123 \
> > > +                 -o encryption=on,encrypt.key-secret=sec0 "$TEST_IMG" 1M 2>&1 \
> > > +                 | grep "Unsupported cipher" ; then
> > > +        _notrun "missing cipher support"
> > > +    fi
> > 
> > What is the thing that you're checking here? If it's really the secret,
> > then just running 'qemu-io --object secret,data=123,id=sec0 -c ""' would
> > be enough. If it's not the secret, but encryption support, then the
> > function is a misnomer.
> 
> The "qemu-io" statement seems to work fine in that case, so you're right,
> it's apparently not the "secret" object, but rather the "encryption" part
> that is failing.
> 
> So shall I rename it to "_require_encryption" ?
>
> > _require_working_luks() looks pretty similar, though it requires
> > specifically a working luks driver. Could something be unified? (The
> > answer might be no, but it would be good to explicitly say it.)
> 
> While it looks a little bit similar, at least for me it still looks too
> distinct for unification - or is "-o key-secret=sec0" doing exactly the same
> as "-o encryption=on,encrypt.key-secret=sec0" ? ... I lack the deeper
> understanding of the parameters here to judge on that topic.

Specifically these three tests are all relying on QCow2 traditional
built-in AES encryption which pre-dated LUKS. Just name it for what
it tests:

  _require_qcow2_aes

With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|