I didn't add Stefans patch yet. Note: the Mentioned patch is at: Note: http://lists.nongnu.org/archive/html/qemu-devel/2017-08/msg04027.html
With your debug patch applied I get: 2017-08-22 17:57:04.486+0000: initiating migration bdrv_inactivate_recurse: entry for drive-virtio-disk0 bdrv_inactivate_recurse: entry for #block145 bdrv_inactivate_recurse: entry for #block328 bdrv_inactivate_recurse: entry for #block210 bdrv_inactivate_recurse: exit end good for #block210 bdrv_inactivate_recurse: exit end good for #block328 bdrv_inactivate_recurse: entry for #block082 bdrv_inactivate_recurse: exit end good for #block082 bdrv_inactivate_recurse: exit end good for #block145 bdrv_inactivate_recurse: exit end good for drive-virtio-disk0 bdrv_inactivate_recurse: entry for #block763 bdrv_inactivate_recurse: entry for #block631 bdrv_inactivate_recurse: exit end good for #block631 bdrv_inactivate_recurse: exit end good for #block763 bdrv_inactivate_recurse: entry for drive-virtio-disk1 bdrv_inactivate_recurse: entry for #block544 bdrv_inactivate_recurse: entry for #block405 bdrv_inactivate_recurse: exit end good for #block405 bdrv_inactivate_recurse: exit end good for #block544 bdrv_inactivate_recurse: exit end good for drive-virtio-disk1 bdrv_inactivate_recurse: entry for #block1086 bdrv_inactivate_recurse: entry for #block919 bdrv_inactivate_recurse: exit end good for #block919 bdrv_inactivate_recurse: exit end good for #block1086 bdrv_inactivate_recurse: entry for drive-virtio-disk0 bdrv_inactivate_recurse: exit 2(-1) for drive-virtio-disk0 I'm currently building one with Stefans patch applied as well over (my) night, but let me know if there is more that makes sense to try. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/1711602 Title: --copy-storage-all failing with qemu 2.10 Status in QEMU: New Status in libvirt package in Ubuntu: Confirmed Status in qemu package in Ubuntu: Confirmed Bug description: We fixed an issue around disk locking already in regard to qemu-nbd [1], but there still seem to be issues. $ virsh migrate --live --copy-storage-all kvmguest-artful-normal qemu+ssh://10.22.69.196/system error: internal error: qemu unexpectedly closed the monitor: 2017-08-18T12:10:29.800397Z qemu-system-x86_64: -chardev pty,id=charserial0: char device redirected to /dev/pts/0 (label charserial0) 2017-08-18T12:10:48.545776Z qemu-system-x86_64: load of migration failed: Input/output error Source libvirt log for the guest: 2017-08-18 12:09:08.251+0000: initiating migration 2017-08-18T12:09:08.809023Z qemu-system-x86_64: Unable to read from socket: Connection reset by peer 2017-08-18T12:09:08.809481Z qemu-system-x86_64: Unable to read from socket: Connection reset by peer Target libvirt log for the guest: 2017-08-18T12:09:08.730911Z qemu-system-x86_64: load of migration failed: Input/output error 2017-08-18 12:09:09.010+0000: shutting down, reason=crashed Given the timing it seems that the actual copy now works (it is busy ~10 seconds on my environment which would be the copy). Also we don't see the old errors we saw before, but afterwards on the actual take-over it fails. Dmesg has no related denials as often apparmor is in the mix. Need to check libvirt logs of source [2] and target [3] in Detail. [1]: https://lists.gnu.org/archive/html/qemu-devel/2017-08/msg02200.html [2]: http://paste.ubuntu.com/25339356/ [3]: http://paste.ubuntu.com/25339358/ To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/1711602/+subscriptions