Re: [CentOS] Xen clock drift

2008-01-09 Thread Akemi Yagi
On Jan 9, 2008 12:35 PM, Jack Bailey <[EMAIL PROTECTED]> wrote: > > > A note by Johnny Hughes in http://bugs.centos.org/view.php?id=2189 > > (comment 6644): > > > > "As a side note ... if the clock GAINS (runs to fast) time you should > > be able to fix it with this: > > > > http://kb.vmware.com/kb

Re: [CentOS] Xen clock drift

2008-01-09 Thread Jack Bailey
A note by Johnny Hughes in http://bugs.centos.org/view.php?id=2189 (comment 6644): "As a side note ... if the clock GAINS (runs to fast) time you should be able to fix it with this: http://kb.vmware.com/kb/1591 (by setting the correct host.cpukHz) and vmware tools should adjust a clock that i

Re: [CentOS] Xen clock drift

2008-01-09 Thread Akemi Yagi
On Jan 9, 2008 7:41 AM, Luke Dudney <[EMAIL PROTECTED]> wrote: > 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 synchr

Re: [CentOS] Xen clock drift

2008-01-09 Thread Luke Dudney
On 08/01/2008 15:15, Brian Mathis wrote: From: Jack Bailey <[EMAIL PROTECTED]> 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,

Re: [CentOS] Xen clock drift

2008-01-08 Thread Jack Bailey
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

Re: [CentOS] Xen clock drift

2008-01-08 Thread Brian Mathis
> From: Jack Bailey <[EMAIL PROTECTED]> > 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 cloc

Re: [CentOS] Xen clock drift

2008-01-08 Thread Akemi Yagi
On Jan 8, 2008 5:05 AM, Rick Barnes <[EMAIL PROTECTED]> wrote: > > Akemi Yagi wrote: > > On Jan 8, 2008 4:51 AM, Rick Barnes <[EMAIL PROTECTED]> wrote: > >> Jack Bailey wrote: > >>> These domains are fully virtualized and set up identically, except > >>> "badclock" is allocated two processors versu

Re: [CentOS] Xen clock drift

2008-01-08 Thread Johnny Hughes
Rick Barnes wrote: > > Akemi Yagi wrote: >> On Jan 8, 2008 4:51 AM, Rick Barnes <[EMAIL PROTECTED]> wrote: >>> Jack Bailey wrote: These domains are fully virtualized and set up identically, except "badclock" is allocated two processors versus one processor for "goodclock". DomU's c

Re: [CentOS] Xen clock drift

2008-01-08 Thread Rick Barnes
Akemi Yagi wrote: > On Jan 8, 2008 4:51 AM, Rick Barnes <[EMAIL PROTECTED]> wrote: >> Jack Bailey wrote: >>> 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. >

Re: [CentOS] Xen clock drift

2008-01-08 Thread Akemi Yagi
On Jan 8, 2008 4:51 AM, Rick Barnes <[EMAIL PROTECTED]> wrote: > Jack Bailey wrote: > > 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

Re: [CentOS] Xen clock drift

2008-01-08 Thread Rick Barnes
Jack Bailey wrote: > 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? This is a known issue that has come up on

[CentOS] Xen clock drift

2008-01-08 Thread Jack Bailey
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, on