On Tue, Feb 09, 2016 at 05:41:50PM +0300, Denis V. Lunev wrote:
> On 02/09/2016 05:28 PM, Stefan Hajnoczi wrote:
> >On Fri, Feb 05, 2016 at 11:28:42AM +0300, Denis V. Lunev wrote:
> >>On 02/03/2016 11:14 AM, Fam Zheng wrote:
> >>>On Sat, 01/30 13:56, Vladimir Sementsov-Ogievskiy wrote:
> >>>>Hi all.
> >>>>
> >>>>These series which aims to add external backup api. This is needed to allow
> >>>>backup software use our dirty bitmaps.
> >>>>
> >>>>Vmware and Parallels Cloud Server have this feature.
> >>>What is the advantage of this appraoch over "drive-backup sync=incremental
> >>>..."?
> >>This will allow third-party vendors to backup QEMU VMs into
> >>their own formats or to the cloud etc.
> >As an example, there is a third-party backup format called VMA from
> >Proxmox.  A few years ago I posted a proof-of-concept external backup
> >tool in Python:
> >
> >https://lists.gnu.org/archive/html/qemu-devel/2013-03/msg01536.html
> >
> >It takes a full backup using drive-backup NBD (plus RAM/device state)
> >but the same can be done with incremental backups.
> >
> >Does this NBD approach meet your requirements?
> >
> >Stefan
> for us we should somehow provide implementation of
> calls posted by Vladimir. They are available in Parallels Server
> version 6 and should be available in the next QEMU based
> release using "Parallels SDK to libvirt" convertor. The problem
> for us is that this old approach is used in the other side
> of the product - in containers implementation while this
> SDK is a universal access tool to both things.

Point taken.  I think many other backup applications will expect a
similar API, so it's pragmatic to provide something compatible.

Stefan