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

[Michael S. Tsirkin]

On Wed, Nov 25, 2009 at 04:10:34PM +0100, Juan Quintela wrote:
> "Michael S. Tsirkin" <address@hidden> wrote:
> > On Tue, Nov 24, 2009 at 08:33:11AM -0600, Anthony Liguori wrote:
> >> Michael S. Tsirkin wrote:
> >>> It's very easy: if their guest runs fine on the old qemu,
> >>> it should be safe to migrate there.
> >>>   
> >>
> >> "Runs fine" is a qualitative statement.  There is no way for qemu to  
> >> know whether a guest runs fine or not.
> >
> > The entity between the keyboard and chair is best placed to decide that.
> > That entity has already expressed the decision taken by running
> > the appropriate qemu monitor command.
> >
> >>  There is no way that we can make  
> >> that statement either.  It has to be something that is controlled higher  
> >> in the stack.
> 
> That this would be the 1st time that entity betwen keyboard and monitor
> shoot himself in the foot :)
> 
> I really think "strongly" that this "loose" migration is just searching
> problems.  If we want to create migration, we want the destination to
> consume/understand all the fields.  If any of the fields are not going
> to be used, they shouldn't be sent in the 1st place.  That this is
> managed by a negotiation phase at savevm time, or at a high level by a
> managing application, it don't matter.  If target don't
> understand/consume all info sent during migration -> migration fail.
> 
> Notice that this is "quantatitive" not "qualitative".  It is trivial to
> check if we have consumed everything or not.  If anything is missing,
> etc.  On the other way, when it is safe to not use same fields, that is
> way more complicated to state.  and that belongs to the managament
> aplication/savevm negotation, etc.  Not to the poor savevm protocol.
> 
> Later, Juan.

I agree. A proposed solution to that is a "savevm description file",
specifying savevm versions to use and/or which fields should be sent.

-- 
MST