From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marcelo Tosatti Subject: Re: KVM call agenda for June 28 Date: Tue, 28 Jun 2011 16:41:06 -0300 Message-ID: <20110628194106.GA17443@amt.cnet> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: quintela@redhat.com, KVM devel mailing list , qemu-devel@nongnu.org, Chris Wright , Kevin Wolf To: Stefan Hajnoczi Return-path: Received: from mx1.redhat.com ([209.132.183.28]:53811 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751542Ab1F1Tls (ORCPT ); Tue, 28 Jun 2011 15:41:48 -0400 Content-Disposition: inline In-Reply-To: Sender: kvm-owner@vger.kernel.org List-ID: On Tue, Jun 28, 2011 at 02:38:15PM +0100, Stefan Hajnoczi wrote: > On Mon, Jun 27, 2011 at 3:32 PM, Juan Quintela wrote: > > Please send in any agenda items you are interested in covering. > > Live block copy and image streaming: > * The differences between Marcelo and Kevin's approaches > * 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. 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.