On 04/08/2011 11:02 AM, Stefan Hajnoczi wrote:
On Fri, Apr 8, 2011 at 2:31 PM, Daniel P. Berrange<berrange@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 think the trouble with this API proposal is that it's overloading concepts. Sparse is not the same thing as CoW to a backing file. For instance, when you expose streaming, the result is still a sparse file. So you'd have a rather curious API where you called to "allocate" a region in the file which resulted in having a sparse file which you then called again to make it non sparse. But AFAICT, the API doesn't really tell you these details. I think it's too much abstraction with not enough commonality. Having to related APIs to expand a copy-on-read image and then to fill in a sparse file is certainly a reasonable thing to do. I think trying to make a single API that does both without having a flag that basically makes it two APIs is going to be cumbersome. Regards, Anthony Liguori