From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1Kxjjq-0004Ly-Mh
	for qemu-devel@nongnu.org; Wed, 05 Nov 2008 09:52:06 -0500
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1Kxjjo-0004KQ-US
	for qemu-devel@nongnu.org; Wed, 05 Nov 2008 09:52:05 -0500
Received: from [199.232.76.173] (port=55211 helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1Kxjjn-0004K6-RA
	for qemu-devel@nongnu.org; Wed, 05 Nov 2008 09:52:04 -0500
Received: from mail2.shareable.org ([80.68.89.115]:48092)
	by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32)
	(Exim 4.60) (envelope-from <jamie@shareable.org>) id 1Kxjjn-0005n9-9s
	for qemu-devel@nongnu.org; Wed, 05 Nov 2008 09:52:03 -0500
Date: Wed, 5 Nov 2008 14:52:01 +0000
From: Jamie Lokier <jamie@shareable.org>
Subject: Re: [Qemu-devel] Live migration - exec: support to be reintroduced?
Message-ID: <20081105145201.GI13630@shareable.org>
References: <geqq17$om7$1@ger.gmane.org> <49113157.3090101@codemonkey.ws>
	<4911514C.1070300@redhat.com> <4911A934.9040007@codemonkey.ws>
	<20081105141901.GL25523@redhat.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20081105141901.GL25523@redhat.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: "Daniel P. Berrange" <berrange@redhat.com>, qemu-devel@nongnu.org

Daniel P. Berrange wrote:
> > However, why is it not just using savevm?  Saving the CPU state in the 
> > absence of checkpointing storage doesn't make a lot of sense.
> 
> This isn't for snapshotting, so checkpointing of storage is unneccessary.
> This is just straight save+restore, akin to hibernate-to-disk for a 
> physical machine. 
> 
> The savevm command only works with qcow files, which is not guarenteed
> to be available in this context.
> 
> We do intend to support real snapshotting of VMs at some point, for which
> "savevm" could be useful

Yes, we had a thread a couple of months ago about why "savevm"
snapshotting in qcow2 is not always appropriate or useful.

-- Jamie