From: Eric Blake <eblake@redhat.com>
To: Kevin Wolf <kwolf@redhat.com>
Cc: qemu-block@nongnu.org, famz@redhat.com, quintela@redhat.com,
qemu-devel@nongnu.org, dgilbert@redhat.com, mreitz@redhat.com,
stefanha@redhat.com
Subject: Re: [Qemu-devel] [PATCH 4/4] qemu-iotests: Block migration test
Date: Tue, 23 May 2017 11:29:13 -0500 [thread overview]
Message-ID: <6e53753c-f9c0-6d8c-24c9-7954da0dde68@redhat.com> (raw)
In-Reply-To: <20170523161822.GB6791@noname.redhat.com>
[-- Attachment #1: Type: text/plain, Size: 2453 bytes --]
On 05/23/2017 11:18 AM, Kevin Wolf wrote:
> Am 23.05.2017 um 17:46 hat Eric Blake geschrieben:
>> On 05/23/2017 09:01 AM, Kevin Wolf wrote:
>>> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
>>> ---
>>> tests/qemu-iotests/183 | 121 +++++++++++++++++++++++++++++++++++++++++++++
>>> tests/qemu-iotests/183.out | 48 ++++++++++++++++++
>>> tests/qemu-iotests/group | 1 +
>>> 3 files changed, 170 insertions(+)
>>> create mode 100755 tests/qemu-iotests/183
>>> create mode 100644 tests/qemu-iotests/183.out
>>
>> Does this test gracefully skip when coupled with the efforts for a
>> configure option to disable block migration?
>> https://lists.gnu.org/archive/html/qemu-devel/2017-05/msg04398.html
>
> Obviously it doesn't. How would we even check? Just grep whether the
> magic error string turns up somewhere after doing 'migrate -b'?
I think the easiest way (once Juan's series lands) would be to try this
QMP on a standalone qemu execution prior to firing up the rest of the test:
{ "execute":"migrate-set-capabilities", "arguments":{
"capabilities": [ { "capability":"block", "state":true } ] } }
If that command fails, block migration is not compiled in (or we're
talking to an older qemu that lacks the capability altogether, but we
don't have to worry about that in our iotests). Of course, if we do
that, then we could use QMP 'migrate' with the capabilities rather than
HMP -b to drive the same aspect of the test.
>
> I don't think we have other test cases that don't skip immediately, but
> only after doing half of the test, but I think it might work anyway.
That's an option too - grepping for the magic failure string and
gracefully exiting if we were unable to start migration. I think we
have done something like that recently to grep whether we have
op-blocking support via fcntl OFD semantics, and exit early if it is an
older kernel that has less-sane locks based on the error message.
>> Should we also check the use of -i?
>
> Good point, though I don't even know how to use -i manually. :-)
>
> We can either have a follow-up patch extending this one or a completely
> separate test case for it. I would have to try out -i before I could say
> which makes more sense.
An incremental patch to expand this test is fine.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: qemu.org | libvirt.org
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 604 bytes --]
next prev parent reply other threads:[~2017-05-23 16:29 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-23 14:01 [Qemu-devel] [PATCH 0/4] Block migration (migrate -b) fixes Kevin Wolf
2017-05-23 14:01 ` [Qemu-devel] [PATCH 1/4] block: Fix anonymous BBs in blk_root_inactivate() Kevin Wolf
2017-05-23 15:30 ` Eric Blake
2017-05-23 16:36 ` Juan Quintela
2017-05-23 14:01 ` [Qemu-devel] [PATCH 2/4] migration: Inactivate images after .save_live_complete_precopy() Kevin Wolf
2017-05-23 15:36 ` Eric Blake
2017-05-24 11:34 ` Juan Quintela
2017-05-23 14:01 ` [Qemu-devel] [PATCH 3/4] migration/block: Clean up BBs in block_save_complete() Kevin Wolf
2017-05-23 15:41 ` Eric Blake
2017-05-23 14:01 ` [Qemu-devel] [PATCH 4/4] qemu-iotests: Block migration test Kevin Wolf
2017-05-23 15:46 ` Eric Blake
2017-05-23 16:18 ` Kevin Wolf
2017-05-23 16:29 ` Eric Blake [this message]
2017-05-24 6:23 ` [Qemu-devel] [PATCH 0/4] Block migration (migrate -b) fixes Fam Zheng
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=6e53753c-f9c0-6d8c-24c9-7954da0dde68@redhat.com \
--to=eblake@redhat.com \
--cc=dgilbert@redhat.com \
--cc=famz@redhat.com \
--cc=kwolf@redhat.com \
--cc=mreitz@redhat.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=quintela@redhat.com \
--cc=stefanha@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).