[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] Relative/Absolute timing snapshot problem
From: |
Jes Sorensen |
Subject: |
Re: [Qemu-devel] Relative/Absolute timing snapshot problem |
Date: |
Mon, 28 Mar 2011 13:23:05 +0200 |
User-agent: |
Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.15) Gecko/20110307 Fedora/3.1.9-0.39.b3pre.fc14 Thunderbird/3.1.9 |
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