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

[Kevin Wolf]

Am 08.04.2011 18:48, schrieb Daniel P. Berrange:
> On Fri, Apr 08, 2011 at 06:35:16PM +0200, Kevin Wolf wrote:
>> Am 08.04.2011 18:02, schrieb Stefan Hajnoczi:
>>> 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'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?
> 
> We don't want to implement it in libvirt - we want to control it
> from libvirt - QEMU obviously has to be in charge of actually
> writing the data, since the guest may be running and using the
> disk concurrently, and we don't want libvirt to have to learn
> about the various crazy virtual disk file formats QEMU has.
> 
> Having an API to request allocation of regions of virtual disk
> file was the first request, but to effectively use it, we also
> need to be able to understand what the current allocation of
> the file is, hence the above API (akin to ioctl(FIEMAP) for
> sparse files).
> 
> For full context see the parent messages in the thread
> 
>   http://www.redhat.com/archives/libvir-list/2011-April/msg00482.html
>   http://www.redhat.com/archives/libvir-list/2011-April/msg00483.html

Thanks, now it makes much more sense. I think I agree with your comments.

>>>> 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.
> 
> NB, we'd want something that is a supported interface - so for offline
> case, I assume this means a qemu-img command or two, since AFAIK qemu-io
> is just an adhoc developer debugging tool

Hm, never thought about that. Generally it's a command that I would have
seen to be more natural for qemu-io, but if we're going to make a
difference between fully supported qemu-img and debug-only qemu-io, then
it needs to be qemu-img. I don't think there's an explicit statement on
that yet.

Kevin