On 2016-09-02 16:48, Carlos E. R. wrote:
On 2016-09-02 16:00, Per Jessen wrote:
Continued from opensuse-factory:
(by the way, this was
https://bugzilla.novell.com/show_bug.cgi?id=773323)
But if you run the ntp daemon on guests, it tries to adjust the speed
of the clock there. That's how it works.
Of course, that's what you want it to do. You want the guest clock
synchronized. It would appear to be a good idea to have ntp on the xen
Dom0 govern the clock for all the guests, but in my experience systemd
does not like that.
Yes, we want the clock synchronized, but not by adjusting the speed on
guests. Just copied from the host. It adds load on the virtualized hardware.
I know that vmware does recommends not running ntpd in guests, but
instead use:
tools.syncTime = "TRUE"
I'll try again to find a source for this.
I have not found the paper where I go that info; instead got another that differs.
One old document was http://www.vmware.com/info?id=34 but that link no longer works.
I read a note on one of the posts to google for vmware_timekeeping.pdf, which I found here:
This one has recommendations to use vmware internal clock adjusting, or ntp, with appropriate configs. And be careful to never use both.
The interesting section is "Synchronizing Virtual Machines and Hosts with Real Time" in page 14.
Besides that, the document is very interesting read about PC clocks in general.
+++---------------------
VMware Tools periodic clock synchronization has the advantage that it is aware of the virtual machine’s
built‐in catch‐up and interacts properly with it. If the guest operating system clock is behind real time by more
than the known backlog that is in the process of being caught up, VMware Tools resets the clock and informs
the virtual machine to stop catching up, which sets the backlog to zero. An additional advantage of VMware
Tools clock synchronization is that it does not require networking to be set up in the guest. However, at this
writing, VMware Tools clock synchronization has a serious limitation: it cannot correct the guest clock if it gets
ahead of real time (except in the case of NetWare guest operating systems). This limitation applies only to
periodic clock synchronization. VMware Tools does a one‐shot correction of the virtual machine clock that
may set it either backward or forward in two cases: when the VMware Tools daemon starts (normally while
the guest operating system is booting), and when a user toggles the periodic clock synchronization feature
from off to on.
Native synchronization software has the advantage that it is generally prepared to deal with the virtual
machine clock being either ahead of or behind real time. It has the disadvantage that it is not aware of the
virtual machine’s built‐in catch‐up and thus typically does not synchronize time as well in a virtual machine
as it does when run directly on physical hardware.
One specific problem occurs if native synchronization software happens to set the guest operating system
clock forward to the correct time while the virtual machine has an interrupt backlog that it is in the process of
catching up. Setting the guest operating system clock ahead is a purely software event that the virtual machine
cannot be aware of, so it does not know that it should stop the catch‐up process. As a result, the guest operating
system clock continues to run fast until catch‐up is complete, and it ends up ahead of the correct time.
Fortunately, such events are infrequent, and the native synchronization software generally detects and corrects
the error the next time it runs.
Another specific problem is that native synchronization software may employ control algorithms that are
tuned for the typical rate variation of physical hardware timer devices. Virtual timer devices have a more
widely variable rate, which can make it difficult for the synchronization software to lock on to the proper
correction factor to make the guest operating system clock run at precisely the rate of real time. As a result, the
guest operating system clock tends to oscillate around the correct time to some degree. The native software
may even determine that the timer device is broken and give up on correcting the clock.
Despite these potential problems, however, testing has shown that NTP in particular behaves fairly well in a
virtual machine when appropriately configured (see “Using NTP in Linux and Other Guests” on page 17).
NTP is prepared for some of its readings to be anomalous because of network delays, scheduling delays on the
local host, and other factors and is effective at filtering out such readings.
Generally, it is best to use only one clock synchronization service at a time in a given virtual machine to ensure
that multiple services do not attempt to make conflicting changes to the clock. So if you are using native
synchronization software, we suggest turning VMware Tools periodic clock synchronization off.
---------------------++-
+++---------------------
Using VMware Tools Clock Synchronization
VMware Tools includes an optional clock synchronization feature that can check the guest operating system
clock against the host operating system clock at regular intervals and correct the guest operating system clock.
VMware Tools periodic clock synchronization works in concert with the built‐in catch‐up feature in VMware
virtual machines and avoids turning the clock ahead too far. VMware Tools also performs one‐time corrections
of the guest operating system clock after certain events, even if periodic synchronization is turned off.
...
[Linux]
By default, the daemon checks the guest operating system clock only once per minute. You can specify a
different period by setting the .vmx configuration file option tools.syncTime.period to the desired time
period (value specified in seconds). When the daemon checks the guest operating system clock, if it is much
farther behind the host time than the virtual machine’s built‐in catch‐up mechanism expects it to be, the
daemon resets the guest operating system clock to host time and cancels any pending catch‐up. As discussed
above, this periodic check currently cannot correct the guest operating system time if it is ahead of the host
time except in NetWare guest operating systems.
---------------------++-
Then comes the section "Using NTP in Linux and Other Guests". I'll copy it here for reference:
+++---------------------
The Network Time Protocol is usable in a virtual machine with proper configuration of the NTP daemon. The
following points are important:
* Do not configure the virtual machine to synchronize to its own (virtual) hardware clock, not even as a
fallback with a high stratum number. Some sample ntpd.conf files contain a section specifying the local
clock as a potential time server, often marked with the comment “undisciplined local clock.” Delete any
such server specification from your ntpd.conf file.
* Include the option tinker panic 0 at the top of your ntp.conf file. By default, the NTP daemon
sometimes panics and exits if the underlying clock appears to be behaving erratically. This option causes
the daemon to keep running instead of panicking.
* Follow standard best practices for NTP: Choose a set of servers to synchronize to that have accurate time
and adequate redundancy. If you have many virtual or physical client machines to synchronize, set up
some internal servers for them to use, so that all your clients are not directly accessing an external
low‐stratum NTP server and overloading it with requests.
The following sample ntp.conf file is suitable if you have few enough clients that it makes sense for them to
access an external NTP server directly. If you have many clients, adapt this file by changing the server names
to reference your internal NTP servers.
NOTE Any tinker commands used must appear first.
# ntpd.conf
tinker panic 0
restrict 127.0.0.1
restrict default kod nomodify notrap
server 0.vmware.pool.ntp.org
server 1.vmware.pool.ntp.org
server 2.vmware.pool.ntp.org
server 3.vmware.pool.ntp.org
Here is a sample /etc/ntp/step-tickers corresponding to the sample ntp.conf file above.
# step-tickers
0.vmware.pool.ntp.org
1.vmware.pool.ntp.org
Make sure that ntpd is configured to start at boot time. On some distributions this can be accomplished with
the command chkconfig ntpd on, but consult your distribution’s documentation for details. On most
distributions, you can start ntpd manually with the command /etc/init.d/ntpd start.
---------------------++-
(extracts from Copyright © 2008 VMware, Inc. All rights reserved.)
This link can be also of interest:
https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1006427
Timekeeping best practices for Linux guests (1006427)
It has a list of settings to be using on kernels of different Linux distributions. openSUSE is not included, but SLES is, and SUSE up to 10.3.
There is an interesting note at the end:
+++---------------------
Virtual hardware clock configuration
When configuring the Linux guest operating system, if you are given a choice between keeping the "hardware" clock (that is, the virtual CMOS time of day clock) in UTC or local time, choose UTC. This avoids any confusion when your local time changes between standard and daylight saving time (in England, "summer time").
---------------------++-
... which is false. If done, the clock is off by hours, the time difference between local and utc.
Apparently, the host feeds the local time, not the utc time, to the guest in the cmos emulation.
--
Cheers / Saludos,
Carlos E. R.
(from 13.1 x86_64 "Bottle" at Telcontar)