[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [Bug 1184089] Re: [Feature request] loadvm snapshot as
From: |
Stefan Hajnoczi |
Subject: |
Re: [Qemu-devel] [Bug 1184089] Re: [Feature request] loadvm snapshot as read-only |
Date: |
Tue, 28 May 2013 10:22:36 +0200 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
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
- [Qemu-devel] [PATCH v4 01/12] target-i386/helper: remove EAX macro, liguang, 2013/05/28
- [Qemu-devel] [PATCH v4 02/12] target-i386/helper: remove EBX macro, liguang, 2013/05/28
- [Qemu-devel] [PATCH v4 08/12] target-i386/helper: remove EDI macro, liguang, 2013/05/28
- [Qemu-devel] [PATCH v4 03/12] target-i386/helper: remove ECX macro, liguang, 2013/05/28
- [Qemu-devel] [PATCH v4 07/12] target-i386/helper: remove ESI macro, liguang, 2013/05/28
- [Qemu-devel] [PATCH v4 05/12] target-i386/helper: remove EBP macro, liguang, 2013/05/28
- [Qemu-devel] [PATCH v4 06/12] target-i386/helper: remove ESP macro, liguang, 2013/05/28
- [Qemu-devel] [PATCH v4 10/12] target-i386/helper: remove DF macro, liguang, 2013/05/28
- [Qemu-devel] [PATCH v4 09/12] target-i386/helper: remove EIP macro, liguang, 2013/05/28
- [Qemu-devel] [PATCH v4 04/12] target-i386/helper: remove EDX macro, liguang, 2013/05/28
- [Qemu-devel] [PATCH v4 11/12] target-i386/helper: remove redundant env->eip assignment, liguang, 2013/05/28