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

[Anthony Liguori]

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