qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
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.

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