[Qemu-devel] Relative/Absolute timing snapshot problem

[Qemu-devel] Relative/Absolute timing snapshot problem

[Clemens Kolbitsch]

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).

Thanks,
Clemens

Re: [Qemu-devel] Relative/Absolute timing snapshot problem

[Jes Sorensen]

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

Re: [Qemu-devel] Relative/Absolute timing snapshot problem

[Clemens Kolbitsch]

> 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 <basefile> -f qcow2 <snapshotfile>') and 
boot the snapshot file. Once the system (WinXP SP3 guest) has fully started, I 
create a snapshot (savevm <foo>) and exit the emulator. Later, I resume the 
snapshot by starting Qemu with the snapshotfile and say 'loadvm <foo>'.

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

Re: [Qemu-devel] Relative/Absolute timing snapshot problem

[Jes Sorensen]

On 03/28/11 18:25, Clemens Kolbitsch wrote:
>> 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?
> 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 <basefile> -f qcow2 <snapshotfile>') and 
> boot the snapshot file. Once the system (WinXP SP3 guest) has fully started, I 
> create a snapshot (savevm <foo>) and exit the emulator. Later, I resume the 
> snapshot by starting Qemu with the snapshotfile and say 'loadvm <foo>'.
> 
> 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.

Ok, then I am pretty much in the dark on this one - I don't know
anything about the checkpoint/restart feature and the impact on things
like the clock. I only worked on the live snapshot code (for disk
snapshots).

Hopefully someone else will have an idea.

Cheers,
Jes

Re: [Qemu-devel] Relative/Absolute timing snapshot problem

[Blue Swirl]

On Mon, Mar 28, 2011 at 7:32 PM, Jes Sorensen <Jes.Sorensen@redhat.com> wrote:
> On 03/28/11 18:25, Clemens Kolbitsch wrote:
>>> 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?
>> 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 <basefile> -f qcow2 <snapshotfile>') and
>> boot the snapshot file. Once the system (WinXP SP3 guest) has fully started, I
>> create a snapshot (savevm <foo>) and exit the emulator. Later, I resume the
>> snapshot by starting Qemu with the snapshotfile and say 'loadvm <foo>'.
>>
>> 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.
>
> Ok, then I am pretty much in the dark on this one - I don't know
> anything about the checkpoint/restart feature and the impact on things
> like the clock. I only worked on the live snapshot code (for disk
> snapshots).
>
> Hopefully someone else will have an idea.

Sounds like a bug in the RTC. Maybe decoalescing is triggered, which
would cause a burst of RTC interrupts to catch with the system clock?