From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NCvhr-0000wZ-Ff for qemu-devel@nongnu.org; Tue, 24 Nov 2009 08:45:23 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NCvhm-0000qn-4G for qemu-devel@nongnu.org; Tue, 24 Nov 2009 08:45:22 -0500 Received: from [199.232.76.173] (port=59750 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NCvhl-0000qQ-Qk for qemu-devel@nongnu.org; Tue, 24 Nov 2009 08:45:17 -0500 Received: from mail-yx0-f188.google.com ([209.85.210.188]:38111) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NCvhl-0007bK-GW for qemu-devel@nongnu.org; Tue, 24 Nov 2009 08:45:17 -0500 Received: by yxe26 with SMTP id 26so5493151yxe.4 for ; Tue, 24 Nov 2009 05:45:17 -0800 (PST) Message-ID: <4B0BE369.2000807@codemonkey.ws> Date: Tue, 24 Nov 2009 07:45:13 -0600 From: Anthony Liguori MIME-Version: 1.0 References: <4B0952C9.9010803@redhat.com> <4B095D86.700@codemonkey.ws> <20091124132154.GE2405@redhat.com> In-Reply-To: <20091124132154.GE2405@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: "Michael S. Tsirkin" Cc: dlaor@redhat.com, qemu-devel 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? Regards, Anthony Liguori