From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NCvu6-0000he-7Z for qemu-devel@nongnu.org; Tue, 24 Nov 2009 08:58:02 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NCvu1-0000g3-CJ for qemu-devel@nongnu.org; Tue, 24 Nov 2009 08:58:01 -0500 Received: from [199.232.76.173] (port=33282 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NCvu1-0000fx-9S for qemu-devel@nongnu.org; Tue, 24 Nov 2009 08:57:57 -0500 Received: from mx1.redhat.com ([209.132.183.28]:48130) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NCvu0-00015l-KW for qemu-devel@nongnu.org; Tue, 24 Nov 2009 08:57:57 -0500 Date: Tue, 24 Nov 2009 15:55:15 +0200 From: "Michael S. Tsirkin" Message-ID: <20091124135515.GI2405@redhat.com> References: <4B0952C9.9010803@redhat.com> <4B095D86.700@codemonkey.ws> <20091124132154.GE2405@redhat.com> <4B0BE369.2000807@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B0BE369.2000807@codemonkey.ws> 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: Anthony Liguori Cc: dlaor@redhat.com, qemu-devel On Tue, Nov 24, 2009 at 07:45:13AM -0600, Anthony Liguori wrote: > Michael S. Tsirkin wrote: >> On Sun, Nov 22, 2009 at 09:49:26AM -0600, Anthony Liguori wrote: >> >>>> We cannot even create a new 'hack section' for new code since the >>>> sections are ordered and expected to be exact match on the >>>> destination. >>>> >>>> The result is that new->old migration cannot work. This is not cross >>>> releases even! It means that even a small bug in current release >>>> prevents live migration between various instances of the code. >>>> It forces us to decide whether to fix pvclock migration issue vs >>>> allow new->old migration. Another ugly hack is to add cmdline that >>>> will control this behavior. Still it's a pain to mgmt stack and >>>> users. >>>> >>> This is a pretty normal policy (backwards compat but not forwards compat). >>> >> >> No one is asking that old qemu magically understands new format. It >> would be enough that new qemu is able to migrate to a format that old >> one understands. >> > > I've got no problem with that provided it's something explicitly > requested by the user. This requires no migration protocol change > though so if this is what folks are asking for, why is this thread > focused around changing the live migration protocol? I think the claim is that a section-based migration protocol would make implementing this easier than version-based one, especially for downstream which might cherry-pick a feature from a new release to an old one. It seems the requirement discussion and the implementation discussion are going on together in this thread. > Regards, > > Anthony Liguori > >