Without slew mode, this time difference will be stepped within 15 minutes. When migrating VMs, the VM is paused, not restarted, so there can be a time difference of several seconds or more when the VM resumes. With slew mode, the time is slewed, not stepped, even if a large (up to 600s) offset is seen. Of these items, the most likely cause of the problem was slew mode. The systems were using slew mode ( ntpd -x) There were some other configuration issues (e.g. The systems were bypassing the server selection algorithms by using the 'true' option. The systems were not using 'tinker panic 0'. The systems were using only two NTP servers. The systems were using slew mode (ntpd -x). When looking through their sosreport logs (from two affected clients), I noticed a few things: Understanding Red Hat Enterprise Linux System Clocks And Time Protocol Implementations
T max manager pro timer system for sale how to#
This was not opened as a TAM case, but it was causing problems for the customer so I investigated.įirst, there are some existing knowledge base documents on how to sync the clock on VMs, such as:īest practices for accurate timekeeping for Red Hat Enterprise Linux running on Red Hat Virtualization (It essentially says 'run ntpd'.) # ntpq -np remote refid st t when poll reach delay offset jitter This was causing hundreds of internal customer tickets to be generated. In the first case the problem was that, when migrating VMs (using Red Hat Virtualization), the time on the VM would be off by several seconds. Case 1: Incorrect time after migrating VMs
This is perhaps not a topic people consider very often, but I have seen this recently in a couple of cases - running ntpd in slew mode on a VM can cause the time to be wrong by several seconds, or even several minutes, so I thought I would write a blog post.
0 kommentar(er)
