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. 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. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|