Re: KVM call agenda for June 28

[Stefan Hajnoczi <stefanha@gmail.com>]

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

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