From: Alexey Kardashevskiy <aik@ozlabs.ru>
To: "qemu-devel@nongnu.org" <qemu-devel@nongnu.org>
Cc: Kevin Wolf <kwolf@redhat.com>
Subject: [Qemu-devel] savevm/loadvm
Date: Tue, 08 Oct 2013 19:40:52 +1100 [thread overview]
Message-ID: <5253C514.6090103@ozlabs.ru> (raw)
Hi!
I need the community help with savevm/loadvm.
I run QEMU like this:
./qemu-system-ppc64 \
-drive file=virtimg/fc19_16GB.qcow2 \
-nodefaults \
-m "2048" \
-machine "pseries" \
-nographic \
-vga "none" \
-enable-kvm
The disk image is an 16GB qcow2 image.
Now I start the guest and do "savevm 1" and "loadvm 1" from the qemu
console. Everything works. Then I exit qemu, make sure that the snapshot is
there and run QEMU as above plus "-loadvm 1". It fails with:
qemu-system-ppc64: qcow2: Loading snapshots with different disk size is not
implemented
qemu-system-ppc64: Error -95 while activating snapshot '2' on 'scsi0-hd0'
The check is added by commit 90b277593df873d3a2480f002e2eb5fe1f8e5277
"qcow2: Save disk size in snapshot header".
As I cannot realize the whole idea of the patch, I looked a bit deeper.
This is the check:
int qcow2_snapshot_goto(BlockDriverState *bs, const char *snapshot_id)
{
[...]
if (sn->disk_size != bs->total_sectors * BDRV_SECTOR_SIZE) {
error_report("qcow2: Loading snapshots with different disk "
"size is not implemented");
ret = -ENOTSUP;
goto fail;
}
My understanding of the patch was that the disk_size should remain 16GB
(0x4.0000.0000) as it uses bs->total_sectors and never changes it. And
bs->growable is 0 for qcow2 image because it is not really growable. At
least the total_sectors value from the qcow2 file header does not change
between QEMU starts.
However qcow2_save_vmstate() sets bs->growable to 1 for a short time
(commit 178e08a58f40dd5aef2ce774fe0850f5d0e56918 from 2009) and this
triggers a branch in bdrv_co_do_writev() which changes bs->total_sectors.
So when QEMU writes snapshots to the file, the disk_size field of a
snapshot has bigger value (for example 0x4.007b.8180).
And the check above fails. It does not fail if to do "loadvm"
_in_the_same_run_ after "savevm" because QEMU operates with the updated
bs->total_sectors.
What the proper fix would be? Or it is not a bug at all and I should be
using something else for "-loadvm"? Thanks.
--
Alexey
next reply other threads:[~2013-10-08 8:41 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-10-08 8:40 Alexey Kardashevskiy [this message]
2013-10-08 9:04 ` [Qemu-devel] savevm/loadvm Paolo Bonzini
2013-10-08 9:23 ` Kevin Wolf
2013-10-08 9:33 ` Paolo Bonzini
2013-10-09 7:15 ` Alexey Kardashevskiy
2013-10-09 7:47 ` Paolo Bonzini
2013-10-10 3:50 ` Alexey Kardashevskiy
2013-10-16 6:51 ` Alexey Kardashevskiy
2013-11-01 13:22 ` Alexey Kardashevskiy
2013-11-01 14:16 ` Max Reitz
2013-11-03 0:34 ` Alexey Kardashevskiy
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=5253C514.6090103@ozlabs.ru \
--to=aik@ozlabs.ru \
--cc=kwolf@redhat.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.