[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

[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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]