From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LAskF-0006KJ-TP for qemu-devel@nongnu.org; Thu, 11 Dec 2008 16:06:51 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LAskF-0006Jj-4w for qemu-devel@nongnu.org; Thu, 11 Dec 2008 16:06:51 -0500 Received: from [199.232.76.173] (port=33323 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LAskE-0006Jb-PI for qemu-devel@nongnu.org; Thu, 11 Dec 2008 16:06:50 -0500 Received: from savannah.gnu.org ([199.232.41.3]:36406 helo=sv.gnu.org) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1LAskE-0007ce-7f for qemu-devel@nongnu.org; Thu, 11 Dec 2008 16:06:50 -0500 Received: from cvs.savannah.gnu.org ([199.232.41.69]) by sv.gnu.org with esmtp (Exim 4.63) (envelope-from ) id 1LAskD-0008Ve-Ow for qemu-devel@nongnu.org; Thu, 11 Dec 2008 21:06:49 +0000 Received: from aliguori by cvs.savannah.gnu.org with local (Exim 4.63) (envelope-from ) id 1LAskD-0008VZ-HW for qemu-devel@nongnu.org; Thu, 11 Dec 2008 21:06:49 +0000 MIME-Version: 1.0 Errors-To: aliguori Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit From: Anthony Liguori Message-Id: Date: Thu, 11 Dec 2008 21:06:49 +0000 Subject: [Qemu-devel] [5985] Fix handling of disk-only snapshots (Kevin Wolf) Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Revision: 5985 http://svn.sv.gnu.org/viewvc/?view=rev&root=qemu&revision=5985 Author: aliguori Date: 2008-12-11 21:06:49 +0000 (Thu, 11 Dec 2008) Log Message: ----------- Fix handling of disk-only snapshots (Kevin Wolf) When creating a snapshot with multiple qcow2 disks attached, the current behaviour is that qemu creates a disk snapshot on all of them and chooses one to write the VM state to. Despite having the state only in one image, loadvm tries to restore the VM state from the middle of nowhere if you run qemu a second time with only one of the other images attached. In the lucky case it will fail because there simply is no state, but it also can happen that it loads the state of a different snapshot (the one this new one is based upon). The fix is to write a zero VM state size to the images which don't contain the state, and check this in loadvm. I agree that you probably have to provoke such things intentionally to get in a state like this with qemu itself. However, with my second patch that adds snapshot support to qemu-img it could become a reasonable use case to have snapshots with and without VM states on the same image. Signed-off-by: Kevin Wolf Signed-off-by: Anthony Liguori Modified Paths: -------------- trunk/savevm.c Modified: trunk/savevm.c =================================================================== --- trunk/savevm.c 2008-12-11 21:03:10 UTC (rev 5984) +++ trunk/savevm.c 2008-12-11 21:06:49 UTC (rev 5985) @@ -1020,6 +1020,7 @@ BlockDriverInfo bdi1, *bdi = &bdi1; QEMUFile *f; int saved_vm_running; + uint32_t vm_state_size; #ifdef _WIN32 struct _timeb tb; #else @@ -1079,7 +1080,7 @@ goto the_end; } ret = qemu_savevm_state(f); - sn->vm_state_size = qemu_ftell(f); + vm_state_size = qemu_ftell(f); qemu_fclose(f); if (ret < 0) { term_printf("Error %d while writing VM\n", ret); @@ -1098,6 +1099,8 @@ bdrv_get_device_name(bs1)); } } + /* Write VM state size only to the image that contains the state */ + sn->vm_state_size = (bs == bs1 ? vm_state_size : 0); ret = bdrv_snapshot_create(bs1, sn); if (ret < 0) { term_printf("Error while creating snapshot on '%s'\n", @@ -1115,6 +1118,7 @@ { BlockDriverState *bs, *bs1; BlockDriverInfo bdi1, *bdi = &bdi1; + QEMUSnapshotInfo sn; QEMUFile *f; int i, ret; int saved_vm_running; @@ -1165,6 +1169,11 @@ return; } + /* Don't even try to load empty VM states */ + ret = bdrv_snapshot_find(bs, &sn, name); + if ((ret >= 0) && (sn.vm_state_size == 0)) + goto the_end; + /* restore the VM state */ f = qemu_fopen_bdrv(bs, bdi->vm_state_offset, 0); if (!f) {