[Qemu-devel] Re: Live migration protocol, device features, ABIs and other beasts

["Michael S. Tsirkin" <mst@redhat.com>]

On Tue, Nov 24, 2009 at 07:45:13AM -0600, Anthony Liguori wrote:
> Michael S. Tsirkin wrote:
>> On Sun, Nov 22, 2009 at 09:49:26AM -0600, Anthony Liguori wrote:
>>   
>>>>    We cannot even create a new 'hack section' for new code since the
>>>>    sections are ordered and expected to be exact match on the
>>>>    destination.
>>>>
>>>>    The result is that new->old migration cannot work. This is not cross
>>>>    releases even! It means that even a small bug in current release
>>>>    prevents live migration between various instances of the code.
>>>>    It forces us to decide whether to fix pvclock migration issue vs
>>>>    allow new->old migration. Another ugly hack is to add cmdline that
>>>>    will control this behavior. Still it's a pain to mgmt stack and
>>>>    users.
>>>>       
>>> This is a pretty normal policy (backwards compat but not forwards compat).
>>>     
>>
>> No one is asking that old qemu magically understands new format. It
>> would be enough that new qemu is able to migrate to a format that old
>> one understands.
>>   
>
> I've got no problem with that provided it's something explicitly  
> requested by the user.  This requires no migration protocol change  
> though so if this is what folks are asking for, why is this thread  
> focused around changing the live migration protocol?

I think the claim is that a section-based migration
protocol would make implementing this easier than
version-based one, especially for downstream which might
cherry-pick a feature from a new release to an old one.

It seems the requirement discussion and the implementation
discussion are going on together in this thread.

> Regards,
>
> Anthony Liguori
>
>