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

[Anthony Liguori <anthony@codemonkey.ws>]

Juan Quintela wrote:
> Gleb Natapov <gleb@redhat.com> wrote:
>   
>> On Sun, Nov 22, 2009 at 08:17:46PM -0600, Anthony Liguori wrote:
>>     
>>> Paolo Bonzini wrote:
>>>       
>>>>> I don't see how this fixes anything. If you used feature bits, how do
>>>>> you migrate from a version that has a feature bit that an older version
>>>>> doesn't know about? Do you just ignore it?
>>>>>           
>>>> I'd go with chunk instead of feature bits, specifying them like in
>>>> the PNG specification:
>>>>         
>>> You mean, each device would have multiple sections?  We already use
>>> chunks for each device state.
>>>
>>>       
>> Each device can send device info in multiple formats (each format with
>> its own ID) and destination will choose the one it supports.
>>     
>
> RAM anyone?  You send 1GB of info in different formats, just in case :)
>
> In this case, I think that the only two realistic solutions are to
> increase negotiation during migration:
>
> - source -> target: I can save this devices with this versions:
>    "cpu" 10 - 12
>    "apic" 3
>    "ide" 2-4
>    "virtio-net" 5-10
>    ....
> - target -> source:
>    * I don't support "virtio-net" at all -> failed migration
>    * send it as:
>       "cpu" 11
>       "apic" 3
>       "ide" 2
>       "virtio-net" 10
>      thankyou very much :)
>   

I'm not at all convinced that you can downgrade the version of a device 
without exposing a functional change to a guest.  In fact, I'm pretty 
certain that it's provably impossible.  Please give a counter example of 
where this mechanism would be safe.

> Having subversions for downstream is a different problem that needs to
> be fixed.
>   

Yup.  However, I believe the problem is addresses is really what's 
driving this discussion of optional features.

Regards,

Anthony Liguori

> Later, Juan.
>