@@ -1501,6 +1501,7 @@ static void external_snapshot_prepare(BlkActionState *common,
TransactionAction *action = common->action;
AioContext *aio_context;
AioContext *old_context;
+ uint64_t perm, shared;
int ret;
/* 'blockdev-snapshot' and 'blockdev-snapshot-sync' have similar
@@ -1616,16 +1617,17 @@ static void external_snapshot_prepare(BlkActionState *common,
goto out;
}
- if (bdrv_has_blk(state->new_bs)) {
+ /*
+ * Allow attaching a backing file to an overlay that's already in use only
+ * if the parents don't assume that they are already seeing a valid image.
+ * (Specifically, allow it as a mirror target, which is write-only access.)
+ */
+ bdrv_get_cumulative_perm(state->new_bs, &perm, &shared);
+ if (perm & BLK_PERM_CONSISTENT_READ) {
error_setg(errp, "The overlay is already in use");
goto out;
}
- if (bdrv_op_is_blocked(state->new_bs, BLOCK_OP_TYPE_EXTERNAL_SNAPSHOT,
- errp)) {
- goto out;
- }
-
if (state->new_bs->backing != NULL) {
error_setg(errp, "The overlay already has a backing image");
goto out;
blockdev-snapshot returned an error if the overlay was already in use, which it defined as having any BlockBackend parent. This is in fact both too strict (some parents can tolerate the change of visible data caused by attaching a backing file) and too loose (some non-BlockBackend parents may not be happy with it). One important use case that is prevented by the too strict check is live storage migration with blockdev-mirror. Here, the target node is usually opened without a backing file so that the active layer is mirrored while its backing chain can be copied in the background. The backing chain should be attached to the mirror target node when finalising the job, just before switching the users of the source node to the new copy (at which point the mirror job still has a reference to the node). drive-mirror did this automatically, but with blockdev-mirror this is the job of the QMP client, so it needs a way to do this. blockdev-snapshot is the obvious way, so this patch makes it work in this scenario. The new condition is that no parent uses CONSISTENT_READ permissions. This will ensure that the operation will still be blocked when the node is attached to the guest device, so blockdev-snapshot remains safe. (For the sake of completeness, x-blockdev-reopen can be used to achieve the same, however it is a big hammer, performs the graph change completely unchecked and is still experimental. So even with the option of using x-blockdev-reopen, there are reasons why blockdev-snapshot should be able to perform this operation.) Signed-off-by: Kevin Wolf <kwolf@redhat.com> --- blockdev.c | 14 ++++++++------ 1 file changed, 8 insertions(+), 6 deletions(-)