migration: regain control of images when migration fails to complete
authorGreg Kurz <gkurz@linux.vnet.ibm.com>
Wed, 18 May 2016 13:44:36 +0000 (15:44 +0200)
committerAmit Shah <amit.shah@redhat.com>
Mon, 23 May 2016 16:49:36 +0000 (22:19 +0530)
commitfe904ea8242cbae2d7e69c052c754b8f5f1ba1d6
tree141b1f9a34b28310c9f36c1b239c69daffbf1603
parent24f3902b088cd4f2dbebfd90527b5d81d6a050e9
migration: regain control of images when migration fails to complete

We currently have an error path during migration that can cause
the source QEMU to abort:

migration_thread()
  migration_completion()
    runstate_is_running() ----------------> true if guest is running
    bdrv_inactivate_all() ----------------> inactivate images
    qemu_savevm_state_complete_precopy()
     ... qemu_fflush()
           socket_writev_buffer() --------> error because destination fails
         qemu_fflush() -------------------> set error on migration stream
  migration_completion() -----------------> set migrate state to FAILED
migration_thread() -----------------------> break migration loop
  vm_start() -----------------------------> restart guest with inactive
                                            images

and you get:

qemu-system-ppc64: socket_writev_buffer: Got err=104 for (32768/18446744073709551615)
qemu-system-ppc64: /home/greg/Work/qemu/qemu-master/block/io.c:1342:bdrv_co_do_pwritev: Assertion `!(bs->open_flags & 0x0800)' failed.
Aborted (core dumped)

If we try postcopy with a similar scenario, we also get the writev error
message but QEMU leaves the guest paused because entered_postcopy is true.

We could possibly do the same with precopy and leave the guest paused.
But since the historical default for migration errors is to restart the
source, this patch adds a call to bdrv_invalidate_cache_all() instead.

Signed-off-by: Greg Kurz <gkurz@linux.vnet.ibm.com>
Message-Id: <146357896785.6003.11983081732454362715.stgit@bahia.huguette.org>
Signed-off-by: Amit Shah <amit.shah@redhat.com>
migration/migration.c