[libvirt] The future of virDomainBlockCopy API

[Jiri Denemark]

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