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

[Anthony Liguori <anthony@codemonkey.ws>]

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