mirror of
https://github.com/Motorhead1991/qemu.git
synced 2025-07-29 05:13:54 -06:00
8597af7615
This patch proposes a flag to maintain disk activation status globally. It mostly rewrites disk activation mgmt for QEMU, including COLO and QMP command xen_save_devices_state. Backgrounds =========== We have two problems on disk activations, one resolved, one not. Problem 1: disk activation recover (for switchover interruptions) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ When migration is either cancelled or failed during switchover, especially when after the disks are inactivated, QEMU needs to remember re-activate the disks again before vm starts. It used to be done separately in two paths: one in qmp_migrate_cancel(), the other one in the failure path of migration_completion(). It used to be fixed in different commits, all over the places in QEMU. So these are the relevant changes I saw, I'm not sure if it's complete list: - In 2016, commitfe904ea824("migration: regain control of images when migration fails to complete") - In 2017, commit1d2acc3162("migration: re-active images while migration been canceled after inactive them") - In 2023, commit6dab4c93ec("migration: Attempt disk reactivation in more failure scenarios") Now since we have a slightly better picture maybe we can unify the reactivation in a single path. One side benefit of doing so is, we can move the disk operation outside QMP command "migrate_cancel". It's possible that in the future we may want to make "migrate_cancel" be OOB-compatible, while that requires the command doesn't need BQL in the first place. This will already do that and make migrate_cancel command lightweight. Problem 2: disk invalidation on top of invalidated disks ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ This is an unresolved bug for current QEMU. Link in "Resolves:" at the end. It turns out besides the src switchover phase (problem 1 above), QEMU also needs to remember block activation on destination. Consider two continuous migration in a row, where the VM was always paused. In that scenario, the disks are not activated even until migration completed in the 1st round. When the 2nd round starts, if QEMU doesn't know the status of the disks, it needs to try inactivate the disk again. Here the issue is the block layer API bdrv_inactivate_all() will crash a QEMU if invoked on already inactive disks for the 2nd migration. For detail, see the bug link at the end. Implementation ============== This patch proposes to maintain disk activation with a global flag, so we know: - If we used to inactivate disks for migration, but migration got cancelled, or failed, QEMU will know it should reactivate the disks. - On incoming side, if the disks are never activated but then another migration is triggered, QEMU should be able to tell that inactivate is not needed for the 2nd migration. We used to have disk_inactive, but it only solves the 1st issue, not the 2nd. Also, it's done in completely separate paths so it's extremely hard to follow either how the flag changes, or the duration that the flag is valid, and when we will reactivate the disks. Convert the existing disk_inactive flag into that global flag (also invert its naming), and maintain the disk activation status for the whole lifecycle of qemu. That includes the incoming QEMU. Put both of the error cases of source migration (failure, cancelled) together into migration_iteration_finish(), which will be invoked for either of the scenario. So from that part QEMU should behave the same as before. However with such global maintenance on disk activation status, we not only cleanup quite a few temporary paths that we try to maintain the disk activation status (e.g. in postcopy code), meanwhile it fixes the crash for problem 2 in one shot. For freshly started QEMU, the flag is initialized to TRUE showing that the QEMU owns the disks by default. For incoming migrated QEMU, the flag will be initialized to FALSE once and for all showing that the dest QEMU doesn't own the disks until switchover. That is guaranteed by the "once" variable. Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2395 Signed-off-by: Peter Xu <peterx@redhat.com> Reviewed-by: Fabiano Rosas <farosas@suse.de> Message-Id: <20241206230838.1111496-7-peterx@redhat.com> Signed-off-by: Fabiano Rosas <farosas@suse.de>
94 lines
2.5 KiB
C
94 lines
2.5 KiB
C
/*
|
|
* Block activation tracking for migration purpose
|
|
*
|
|
* SPDX-License-Identifier: GPL-2.0-or-later
|
|
*
|
|
* Copyright (C) 2024 Red Hat, Inc.
|
|
*/
|
|
#include "qemu/osdep.h"
|
|
#include "block/block.h"
|
|
#include "qapi/error.h"
|
|
#include "migration/migration.h"
|
|
#include "qemu/error-report.h"
|
|
#include "trace.h"
|
|
|
|
/*
|
|
* Migration-only cache to remember the block layer activation status.
|
|
* Protected by BQL.
|
|
*
|
|
* We need this because..
|
|
*
|
|
* - Migration can fail after block devices are invalidated (during
|
|
* switchover phase). When that happens, we need to be able to recover
|
|
* the block drive status by re-activating them.
|
|
*
|
|
* - Currently bdrv_inactivate_all() is not safe to be invoked on top of
|
|
* invalidated drives (even if bdrv_activate_all() is actually safe to be
|
|
* called any time!). It means remembering this could help migration to
|
|
* make sure it won't invalidate twice in a row, crashing QEMU. It can
|
|
* happen when we migrate a PAUSED VM from host1 to host2, then migrate
|
|
* again to host3 without starting it. TODO: a cleaner solution is to
|
|
* allow safe invoke of bdrv_inactivate_all() at anytime, like
|
|
* bdrv_activate_all().
|
|
*
|
|
* For freshly started QEMU, the flag is initialized to TRUE reflecting the
|
|
* scenario where QEMU owns block device ownerships.
|
|
*
|
|
* For incoming QEMU taking a migration stream, the flag is initialized to
|
|
* FALSE reflecting that the incoming side doesn't own the block devices,
|
|
* not until switchover happens.
|
|
*/
|
|
static bool migration_block_active;
|
|
|
|
/* Setup the disk activation status */
|
|
void migration_block_active_setup(bool active)
|
|
{
|
|
migration_block_active = active;
|
|
}
|
|
|
|
bool migration_block_activate(Error **errp)
|
|
{
|
|
ERRP_GUARD();
|
|
|
|
assert(bql_locked());
|
|
|
|
if (migration_block_active) {
|
|
trace_migration_block_activation("active-skipped");
|
|
return true;
|
|
}
|
|
|
|
trace_migration_block_activation("active");
|
|
|
|
bdrv_activate_all(errp);
|
|
if (*errp) {
|
|
error_report_err(error_copy(*errp));
|
|
return false;
|
|
}
|
|
|
|
migration_block_active = true;
|
|
return true;
|
|
}
|
|
|
|
bool migration_block_inactivate(void)
|
|
{
|
|
int ret;
|
|
|
|
assert(bql_locked());
|
|
|
|
if (!migration_block_active) {
|
|
trace_migration_block_activation("inactive-skipped");
|
|
return true;
|
|
}
|
|
|
|
trace_migration_block_activation("inactive");
|
|
|
|
ret = bdrv_inactivate_all();
|
|
if (ret) {
|
|
error_report("%s: bdrv_inactivate_all() failed: %d",
|
|
__func__, ret);
|
|
return false;
|
|
}
|
|
|
|
migration_block_active = false;
|
|
return true;
|
|
}
|