Hi David
As we are in danger of taking this thread in a direction that the OP
CDW probably did not intend I'll keep it short(ish) ....8-)
You are right that NTP is very tricky when VMs are involved. VMs need
exactly the right NTP config to work properly (e.g. to jump the time
quickly after a suspend).
The ultimate crime is to run an NTPD Server in a VM. The less said
about that the better.
For those in the need of some nerdy bedtime reading there is an
excellent document on the topic from VMWare:
http://www.vmware.com/files/pdf/Timekeeping-In-VirtualMachines.pdf
While it specific for VMWare, much of the content is relevant to other
virtualisers (e.g. VirtualBox)
Cheers
Chris
Zitat von "David Greaves" <david.grea...@jolla.com>:
On 15/04/14 07:07, christopher.l...@thurweb.ch wrote:
Hi Thomas
Earlier this year in addition to my normal day job I took over
responsibility
for a server farm of over 50 servers both real and virtual. Their
clocks, system
and hardware were all over the place. This lead to strange knock on effects,
like Samba not being able to authenticate users via SSSD / LDAP.
In order to git the clocks under control again I was forced to find out much
more about clock-skew {1} and NTP then I cared for. As a result I
can be very
boring on the subject. 8-)
While ntpdate is a valid pragmatic workaround, it remains a workaround, as a
properly configured ntp daemon should automatically keep your
system clock in
sub millisecond sync. Be aware also that NTDATE is deprecated {2}.
Instead you
should use ntpd -gq
Personally I think you should use a virtualisation specific solution to time
sync if possible - it tends to cope better with virt specific issues like
suspend and migrate. eg VMs running on laptops. In this case the VM
may not even
know that it was suspended since the virt layer does it, not VM pm layer and
hence cannot trigger special-case timesync handling.
Running ntp on all guests is required in some situations though (eg
older xen).
Happy to hear any counter-arguments though
nb - in farm situations this also means that you simply run ntp on
the physical
hosts and that's one less config pita on the guests :)
However if the time is already "too far off" the NTD may never be
able to catch
up (as normally it only makes small jumps {3), or even give up altogether.
When I encountered a server with clock(s) "way off" I used the set
of commands
below to get it back in line.
hwclock --show
date
service ntpd stop
ntpd -gq
hwclock --systohc --localtime
service ntpd start
hwclock --show
date
After that, if NTPD is properly configured, then NTP should be able
to keep the
server's system clock in line.
HtH
Chris
{1} the root of all evil
{2} http://support.ntp.org/bin/view/Dev/DeprecatingNtpdate
{3} by my measurements about 1.7 mins per day
Zitat von "Thomas Tanghus" <tho...@tanghus.net>:
On Monday 14 April 2014 14:49 Chris Walker wrote:
I installed the ntp client and it now picks up network time. I'm
assuming therefore that there is some time 'slip' between the host
machine and VBox.
I had the same problem and now run ntpdate from cron.daily. Turns
out my PCs
clock loses ~5 seconds(sic!) for every 24h :(
--
Med venlig hilsen / Best Regards
Thomas Tanghus
_______________________________________________
SailfishOS.org Devel mailing list
_______________________________________________
SailfishOS.org Devel mailing list
_______________________________________________
SailfishOS.org Devel mailing list
_______________________________________________
SailfishOS.org Devel mailing list
