From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:35949) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aTBTb-0000BQ-5i for qemu-devel@nongnu.org; Tue, 09 Feb 2016 11:49:20 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aTBTX-0007k9-53 for qemu-devel@nongnu.org; Tue, 09 Feb 2016 11:49:19 -0500 Received: from mx1.redhat.com ([209.132.183.28]:41485) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aTBTW-0007k3-VM for qemu-devel@nongnu.org; Tue, 09 Feb 2016 11:49:15 -0500 References: <1454151394-52320-1-git-send-email-vsementsov@virtuozzo.com> <20160203081418.GC25746@ad.usersys.redhat.com> <56B45D3A.405@virtuozzo.com> <20160209142100.GA19303@stefanha-x1.localdomain> <56B9F9B0.8010801@virtuozzo.com> From: John Snow Message-ID: <56BA1888.7050308@redhat.com> Date: Tue, 9 Feb 2016 11:49:12 -0500 MIME-Version: 1.0 In-Reply-To: <56B9F9B0.8010801@virtuozzo.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH v2 0/6] external backup api List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Denis V. Lunev" , Stefan Hajnoczi Cc: kwolf@redhat.com, Vladimir Sementsov-Ogievskiy , Fam Zheng , qemu-devel@nongnu.org, armbru@redhat.com On 02/09/2016 09:37 AM, Denis V. Lunev wrote: > On 02/09/2016 05:21 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. >> Backup software can implement NBD to receive the incremental blocks from >> QEMU. Use drive-backup sync=incremental and the backup appliance as the >> NBD target. >> >> It's more complicated to add this QMP command flow to backup software >> than to implement NBD. >> >> Stefan > it can, but this is a matter of problem due to the nature of > how this software is implemented. Usually it is written > in a semi-standard way and it uses "plugins" to actually > collect the data, i.e. the code is written in standard > interface/real implementation pattern and interfaces are > basically the same. > > With this standard approach backup software is working > as an active side of the process, i.e. it performs operations > and controls the flow. > > This means that "non-standard" QEMU technology will be > pain here. > > Den Am I to understand that for e.g. VMWare the backup appliance is literally reading the disk image from storage directly while the VM is running? I'd be a bit surprised if that were true. My biggest concern here is that there is not a safe way, today, to read from a disk image atomically while the VM is running. I think that'd take a lot of work to do and you'll not find a lot of support in implementing it. Of course, while the VM is paused/off is a different story, but for now I still feel like NBD is the right answer for getting block data from QEMU. What am I missing? --js