Steven Timm wrote:
> Since the errata kernel release 2.6.18-164.6.1 we have been
> seeing Xen domU's that will occasionally jump forward in time by
> 40-80 minutes.  the behavior is such that the clock will jump
> forward and then just sit there until the clock of the underlying
> dom0 catches up to it again.
> 
> At first we were running ntpd on our domU's but then disabled it
> in response to suggestions in several howtos.  So now we know
> that the problem has nothing to do with rogue ntp packets but
> could very well be something in xen or kernel-xen that is causing it.
> There's a report of something very similar in the CentOS forum
> to which I've appended more details of this bug.
> 
> https://www.centos.org/modules/newbb/viewtopic.php?topic_id=23402
> 
> Nothing in the upstream vendor bugzilla about this that I can find,
> or nothing in the Xen mailing lists that's obvious.
> 
> Any help is appreciated.
> 
> Steve Timm
> 
> 

Hi Steve,
With the new kernel (2.6.18-164.11.1.el5) that just was released, there 
were lots of time bug fixes.

http://www.redhat.com/docs/en-US/errata/RHSA-2010-0046/Kernel_Security_Update/index.html

Here are the time related ones

* Scientific Linux 5.4 SMP guests running on a Scientific Linux 
Hypervisor may have experienced inconsistent time, for example, the time 
going backwards. This could have caused some applications to hang.

* In rare cases, a system management interrupt (SMI) could occur during
CPU frequency calibration (during boot), resulting in the frequency
being calculated to a value larger than the CPU's specification. This
could have resulted in timer values being miscalculated and firing at
incorrect times. Note: This fix is optional. To enable the fix, the
system must be booted with the avoid_smi kernel parameter.

* A KVM pvclock fix in the kernel-2.6.18-164.2.1.el5 update introduced a
bug: Some SMP guest operating systems experienced time drift. This could
cause problems for time-sensitive applications.

* Scientific Linux 5.4 guests using KVM pvclock, calling the
clock_gettime(CLOCK_REALTIME) and gettimeofday() functions in sequence
could have, in rare cases, caused clock_gettime() to return a smaller
value than gettimeofday(). If the sequence was reversed, gettimeofday()
could return a smaller value than clock_gettime(CLOCK_REALTIME). This
could cause applications to hang and use large amounts of CPU (up to
100%), or cause problems for applications that depend on timestamps to
order events. Note: This update only resolves this issue for Intel 64
and AMD64 systems. The issue can still present on i386 systems.

I am not positive that it will fix your problem, but it sure looks like 
this kernel they did alot of work on time and virtulization.

Troy
-- 
__________________________________________________
Troy Dawson  [log in to unmask]  (630)840-6468
Fermilab  ComputingDivision/LSCS/CSI/USS Group
__________________________________________________