From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:38707) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1d8Rcc-0007BL-99 for qemu-devel@nongnu.org; Wed, 10 May 2017 09:25:43 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1d8RcY-0006I1-9I for qemu-devel@nongnu.org; Wed, 10 May 2017 09:25:42 -0400 References: <20170504105444.8940-1-daniel.kucera@gmail.com> <20170508203556.GA22634@stefanha-x1.localdomain> <20170509165254.GA26793@stefanha-x1.localdomain> From: "Denis V. Lunev" Message-ID: Date: Wed, 10 May 2017 15:25:31 +0200 MIME-Version: 1.0 In-Reply-To: <20170509165254.GA26793@stefanha-x1.localdomain> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PATCH] mirror: add sync mode incremental to drive-mirror and blockdev-mirror List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi , John Snow Cc: Daniel Kucera , Kevin Wolf , "open list:Block Jobs" , Markus Armbruster , Jeff Cody , qemu-devel@nongnu.org, Max Reitz , Vladimir Sementsov-Ogievskiy On 05/09/2017 06:52 PM, Stefan Hajnoczi wrote: > On Mon, May 08, 2017 at 05:07:18PM -0400, John Snow wrote: >> >> On 05/08/2017 05:02 PM, Denis V. Lunev wrote: >>> On 05/08/2017 10:35 PM, Stefan Hajnoczi wrote: >>>> On Thu, May 04, 2017 at 12:54:40PM +0200, Daniel Kucera wrote: >>>> >>>> Seems like a logical extension along the same lines as the backup bl= ock >>>> job's dirty bitmap sync mode. >>>> >>>>> parameter bitmap chooses existing dirtymap instead of newly created= >>>>> in mirror_start_job >>>>> >>>>> Signed-off-by: Daniel Kucera >>> Can you pls describe the use case pls in a bit more details. >>> >>> For now this could be a bit strange: >>> - dirty bitmap, which can be found via bdrv_create_dirty_bitmap >>> could be read-only or read-write, i.e. being modified by writes >>> or be read-only, which should not be modified. Thus adding >>> r/o bitmap to the mirror could result in interesting things. >>> >> This patch as it was submitted does not put the bitmap into a read-onl= y >> mode; it leaves it RW and modifies it as it processes the mirror comma= nd. >> >> Though you do raise a good point; this bitmap is now in-use by a job a= nd >> should not be allowed to be deleted by the user, but our existing >> mechanism treats a locked bitmap as one that is also in R/O mode. This= >> would be a different use case. >> >>> Minimally we should prohibit usage of r/o bitmaps this way. >>> >>> So, why to use mirror, not backup for the case? >>> >> My guess is for pivot semantics. > Daniel posted his workflow in a previous revision of this series: > > He is doing a variation on non-shared storage migration with the mirror= > block job, but using the ZFS send operation to transfer the initial cop= y > of the disk. > > Once ZFS send completes it's necessary to transfer all the blocks that > were dirtied while the transfer was taking place. > > 1. Create dirty bitmap and start tracking dirty blocks in QEMU. > 2. Snapshot and send ZFS volume. > 3. mirror sync=3Dbitmap after ZFS send completes. > 4. Live migrate. > > Stefan thank you very much. This is clear now. If I am not mistaken, this can be very easy done with the current implementation without further QEMU modifications. Daniel just needs to start mirror and put it on pause for the duration of stage (2). Will this work? Den