2019-03-07 15:58:38 +01:00
|
|
|
#!/usr/bin/env bash
|
2021-01-16 14:44:19 +01:00
|
|
|
# group: rw auto
|
2013-09-03 10:09:55 +02:00
|
|
|
#
|
|
|
|
|
# Test case for image option amendment in qcow2.
|
|
|
|
|
#
|
|
|
|
|
# Copyright (C) 2013 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/>.
|
|
|
|
|
#
|
|
|
|
|
|
|
|
|
|
# creator
|
2022-03-22 18:42:12 +01:00
|
|
|
owner=hreitz@redhat.com
|
2013-09-03 10:09:55 +02:00
|
|
|
|
|
|
|
|
seq=`basename $0`
|
|
|
|
|
echo "QA output created by $seq"
|
|
|
|
|
|
|
|
|
|
status=1 # failure is the default!
|
|
|
|
|
|
|
|
|
|
_cleanup()
|
|
|
|
|
{
|
2019-02-26 15:00:29 +01:00
|
|
|
_cleanup_test_img
|
2019-11-07 17:37:01 +01:00
|
|
|
_rm_test_img "$TEST_IMG.data"
|
2013-09-03 10:09:55 +02:00
|
|
|
}
|
|
|
|
|
trap "_cleanup; exit \$status" 0 1 2 3 15
|
|
|
|
|
|
|
|
|
|
# get standard environment, filters and checks
|
|
|
|
|
. ./common.rc
|
|
|
|
|
. ./common.filter
|
|
|
|
|
|
2019-11-07 17:36:47 +01:00
|
|
|
# This tests qcow2-specific low-level functionality
|
2013-09-03 10:09:55 +02:00
|
|
|
_supported_fmt qcow2
|
2014-02-03 10:26:14 +01:00
|
|
|
_supported_proto file
|
2013-09-03 10:09:55 +02:00
|
|
|
_supported_os Linux
|
2019-11-07 17:36:57 +01:00
|
|
|
# Conversion between different compat versions can only really work
|
2019-11-07 17:37:07 +01:00
|
|
|
# with refcount_bits=16;
|
|
|
|
|
# we have explicit tests for data_file here, but the whole test does
|
2020-03-24 18:42:32 +01:00
|
|
|
# not work with it;
|
|
|
|
|
# we have explicit tests for various cluster sizes, the remaining tests
|
|
|
|
|
# require the default 64k cluster
|
2021-12-23 17:01:44 +01:00
|
|
|
# we don't have explicit tests for zstd qcow2 compression type, as zstd may be
|
|
|
|
|
# not compiled in. And we can't create compat images with comression type
|
|
|
|
|
# extension
|
|
|
|
|
_unsupported_imgopts 'refcount_bits=\([^1]\|.\([^6]\|$\)\)' data_file \
|
|
|
|
|
cluster_size compression_type
|
2013-09-03 10:09:55 +02:00
|
|
|
|
|
|
|
|
echo
|
|
|
|
|
echo "=== Testing version downgrade with zero expansion ==="
|
|
|
|
|
echo
|
2019-11-07 17:36:57 +01:00
|
|
|
_make_test_img -o "compat=1.1,lazy_refcounts=on" 64M
|
2013-09-03 10:09:55 +02:00
|
|
|
$QEMU_IO -c "write -z 0 128k" "$TEST_IMG" | _filter_qemu_io
|
2021-12-23 17:01:39 +01:00
|
|
|
_qcow2_dump_header
|
2013-09-03 10:09:55 +02:00
|
|
|
$QEMU_IMG amend -o "compat=0.10" "$TEST_IMG"
|
2021-12-23 17:01:39 +01:00
|
|
|
_qcow2_dump_header
|
2013-09-03 10:09:55 +02:00
|
|
|
$QEMU_IO -c "read -P 0 0 128k" "$TEST_IMG" | _filter_qemu_io
|
|
|
|
|
_check_test_img
|
|
|
|
|
|
2018-02-05 15:33:38 +01:00
|
|
|
echo
|
|
|
|
|
echo "=== Testing version downgrade with zero expansion and 4K cache entries ==="
|
|
|
|
|
echo
|
2019-11-07 17:36:57 +01:00
|
|
|
_make_test_img -o "compat=1.1,lazy_refcounts=on" 64M
|
2018-02-05 15:33:38 +01:00
|
|
|
$QEMU_IO -c "write -z 0 128k" "$TEST_IMG" | _filter_qemu_io
|
|
|
|
|
$QEMU_IO -c "write -z 32M 128k" "$TEST_IMG" | _filter_qemu_io
|
|
|
|
|
$QEMU_IO -c map "$TEST_IMG" | _filter_qemu_io
|
2021-12-23 17:01:39 +01:00
|
|
|
_qcow2_dump_header
|
2018-02-05 15:33:38 +01:00
|
|
|
$QEMU_IMG amend -o "compat=0.10" --image-opts \
|
|
|
|
|
driver=qcow2,file.filename=$TEST_IMG,l2-cache-entry-size=4096
|
2021-12-23 17:01:39 +01:00
|
|
|
_qcow2_dump_header
|
2018-02-05 15:33:38 +01:00
|
|
|
$QEMU_IO -c "read -P 0 0 128k" "$TEST_IMG" | _filter_qemu_io
|
|
|
|
|
$QEMU_IO -c "read -P 0 32M 128k" "$TEST_IMG" | _filter_qemu_io
|
|
|
|
|
$QEMU_IO -c map "$TEST_IMG" | _filter_qemu_io
|
|
|
|
|
_check_test_img
|
|
|
|
|
|
2013-09-03 10:09:55 +02:00
|
|
|
echo
|
|
|
|
|
echo "=== Testing dirty version downgrade ==="
|
|
|
|
|
echo
|
2019-11-07 17:36:57 +01:00
|
|
|
_make_test_img -o "compat=1.1,lazy_refcounts=on" 64M
|
2019-09-04 11:11:20 +02:00
|
|
|
_NO_VALGRIND \
|
2015-09-28 16:23:00 +02:00
|
|
|
$QEMU_IO -c "write -P 0x2a 0 128k" -c flush \
|
|
|
|
|
-c "sigraise $(kill -l KILL)" "$TEST_IMG" 2>&1 | _filter_qemu_io
|
2021-12-23 17:01:39 +01:00
|
|
|
_qcow2_dump_header
|
2013-09-03 10:09:55 +02:00
|
|
|
$QEMU_IMG amend -o "compat=0.10" "$TEST_IMG"
|
2021-12-23 17:01:39 +01:00
|
|
|
_qcow2_dump_header
|
2013-09-03 10:09:55 +02:00
|
|
|
$QEMU_IO -c "read -P 0x2a 0 128k" "$TEST_IMG" | _filter_qemu_io
|
|
|
|
|
_check_test_img
|
|
|
|
|
|
|
|
|
|
echo
|
|
|
|
|
echo "=== Testing version downgrade with unknown compat/autoclear flags ==="
|
|
|
|
|
echo
|
2019-11-07 17:36:57 +01:00
|
|
|
_make_test_img -o "compat=1.1" 64M
|
2014-05-24 23:24:58 +02:00
|
|
|
$PYTHON qcow2.py "$TEST_IMG" set-feature-bit compatible 42
|
|
|
|
|
$PYTHON qcow2.py "$TEST_IMG" set-feature-bit autoclear 42
|
2021-12-23 17:01:39 +01:00
|
|
|
_qcow2_dump_header
|
2013-09-03 10:09:55 +02:00
|
|
|
$QEMU_IMG amend -o "compat=0.10" "$TEST_IMG"
|
2021-12-23 17:01:39 +01:00
|
|
|
_qcow2_dump_header
|
2013-09-03 10:09:55 +02:00
|
|
|
_check_test_img
|
|
|
|
|
|
|
|
|
|
echo
|
|
|
|
|
echo "=== Testing version upgrade and resize ==="
|
|
|
|
|
echo
|
2019-11-07 17:36:57 +01:00
|
|
|
_make_test_img -o "compat=0.10" 64M
|
2013-09-03 10:09:55 +02:00
|
|
|
$QEMU_IO -c "write -P 0x2a 42M 64k" "$TEST_IMG" | _filter_qemu_io
|
2021-12-23 17:01:39 +01:00
|
|
|
_qcow2_dump_header
|
2013-09-03 10:09:55 +02:00
|
|
|
$QEMU_IMG amend -o "compat=1.1,lazy_refcounts=on,size=128M" "$TEST_IMG"
|
2021-12-23 17:01:39 +01:00
|
|
|
_qcow2_dump_header
|
2013-09-03 10:09:55 +02:00
|
|
|
$QEMU_IO -c "read -P 0x2a 42M 64k" "$TEST_IMG" | _filter_qemu_io
|
|
|
|
|
_check_test_img
|
|
|
|
|
|
qcow2: Allow resize of images with internal snapshots
We originally refused to allow resize of images with internal
snapshots because the v2 image format did not require the tracking of
snapshot size, making it impossible to safely revert to a snapshot
with a different size than the current view of the image. But the
snapshot size tracking was rectified in v3, and our recent fixes to
qemu-img amend (see 0a85af35) guarantee that we always have a valid
snapshot size. Thus, we no longer need to artificially limit image
resizes, but it does become one more thing that would prevent a
downgrade back to v2. And now that we support different-sized
snapshots, it's also easy to fix reverting to a snapshot to apply the
new size.
Upgrade iotest 61 to cover this (we previously had NO coverage of
refusal to resize while snapshots exist). Note that the amend process
can fail but still have effects: in particular, since we break things
into upgrade, resize, downgrade, a failure during resize does not roll
back changes made during upgrade, nor does failure in downgrade roll
back a resize. But this situation is pre-existing even without this
patch; and without journaling, the best we could do is minimize the
chance of partial failure by collecting all changes prior to doing any
writes - which adds a lot of complexity but could still fail with EIO.
On the other hand, we are careful that even if we have partial
modification but then fail, the image is left viable (that is, we are
careful to sequence things so that after each successful cluster
write, there may be transient leaked clusters but no corrupt
metadata). And complicating the code to make it more transaction-like
is not worth the effort: a user can always request multiple 'qemu-img
amend' changing one thing each, if they need finer-grained control
over detecting the first failure than what they get by letting qemu
decide how to sequence multiple changes.
Signed-off-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Max Reitz <mreitz@redhat.com>
Message-Id: <20200428192648.749066-3-eblake@redhat.com>
Signed-off-by: Max Reitz <mreitz@redhat.com>
2020-04-28 21:26:47 +02:00
|
|
|
echo
|
|
|
|
|
echo "=== Testing resize with snapshots ==="
|
|
|
|
|
echo
|
|
|
|
|
_make_test_img -o "compat=0.10" 32M
|
|
|
|
|
$QEMU_IO -c "write -P 0x2a 24M 64k" "$TEST_IMG" | _filter_qemu_io
|
|
|
|
|
$QEMU_IMG snapshot -c foo "$TEST_IMG"
|
|
|
|
|
$QEMU_IMG resize "$TEST_IMG" 64M &&
|
|
|
|
|
echo "unexpected pass"
|
2021-12-23 17:01:39 +01:00
|
|
|
_qcow2_dump_header | grep '^\(version\|size\|nb_snap\)'
|
qcow2: Allow resize of images with internal snapshots
We originally refused to allow resize of images with internal
snapshots because the v2 image format did not require the tracking of
snapshot size, making it impossible to safely revert to a snapshot
with a different size than the current view of the image. But the
snapshot size tracking was rectified in v3, and our recent fixes to
qemu-img amend (see 0a85af35) guarantee that we always have a valid
snapshot size. Thus, we no longer need to artificially limit image
resizes, but it does become one more thing that would prevent a
downgrade back to v2. And now that we support different-sized
snapshots, it's also easy to fix reverting to a snapshot to apply the
new size.
Upgrade iotest 61 to cover this (we previously had NO coverage of
refusal to resize while snapshots exist). Note that the amend process
can fail but still have effects: in particular, since we break things
into upgrade, resize, downgrade, a failure during resize does not roll
back changes made during upgrade, nor does failure in downgrade roll
back a resize. But this situation is pre-existing even without this
patch; and without journaling, the best we could do is minimize the
chance of partial failure by collecting all changes prior to doing any
writes - which adds a lot of complexity but could still fail with EIO.
On the other hand, we are careful that even if we have partial
modification but then fail, the image is left viable (that is, we are
careful to sequence things so that after each successful cluster
write, there may be transient leaked clusters but no corrupt
metadata). And complicating the code to make it more transaction-like
is not worth the effort: a user can always request multiple 'qemu-img
amend' changing one thing each, if they need finer-grained control
over detecting the first failure than what they get by letting qemu
decide how to sequence multiple changes.
Signed-off-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Max Reitz <mreitz@redhat.com>
Message-Id: <20200428192648.749066-3-eblake@redhat.com>
Signed-off-by: Max Reitz <mreitz@redhat.com>
2020-04-28 21:26:47 +02:00
|
|
|
|
|
|
|
|
$QEMU_IMG amend -o "compat=1.1,size=128M" "$TEST_IMG" ||
|
|
|
|
|
echo "unexpected fail"
|
2021-12-23 17:01:39 +01:00
|
|
|
_qcow2_dump_header | grep '^\(version\|size\|nb_snap\)'
|
qcow2: Allow resize of images with internal snapshots
We originally refused to allow resize of images with internal
snapshots because the v2 image format did not require the tracking of
snapshot size, making it impossible to safely revert to a snapshot
with a different size than the current view of the image. But the
snapshot size tracking was rectified in v3, and our recent fixes to
qemu-img amend (see 0a85af35) guarantee that we always have a valid
snapshot size. Thus, we no longer need to artificially limit image
resizes, but it does become one more thing that would prevent a
downgrade back to v2. And now that we support different-sized
snapshots, it's also easy to fix reverting to a snapshot to apply the
new size.
Upgrade iotest 61 to cover this (we previously had NO coverage of
refusal to resize while snapshots exist). Note that the amend process
can fail but still have effects: in particular, since we break things
into upgrade, resize, downgrade, a failure during resize does not roll
back changes made during upgrade, nor does failure in downgrade roll
back a resize. But this situation is pre-existing even without this
patch; and without journaling, the best we could do is minimize the
chance of partial failure by collecting all changes prior to doing any
writes - which adds a lot of complexity but could still fail with EIO.
On the other hand, we are careful that even if we have partial
modification but then fail, the image is left viable (that is, we are
careful to sequence things so that after each successful cluster
write, there may be transient leaked clusters but no corrupt
metadata). And complicating the code to make it more transaction-like
is not worth the effort: a user can always request multiple 'qemu-img
amend' changing one thing each, if they need finer-grained control
over detecting the first failure than what they get by letting qemu
decide how to sequence multiple changes.
Signed-off-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Max Reitz <mreitz@redhat.com>
Message-Id: <20200428192648.749066-3-eblake@redhat.com>
Signed-off-by: Max Reitz <mreitz@redhat.com>
2020-04-28 21:26:47 +02:00
|
|
|
|
|
|
|
|
$QEMU_IMG snapshot -c bar "$TEST_IMG"
|
|
|
|
|
$QEMU_IMG resize --shrink "$TEST_IMG" 64M ||
|
|
|
|
|
echo "unexpected fail"
|
2021-12-23 17:01:39 +01:00
|
|
|
_qcow2_dump_header | grep '^\(version\|size\|nb_snap\)'
|
qcow2: Allow resize of images with internal snapshots
We originally refused to allow resize of images with internal
snapshots because the v2 image format did not require the tracking of
snapshot size, making it impossible to safely revert to a snapshot
with a different size than the current view of the image. But the
snapshot size tracking was rectified in v3, and our recent fixes to
qemu-img amend (see 0a85af35) guarantee that we always have a valid
snapshot size. Thus, we no longer need to artificially limit image
resizes, but it does become one more thing that would prevent a
downgrade back to v2. And now that we support different-sized
snapshots, it's also easy to fix reverting to a snapshot to apply the
new size.
Upgrade iotest 61 to cover this (we previously had NO coverage of
refusal to resize while snapshots exist). Note that the amend process
can fail but still have effects: in particular, since we break things
into upgrade, resize, downgrade, a failure during resize does not roll
back changes made during upgrade, nor does failure in downgrade roll
back a resize. But this situation is pre-existing even without this
patch; and without journaling, the best we could do is minimize the
chance of partial failure by collecting all changes prior to doing any
writes - which adds a lot of complexity but could still fail with EIO.
On the other hand, we are careful that even if we have partial
modification but then fail, the image is left viable (that is, we are
careful to sequence things so that after each successful cluster
write, there may be transient leaked clusters but no corrupt
metadata). And complicating the code to make it more transaction-like
is not worth the effort: a user can always request multiple 'qemu-img
amend' changing one thing each, if they need finer-grained control
over detecting the first failure than what they get by letting qemu
decide how to sequence multiple changes.
Signed-off-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Max Reitz <mreitz@redhat.com>
Message-Id: <20200428192648.749066-3-eblake@redhat.com>
Signed-off-by: Max Reitz <mreitz@redhat.com>
2020-04-28 21:26:47 +02:00
|
|
|
|
|
|
|
|
$QEMU_IMG amend -o "compat=0.10,size=32M" "$TEST_IMG" &&
|
|
|
|
|
echo "unexpected pass"
|
2021-12-23 17:01:39 +01:00
|
|
|
_qcow2_dump_header | grep '^\(version\|size\|nb_snap\)'
|
qcow2: Allow resize of images with internal snapshots
We originally refused to allow resize of images with internal
snapshots because the v2 image format did not require the tracking of
snapshot size, making it impossible to safely revert to a snapshot
with a different size than the current view of the image. But the
snapshot size tracking was rectified in v3, and our recent fixes to
qemu-img amend (see 0a85af35) guarantee that we always have a valid
snapshot size. Thus, we no longer need to artificially limit image
resizes, but it does become one more thing that would prevent a
downgrade back to v2. And now that we support different-sized
snapshots, it's also easy to fix reverting to a snapshot to apply the
new size.
Upgrade iotest 61 to cover this (we previously had NO coverage of
refusal to resize while snapshots exist). Note that the amend process
can fail but still have effects: in particular, since we break things
into upgrade, resize, downgrade, a failure during resize does not roll
back changes made during upgrade, nor does failure in downgrade roll
back a resize. But this situation is pre-existing even without this
patch; and without journaling, the best we could do is minimize the
chance of partial failure by collecting all changes prior to doing any
writes - which adds a lot of complexity but could still fail with EIO.
On the other hand, we are careful that even if we have partial
modification but then fail, the image is left viable (that is, we are
careful to sequence things so that after each successful cluster
write, there may be transient leaked clusters but no corrupt
metadata). And complicating the code to make it more transaction-like
is not worth the effort: a user can always request multiple 'qemu-img
amend' changing one thing each, if they need finer-grained control
over detecting the first failure than what they get by letting qemu
decide how to sequence multiple changes.
Signed-off-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Max Reitz <mreitz@redhat.com>
Message-Id: <20200428192648.749066-3-eblake@redhat.com>
Signed-off-by: Max Reitz <mreitz@redhat.com>
2020-04-28 21:26:47 +02:00
|
|
|
|
|
|
|
|
$QEMU_IMG snapshot -a bar "$TEST_IMG" ||
|
|
|
|
|
echo "unexpected fail"
|
2021-12-23 17:01:39 +01:00
|
|
|
_qcow2_dump_header | grep '^\(version\|size\|nb_snap\)'
|
qcow2: Allow resize of images with internal snapshots
We originally refused to allow resize of images with internal
snapshots because the v2 image format did not require the tracking of
snapshot size, making it impossible to safely revert to a snapshot
with a different size than the current view of the image. But the
snapshot size tracking was rectified in v3, and our recent fixes to
qemu-img amend (see 0a85af35) guarantee that we always have a valid
snapshot size. Thus, we no longer need to artificially limit image
resizes, but it does become one more thing that would prevent a
downgrade back to v2. And now that we support different-sized
snapshots, it's also easy to fix reverting to a snapshot to apply the
new size.
Upgrade iotest 61 to cover this (we previously had NO coverage of
refusal to resize while snapshots exist). Note that the amend process
can fail but still have effects: in particular, since we break things
into upgrade, resize, downgrade, a failure during resize does not roll
back changes made during upgrade, nor does failure in downgrade roll
back a resize. But this situation is pre-existing even without this
patch; and without journaling, the best we could do is minimize the
chance of partial failure by collecting all changes prior to doing any
writes - which adds a lot of complexity but could still fail with EIO.
On the other hand, we are careful that even if we have partial
modification but then fail, the image is left viable (that is, we are
careful to sequence things so that after each successful cluster
write, there may be transient leaked clusters but no corrupt
metadata). And complicating the code to make it more transaction-like
is not worth the effort: a user can always request multiple 'qemu-img
amend' changing one thing each, if they need finer-grained control
over detecting the first failure than what they get by letting qemu
decide how to sequence multiple changes.
Signed-off-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Max Reitz <mreitz@redhat.com>
Message-Id: <20200428192648.749066-3-eblake@redhat.com>
Signed-off-by: Max Reitz <mreitz@redhat.com>
2020-04-28 21:26:47 +02:00
|
|
|
|
|
|
|
|
$QEMU_IMG snapshot -d bar "$TEST_IMG"
|
|
|
|
|
$QEMU_IMG amend -o "compat=0.10,size=32M" "$TEST_IMG" ||
|
|
|
|
|
echo "unexpected fail"
|
2021-12-23 17:01:39 +01:00
|
|
|
_qcow2_dump_header | grep '^\(version\|size\|nb_snap\)'
|
qcow2: Allow resize of images with internal snapshots
We originally refused to allow resize of images with internal
snapshots because the v2 image format did not require the tracking of
snapshot size, making it impossible to safely revert to a snapshot
with a different size than the current view of the image. But the
snapshot size tracking was rectified in v3, and our recent fixes to
qemu-img amend (see 0a85af35) guarantee that we always have a valid
snapshot size. Thus, we no longer need to artificially limit image
resizes, but it does become one more thing that would prevent a
downgrade back to v2. And now that we support different-sized
snapshots, it's also easy to fix reverting to a snapshot to apply the
new size.
Upgrade iotest 61 to cover this (we previously had NO coverage of
refusal to resize while snapshots exist). Note that the amend process
can fail but still have effects: in particular, since we break things
into upgrade, resize, downgrade, a failure during resize does not roll
back changes made during upgrade, nor does failure in downgrade roll
back a resize. But this situation is pre-existing even without this
patch; and without journaling, the best we could do is minimize the
chance of partial failure by collecting all changes prior to doing any
writes - which adds a lot of complexity but could still fail with EIO.
On the other hand, we are careful that even if we have partial
modification but then fail, the image is left viable (that is, we are
careful to sequence things so that after each successful cluster
write, there may be transient leaked clusters but no corrupt
metadata). And complicating the code to make it more transaction-like
is not worth the effort: a user can always request multiple 'qemu-img
amend' changing one thing each, if they need finer-grained control
over detecting the first failure than what they get by letting qemu
decide how to sequence multiple changes.
Signed-off-by: Eric Blake <eblake@redhat.com>
Reviewed-by: Max Reitz <mreitz@redhat.com>
Message-Id: <20200428192648.749066-3-eblake@redhat.com>
Signed-off-by: Max Reitz <mreitz@redhat.com>
2020-04-28 21:26:47 +02:00
|
|
|
|
|
|
|
|
_check_test_img
|
|
|
|
|
|
|
|
|
|
|
2013-09-03 10:09:55 +02:00
|
|
|
echo
|
|
|
|
|
echo "=== Testing dirty lazy_refcounts=off ==="
|
|
|
|
|
echo
|
2019-11-07 17:36:57 +01:00
|
|
|
_make_test_img -o "compat=1.1,lazy_refcounts=on" 64M
|
2019-09-04 11:11:20 +02:00
|
|
|
_NO_VALGRIND \
|
2015-09-28 16:23:00 +02:00
|
|
|
$QEMU_IO -c "write -P 0x2a 0 128k" -c flush \
|
|
|
|
|
-c "sigraise $(kill -l KILL)" "$TEST_IMG" 2>&1 | _filter_qemu_io
|
2021-12-23 17:01:39 +01:00
|
|
|
_qcow2_dump_header
|
2013-09-03 10:09:55 +02:00
|
|
|
$QEMU_IMG amend -o "lazy_refcounts=off" "$TEST_IMG"
|
2021-12-23 17:01:39 +01:00
|
|
|
_qcow2_dump_header
|
2013-09-03 10:09:55 +02:00
|
|
|
$QEMU_IO -c "read -P 0x2a 0 128k" "$TEST_IMG" | _filter_qemu_io
|
|
|
|
|
_check_test_img
|
|
|
|
|
|
|
|
|
|
echo
|
|
|
|
|
echo "=== Testing backing file ==="
|
|
|
|
|
echo
|
2019-11-07 17:36:57 +01:00
|
|
|
_make_test_img -o "compat=1.1" 64M
|
|
|
|
|
TEST_IMG="$TEST_IMG.base" _make_test_img -o "compat=1.1" 64M
|
2013-09-03 10:09:55 +02:00
|
|
|
$QEMU_IO -c "write -P 0x2a 0 128k" "$TEST_IMG.base" | _filter_qemu_io
|
|
|
|
|
$QEMU_IO -c "read -P 0 0 128k" "$TEST_IMG" | _filter_qemu_io
|
2021-05-03 23:35:59 +02:00
|
|
|
$QEMU_IMG amend -o "backing_file=$TEST_IMG.base,backing_fmt=qcow2" \
|
|
|
|
|
"$TEST_IMG" && echo "unexpected pass"
|
|
|
|
|
$QEMU_IMG rebase -u -b "$TEST_IMG.base" -F qcow2 "$TEST_IMG"
|
2013-09-03 10:09:55 +02:00
|
|
|
$QEMU_IMG amend -o "backing_file=$TEST_IMG.base,backing_fmt=qcow2" "$TEST_IMG"
|
|
|
|
|
$QEMU_IO -c "read -P 0x2a 0 128k" "$TEST_IMG" | _filter_qemu_io
|
|
|
|
|
_check_test_img
|
|
|
|
|
|
|
|
|
|
echo
|
|
|
|
|
echo "=== Testing invalid configurations ==="
|
|
|
|
|
echo
|
2019-11-07 17:36:57 +01:00
|
|
|
_make_test_img -o "compat=0.10" 64M
|
2013-09-03 10:09:55 +02:00
|
|
|
$QEMU_IMG amend -o "lazy_refcounts=on" "$TEST_IMG"
|
|
|
|
|
$QEMU_IMG amend -o "compat=1.1" "$TEST_IMG" # actually valid
|
|
|
|
|
$QEMU_IMG amend -o "compat=0.10,lazy_refcounts=on" "$TEST_IMG"
|
|
|
|
|
$QEMU_IMG amend -o "compat=0.42" "$TEST_IMG"
|
|
|
|
|
$QEMU_IMG amend -o "foo=bar" "$TEST_IMG"
|
|
|
|
|
$QEMU_IMG amend -o "cluster_size=1k" "$TEST_IMG"
|
|
|
|
|
$QEMU_IMG amend -o "encryption=on" "$TEST_IMG"
|
|
|
|
|
$QEMU_IMG amend -o "preallocation=on" "$TEST_IMG"
|
|
|
|
|
|
|
|
|
|
echo
|
|
|
|
|
echo "=== Testing correct handling of unset value ==="
|
|
|
|
|
echo
|
2019-11-07 17:36:57 +01:00
|
|
|
_make_test_img -o "compat=1.1,cluster_size=1k" 64M
|
2013-09-03 10:09:55 +02:00
|
|
|
echo "Should work:"
|
|
|
|
|
$QEMU_IMG amend -o "lazy_refcounts=on" "$TEST_IMG"
|
|
|
|
|
echo "Should not work:" # Just to know which of these tests actually fails
|
|
|
|
|
$QEMU_IMG amend -o "cluster_size=64k" "$TEST_IMG"
|
|
|
|
|
|
|
|
|
|
echo
|
|
|
|
|
echo "=== Testing zero expansion on inactive clusters ==="
|
|
|
|
|
echo
|
2019-11-07 17:36:57 +01:00
|
|
|
_make_test_img -o "compat=1.1" 64M
|
2013-09-03 10:09:55 +02:00
|
|
|
$QEMU_IO -c "write -z 0 128k" "$TEST_IMG" | _filter_qemu_io
|
|
|
|
|
$QEMU_IMG snapshot -c foo "$TEST_IMG"
|
|
|
|
|
$QEMU_IO -c "write -P 0x2a 0 128k" "$TEST_IMG" | _filter_qemu_io
|
|
|
|
|
$QEMU_IMG amend -o "compat=0.10" "$TEST_IMG"
|
|
|
|
|
_check_test_img
|
|
|
|
|
$QEMU_IO -c "read -P 0x2a 0 128k" "$TEST_IMG" | _filter_qemu_io
|
|
|
|
|
$QEMU_IMG snapshot -a foo "$TEST_IMG"
|
|
|
|
|
_check_test_img
|
|
|
|
|
$QEMU_IO -c "read -P 0 0 128k" "$TEST_IMG" | _filter_qemu_io
|
|
|
|
|
|
2013-09-05 10:55:54 +02:00
|
|
|
echo
|
|
|
|
|
echo "=== Testing zero expansion on shared L2 table ==="
|
|
|
|
|
echo
|
2019-11-07 17:36:57 +01:00
|
|
|
_make_test_img -o "compat=1.1" 64M
|
2013-09-05 10:55:54 +02:00
|
|
|
$QEMU_IO -c "write -z 0 128k" "$TEST_IMG" | _filter_qemu_io
|
|
|
|
|
$QEMU_IMG snapshot -c foo "$TEST_IMG"
|
|
|
|
|
$QEMU_IMG amend -o "compat=0.10" "$TEST_IMG"
|
|
|
|
|
_check_test_img
|
|
|
|
|
$QEMU_IO -c "read -P 0 0 128k" "$TEST_IMG" | _filter_qemu_io
|
|
|
|
|
$QEMU_IMG snapshot -a foo "$TEST_IMG"
|
|
|
|
|
_check_test_img
|
|
|
|
|
$QEMU_IO -c "read -P 0 0 128k" "$TEST_IMG" | _filter_qemu_io
|
|
|
|
|
|
2013-09-03 10:09:55 +02:00
|
|
|
echo
|
|
|
|
|
echo "=== Testing zero expansion on backed image ==="
|
|
|
|
|
echo
|
2019-11-07 17:36:57 +01:00
|
|
|
TEST_IMG="$TEST_IMG.base" _make_test_img -o "compat=1.1" 64M
|
2013-09-03 10:09:55 +02:00
|
|
|
$QEMU_IO -c "write -P 0x2a 0 128k" "$TEST_IMG.base" | _filter_qemu_io
|
iotests: Specify explicit backing format where sensible
There are many existing qcow2 images that specify a backing file but
no format. This has been the source of CVEs in the past, but has
become more prominent of a problem now that libvirt has switched to
-blockdev. With older -drive, at least the probing was always done by
qemu (so the only risk of a changed format between successive boots of
a guest was if qemu was upgraded and probed differently). But with
newer -blockdev, libvirt must specify a format; if libvirt guesses raw
where the image was formatted, this results in data corruption visible
to the guest; conversely, if libvirt guesses qcow2 where qemu was
using raw, this can result in potential security holes, so modern
libvirt instead refuses to use images without explicit backing format.
The change in libvirt to reject images without explicit backing format
has pointed out that a number of tools have been far too reliant on
probing in the past. It's time to set a better example in our own
iotests of properly setting this parameter.
iotest calls to create, rebase, and convert are all impacted to some
degree. It's a bit annoying that we are inconsistent on command line
- while all of those accept -o backing_file=...,backing_fmt=..., the
shortcuts are different: create and rebase have -b and -F, while
convert has -B but no -F. (amend has no shortcuts, but the previous
patch just deprecated the use of amend to change backing chains).
Signed-off-by: Eric Blake <eblake@redhat.com>
Message-Id: <20200706203954.341758-9-eblake@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2020-07-06 22:39:52 +02:00
|
|
|
_make_test_img -o "compat=1.1" -b "$TEST_IMG.base" -F $IMGFMT 64M
|
2013-09-03 10:09:55 +02:00
|
|
|
$QEMU_IO -c "read -P 0x2a 0 128k" -c "write -z 0 64k" "$TEST_IMG" | _filter_qemu_io
|
|
|
|
|
$QEMU_IMG amend -o "compat=0.10" "$TEST_IMG"
|
|
|
|
|
_check_test_img
|
|
|
|
|
$QEMU_IO -c "read -P 0 0 64k" -c "read -P 0x2a 64k 64k" "$TEST_IMG" | _filter_qemu_io
|
|
|
|
|
|
|
|
|
|
echo
|
|
|
|
|
echo "=== Testing zero expansion on backed inactive clusters ==="
|
|
|
|
|
echo
|
2019-11-07 17:36:57 +01:00
|
|
|
TEST_IMG="$TEST_IMG.base" _make_test_img -o "compat=1.1" 64M
|
2013-09-03 10:09:55 +02:00
|
|
|
$QEMU_IO -c "write -P 0x2a 0 128k" "$TEST_IMG.base" | _filter_qemu_io
|
iotests: Specify explicit backing format where sensible
There are many existing qcow2 images that specify a backing file but
no format. This has been the source of CVEs in the past, but has
become more prominent of a problem now that libvirt has switched to
-blockdev. With older -drive, at least the probing was always done by
qemu (so the only risk of a changed format between successive boots of
a guest was if qemu was upgraded and probed differently). But with
newer -blockdev, libvirt must specify a format; if libvirt guesses raw
where the image was formatted, this results in data corruption visible
to the guest; conversely, if libvirt guesses qcow2 where qemu was
using raw, this can result in potential security holes, so modern
libvirt instead refuses to use images without explicit backing format.
The change in libvirt to reject images without explicit backing format
has pointed out that a number of tools have been far too reliant on
probing in the past. It's time to set a better example in our own
iotests of properly setting this parameter.
iotest calls to create, rebase, and convert are all impacted to some
degree. It's a bit annoying that we are inconsistent on command line
- while all of those accept -o backing_file=...,backing_fmt=..., the
shortcuts are different: create and rebase have -b and -F, while
convert has -B but no -F. (amend has no shortcuts, but the previous
patch just deprecated the use of amend to change backing chains).
Signed-off-by: Eric Blake <eblake@redhat.com>
Message-Id: <20200706203954.341758-9-eblake@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2020-07-06 22:39:52 +02:00
|
|
|
_make_test_img -o "compat=1.1" -b "$TEST_IMG.base" -F $IMGFMT 64M
|
2013-09-03 10:09:55 +02:00
|
|
|
$QEMU_IO -c "write -z 0 64k" "$TEST_IMG" | _filter_qemu_io
|
|
|
|
|
$QEMU_IMG snapshot -c foo "$TEST_IMG"
|
|
|
|
|
$QEMU_IO -c "write -P 0x42 0 128k" "$TEST_IMG" | _filter_qemu_io
|
|
|
|
|
$QEMU_IMG amend -o "compat=0.10" "$TEST_IMG"
|
|
|
|
|
_check_test_img
|
|
|
|
|
$QEMU_IO -c "read -P 0x42 0 128k" "$TEST_IMG" | _filter_qemu_io
|
|
|
|
|
$QEMU_IMG snapshot -a foo "$TEST_IMG"
|
|
|
|
|
_check_test_img
|
|
|
|
|
$QEMU_IO -c "read -P 0 0 64k" -c "read -P 0x2a 64k 64k" "$TEST_IMG" | _filter_qemu_io
|
|
|
|
|
|
2013-09-05 10:55:54 +02:00
|
|
|
echo
|
|
|
|
|
echo "=== Testing zero expansion on backed image with shared L2 table ==="
|
|
|
|
|
echo
|
2019-11-07 17:36:57 +01:00
|
|
|
TEST_IMG="$TEST_IMG.base" _make_test_img -o "compat=1.1" 64M
|
2013-09-05 10:55:54 +02:00
|
|
|
$QEMU_IO -c "write -P 0x2a 0 128k" "$TEST_IMG.base" | _filter_qemu_io
|
iotests: Specify explicit backing format where sensible
There are many existing qcow2 images that specify a backing file but
no format. This has been the source of CVEs in the past, but has
become more prominent of a problem now that libvirt has switched to
-blockdev. With older -drive, at least the probing was always done by
qemu (so the only risk of a changed format between successive boots of
a guest was if qemu was upgraded and probed differently). But with
newer -blockdev, libvirt must specify a format; if libvirt guesses raw
where the image was formatted, this results in data corruption visible
to the guest; conversely, if libvirt guesses qcow2 where qemu was
using raw, this can result in potential security holes, so modern
libvirt instead refuses to use images without explicit backing format.
The change in libvirt to reject images without explicit backing format
has pointed out that a number of tools have been far too reliant on
probing in the past. It's time to set a better example in our own
iotests of properly setting this parameter.
iotest calls to create, rebase, and convert are all impacted to some
degree. It's a bit annoying that we are inconsistent on command line
- while all of those accept -o backing_file=...,backing_fmt=..., the
shortcuts are different: create and rebase have -b and -F, while
convert has -B but no -F. (amend has no shortcuts, but the previous
patch just deprecated the use of amend to change backing chains).
Signed-off-by: Eric Blake <eblake@redhat.com>
Message-Id: <20200706203954.341758-9-eblake@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2020-07-06 22:39:52 +02:00
|
|
|
_make_test_img -o "compat=1.1" -b "$TEST_IMG.base" -F $IMGFMT 64M
|
2013-09-05 10:55:54 +02:00
|
|
|
$QEMU_IO -c "write -z 0 128k" "$TEST_IMG" | _filter_qemu_io
|
|
|
|
|
$QEMU_IMG snapshot -c foo "$TEST_IMG"
|
|
|
|
|
$QEMU_IMG amend -o "compat=0.10" "$TEST_IMG"
|
|
|
|
|
_check_test_img
|
|
|
|
|
$QEMU_IO -c "read -P 0 0 128k" "$TEST_IMG" | _filter_qemu_io
|
|
|
|
|
$QEMU_IMG snapshot -a foo "$TEST_IMG"
|
|
|
|
|
_check_test_img
|
|
|
|
|
$QEMU_IO -c "read -P 0 0 128k" "$TEST_IMG" | _filter_qemu_io
|
|
|
|
|
|
2013-09-25 12:07:23 +02:00
|
|
|
echo
|
|
|
|
|
echo "=== Testing preallocated zero expansion on full image ==="
|
|
|
|
|
echo
|
2019-11-07 17:36:57 +01:00
|
|
|
TEST_IMG="$TEST_IMG" _make_test_img -o "compat=1.1" 64M
|
2013-09-25 12:07:23 +02:00
|
|
|
$QEMU_IO -c "write -P 0x2a 0 64M" "$TEST_IMG" -c "write -z 0 64M" | _filter_qemu_io
|
|
|
|
|
$QEMU_IMG amend -o "compat=0.10" "$TEST_IMG"
|
|
|
|
|
_check_test_img
|
|
|
|
|
$QEMU_IO -c "read -P 0 0 64M" "$TEST_IMG" | _filter_qemu_io
|
|
|
|
|
|
2014-10-27 11:12:56 +01:00
|
|
|
echo
|
|
|
|
|
echo "=== Testing progress report without snapshot ==="
|
|
|
|
|
echo
|
2019-11-07 17:36:57 +01:00
|
|
|
TEST_IMG="$TEST_IMG.base" _make_test_img -o "compat=1.1" 4G
|
iotests: Specify explicit backing format where sensible
There are many existing qcow2 images that specify a backing file but
no format. This has been the source of CVEs in the past, but has
become more prominent of a problem now that libvirt has switched to
-blockdev. With older -drive, at least the probing was always done by
qemu (so the only risk of a changed format between successive boots of
a guest was if qemu was upgraded and probed differently). But with
newer -blockdev, libvirt must specify a format; if libvirt guesses raw
where the image was formatted, this results in data corruption visible
to the guest; conversely, if libvirt guesses qcow2 where qemu was
using raw, this can result in potential security holes, so modern
libvirt instead refuses to use images without explicit backing format.
The change in libvirt to reject images without explicit backing format
has pointed out that a number of tools have been far too reliant on
probing in the past. It's time to set a better example in our own
iotests of properly setting this parameter.
iotest calls to create, rebase, and convert are all impacted to some
degree. It's a bit annoying that we are inconsistent on command line
- while all of those accept -o backing_file=...,backing_fmt=..., the
shortcuts are different: create and rebase have -b and -F, while
convert has -B but no -F. (amend has no shortcuts, but the previous
patch just deprecated the use of amend to change backing chains).
Signed-off-by: Eric Blake <eblake@redhat.com>
Message-Id: <20200706203954.341758-9-eblake@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2020-07-06 22:39:52 +02:00
|
|
|
_make_test_img -o "compat=1.1" -b "$TEST_IMG.base" -F $IMGFMT 4G
|
2014-10-27 11:12:56 +01:00
|
|
|
$QEMU_IO -c "write -z 0 64k" \
|
|
|
|
|
-c "write -z 1G 64k" \
|
|
|
|
|
-c "write -z 2G 64k" \
|
|
|
|
|
-c "write -z 3G 64k" "$TEST_IMG" | _filter_qemu_io
|
|
|
|
|
$QEMU_IMG amend -p -o "compat=0.10" "$TEST_IMG"
|
|
|
|
|
_check_test_img
|
|
|
|
|
|
|
|
|
|
echo
|
|
|
|
|
echo "=== Testing progress report with snapshot ==="
|
|
|
|
|
echo
|
2019-11-07 17:36:57 +01:00
|
|
|
TEST_IMG="$TEST_IMG.base" _make_test_img -o "compat=1.1" 4G
|
iotests: Specify explicit backing format where sensible
There are many existing qcow2 images that specify a backing file but
no format. This has been the source of CVEs in the past, but has
become more prominent of a problem now that libvirt has switched to
-blockdev. With older -drive, at least the probing was always done by
qemu (so the only risk of a changed format between successive boots of
a guest was if qemu was upgraded and probed differently). But with
newer -blockdev, libvirt must specify a format; if libvirt guesses raw
where the image was formatted, this results in data corruption visible
to the guest; conversely, if libvirt guesses qcow2 where qemu was
using raw, this can result in potential security holes, so modern
libvirt instead refuses to use images without explicit backing format.
The change in libvirt to reject images without explicit backing format
has pointed out that a number of tools have been far too reliant on
probing in the past. It's time to set a better example in our own
iotests of properly setting this parameter.
iotest calls to create, rebase, and convert are all impacted to some
degree. It's a bit annoying that we are inconsistent on command line
- while all of those accept -o backing_file=...,backing_fmt=..., the
shortcuts are different: create and rebase have -b and -F, while
convert has -B but no -F. (amend has no shortcuts, but the previous
patch just deprecated the use of amend to change backing chains).
Signed-off-by: Eric Blake <eblake@redhat.com>
Message-Id: <20200706203954.341758-9-eblake@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2020-07-06 22:39:52 +02:00
|
|
|
_make_test_img -o "compat=1.1" -b "$TEST_IMG.base" -F $IMGFMT 4G
|
2014-10-27 11:12:56 +01:00
|
|
|
$QEMU_IO -c "write -z 0 64k" \
|
|
|
|
|
-c "write -z 1G 64k" \
|
|
|
|
|
-c "write -z 2G 64k" \
|
|
|
|
|
-c "write -z 3G 64k" "$TEST_IMG" | _filter_qemu_io
|
|
|
|
|
$QEMU_IMG snapshot -c foo "$TEST_IMG"
|
|
|
|
|
$QEMU_IMG amend -p -o "compat=0.10" "$TEST_IMG"
|
|
|
|
|
_check_test_img
|
|
|
|
|
|
2019-02-26 15:00:29 +01:00
|
|
|
echo
|
|
|
|
|
echo "=== Testing version downgrade with external data file ==="
|
|
|
|
|
echo
|
2019-11-07 17:36:57 +01:00
|
|
|
_make_test_img -o "compat=1.1,data_file=$TEST_IMG.data" 64M
|
2019-02-26 15:00:29 +01:00
|
|
|
$QEMU_IMG amend -o "compat=0.10" "$TEST_IMG"
|
|
|
|
|
_img_info --format-specific
|
|
|
|
|
_check_test_img
|
|
|
|
|
|
2020-07-10 18:13:15 +02:00
|
|
|
echo
|
|
|
|
|
echo "=== Testing version downgrade with extended L2 entries ==="
|
|
|
|
|
echo
|
|
|
|
|
_make_test_img -o "compat=1.1,extended_l2=on" 64M
|
|
|
|
|
$QEMU_IMG amend -o "compat=0.10" "$TEST_IMG"
|
|
|
|
|
|
2019-02-26 15:00:29 +01:00
|
|
|
echo
|
|
|
|
|
echo "=== Try changing the external data file ==="
|
|
|
|
|
echo
|
2019-11-07 17:36:57 +01:00
|
|
|
_make_test_img -o "compat=1.1" 64M
|
2019-02-26 15:00:29 +01:00
|
|
|
$QEMU_IMG amend -o "data_file=foo" "$TEST_IMG"
|
|
|
|
|
|
|
|
|
|
echo
|
2019-11-07 17:36:57 +01:00
|
|
|
_make_test_img -o "compat=1.1,data_file=$TEST_IMG.data" 64M
|
2019-02-26 15:00:29 +01:00
|
|
|
$QEMU_IMG amend -o "data_file=foo" "$TEST_IMG"
|
|
|
|
|
_img_info --format-specific
|
|
|
|
|
TEST_IMG="data-file.filename=$TEST_IMG.data,file.filename=$TEST_IMG" _img_info --format-specific --image-opts
|
|
|
|
|
|
|
|
|
|
echo
|
|
|
|
|
$QEMU_IMG amend -o "data_file=" --image-opts "data-file.filename=$TEST_IMG.data,file.filename=$TEST_IMG"
|
|
|
|
|
_img_info --format-specific
|
|
|
|
|
TEST_IMG="data-file.filename=$TEST_IMG.data,file.filename=$TEST_IMG" _img_info --format-specific --image-opts
|
|
|
|
|
|
|
|
|
|
echo
|
|
|
|
|
echo "=== Clearing and setting data-file-raw ==="
|
|
|
|
|
echo
|
2019-11-07 17:36:57 +01:00
|
|
|
_make_test_img -o "compat=1.1,data_file=$TEST_IMG.data,data_file_raw=on" 64M
|
2019-02-26 15:00:29 +01:00
|
|
|
$QEMU_IMG amend -o "data_file_raw=on" "$TEST_IMG"
|
|
|
|
|
_img_info --format-specific
|
|
|
|
|
_check_test_img
|
|
|
|
|
|
|
|
|
|
$QEMU_IMG amend -o "data_file_raw=off" "$TEST_IMG"
|
|
|
|
|
_img_info --format-specific
|
|
|
|
|
_check_test_img
|
|
|
|
|
|
|
|
|
|
$QEMU_IMG amend -o "data_file_raw=on" "$TEST_IMG"
|
|
|
|
|
_img_info --format-specific
|
|
|
|
|
_check_test_img
|
|
|
|
|
|
|
|
|
|
|
2013-09-03 10:09:55 +02:00
|
|
|
# success, all done
|
|
|
|
|
echo "*** done"
|
|
|
|
|
rm -f $seq.full
|
|
|
|
|
status=0
|
