From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LbZP3-00058w-0i for qemu-devel@nongnu.org; Mon, 23 Feb 2009 06:55:17 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LbZP1-00058c-Ei for qemu-devel@nongnu.org; Mon, 23 Feb 2009 06:55:16 -0500 Received: from [199.232.76.173] (port=57070 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LbZP1-00058S-4p for qemu-devel@nongnu.org; Mon, 23 Feb 2009 06:55:15 -0500 Received: from mx20.gnu.org ([199.232.41.8]:16309) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1LbZP0-0008Q9-Ob for qemu-devel@nongnu.org; Mon, 23 Feb 2009 06:55:14 -0500 Received: from mail.codesourcery.com ([65.74.133.4]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LbZOz-0002KU-0q for qemu-devel@nongnu.org; Mon, 23 Feb 2009 06:55:13 -0500 From: Paul Brook Subject: Re: [Qemu-devel] [RFC] More robust migration Date: Mon, 23 Feb 2009 11:55:08 +0000 References: <499EBFD8.50307@amd.com> <200902201647.27138.paul@codesourcery.com> <20090223035140.GA23719@shareable.org> In-Reply-To: <20090223035140.GA23719@shareable.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200902231155.09093.paul@codesourcery.com> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org On Monday 23 February 2009, Jamie Lokier wrote: > Paul Brook wrote (about resuming snapshots on a different QEMU): > > I'm not saying it's a useless feature, just that it's very extremely > > to do reliably, and for that reason unlikely to happen. An > > unreliable implementation (i.e. one that claims to migrate/snapshot, > > then breaks some of the time) is IMHO worse than nothing. > > Well, one which cannot resume from a snapshot at all unless you have > the original host and original QEMU/KVM around is pretty bad. I never said you need the same host. All the save/restore code should be host independent. It should be possible to save state on (say) i386 and restore on ppc64. Anything that prevents this is IMO a bug. For KVM you're likely to need a cpu with at least as many features as the old one, but that's the price you pay for using host hardware features. However different versions of qemu (i.e. qemu built from different sources) are a different question altogether. If you can't reproduce your old qemu binaries you have much larger problems. Paul