VMware-Forum

Hi,

ich habe gestern unserem Cluster 2 neue Hosts hinzugefügt und dabei nicht drauf geachtet, das die beiden neuen Hosts eine falsche Zeit eingestellt hatten.

Jetzt hatten wir auf einigen Server die auf diese Hosts verschoben wurden (DRS) die falsche Zeit der neuen Hosts, obwohl in den VMware Tools die Hacken für die Zeitsynchronisation nicht gesetzt ist.

Meiner Meinung nach sollte die Zeit des Hosts die VM nicht beeinflussen, es sei denn der Hacken ist gesetzt, oder versteh ich da was falsch.

Im Eventlog steht nichts, da ist die Zeit der Einträge eon einem zum anderen Eintrag plötzlich anders.

Jemand ne Ahnung was da passiert sein könnte?

Die Maschienen die eine geänderte Zeit hatten waren Windows 2003 R2 oder 2008 R2 mit Hardwareversionen zwischen 7 und 9 und veralteten (von 5.0) oder aktuellen vmware Tools, also nichts einheitliches an dem ich es fest machen könnte.

Ich verwende ESX Version 5.1.0, 838463

Beim Starten übernimmt das Gast die BIOS Uhrzeit. Diese ist natürlich die des Hosts.

MarcelMertens hat geschrieben:Beim Starten übernimmt das Gast die BIOS Uhrzeit. Diese ist natürlich die des Hosts.

nur ist keiner der Server neu gestartet zu dem Zeitpunkt

Wenn die beiden neuen Hosts die falsche Zeit eingestellt hatten, setzt sich dies auch bei darauf gestarteten VMs fort.
Beim jedem VM-Start wird ohne manuellen Eingriff in die VMX-Datei immer die Host-Zeit als momentane Zeit übernommen und das ist unabhängig davon, ob du die Zeitsynchronisation mit zwischen Host/Gast aktiviert hast.
Speziell im Cluster dürfte es meines Wissens aber gerade keine Zeitunterschiede geben oder sehe ich das falsch?

dieses Verhalten ist mir inzwischen auch aufgefallen, dass VMs sich die Zeit vom Host holen, obwohl das in den Eigenschaften explizit der VM nicht angegeben ist. Dieses Verhalten ist in ESX4 m.E. nicht so gewesen. Das ist insofern unangenehm, als das z.B. bei Windows Clients die Domänenzeitsync. ausgehebelt wird, die Authentifizierung an der Domäne fehl schlägt und dann die Windows eigene Zeitsync auch nicht mehr klappt.

Meiner Meinung nach ist das ein unakzeptables Verhalten, denn die Option ist vorhanden und per default eigentlich nicht aktiviert.

Umso mehr ein Grund darauf zu achten, dass jeder Host eine aktivierten NTP Client konfiguriert hat.

Dieses Verhalten ist in ESX4 m.E. nicht so gewesen.
...
Meiner Meinung nach ist das ein unakzeptables Verhalten, denn die Option ist vorhanden und per default eigentlich nicht aktiviert.

Das es mit einem anderen Produkt anders gewesen sein soll, kann ich mir nur schwer vorstellen. Bei VMserver, Workstation/Player und Fusion war es nie anders gewesen. Weshalb sollte es beim ESX(i) also anders sein und wie sollte er es sonst machen?
Wenn du einen Rechner normal startest, übernimmt dieser doch auch erstmal die Zeit vom pBios und das OS überschreibt diese anschließend per NTP, Netzwerk oder DCF77-Empfänger.
Das man sich die Startzeit vorher als Unixzeit berechnen und in die VMX eintragen kann, macht man nur zu besonderen Zwecken. Diese vor jedem VM-Start erst zu ändern, ist wohl kaum praktikabel zu nennen. Im Endeffekt wird dabei lediglich die Zeit im vBIOS entsprechend geändert, daß könnte man notfalls (bzw bei ausreichendem Masochismus auch bei jedem Start) manuell nachholen.

Auf der anderen Seite stellt sich mir die Frage, weshalb man zwar einen Cluster konfigurieren kann, aber nicht den eingebauten NTP-Client im ESX(i) nutzt.
Spätestens wenn man Zugang zu einer Netzwerkfreigabe hat, sollten Lokal- und Netzzeit zumindest minutengenau sein. Andernfalls sind dauerhafte Rückfragen zu erwarten, manch einer schaut doch mal auf das Dateidatum oder einige SW wie manche Zeiterfassungssysteme kommen sogar völlig aus dem Tritt.
Beispielsweise ist unsere Zeiterfassung an den SBS2011 angeflanscht und dieser hatte unglücklicherweise "time.windows.com" konfiguriert bekommen. Kleine Sprünge waren für die Zeiterfassung noch unkritisch und der SBS blieb davon unbeeindruckt, zumindest lief das Tagesgeschäft ohne Probleme. Nachdem aber die Zeit unregelmäßiger, die Sprünge grösser wurden und ihren Höhepunkt in einem mehr als einstündigen Spung in die Vergangenheit fanden, hing sich die Zeiterfassung auf und produzierte nur noch Müllbuchungen.
Die mit der Zeiterfassung betraute Kollegin dankt unserem Sys-Admin auch heute noch für die vielen von ihr deswegen vorzunehmenden Korrekturbuchungen.

warum es anders gewesen sein soll? Weil ich dieses Verhalten seit ESX 2.0 nicht beobachten konnte. Es hat ja auch keinen Sinn eine "Option" anzubieten, und diese dann nicht mehr Optional zu machen, sondern restriktiv.

Leider habe ich keinen ESX4 Server mehr zum Testen, hatte vor v5 auch nur ESX ohne i im Einsatz.

Du hast natürlich recht, die ESXi Server gehören per NTP gesynced'. Sind sie es nicht hat man bis auf das Gastsystem Probleme, also ist der Einsatz von NTP zwingend notwendig.

Andererseits ist es Best-Practice EINE Zeitsynchronisation zu verwenden, nicht mehrere. In Windows Umgebungen sind das per Default eben die Domain Controller. Wenn ich mich also nicht darauf verlassen kann, dass eine deaktivierte Option auch deaktiviert bleibt, dann ist das ein Fehler.

Zusätzlich kommt noch, dass zumindest unter ESXi5.0 der NTP Dienst auf dem Host gerne mal auf "Stopped" steht, obwohl der expliziert aktiviert wurde und auf automatisch steht. Auch ein Bug?

Es reicht ja auch eine Zeitsync, bei dem sich aber alle ESX(i)-Server ihre Zeit abholen. Denn sind die Hosts im Sync, müssen es ohne manuellen Unixzeit-Eintrag in der VMX, auch alle Gäste sein.

Du sagst, daß du es seit ESX2.0 nicht beobachten konntest. Ich stelle deine Aussage mal um und du beantworte dir dann mal folgende Frage:

Mit welchem Datum und Uhrzeit waren die VMs gestartet, wenn sie auf früheren ESX(i)-Versionen ausgeführt wurden?

Möglich wären die kleinstmögliche Unixzeit bei Zeitstempel Null ab Donnerstag, den 1.Januar 1970 00:00 Uhr UTC oder der Beginn der Microsoft-Zeitrechnung in Schritten von 100 ns ab dem 1.Januar 1901 oder die früheste Zeiteinstellung im p- bzw v-BIOS.
Eigentlich kannst du jetzt nur zu der Erkenntnis kommen, daß man vorher nur nie richtig darauf geachtet hatte. Wozu auch, wenn's läuft, ist alles schick.

Wenn der NTP-Dienst öfter mal unerwartet stoppt, kann das mehrere Gründe haben.
Entweder liegt wirklich ein Bug vor, beim ESXi5.1 hat Murphy eh schon voll zugelangt und die längste Mängelliste aller neuen Produktversion produziert, da käme es auf das bisschen NTP auch nicht mehr an oder die zeitliche Differenz bzw Varianz im Zeitstempel war aus unbekannten Gründen so groß, daß von einer genauen Zeit keine Rede mehr sein kann. In solchen Fällen ist es dann einfach besser, wenn der NTP-Dienst/Damon seine Arbeit einstellt und einen entsprechenden Vermerk ins System-Log macht.
Wer noch einen DCF77-Empfänger im Einsatz hat, ist jetzt natürlich fein raus. Aber so ein Teil kann man sich ausgehend von http://www.amateurfunkbasteln.de/dcf77 auch leicht für wenig Geld basteln. Wem der darin verbaute USB- oder Serial-Port nicht zusagt, kann sowas als Zeitserver auch mit RJ45-Anschluß ins Netzwerk hängen.

AFAIK übernimmt die VM beim Starten die Zeit des Hosts, und auch beim vMotion-Vorgang die Zeit des Zielhosts.

Ganz egal, welche Einstellung man für die Synchronisation ueber die tools gemacht hat.
Diese Einstellung gilt dann nur im laufenden Betrieb.

Macht ja auch Sinn, denn irgendwoher muss beim Starten der VM der ESX ja eine Zeit festlegen, und das Gast-OS läuft zu dem Zeitpunkt noch nicht.

Viele Grüße,
Jörg