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

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



Am 08.04.2011 18:02, schrieb Stefan Hajnoczi:
> 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'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


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