From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1LaXwF-0008Ug-N6
	for qemu-devel@nongnu.org; Fri, 20 Feb 2009 11:09:19 -0500
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1LaXwE-0008UR-4S
	for qemu-devel@nongnu.org; Fri, 20 Feb 2009 11:09:18 -0500
Received: from [199.232.76.173] (port=54527 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1LaXwD-0008UO-UT
	for qemu-devel@nongnu.org; Fri, 20 Feb 2009 11:09:17 -0500
Received: from mx20.gnu.org ([199.232.41.8]:34430)
	by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32)
	(Exim 4.60) (envelope-from <paul@codesourcery.com>)
	id 1LaXwC-0006PA-Te
	for qemu-devel@nongnu.org; Fri, 20 Feb 2009 11:09:17 -0500
Received: from mail.codesourcery.com ([65.74.133.4])
	by mx20.gnu.org with esmtp (Exim 4.60)
	(envelope-from <paul@codesourcery.com>) id 1LaXwB-00050w-4H
	for qemu-devel@nongnu.org; Fri, 20 Feb 2009 11:09:15 -0500
From: Paul Brook <paul@codesourcery.com>
Subject: Re: [Qemu-devel] [RFC] More robust migration
Date: Fri, 20 Feb 2009 16:09:11 +0000
References: <499EBFD8.50307@amd.com> <499EC92E.9000401@codemonkey.ws>
In-Reply-To: <499EC92E.9000401@codemonkey.ws>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200902201609.11547.paul@codesourcery.com>
Reply-To: qemu-devel@nongnu.org
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: qemu-devel@nongnu.org

> > In general I would like to know whether QEMU migration is intended to
> > be used in such a flexible manner or whether the requirement of the
> > exact same software version on both side is not a limitation in
> > everyday use.
>
> My primary goal for migration is robustness.  I do not think it's a good
> idea to support any circumstances that could introduce changes in guest
> visible state during a live migration.
>
> Live migration is a critical feature for many production environments.
> To be useful IMHO, it has to be bullet-proof.

I agree.

I suspect that in practice live migration of a VM between different qemu 
versions ends up comparable to in-place live kernel upgrades. i.e. it takes 
an awful lot of work and care to make it happen, and in practice isn't going 
to happen for any particularly useful span of versions.

Paul