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(a)redhat.com&gt; 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.