[Qemu-devel] [PATCH 0/2] qemu-iotests with sample images, vhdx read test

[Qemu-devel] [PATCH 0/2] qemu-iotests with sample images, vhdx read test

[Jeff Cody]

This provides:

Patch 1/2:  A basic framework for using sample image files.  This is intended
            to be sample images created with the image format native tool; e.g.
            a VHDX image created with Hyper-V.

Patch 2/2:  VHDX read test on a sample image created with Hyper-V.

Jeff Cody (2):
  block: qemu-iotests - add basic ability to use binary sample images
  block: qemu-iotests for vhdx, read sample dynamic image

 tests/qemu-iotests/064                             |  62 +++++++++++++++++++++
 tests/qemu-iotests/064.out                         |  14 +++++
 tests/qemu-iotests/common                          |   6 ++
 tests/qemu-iotests/common.config                   |  11 ++++
 tests/qemu-iotests/common.rc                       |   9 +++
 tests/qemu-iotests/group                           |   1 +
 tests/qemu-iotests/sample_images/MANIFEST          |   7 +++
 tests/qemu-iotests/sample_images/README            |   8 +++
 .../sample_images/iotest-dynamic-1G.vhdx.bz2       | Bin 0 -> 874 bytes
 9 files changed, 118 insertions(+)
 create mode 100755 tests/qemu-iotests/064
 create mode 100644 tests/qemu-iotests/064.out
 create mode 100644 tests/qemu-iotests/sample_images/MANIFEST
 create mode 100644 tests/qemu-iotests/sample_images/README
 create mode 100644 tests/qemu-iotests/sample_images/iotest-dynamic-1G.vhdx.bz2

-- 
1.8.3.1

[Qemu-devel] [PATCH 1/2] block: qemu-iotests - add basic ability to use binary sample images

[Jeff Cody]

For image formats that are not "QEMU native", but supported for
compatibility, it is useful to verify that an image created with
the 'gold standard' native tool can be read / written to successfully
by QEMU.

In addition to testing non-native images, this could also be useful to
test against image files created by older versions of QEMU.

This provides a directory to store small sample images, for use by
scripts in tests/qemu-iotests.

The MANIFEST file should be updated when a new image is added to the
directory, to give some idea about the nature of the image and the
data store therein.

Image files should be compressed with bzip2.

To use a sample image from a bash script, the _use_sample_img function
will copy and decompress the image into $TEST_DIR, and set $TEST_IMG to
be the decompressed sample image copy.  To cleanup, call
_cleanup_test_img as normal.

Signed-off-by: Jeff Cody <jcody@redhat.com>
---
 tests/qemu-iotests/common.config          | 11 +++++++++++
 tests/qemu-iotests/common.rc              |  9 +++++++++
 tests/qemu-iotests/sample_images/MANIFEST |  2 ++
 tests/qemu-iotests/sample_images/README   |  8 ++++++++
 4 files changed, 30 insertions(+)
 create mode 100644 tests/qemu-iotests/sample_images/MANIFEST
 create mode 100644 tests/qemu-iotests/sample_images/README

diff --git a/tests/qemu-iotests/common.config b/tests/qemu-iotests/common.config
index d794e62..d90a8bc 100644
--- a/tests/qemu-iotests/common.config
+++ b/tests/qemu-iotests/common.config
@@ -125,6 +125,17 @@ fi
 
 export TEST_DIR
 
+if [ -z "$SAMPLE_IMG_DIR" ]; then
+        SAMPLE_IMG_DIR=`pwd`/sample_images
+fi
+
+if [ ! -d "$SAMPLE_IMG_DIR" ]; then
+    echo "common.config: Error: \$SAMPLE_IMG_DIR ($SAMPLE_IMG_DIR) is not a directory"
+    exit 1
+fi
+
+export SAMPLE_IMG_DIR
+
 _readlink()
 {
     if [ $# -ne 1 ]; then
diff --git a/tests/qemu-iotests/common.rc b/tests/qemu-iotests/common.rc
index 28b39e4..d52f344 100644
--- a/tests/qemu-iotests/common.rc
+++ b/tests/qemu-iotests/common.rc
@@ -91,6 +91,14 @@ _set_default_imgopts()
     fi
 }
 
+_use_sample_img()
+{
+    cp $SAMPLE_IMG_DIR/"$1" $TEST_DIR
+    bunzip2 $TEST_DIR/"$1"
+    SAMPLE_IMG_FILE="${1%\.bz2}"
+    TEST_IMG=$TEST_DIR/$SAMPLE_IMG_FILE
+}
+
 _make_test_img()
 {
     # extra qemu-img options can be added by tests
@@ -158,6 +166,7 @@ _cleanup_test_img()
             rm -f $TEST_DIR/t.$IMGFMT
             rm -f $TEST_DIR/t.$IMGFMT.orig
             rm -f $TEST_DIR/t.$IMGFMT.base
+            rm -f $TEST_DIR/$SAMPLE_IMG_FILE
             ;;
 
         rbd)
diff --git a/tests/qemu-iotests/sample_images/MANIFEST b/tests/qemu-iotests/sample_images/MANIFEST
new file mode 100644
index 0000000..7abf287
--- /dev/null
+++ b/tests/qemu-iotests/sample_images/MANIFEST
@@ -0,0 +1,2 @@
+   Image Filename           |                  Description
+------------------------------------------------------------------------------
diff --git a/tests/qemu-iotests/sample_images/README b/tests/qemu-iotests/sample_images/README
new file mode 100644
index 0000000..9321b00
--- /dev/null
+++ b/tests/qemu-iotests/sample_images/README
@@ -0,0 +1,8 @@
+This is for small sample images to be used with qemu-iotests, intended for
+non-native formats that QEMU supports for compatibility.  The idea is to use
+the native tool to create the sample image.
+
+For instance, a VHDX image in this directory would be an image created not by
+QEMU itself, but rather created by Hyper-V.
+
+Sample images added here should be described in the MANIFEST file.
-- 
1.8.3.1

Re: [Qemu-devel] [PATCH 1/2] block: qemu-iotests - add basic ability to use binary sample images

[Stefan Hajnoczi]

On Thu, Sep 19, 2013 at 11:48:42PM -0400, Jeff Cody wrote:
> For image formats that are not "QEMU native", but supported for
> compatibility, it is useful to verify that an image created with
> the 'gold standard' native tool can be read / written to successfully
> by QEMU.
> 
> In addition to testing non-native images, this could also be useful to
> test against image files created by older versions of QEMU.
> 
> This provides a directory to store small sample images, for use by
> scripts in tests/qemu-iotests.
> 
> The MANIFEST file should be updated when a new image is added to the
> directory, to give some idea about the nature of the image and the
> data store therein.

I'd drop the MANIFEST because metadata tends to get out-of-sync or is
ignored.  The MANIFEST file can cause patch conflicts.  Test code or the
commit message can describe the contents of the image so I don't see the
need to create another copy of this information.

> diff --git a/tests/qemu-iotests/common.rc b/tests/qemu-iotests/common.rc
> index 28b39e4..d52f344 100644
> --- a/tests/qemu-iotests/common.rc
> +++ b/tests/qemu-iotests/common.rc
> @@ -91,6 +91,14 @@ _set_default_imgopts()
>      fi
>  }
>  
> +_use_sample_img()
> +{
> +    cp $SAMPLE_IMG_DIR/"$1" $TEST_DIR
> +    bunzip2 $TEST_DIR/"$1"

bzcat?  It eliminates the temporary copy.

> @@ -158,6 +166,7 @@ _cleanup_test_img()
>              rm -f $TEST_DIR/t.$IMGFMT
>              rm -f $TEST_DIR/t.$IMGFMT.orig
>              rm -f $TEST_DIR/t.$IMGFMT.base
> +            rm -f $TEST_DIR/$SAMPLE_IMG_FILE

It seems that qemu-iotests doesn't care for paths with spaces.

Re: [Qemu-devel] [PATCH 1/2] block: qemu-iotests - add basic ability to use binary sample images

[Jeff Cody]

On Fri, Sep 20, 2013 at 02:32:26PM +0200, Stefan Hajnoczi wrote:
> On Thu, Sep 19, 2013 at 11:48:42PM -0400, Jeff Cody wrote:
> > For image formats that are not "QEMU native", but supported for
> > compatibility, it is useful to verify that an image created with
> > the 'gold standard' native tool can be read / written to successfully
> > by QEMU.
> > 
> > In addition to testing non-native images, this could also be useful to
> > test against image files created by older versions of QEMU.
> > 
> > This provides a directory to store small sample images, for use by
> > scripts in tests/qemu-iotests.
> > 
> > The MANIFEST file should be updated when a new image is added to the
> > directory, to give some idea about the nature of the image and the
> > data store therein.
> 
> I'd drop the MANIFEST because metadata tends to get out-of-sync or is
> ignored.  The MANIFEST file can cause patch conflicts.  Test code or the
> commit message can describe the contents of the image so I don't see the
> need to create another copy of this information.
>

OK, good point.

> > diff --git a/tests/qemu-iotests/common.rc b/tests/qemu-iotests/common.rc
> > index 28b39e4..d52f344 100644
> > --- a/tests/qemu-iotests/common.rc
> > +++ b/tests/qemu-iotests/common.rc
> > @@ -91,6 +91,14 @@ _set_default_imgopts()
> >      fi
> >  }
> >  
> > +_use_sample_img()
> > +{
> > +    cp $SAMPLE_IMG_DIR/"$1" $TEST_DIR
> > +    bunzip2 $TEST_DIR/"$1"
> 
> bzcat?  It eliminates the temporary copy.
> 

Sure

> > @@ -158,6 +166,7 @@ _cleanup_test_img()
> >              rm -f $TEST_DIR/t.$IMGFMT
> >              rm -f $TEST_DIR/t.$IMGFMT.orig
> >              rm -f $TEST_DIR/t.$IMGFMT.base
> > +            rm -f $TEST_DIR/$SAMPLE_IMG_FILE
> 
> It seems that qemu-iotests doesn't care for paths with spaces.

For v2, I'll go through all the scripts (I think TEST_DIR is used in
some of the 0?? scripts as well) and make sure it is quoted (along
with SAMPLE_IMG_DIR).

Re: [Qemu-devel] [PATCH 1/2] block: qemu-iotests - add basic ability to use binary sample images

[Eric Blake]

[-- Attachment #1: Type: text/plain, Size: 1102 bytes --]

On 09/19/2013 09:48 PM, Jeff Cody wrote:
> For image formats that are not "QEMU native", but supported for
> compatibility, it is useful to verify that an image created with
> the 'gold standard' native tool can be read / written to successfully
> by QEMU.
> 
> In addition to testing non-native images, this could also be useful to
> test against image files created by older versions of QEMU.
> 
> This provides a directory to store small sample images, for use by
> scripts in tests/qemu-iotests.
> 
> The MANIFEST file should be updated when a new image is added to the
> directory, to give some idea about the nature of the image and the
> data store therein.
> 
> Image files should be compressed with bzip2.

Why bzip2?  xz beats bzip2 in both compression ratio and decompression
speed; or if you are worried about portability, gzip is present on more
machines.  bzip2 will probably be around for some time, but it is no
longer the compression engine of choice.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 621 bytes --]

Re: [Qemu-devel] [PATCH 1/2] block: qemu-iotests - add basic ability to use binary sample images

[Jeff Cody]

On Fri, Sep 20, 2013 at 06:46:56AM -0600, Eric Blake wrote:
> On 09/19/2013 09:48 PM, Jeff Cody wrote:
> > For image formats that are not "QEMU native", but supported for
> > compatibility, it is useful to verify that an image created with
> > the 'gold standard' native tool can be read / written to successfully
> > by QEMU.
> > 
> > In addition to testing non-native images, this could also be useful to
> > test against image files created by older versions of QEMU.
> > 
> > This provides a directory to store small sample images, for use by
> > scripts in tests/qemu-iotests.
> > 
> > The MANIFEST file should be updated when a new image is added to the
> > directory, to give some idea about the nature of the image and the
> > data store therein.
> > 
> > Image files should be compressed with bzip2.
> 
> Why bzip2?  xz beats bzip2 in both compression ratio and decompression
> speed; or if you are worried about portability, gzip is present on more
> machines.  bzip2 will probably be around for some time, but it is no
> longer the compression engine of choice.
> 

iotest-dynamic-1G.vhdx compressed with gzip, xv, and bzip2:

gzip:   102548 bytes
xv:      15892 bytes
bzip2:     874 bytes

I think bzip2 is particularly well suited for image files with
hyper-repetitive consecutive bytes due to its use of RLE.  I don't
know that all sample images will have data like that, but chances are
good many will - and even if they don't, bzip2 is not horrible
compared to xz even on normal data.

-Jeff

[Qemu-devel] [PATCH 2/2] block: qemu-iotests for vhdx, read sample dynamic image

[Jeff Cody]

This adds the VHDX format to the qemu-iotests format, and adds
a read test.  The test reads from an existing sample image, that
was created with Hyper-V under Windwos Server 2012.

The image file is a 1GB dynamic image, with 32MB blocks.

The pattern 0xa5 exists from 0MB-33MB (past a block size boundary)

The pattern 0x96 exists from 33MB-66MB (past another block boundary,
and leaving a partial blank block)

>From 66MB-1024MB, all reads should return 0.

Although 1GB dynamic image with 66MB of data, the bzip2'ed image
file size is only 874 bytes.

Signed-off-by: Jeff Cody <jcody@redhat.com>
---
 tests/qemu-iotests/064                             |  62 +++++++++++++++++++++
 tests/qemu-iotests/064.out                         |  14 +++++
 tests/qemu-iotests/common                          |   6 ++
 tests/qemu-iotests/group                           |   1 +
 tests/qemu-iotests/sample_images/MANIFEST          |   5 ++
 .../sample_images/iotest-dynamic-1G.vhdx.bz2       | Bin 0 -> 874 bytes
 6 files changed, 88 insertions(+)
 create mode 100755 tests/qemu-iotests/064
 create mode 100644 tests/qemu-iotests/064.out
 create mode 100644 tests/qemu-iotests/sample_images/iotest-dynamic-1G.vhdx.bz2

diff --git a/tests/qemu-iotests/064 b/tests/qemu-iotests/064
new file mode 100755
index 0000000..6a17bdb
--- /dev/null
+++ b/tests/qemu-iotests/064
@@ -0,0 +1,62 @@
+#!/bin/bash
+#
+# Test VHDX read/write from a sample image created with Hyper-V
+#
+# 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
+owner=jcody@redhat.com
+
+seq=`basename $0`
+echo "QA output created by $seq"
+
+here=`pwd`
+tmp=/tmp/$$
+status=1	# failure is the default!
+
+_cleanup()
+{
+    _cleanup_test_img
+}
+trap "_cleanup; exit \$status" 0 1 2 3 15
+
+# get standard environment, filters and checks
+. ./common.rc
+. ./common.filter
+
+_supported_fmt vhdx
+_supported_proto generic
+_supported_os Linux
+
+_use_sample_img iotest-dynamic-1G.vhdx.bz2
+
+echo
+echo "=== Verify pattern 0xa5, 0 - 33MB ==="
+$QEMU_IO -c "read -pP 0xa5 0 33M" $TEST_IMG | _filter_qemu_io
+
+echo
+echo "=== Verify pattern 0x96, 33M - 66M ==="
+$QEMU_IO -c "read -pP 0x96 33M 33M" $TEST_IMG | _filter_qemu_io
+
+echo
+echo "=== Verify pattern 0x00, 66M - 1024M ==="
+$QEMU_IO -c "read -pP 0x00 66M 958M" $TEST_IMG | _filter_qemu_io
+
+# success, all done
+echo "*** done"
+rm -f $seq.full
+status=0
diff --git a/tests/qemu-iotests/064.out b/tests/qemu-iotests/064.out
new file mode 100644
index 0000000..b9e8e4a
--- /dev/null
+++ b/tests/qemu-iotests/064.out
@@ -0,0 +1,14 @@
+QA output created by 064
+
+=== Verify pattern 0xa5, 0 - 33MB ===
+read 34603008/34603008 bytes at offset 0
+33 MiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
+
+=== Verify pattern 0x96, 33M - 66M ===
+read 34603008/34603008 bytes at offset 34603008
+33 MiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
+
+=== Verify pattern 0x00, 66M - 1024M ===
+read 1004535808/1004535808 bytes at offset 69206016
+958 MiB, X ops; XX:XX:XX.X (XXX YYY/sec and XXX ops/sec)
+*** done
diff --git a/tests/qemu-iotests/common b/tests/qemu-iotests/common
index fecaf85..311c9e4 100644
--- a/tests/qemu-iotests/common
+++ b/tests/qemu-iotests/common
@@ -133,6 +133,7 @@ check options
     -qed                test qed
     -vdi                test vdi
     -vpc                test vpc
+    -vhdx               test vhdx
     -vmdk               test vmdk
     -rbd                test rbd
     -sheepdog           test sheepdog
@@ -195,6 +196,11 @@ testlist options
             xpand=false
             ;;
 
+        -vhdx)
+            IMGFMT=vhdx
+            xpand=false
+            ;;
+
         -rbd)
             IMGPROTO=rbd
             xpand=false
diff --git a/tests/qemu-iotests/group b/tests/qemu-iotests/group
index 1ad02e5..9e950fd 100644
--- a/tests/qemu-iotests/group
+++ b/tests/qemu-iotests/group
@@ -69,3 +69,4 @@
 061 rw auto
 062 rw auto
 063 rw auto
+064 rw auto
diff --git a/tests/qemu-iotests/sample_images/MANIFEST b/tests/qemu-iotests/sample_images/MANIFEST
index 7abf287..6e4a7ef 100644
--- a/tests/qemu-iotests/sample_images/MANIFEST
+++ b/tests/qemu-iotests/sample_images/MANIFEST
@@ -1,2 +1,7 @@
    Image Filename           |                  Description
 ------------------------------------------------------------------------------
+iotest-dynamic-1G.vhdx.bz2  |  1GB dynamic VHDX image with block size of 32 MB.
+                            |  This image file has a pattern of 33MB of 0xa5,
+                            |  followed by 33MB of 0x96, followed by zeroes.
+                            |  Created with Hyper-V on Windows Server 2012.
+                            |
diff --git a/tests/qemu-iotests/sample_images/iotest-dynamic-1G.vhdx.bz2 b/tests/qemu-iotests/sample_images/iotest-dynamic-1G.vhdx.bz2
new file mode 100644
index 0000000000000000000000000000000000000000..77d97a0bae2e45b84ad489a77788084cc09331e0
GIT binary patch
literal 874
zcmV-w1C{(jT4*^jL0KkKS)@Vdf&hZIfB*mY_ijz2|NMXYGlTE%z2+coecwBIyV?7?
zRYF<0^&db2mkJrM&`P9@s2TtO0000000001paz-%27#ae0017K&}e8HN-(1kVrigg
z13&{nXwU!#fB~QY0000000001pg_pcpwKcJX_G+7gwSGQGHB2;7>oqbhyZB84Gbd_
zCQULjF*ML*U`z^<ku<01QIpj3N(ZFK)6~-=)Mx+=JwOB0G|{FZpglkU8fXAC(dh%q
zHq|us0A%$&Lxl0c7NkVLFGMRq07UW*2)3emj1{>kK$s^jUBKR?z~CteOe$Qc!=`MK
zpppgLEo&~>A_R+6h=@Ddl1ZgN7+7*hWL09_s<d&+mMmjjw<LrCx2PjFk~{@nV^|kz
z6;cuaQLw8m>{bL}swE6xrU?On8VxK`u45pSB}p6^9?4@FBo_q60jNQ8)7nwfo~p{X
z21&Hu-QCr>IEs=a0NK%&p{HE(oeD(TehV85d6fuURBs<`t5K&|m^Maoo0fjdi=f}{
z>E$yWvA4r~wZiNcLm<7lTF>T|a9Q1JFM7G$o)?hwxePeOZq}`A`za=Z)W^WEd#*Qp
z#kZ!X0!i<$>Ta+f8L@u+=r$sPWWhg>cfbk7O*y(bhdvqNE8G<%ccZNIDKSnW9b)lr
z?+BB(@#_SGMX@o$bqc@{OqyW;7?h|wi9+N-4D|@7-dVn6g4ihCM|pt2A}N5VGk<5?
z{FoRKTsV)8P`B0_=}2A^fU(eP{;OfF)7siztdO#@z6*HnA0O+ly16Hl#BjL02H~Lm
zU#o1s*F84YWNZGN7x>n4q>?0voA1&{kdPzmvi42q4UHtuzRJ>PzbPk0x?j$@OjIC3
z291dl2@(l)mGJeNMy5-7djC|iYdFpGgRa2BeV-I!Lj_~=H)^bLy>S7`E*Kbz7L6m%
z!pI?M^X|&xFCh=b`Ky@r+f7T@9xGSDdF)KJ&1d`VHFb7cxH1v|W<-)Ch@CnRAp<+?
z+_Yc$iVDdxn#!(cW8fGi)&T|p2nYZGK>!1RnrIY~H<Tz)=_E*(j#5Pu)m2EUIYNaE
zB#I@zVuG?vrm|0*DoOy!8h{0W000C45I_K7m<m%&lp-yPP>8%;$rRy2Ky^V+T-`Z@
A&j0`b

literal 0
HcmV?d00001

-- 
1.8.3.1

Re: [Qemu-devel] [PATCH 2/2] block: qemu-iotests for vhdx, read sample dynamic imagee

[Alex Bennée]

jcody@redhat.com writes:

> This adds the VHDX format to the qemu-iotests format, and adds
> a read test.  The test reads from an existing sample image, that
> was created with Hyper-V under Windwos Server 2012.
>
> The image file is a 1GB dynamic image, with 32MB blocks.
>
> The pattern 0xa5 exists from 0MB-33MB (past a block size boundary)
>
> The pattern 0x96 exists from 33MB-66MB (past another block boundary,
> and leaving a partial blank block)
>
> From 66MB-1024MB, all reads should return 0.
>
> Although 1GB dynamic image with 66MB of data, the bzip2'ed image
> file size is only 874 bytes.

I take it there is additional meta-data in there generated by Windows
Server itself? Otherwise I would be tempted to write a tool to generate
the image on demand so it could be used to trigger other edge cases when
found.

Having said that 874 bytes certainly isn't to heavy a burden for the
repository ;-)

I'm currently pondering what the best way of supporting system images
(i.e. kernel+rootfs) would be to make system regression testing easier.
Unfortunately those images would be far too large to carry in the repo
although there may be some sub-module annex type thing I could try.

-- 
Alex Bennée

Re: [Qemu-devel] [PATCH 2/2] block: qemu-iotests for vhdx, read sample dynamic imagee

[Kevin Wolf]

Am 20.09.2013 um 11:10 hat Alex Bennée geschrieben:
> 
> jcody@redhat.com writes:
> 
> > This adds the VHDX format to the qemu-iotests format, and adds
> > a read test.  The test reads from an existing sample image, that
> > was created with Hyper-V under Windwos Server 2012.
> >
> > The image file is a 1GB dynamic image, with 32MB blocks.
> >
> > The pattern 0xa5 exists from 0MB-33MB (past a block size boundary)
> >
> > The pattern 0x96 exists from 33MB-66MB (past another block boundary,
> > and leaving a partial blank block)
> >
> > From 66MB-1024MB, all reads should return 0.
> >
> > Although 1GB dynamic image with 66MB of data, the bzip2'ed image
> > file size is only 874 bytes.
> 
> I take it there is additional meta-data in there generated by Windows
> Server itself? Otherwise I would be tempted to write a tool to generate
> the image on demand so it could be used to trigger other edge cases when
> found.
> 
> Having said that 874 bytes certainly isn't to heavy a burden for the
> repository ;-)

Eventually, qemu-img will be able to create VHDX images, but I think the
point is that we compare against real Hyper-V VHDX images to ensure that
we're really reading the spec the same way as they do.

> I'm currently pondering what the best way of supporting system images
> (i.e. kernel+rootfs) would be to make system regression testing easier.
> Unfortunately those images would be far too large to carry in the repo
> although there may be some sub-module annex type thing I could try.

Sounds like you're looking for qemu-tests?

    http://git.qemu.org/?p=qemu-test.git;a=summary

Kevin

Re: [Qemu-devel] [PATCH 2/2] block: qemu-iotests for vhdx, read sample dynamic imagee

[Alex Bennée]

kwolf@redhat.com writes:

> Am 20.09.2013 um 11:10 hat Alex Bennée geschrieben:
>> 
>> jcody@redhat.com writes:
>> 
<<snip>> 
>> I'm currently pondering what the best way of supporting system images
>> (i.e. kernel+rootfs) would be to make system regression testing easier.
>> Unfortunately those images would be far too large to carry in the repo
>> although there may be some sub-module annex type thing I could try.
>
> Sounds like you're looking for qemu-tests?
>
>     http://git.qemu.org/?p=qemu-test.git;a=summary

Thanks, Stefan H had already pointed me at that. I'm currently thinking
of painless ways to integrate those sort of tests in the main tree to
further the regression testing stuff I'm looking at.

Anyway I have already diverted enough of topic so I'll save that
discussion for another thread ;-)


-- 
Alex Bennée

Re: [Qemu-devel] [PATCH 2/2] block: qemu-iotests for vhdx, read sample dynamic imagee

[Jeff Cody]

On Fri, Sep 20, 2013 at 11:18:14AM +0200, Kevin Wolf wrote:
> Am 20.09.2013 um 11:10 hat Alex Bennée geschrieben:
> > 
> > jcody@redhat.com writes:
> > 
> > > This adds the VHDX format to the qemu-iotests format, and adds
> > > a read test.  The test reads from an existing sample image, that
> > > was created with Hyper-V under Windwos Server 2012.
> > >
> > > The image file is a 1GB dynamic image, with 32MB blocks.
> > >
> > > The pattern 0xa5 exists from 0MB-33MB (past a block size boundary)
> > >
> > > The pattern 0x96 exists from 33MB-66MB (past another block boundary,
> > > and leaving a partial blank block)
> > >
> > > From 66MB-1024MB, all reads should return 0.
> > >
> > > Although 1GB dynamic image with 66MB of data, the bzip2'ed image
> > > file size is only 874 bytes.
> > 
> > I take it there is additional meta-data in there generated by Windows
> > Server itself? Otherwise I would be tempted to write a tool to generate
> > the image on demand so it could be used to trigger other edge cases when
> > found.
> > 
> > Having said that 874 bytes certainly isn't to heavy a burden for the
> > repository ;-)
> 
> Eventually, qemu-img will be able to create VHDX images, but I think the
> point is that we compare against real Hyper-V VHDX images to ensure that
> we're really reading the spec the same way as they do.
> 

Exactly.  If we use qemu-img to generate test images, we aren't really
testing QEMU's compatibility with non-native formats.

Also, it may be useful to occasionally put native images (qcow2, qed)
in the sample_images directory for some major release, so that we can
run some image format regression tests on image format code changes.


> > I'm currently pondering what the best way of supporting system images
> > (i.e. kernel+rootfs) would be to make system regression testing easier.
> > Unfortunately those images would be far too large to carry in the repo
> > although there may be some sub-module annex type thing I could try.
> 
> Sounds like you're looking for qemu-tests?
> 
>     http://git.qemu.org/?p=qemu-test.git;a=summary
>

There is also autotest:
https://github.com/autotest/virt-test/wiki