From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:60687) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QbnOF-0001vw-Df for qemu-devel@nongnu.org; Wed, 29 Jun 2011 01:32:44 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1QbnOD-0006x9-M4 for qemu-devel@nongnu.org; Wed, 29 Jun 2011 01:32:43 -0400 Received: from mail-yi0-f45.google.com ([209.85.218.45]:49226) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1QbnOD-0006x5-BQ for qemu-devel@nongnu.org; Wed, 29 Jun 2011 01:32:41 -0400 Received: by yia25 with SMTP id 25so424285yia.4 for ; Tue, 28 Jun 2011 22:32:39 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <20110628194106.GA17443@amt.cnet> References: <20110628194106.GA17443@amt.cnet> Date: Wed, 29 Jun 2011 06:32:39 +0100 Message-ID: From: Stefan Hajnoczi Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] KVM call agenda for June 28 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Marcelo Tosatti Cc: Chris Wright , Kevin Wolf , qemu-devel@nongnu.org, KVM devel mailing list , quintela@redhat.com On Tue, Jun 28, 2011 at 8:41 PM, Marcelo Tosatti wrot= e: > On Tue, Jun 28, 2011 at 02:38:15PM +0100, Stefan Hajnoczi wrote: >> On Mon, Jun 27, 2011 at 3:32 PM, Juan Quintela wro= te: >> > Please send in any agenda items you are interested in covering. >> >> Live block copy and image streaming: >> =A0* The differences between Marcelo and Kevin's approaches >> =A0* Which approach to choose and who can help implement it > > After more thinking, i dislike the image metadata approach. Management > must carry the information anyway, so its pointless to duplicate it > inside an image format. I agree with you. It would be a significant change for QEMU users to deal with block state files just in case they want to use live block copy/image streaming. Not only would existing management layers need to be updated but also custom management or provisioning scripts. > After the discussion today, i think the internal mechanism and interface > should be different for copy and stream: > > block copy > ---------- > > With backing files: > > 1) base <- sn1 <- sn2 > 2) base <- copy > > Without: > > 1) source > 2) destination > > Copy is only valid after switch has been performed. Same interface and > crash recovery characteristics for all image formats. > > If management wants to support continuation, it must specify > blkcopy:sn2:copy on startup. > > stream > ------ > > 1) base <- remote > 2) base <- remote <- local > 3) base <- local > > "local" image is always valid. Requires backing file support. I agree that the modes of operation are different and we should provide different HMP/QMP APIs for them. Internally I still think they can share code for the source -> destination copy operation. Stefan