Re: [Qemu-devel] KVM call agenda for June 28

[Kevin Wolf <kwolf@redhat.com>]

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@redhat.com> 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