On 08/01/2008 15:15, Brian Mathis wrote:
From: Jack Bailey jack@internetguy.net Date: Jan 8, 2008 3:17 AM To: centos@centos.org
Hello All,
Consider a CentOS-5.1 Xen server (2.6.18-53.1.4.el5xen) hosting two domains running CentOS-5.1 (2.6.18-53.1.4.el5). One domain has a fairly accurate clock, the other domain has a clock that gains ungodly amounts of time, roughly one minute every two or three minutes. For a fix, one suggestion is to run this command in DomU:
echo 1 > /proc/sys/xen/independent_wallclock
This didn't change anything. As an experiment, I wrote a script to call ntpd -q, sleep 60, and repeat indefinitely. Here are a couple of snippets of output:
goodclock# ksh ./xenclockdrift ntpd: time slew +0.001211s ntpd: time slew +0.001200s ntpd: time slew +0.001855s ntpd: time slew +0.001532s ntpd: time slew +0.001603s ntpd: time slew +0.001320s ntpd: time slew +0.001931s
badclock# ksh ./xenclockdrift ntpd: time slew -0.000193s ntpd: time set -57.356377s ntpd: time slew +0.002352s ntpd: time slew +0.003018s ntpd: time set -57.417488s ntpd: time slew +0.012089s ntpd: time slew -0.000985s
These domains are fully virtualized and set up identically, except "badclock" is allocated two processors versus one processor for "goodclock". DomU's clock is running normally.
Anyone know what's going or know how to fix it? Jack
I'm not sure with Xen, but on VMWare one should not be using NTP at all. Time syncing should be done with the vmware tools and the host, with NTP only running on the host (not the guests). Using NTP on a vmware system will result in similar behavior to what you are seeing here.
At least, that is the theory. Empirically, using the vmware tools time sync feature will push a slow VM's clock forwards, but it won't push a fast clock backwards. I'm yet to see a "best practice" for ensuring proper time synchronisation within VMware VMs, but for now, NTP seems the best option.
cheers Luke