On Tue, Jun 28, 2011 at 8:41 PM, Marcelo Tosatti <mtosatti@xxxxxxxxxx> wrote: > 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. 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 -- 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
