about the system clock uses UTC installation option

[zhangfred_vm]

Hi friends,

While installing the ESX Server Host, there is a 'system clock uses UTC' option.

Should I check this option? why?

Thanks

[RParker]

Coordinated Universal Time (UTC) is a high-precision atomic time standard. UTC has uniform seconds defined by International Atomic Time (TAI), with leap seconds announced at irregular intervals to compensate for the earth's slowing rotation and other discrepancies. Leap seconds allow UTC to closely track Universal Time (UT), a time standard based not on the uniform passage of seconds, but on Earth's angular rotation.

Time zones around the world are expressed as positive or negative offsets from UTC. As the zero-point reference, UTC is also referred to as Zulu time (Z). UTC is often referred to as Greenwich Mean Time when describing time zones, although strictly speaking, it is only an approximation

[cduffy]

I would:

Set the ESX host to UTC and the local clock in your guest VM's to the local timezone.

Because:

Your single ESX host could be supporting VM's in different time zones. Servers for India, Ireland, and Idaho for example.

[bertdb]

select it !

the internal kernel clock in modern OSes counts in UTC (no timezones, no daylight savings time). Whenever the time needs to be displayed to the user, a translation to the configured timezone is done.

The BIOS clock is only used to initialize the Linux kernel clock when booting the physical server. By having it in UTC, you make sure it never needs to be adapted for daylight savings time.

The only reason to set it to localtime would be if you have (physical) MS OSes running on the same box. But you're not running a dualboot WinXP-ESX on this machine, are you ?

The time representation is will not be affected, whatever you choose. But rebooting in- and outside of daylight savings time periods might result in one-hour-off time problems if you have your BIOS clock in localtime.

Thus: the BIOS clock should be in UTC !

[zhangfred_vm]

thanks, bertdb,

I am not understand .

Could you give me an example?

[zhangfred_vm]

Does the option "System Clock uses UTC" mean whether we set your time via the BIOS?

If we set the time use UTC, then any modify the system in the service console will be resulted in the System Clock modified.

So when the system is rebooted, the datetime presented in the service console will keep consistant with the time before it is rebooted.

[Hompie]

VM's have issues gaining time, or loosing time, the workaround / solution to this problem is among other to set the ESX and the Vm's to the same timezone. Therefore if you set the ESX to UTC, you would need to set the VM's to it also. That is only handy when the users are in the UK.

We set the timezone of the ESX to the timezone of the location, and the VM's also. You can then opt to use daylight savings or not.

[bertdb]

when the service console boots, time is always initialised using the BIOS clock. That's something that you can't change. The BIOS clock is the only time source available at that time.

But this is just the \_initialisation_. From that point on, the service console kernel counts the time independently, and you can further synchronize it using NTP once your network connection is up.

When the system is rebooted properly, we will write the current time to the BIOS clock before rebooting, and after rebooting, the normal initialisation process will pick up the time again from the BIOS clock.

[bertdb]

let's suppose the BIOS counts in local time: GMT+5

the system boots, and the service console is initialised correctly.

the service console kernel starts counting from there (it converts to UTC, and converts back to local time whenever the date/time needs to be displayed)

when the daylight savings time changes, local time changes to GMT+6

the service console now displays the time correctly, because the translation of the time is aware of DST changes

But after a crash/reboot, the service console initializes with the BIOS (GMT5) time, but interprets it as GMT6, because that's the current local time zone.

=> one hour difference between displayed time and real time.

[bertdb]

the gaining/loosing time shouldn't have anything to do with timezones. It has to do with losing timer interrupts due to the descheduling (periods where a certain VM doesn't run) and the inability to provide enough timer interrupts after a descheduled period to "catch up".

[zhangfred_vm]

bertdb, thank you very much.

after read your answer, my understanding is :

>>But after a crash/reboot, the service console initializes with the BIOS (GMT5) time, but interprets it as GMT6, because that's the current local time zone.

When it is rebooted, the linux kernel will convert the time in this way.

Service Console Time = (GMT+5)- 6 + 6 = GMT + 5

while

Real Time = GMT + 6

so there is one hour difference, am I understandingn right?