From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=54504 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Q4FHU-0008VU-Ib for qemu-devel@nongnu.org; Mon, 28 Mar 2011 12:27:08 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Q4FHO-0004ml-92 for qemu-devel@nongnu.org; Mon, 28 Mar 2011 12:26:59 -0400 Received: from mail.seclab.tuwien.ac.at ([128.130.60.29]:37455) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Q4FHN-0004j1-W7 for qemu-devel@nongnu.org; Mon, 28 Mar 2011 12:26:58 -0400 From: Clemens Kolbitsch Subject: Re: [Qemu-devel] Relative/Absolute timing snapshot problem Date: Mon, 28 Mar 2011 09:25:57 -0700 References: <201103181339.33709.ck@iseclab.org> <4D906F99.9080808@redhat.com> In-Reply-To: <4D906F99.9080808@redhat.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <201103280925.57531.ck@iseclab.org> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jes Sorensen Cc: qemu-devel@nongnu.org > On 03/18/11 21:39, Clemens Kolbitsch wrote: > > Hi list, > > > > strange situation: When I create a snapshot using Qemu 0.14.0 stable, > > everything works smoothly and resuming the CPU takes about 1-2 seconds. > > If I don't use the snapshot file for some time, the time it takes to > > resume grows by 2-3 seconds per day. At the moment, I'm looking at a > > snapshot file from last week and it takes nearly 30 seconds to load. > > > > Funny thing about it: if I turn my system time back to the date when the > > snapshot was created (or before that), resuming CPU works within the > > expected 1-2 seconds. I have _very briefly_ looked into it and it seems > > like Qemu spends an aweful long amount of time catching up with timer > > execution -- is it possible that these are stored using absolute time > > instead of relative timing? > > > > I am using qcow2 file format, because I absolutely rely on CPU-snapshots > > and support for base-files. I have read here and there that it is more > > or less broken (or at least very slow), but with the correct > > cache-options it works for me (except for this bug, of course). > > > > Has anyone encountered this or should I start looking into it (although I > > have some experience with the core source, I'm not very experienced with > > the snapshotting code). > > Hi Clemens, > > Could you clarify what you are doing, when you say snapshot do you mean > a savevm operation (ie. checkpoint) or a disk snapshot? > > Cheers, > Jes I Jes, sorry for not being clear: I use a savevm operation. Following setup: I have a base file (qcow2 or qew format) and a snapshot file (generated via 'qemu-img create -b -f qcow2 ') and boot the snapshot file. Once the system (WinXP SP3 guest) has fully started, I create a snapshot (savevm ) and exit the emulator. Later, I resume the snapshot by starting Qemu with the snapshotfile and say 'loadvm '. Actually, I found that the times I gave in my last email were way underestimated. The time difference is MUCH larger than 2-3 seconds per day. A week-old snapshot can take minutes to load on a reasonably idle host machine. --Clemens