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

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

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.
>
>>> 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.

But some things might have greater impact than others.

Consider INTx state in PCI as an example.
Qemu used not to migrate it, as a result guest might
lose interrupt when migrating between such old qemu binaries.
This is rare enough, and often harmless, so for a while
no one noticed.

Later, we noticed this is user visible.
As a fix, we are now migrating INTx state and
guests are happy when migrating from new qemu to new qemu.

But it's easy to support migration to old qemu just
by discarding the INTx state, and this is not
at all harder, or worse, than migrating from old qemu
to new one.


> By definition, anything that is guest visible is important because it  
> affects the guest's behavior.
>
> Regards,
>
> Anthony Liguori
>