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
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:
Time offsets for all xenU guests exceeds 128ms.
time offsets should be within 128 ms.
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
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:
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
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.