Tests 080, 130, 137, and 176 simply do not work with compat=0.10 for the
reasons stated there.

177 is a bit more interesting:  Originally, it was actually very much
intended to work with compat=0.10 (it even had a special case for that).
However, it now prints the test image's map twice, and short of just not
doing that, there is no solution I can imagine that is both simple and
would leave compat=0.10 support intact.

Signed-off-by: Max Reitz <mreitz@redhat.com>
---
 tests/qemu-iotests/080 |  5 +++--
 tests/qemu-iotests/130 |  2 ++
 tests/qemu-iotests/137 |  2 ++
 tests/qemu-iotests/176 |  2 ++
 tests/qemu-iotests/177 | 13 +++----------
 5 files changed, 12 insertions(+), 12 deletions(-)

diff --git a/tests/qemu-iotests/080 b/tests/qemu-iotests/080
index 55044c700b..1c2bd85742 100755
--- a/tests/qemu-iotests/080
+++ b/tests/qemu-iotests/080
@@ -41,8 +41,9 @@ trap "_cleanup; exit \$status" 0 1 2 3 15
 _supported_fmt qcow2
 _supported_proto file
 _supported_os Linux
-# Internal snapshots are (currently) impossible with refcount_bits=1
-_unsupported_imgopts 'refcount_bits=1[^0-9]'
+# - Internal snapshots are (currently) impossible with refcount_bits=1
+# - This is generally a test for compat=1.1 images
+_unsupported_imgopts 'refcount_bits=1[^0-9]' 'compat=0.10'
 
 header_size=104
 
diff --git a/tests/qemu-iotests/130 b/tests/qemu-iotests/130
index e7e43de6d6..2c4b94da1b 100755
--- a/tests/qemu-iotests/130
+++ b/tests/qemu-iotests/130
@@ -45,6 +45,8 @@ _supported_fmt qcow2
 _supported_proto generic
 _unsupported_proto vxhs
 _supported_os Linux
+# We are going to use lazy-refcounts
+_unsupported_imgopts 'compat=0.10'
 
 qemu_comm_method="monitor"
 
diff --git a/tests/qemu-iotests/137 b/tests/qemu-iotests/137
index eb91e517d7..5a01250005 100755
--- a/tests/qemu-iotests/137
+++ b/tests/qemu-iotests/137
@@ -41,6 +41,8 @@ trap "_cleanup; exit \$status" 0 1 2 3 15
 _supported_fmt qcow2
 _supported_proto file
 _supported_os Linux
+# We are going to use lazy-refcounts
+_unsupported_imgopts 'compat=0.10'
 
 
 _make_test_img 64M
diff --git a/tests/qemu-iotests/176 b/tests/qemu-iotests/176
index b8dc17c592..d38b3aeb91 100755
--- a/tests/qemu-iotests/176
+++ b/tests/qemu-iotests/176
@@ -48,6 +48,8 @@ trap "_cleanup; exit \$status" 0 1 2 3 15
 _supported_fmt qcow2
 _supported_proto file
 _supported_os Linux
+# Persistent dirty bitmaps require compat=1.1
+_unsupported_imgopts 'compat=0.10'
 
 function run_qemu()
 {
diff --git a/tests/qemu-iotests/177 b/tests/qemu-iotests/177
index 28990977f1..86cf25f855 100755
--- a/tests/qemu-iotests/177
+++ b/tests/qemu-iotests/177
@@ -39,6 +39,8 @@ trap "_cleanup; exit \$status" 0 1 2 3 15
 
 _supported_fmt qcow2
 _supported_proto file
+# This test assumes that discard leaves zero clusters
+_unsupported_imgopts 'compat=0.10'
 
 CLUSTER_SIZE=1M
 size=128M
@@ -93,15 +95,6 @@ echo "== verify image content =="
 
 function verify_io()
 {
-    if ($QEMU_IMG info -f "$IMGFMT" "$TEST_IMG" |
-	    grep "compat: 0.10" > /dev/null); then
-        # For v2 images, discarded clusters are read from the backing file
-        discarded=11
-    else
-        # Discarded clusters are zeroed for v3 or later
-        discarded=0
-    fi
-
     echo read -P 22 0 1000
     echo read -P 33 1000 128k
     echo read -P 22 132072 7871512
@@ -109,7 +102,7 @@ function verify_io()
     echo read -P 22 10096640 23457792
     echo read -P 0 32M 32M
     echo read -P 22 64M 13M
-    echo read -P $discarded 77M 29M
+    echo read -P 0 77M 29M
     echo read -P 22 106M 4M
     echo read -P 11 110M 18M
 }
-- 
2.13.6

On 11/22/2017 09:08 PM, Max Reitz wrote:
> Tests 080, 130, 137, and 176 simply do not work with compat=0.10 for the
> reasons stated there.
> 
> 177 is a bit more interesting:  Originally, it was actually very much
> intended to work with compat=0.10 (it even had a special case for that).
> However, it now prints the test image's map twice, and short of just not
> doing that, there is no solution I can imagine that is both simple and
> would leave compat=0.10 support intact.
> 

So we lost that support in
f0a9c18f9e7
and
81c219ac6ce

Eric, any input before we downscope your test?

> Signed-off-by: Max Reitz <mreitz@redhat.com>

Without agonizing over it, I don't see an easy win either, so:

Reviewed-by: John Snow <jsnow@redhat.com>

(but it is a shame to lose the ability to test it.)

On 12/08/2017 07:46 PM, John Snow wrote:
> 
> 
> On 11/22/2017 09:08 PM, Max Reitz wrote:
>> Tests 080, 130, 137, and 176 simply do not work with compat=0.10 for the
>> reasons stated there.
>>
>> 177 is a bit more interesting:  Originally, it was actually very much
>> intended to work with compat=0.10 (it even had a special case for that).
>> However, it now prints the test image's map twice, and short of just not
>> doing that, there is no solution I can imagine that is both simple and
>> would leave compat=0.10 support intact.
>>
> 
> So we lost that support in
> f0a9c18f9e7
> and
> 81c219ac6ce
> 
> Eric, any input before we downscope your test?

Ouch, I broke my own test.

Maybe the best thing would be to split 177 into two tests: the original
test (as it was before f0a9c18) that works on both compats, and a new
test that works on just compat=1.1 images for the things added in later
commits.

Since I'm the author for all commits (so far) to that file, I guess I
can sign up for that work...

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

On 2017-12-09 17:53, Eric Blake wrote:
> On 12/08/2017 07:46 PM, John Snow wrote:
>>
>>
>> On 11/22/2017 09:08 PM, Max Reitz wrote:
>>> Tests 080, 130, 137, and 176 simply do not work with compat=0.10 for the
>>> reasons stated there.
>>>
>>> 177 is a bit more interesting:  Originally, it was actually very much
>>> intended to work with compat=0.10 (it even had a special case for that).
>>> However, it now prints the test image's map twice, and short of just not
>>> doing that, there is no solution I can imagine that is both simple and
>>> would leave compat=0.10 support intact.
>>>
>>
>> So we lost that support in
>> f0a9c18f9e7
>> and
>> 81c219ac6ce
>>
>> Eric, any input before we downscope your test?
> 
> Ouch, I broke my own test.
> 
> Maybe the best thing would be to split 177 into two tests: the original
> test (as it was before f0a9c18) that works on both compats, and a new
> test that works on just compat=1.1 images for the things added in later
> commits.
> 
> Since I'm the author for all commits (so far) to that file, I guess I
> can sign up for that work...

Did you make any progress? :-)

Max

On 01/17/2018 07:41 AM, Max Reitz wrote:

>>> So we lost that support in
>>> f0a9c18f9e7
>>> and
>>> 81c219ac6ce
>>>
>>> Eric, any input before we downscope your test?
>>
>> Ouch, I broke my own test.
>>
>> Maybe the best thing would be to split 177 into two tests: the original
>> test (as it was before f0a9c18) that works on both compats, and a new
>> test that works on just compat=1.1 images for the things added in later
>> commits.
>>
>> Since I'm the author for all commits (so far) to that file, I guess I
>> can sign up for that work...
> 
> Did you make any progress? :-)

Ah, thanks for the reminder.  Posted as
<20180117165420.15946-1-eblake@redhat.com>

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org