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:gdri...@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@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.
_______________________________________________
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss
