From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kevin Wolf Subject: Re: KVM call agenda for June 28 Date: Wed, 29 Jun 2011 09:57:20 +0200 Message-ID: <4E0ADAE0.6040204@redhat.com> References: <20110628194106.GA17443@amt.cnet> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Stefan Hajnoczi , quintela@redhat.com, KVM devel mailing list , qemu-devel@nongnu.org, Chris Wright , Dor Laor , Avi Kivity To: Marcelo Tosatti Return-path: Received: from mx1.redhat.com ([209.132.183.28]:8422 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751132Ab1F2Hyb (ORCPT ); Wed, 29 Jun 2011 03:54:31 -0400 In-Reply-To: <20110628194106.GA17443@amt.cnet> Sender: kvm-owner@vger.kernel.org List-ID: Am 28.06.2011 21:41, schrieb Marcelo Tosatti: > 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. We can use almost the same interface and still have an image that is always valid (assuming that you provide the right format on the command line, which is already a requirement today). base <- sn1 <- sn2 <- copy.raw You just add the file name for an external COW file, like blkcopy:sn2:copy.raw:copy.cow (we can even have a default filename for HMP instead of requiring to specify it, like $IMAGE.cow) and if the destination doesn't support backing files by itself, blkcopy creates the COW overlay BlockDriverState that uses this file. No difference for management at all, except that it needs to allow access to another file. > stream > ------ > > 1) base <- remote > 2) base <- remote <- local > 3) base <- local > > "local" image is always valid. Requires backing file support. With the above, this restriction wouldn't apply any more. Also I don't think we should mix approaches. Either both block copy and image streaming use backing files, or none of them do. Mixing means duplicating more code, and even worse, that you can't stop a block copy in the middle and continue with streaming (which I believe is a really valuable feature to have). Kevin