Am 05.07.2011 16:32, schrieb Marcelo Tosatti: > On Tue, Jul 05, 2011 at 04:39:06PM +0300, Dor Laor wrote: >> On 07/05/2011 03:58 PM, Marcelo Tosatti wrote: >>> On Tue, Jul 05, 2011 at 01:40:08PM +0100, Stefan Hajnoczi wrote: >>>> On Tue, Jul 5, 2011 at 9:01 AM, Dor Laor<dlaor@xxxxxxxxxx> wrote: >>>>> I tried to re-arrange all of the requirements and use cases using this wiki >>>>> page: http://wiki.qemu.org/Features/LiveBlockMigration >>>>> >>>>> It would be the best to agree upon the most interesting use cases (while we >>>>> make sure we cover future ones) and agree to them. >>>>> The next step is to set the interface for all the various verbs since the >>>>> implementation seems to be converging. >>>> >>>> Live block copy was supposed to support snapshot merge. I think the >>>> current favored approach is to make the source image a backing file to >>>> the destination image and essentially do image streaming. >>>> >>>> Using this mechanism for snapshot merge is tricky. The COW file >>>> already uses the read-only snapshot base image. So now we cannot >>>> trivally copy the COW file contents back into the snapshot base image >>>> using live block copy. >>> >>> It never did. Live copy creates a new image were both snapshot and >>> "current" are copied to. >>> >>> This is similar with image streaming. >> >> Not sure I realize what's bad to do in-place merge: >> >> Let's suppose we have this COW chain: >> >> base <-- s1 <-- s2 >> >> Now a live snapshot is created over s2, s2 becomes RO and s3 is RW: >> >> base <-- s1 <-- s2 <-- s3 >> >> Now we've done with s2 (post backup) and like to merge s3 into s2. >> >> With your approach we use live copy of s3 into newSnap: >> >> base <-- s1 <-- s2 <-- s3 >> base <-- s1 <-- newSnap >> >> When it is over s2 and s3 can be erased. >> The down side is the IOs for copying s2 data and the temporary >> storage. I guess temp storage is cheap but excessive IO are >> expensive. >> >> My approach was to collapse s3 into s2 and erase s3 eventually: >> >> before: base <-- s1 <-- s2 <-- s3 >> after: base <-- s1 <-- s2 >> >> If we use live block copy using mirror driver it should be safe as >> long as we keep the ordering of new writes into s3 during the >> execution. >> Even a failure in the the middle won't cause harm since the >> management will keep using s3 until it gets success event. > > Well, it is more complicated than simply streaming into a new > image. I'm not entirely sure it is necessary. The common case is: > > base -> sn-1 -> sn-2 -> ... -> sn-n > > When n reaches a limit, you do: > > base -> merge-1 Hm, I would expect that a case like this is important, too: base <- sn-1 <- ... <- sn-n-1 <- sn-n <- ... <- sn-m Which should be merged so that we get the following (i.e. deleting older snapshots but retaining more recent ones): base <- sn-merged <- sn-n <- ... <- sn-m 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
