From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Daniel P. Berrange" Subject: Re: [PATCH] blktap: qcow2 image format support Date: Thu, 21 Feb 2008 12:47:52 +0000 Message-ID: <20080221124752.GB30015@redhat.com> References: <200802211007.14443.Christoph.Egger@amd.com> Reply-To: "Daniel P. Berrange" Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Content-Disposition: inline In-Reply-To: <200802211007.14443.Christoph.Egger@amd.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Christoph Egger Cc: xen-devel@lists.xensource.com, Kevin Wolf List-Id: xen-devel@lists.xenproject.org On Thu, Feb 21, 2008 at 10:07:14AM +0100, Christoph Egger wrote: > On Thursday 21 February 2008 09:57:48 Keir Fraser wrote: > > On 21/2/08 08:49, "Kevin Wolf" wrote: > > > This patch adds support for the qcow2 image format to blktap. It > > > consists mostly of qemu code, adapted to the blktap interfaces. > > > Snapshots and compressed images are supported. > > > > > > The qcow2 driver may be used by either specifying tap:qcow2 or by using > > > tap:qcow which will detect that you have a version 2 image and will call > > > the qcow2 driver. > > > > Is qcow2 so different from qcow1 that it really needs its own backend > > driver? > > IMO, _all_ blktap drivers need some code refactoring. There is a lot of > duplicated code across all drivers > that can be moved into a blktap/drivers/blk-common.c. Well if you're concerned about code duplication - we've 2 entirely separate impls of every disk format - one in blktap and one in QEMU itself. The original motivation for the duplication was that QEMU's block driver API did not support Async-IO operations, but that was addressed in 0.9.0 - if you look at the internal QEMU block driver API for disk formats vs blktaps internal driver API they're near identical. I think it'd be an interesting project to actually make QEMU userspace talk directly to blktap kernel driver, thus eliminating the entire blktap users & all code duplication. Then we'd have parity of disk support across PV & HVM guests too. Certainly not an easy or quick project, but if someone's looking for something interesting to hack on.... Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|