Re: [Qemu-devel] [RFC] Migration capability negotation

[Peter Lieven]

Am 25.10.2013 um 01:37 schrieb Juan Quintela <address@hidden>:

> Peter Lieven <address@hidden> wrote:
>> Hi,
>> 
>> I was thinking that it would be great to have the source and
>> destination during migration negoatiate
>> migration capabilities e.g. something like this:
>> 
>> User wants to use a feature e.g. 'zero_blocks'. He switches it to 'on'
>> or maybe a new state 'auto' on the source VM.
>> 
>> If the migration is started the source hypervisor sends a set of all
>> desired features. The destination hypervisor
>> answers with a subset of all features it supports and automatically
>> enables them on its side. Depending on the returned
>> subset the source disables all features the destination does not support.
>> 
>> This would also allow us also to introduce new features which we would
>> like to enable by default, but we cannot
>> because we do not know if the destination will support it.
>> 
>> Is there any way to add this without breaking backwards compability?
>> 
>> Comments welcome.
> 
> As said by Eric,  comunications goes only in one direction (think that
> we are migrating to a file,  A.K.A. savevm).  Anthony basically forbides
> them.  You can do the equivalent thing from the management application.

Ok, one way direction - i forgot about this paradigm.

2 thoughts:

a) a send-capabilities capability that "stores" the capabilities that where
used when savevm was used. I would implement a special segment
right at the beginning of the data stream that has all capabilities listed that
where set and that ultimately must be supported to import a saved state
under any circumstances. capabilities that are only have a meaning at
the source VM should not be set. if there is an unsupported capability
set the import can be aborted right at the beginning.

b) an extension the the qmp-migrate-capabilities or a new command that give
the controlling process (e.g. libvirt) a hint which features are a good thing 
to turn on
if they are supported on both sides (e.g. zero-blocks in block-migration).

Peter