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

[Eduardo Habkost <ehabkost@redhat.com>]

Excerpts from Anthony Liguori's message of Mon Nov 23 00:17:46 -0200 2009:
> 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.

I was going to suggest that. The current section system would be a good
candidate for a "capability" system. e.g. instead of adding new data to
the "cpu" section and increasing its version number, you add a
"cpu.pvclock-msrs" section that contains the new data. This way, if a
vendor backports the fix, it doesn't mess up with the section version
numbers.

We could improve the API to make it easier to do, or maybe even improve
the protocol/format to make the "subsection" representation more
compact. Either way, my point is that using names to track new
capabilities sounds better than having to agree on capability bits.


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