On Wed, May 10, 2017 at 03:25:31PM +0200, Denis V. Lunev wrote: > 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 block > >>>> job's dirty bitmap sync mode. > >>>> > >>>>> parameter bitmap chooses existing dirtymap instead of newly created > >>>>> in mirror_start_job > >>>>> > >>>>> Signed-off-by: Daniel Kucera <daniel.kuc...@gmail.com> > >>> 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-only > >> mode; it leaves it RW and modifies it as it processes the mirror command. > >> > >> Though you do raise a good point; this bitmap is now in-use by a job and > >> 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 copy > > 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=bitmap 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?
I think it's a interesting idea but I'm not sure if sync=none + pause can be done atomically. Without atomicity a block might be sent to the destination while the ZFS send is still in progress. Stefan
signature.asc
Description: PGP signature
