From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Kevin Wolf <kwolf@redhat.com>
Cc: "Thomas Huth" <thuth@redhat.com>,
"Cleber Rosa" <crosa@redhat.com>,
qemu-devel@nongnu.org, "Fam Zheng" <fam@euphon.net>,
"Philippe Mathieu-Daudé" <philmd@redhat.com>,
"Alex Bennée" <alex.bennee@linaro.org>,
Qemu-block <qemu-block@nongnu.org>,
"Marc-André Lureau" <marcandre.lureau@redhat.com>
Subject: Re: [Qemu-devel] Failing iotests in CI (was: Add a gitlab-ci file for Continuous Integration testing on Gitlab)
Date: Tue, 19 Feb 2019 12:04:13 +0000 [thread overview]
Message-ID: <20190219120413.GA9981@redhat.com> (raw)
In-Reply-To: <20190219120128.GF7154@redhat.com>
On Tue, Feb 19, 2019 at 12:01:28PM +0000, Daniel P. Berrangé wrote:
> On Tue, Feb 19, 2019 at 12:31:41PM +0100, Kevin Wolf wrote:
> > Am 19.02.2019 um 12:06 hat Daniel P. Berrangé geschrieben:
> > > On Tue, Feb 19, 2019 at 10:37:16AM +0100, Kevin Wolf wrote:
> > > > Am 19.02.2019 um 10:04 hat Thomas Huth geschrieben:
> > > > >
> > > > > https://gitlab.com/huth/qemu/-/jobs/163680780
> > > > >
> > > > > Some of them apparently need encryption to be enabled (as already
> > > > > mentioned by Cleber in his patch) - thus should they really be in the
> > > > > quick check, too? Or could they at least check whether QEMU has been
> > > > > built with encryption?
> > > >
> > > > The correct solution would be that they detect the situation
> > > > automatically and skip the test by calling _notrun.
> > > >
> > > > I'm not sure how to detect if a given QEMU binary supports encryption,
> > > > but Dan might know.
> > >
> > > It isn't easy & depends which encryption feature you're trying to use.
> > >
> > > For TLS related features you can do something gross like
> > >
> > > qemu-img info --object tls-creds-anon,id=dummy README 2>&1
> > > test $? != 0 && exit 0
> > >
> > > This relies on fact that 'tls-creds-anon' object type will report a
> > > runtime error during initialization if gnutls isn't enabled.
> > >
> > > For more general ciphers you pretty much have to just try the higher level
> > > feature and see if it fails.
> >
> > Actually, I think for test cases we should see 'qemu-img create' failing
> > and could just skip the test if it returns a non-zero exit code.
> >
> > But then I looked at Thomas' output again:
> >
> > --- /builds/huth/qemu/tests/qemu-iotests/188.out 2019-02-19 08:23:54.000000000 +0000
> > +++ /builds/huth/qemu/tests/qemu-iotests/188.out.bad 2019-02-19 08:34:54.000000000 +0000
> > @@ -1,4 +1,5 @@
> > QA output created by 188
> > +qemu-img: TEST_DIR/t.IMGFMT: No crypto library supporting PBKDF in this build: Function not implemented
> > Formatting 'TEST_DIR/t.IMGFMT', fmt=IMGFMT size=16777216 encrypt.format=luks encrypt.key-secret=sec0 encrypt.iter-time=10
> >
> > == reading whole image ==--- /builds/huth/qemu/tests/qemu-iotests/188.out 2019-02-19 08:23:54.000000000 +0000
> >
> > What is it actually doing there? There's clearly an error message, but
> > it almost looks like it's creating some kind of image anyway? The
> > following I/O works fine (i.e. this created image can even be opened
> > again with the luks driver), except that you can also access the image
> > with the wrong password.
> >
> > Is this a real bug in either qcow2 or luks?
>
> It is an artifact of the way qcow2 image creation happens in multiple
> phases. qcow2_co_create first creates a minimal qcow2 file, and then
> opens it and updates it to add in the various extra features, including
> luks encryption. We fail to create the luks encryption, but enough of
> the qcow2 file has been created that it is able to still do plain text
> I/O.
>
> Essentially the problem is that qcow2_co_create() doesn't unlink() the
> partially created image when things fail. This is a generic problem
> which can affect any part of qcow2_co_create that might fail, but it
> is especially problematic with luks.
>
> The complication in fixing this is that can't just do an unlink() as
> we can't assume a local file. We need to have a bdrv_unlink() driver
> callback we can use to delegate to the right block driver APIs for
> deletion.
As a quick hack we could perhaps overwrite the qcow2 header with
garbage or all-zeros on failure to avoid it being mistakenly
interpreted as a valid qcow2 file on failure (could still be
mistakenly probed as raw but we tell people not to allow probing)
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 :|
next prev parent reply other threads:[~2019-02-19 12:04 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-13 11:54 [Qemu-devel] [PATCH v2] Add a gitlab-ci file for Continuous Integration testing on Gitlab Thomas Huth
2019-02-13 12:06 ` Marc-André Lureau
2019-02-13 12:20 ` Thomas Huth
2019-02-13 14:03 ` Alex Bennée
2019-02-13 14:06 ` Marc-André Lureau
2019-02-18 18:22 ` Cleber Rosa
2019-02-19 6:44 ` Thomas Huth
2019-02-19 7:53 ` [Qemu-devel] [Qemu-block] " Kevin Wolf
2019-02-19 9:04 ` [Qemu-devel] Failing iotests in CI (was: Add a gitlab-ci file for Continuous Integration testing on Gitlab) Thomas Huth
2019-02-19 9:37 ` Kevin Wolf
2019-02-19 10:11 ` Thomas Huth
2019-02-19 11:38 ` Kevin Wolf
2019-02-19 12:09 ` Thomas Huth
2019-02-19 11:06 ` Daniel P. Berrangé
2019-02-19 11:31 ` Kevin Wolf
2019-02-19 12:01 ` Daniel P. Berrangé
2019-02-19 12:04 ` Daniel P. Berrangé [this message]
2019-02-19 12:16 ` Kevin Wolf
2019-02-19 12:51 ` Daniel P. Berrangé
2019-02-20 11:27 ` [Qemu-devel] [PATCH v2] Add a gitlab-ci file for Continuous Integration testing on Gitlab Paolo Bonzini
2019-02-20 11:35 ` Alex Bennée
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190219120413.GA9981@redhat.com \
--to=berrange@redhat.com \
--cc=alex.bennee@linaro.org \
--cc=crosa@redhat.com \
--cc=fam@euphon.net \
--cc=kwolf@redhat.com \
--cc=marcandre.lureau@redhat.com \
--cc=philmd@redhat.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=thuth@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).