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 <quintela@xxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
