On Wed, Nov 25, 2009 at 04:10:34PM +0100, Juan Quintela wrote: > "Michael S. Tsirkin" <m...@redhat.com> 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