Muss ich in jeder VM einen NTP-Server ausführen?

Könnten die Gäste nicht irgendwie die Systemzeit des Hosts erben?

Es erscheint irgendwie sinnlos, denselben Daemon mehrmals auszuführen, um dieselben Ergebnisse auf demselben Computer zu erzielen, aber ich habe beim Lesen von KVM- oder Xen-Artikeln nichts mit der Zeit zu tun gehabt. Ich verstehe, dass der Gast die Host-Zeit beim Booten erhält, diese dann aber auseinander driften kann. Ist das korrekt ?

Das ist richtig. Es ist zu beachten, dass die Zeit nicht nur "wegdriften" kann, sondern auch wegdriften wird , da die Intervalle zwischen Timer-Interrupts (auf denen die Zeitmessung unter Betriebssystemen häufig basiert) nach Belieben des Hypervisors gedehnt und komprimiert werden.

Eine gängige Problemumgehung für die meisten Virtualisierungsplattformen (Hyper-V-Integrationsdienste, VMWare-Tools) besteht darin, dass auf dem Gast ein Dämon ausgeführt wird, der die Uhren regelmäßig mit dem VM-Host synchronisiert. Wie Hauke ​​in einem Kommentar zu Ihrer Frage angemerkt hat, stellt KVM zusätzlich eine paravirtualisierte Uhr zur Verfügung, für die der entsprechende Treiber auf dem Gastbetriebssystem geladen sein müsste.

Zeitmessung in virtuellen VMWare-Maschinen (vmware.com)
KVM-Gastuhrsynchronisation (s19n.net)

In einer perfekten Welt würden Ihre VM-Gäste die perfekte Zeit einhalten oder zumindest so perfekt, wie es der Host bereitstellt. Leider leben wir nicht in einer perfekten Welt.

Aufgrund meiner Erfahrung mit praktisch jedem bekannten Hypervisor führe ich ausnahmslos einen NTP-Client in virtuellen Maschinen aus. Mein übliches Setup ist ntpd mit der Option -g oder ntpdate, das bei alten Systemen direkt davor startet, um die Uhr zu stellen (was beim Systemstart möglicherweise weit von der Synchronisation entfernt ist).

KVM hat mit seiner paravirtualisierten Echtzeituhr fast das perfekte Setup . Gäste mit dem entsprechenden Treiber (mindestens alle aktuellen Linux-Versionen) behalten sowohl Zeit als auch den Host. Hier läuft aber immer noch etwas schief: Auf dem Host wird möglicherweise kein NTP ausgeführt, auf dem Host ist möglicherweise eine falsche Zeitzone eingestellt, die Uhr des Hosts ist möglicherweise einfach falsch usw.

VMware und Hyper-V fallen in die Mitte. Jedes verfügt über ein Tool, das auf dem Gast ausgeführt werden soll und die Uhr regelmäßig mit dem Host synchronisiert. Auch dies ist jedoch anfällig für vorhandene Probleme mit der Hostuhr.

Gäste auf meinem Test-Hyper-V-Server zeigten auch ein merkwürdiges Verhalten: Selbst mit Integrationsdiensten würde die Gastuhr schneller als 500 ppm laufen, was die Funktion von ntpd verhindern würde ( die Uhr wird als verrückt angesehen, wenn sie schneller läuft ). Ich musste diese Gäste auf chronisch umstellen , damit dieser Wert angepasst werden kann.

Xen ist in dieser Hinsicht das Schlimmste. Es hat absolut keine Synchronisation und das Ausführen von NTP in den Gästen ist ziemlich erforderlich. (Mir wurde gesagt, dass die neuesten Versionen von Xen eine Art Synchronisation haben, aber noch nicht persönlich damit gearbeitet haben.)

Es wird nur schlimmer, wenn der Host-Hypervisor nicht unter Ihrer Kontrolle steht, z. B. eine öffentliche Cloud. Sie sind dem Anbieter in Bezug auf die Host-Uhr ausgeliefert. Wenn dieser nicht fleißig daran arbeitet, die Uhr synchron zu halten, verlieren Sie.

Mit all dem ist das Ausführen von NTP-Clients in Ihren virtuellen Maschinen ziemlich erforderlich, wenn Sie sogar eine halbgenaue Uhr benötigen. Hinweis: Wenn Sie virtuelle Windows-Maschinen ausführen, besorgen Sie sich einen NTP-Client eines Drittanbieters, der die Uhr kontinuierlich anpasst. Die schlechte Entschuldigung für einen Client, der mit Windows geliefert wird, stellt die Uhr nur einmal pro Woche ein , was absolut lächerlich ist.

Ich würde empfehlen, NTP zu verwenden, da es bekannt ist und schon lange existiert. Das Einstellen der Uhr ist nicht trivial. NTP hat dieses Problem behoben.

Die offizielle Linie von VMware besteht darin, einen Mechanismus zu verwenden, wobei NTP bevorzugt wird, weil es feinkörniger ist und kleinere Schritte unternimmt, um die Zeit anzupassen. Die interne VMware-Lösung unternimmt größere Schritte. Wenn Sie beide ausführen, können sie sich gegenseitig bekämpfen. Wenn die interne VMware-Lösung einen großen Schritt macht und NTP sie dann ein wenig anpasst und zurücknimmt.

In der Praxis laufen wir jedoch beide gleichzeitig und ich habe noch kein Problem gesehen.

$ ntpq   
ntpq> peers
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
something.org  172.2.1.5          2 u   57   64  377    1.597   -2.409   5.952


$  vmware-toolbox-cmd  timesync status
Enabled


$ vmware-toolbox-cmd help timesync
timesync: functions for controlling time synchronization on the guest OS
Usage: vmware-toolbox-cmd timesync <subcommand>

Subcommands:
  enable: enable time synchronization
  disable: disable time synchronization
  status: print the time synchronization status