| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] [PATCH 1/4] (Refactored) provide vhd support to qemu
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@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home