From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from [140.186.70.92] (port=50151 helo=eggs.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1Ott2Z-0006Ea-9B
	for qemu-devel@nongnu.org; Thu, 09 Sep 2010 22:08:36 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69)
	(envelope-from <anthony@codemonkey.ws>) id 1Ott2X-0006oh-Ps
	for qemu-devel@nongnu.org; Thu, 09 Sep 2010 22:08:35 -0400
Received: from mail-iw0-f173.google.com ([209.85.214.173]:49890)
	by eggs.gnu.org with esmtp (Exim 4.69)
	(envelope-from <anthony@codemonkey.ws>) id 1Ott2X-0006oX-Ll
	for qemu-devel@nongnu.org; Thu, 09 Sep 2010 22:08:33 -0400
Received: by iwn38 with SMTP id 38so1743713iwn.4
	for <qemu-devel@nongnu.org>; Thu, 09 Sep 2010 19:08:32 -0700 (PDT)
Message-ID: <4C89931C.1010605@codemonkey.ws>
Date: Thu, 09 Sep 2010 21:08:28 -0500
From: Anthony Liguori <anthony@codemonkey.ws>
MIME-Version: 1.0
Subject: Re: [Qemu-devel] [PATCH] [RFC] savevm only saves disk state
References: <1284083014-8198-1-git-send-email-disheng.su@gmail.com>
In-Reply-To: <1284083014-8198-1-git-send-email-disheng.su@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
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.nongnu.org/archive/html/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: disheng.su@gmail.com
Cc: qemu-devel@nongnu.org, edison <edison@cloud.com>

On 09/09/2010 08:43 PM, disheng.su@gmail.com wrote:
> From: edison<edison@cloud.com>
>
> Add a new option when "savevm": savevm -n snapshotName, which only takes snapshot on disk, but doesn't save vm state(memory,cpu,devices...).
> Saving vm state on QCOW2 disk will take a long time, per my test, it will take 1~2 minutes to "savevm" on VM with 1G memory. Even worse, the VM is wholely stopped at that time, makes "savevm" not that useful.
> All we know the side effect of it:) but does it make sense to give user the choice?
>    

I think it would be better to explore ways to make savevm live.  A round 
about option would be to combine a disk-only snapshot with a live 
migration to disk and somehow allow qcow2 to refer to an external memory 
snapshot.

A better alternative would be a live snapshot within qcow2.  I think 
Kevin has some good ideas about how to do this with qcow2 today but 
provided we had a nice interface to do this, the changes to the live 
migration code should be fairly straight forward.

Regards,

Anthony Liguori