[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Wenchao Xia
Subject: Re: [Qemu-devel] [RFC] introduce a dynamic library to expose qemu block API
Date: Tue, 10 Jul 2012 13:37:16 +0800
User-agent: Mozilla/5.0 (Windows NT 5.1; rv:12.0) Gecko/20120428 Thunderbird/12.0.1

于 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.


Best Regards

Wenchao Xia

reply via email to

[Prev in Thread] Current Thread [Next in Thread]