On 04/04/16 09:18, Jeremy Charles wrote: > I’m seeing all sort of documentation about how it’s not a great idea to > use a VM as an NTP server due to how sketchy time tracking is within a VM. > > My supervisor directed me to try it anyway. He feels that our existing > NTP servers are too old and need to be replaced, and he wants to replace > them with VMs rather than physical servers. > > I’m not seeing any difference in behavior between the two existing > physical NTP servers and the VM that I set up to test as an NTP server. > > Thoughts?
The timer tick interrupt is virtualized and replicated across all VMs via software. It is no longer a stable measure of time. NTPd's detection of slew rate is no longer a constant. Under high loads you get random time drifts. How do you track real time passage in a virtual reality? https://www.kernel.org/doc/Documentation/virtual/kvm/timekeeping.txt "4.1) Interrupt clocking One of the most immediate problems that occurs with legacy operating systems is that the system timekeeping routines are often designed to keep track of time by counting periodic interrupts. These interrupts may come from the PIT or the RTC, but the problem is the same: the host virtualization engine may not be able to deliver the proper number of interrupts per second, and so guest time may fall behind. This is especially problematic if a high interrupt rate is selected, such as 1000 HZ, which is unfortunately the default for many Linux guests. There are three approaches to solving this problem; first, it may be possible to simply ignore it. Guests which have a separate time source for tracking 'wall clock' or 'real time' may not need any adjustment of their interrupts to maintain proper time. If this is not sufficient, it may be necessary to inject additional interrupts into the guest in order to increase the effective interrupt rate. This approach leads to complications in extreme conditions, where host load or guest lag is too much to compensate for, and thus another solution to the problem has risen: the guest may need to become aware of lost ticks and compensate for them internally. Although promising in theory, the implementation of this policy in Linux has been extremely error prone, and a number of buggy variants of lost tick compensation are distributed across commonly used Linux systems. Windows uses periodic RTC clocking as a means of keeping time internally, and thus requires interrupt slewing to keep proper time. It does use a low enough rate (ed: is it 18.2 Hz?) however that it has not yet been a problem in practice." -- Mr. Flibble King of the Potato People http://www.linkedin.com/in/RobertLanning _______________________________________________ Tech mailing list Tech@lists.lopsa.org https://lists.lopsa.org/cgi-bin/mailman/listinfo/tech This list provided by the League of Professional System Administrators http://lopsa.org/
