qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Stefan Hajnoczi <stefanha@gmail.com>
To: John Snow <jsnow@redhat.com>
Cc: "Denis V. Lunev" <den@openvz.org>,
	Daniel Kucera <daniel.kucera@gmail.com>,
	Kevin Wolf <kwolf@redhat.com>,
	"open list:Block Jobs" <qemu-block@nongnu.org>,
	Markus Armbruster <armbru@redhat.com>,
	Jeff Cody <jcody@redhat.com>,
	qemu-devel@nongnu.org, Max Reitz <mreitz@redhat.com>,
	Vladimir Sementsov-Ogievskiy <vsementsov@virtuozzo.com>
Subject: Re: [Qemu-devel] [PATCH] mirror: add sync mode incremental to drive-mirror and blockdev-mirror
Date: Tue, 9 May 2017 12:52:54 -0400	[thread overview]
Message-ID: <20170509165254.GA26793@stefanha-x1.localdomain> (raw)
In-Reply-To: <fac1ae33-dc7e-b513-d694-c8f8c1555baa@redhat.com>

[-- Attachment #1: Type: text/plain, Size: 2051 bytes --]

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.kucera@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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]

  reply	other threads:[~2017-05-09 17:53 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-04 10:54 [Qemu-devel] [PATCH] mirror: add sync mode incremental to drive-mirror and blockdev-mirror Daniel Kucera
2017-05-08 20:35 ` Stefan Hajnoczi
2017-05-08 21:02   ` Denis V. Lunev
2017-05-08 21:07     ` John Snow
2017-05-09 16:52       ` Stefan Hajnoczi [this message]
2017-05-10 13:25         ` Denis V. Lunev
2017-05-10 15:00           ` Stefan Hajnoczi
2017-05-10 15:05             ` Denis V. Lunev
2017-05-11 14:16               ` Daniel Kučera
2017-05-11 14:28                 ` Denis V. Lunev
2017-05-11 14:52                   ` Daniel Kučera
2017-05-11 18:35                   ` Stefan Hajnoczi
2017-05-11 18:43                     ` John Snow
2017-05-11 18:46                       ` Denis V. Lunev

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170509165254.GA26793@stefanha-x1.localdomain \
    --to=stefanha@gmail.com \
    --cc=armbru@redhat.com \
    --cc=daniel.kucera@gmail.com \
    --cc=den@openvz.org \
    --cc=jcody@redhat.com \
    --cc=jsnow@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=mreitz@redhat.com \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    --cc=vsementsov@virtuozzo.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).