[libvirt] [RFC] Introduce virDomainBlockCopy API

[Stefan Hajnoczi]

On Tue, Jun 21, 2011 at 1:01 PM, Jiri Denemark <jdenemar at redhat.com> wrote:
> On Tue, Jun 21, 2011 at 10:48:38 +0100, Daniel P. Berrange wrote:
>> On Mon, Jun 20, 2011 at 08:15:24PM +0200, Jiri Denemark wrote:
>> > This API starts asynchronous live copy of a block device (specified by
>> > target element of the xml argument) into a new source (which must
>> > already exist). The process can be controlled in the same way as
>> > migration: monitored with virDomainJobInfo() and canceled using
>> > virDomainAbortJob().
>> >
>> > I don't particularly like the name (but I wasn't able to come up with a
>> > better one) since it doesn't reflect the fact that once a block device
>> > is switched to use the new source once copying finishes. In other words,
>> > the goal of this API is to update the device to use new source (just
>> > like virDomainUpdateDeviceFlags) but before doing so all data is copied
>> > from the old source into the new one (unlike the UpdateDevice API).
>>
>> How is this functionality different from the virDomainBlockPull
>> APIs we just added from Adam. From this description, it sounds
>> practically identical, except it only allows one job to be run
>> at a time, instead of allowing many.
>
> Assuming I understand Adam's virDomainBlockPull API correctly it takes a disk
> image which is based on a backing image and pulls all data from the backing
> image into the main image so that it becomes independent on the backing image.
>
> This new virDomainBlockCopy API is different. It can be used when you have a
> disk image (no matter what kind) stored somewhere and you need to copy it
> somewhere else. It takes two different and independent images, one currently
> assigned to a virtual block device and a new unassigned one, copies all data
> from the old one to the new one and reconfigures the block device to use the
> new image. Neither of the image formats has to be even capable of backing
> images.

Right.

Stefan