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: <www.vmware.com/pdf/vmware_timekeeping.pdf> 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 <www.vmware.com/pdf/vmware_timekeeping.pdf> 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)
signature.asc
Description: OpenPGP digital signature
