[Feature request] loadvm snapshot as read-only

[Michael Coppola]

There are many ways to take and manage snapshots in QEMU, but one main feature that's missing is the ability to 'loadvm' a LIVE snapshot and have all future changes redirected to a temporary file. This would effectively be combining the -loadvm and -snapshot switches and make the snapshot read-only. With this feature, users would be provided a "sandbox" and be able to start and restart the same live snapshot without corrupting the image in doing so.

I found a lot of discussion about this topic on the mailing list years ago, including some patch submissions, but none of the conversations panned out.

http://lists.gnu.org/archive/html/qemu-discuss/2011-10/msg00011.html
http://copilotco.com/mail-archives/qemu.2008/msg00072.html
http://web.archiveorange.com/archive/v/1XS1vcusGInZKG2e0ImX
http://marc.info/?l=qemu-devel&m=117191084713590

What would it take for this feature to be added, and can we use the patches submitted by Eddie Kohler to enable this feature?

[Stefan Hajnoczi (stefanha)]

On Sat, May 25, 2013 at 08:29:11AM -0000, Michael Coppola wrote:
> There are many ways to take and manage snapshots in QEMU, but one main
> feature that's missing is the ability to 'loadvm' a LIVE snapshot and
> have all future changes redirected to a temporary file. This would
> effectively be combining the -loadvm and -snapshot switches and make the
> snapshot read-only. With this feature, users would be provided a
> "sandbox" and be able to start and restart the same live snapshot
> without corrupting the image in doing so.

This should be possible soon. Wenchao Xia is working on new monitor
commands that allow you to combine internal snapshots (loadvm/savevm)
with external snapshots (blockdev-snapshot-sync).

You would submit a QMP 'transaction' command that specifies a loadvm
followed by a blockdev-snapshot-sync. This operation is atomic.

Note that internal snapshots do not destroy the snapshot. Therefore,
when you loadvm an internal snapshot and write to the disk, you are not
modifying the internal snapshot only the current state of the disk. You
can loadvm it again later.

Stefan

[Michael Coppola (mncoppola)]

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).

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.

[Stefan Hajnoczi (stefanha)]

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

[Thomas Huth (th-huth)]

The QEMU project is currently considering to move its bug tracking to another system. For this we need to know which bugs are still valid and which could be closed already. Thus we are setting older bugs to "Incomplete" now.
If you still think this bug report here is valid, then please switch the state back to "New" within the next 60 days, otherwise this report will be marked as "Expired". Or mark it as "Fix Released" if the problem has been solved with a newer version of QEMU already. Thank you and sorry for the inconvenience.

[Launchpad Janitor (janitor)]

[Expired for QEMU because there has been no activity for 60 days.]