From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:59360) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aRmMg-0004lx-8q for qemu-devel@nongnu.org; Fri, 05 Feb 2016 14:48:23 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aRmMc-0005qu-11 for qemu-devel@nongnu.org; Fri, 05 Feb 2016 14:48:22 -0500 Received: from mx1.redhat.com ([209.132.183.28]:56451) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aRmMb-0005qk-Rg for qemu-devel@nongnu.org; Fri, 05 Feb 2016 14:48:17 -0500 References: <1453482459-80179-1-git-send-email-vsementsov@virtuozzo.com> From: John Snow Message-ID: <56B4FC80.1070402@redhat.com> Date: Fri, 5 Feb 2016 14:48:16 -0500 MIME-Version: 1.0 In-Reply-To: <1453482459-80179-1-git-send-email-vsementsov@virtuozzo.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH RFC] external backup api List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Vladimir Sementsov-Ogievskiy , qemu-devel@nongnu.org Cc: famz@redhat.com, den@virtuozzo.com, Stefan Hajnoczi On 01/22/2016 12:07 PM, Vladimir Sementsov-Ogievskiy wrote: > Hi all. > > This is the early begin of the 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. > Have a link to the equivalent feature that VMWare exposes? (Or Parallels Cloud Server) ... I'm curious about what the API there looks like. > There is only one patch here, about querying dirty bitmap from qemu by > qmp command. It is just an updated and clipped (hmp command removed) old > my patch "[PATCH RFC v3 01/14] qmp: add query-block-dirty-bitmap". > > Before writing the whole thing I'd like to discuss the details. Or, may > be there are existing plans on this topic, or may be someone already > works on it? > > I see it like this: > > ===== > > - add qmp commands for dirty-bitmap functions: create_successor, abdicate, > reclaime. Hm, why do we need such low-level control over splitting and merging bitmaps from an external client? > - make create-successor command transaction-able > - add query-block-dirty-bitmap qmp command > > then, external backup: > > qmp transaction { > external-snapshot > bitmap-create-successor > } > > qmp query frozen bitmap, not acquiring aio context. > > do external backup, using snapshot and bitmap > > if (success backup) > qmp bitmap-abdicate > else > qmp bitmap-reclaime > > qmp merge snapshot > ===== > Hm, I see -- so you're hoping to manage the backup *entirely* externally, so you want to be able to reach inside of QEMU and control some status conditions to guarantee it'll be safe. I'm not convinced QEMU can guarantee such things -- due to various flush properties, race conditions on write, etc. QEMU handles all of this internally in a non-public way at the moment. > > In the following patch query-bitmap acquires aio context. This must be > ofcourse dropped for frozen bitmap. > But to make it in true way, I think, I should check somehow that this is > not just frozen bitmap, but the bitmap frozen by qmp command, to avoid > incorrect quering of bitmap frozen by internal backup (or other > mechanizm).. May be, it is not necessary. > > >