Re: [Xen-users] Unable to set system clock on domU

["Fajar A. Nugraha" <fajar@xxxxxxxxx>]

On Tue, Feb 17, 2009 at 3:34 PM, Daniel Bareiro <daniel-listas@xxxxxxx> wrote:
>> > /proc/sys/xen/independent_wallclock is set to 0 on dom0. what can be
>> > happening?
>
>> Set it to "1".
>
> I tried setting /proc/sys/xen/independent_wallclock to "1" and booting
> again the domU, but I obtain the same message during boot.

Sorry, I should've been more specific :)

The normal way with xen is that domU follows dom0's clock. You should
not need to set clock on domU, you simply need to use rtc_timeoffset
or localtime to adjust (possible) time zone or RTC settings
differences.

However, some users reported domU's clock going out-of-syc from dom0.
I have only experience this behaviour with Opensolaris domU, YMMV. In
this case setting /proc/sys/xen/independent_wallclock on domU (not
dom0) allows that domU to set it's own system clock (or wall clock).
This is the clock that will be modified by ntpd, ntpdate, or the
command "date".

Some implementantions of ntp init scripts (like the one from RHEL)
will also try to modify RTC by default during ntp startup. When in
domU, this will create an error as domU doesn't have RTC. You can
safely ignore this error though. The error would be something like

"Syncing hardware clock to system time Cannot access the Hardware
Clock via any known method.
Use the --debug option to see the details of our search for an access method.
[FAILED]
"

Now I dont't know whether or not Debian modifies RTC, but I think you
simply need to set /proc/sys/xen/independent_wallclock to "1" on that
particular domU (again, not dom0).

My suggestion though is simply set the correct time zone, set
"locatime" or "rtc_timeoffset" on domU config if necessary, and simply
run ntpd on dom0.

Regards,

Fajar

_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users