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.
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
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.
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?
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.
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?
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. :-( )
change QA contact
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.