2020-05-21 22:21:37 +03:00
|
|
|
#!/usr/bin/env bash
|
|
|
|
#
|
|
|
|
# Test qemu-img bitmap handling
|
|
|
|
#
|
|
|
|
# Copyright (C) 2018-2020 Red Hat, Inc.
|
|
|
|
#
|
|
|
|
# This program is free software; you can redistribute it and/or modify
|
|
|
|
# it under the terms of the GNU General Public License as published by
|
|
|
|
# the Free Software Foundation; either version 2 of the License, or
|
|
|
|
# (at your option) any later version.
|
|
|
|
#
|
|
|
|
# This program is distributed in the hope that it will be useful,
|
|
|
|
# but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
|
|
# GNU General Public License for more details.
|
|
|
|
#
|
|
|
|
# You should have received a copy of the GNU General Public License
|
|
|
|
# along with this program. If not, see <http://www.gnu.org/licenses/>.
|
|
|
|
#
|
|
|
|
|
|
|
|
seq="$(basename $0)"
|
|
|
|
echo "QA output created by $seq"
|
|
|
|
|
|
|
|
status=1 # failure is the default!
|
|
|
|
|
|
|
|
_cleanup()
|
|
|
|
{
|
|
|
|
_cleanup_test_img
|
|
|
|
nbd_server_stop
|
|
|
|
}
|
|
|
|
trap "_cleanup; exit \$status" 0 1 2 3 15
|
|
|
|
|
|
|
|
# get standard environment, filters and checks
|
|
|
|
. ./common.rc
|
|
|
|
. ./common.filter
|
|
|
|
. ./common.nbd
|
|
|
|
|
|
|
|
_supported_fmt qcow2
|
|
|
|
_supported_proto file
|
|
|
|
_supported_os Linux
|
|
|
|
_require_command QEMU_NBD
|
2020-06-17 13:48:22 +03:00
|
|
|
# compat=0.10 does not support bitmaps
|
|
|
|
_unsupported_imgopts 'compat=0.10'
|
2020-05-21 22:21:37 +03:00
|
|
|
|
2020-10-27 19:44:15 +03:00
|
|
|
# Filter irrelevant format-specific information from the qemu-img info
|
|
|
|
# output (we only want the bitmaps, basically)
|
|
|
|
_filter_irrelevant_img_info()
|
|
|
|
{
|
|
|
|
grep -v -e 'compat' -e 'compression type' -e 'data file' -e 'extended l2' \
|
|
|
|
-e 'lazy refcounts' -e 'refcount bits'
|
|
|
|
}
|
|
|
|
|
2020-05-21 22:21:37 +03:00
|
|
|
echo
|
|
|
|
echo "=== Initial image setup ==="
|
|
|
|
echo
|
|
|
|
|
|
|
|
# Create backing image with one bitmap
|
|
|
|
TEST_IMG="$TEST_IMG.base" _make_test_img 10M
|
|
|
|
$QEMU_IMG bitmap --add -f $IMGFMT "$TEST_IMG.base" b0
|
|
|
|
$QEMU_IO -c 'w 3M 1M' -f $IMGFMT "$TEST_IMG.base" | _filter_qemu_io
|
|
|
|
|
|
|
|
# Create initial image and populate two bitmaps: one active, one inactive.
|
|
|
|
ORIG_IMG=$TEST_IMG
|
|
|
|
TEST_IMG=$TEST_IMG.orig
|
|
|
|
_make_test_img -b "$ORIG_IMG.base" -F $IMGFMT 10M
|
|
|
|
$QEMU_IO -c 'w 0 1M' -f $IMGFMT "$TEST_IMG" | _filter_qemu_io
|
|
|
|
$QEMU_IMG bitmap --add -g 512k -f $IMGFMT "$TEST_IMG" b1
|
|
|
|
$QEMU_IMG bitmap --add --disable -f $IMGFMT "$TEST_IMG" b2
|
|
|
|
$QEMU_IO -c 'w 3M 1M' -f $IMGFMT "$TEST_IMG" | _filter_qemu_io
|
|
|
|
$QEMU_IMG bitmap --clear -f $IMGFMT "$TEST_IMG" b1
|
|
|
|
$QEMU_IO -c 'w 1M 1M' -f $IMGFMT "$TEST_IMG" | _filter_qemu_io
|
|
|
|
$QEMU_IMG bitmap --disable -f $IMGFMT "$TEST_IMG" b1
|
|
|
|
$QEMU_IMG bitmap --enable -f $IMGFMT "$TEST_IMG" b2
|
|
|
|
$QEMU_IO -c 'w 2M 1M' -f $IMGFMT "$TEST_IMG" | _filter_qemu_io
|
|
|
|
|
|
|
|
echo
|
|
|
|
echo "=== Bitmap preservation not possible to non-qcow2 ==="
|
|
|
|
echo
|
|
|
|
|
|
|
|
TEST_IMG=$ORIG_IMG
|
|
|
|
$QEMU_IMG convert --bitmaps -O raw "$TEST_IMG.orig" "$TEST_IMG" &&
|
|
|
|
echo "unexpected success"
|
|
|
|
|
|
|
|
echo
|
|
|
|
echo "=== Convert with bitmap preservation ==="
|
|
|
|
echo
|
|
|
|
|
|
|
|
# Only bitmaps from the active layer are copied
|
|
|
|
$QEMU_IMG convert --bitmaps -O qcow2 "$TEST_IMG.orig" "$TEST_IMG"
|
2020-10-27 19:44:15 +03:00
|
|
|
_img_info --format-specific | _filter_irrelevant_img_info
|
2020-05-21 22:21:37 +03:00
|
|
|
# But we can also merge in bitmaps from other layers. This test is a bit
|
|
|
|
# contrived to cover more code paths, in reality, you could merge directly
|
|
|
|
# into b0 without going through tmp
|
|
|
|
$QEMU_IMG bitmap --add --disable -f $IMGFMT "$TEST_IMG" b0
|
|
|
|
$QEMU_IMG bitmap --add --merge b0 -b "$TEST_IMG.base" -F $IMGFMT \
|
|
|
|
-f $IMGFMT "$TEST_IMG" tmp
|
|
|
|
$QEMU_IMG bitmap --merge tmp -f $IMGFMT "$TEST_IMG" b0
|
|
|
|
$QEMU_IMG bitmap --remove --image-opts \
|
|
|
|
driver=$IMGFMT,file.driver=file,file.filename="$TEST_IMG" tmp
|
2020-10-27 19:44:15 +03:00
|
|
|
_img_info --format-specific | _filter_irrelevant_img_info
|
2020-05-21 22:21:37 +03:00
|
|
|
|
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
name.
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>
2020-09-14 22:10:09 +03:00
|
|
|
echo
|
|
|
|
echo "=== Merge from top layer into backing image ==="
|
|
|
|
echo
|
|
|
|
|
|
|
|
$QEMU_IMG rebase -u -F qcow2 -b "$TEST_IMG.base" "$TEST_IMG"
|
|
|
|
$QEMU_IMG bitmap --add --merge b2 -b "$TEST_IMG" -F $IMGFMT \
|
|
|
|
-f $IMGFMT "$TEST_IMG.base" b3
|
2020-10-27 19:44:15 +03:00
|
|
|
_img_info --format-specific --backing-chain | _filter_irrelevant_img_info
|
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
name.
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>
2020-09-14 22:10:09 +03:00
|
|
|
|
2020-05-21 22:21:37 +03:00
|
|
|
echo
|
|
|
|
echo "=== Check bitmap contents ==="
|
|
|
|
echo
|
|
|
|
|
|
|
|
# x-dirty-bitmap is a hack for reading bitmaps; it abuses block status to
|
|
|
|
# report "data":false for portions of the bitmap which are set
|
|
|
|
IMG="driver=nbd,server.type=unix,server.path=$nbd_unix_socket"
|
2020-10-27 08:05:52 +03:00
|
|
|
nbd_server_start_unix_socket -r -f qcow2 \
|
|
|
|
-B b0 -B b1 -B b2 -B b3 "$TEST_IMG"
|
2020-05-21 22:21:37 +03:00
|
|
|
$QEMU_IMG map --output=json --image-opts \
|
|
|
|
"$IMG,x-dirty-bitmap=qemu:dirty-bitmap:b0" | _filter_qemu_img_map
|
|
|
|
$QEMU_IMG map --output=json --image-opts \
|
|
|
|
"$IMG,x-dirty-bitmap=qemu:dirty-bitmap:b1" | _filter_qemu_img_map
|
|
|
|
$QEMU_IMG map --output=json --image-opts \
|
|
|
|
"$IMG,x-dirty-bitmap=qemu:dirty-bitmap:b2" | _filter_qemu_img_map
|
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
name.
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>
2020-09-14 22:10:09 +03:00
|
|
|
$QEMU_IMG map --output=json --image-opts \
|
|
|
|
"$IMG,x-dirty-bitmap=qemu:dirty-bitmap:b3" | _filter_qemu_img_map
|
2020-05-21 22:21:37 +03:00
|
|
|
|
2020-10-27 19:44:16 +03:00
|
|
|
nbd_server_stop
|
|
|
|
|
2020-05-21 22:21:37 +03:00
|
|
|
# success, all done
|
|
|
|
echo '*** done'
|
|
|
|
rm -f $seq.full
|
|
|
|
status=0
|