[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-commits] [qemu/qemu] 14f16b: qemu-img: Support bitmap --merge into

From: Peter Maydell
Subject: [Qemu-commits] [qemu/qemu] 14f16b: qemu-img: Support bitmap --merge into backing image
Date: Wed, 23 Sep 2020 09:00:42 -0700

  Branch: refs/heads/master
  Home:   https://github.com/qemu/qemu
  Commit: 14f16bf9474c860ecc127a66a86961942319f7af
  Author: Eric Blake <eblake@redhat.com>
  Date:   2020-09-21 (Mon, 21 Sep 2020)

  Changed paths:
    M qemu-img.c
    M tests/qemu-iotests/291
    M tests/qemu-iotests/291.out

  Log Message:
  qemu-img: Support bitmap --merge into backing image

If you have the chain 'base.qcow2 <- top.qcow2' and want to merge a
bitmap from top into base, qemu-img was failing with:

qemu-img: Could not open 'top.qcow2': Could not open backing file: Failed to 
get shared "write" lock
Is another process using the image [base.qcow2]?

The easiest fix is to not open the entire backing chain of either
image (source or destination); after all, the point of 'qemu-img
bitmap' is solely to manipulate bitmaps directly within a single qcow2
image, and this is made more precise if we don't pay attention to
other images in the chain that may happen to have a bitmap by the same

However, note that on a case-by-case analysis, there _are_ times where
we treat it as a feature that we can access a bitmap from a backing
layer in association with an overlay BDS.  A demonstration of this is
using NBD to expose both an overlay BDS (for constant contents) and a
bitmap (for learning which blocks are interesting) during an
incremental backup:

Base <- Active <- Temporary
          \--block job ->/

where Temporary is being fed by a backup 'sync=none' job.  When
exposing Temporary over NBD, referring to a bitmap that lives only in
Active is less effort than having to copy a bitmap into Temporary [1].
So the testsuite additions in this patch check both where bitmaps get
allocated (the qemu-img info output), and that qemu-nbd is indeed able
to access a bitmap inherited from the backing chain since it is a
different use case than 'qemu-img bitmap'.

[1] Full disclosure: prior to the recent commit 374eedd1c4 and
friends, we were NOT able to see bitmaps through filters, which meant
that we actually did not have nice clean semantics for uniformly being
able to pick up bitmaps from anywhere in the backing chain (seen as a
change in behavior between qemu 4.1 and 4.2 at commit 00e30f05de, when
block-copy swapped from a one-off to a filter).  Which means libvirt
was already coded to copy bitmaps around for the sake of older qemu,
even though modern qemu no longer needs it.  Oh well.

Fixes: http://bugzilla.redhat.com/1877209
Reported-by: Eyal Shenitzky <eshenitz@redhat.com>
Signed-off-by: Eric Blake <eblake@redhat.com>
Message-Id: <20200914191009.644842-1-eblake@redhat.com>
[eblake: more commit message tweaks, per Max Reitz review]
Reviewed-by: Max Reitz <mreitz@redhat.com>
Reviewed-by: Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>

  Commit: c122bca9cd7b986be4d473240a4fec6315b7a2c2
  Author: Peter Maydell <peter.maydell@linaro.org>
  Date:   2020-09-23 (Wed, 23 Sep 2020)

  Changed paths:
    M qemu-img.c
    M tests/qemu-iotests/291
    M tests/qemu-iotests/291.out

  Log Message:
  Merge remote-tracking branch 'remotes/ericb/tags/pull-bitmaps-2020-09-21' 
into staging

bitmaps patches for 2020-09-21

- Eric Blake: Improve 'qemu-img bitmap --merge' by not opening backing images

# gpg: Signature made Tue 22 Sep 2020 01:58:31 BST
# gpg:                using RSA key 71C2CC22B1C4602927D2F3AAA7A16B4A2527436A
# gpg: Good signature from "Eric Blake <eblake@redhat.com>" [full]
# gpg:                 aka "Eric Blake (Free Software Programmer) 
<ebb9@byu.net>" [full]
# gpg:                 aka "[jpeg image of size 6874]" [full]
# Primary key fingerprint: 71C2 CC22 B1C4 6029 27D2  F3AA A7A1 6B4A 2527 436A

* remotes/ericb/tags/pull-bitmaps-2020-09-21:
  qemu-img: Support bitmap --merge into backing image

Signed-off-by: Peter Maydell <peter.maydell@linaro.org>

Compare: https://github.com/qemu/qemu/compare/0fc0142828b5...c122bca9cd7b

reply via email to

[Prev in Thread] Current Thread [Next in Thread]