From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:59867) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VcleD-0004kh-CV for qemu-devel@nongnu.org; Sat, 02 Nov 2013 20:34:40 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Vcle5-0001hS-OK for qemu-devel@nongnu.org; Sat, 02 Nov 2013 20:34:32 -0400 Received: from mail-pb0-f48.google.com ([209.85.160.48]:39461) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vcle5-0001hO-Ht for qemu-devel@nongnu.org; Sat, 02 Nov 2013 20:34:25 -0400 Received: by mail-pb0-f48.google.com with SMTP id mc17so5708381pbc.35 for ; Sat, 02 Nov 2013 17:34:24 -0700 (PDT) Message-ID: <52759A06.5000101@ozlabs.ru> Date: Sun, 03 Nov 2013 11:34:14 +1100 From: Alexey Kardashevskiy MIME-Version: 1.0 References: <5253C514.6090103@ozlabs.ru> <5273B7BF.6080404@redhat.com> In-Reply-To: <5273B7BF.6080404@redhat.com> Content-Type: text/plain; charset=KOI8-R Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] savevm/loadvm List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Max Reitz , "qemu-devel@nongnu.org" Cc: Kevin Wolf On 11/02/2013 01:16 AM, Max Reitz wrote: > Hi, > > Sorry I'm just now replying to this. I ran into the same issue (and > another one) and it should be fixed by the upstream commits > eedff66f21e542650d895801549ce05ac108278b and > 6e13610aa454beba52944e8df6d93158d68ab911. Those have been merged to > master yesterday, so could you re-build qemu from master and try again? Yes, this works now, thanks! > Kind regards, > > Max > > > On 08.10.2013 10:40, Alexey Kardashevskiy wrote: >> 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