From: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
To: John Snow <jsnow@redhat.com>, Max Reitz <mreitz@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 12:36:57 +0300 [thread overview]
Message-ID: <ec4ee8f5-7a47-2e18-1fe3-d4f3859bc8ce@virtuozzo.com> (raw)
In-Reply-To: <47c416af-4b8e-db9a-4b4b-9b0eb060b4ff@virtuozzo.com>
11.04.2018 12: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?
>
third type of fail, without this patch:
+======================================================================
+ERROR: test__persistent__migbitmap__offline_shared
(__main__.TestDirtyBitmapMigration)
+methodcaller(name, ...) --> methodcaller object
+----------------------------------------------------------------------
+Traceback (most recent call last):
+ File "169", line 135, in do_test_migration
+ self.vm_b.launch()
+ File
"/work/src/qemu/up-169/tests/qemu-iotests/../../scripts/qemu.py", line
221, in launch
+ self._launch()
+ File
"/work/src/qemu/up-169/tests/qemu-iotests/../../scripts/qemu.py", line
244, in _launch
+ self._post_launch()
+ File
"/work/src/qemu/up-169/tests/qemu-iotests/../../scripts/qtest.py", line
100, in _post_launch
+ super(QEMUQtestMachine, self)._post_launch()
+ File
"/work/src/qemu/up-169/tests/qemu-iotests/../../scripts/qemu.py", line
196, in _post_launch
+ self._qmp.accept()
+ File
"/work/src/qemu/up-169/tests/qemu-iotests/../../scripts/qmp/qmp.py",
line 157, in accept
+ return self.__negotiate_capabilities()
+ File
"/work/src/qemu/up-169/tests/qemu-iotests/../../scripts/qmp/qmp.py",
line 75, in __negotiate_capabilities
+ resp = self.cmd('qmp_capabilities')
+ File
"/work/src/qemu/up-169/tests/qemu-iotests/../../scripts/qmp/qmp.py",
line 191, in cmd
+ return self.cmd_obj(qmp_cmd)
+ File
"/work/src/qemu/up-169/tests/qemu-iotests/../../scripts/qmp/qmp.py",
line 174, in cmd_obj
+ resp = self.__json_read()
+ File
"/work/src/qemu/up-169/tests/qemu-iotests/../../scripts/qmp/qmp.py",
line 82, in __json_read
+ data = self.__sockfile.readline()
+ File "/usr/lib64/python2.7/socket.py", line 447, in readline
+ data = self._sock.recv(self._rbufsize)
+error: [Errno 104] Connection reset by peer
+
--
Best regards,
Vladimir
next prev parent reply other threads:[~2018-04-11 9:37 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 [this message]
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
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=ec4ee8f5-7a47-2e18-1fe3-d4f3859bc8ce@virtuozzo.com \
--to=vsementsov@virtuozzo.com \
--cc=den@openvz.org \
--cc=jsnow@redhat.com \
--cc=kwolf@redhat.com \
--cc=mreitz@redhat.com \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
/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).