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

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(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? 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

>>> 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