On 02/24/2012 06:46 PM, Eric Blake wrote: > I think you need to be more explicit that @new-image-file MUST have > identical contents as the current image file, for this to be useful, and > that qemu does not validate whether the new image met those conditions. > Possible ways to achieve this:
Not necessarily, you could always do this on a paused machine. >> > +# @destination: the destination of the block migration. > Where do you list what format the destination is? Shouldn't this have > an optional format, defaulting to qcow2? Does qemu create the > destination file, or must it already be existing? I think no default, raw makes as much or more sense in the non-incremental case. Anyway either autodetect, or no default. >> > +# >> > +# @new-image-file: #optional an existing image file that will replace >> > +# the current one in the device. > Where do you list what format the new-image-file is? Shouldn't this > have an optional format, defaulting to qcow2? Does qemu create the > new-image-file, or can one already be existing? qemu does not create the file now, but in the future we may add a flag to create a snapshot. I think no default is better here too, or autodetect. > I know that this patch is only implementing the case where incremental > is true and new-image-file is provided; but I'm not quite sure what > semantics are intended if incremental is false. Is that still a case > where this sets up mirroring (writes go to two images) but additionally > the contents from the current image are (asynchronously) streamed into > the destination? Yes. The image should already be there also in this case, and new-image-file will usually be omitted. Paolo