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
signature.asc
Description: PGP signature
