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

[Michael S. Tsirkin]

On Mon, Nov 23, 2009 at 08:53:54AM -0600, Anthony Liguori wrote:
> Eduardo Habkost wrote:
>>>>> Migration needs to be conservative. There should be only two possible
>>>>> outcomes: 1) a successful live migration or 2) graceful failure with the
>>>>> source VM still running correctly. Silently ignoring things that could
>>>>> affect the guests behavior means that it's possible that after failure,
>>>>> the guest will fail in an unexpected way.
>>>>>         
>>>> It's up to the source to decide what information is extra.  For  
>>>> example, the state of a RNG emulation is nice-to-have, but as long 
>>>> as it is initialized from another random source on the destination 
>>>> you shouldn't care.
>>>>       
>>> We only migrate things that are guest visible.  Everything else is 
>>> left to the user to configure.  We wouldn't migrate the state of a 
>>> RNG emulation provided that it doesn't have an impact on the guest.
>>>
>>> By definition, anything that is guest visible is important because it 
>>> affects the guest's behavior.
>>>     
>>
>> Right, but I wouldn't be surprised if a user complains that "I know that
>> my guest don't use that VM feature, so I want to be able to migrate to
>> an older version anyway".
>>   
>
> This could be addressed with a "force" migration feature.  That said, I  
> don't believe that the overwhelming majority of users are in a position  
> to determine whether they can safely migrate to an older version.
>
> Regards,
>
> Anthony Liguori

It's very easy: if their guest runs fine on the old qemu,
it should be safe to migrate there.


-- 
MST