qemu-block
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-block] [Qemu-devel] [PATCH 4/4] qemu-iotests: Block migration


From: Eric Blake
Subject: Re: [Qemu-block] [Qemu-devel] [PATCH 4/4] qemu-iotests: Block migration test
Date: Tue, 23 May 2017 11:29:13 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.0

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 <address@hidden>
>>> ---
>>>  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: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]