From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KxnXP-0001VN-4y for qemu-devel@nongnu.org; Wed, 05 Nov 2008 13:55:31 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KxnXN-0001Ui-HX for qemu-devel@nongnu.org; Wed, 05 Nov 2008 13:55:30 -0500 Received: from [199.232.76.173] (port=57978 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KxnXN-0001Ue-9j for qemu-devel@nongnu.org; Wed, 05 Nov 2008 13:55:29 -0500 Received: from main.gmane.org ([80.91.229.2]:52920 helo=ciao.gmane.org) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1KxnXM-0003nY-K9 for qemu-devel@nongnu.org; Wed, 05 Nov 2008 13:55:28 -0500 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1KxnXG-0007mG-Qe for qemu-devel@nongnu.org; Wed, 05 Nov 2008 18:55:22 +0000 Received: from rrcs-71-41-149-67.sw.biz.rr.com ([71.41.149.67]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 05 Nov 2008 18:55:22 +0000 Received: from Charles_Duffy by rrcs-71-41-149-67.sw.biz.rr.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 05 Nov 2008 18:55:22 +0000 From: Charles Duffy Date: Wed, 05 Nov 2008 12:55:14 -0600 Message-ID: References: <49113157.3090101@codemonkey.ws> <4911514C.1070300@redhat.com> <4911A934.9040007@codemonkey.ws> <20081105141901.GL25523@redhat.com> <4911B7D2.2050304@codemonkey.ws> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit In-Reply-To: <4911B7D2.2050304@codemonkey.ws> Sender: news Subject: [Qemu-devel] Re: Live migration - exec: support to be reintroduced? 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 Anthony Liguori wrote: > Daniel P. Berrange wrote: >> 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. > > This is a fundamentally broken concept. You cannot just save the > guest's memory state without saving the current state of the storage. Oh -- let me follow up on how this works in libvirt: The "save" and "restore" commands shut down and start the VM when invoked; consequently, no storage changes are made while the VM is down. Restoring more than once off the same "save" is not an intended use case.