From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NCaOo-0005Y3-8P for qemu-devel@nongnu.org; Mon, 23 Nov 2009 10:00:18 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NCaOj-0005VQ-Fa for qemu-devel@nongnu.org; Mon, 23 Nov 2009 10:00:17 -0500 Received: from [199.232.76.173] (port=33294 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NCaOj-0005V1-4q for qemu-devel@nongnu.org; Mon, 23 Nov 2009 10:00:13 -0500 Received: from mail-bw0-f228.google.com ([209.85.218.228]:45808) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NCaOi-0007Nb-9T for qemu-devel@nongnu.org; Mon, 23 Nov 2009 10:00:12 -0500 Received: by bwz28 with SMTP id 28so5744395bwz.17 for ; Mon, 23 Nov 2009 07:00:11 -0800 (PST) Message-ID: <4B0AA375.2000003@codemonkey.ws> Date: Mon, 23 Nov 2009 09:00:05 -0600 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: Live migration protocol, device features, ABIs and other beasts References: <4B0952C9.9010803@redhat.com> <4B095D86.700@codemonkey.ws> <4B09F0CA.3060705@codemonkey.ws> <1258983457-sup-5031@blackpad.lan.raisama.net> <4B0A9A64.2090109@redhat.com> In-Reply-To: <4B0A9A64.2090109@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: Eduardo Habkost , qemu-devel Paolo Bonzini wrote: > On 11/23/2009 02:51 PM, Eduardo Habkost wrote: >> Right, but I wouldn't be surprised if a user complains that "I know that >> my guest don't use that VM feature, so I want to be able to migrate to >> an older version anyway". > > That's a bit more tricky. What if the older version doesn't support > sound (just making up an example) and you know that you're not using a > client that plays sound, but still the sound card is part of the > machine? I think there is no doubt that the migration (or > save/restore) should be aborted in that case. > > I would not generalize very much, the problem that Dor posed is very > specific and probably quite rare. However, it's real. I think the problem is that you shouldn't be changing the guest visible state in a stable update of qemu. If you change the guest visible state in a stable update, then you won't be able to support live migration between arbitrary stable versions. You can't introduce features without introducing forward compatibility issues. If you're adding new guest visible state, you've added a feature. This is not a live migration problem, this is a problem with your stable branch policy. Regards, Anthony Liguori > Paolo