qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Jeff Cody
Subject: Re: [Qemu-devel] [PATCH 2/2] block: qemu-iotests for vhdx, read sample dynamic imagee
Date: Fri, 20 Sep 2013 07:24:33 -0400
User-agent: Mutt/1.5.21 (2010-09-15)

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:
> > 
> > address@hidden 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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]