Is there some way to prevent Xen from setting the clock for a PV guest while booting it? ie. getting rid of this boot message: Setting clock (localtime) Fri Oct 16 09:43:52 BST 2009 [ OK ] This PV guest (Centos 5) has independent_wallclock set, and runs on it''s own date and time settings, but I still have to fix the date after every boot because Xen has set it to the Dom0''s time. Setting ''independent_wallclock=1'' as a boot parameter doesn''t stop the clock set. I''m on Xen 3.1.0, using an old-style config file. Thanks - Evan _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
I think that message is from CentOS (/etc/rc.sysinit) setting the clock from the hardware clock. Evan Lavelle wrote:> Is there some way to prevent Xen from setting the clock for a PV guest > while booting it? ie. getting rid of this boot message: > > Setting clock (localtime) Fri Oct 16 09:43:52 BST 2009 [ OK ] > > This PV guest (Centos 5) has independent_wallclock set, and runs on > it''s own date and time settings, but I still have to fix the date > after every boot because Xen has set it to the Dom0''s time. > > Setting ''independent_wallclock=1'' as a boot parameter doesn''t stop the > clock set. I''m on Xen 3.1.0, using an old-style config file. > > Thanks - > > Evan > > _______________________________________________ > Xen-users mailing list > Xen-users@lists.xensource.com > http://lists.xensource.com/xen-users_______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Roy wrote:> I think that message is from CentOS (/etc/rc.sysinit) setting the clock > from the hardware clock.You''re right, but unfortunately it doesn''t help. rc.sysinit attempts to run ''hwclock --hctosys'' to set the system time from the Hardware Clock. This is fine for non-Xenned kernels. In a Xen guest kernel, however: 1 - ''date'' already shows the valid Dom0 time *before* ''hwclock --hctosys'' is run; on bare metal, ''date'' would have some sort of default value here 2 - hwclock fails, because guests don''t have access to the "Hardware Clock" 3 - rc.sysinit then runs ''date'' to get the system time to produce this boot message:> Setting clock (localtime) Fri Oct 16 09:43:52 BST 2009 [ OK ]Note that this message is wrong for a Xen guest - the system clock set actually failed. The message just shows the Dom0 time that Xen has provided as the initial value of the system time. Does anyone know how/where Xen actually sets the initial value of ''date'', and whether it can be disabled? Incidentally, ''independent_wallclock'' is incorrectly named. If the guest wallclock was actually independent, then Dom0 wouldn''t set it during boot. What it seems to mean is ''guest can set its own time, but only after Xen has already set the initial value''. Thanks - Evan _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Evan Lavelle wrote:> Roy wrote: >> I think that message is from CentOS (/etc/rc.sysinit) setting the >> clock from the hardware clock. > You''re right, but unfortunately it doesn''t help. rc.sysinit attempts > to run ''hwclock --hctosys'' to set the system time from the Hardware > Clock. This is fine for non-Xenned kernels. In a Xen guest kernel, > however: > > 1 - ''date'' already shows the valid Dom0 time *before* ''hwclock > --hctosys'' is run; on bare metal, ''date'' would have some sort of > default value here > > 2 - hwclock fails, because guests don''t have access to the "Hardware > Clock" > > 3 - rc.sysinit then runs ''date'' to get the system time to produce this > boot message: > >> Setting clock (localtime) Fri Oct 16 09:43:52 BST 2009 [ OK ] > > Note that this message is wrong for a Xen guest - the system clock set > actually failed. The message just shows the Dom0 time that Xen has > provided as the initial value of the system time. > > Does anyone know how/where Xen actually sets the initial value of > ''date'', and whether it can be disabled? > > Incidentally, ''independent_wallclock'' is incorrectly named. If the > guest wallclock was actually independent, then Dom0 wouldn''t set it > during boot. What it seems to mean is ''guest can set its own time, but > only after Xen has already set the initial value''. > > Thanks - > > Evan > >The current time is passed to the DomU during the startup. The PV kernel uses it to initialize things. Why not just override the clock during startup by setting it in /etc/rc.sysinit via date to whatever value you want? _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
Roy wrote:> Why not just override the clock during startup by setting it in > /etc/rc.sysinit via date to whatever value you want?I have to do that anyway, to set the system time to the required value. The problem is that Xen has already set it to something else, so there may be some files somewhere that have already been timestamped with the Dom0''s time, and not my time. For consistency, it would be better if I could prevent Xen from setting its own initial value. -Evan _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
On Sat, Oct 17, 2009 at 10:55 PM, Evan Lavelle <sa212+xen@cyconix.com> wrote:> Roy wrote: > >> Why not just override the clock during startup by setting it in >> /etc/rc.sysinit via date to whatever value you want? > > I have to do that anyway, to set the system time to the required value. > > The problem is that Xen has already set it to something else, so there may > be some files somewhere that have already been timestamped with the Dom0''s > time, and not my time. > > For consistency, it would be better if I could prevent Xen from setting its > own initial value.It worked fine on my setup. Is it possible that you set dom0 or domU to use local time instead of UTC for system clock? I set dom0 and domU to use UTC. This is the content of my /etc/sysconfig/clock : ZONE="Asia/Jakarta" UTC=true ARC=false with that setup Xen''s initial value (with dom0 running ntp) is the same as what I get when running ntp on domU. For domUs that uses localtime as system clock, I add this setting on domU config file: localtime=1 You could also play with rtc_timeoffset setting (in case domUs uses different time zones). -- Fajar _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users
A partial answer, for anyone who comes this way in the future:> Is there some way to prevent Xen from setting the clock for a PV guest > while booting it?The answer seems to be no. ''hwclock'' doesn''t work (as you''d expect), and ''date'' is disabled until some point in the boot sequence which I haven''t identified. You can''t wait till booting has completed to fix the date, because by that time you can have thousands of files which have been incorrectly stamped. If you really want a guest with an independent system time, then it looks like it has to be hvm. When ''hwclock'' is run from rc.sysinit it sometimes sets the date to the Dom0 date (on a cold boot?), and sometimes sets it to the last time at which the DomU shut down. This isn''t a problem, because you can insert a ''date'' command immediately after ''hwclock'' and it works. You probably also have to turn off SELinux in the guest; the dom0 date leaks through somehow during the boot. There are also a few files in /proc which occasionally seem to get timestamped 3 days in the future, but this is easy enough to fix. -Evan _______________________________________________ Xen-users mailing list Xen-users@lists.xensource.com http://lists.xensource.com/xen-users