From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([140.186.70.92]:55415)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <mtosatti@redhat.com>) id 1QXa4y-0008I9-A7
	for qemu-devel@nongnu.org; Fri, 17 Jun 2011 10:31:25 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <mtosatti@redhat.com>) id 1QXa4w-0007jH-Fu
	for qemu-devel@nongnu.org; Fri, 17 Jun 2011 10:31:23 -0400
Received: from mx1.redhat.com ([209.132.183.28]:34225)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <mtosatti@redhat.com>) id 1QXa4w-0007j3-07
	for qemu-devel@nongnu.org; Fri, 17 Jun 2011 10:31:22 -0400
Date: Fri, 17 Jun 2011 09:31:53 -0300
From: Marcelo Tosatti <mtosatti@redhat.com>
Message-ID: <20110617123152.GA7379@amt.cnet>
References: <1308075511-4745-1-git-send-email-stefanha@linux.vnet.ibm.com>
	<4DF9F899.5050301@redhat.com> <4DF9FBE4.9080300@redhat.com>
	<4DFA004E.9010001@redhat.com> <20110616145243.GB12173@amt.cnet>
	<20110616153018.GA20714@stefanha-thinkpad.localdomain>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20110616153018.GA20714@stefanha-thinkpad.localdomain>
Subject: Re: [Qemu-devel] Image streaming and live block copy
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>
Cc: Kevin Wolf <kwolf@redhat.com>, Anthony Liguori <aliguori@us.ibm.com>, jes sorensen <jes.sorensen@redhat.com>, Dor Laor <dlaor@redhat.com>, qemu-devel@nongnu.org, Avi Kivity <avi@redhat.com>, Adam Litke <agl@us.ibm.com>

On Thu, Jun 16, 2011 at 04:30:18PM +0100, Stefan Hajnoczi wrote:
> On Thu, Jun 16, 2011 at 11:52:43AM -0300, Marcelo Tosatti wrote:
> This approach does not use the backing file feature?
> 
> > blkstream block driver:
> > 
> > - Maintain in memory whether given block is allocated in local image,
> > if not, read from remote, write to local. Set block as local.
> > Local and remote simply two block drivers from image streaming driver
> > POV.
> > - Once all blocks are local, notify mgmt so it can switch to local
> > copy.
> > - Writes are mirrored to source and destination, minding guest writes
> > over copy writes.
> 
> We open the remote file read-only for image streaming and do not want to
> mirror writes.

Why not? Is there any disadvantage of mirroring writes?

> If QEMU crashes or there is a power failure we need to restart the
> streaming process carefully - local blocks must not be overwritten.
> Perhaps this is the tricky part.

Under the proposed scheme, if QEMU crashes you'd restart streaming from
zero. In that case, the remote image is consistent due to mirrored
writes.

That is one disadvantage of keeping the local/remote status of blocks
in memory: in case of a crash you'd have to restart from zero. But this
should be an uncommon case (and there is not much of an option for
generic-format image streaming without keeping metadata).

Do you see a problem with that?

> > Over this scheme, you'd have:
> > 
> > 1) Block copy. 
> > Reopen image to be copied with
> > blkstream:/path/to/current-image:/path/to/destination-image,
> > background read sectors 0...N.
> > 
> > 2) Image stream:
> > blkstream:remote-image:/path/to/local-image,
> > background read sectors 0...N.
> 
> Stefan