From: Max Reitz <mreitz@redhat.com>
To: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>,
John Snow <jsnow@redhat.com>,
qemu-devel@nongnu.org, qemu-block@nongnu.org
Cc: kwolf@redhat.com, den@openvz.org
Subject: Re: [Qemu-devel] [PATCH] iotests: fix 169
Date: Wed, 11 Apr 2018 13:52:12 +0200 [thread overview]
Message-ID: <766b66de-8ca8-c687-e9a3-616f1b8b55b7@redhat.com> (raw)
In-Reply-To: <47c416af-4b8e-db9a-4b4b-9b0eb060b4ff@virtuozzo.com>
On 2018-04-11 11:02, Vladimir Sementsov-Ogievskiy wrote:
> 03.04.2018 23:13, John Snow wrote:
>>
>> On 04/03/2018 12:23 PM, Max Reitz wrote:
>>> On 2018-03-30 18:10, Vladimir Sementsov-Ogievskiy wrote:
>>>> Use MIGRATION events instead of RESUME. Also, make a TODO: enable
>>>> dirty-bitmaps capability for offline case.
>>>>
>>>> This (likely) fixes racy faults at least of the following types:
>>>>
>>>> - timeout on waiting for RESUME event
>>>> - sha256 mismatch on 136 (138 after this patch)
>>>>
>>>> Signed-off-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
>>>> ---
>>>>
>>>> This patch is a true change for the test anyway. But I don't
>>>> understand,
>>>> why (and do really) it fixes the things. And I'm not sure about do we
>>>> really have a bug in bitmap migration or persistence. So, it's up to
>>>> you,
>>>> take it into 2.12...
>>>>
>>>> It was already discussed, that "STOP" event is bad for tests. What
>>>> about
>>>> "RESUME"? How can we miss it? And sha256 mismatch is really something
>>>> strange.
>>>>
>>>> Max, please check, do it fix 169 for you.
>>>>
>>>> tests/qemu-iotests/169 | 44
>>>> +++++++++++++++++++++++---------------------
>>>> 1 file changed, 23 insertions(+), 21 deletions(-)
>>> This makes the test pass (thanks!), but it still leaves behind five
>>> cats...
>>>
>>> Max
>>>
>>>
>> Hmm:
>>
>> jhuston 14772 0.0 0.0 4296 784 pts/3 S 16:12 0:00 cat
>> /home/bos/jhuston/src/qemu/bin/git/tests/qemu-iotests/scratch/mig_file
>> jhuston 14796 0.0 0.0 4296 764 pts/3 S 16:12 0:00 cat
>> /home/bos/jhuston/src/qemu/bin/git/tests/qemu-iotests/scratch/mig_file
>> jhuston 14940 0.0 0.0 4296 788 pts/3 S 16:12 0:00 cat
>> /home/bos/jhuston/src/qemu/bin/git/tests/qemu-iotests/scratch/mig_file
>> jhuston 14964 0.0 0.0 4296 720 pts/3 S 16:12 0:00 cat
>> /home/bos/jhuston/src/qemu/bin/git/tests/qemu-iotests/scratch/mig_file
>> jhuston 15052 0.0 0.0 4296 768 pts/3 S 16:12 0:00 cat
>> /home/bos/jhuston/src/qemu/bin/git/tests/qemu-iotests/scratch/mig_file
>>
>> Why do these get left behind? Nothing to consume the data...?
>
> aha, understand. it is due to last vm_b.shutdown() and vm_b.launch in
> case of should_migrate. So, at the end of the test I restart vm_b with
> -incoming parameter. But it looks like a bug anyway, If we start qemu
> with -incoming "exec", should not we kill cat process, if there were no
> migration?
I agree, but it's your choice whether you want to fix that bug or just
change the test slightly -- I'm responsible for the iotests, but not for
migration, so I have to admit I don't mind just changing this test to
accomodate. O:-)
It appears that just removing the mig_file before the second
vm_b.launch() is sufficient (and enclosing the removal of that file in
tearDown() in a try/except block). I suppose the cat process will
complain, but that doesn't stop the test from passing. If you want to
be really nice, I suppose you could just overwrite the FIFO mig_file
with an empty regular file, but I don't think it's actually necessary...
Max
prev parent reply other threads:[~2018-04-11 11:52 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-30 16:10 [Qemu-devel] [PATCH] iotests: fix 169 Vladimir Sementsov-Ogievskiy
2018-03-30 16:11 ` Vladimir Sementsov-Ogievskiy
2018-03-31 8:59 ` no-reply
2018-04-03 16:23 ` Max Reitz
2018-04-03 20:13 ` John Snow
2018-04-11 9:02 ` Vladimir Sementsov-Ogievskiy
2018-04-11 9:36 ` Vladimir Sementsov-Ogievskiy
2018-04-11 13:05 ` Vladimir Sementsov-Ogievskiy
2018-04-11 13:40 ` Vladimir Sementsov-Ogievskiy
2018-04-11 16:11 ` Max Reitz
2018-04-12 8:34 ` Vladimir Sementsov-Ogievskiy
2018-04-12 9:09 ` Vladimir Sementsov-Ogievskiy
2018-04-13 13:35 ` Max Reitz
2018-04-11 11:52 ` Max Reitz [this message]
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=766b66de-8ca8-c687-e9a3-616f1b8b55b7@redhat.com \
--to=mreitz@redhat.com \
--cc=den@openvz.org \
--cc=jsnow@redhat.com \
--cc=kwolf@redhat.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=vsementsov@virtuozzo.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).