From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=38240 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PmYJS-0007nx-AW for qemu-devel@nongnu.org; Mon, 07 Feb 2011 16:08:02 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PmWvl-0004by-78 for qemu-devel@nongnu.org; Mon, 07 Feb 2011 14:39:26 -0500 Received: from mail-wy0-f173.google.com ([74.125.82.173]:53614) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PmWvl-0004bk-1u for qemu-devel@nongnu.org; Mon, 07 Feb 2011 14:39:25 -0500 Received: by wyg36 with SMTP id 36so5137305wyg.4 for ; Mon, 07 Feb 2011 11:39:24 -0800 (PST) Message-ID: <4D504A5F.6070807@codemonkey.ws> Date: Mon, 07 Feb 2011 13:39:11 -0600 From: Anthony Liguori MIME-Version: 1.0 References: <20110207160751.GC25106@redhat.com> <1297096814.3518.43.camel@x201> <20110207165118.GH25106@redhat.com> In-Reply-To: <20110207165118.GH25106@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: new->old version migration List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Michael S. Tsirkin" Cc: Amit Shah , Alex Williamson , qemu list , Juan Quintela On 02/07/2011 10:51 AM, Michael S. Tsirkin wrote: > On Mon, Feb 07, 2011 at 09:40:14AM -0700, Alex Williamson wrote: > >> On Mon, 2011-02-07 at 18:07 +0200, Michael S. Tsirkin wrote: >> >>> New thread stated intentionally, the original patch is Message-ID: >>> <349e93a4cfc6e1effc1b681cae53f805fdb9624e.1296713825.git.amit.shah@redhat.com> >>> >>> On Thu, Feb 03, 2011 at 11:47:08AM +0530, Amit Shah wrote: >>> >>>> Add a compat property for older machine types. When this is used (via >>>> -M pc-0.13, for example), the new flow control mechanisms will not be >>>> used. This is done to keep migration from a machine started with older >>>> type on a pc-0.14+ qemu to an older machine working. >>>> >>>> The property is named 'flow_control' and defaults to on. >>>> >>>> Reported-by: Alex Williamson >>>> Signed-off-by: Amit Shah >>>> >>> So, I think there are two things that need to be agreed on: >>> >>> - Can we commit to support migration from new qemu version to an old one? >>> We haven't in the past but downstreams do want this, >>> so it makes sense to have the infrastructure upstream. >>> >> I think lack of testing is the primary thing preventing this. We can >> catch things like this in code review, but it's hard to commit to >> support it if we can't reliably catch problems. This one, we did catch, >> and I think it's useful to put Amit's fix upstream, even if other >> devices end up having issues. >> > It's not just testing. Look at the specific example. The requirement > for new->old migration makes us keep broken code without flow control > around. This will only increase with time and the mess here > is not limited to vmstate, unlike the old->new format which > generally makes us do conversion at load time, so it's contained. > I haven't looked closely at the specific example but subsections allow us to migrate a state only when it's value is not what the old version defaults to. This is the only way we can have our cake and eat it too. Anything less compromises integrity. Regards, Anthony Liguori > >>> - The infrastructure/command line option for such support. >>> We have the -M flags to describe the machine that >>> we are running, but that abstracts away guest-visible machine, >>> which the migration format is not. >>> Also, same qemu could migrate to any older version. >>> So I think we would have to add a flag (call it -V for now) >>> to savevm/migrate commands to specify the format to be used. >>> Naturally some machines would be incompatible with >>> specific -V values, that's nothing new. >>> >> This seems unnecessarily complicated. It makes sense to me that we >> should track both the guest visible machine and the migration data >> format with the same option. In fact, I can't think of a good reason >> for these ever being different and how we'd support it if they were. >> There's plenty wrong with the migration data format, but that's a longer >> term discussion, and I think this is appropriate given what we have >> today. >> >> Alex >> >> > Take the specific example. 0.13 has trouble under stress, it loses data. > -M 0.13 is needed if you created the guest under 0.14, to make upgrading > hypervisors seamless. > > This patch would force disabling flow control which > is not needed if both version being migrated between > are 0.14. > > >