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 <vsement...@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
