Re: [Qemu-devel] Relative/Absolute timing snapshot problem
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
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
On Mon, Mar 28, 2011 at 7:32 PM, Jes Sorensen jes.soren...@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?
Re: [Qemu-devel] Relative/Absolute timing snapshot problem
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
[Qemu-devel] Relative/Absolute timing snapshot problem
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
