From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:34886) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VMypG-0005Cn-Nn for qemu-devel@nongnu.org; Fri, 20 Sep 2013 07:24:47 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VMypC-0007Sq-E2 for qemu-devel@nongnu.org; Fri, 20 Sep 2013 07:24:42 -0400 Received: from mx1.redhat.com ([209.132.183.28]:35775) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VMypC-0007Si-5r for qemu-devel@nongnu.org; Fri, 20 Sep 2013 07:24:38 -0400 Date: Fri, 20 Sep 2013 07:24:33 -0400 From: Jeff Cody Message-ID: <20130920112433.GK15106@localhost.localdomain> References: <20130920091814.GC2800@dhcp-200-207.str.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <20130920091814.GC2800@dhcp-200-207.str.redhat.com> Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH 2/2] block: qemu-iotests for vhdx, read sample dynamic imagee List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin Wolf Cc: famz@redhat.com, Alex =?iso-8859-1?Q?Benn=E9e?= , qemu-devel@nongnu.org, stefanha@redhat.com On Fri, Sep 20, 2013 at 11:18:14AM +0200, Kevin Wolf wrote: > Am 20.09.2013 um 11:10 hat Alex Benn=E9e geschrieben: > >=20 > > jcody@redhat.com writes: > >=20 > > > 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. > >=20 > > 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 genera= te > > the image on demand so it could be used to trigger other edge cases w= hen > > found. > >=20 > > Having said that 874 bytes certainly isn't to heavy a burden for the > > repository ;-) >=20 > Eventually, qemu-img will be able to create VHDX images, but I think th= e > point is that we compare against real Hyper-V VHDX images to ensure tha= t > we're really reading the spec the same way as they do. >=20 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 easie= r. > > Unfortunately those images would be far too large to carry in the rep= o > > although there may be some sub-module annex type thing I could try. >=20 > Sounds like you're looking for qemu-tests? >=20 > http://git.qemu.org/?p=3Dqemu-test.git;a=3Dsummary > There is also autotest: https://github.com/autotest/virt-test/wiki