[libvirt] [PATCH 1/6] Add new API virDomainStreamDisk[Info] to header and drivers

Anthony Liguori anthony at codemonkey.ws
Fri Apr 8 19:26:48 UTC 2011


On 04/08/2011 11:02 AM, Stefan Hajnoczi wrote:
> On Fri, Apr 8, 2011 at 2:31 PM, Daniel P. Berrange<berrange at 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




More information about the libvir-list mailing list