From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=49659 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Q4AY8-0000v5-UV for qemu-devel@nongnu.org; Mon, 28 Mar 2011 07:23:57 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Q4AY4-0000wy-1H for qemu-devel@nongnu.org; Mon, 28 Mar 2011 07:23:53 -0400 Received: from mx1.redhat.com ([209.132.183.28]:28763) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Q4AY3-0000wl-KF for qemu-devel@nongnu.org; Mon, 28 Mar 2011 07:23:51 -0400 Message-ID: <4D906F99.9080808@redhat.com> Date: Mon, 28 Mar 2011 13:23:05 +0200 From: Jes Sorensen MIME-Version: 1.0 Subject: Re: [Qemu-devel] Relative/Absolute timing snapshot problem References: <201103181339.33709.ck@iseclab.org> In-Reply-To: <201103181339.33709.ck@iseclab.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Clemens Kolbitsch 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