Red Hat Bugzilla – Full Text Bug Listing
|Summary:||ntpd and ntpdate not functioning correctly under xenU kernel|
|Component:||xen||Assignee:||Xen Maintainance List <xen-maint>|
|Status:||CLOSED WONTFIX||QA Contact:||Martin Jenner <mjenner>|
|Version:||5||CC:||bstein, hps, katzj|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2007-09-24 19:59:20 EDT||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
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: 1. 2. 3. 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 millisecs.
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: http://lists.xensource.com/archives/html/xen-devel/2006-07/msg00404.html 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 kernels. 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.