From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NCvxl-0002Ty-R5 for qemu-devel@nongnu.org; Tue, 24 Nov 2009 09:01:49 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NCvxg-0002RO-GZ for qemu-devel@nongnu.org; Tue, 24 Nov 2009 09:01:49 -0500 Received: from [199.232.76.173] (port=33348 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NCvxg-0002RF-AP for qemu-devel@nongnu.org; Tue, 24 Nov 2009 09:01:44 -0500 Received: from mx1.redhat.com ([209.132.183.28]:7486) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NCvxf-0001Vk-O5 for qemu-devel@nongnu.org; Tue, 24 Nov 2009 09:01:43 -0500 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id nAOE1gW2025324 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 24 Nov 2009 09:01:43 -0500 Date: Tue, 24 Nov 2009 15:59:06 +0200 From: "Michael S. Tsirkin" Message-ID: <20091124135906.GJ2405@redhat.com> References: <4B0952C9.9010803@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: dlaor@redhat.com, qemu-devel On Mon, Nov 23, 2009 at 01:15:01PM +0100, Juan Quintela wrote: > Dor Laor wrote: > > In the last couple of days we discovered some issues regarding stable > > ABI and the robustness of the live migration protocol. Let's just jump > > right into it, ordered by complexity: > > > > 1. Control *every* feature exposed to the guest by qemu cmdline: > > > > While thinking on cross version migration, and reviewing some > > patches, I noticed that there are many times that we use feature bits > > in order to expose functionality for the guest driver - example: > > VIRTIO_BLK_F_BARRIER, but we do not control it from qemu cmdline. > > In my opinion this is madness, qemu command line is already too > complicated. I agree with anthony to put it in the command line. > I will go further, and think that this kind of issues should be put into > the machine type. > > If you start qemu with -M pc-0.10, it should save the state in a 0.10 > compatible way (that don't happens at the moment, but it should work > that way). The way you save state is fundamentally different from what you have in the machine. It's easy to imagine where you migrate qemu-1.0 to qemu-2.0 to qemu-3.0. There's no reason I can see to use 1.0 format in the second step in the process, and not requiring it will make it easier for us to get rid of old format support in the future. -- MST