From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NDKlu-0001ic-2x for qemu-devel@nongnu.org; Wed, 25 Nov 2009 11:31:14 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NDKlp-0001fm-FL for qemu-devel@nongnu.org; Wed, 25 Nov 2009 11:31:13 -0500 Received: from [199.232.76.173] (port=53766 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NDKlp-0001fh-DH for qemu-devel@nongnu.org; Wed, 25 Nov 2009 11:31:09 -0500 Received: from mx1.redhat.com ([209.132.183.28]:22162) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NDKlo-0000Yb-QC for qemu-devel@nongnu.org; Wed, 25 Nov 2009 11:31:09 -0500 Date: Wed, 25 Nov 2009 18:28:27 +0200 From: "Michael S. Tsirkin" Message-ID: <20091125162826.GA24454@redhat.com> References: <4B0952C9.9010803@redhat.com> <4B095D86.700@codemonkey.ws> <4B09F0CA.3060705@codemonkey.ws> <1258983457-sup-5031@blackpad.lan.raisama.net> <4B0AA202.2050001@codemonkey.ws> <20091124142811.GP2405@redhat.com> <4B0BEEA7.60006@codemonkey.ws> <20091124160552.GE6737@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: [Qemu-devel] Re: Live migration protocol, device features, ABIs and other beasts List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Juan Quintela Cc: Paolo Bonzini , Eduardo Habkost , qemu-devel On Wed, Nov 25, 2009 at 04:10:34PM +0100, Juan Quintela wrote: > "Michael S. Tsirkin" 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