Re: SLES 11 under z/VM clock incorrectly set at boot

[Aria Bamdad]

>This would probably be a good thing to be discussed in the Linux Device
>Driver and Command Reference book.
>
>Alan Altmark


I agree.  I also think it would be good to mention it in the virtualization
cookbooks.  AFAIK, I don't see any reference to this anywhere in the manuals
that I have looked at.

I reported your comments as well as Martin's to SUSE level 2 support.

For now, I will test setting most of my guests to 'hardware clock set to
UTC' and then update via NTP to be sure but at least, this makes them boot
up with the correct time early in the boot process and doesn't depend on NTP
being up to have the correct system time.

Thanks again,
Aria

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Re: SLES 11 under z/VM clock incorrectly set at boot

[Alan Altmark]

On Wednesday, 11/30/2016 at 02:55 GMT, Aria Bamdad  
wrote:
> Thank you both for your clarifications.   I do run my CPC clock on UTC 
but
> my VM system is local time.  I was under the incorrect impression that 
Linux
> got its time as the VM time.
>
> Based on what you said and what I observed, it appears that leaving the
> processor time as UTC and VM time as local time, then selecting 
'Hardware
> clock set to UTC' and the correct timezone in Linux would be the 
appropriate
> setting.
>
> I was under the wrong impression that the time received by the guest 
would
> be the VM virtual machine time the guest was running under.

This would probably be a good thing to be discussed in the Linux Device 
Driver and Command Reference book.

Alan Altmark

Senior Managing z/VM and Linux Consultant
Lab Services System z Delivery Practice
IBM Systems & Technology Group
ibm.com/systems/services/labservices
office: 607.429.3323
mobile; 607.321.7556
alan_altm...@us.ibm.com
IBM Endicott

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Re: SLES 11 under z/VM clock incorrectly set at boot

[Aria Bamdad]

Alan and Martin,

Thank you both for your clarifications.   I do run my CPC clock on UTC but
my VM system is local time.  I was under the incorrect impression that Linux
got its time as the VM time.

Based on what you said and what I observed, it appears that leaving the
processor time as UTC and VM time as local time, then selecting 'Hardware
clock set to UTC' and the correct timezone in Linux would be the appropriate
setting.

I was under the wrong impression that the time received by the guest would
be the VM virtual machine time the guest was running under.

Thanks again,
Aria

-Original Message-
From: Linux on 390 Port [mailto:LINUX-390@VM.MARIST.EDU] On Behalf Of Martin
Schwidefsky
Sent: Wednesday, November 30, 2016 2:01 AM
To: LINUX-390@VM.MARIST.EDU
Subject: Re: SLES 11 under z/VM clock incorrectly set at boot

On Wed, 30 Nov 2016 00:22:41 -0500
Alan Altmark <alan_altm...@us.ibm.com> wrote:

> On Tuesday, 11/29/2016 at 08:56 GMT, Aria Bamdad <a...@bsc.gwu.edu> wrote:
> > When you say the virtual TOD is on UTC, do you mean that even if I IPL
> > z/VM using
> > the local time and timezone, the TOD reported to Linux is in UTC?
> > Then this means
> > regardless of what z/VM time is set to, the guests always see UTC as
> > the TOD time.
>
> Unless you use CP SET VTOD command or the guest issues a SET CLOCK or
> PERFORM TIMING FACILITY FUNCTION instruction to change the virtual TOD,
> the virtual TOD will match the LPAR TOD.  Further, the LPAR TOD will match
> the machine TOD.  I'm over-simplifying, but it's good enough for our
> discussion.

Linux uses the only available source to get the initial time which is
the TOD clock. The assumption is that the wall clock returned by the TOD
is STP time. If you configure your machine by the book the following
holds:
STP timestamp = UTC timestamp + leap-second-offset

As Alan already mentioned most people simply use UTC for the TOD clock
and ignore leap seconds. In this case the time stamp returned by the TOD
clock is UTC. The Linux time is calculated in UTC, any timezone offset
is added by userspace.

Now we have three cases:
1) TOD = UTC with leap seconds.
   The initial system time is UTC. All is good.
2) TOD = UTC without leap seconds.
   The initial system time is UTC + leap-seconds. The initial system
   time is off by the number of leap seconds.
3) TOD = local time
   Linux has no way to know what you did to your machine TOD clock.
   The initial system time will by off by the timezone offset.

There is an upstream patch to read the configured number of leap seconds
at IPL and subtract it from the TOD clock to get the initial time. This
fixes case 2). See the following git commit:

commit 936cc855ffe808b428cf75116fe031af9f12237e
Author: Martin Schwidefsky <schwidef...@de.ibm.com>
Date:   Tue May 31 12:47:03 2016 +0200

s390/time: add leap seconds to initial system time

The PTFF instruction can be used to retrieve information about UTC
including the current number of leap seconds. Use this value to
convert the coordinated server time value of the TOD clock to a
proper UTC timestamp to initialize the system time. Without this
correction the system time will be off by the number of leap seonds
until it has been corrected via NTP.

Signed-off-by: Martin Schwidefsky <schwidef...@de.ibm.com>

This is upstream only right now.

> > Based on the above, I tested setting the correct region, and then
> > selected 'Hardware
> > clock set to UTC' in Yast and rebooted.  Sure enough, the time in
> > Linux shows my local
> > time correctly.
> >
> > So does this mean that regardless of what z/VM time is set to, the
> > Linux guests should
> > select their time as 'Hardware clock set to UTC'?
>
> Before Linux can correctly calculate the time, it needs to know how the
> (virtual) TOD clock is set.  Some people (unwisely) set the TOD clock to
> the local time instead of UTC by setting local time with offset 0 (gag).
> But most people set the TOD clock to UTC (ignoring leap seconds).

If you do that the only way to get your system time corrected is NTP.

> > Is the kernel parameter clocksource=tod needed?
>
> I don't think so, but I'm not sure.  A long time ago the timer support in
> Linux was changed to use the TOD rather than depending on a ticking
> software clock.  (Martin?)

No, you do not have to do this. There is only one clocksource which is the
TOD and it is used automatically.

My suggestion would by to configure your machines TOD clock to UTC.

--
blue skies,
   Martin.

"Reality continues to ruin my life." - Calvin.

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or
visit
http://www.m

Re: SLES 11 under z/VM clock incorrectly set at boot

[Martin Schwidefsky]

On Wed, 30 Nov 2016 00:22:41 -0500
Alan Altmark  wrote:

> On Tuesday, 11/29/2016 at 08:56 GMT, Aria Bamdad  wrote:
> > When you say the virtual TOD is on UTC, do you mean that even if I IPL
> > z/VM using
> > the local time and timezone, the TOD reported to Linux is in UTC?
> > Then this means
> > regardless of what z/VM time is set to, the guests always see UTC as
> > the TOD time.
>
> Unless you use CP SET VTOD command or the guest issues a SET CLOCK or
> PERFORM TIMING FACILITY FUNCTION instruction to change the virtual TOD,
> the virtual TOD will match the LPAR TOD.  Further, the LPAR TOD will match
> the machine TOD.  I'm over-simplifying, but it's good enough for our
> discussion.

Linux uses the only available source to get the initial time which is
the TOD clock. The assumption is that the wall clock returned by the TOD
is STP time. If you configure your machine by the book the following
holds:
STP timestamp = UTC timestamp + leap-second-offset

As Alan already mentioned most people simply use UTC for the TOD clock
and ignore leap seconds. In this case the time stamp returned by the TOD
clock is UTC. The Linux time is calculated in UTC, any timezone offset
is added by userspace.

Now we have three cases:
1) TOD = UTC with leap seconds.
   The initial system time is UTC. All is good.
2) TOD = UTC without leap seconds.
   The initial system time is UTC + leap-seconds. The initial system
   time is off by the number of leap seconds.
3) TOD = local time
   Linux has no way to know what you did to your machine TOD clock.
   The initial system time will by off by the timezone offset.

There is an upstream patch to read the configured number of leap seconds
at IPL and subtract it from the TOD clock to get the initial time. This
fixes case 2). See the following git commit:

commit 936cc855ffe808b428cf75116fe031af9f12237e
Author: Martin Schwidefsky 
Date:   Tue May 31 12:47:03 2016 +0200

s390/time: add leap seconds to initial system time

The PTFF instruction can be used to retrieve information about UTC
including the current number of leap seconds. Use this value to
convert the coordinated server time value of the TOD clock to a
proper UTC timestamp to initialize the system time. Without this
correction the system time will be off by the number of leap seonds
until it has been corrected via NTP.

Signed-off-by: Martin Schwidefsky 

This is upstream only right now.

> > Based on the above, I tested setting the correct region, and then
> > selected 'Hardware
> > clock set to UTC' in Yast and rebooted.  Sure enough, the time in
> > Linux shows my local
> > time correctly.
> >
> > So does this mean that regardless of what z/VM time is set to, the
> > Linux guests should
> > select their time as 'Hardware clock set to UTC'?
>
> Before Linux can correctly calculate the time, it needs to know how the
> (virtual) TOD clock is set.  Some people (unwisely) set the TOD clock to
> the local time instead of UTC by setting local time with offset 0 (gag).
> But most people set the TOD clock to UTC (ignoring leap seconds).

If you do that the only way to get your system time corrected is NTP.

> > Is the kernel parameter clocksource=tod needed?
>
> I don't think so, but I'm not sure.  A long time ago the timer support in
> Linux was changed to use the TOD rather than depending on a ticking
> software clock.  (Martin?)

No, you do not have to do this. There is only one clocksource which is the
TOD and it is used automatically.

My suggestion would by to configure your machines TOD clock to UTC.

--
blue skies,
   Martin.

"Reality continues to ruin my life." - Calvin.

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Re: SLES 11 under z/VM clock incorrectly set at boot

[Alan Altmark]

On Tuesday, 11/29/2016 at 08:56 GMT, Aria Bamdad  wrote:
> When you say the virtual TOD is on UTC, do you mean that even if I IPL
> z/VM using
> the local time and timezone, the TOD reported to Linux is in UTC?
> Then this means
> regardless of what z/VM time is set to, the guests always see UTC as
> the TOD time.

Unless you use CP SET VTOD command or the guest issues a SET CLOCK or 
PERFORM TIMING FACILITY FUNCTION instruction to change the virtual TOD, 
the virtual TOD will match the LPAR TOD.  Further, the LPAR TOD will match 
the machine TOD.  I'm over-simplifying, but it's good enough for our 
discussion.

> Based on the above, I tested setting the correct region, and then
> selected 'Hardware
> clock set to UTC' in Yast and rebooted.  Sure enough, the time in
> Linux shows my local
> time correctly.
>
> So does this mean that regardless of what z/VM time is set to, the
> Linux guests should
> select their time as 'Hardware clock set to UTC'?

Before Linux can correctly calculate the time, it needs to know how the 
(virtual) TOD clock is set.  Some people (unwisely) set the TOD clock to 
the local time instead of UTC by setting local time with offset 0 (gag). 
But most people set the TOD clock to UTC (ignoring leap seconds).

> Is the kernel parameter clocksource=tod needed?

I don't think so, but I'm not sure.  A long time ago the timer support in 
Linux was changed to use the TOD rather than depending on a ticking 
software clock.  (Martin?)

Alan Altmark

Senior Managing z/VM and Linux Consultant
Lab Services System z Delivery Practice
IBM Systems & Technology Group
ibm.com/systems/services/labservices
office: 607.429.3323
mobile; 607.321.7556
alan_altm...@us.ibm.com
IBM Endicott

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Re: SLES 11 under z/VM clock incorrectly set at boot

[Aria Bamdad]

 Quoting Alan Altmark :


On Tuesday, 11/29/2016 at 08:18 GMT, Aria Bamdad  wrote:

I am reaching out to the community regarding a problem that I have


observed

since SLES 9 and I wanted to reach out to see if others observe what we


do.

We run z/VM on local time (Eastern US) with the appropriate timezone. We
setup SLES 11 (SP4) via Yast -> System -> Date and time, set the correct
Region and Time Zone, and uncheck the setting that reads 'Hardware clock


set

to UTC'. This sets HWCLOCK="--localtime" in /etc/sysconfig/clock.


However,

with these settings, when Linux boots, the time is 5 hours
ahead. Up to
now, we have been correcting the system time after boot via NTP.

I recently contacted SuSE support and for the past week, we have been


trying

to figure out why this is to no avail. We also tried
using a kernel


boot

parameter clocksource=tod in conjunction with setting the option for
"Hardware clock set to UTC" as checked. This seems to correct the time


but

clearly is not the correct settings.

Would anyone care to provide some input with respect to this? Do you
observe this behavior with z/VM running on local time and if so, what


do

you see with respect to Linux time at boot?


It sounds like the Linux TZ variable is not set, giving you an offset of 0
from UTC. The virtual TOD is on UTC because your machine is
nominally set
to "UTC" (which is technically incorrect for z Systems).

Also, please be aware of
http://www.vm.ibm.com/devpages/altmarka/vmleap.html.

Alan Altmark




Alan, thanks for your reply.  I am afraid I don't quite understand.  You are
correct that the TZ variable is not set when I login but even when I set it
correctly, the time is still the same as before.  However, the time is
incorrect
even early on in the boot process.

When you say the virtual TOD is on UTC, do you mean that even if I IPL
z/VM using
the local time and timezone, the TOD reported to Linux is in UTC?
Then this means
regardless of what z/VM time is set to, the guests always see UTC as
the TOD time.

Based on the above, I tested setting the correct region, and then
selected 'Hardware
clock set to UTC' in Yast and rebooted.  Sure enough, the time in
Linux shows my local
time correctly.

So does this mean that regardless of what z/VM time is set to, the
Linux guests should
select their time as 'Hardware clock set to UTC'?

Is the kernel parameter clocksource=tod needed?

Thanks,
Aria

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

Re: SLES 11 under z/VM clock incorrectly set at boot

[Alan Altmark]

On Tuesday, 11/29/2016 at 08:18 GMT, Aria Bamdad  wrote:
> I am reaching out to the community regarding a problem that I have 
observed
> since SLES 9 and I wanted to reach out to see if others observe what we 
do.
> We run z/VM on local time (Eastern US) with the appropriate timezone. We
> setup SLES 11 (SP4) via Yast -> System -> Date and time, set the correct
> Region and Time Zone, and uncheck the setting that reads 'Hardware clock 
set
> to UTC'.  This sets HWCLOCK="--localtime" in /etc/sysconfig/clock. 
However,
> with these settings, when Linux boots, the time is 5 hours ahead.  Up to
> now, we have been correcting the system time after boot via NTP.
>
> I recently contacted SuSE support and for the past week, we have been 
trying
> to figure out why this is to no avail.   We also tried using a kernel 
boot
> parameter clocksource=tod in conjunction with setting the option for
> "Hardware clock set to UTC" as checked.  This seems to correct the time 
but
> clearly is not the correct settings.
>
> Would anyone care to provide some input with respect to this?  Do you
> observe this behavior with  z/VM running on local time and if so, what 
do
> you see with respect to Linux time at boot?

It sounds like the Linux TZ variable is not set, giving you an offset of 0 
from UTC.  The virtual TOD is on UTC because your machine is nominally set 
to "UTC" (which is technically incorrect for z Systems).

Also, please be aware of 
http://www.vm.ibm.com/devpages/altmarka/vmleap.html.

Alan Altmark

Senior Managing z/VM and Linux Consultant
Lab Services System z Delivery Practice
IBM Systems & Technology Group
ibm.com/systems/services/labservices
office: 607.429.3323
mobile; 607.321.7556
alan_altm...@us.ibm.com
IBM Endicott

--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/

SLES 11 under z/VM clock incorrectly set at boot

[Aria Bamdad]

Hi,



I am reaching out to the community regarding a problem that I have observed
since SLES 9 and I wanted to reach out to see if others observe what we do.
We run z/VM on local time (Eastern US) with the appropriate timezone.  We
setup SLES 11 (SP4) via Yast -> System -> Date and time, set the correct
Region and Time Zone, and uncheck the setting that reads 'Hardware clock set
to UTC'.  This sets HWCLOCK="--localtime" in /etc/sysconfig/clock.  However,
with these settings, when Linux boots, the time is 5 hours ahead.  Up to
now, we have been correcting the system time after boot via NTP.



I recently contacted SuSE support and for the past week, we have been trying
to figure out why this is to no avail.   We also tried using a kernel boot
parameter clocksource=tod in conjunction with setting the option for
"Hardware clock set to UTC" as checked.  This seems to correct the time but
clearly is not the correct settings.



Would anyone care to provide some input with respect to this?  Do you
observe this behavior with  z/VM running on local time and if so, what do
you see with respect to Linux time at boot?



Thanks in advance,

Aria


--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
--
For more information on Linux on System z, visit
http://wiki.linuxvm.org/