Warum NTP weiterhin in virtuellen Maschinen läuft, trotz Guest Agents und paravirtualisierter Uhren

Worum es geht

Das Zeitverständnis eines Gasts in einer VM wird von mehr als einem Mechanismus beeinflusst. Unter KVM beschreibt die Timekeeping-Dokumentation des Kernels kvmclock (kvmclock/kvm-clock) als paravirtualisierte Clocksource, die der Gastkernel anstelle einer in Software emulierten Hardwareuhr verwenden kann. Das verringert Drift und Overhead, die durch das Abfangen und Emulieren von Timer-Hardware entstehen. Unabhängig davon bietet QEMU den QEMU Guest Agent (qemu-ga) an, einen im Gast installierten Daemon, über den der Host per virtio-serial-Kanal Befehle an den Gast senden kann. Das ist ein Verwaltungskanal und keine Zeitquelle, auch wenn er auf Anforderung die Gastuhr einmalig setzen kann (virsh domtime <domain> --sync, das die Zeit aus der RTC des Gasts liest). Hyper-V bringt eigene Integration Services mit, darunter einen Time-Synchronization-Dienst (vmictimesync), der die Gastuhr mit der Uhr des Hosts abgleicht.

Warum es wichtig ist

Keiner dieser Mechanismen ersetzt einen Zeitsynchronisations-Client (chronyd, systemd-timesyncd oder den Windows-Zeitdienst) im Gast:

• kvmclock verbessert die Qualität und Stabilität der Clocksource, die dem Gastkernel zur Verfügung steht. Den Gast synchronisiert es nicht mit der tatsächlichen Zeit, und es kann weiterhin driften, insbesondere bei Host-Migrationen, Suspend/Resume des Hosts oder hoher CPU-Konkurrenz auf dem Host, die den tatsächlichen Lauf der virtuellen CPU des Gasts verzögert.
• Der QEMU Guest Agent kann die Uhr auf Anweisung einmalig stellen (zum Beispiel nach einem Resume), regelt sie aber nicht kontinuierlich nach.
• Die Zeitsynchronisationskomponente von Hyper-V folgt der Uhr des Hosts, der Gast ist also nur so genau wie der Host. Der Host selbst braucht weiterhin eine gute Zeitquelle, und der Gast profitiert zusätzlich von einem eigenen Zeitdienst (Windows-Zeitdienst, chronyd oder systemd-timesyncd).

So wird es angewendet

• In jedem Gast einen NTP-/chrony-Client (oder den Windows-Zeitdienst) aktiv und korrekt konfiguriert halten, unabhängig vom Hypervisor und von den installierten Gast-Tools.
• Nach Host-Migrationen, Snapshot-Wiederherstellungen oder dem Fortsetzen einer pausierten bzw. suspendierten VM ist mit einem Zeitsprung im Gast zu rechnen, bis der Client im Gast ihn korrigiert. Nach solchen Ereignissen den Dienststatus prüfen (chronyc tracking, w32tm /query /status), statt von einem kontinuierlichen Zeitverlauf auszugehen.
• Prüfen, welche Clocksource ein Linux-Gast tatsächlich verwendet: cat /sys/devices/system/clocksource/clocksource0/current_clocksource (bei KVM-Gästen typischerweise kvm-clock; neuere Gastkernel bevorzugen unter Umständen tsc, wenn der Host einen stabilen invarianten TSC bereitstellt). cat /sys/devices/system/clocksource/clocksource0/available_clocksource listet die Alternativen auf.
• Zeitangaben des Hosts (der Time-Synchronization-Integrationsdienst von Hyper-V, das Pendant bei VMware) als grobe Korrekturebene neben dem eigenen Zeitdienst des Gasts behandeln. Für Sonderrollen wie virtualisierte Domänencontroller, bei denen sich die beiden Quellen in die Quere kommen können, die Empfehlungen des Hypervisor-Herstellers beachten.

Stolpersteine

• Den NTP-Client im Gast deaktivieren, weil «der Hypervisor die Zeit übernimmt», und anschliessend nach einer Migration oder einem Resume Fehler bei der Zertifikatsvalidierung, bei Kerberos oder bei der Log-Korrelation beobachten.
• Annehmen, kvmclock allein halte die Wanduhrzeit korrekt. Es ist eine Eigenschaft der Clocksource, kein Synchronisationsprotokoll.