]> git.ipfire.org Git - thirdparty/qemu.git/commit
migration: Attempt disk reactivation in more failure scenarios
authorEric Blake <eblake@redhat.com>
Tue, 2 May 2023 20:52:12 +0000 (15:52 -0500)
committerMichael Tokarev <mjt@tls.msk.ru>
Thu, 18 May 2023 13:59:30 +0000 (16:59 +0300)
commitc0ad2a91914751819ddbf49d19043f9cbcbe2651
treefcd02b4e3d6df0c10815f1ecb5c1431ace80243f
parentd2a811dd7d95e3c35271edad066504d76e83dea4
migration: Attempt disk reactivation in more failure scenarios

Commit fe904ea824 added a fail_inactivate label, which tries to
reactivate disks on the source after a failure while s->state ==
MIGRATION_STATUS_ACTIVE, but didn't actually use the label if
qemu_savevm_state_complete_precopy() failed.  This failure to
reactivate is also present in commit 6039dd5b1c (also covering the new
s->state == MIGRATION_STATUS_DEVICE state) and 403d18ae (ensuring
s->block_inactive is set more reliably).

Consolidate the two labels back into one - no matter HOW migration is
failed, if there is any chance we can reach vm_start() after having
attempted inactivation, it is essential that we have tried to restart
disks before then.  This also makes the cleanup more like
migrate_fd_cancel().

Suggested-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Eric Blake <eblake@redhat.com>
Message-Id: <20230502205212.134680-1-eblake@redhat.com>
Acked-by: Peter Xu <peterx@redhat.com>
Reviewed-by: Juan Quintela <quintela@redhat.com>
Reviewed-by: Kevin Wolf <kwolf@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
(cherry picked from commit 6dab4c93ecfae48e2e67b984d1032c1e988d3005)
Signed-off-by: Michael Tokarev <mjt@tls.msk.ru>
(Mjt: minor context tweak near added comment in migration/migration.c)
migration/migration.c