My Virtual Machine's clock drifts pretty significantly. There's documentation out there about dealing with this, but nothing seems to be working very well.
Anyone have any suggestions, things that worked well for them, ...
Supposedly updating regularly via ntp is not a good solution.
VMware® virtual machines use several techniques to minimize and conceal differences in timing performance, but the differences can still sometimes cause timekeeping inaccuracies and other problems in software running in a virtual machine. When this occurs, it's called time drift.
Q: Why is the time wrong in my virtual machine (VMware)? This is a common occurrence and can have a variety of causes, including variable clock rates on some CPUs. An effective way to address it is to install VMware Tools in the VM, and to turn on time synchronization via the Options > Miscellaneous Options tab.
"Clock Drift" in this context is defined as the clock going out of sync. This is caused by Windows using SNTP (Simplified Network Time Protocol) rather than a full NTP service; as well as Windows having a too-infrequent clock update cycle by default.
Configure the guest VM to synchronize time with ESX. In the VM's configuration, go to Edit Settings > Options > VMware tools. Tick the synchronise guest time with host box.
Timekeeping best practices for Linux guests among other things says: Ref: http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1006427
NTP Recommendations Note: VMware recommends you to use NTP instead of VMware Tools periodic time synchronization. NTP is an industry standard and ensures accurate time keeping in your guest. You may have to open the firewall (UDP 123) to allow NTP traffic.
This is a sample /etc/ntp.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 driftfile /var/lib/ntp/drift
This is a sample (RedHat specific) /etc/ntp/step-tickers:
0.vmware.pool.ntp.org 1.vmware.pool.ntp.org
The configuration directive tinker panic 0 instructs NTP not to give up if it sees a large jump in time. This is important for coping with large time drifts and also resuming virtual machines from their suspended state.
Note: The directive tinker panic 0 must be at the top of the ntp.conf file.
It is also important not to use the local clock as a time source, often referred to as the Undisciplined Local Clock. NTP has a tendency to fall back to this in preference to the remote servers when there is a large amount of time drift.
An example of such a configuration is:
server 127.127.1.0 fudge 127.127.1.0 stratum 10
Comment out both lines.
After making changes to NTP configuration, the NTP daemon must be restarted. Refer to your operating system vendor’s documentation.
vmware have a really good PDF doc on this problem.
Basically, the host will slew the ticks delivered to your guests as it can. Don't run NTP or timed or junk like that. Just install vmware-guestd and let the host slew your ticks. If you still lose ticks, then any other solution will have major drift too.
If you can, use a guest OS that has a low frequency tick rate. Newer versions of Linux come with 1000Hz ticks, but it used only to be 100Hz. That seems easier for the host to deliver. A kernel rebuild is usually needed to change the HZ value.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With