Bug 449187 - Clock drift in certain KVM guest
Clock drift in certain KVM guest
Product: Fedora
Classification: Fedora
Component: kvm (Show other bugs)
All Linux
low Severity low
: ---
: ---
Assigned To: Glauber Costa
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2008-05-30 20:06 EDT by Alan Pevec
Modified: 2009-07-14 11:21 EDT (History)
10 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-07-14 11:21:25 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Alan Pevec 2008-05-30 20:06:49 EDT
Description of problem:
in certain KVM guests (let's call it WUI) time drifts significantly (slows down)
while in the other guest (clet's call it NODE) on the same host, time stays
stable. One significant difference is:
NODE - LOC:     100321   Local timer interrupts
WUI  - LOC:    1088230   Local timer interrupts

This happens even with clocksource=acpi_pm boot param
( TSC is unstable, from WUI dmesg:  Clocksource tsc unstable (delta = 4686864172 ns)

Version-Release number of selected component (if applicable):

How reproducible:
every time

Steps to Reproduce:
1. build WUI guest:
   wget http://ovirt.org/download/create-wui-appliance.sh
   sh create-wui-appliance.sh -v -t 
http://download.fedora.redhat.com/pub/fedora/linux/releases/9/Fedora/i386/os/ -k

2. on WUI: service ntpd stop; ntpd -q -d
3. wait ~10min; ntpd -q -d
Actual results:
clock drifted, ntpd -q -d output shows (last line): e.g.
ntpd: time set +74.993754s

Expected results:
clock doesn't drift: e.g.
ntpd: time slew -0.054264s

Additional info:
Comment 1 Glauber Costa 2008-06-02 09:34:19 EDT
For the record, what is the current clocksource in your guest?
(As the output of cat

Comment 2 Alan Pevec 2008-06-02 10:55:22 EDT

since I have clocksource=acpi_pm but it was also falling back to this b/c of
unstable tsc (Clocksource tsc unstable w/ few sec delta in dmesg)

Important data I missed in the report is CPU:
model name      : Intel(R) Core(TM)2 Quad  CPU   Q9450  @ 2.66GHz
stepping        : 6
This stepping doesn't have C2 support.
Mobo is Q35 beta
Comment 3 Alan Pevec 2008-06-02 10:57:58 EDT
On suggestion from chrisw I'm testing with:

commit 3d80840d96127401ba6aeadd813c3a15b84e70fe
Author: Marcelo Tosatti <mtosatti@redhat.com>
Date:   Fri Apr 11 14:53:26 2008 -0300

    KVM: hlt emulation should take in-kernel APIC/PIT timers into account
After running for few hours, the same VM doesn't exhibit such time drift,
ntpd -q -d says: time slew +0.039053s
Comment 4 Alan Pevec 2008-06-02 15:57:58 EDT
Adding to comment 3 - after I left VM idling for few more hourse, time drifted
again ( > 1000s so it was too much even for ntpd -q )
Will try now on a different CPU...
Comment 5 Chris Lalancette 2008-06-03 07:25:06 EDT
Just for another data point, I have a Core2 Due E6850, running the WUI, and ntp
seems to be keeping the time perfectly in sync for me.

Chris Lalancette
Comment 6 Perry Myers 2008-06-03 10:21:35 EDT
Another data point.  I have a Core2 Duo E6850 running the WUI and when I disable
NTP my guest loses time rapidly (1 minute lost out of every 10).  

I tried a test where I disabled ACPI in the Guest via libvirt config, and now
time is kept perfectly in sync with the guest.
Comment 7 Alan Pevec 2008-06-03 11:14:29 EDT
I can confirm that on Q9450 with ACPI disabled in WUI guest, I get stable time,
ntpd -q after ~15min shows:
ntpd: time slew +0.051113
And this is with original F9 KVM kmods:


Comment 8 Alexander Boström 2008-12-23 12:31:33 EST
I see this too. F10 x86_64 host on Athlon X2, F10 i686 guests. clocksource=acpi_pm

How little drift is reasonable to expect?

If time on the host is well kept then there should be nothing for ntpd in the guests to do. The guests should just hwclock --hctosys, ntpdate or similar once at boot and then time in the guest should stay in sync with the host from then on, because there should be no clock drift to compensate for. But can we hope for acpi_pm emulation to become that good?
Comment 9 Bug Zapper 2009-06-09 21:18:17 EDT
This message is a reminder that Fedora 9 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 9.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '9'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 9's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 9 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
Comment 10 Doncho N. Gunchev 2009-06-20 03:17:22 EDT
I am using KVM with 64 bit fedora 11 and 64 bit guests (maybe the version should get updated) and had similar problem.

With fedora 11 guest 'cat /sys/devices/system/clocksource/clocksource0/current_clocksource' shows kvm-clock and all works fine (ntpd).

With CentOS kernel 2.6.18-128.1.14.el5 I get jitter > 5000 and ntpd refuses to work. Clock source is jiffies (the only one available).

With CentOS kernel 2.6.18-128.1.14.el5 with 'notsc divider=10' added to the kernel boot line I get jitter from 18 to 20 on three virtual machines and ntpd works fine.

Comment 11 Bug Zapper 2009-07-14 11:21:25 EDT
Fedora 9 changed to end-of-life (EOL) status on 2009-07-10. Fedora 9 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

Note You need to log in before you can comment on or make changes to this bug.