[Pool] time reset

Chuck Swiger cswiger at mac.com
Thu Mar 24 22:38:32 UTC 2011

On Mar 24, 2011, at 1:29 PM, Alby wrote:
>  Its a Virtual Machine at (openhosting.com). A long time ago it was
> working fine, no errors or anything. Then out of the blue, these
> problems started up. So who knows what happened. It just might be a
> crazy clock.

Ah, you should have mentioned that it is a VM and not running on
a physical machine.  To quote something I've mentioned elsewhere:

1) Running ntpd in the Dom0/host ESX/host is very useful.  Keeping good time
there means that good time will be available to all of the VMs/guests via
independent_wallclock = 0, vmx option tools.syncTime = true, etc.

2) Running ntpd in the Dom0/host ESX/host also means that system/kernel clock
will or ought to be sync'ed, which means that the periodic updates to the
RTC/TOD/TOY clock are also good.

3) Running ntpd in a DomU/guest is possible, however a DomU/guest OS cannot
update the time seen in other DomUs/guests, and it cannot update the
RTC/TOD/TOY clock.

4) Furthermore, ntpd in a DomU/guest may experience large jumps in time
depending on the loading of the physical host, whether the VM is swapped
out or otherwise suspended for long periods of time, etc.

[ This is why the suggested ntp.conf's for DomU/guests use "tinker panic 0",
and recommend not to use to undisciplined local clock. ]

5) I have yet to see an example where running ntpd in a DomU/guest kept
better time than ntpd running in Dom0/host OS.

6) I have yet to see an example where ntpd running in a DomU/guest kept
better time than using independent_wallclock = 0, tools.syncTime = true, etc
if the Dom0/host OS is sync'ed.

Because of the above, I've drawn the conclusion that "running ntpd's in the
other DomUs/guest VMs is almost entirely pointless".


More information about the pool mailing list