[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] 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
|
![]() |
Lists.xenproject.org is hosted with RackSpace, monitoring our |