Am 08.04.2011 18:02, schrieb Stefan Hajnoczi:
On Fri, Apr 8, 2011 at 2:31 PM, Daniel P. Berrange
<berrange(a)redhat.com> wrote:
I have CCed Anthony and Kevin. Anthony drove the QED image streaming
and Kevin will probably be interested in the idea of allocating raw
images as a background activity while QEMU runs.
> /*
> * @path: fully qualified filename of the virtual disk
> * @nregions: filled in the number of @region structs
> * @regions: filled with a list of allocated regions
> *
> * Query the extents of allocated regions within the
> * virtual disk file. The offsets in the list of regions
> * are not guarenteed to be sorted in any explicit order.
> */
> int virDomainBlockGetAllocationMap(virDomainPtr dom,
> const char *path,
> unsigned int *nregions,
> virDomainBlockRegionPtr *regions);
QEMU can provide this with its existing .bdrv_is_allocated() function.
Kevin, do you have any thoughts on whether this API will work well?
I'm probably just lacking context here, but what would a management tool
do with this information?
From this one function it looks like you want to implement the image
streaming in libvirt rather than qemu? What's the reason for this? And
wouldn't you need at least a second function that actually copies data
from the source?
> This takes care of things for running guests. It would be
> desirable to have the same functionality available when a
> guest is not running, via the virStorageVol APIs. Indeed,
> this would allow access to the allocation functionality
> for disks not explicitly associated with any VM yet.
Today QEMU doesn't really cover the offline case although in the
future it may be possible to have a qemu-img command that preallocates
images and can be aborted.
Maybe qemu-io can be used to access the information? Again, I think I'm
lacking context, so I don't really know what the use case is.
Kevin