From: Sam Bobroff <sam.bobroff@au1.ibm.com>
To: qemu-devel@nongnu.org
Subject: [Qemu-devel] Question about odd snapshot behaviour
Date: Mon, 19 Oct 2015 16:27:01 +1100 [thread overview]
Message-ID: <20151019052701.GA6500@tungsten.ozlabs.ibm.com> (raw)
Hi all,
While working through the QEMU code that saves and loads snapshots, I've
noticed some confusing behaviour when using named VM snapshots that may need to
be fixed somehow. This is what I've noticed:
* If I create two empty qcow2 filesystems: fs1.qcow2 and fs2.qcow2:
* e.g. qemu-image create -f qcow2 fs1.qcow2 10G
* e.g. qemu-image create -f qcow2 fs2.qcow2 10G
* Then boot the guest with the above filesystems as hda and hdb (my guest's rootfs
is an initramfs, not either of these):
* e.g. qemu-system-ppc64 ... -hda fs1.qcow2 -hdb fs2.qcow2
* In the QEMU monitor, create a blockdev snapshot on hd2 called "foo":
e.g. snapshot_blkdev_internal scsi0-hd1 foo
* Check fs2 on the host command line:
e.g. qemu-img snapshot -l fs2.qcow2
Snapshot list:
ID TAG VM SIZE DATE VM CLOCK
1 foo 0 2015-10-19 15:56:29 00:00:20.969
* In the QEMU monitor, save the vm state as "bar":
e.g. savevm bar
* Check the snapshot on fs1:
e.g. info snapshots
ID TAG VM SIZE DATE VM CLOCK
1 bar 215M 2015-10-19 04:57:13 00:01:05.589
* Check fs2 again on the host command line:
e.g. qemu-img snapshot -l fs2.qcow2
Snapshot list:
ID TAG VM SIZE DATE VM CLOCK
1 foo 0 2015-10-19 15:56:29 00:00:20.969
2 bar 0 2015-10-19 15:57:13 00:01:05.589
* Now the fun part: overwrite the bar snapshot on fs1 by ID:
* savevm 1
* Examine the results from the monitor:
* e.g. info snapshots
There is no suitable snapshot available
* Examine fs1 and fs2 from the command line:
* e.g. qemu-img snapshot -l fs1.qcow2
Snapshot list:
ID TAG VM SIZE DATE VM CLOCK
1 bar 215M 2015-10-19 16:00:45 00:04:36.065
* e.g. qemu-img snapshot -l fs2.qcow2
Snapshot list:
ID TAG VM SIZE DATE VM CLOCK
2 bar 0 2015-10-19 15:57:13 00:01:05.589
3 bar 0 2015-10-19 16:00:45 00:04:36.065
So what seems odd is:
* QEMU has lost the bar snapshot on fs1, although qemu-img still shows
it and it re-appears in QEMU if the guest is started with only
hd1.qcow attached.
* QEMU has deleted the snapshot named "foo" on hd2, even though we issued
"savevm 1" and the old snapshot (on hd1) with ID 1 was named "bar". This
surprised me.
* QEMU has created a snapshot on hd2 with a duplicate name ("bar") and if we
issue a "loadvm bar" QEMU loads the snapshot with ID 1 on hd1 and the first
snapshot with the name "bar" on hd2 which is the one with ID 2. That is not
the snapshot that matches the vm state (which is the one with ID 3) and
presumably can lead to filesystem corruption on hd2.
Do these seem like bugs? Should I try to find a way to fix some or all of them?
(Note: I checked the launchpad bug list but didn't see these listed.)
Cheers,
Sam.
next reply other threads:[~2015-10-19 5:28 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-10-19 5:27 Sam Bobroff [this message]
2015-10-19 12:50 ` [Qemu-devel] Question about odd snapshot behaviour Kevin Wolf
2015-10-22 23:54 ` Sam Bobroff
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20151019052701.GA6500@tungsten.ozlabs.ibm.com \
--to=sam.bobroff@au1.ibm.com \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).