I've reproduced your IO hang with 2.0 and both
9b1786829aefb83f37a8f3135e3ea91c56001b56 and
a096b3a6732f846ec57dc28b47ee9435aa0609bf applied.
Reverting 9b1786829aefb83f37a8f3135e3ea91c56001b56 indeed fixes the
problem (but reintroduces block-migration hang). It's seems like qemu
bug rather than guest problem, as no-kvmclock parameters makes no
difference. IO just stops, all qemu IO threads die off. Almost like it
forgets to migrate them:-)
Some more info:
a) 2.0 + 9b1786829aefb83f37a8f3135e3ea91c56001b56 +
a096b3a6732f846ec57dc28b47ee9435aa0609bf = hangs
b) 2.0 + 9b1786829aefb83f37a8f3135e3ea91c56001b56 = works
c) 2.0 + 9b1786829aefb83f37a8f3135e3ea91c56001b56 + move
cpu_synchronize_state to migration.c = works
Tested with NFS (qcow2) + cache=none.
IO is dead only for disk that was being written to during migration.
I.e. if my test VM has two disks: vda and vdb, and I'm running fio on
vdb and it hangs after migration, I can still issue writes to vda.
Recreation steps:
1. Create VM
2. Run fio (Andrey's config)
3. Live migrate VM couple of times.
--
mg
