From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([208.118.235.92]:59611)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <stefanha@gmail.com>) id 1UhFB8-0005Fv-Jj
	for qemu-devel@nongnu.org; Tue, 28 May 2013 04:22:53 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <stefanha@gmail.com>) id 1UhFB3-0000o6-47
	for qemu-devel@nongnu.org; Tue, 28 May 2013 04:22:46 -0400
Received: from mail-ea0-x229.google.com ([2a00:1450:4013:c01::229]:43143)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <stefanha@gmail.com>) id 1UhFB2-0000ns-Ug
	for qemu-devel@nongnu.org; Tue, 28 May 2013 04:22:41 -0400
Received: by mail-ea0-f169.google.com with SMTP id m14so4407900eaj.0
	for <qemu-devel@nongnu.org>; Tue, 28 May 2013 01:22:40 -0700 (PDT)
Date: Tue, 28 May 2013 10:22:36 +0200
From: Stefan Hajnoczi <stefanha@gmail.com>
Message-ID: <20130528082236.GF13368@stefanha-thinkpad.redhat.com>
References: <20130525082911.27253.67454.malonedeb@gac.canonical.com>
	<20130527224217.26583.40786.malone@wampee.canonical.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20130527224217.26583.40786.malone@wampee.canonical.com>
Subject: Re: [Qemu-devel] [Bug 1184089] Re: [Feature request] loadvm
 snapshot as read-only
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/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: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Bug 1184089 <1184089@bugs.launchpad.net>
Cc: qemu-devel@nongnu.org

On Mon, May 27, 2013 at 10:42:17PM -0000, Michael Coppola wrote:
> Awesome, looking forward to it.  I may be misunderstanding what's
> happening under the hood, but at least for me, calling 'loadvm' on a
> single snapshot over and over seems to work the first few times and then
> immediately blue screens the WinXP guest with PFN_LIST_CORRUPT.  I was
> under the assumption that all runtime modifications were being written
> back to the image, effectively "corrupting" something (whether it was
> changes to the snapshot or the "backing image" causing things to break).

savevm/loadvm does not use backing images.  It relies on internal
snapshot which are stored inside the existing qcow2 image file.

If you *are* using backing images then you're right - modifying the
backing image is likely to trigger weird guest behavior.

> Until then, I've seemed to have found a workaround for the feature
> itself.  Instead of creating a snapshot with 'savevm', I can start the
> VM with -snapshot and then call:
> 
> migrate "exec: gzip -c > snapshot.gz"
> 
> in QMP and it saves the live image to a compressed file.  Make sure it's
> completed migration before exiting with "info migrate".  Subsequently
> loading the snapshot with:
> 
> qemu-* <whatever flags> -incoming "exec: gzip -c -d snapshot.gz"
> -snapshot
> 
> will load the live snapshot and redirect all runtime modifications to a
> temp file.  http://www.linux-kvm.org/page/Migration says not to use
> -snapshot, but who follows the rules anyways? ;)  It seems to work so
> far and things haven't exploded yet.  Running md5sum on the qcow2 image
> and gzip snapshot before and after shows no changes to either files.

The reason that -snapshot isn't used together with migration is because
the disk state will be discarded and not migrated.

Stefan