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
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
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
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,
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
> 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
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
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
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.
>
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
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
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
12 matches
Mail list logo