Re: [Qemu-devel] [RFC] introduce a dynamic library to expose qemu block API

[Wenchao Xia <xiawenc@linux.vnet.ibm.com>]

于 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