From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:42761) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SoT9L-0003JC-Nc for qemu-devel@nongnu.org; Tue, 10 Jul 2012 01:38:17 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SoT9J-0000yv-S7 for qemu-devel@nongnu.org; Tue, 10 Jul 2012 01:38:15 -0400 Received: from e23smtp08.au.ibm.com ([202.81.31.141]:58193) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SoT9J-0000y0-6I for qemu-devel@nongnu.org; Tue, 10 Jul 2012 01:38:13 -0400 Received: from /spool/local by e23smtp08.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Tue, 10 Jul 2012 05:34:45 +1000 Received: from d23av01.au.ibm.com (d23av01.au.ibm.com [9.190.234.96]) by d23relay04.au.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q6A5U2fs61538492 for ; Tue, 10 Jul 2012 15:30:03 +1000 Received: from d23av01.au.ibm.com (loopback [127.0.0.1]) by d23av01.au.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q6A5bqnk002867 for ; Tue, 10 Jul 2012 15:37:52 +1000 Message-ID: <4FFBBF8C.8080708@linux.vnet.ibm.com> Date: Tue, 10 Jul 2012 13:37:16 +0800 From: Wenchao Xia MIME-Version: 1.0 References: <4FFA9C30.2070201@linux.vnet.ibm.com> <20120709092705.GG16198@redhat.com> In-Reply-To: <20120709092705.GG16198@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Qemu-devel] [RFC] introduce a dynamic library to expose qemu block API List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Daniel P. Berrange" Cc: Paolo Bonzini , Anthony Liguori , Stefan Hajnoczi , qemu-devel@nongnu.org 于 2012-7-9 17:27, Daniel P. Berrange 写道: > On Mon, Jul 09, 2012 at 04:54:08PM +0800, Wenchao Xia wrote: >> Hi, Paolo and folks, >> qemu have good capabilities to access different virtual disks, I want >> to expose its block layer API to let 3rd party program linked in, such >> as management stack or block tools, to access images data directly. >> >> Following is the objects: >> (1) API to write/read block device at offset. >> (2) Determine the image type,qcow2/qed/raw >> (3) Determine which blocks are allocated. >> (4) Determine backing file. >> >> Following is my implementing plan draft: >> 1 introduce libqblock.so in sub directory in qemu. >> 2 write a nbd client in libqblock, similar to qemu nbd client. Then >> use it to talk with nbd server, by default is qemu-nbd, to get access >> to images. In this way, libqblock.so could be friendly LGPL licensed. >> 3 still not got a good way to get additional info in (2)(3)(4), >> currently in my head is patch qemu-nbd to add an additional nbd command, >> "image-info", in which returns related info. >> >> What do you think about it? > > For arbirary read/write access to disk images, I can see a little value > in having a standalone libnbd client API, that is able to just talk to > any NBD server. Arguably such a thing does not need to be part of the > QEMU source tree - eg see the recently written libiscsi.so client. > > For getting the other metadata about the disk image you mention, another > possibility to is just make 'qemu-img info' return the data in a machine > parseable format, ie JSON& make a client API for extracting data from > this JSON document. > Thank u for the idea. The .so is introduced to let program access the image more directly, parsing string is not so fast and it depends on another program's stdout output, I hope to get a faster way. > For a full-blown RPC API for doing arbitrary tasks related to block > devices, then many apps will tend towards libguestfs, since it provides > such a wide range of functionality for manipulating disk images. > I used libguestfs to make my image too, but the target of the .so is a bit different: it expose block data in a lower level, expose everything qemu main code(except block code) can see. Potential purpose is as first step to make qemu block layer independent, then qemu and other tool would be just employers of the library. But now it is out of plan because license issue, and the library acts as client now lowering the performance. > Regards, > Daniel -- Best Regards Wenchao Xia