migration: Don't activate block devices if using -S
PATCH v2 1/1 migration: Don't activate block devices if using -S
From: "Dr. David Alan Gilbert" <[email protected]>
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
--- migration/migration.c | 34 +++++++++++++++++++++++++++------- qapi/migration.json | 6 +++++- 2 files changed, 32 insertions(+), 8 deletions(-)
migration/migration.c +27 -7
@@ -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; + } }/*
qapi/migration.json +5 -1
@@ -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:
Signature · 1 line
2.17.0
Quoted 6 lines · Dr. David Alan Gilbert (git)
From: "Dr. David Alan Gilbert" <[email protected]>
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:-)
Quoted 4 lines
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 ....
Quoted 6 lines
bz: https://bugzilla.redhat.com/show_bug.cgi?id=1560854
Signed-off-by Dr. David Alan Gilbert <[email protected]>--- migration/migration.c | 34 +++++++++++++++++++++++++++------- qapi/migration.json | 6 +++++- 2 files changed, 32 insertions(+), 8 deletions(-)
Quoted 5 lines
qapi/migration.json +4
-0+# @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
qapi/migration.json line 373
Quoted 10 lines
qapi/migration.json +1
-1## { '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.
Quoted 7 lines · Dr. David Alan Gilbert (git)
From: "Dr. David Alan Gilbert" <[email protected]>
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.
Quoted 7 lines
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 <[email protected]>