[Pool] time reset
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
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