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. Jirka -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list