From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1K5Fyw-0000YG-SZ for qemu-devel@nongnu.org; Sun, 08 Jun 2008 04:10:30 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1K5Fyv-0000XU-Og for qemu-devel@nongnu.org; Sun, 08 Jun 2008 04:10:30 -0400 Received: from [199.232.76.173] (port=58625 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1K5Fyv-0000XG-IE for qemu-devel@nongnu.org; Sun, 08 Jun 2008 04:10:29 -0400 Received: from xenbox.codefidence.com ([92.48.73.16]:57061) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1K5Fyv-0003kt-2b for qemu-devel@nongnu.org; Sun, 08 Jun 2008 04:10:29 -0400 Received: from [192.168.1.106] (l192-117-111-195.broadband.actcom.net.il [192.117.111.195]) by xenbox.codefidence.com (Postfix) with ESMTP id CF97324261 for ; Sun, 8 Jun 2008 04:10:08 -0400 (EDT) Message-ID: <484B93E0.5020801@codefidence.com> Date: Sun, 08 Jun 2008 11:10:08 +0300 From: Shahar Livne MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH] cut large snapshot startup time (Vista runs in 5 secs) References: <48315413.9080005@codefidence.com> In-Reply-To: Content-Type: multipart/mixed; boundary="------------040101070906080700050200" 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 This is a multi-part message in MIME format. --------------040101070906080700050200 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Andrzej - thank you for the remark. version_id increase is indeed a good way to track the change in the format, and I will be happy to implement it if the maintainers find interest in this improvement. It can also join the next version_id change, which may come from other reasons. For my purposes, I didn't have to work with the 2 formats in parallel, as I just ran one time conversion. The conversion was done by firing a modified qemu that read the static_ram in the old format, and wrote the static_ram back in the new format (patch attached). The converter was started with -S, so the VM never ran. When the monitor prompt appeared, I just asked for loadvm, delvm, savevm, quit, and the image was converted. A script did this job on the 500 old images which required conversion, and that was it. Another small remark: If the old image was saved while -usb flag in the qemu was present, it must be present also during the conversion, or else the usb related state is not saved. RAM saving depends on the current hardware. Shahar andrzej zaborowski wrote: > On 19/05/2008, Shahar Livne wrote: > >> It is important to mention that old snapshots must be converted once this >> patch is applied. >> > > Great finding, but if the snapshot format changes, you need to at > least attempt to detect old snapshots. Qemu has an easy mechanism for > this (note the version_id parameter, just increase it). > --------------040101070906080700050200 Content-Type: text/x-patch; name="qcow2-static-ram-format-converter.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="qcow2-static-ram-format-converter.patch" Index: vl.c =================================================================== --- vl.c (revision 688) +++ vl.c (revision 689) @@ -5788,6 +5788,10 @@ return 0; } +/* The PREV_BDRV_HASH_BLOCK_SIZE is used for converter */ +/* It can be set to the default of 1024, and then it */ +/* reads old format and writes new format */ +#define PREV_BDRV_HASH_BLOCK_SIZE 16384 #define BDRV_HASH_BLOCK_SIZE 16384 #define IOBUF_SIZE 4096 #define RAM_CBLOCK_MAGIC 0xfabe @@ -6013,7 +6017,7 @@ return -EINVAL; if (ram_decompress_open(s, f) < 0) return -EINVAL; - for(i = 0; i < phys_ram_size; i+= BDRV_HASH_BLOCK_SIZE) { + for(i = 0; i < phys_ram_size; i+= PREV_BDRV_HASH_BLOCK_SIZE) { #ifdef USE_KVM if (kvm_allowed && (i>=0xa0000) && (i<0xc0000)) /* do not access video-addresses */ continue; @@ -6023,7 +6027,7 @@ goto error; } if (buf[0] == 0) { - if (ram_decompress_buf(s, phys_ram_base + i, BDRV_HASH_BLOCK_SIZE) < 0) { + if (ram_decompress_buf(s, phys_ram_base + i, PREV_BDRV_HASH_BLOCK_SIZE) < 0) { fprintf(stderr, "Error while reading ram block address=0x%08x", i); goto error; } @@ -6041,7 +6045,7 @@ goto error; } if (bdrv_read(bs_table[bs_index], sector_num, phys_ram_base + i, - BDRV_HASH_BLOCK_SIZE / 512) < 0) { + PREV_BDRV_HASH_BLOCK_SIZE / 512) < 0) { fprintf(stderr, "Error while reading sector %d:%" PRId64 "\n", bs_index, sector_num); goto error; --------------040101070906080700050200--