From: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
Activating the block devices causes the locks to be taken on
the backing file. If we're running with -S and the destination libvirt
hasn't started the destination with 'cont', it's expecting the locks are
still untaken.
Don't activate the block devices if we're not going to autostart the VM;
'cont' already will do that anyway. This change is tied to the new
migration capability 'late-block-activate' that defaults to off, keeping
the old behaviour by default.
bz: https://bugzilla.redhat.com/show_bug.cgi?id=1560854
Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
---
migration/migration.c | 34 +++++++++++++++++++++++++++-------
qapi/migration.json | 6 +++++-
2 files changed, 32 insertions(+), 8 deletions(-)
diff --git a/migration/migration.c b/migration/migration.c
index 52a5092add..a05c6c893b 100644
--- a/migration/migration.c
+++ b/migration/migration.c
@@ -197,6 +197,16 @@ static void migrate_generate_event(int new_state)
}
}
+static bool migrate_late_block_activate(void)
+{
+ MigrationState *s;
+
+ s = migrate_get_current();
+
+ return s->enabled_capabilities[
+ MIGRATION_CAPABILITY_LATE_BLOCK_ACTIVATE];
+}
+
/*
* Called on -incoming with a defer: uri.
* The migration can be started later after any parameters have been
@@ -306,13 +316,23 @@ static void process_incoming_migration_bh(void *opaque)
Error *local_err = NULL;
MigrationIncomingState *mis = opaque;
- /* Make sure all file formats flush their mutable metadata.
- * If we get an error here, just don't restart the VM yet. */
- bdrv_invalidate_cache_all(&local_err);
- if (local_err) {
- error_report_err(local_err);
- local_err = NULL;
- autostart = false;
+ /* If capability late_block_activate is set:
+ * Only fire up the block code now if we're going to restart the
+ * VM, else 'cont' will do it.
+ * This causes file locking to happen; so we don't want it to happen
+ * unless we really are starting the VM.
+ */
+ if (!migrate_late_block_activate() ||
+ (autostart && (!global_state_received() ||
+ global_state_get_runstate() == RUN_STATE_RUNNING))) {
+ /* Make sure all file formats flush their mutable metadata.
+ * If we get an error here, just don't restart the VM yet. */
+ bdrv_invalidate_cache_all(&local_err);
+ if (local_err) {
+ error_report_err(local_err);
+ local_err = NULL;
+ autostart = false;
+ }
}
/*
diff --git a/qapi/migration.json b/qapi/migration.json
index 9d0bf82cf4..757302762d 100644
--- a/qapi/migration.json
+++ b/qapi/migration.json
@@ -357,13 +357,17 @@
# @dirty-bitmaps: If enabled, QEMU will migrate named dirty bitmaps.
# (since 2.12)
#
+# @late-block-activate: If enabled, the destination will not activate block
+# devices (and thus take locks) immediately at the end of migration.
+# (since 2.13)
+#
# Since: 1.2
##
{ 'enum': 'MigrationCapability',
'data': ['xbzrle', 'rdma-pin-all', 'auto-converge', 'zero-blocks',
'compress', 'events', 'postcopy-ram', 'x-colo', 'release-ram',
'block', 'return-path', 'pause-before-switchover', 'x-multifd',
- 'dirty-bitmaps' ] }
+ 'dirty-bitmaps', 'late-block-activate' ] }
##
# @MigrationCapabilityStatus:
--
2.17.0
"Dr. David Alan Gilbert (git)" <dgilbert@redhat.com> wrote: > From: "Dr. David Alan Gilbert" <dgilbert@redhat.com> > > Activating the block devices causes the locks to be taken on > the backing file. If we're running with -S and the destination libvirt > hasn't started the destination with 'cont', it's expecting the locks are > still untaken. I will try to change the naming, because we have: - don't activate block device - and we stop calling bdrv_invalidate_cache_all i.e. behind the scenes bdrv_invalidate_cache activates a block device, not bad O:-) > Don't activate the block devices if we're not going to autostart the VM; > 'cont' already will do that anyway. This change is tied to the new > migration capability 'late-block-activate' that defaults to off, keeping > the old behaviour by default. I have read the old discussion, and we have: - current patch (not call bdrv_invalidate_cache() at bottom_handler) - kevin approach: create two commands activate_devices/deactivate_devices and make libvirt use them correctly I am not really sure which one is better, but as the patch author is Dave .... > bz: https://bugzilla.redhat.com/show_bug.cgi?id=1560854 > Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com> > --- > migration/migration.c | 34 +++++++++++++++++++++++++++------- > qapi/migration.json | 6 +++++- > 2 files changed, 32 insertions(+), 8 deletions(-) Reviewed-by: Juan Quintela <quintela@redhat.com> > +# @late-block-activate: If enabled, the destination will not activate block > +# devices (and thus take locks) immediately at the end of migration. > +# (since 2.13) > +# > # Since: 1.2 > ## > { 'enum': 'MigrationCapability', > 'data': ['xbzrle', 'rdma-pin-all', 'auto-converge', 'zero-blocks', > 'compress', 'events', 'postcopy-ram', 'x-colo', 'release-ram', > 'block', 'return-path', 'pause-before-switchover', 'x-multifd', > - 'dirty-bitmaps' ] } > + 'dirty-bitmaps', 'late-block-activate' ] } > > ## > # @MigrationCapabilityStatus: Just wondering, is there a way to enable a capability for 2.13 and newer, and not activate it for older versions? I *think* that this feature should be on in new releases, and off by default with old machine types. But I haven't through long enough to know what needs to be changed. Later, Juan.
"Dr. David Alan Gilbert (git)" <dgilbert@redhat.com> wrote: > From: "Dr. David Alan Gilbert" <dgilbert@redhat.com> > > Activating the block devices causes the locks to be taken on > the backing file. If we're running with -S and the destination libvirt > hasn't started the destination with 'cont', it's expecting the locks are > still untaken. > > Don't activate the block devices if we're not going to autostart the VM; > 'cont' already will do that anyway. This change is tied to the new > migration capability 'late-block-activate' that defaults to off, keeping > the old behaviour by default. > > bz: https://bugzilla.redhat.com/show_bug.cgi?id=1560854 > Signed-off-by: Dr. David Alan Gilbert <dgilbert@redhat.com> Reviewed-by: Juan Quintela <quintela@redhat.com>
© 2016 - 2024 Red Hat, Inc.