Xen devel - Jun 2007 - [PATCH 1/4] (Refactored) provide vhd support to qemu

[PATCH 1/4] (Refactored) provide vhd support to qemu
qemu-vhd-support.patch
Provides integration of vdisk library, and implementation of block-vhd
into qemu.
Signed-off-by: Boris Ostrovsky <bostrovsky@virtualiron.com>
Signed-off-by: Ben Guthro <bguthro@virtualiron.com>



_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Hi Ben,

   Thanks very much for these patches -- it would be great to see VHD
support added to blktap.  I''ve taken a high-level pass over your
patches and have a few comments/suggestions:

  1. Your patches add a vdisk abstraction.  It''s not clear that adding
another virtual disk interface (in addition to what is already
presented with tapdisk and used by the existing drivers) is a big win
-- especially since VHD is the only consumer of the new abstraction.
If the tapdisk interface falls short, can we evolve it to address
deficiencies rather than add another parallel interface?

  2. Having both qemu and tapdisk instances go directly at the disk
isn''t ideal.  It would be much better to plumb qemu through tapdisk,
say through a dom0 block-attach, so that we implement drivers in a
single place,  cache image metadata in a single entity at runtime,
etc.

  3. It doesn''t look like your VHD implementation does chained disks.
Am I missing something, or is this future work?


a.

On 6/21/07, Ben Guthro <bguthro@virtualiron.com>
wrote:
> [PATCH 1/4] (Refactored) provide vhd support to qemu
> qemu-vhd-support.patch
> Provides integration of vdisk library, and implementation of block-vhd
> into qemu.
> Signed-off-by: Boris Ostrovsky <bostrovsky@virtualiron.com>
> Signed-off-by: Ben Guthro <bguthro@virtualiron.com>
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
>
>
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Andrew Warfield wrote:
> Hi Ben,
> 
>   Thanks very much for these patches -- it would be great to see VHD
> support added to blktap.  I''ve taken a high-level pass over your
> patches and have a few comments/suggestions:
> 
>  1. Your patches add a vdisk abstraction.  It''s not clear that
adding
> another virtual disk interface (in addition to what is already
> presented with tapdisk and used by the existing drivers) is a big win
> -- especially since VHD is the only consumer of the new abstraction.
> If the tapdisk interface falls short, can we evolve it to address
> deficiencies rather than add another parallel interface?
The vdisk abstraction was mainly designed to allow qemu & tapdisk to share
the same format translation code.  Existing formats seemed to duplicate
code between the two consumers.
>  2. Having both qemu and tapdisk instances go directly at the disk
> isn''t ideal.  It would be much better to plumb qemu through
tapdisk,
> say through a dom0 block-attach, so that we implement drivers in a
> single place,  cache image metadata in a single entity at runtime,
> etc.
I''m confused here, are you saying that the current disk format decoders
are
not duplicated in both qemu and tapdisk?  I didn''t think upstream qemu
even
knew about tapdisk.

In any case, I would think Qemu performance overhead is significant enough
without adding another hop through tapdisk.
>  3. It doesn''t look like your VHD implementation does chained
disks.
> Am I missing something, or is this future work?
Disk chaining (parent/child relationships) is currently handled by the
vdisk layer, not the VHD format translation directly.

Steve
-- 
Steve Ofsthun - Virtual Iron Software, Inc.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel