[OpenIndiana-discuss] ntpd not keeping time in sync

[Mark]

On 10/07/2011 8:54 a.m., Richard L. Hamilton wrote:
> AFAIK, at least historically, the hardware battery clock time is expected (without some tweaks, to the extent that a given version allowed those) by Windows to be in local time.  Operating systems that keep their internal time in something else (.e.g. Unix and related, where it's supposed to be in GMT, with the TZ environment variable providing an offset to local time as desired) already have to deal with that (and probably with the possibility of it running in GMT instead).
>
> It seems to me that a virtualization environment should simulate an RTC clock for the guest, and should simply keep track of the offset between that time and the host's internal time, to be used to supply an initial value when the guest is started.
>
> Both virtualization and dual boot get tricky if there are mixed assumptions as to the RTC being in local vs GMT, especially with the addition of daylight saving time, and most particularly if the guest or less common boot environment is active at start or end of DST.
> It takes some care on the part of all OS and virtualization product producers _and_ the person setting up such a system, to get the whole situation right.
>
> It would probably be helpful if the OP provided more details of whether dual boot or virtualization was involved in their situations;  and also if someone would write up a good guide to cases where Solaris/OpenSolaris/OpenIndiana was host or guest or primary or alternate boot with various other common OSs, on how to successfully keep the time consistent (unless something other than consistency was intentional!) across all environments.
>
> AFAIK, for semi-modern versions of Windows, there are settings that can allow the RTC to run in GMT and still have the OS in local time (with or without DST).  I think most other OSs should also be happy with that, or be easily able to be made happy with that.  It's what I'd do if I had a multi-boot Intel box that was having issues with getting the time right on some of the OSs.
>
> On Jul 9, 2011, at 1:43 PM, Dan Swartzendruber wrote:
>
>>
>> No, I think he meant resetting the time in the BIOS of the VM.
>>
>> -----Original Message-----
>> From: Gary Driggs [mailto:gdriggs at gmail.com]
>> Sent: Saturday, July 09, 2011 1:42 PM
>> To: Discussion list for OpenIndiana
>> Subject: Re: [OpenIndiana-discuss] ntpd not keeping time in sync
>>
>> On Jul 9, 2011, at 8:48 AM, Gary Gendel wrote:
>>
>>> I suppose this could be true of a virtual machine resetting the time as
>> well.
>>
>> A guest OS should never be allowed to adjust its hosts clock. Sometimes a
>> failing motherboard battery can cause issues but NTP should be correcting
>> them. Have you tried resarting or disabling/enabling the service?
>>
>> -Gary D
>> _______________________________________________
>> OpenIndiana-discuss mailing list
>> OpenIndiana-discuss at openindiana.org
>> http://openindiana.org/mailman/listinfo/openindiana-discuss
>>

The hardware RTC is only read at boot and sets the initial date/time.
The OS will adjust it's internal time from this initial reference and 
it's timezone, hence different times between cmos rtc and server e.g 
daylight time.

Then the hardware time ticks are counted by the OS to maintain internal 
time. This is the sole time source until the next boot.

The issue is drift of the internal time ticks against the ntp external 
reference. When this drift exceeds ntp's "capture" range, you get the 
error message. I have seen this with virtual (VMWare) Windows and Linux 
as well.

VMware also throws in a few "extra's" at vm bootup, just to make life 
more interesting, but one running, it's up to the OS's method to 
maintain time.

Mark.