[ale] RHEL use AD server for NTP?

[DJ-Pfulio]

Windows can't keep time.  They've had this issue since at least 1995.
Around 2005, I spoke with onsite MSFT engineers about this and their
stance was that +/- 5min was close enough. My work-provided machine was
running about 3 min late, thanks to Windows time being off, so I'd join
every meeting/conferent 3 min late.

In the late 1990s, I was fed up with Windows time issues and brought up
an internal Linux NTP server.  Pointed all my systems at it, including
Windows.  To get Windows clients to keep time, I had to force the NTP
updates to be every 15 min.  Every hour and Windows would drift 3+ minutes.

BTW, the Linux system used as the time server had Windows on it for a
year before and couldn't keep correct time.  It has been running Linux
as a VM host since then, and keeps sub-sec accuracy all this time.

As for virtual machines and time accuracy, this depends on the
hypervisor used. Some provide NTP extensions to their guest addons which
are supposed to get time from the hostOS HW clock.  IME, this mostly
works.  NTP Linux to Linux between a physical hostOS and all guest VMs
on it and other hosts, don't seem to have the time drift issue. At least
not on my 20-30 systems.

I've run vbox, ESXi, KVM and Xen VM hosts. They all behaved about the
same, except vbox.  I treat all my Linux VMs like they are physical
machines, except using virtio drivers for NICs and storage.

The Windows guests still drift a little, even with 15min forced syncs,
virtio drivers and QXL video.  Every few weeks, I discover a Windows
guest is off enough to bother me - manual re-sync fixes it for a few
weeks.  I've tried to automate that, but the net /time stuff doesn't
seem to work.

I don't need real-time accuracy, but sub-second accuracy isn't THAT hard
since 1993, really.  There's really no good reason for MSFTs 'tude about
this. Perhaps they've fixed it in the time since I stopped accepting
their patches about 2 yrs ago?

That's what I think I know.  YMMV.

Just for fun, here's the current 'date' for a few Linux systems, most
are VMs, pulled over about 5 seconds:
Wed Jan  3 11:51:12 EST 2018
Wed Jan  3 11:51:14 EST 2018
Wed Jan  3 11:51:14 EST 2018
Wed Jan  3 11:51:14 EST 2018
Wed Jan  3 11:51:15 EST 2018
Wed Jan  3 11:51:15 EST 2018
Wed Jan  3 11:51:16 EST 2018
Wed Jan  3 11:51:16 EST 2018
Wed Jan  3 11:51:17 EST 2018
Wed Jan  3 11:51:17 EST 2018
Wed Jan  3 11:51:17 EST 2018

Close enough.   Checked a Windows VM, it was off about ... 2 sec, which
was pretty great for it.  Forced a sync a few days ago. It was off 3 min
then.

The date run was Ansible at work. ;)  I haven't seen much difference in
time sync between all the Linux systems. The time host is an Ubuntu
14.04 LTS server.



On 01/03/2018 10:49 AM, Jim Kinney via Ale wrote:
> I've had issues with the clock on VMs dragging but never had an issue
> with a VM as an NTP server. As a server, it checks upstream more often
> and thus the lag and drift is microscopic.
> 
> On Wed, 2018-01-03 at 10:12 -0500, Leam Hall via Ale wrote:
>> I've heard that RHEL 6 boxes have issues using Winderz AD servers as a 
>> time source. While a VM to VM ntp query is always iffy, is there 
>> anything to the claim? If so, what can be done about it?
>>