Am 08.04.2011 18:02, schrieb Stefan Hajnoczi: > On Fri, Apr 8, 2011 at 2:31 PM, Daniel P. Berrange <berrange@xxxxxxxxxx> 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 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list