[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