12.04.2018 11:34, Vladimir Sementsov-Ogievskiy wrote:
11.04.2018 19:11, Max Reitz wrote:
On 2018-04-11 15:05, Vladimir Sementsov-Ogievskiy wrote:


Hmm, first type? I'm now not sure about, did I really see sha256
mismatch, or something like this (should be error, but found bitmap):

--- /work/src/qemu/up-169/tests/qemu-iotests/169.out 2018-04-11
15:35:10.055027392 +0300
+++ /work/src/qemu/up-169/tests/qemu-iotests/169.out.bad 2018-04-11
15:58:09.300450045 +0300
@@ -1,5 +1,20 @@
+FAIL: test__not_persistent__migbitmap__offline
+methodcaller(name, ...) --> methodcaller object
+Traceback (most recent call last):
+  File "169", line 136, in do_test_migration
+    self.check_bitmap(self.vm_b, sha256 if persistent else False)
+  File "169", line 77, in check_bitmap
+    "Dirty bitmap 'bitmap0' not found");
+  File "/work/src/qemu/up-169/tests/qemu-iotests/iotests.py", line 389,
in assert_qmp
+    result = self.dictpath(d, path)
+  File "/work/src/qemu/up-169/tests/qemu-iotests/iotests.py", line 348,
in dictpath
+    self.fail('failed path traversal for "%s" in "%s"' % (path, str(d)))
+AssertionError: failed path traversal for "error/desc" in "{u'return':

Max, did you really seed sha256 mismatch or only something like this?
I'm pretty sure I did see mismatches.

hm, may be it possible too, because of not waiting for RESUME in this case, we can request sha256 in the intermediate state of bitmap loading

no. if you see mismatch on first check after migration, then it is after RESUME event, so it means, migrated broken bitmap, it's a bug..

if you see mismatch on second check - after vm_b stop/start, this means that it is a persistent case, so incoming migration should fail, and bitmap is loaded from file, but how it can mismatch? persistance bug?


Best regards,

Reply via email to