localtime in BIOS und in ESX - Bug or Feature?

[Tyler_Durden]

Hallo zusammen,

hab grade meinen ersten ESX4 Upd1 Server aufgesetzt (HP DL380 G6) und brech mir grad einen ab bei der Zeitkonfiguration. Erfahrungen mit VMWare Server 2.0 auf debian und ESXi hab ich schon etwas gesammelt, aber jetzt soll es produktiv werden mit nem ESX.

Was ich will:

localtime sowohl im BIOS, als auch im ESX, weil ich in ILO2 nicht UTC Zeiten stehen haben will, sondern eben die lokale (CEST, bzw GMT+1)

Gewohnt aus debian hab ich also UTC=no gesetzt und ntpd an unseren timeserver gehängt. In ESX ist auch alles gut, aber bei jedem reboot setzt der mir die UTC Zeit ins BIOS (soll sehr selten vorkommen nen reboot, aber nervt trotzdem das jedesmal neu setzen zu müssen)

Konkret ist folgendes eingestellt:

Code: Alles auswählen

[root@vmwesx01 ~]# cat /etc/sysconfig/clock
ZONE=Europe/Berlin
UTC=false
ARC=false

[root@vmwesx01 ~]#


Im /etc/init.d/halt script (wird bei halt und reboot ausgeführt) habe ich dann folgende Zeilen gefunden, die mich etwas irritiert haben:

Code: Alles auswählen

# Sync the system clock.
CLOCKFLAGS="$CLOCKFLAGS --systohc --utc"

[ -x /sbin/hwclock ] && action $"Syncing hardware clock to system time" /sbin/hwclock $CLOCKFLAGS


In allen anderen runleveln, wo ntpd gestartet, oder gestoppt wird macht er brav eine Abfrage, was denn gesetzt ist in /etc/sysconfig/clock aber beim reboot scheißt er drauf und geht von utc aus?!
Auszug aus /etc/init.d/ntpd:

Code: Alles auswählen

 CLOCKFLAGS="$CLOCKFLAGS --systohc"

        case "$UTC" in
            yes|true)   CLOCKFLAGS="$CLOCKFLAGS --utc";;
            no|false)   CLOCKFLAGS="$CLOCKFLAGS --localtime";;
        esac


War jetzt einfach böse und hab das in /etc/init.d/halt geändert auf:

Code: Alles auswählen

CLOCKFLAGS="$CLOCKFLAGS --systohc --localtime"

Musste dann aber noch zusätzlich in die rc.local nen sync von der hwclock zum Betriebssystem einbauen, sonst stimmt die Uhrzeit nach dem booten in ESX auch nicht:

Code: Alles auswählen

hwclock --hctosys --localtime

Wobei das auch daran liegen könnte, dass ich dazwischen /etc/adjtime nicht gelöscht hatte und da noch die falschen Einstellungen drin waren.

Jemand ne Idee, ob ich einfach zu blöd bin, oder ob das tatsächlich nicht möglich ist im BIOS die localtime zu halten, ohne an den runlevel scripten zu hacken?

mfg tyler

[Tschoergez]

Ich wüsste auch keine andere Lösung.

In der API, (die ja z.B. auch vom vSphere Client verwendet wird, und das empfohlene Werkzeug für ESX-Einstellungen ist) gibts dafür gar keinen Schalter oder ähnliches.

Ich erinner mich einzig an eine Abfrage während der Installation mit "Systemclock uses UTC", bei der man eine checkbox aktivieren konnte.
Weiß aber nicht mehr, ob das in der aktuellen Version auch noch so ist...

Viele Grüße,
jörg

[Tyler_Durden]

Hi,

tja scheint kein Bug zu sein, sondern ein fehlendes Feature. Hab grade, da ich eh noch nicht viel konfiguriert hatte und es mich interessiert hat, ob ich bei der Installation was übersehen habe, mich dazu entschieden nicht das Update auf Update 2 zu machen, sondern eine Neuinstallation mit ESX 4 Update 2 zu machen und da gibt es keine Checkbox, ob die Hardwareclock auf UTC eingestellt ist, oder localtime. Also bleibt nur das gehacke, das ich oben schon genannt habe
Außer ich bin voll blind und hab es zwei mal übersehen. Ich teste mal ne Installation eines ESX 4 Update 2 nochmal, diesmal aber als virtuelle Maschine, wofür hab ich die Kiste denn

Irgendwo macht er beim booten ein Abgleich von der Hardwareclock zur Systemclock und geht von utc aus, wie beim halt, aber das finde ich nicht mit:

Code: Alles auswählen

grep -e "hwclock" /etc/rc.d/*/*


Also wird es entweder nicht mit hwclock gemacht, oder nicht mit Scripten aus dem Verzeichnis.

/etc/rc.local ist aber auch kein idealer Ort um den Abgleich Hardwareclock -> Systemclock zu machen, da das Script erst nach allen anderen ausgeführt wird. Da muss ich mir mal noch einen besseren Ort suchen, so früh wie möglich im Bootvorgang, denn so ist das bootlog in /var/log/messages komplett mit der falschen Zeit (momentan zwei Stunden zu spät, da Sommerzeit).
Wenn man den Angleich nach dem booten nicht macht, dauert es ca 5 min, bis ntpd die Uhrzeit wieder angeglichen hat, aber das sieht in den logs total blöde aus.
Mal sehen ob ich es so früh reinbekomme, dass das syslogd restart schon die richtige Uhrzeit hat:

Code: Alles auswählen

Jun 14 20:06:05 vmwesx01 kernel: Kernel logging (proc) stopped.
Jun 14 20:06:05 vmwesx01 kernel: Kernel log daemon terminating.
Jun 14 20:06:06 vmwesx01 exiting on signal 15
Jun 14 22:09:15 vmwesx01 syslogd 1.4.1: restart.
Jun 14 22:09:15 vmwesx01 kernel: klogd 1.4.1, log source = /proc/kmsg started.
Jun 14 22:09:15 vmwesx01 kernel: [    0.000000] Linux version 2.6.18-164.ESX (mts@pa-lin-bld530.eng.vmware.com) (gcc version 4.1.2) #1 Thu
 Mar 11 07:09:06 PST 2010 [ESX Service Console build 240614]


Der war da nicht 2h aus, das war ein reboot ("nur" 3 min POST das geht doch eigentlich), sobald der bootvorgang durch ist stimmt die Uhrzeit wieder im log wegen dem Angleich in rc.local.

mfg tyler

***edit***

gefunden:

Code: Alles auswählen

Jun 14 21:13:49 vmwesx01 kernel: Kernel logging (proc) stopped.
Jun 14 21:13:49 vmwesx01 kernel: Kernel log daemon terminating.
Jun 14 21:13:50 vmwesx01 exiting on signal 15
Jun 14 21:17:03 vmwesx01 syslogd 1.4.1: restart.
Jun 14 21:17:03 vmwesx01 kernel: klogd 1.4.1, log source = /proc/kmsg started.


/etc/rc.d/rc.sysinit ist der richtige Kandidat für die Aufgabe, habs ziemlich zum Schluss eingebaut, auf jeden Fall muss es nach dem remount read-write erfolgen, die Zeile unter dem # get the localtime from the hardwareclock (und den Kommentar natürlich auch) hab ich eingefügt:

Code: Alles auswählen

# Now that we have all of our basic modules loaded and the kernel going,
# let's dump the syslog ring somewhere so we can find it later
dmesg -s 131072 > /var/log/dmesg

# get the localtime from the hardwareclock
hwclock --hctosys --localtime

# create the crash indicator flag to warn on crashes, offer fsck with timeout
touch /.autofsck &> /dev/null


Funktioniert soweit gut. Einerseits schade, dass VMWare nicht die Möglichkeit das zu konfigurieren mitliefert, andereseits bin ich froh nen ESX zu haben, da kann man wenigstens noch eingreifen, da es grundsätzlich ein RedHat ist.
Da das aber ziemlich krass ist an den Scripten zu arbeiten empfehle ich jedem VORHER ein Backup der Dateien zu machen (überhaupt sollte man das mit allen Konfigurationsdateien machen, die man verändert).
Wenn ihr eure Kiste dabei zerballert und die nicht mehr bootet, gebt mir nicht die Schuld

***edit zum 2.***

Das ist doch noch zu spät im script, die device Dateien unter /dev, /tmp/.ICE-unix und /var/log/dmesg haben da noch die falsche Uhrzeit, daher noch etwas früher:

Code: Alles auswählen

[root@vmwesx01 ~]# grep -n -B 3 -C 3 -e hwclock /etc/rc.d/rc.sysinit
783-[ -x /sbin/pam_console_apply ] && /sbin/pam_console_apply -r
784-
785-# get the localtime from the hardwareclock
786:hwclock --hctosys --localtime
787-
788-{
789-# Clean up utmp/wtmp


Dann finde ich keine falschen Uhrzeiten mehr.

[Enrique]

Ich habe das gleiche Problem mit ESXi 4. Gibt es hierfür eine Lösung?

[Tyler_Durden]

Hi,

die Lösung hab ich doch beschrieben, ein paar Scripte, die beim hoch- und runterfahren ausgeführt werden editieren.

Sag doch mal genauer, wo du Probleme hast das zu verstehen/auszuführen, dann kann ich dir auch helfen.

mfg tyler

[Enrique]

Also ich nutze grad einen ESXi 4.1 Server der 2 verschiedene Uhrzeiten anschaut.

1. Wenn ich mich mit dem vSphere-Client verbinde und dann auf Konfiguration\Uhrzeitkonfiguration gehe, steht dort unter Datum und Uhrzeit 07:54

2. Wenn ich per SSH mich auf den Server verbinde und in der Kommandozeile den Befehl "date" eingebe, wird mir folgendes angezeigt: 05:54:27 UTC 2010

D.h. intern läuft die Uhr 2 Stunden hinter der tatsächlichen. Wie behebe ich das Problem?

Bei Scripten wird leider immer die interne Uhr berücksichtigt.