Re: [Qemu-devel] [PATCH v6 2/2] block/vxhs.c: Add qemu-iotests for new block device type "vxhs"

[Jeff Cody <jcody@redhat.com>]

On Mon, Feb 13, 2017 at 01:37:25PM +0000, Stefan Hajnoczi wrote:
> On Tue, Feb 07, 2017 at 03:12:36PM -0800, ashish mittal wrote:
> > On Tue, Nov 8, 2016 at 12:44 PM, Jeff Cody <jcody@redhat.com> wrote:
> > > On Mon, Nov 07, 2016 at 04:59:45PM -0800, Ashish Mittal wrote:
> > >> These changes use a vxhs test server that is a part of the following
> > >> repository:
> > >> https://github.com/MittalAshish/libqnio.git
> > >>
> > >> Signed-off-by: Ashish Mittal <ashish.mittal@veritas.com>
> > >> ---
> > >> v6 changelog:
> > >> (1) Added iotests for VxHS block device.
> > >>
> > >>  tests/qemu-iotests/common        |  6 ++++++
> > >>  tests/qemu-iotests/common.config | 13 +++++++++++++
> > >>  tests/qemu-iotests/common.filter |  1 +
> > >>  tests/qemu-iotests/common.rc     | 19 +++++++++++++++++++
> > >>  4 files changed, 39 insertions(+)
> > >>
> > >> diff --git a/tests/qemu-iotests/common b/tests/qemu-iotests/common
> > >> index d60ea2c..41430d8 100644
> > >> --- a/tests/qemu-iotests/common
> > >> +++ b/tests/qemu-iotests/common
> > >
> > > When using raw format, I was able to run the test successfully for all
> > > supported test cases (26 of them).
> > >
> > > With qcow2, they fail - but not the fault of this patch, I think; but
> > > rather, the fault of the test server.  Can qnio_server be modified so that
> > > it does not work on just raw files?
> > >
> > >
> > 
> > VxHS supports and uses only the raw format.
> 
> That's like saying only ext4 guest file systems are supported on VxHS
> and not ZFS.  The VxHS driver should not care what file system is used,
> it just does block I/O without interpreting the data.
> 
> It must be possible to use any format on top of the VxHS protocol.
> After all, the image format drivers just do block I/O.  If there is a
> case where qcow2 on VxHS fails then it needs to be investigated.
> 
> The VxHS driver can't be merged until we at least understand the cause
> of the qcow2 test failures.
>

A quick run with the test server and a QEMU process showed an abort() in the
test server, so I just sent a pull req to libqnio to fix that.  

But playing with it in gdb right now with a test qcow2 file, I see that we
are waiting in aio_poll() forever for the test server to respond to a read
request, when using qcow2 format.  

As Stefan said, this doesn't really make any sense - why would VXHS behave
differently based on the file contents?

Jeff