Bug 193213

Summary: ntpd and ntpdate not functioning correctly under xenU kernel
Product: [Fedora] Fedora Reporter: lannet
Component: xenAssignee: Xen Maintainance List <xen-maint>
Status: CLOSED WONTFIX QA Contact: Martin Jenner <mjenner>
Severity: medium Docs Contact:
Priority: medium    
Version: 5CC: bstein, hps, katzj
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2007-09-24 19:59:20 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Description Flags
Output from command: for i in gw repo vhost vdb vint vmx vns vwww guru-wlan0 ; do echo $i; ssh $i 'ntpq -p'; done none

Description lannet 2006-05-26 01:11:15 EDT
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 01:11:15 EDT
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 01:44:52 EDT
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 17:26:16 EDT
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 17:13:24 EDT
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-13 20:43:37 EDT
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 05:24:56 EDT
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 19:55:12 EDT
change QA contact
Comment 8 Daniel Berrange 2007-09-24 19:59:20 EDT
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.