Re: [PATCH 1/4] (Refactored) provide vhd support to qemu

[Steve Ofsthun <sofsthun@virtualiron.com>]

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.