[libvirt] The future of virDomainBlockCopy API

Hi, With the current changes of block copy implementation in qemu (which was dropped in favor of using image streaming and snapshots to do the job) I think it's best not to include virDomainBlockCopy API in libvirt (yet). This is for several reasons: - the ideal semantics of virDomainBlockCopy API would be a no-op in case of failure, which can't be achieved with snapshot/image streaming combo since the domain is switched to the new image before any copying starts instead of when everything is finished - since monitor/cancellation APIs are designed with future block operations in mind, it will be easy to provide virDomainBlockCopy in the future if we feel the need for it - with BlockPull and Snapshot APIs in place, users/apps can do block copy by creating a snapshot of a disk and running BlockPull on it to make the new image independent on the original disk image - the two phase process makes it easy to resume image streaming in case it failed for a recoverable reason With current (WIP) snapshot support, one would use virDomainSnapshotCreateXML asking for a disk snapshot only (no memory) with the following XML: <domainsnapshot> <name>whatever</name> <disk name='/path/to/image1' snapshot='no'/> <disk name='/path/to/image2' snapshot='yes'> <volsnapshot> <name>disk snapshot name</name> <image name='/another/path/to/image2.new'/> </volsnapshot> </disk> </domainsnapshot> This will switch the domain to /another/path/to/image2.new with /path/to/image2 as its backing store. The new image can then be made independent on its backing store by calling virDomainBlockPull on it. Jirka