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@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? > > 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 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list