Bug 193213 - ntpd and ntpdate not functioning correctly under xenU kernel
Summary: ntpd and ntpdate not functioning correctly under xenU kernel
Alias: None
Product: Fedora
Classification: Fedora
Component: xen   
(Show other bugs)
Version: 5
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Xen Maintainance List
QA Contact: Martin Jenner
Depends On:
TreeView+ depends on / blocked
Reported: 2006-05-26 05:11 UTC by lannet
Modified: 2007-11-30 22:11 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-09-24 23:59:20 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Output from command: for i in gw repo vhost vdb vint vmx vns vwww guru-wlan0 ; do echo $i; ssh $i 'ntpq -p'; done (3.59 KB, text/plain)
2006-05-26 05:11 UTC, lannet
no flags Details

Description lannet 2006-05-26 05:11:15 UTC
Description of problem:
It's difficult to determine whether this is a bug, and if so whether it is a bug
in ntpd/ntpdate or in Xen.

The ntpd daemon running on a xenU kernel does not appear to hold the system date
within the defined limits.  Similarly running ntpdate, without ntpd running,
show the offset but fails to update the system date.

Version-Release number of selected component (if applicable):
Host xen0 2096
Guests xenU 2111

How reproducible:
Check the date settings on a group of hosts/guests using a command similar to:

for i in <list_of_servers> ; do echo $i; ssh $i 'ntpq -p'; done

Steps to Reproduce:
Actual results:
Time offsets for all xenU guests exceeds 128ms.

Expected results:
time offsets should be within 128 ms.

Additional info:

See attached data file.  Note that the server "vhost" is running xen0 and all
the "v*" servers are running xenU as guests under vhost; all other servers are
running non-xen kernels.  Also note that the ntpq command shows all offsets in

Comment 1 lannet 2006-05-26 05:11:15 UTC
Created attachment 130012 [details]
Output from command: for i in gw repo vhost vdb vint vmx vns vwww guru-wlan0 ; do echo $i; ssh $i 'ntpq -p'; done

Comment 2 lannet 2006-05-26 05:44:52 UTC
It has been pointed out to me elsewhere that the xenU clocks are tied to the
xen0 clock and that there is a /proc variable /proc/sys/xen/independent_wallclock

This still doesn't explain to me why the offsets are not all the same for each
v* guest, neither does it explain why the offsets are varying over a period of
time - in some cases by as much as 1 second per hour approx.

Comment 3 lannet 2006-05-28 21:26:16 UTC
Re: my earlier post.  Does setting /proc/sys/xen/independent_wallclock somewhere
overcome this problem.  If so, should it be set in the host or in the guests?

Comment 4 Jeff Layton 2006-07-11 21:13:24 UTC
Setting /proc/sys/xen/independent_wallclock on the guest should allow its clock
to be independent of dom0. There is no need to set that on dom0 since it's
already the "master".

I've noticed this problem too on one of my xen boxes. The clock in the guest is
off from dom0 by ~19s. Not sure yet of the cause, but I'm wondering if the xen
scheduler change in the latest devel kernels might affect it.

Theoretically, dom0 and domU should have their wallclocks in sync by default.

Comment 5 Chris Lalancette 2006-07-14 00:43:37 UTC
There is an upstream discussion about this same problem here:


So apparently in the latest Xen (at least on some processors) something is
broken with regards to dom0/domU time synchronization.  Out of curiousity, what
types of processors you are using?  The thread mentions dual-core AMD64 boxes,
and Jeff Layton is running on an Athlon, I believe.  I wonder if this problem is
related to AMD processors?

Comment 6 Henning Schmiedehausen 2006-07-24 09:24:56 UTC
I see this problem on Dual PIII and Single CPU PIV boxes running 2139 and 2145 xen

Setting independent wallclock and runing ntp on the guests solves the problem for
me (though this solution sucks. :-( )

Comment 7 Red Hat Bugzilla 2007-07-24 23:55:12 UTC
change QA contact

Comment 8 Daniel Berrange 2007-09-24 23:59:20 UTC
Closing on basis that FC5 is end-of-life. Feel free to re-open if the problem
still occurs on Fc6 or later, changing the 'version' field as needed.

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