KVM und NTP auf den Gästen

[hoeschler]

Hallo,

Das Problem sollte hinreichend bekannt sein: Auf virtualisierten Gästen läuft keine Hardware-Uhr, was zur Folge hat, dass die Uhr selbst gerne mal ziemlich extrem vor- bzw. nach geht.

Ich hab jetzt von mehreren Seiten mehrere Lösungen gehört und hatte bisher sowohl auf dem Host als auch auf den Gästen ntp laufen mit minpoll 4 und maxpoll 4 um quasi so schnell es geht die Zeit zu syncen.
Dort habe ich allerdings das Problem, dass die Zeit auf den Gästen manchmal wirklich stark driftet und meine nagios ntp checks werfen regelmäßig crits.

Gleichzeitig habe ich bei kvm folgendes gefunden:
http://www.linux-kvm.org/page/KVMClock

Wo es heißt, kvm hätte eine eigene Lösung für die Gäste. Aus anderen Richtungen heißt es dann wieder, man solle den NTP nur auf dem Host laufen lassen und auf den Gästen tunlichst nicht.

Jetzt weiß ich nicht was richtig ist, tendenziell wäre mir die Lösung mit KVMClock lieber.

Preisfrage: Wie kann ich jetzt auf meinen Gästen monitoren, ob die Zeit tatsächlich passt? kann man irgendwie lokal einen ntpclient installieren, der nur kurz abfragt, wie denn so der offset gegenüber einem Zeitserver ist und irgendeine Form von Meldung rausgeben oder sowas?

[slu]

Ich hab mir da noch nie Gedanken darüber gemacht, auf meinen Gästen läuft der NTP Client und die Uhrzeit stimmt.

[rendegast]

minpoll 4 und maxpoll 4

Dann wird alle 8 Sekunden gepollt, halte ich nicht für sinnvoll.
Standard
minpoll 6 (64 Sekunden)
maxpoll 10 (~17 Minuten)
sollte reichen.

ala slu, bei mir chrony, und bezugnehmend auf einen lokalen Zeitserver statt welchen aus dem Internet.

manchmal wirklich stark driftet und meine nagios ntp checks werfen regelmäßig crits.

Was ist da die Größenordnung?
Kommt vielleicht durch das Einfrieren und Neustarten von VM?
("Echtes" suspend-to-disk hätte da Mechanismen)
Dann vielleicht einen Trigger überlegen, der die neue Zeit in der Maschine valide macht.
Die Zeitdämonen können mit ihren Korrekturmechanismen an einem (menschlich) kleinem Versatz tagelang korrigieren.

[cosmac]

hi,

man könnte die KVMClock benutzen und gleichzeitig einen ntpd auf dem Gast laufen lassen. Der bekommt aber als Refclock keinen echten Server, sondern nur seine eigene Systemuhr, ungefähr so:

Code: Alles auswählen

# server 0.debian.pool.ntp.org iburst
server 127.127.1.0
fudge 127.127.1.0 stratum 6

Dann kann man die Zeit auf dem Gast mit den normalen ntp-Werkzeugen fern-überwachen.

Natürlich sollte niemand diesen ntpd als Referenz verwenden. Obwohl, es funktioniert, nur die Drift ist nicht ganz ntp-like

[hoeschler]

Danke für die Tipps. Vor allem letzterer klingt testwürdig.

Tendentiell fände ichs natürlich schon praktisch, wenn der timesync alleine auf dem Host stattfindet.

Müsst ich halt irgendwie validieren können, dass es auch ohne weitere Bordmittel tut.
Ich könnt mit ntpdate -q zumindest als Trockenübung schauen, welche offset Anpassungen gemacht werden würden.

So richtig warm werde ich mit der "ntpd auf allen vm" Sache nämlich nicht.

@rendegast: merkliche Unterschiede. Manchmal 5-10 Sekunden, teilweise auch schon über 60. Das ist jenseits von schön. Ich habe die Befürchtung, dass sich die NTP Sync auf Host und Gästen in die Quere kommen. Das kann natürlich auch an dem geringen Polling liegen, welches ich fahre.

Was anderes zu den ntpclient Methoden: Reicht das, um auch zeitkritischen Kram fahren zu können? Also ich denke da an so Sachen wie LDAP Replikation, krb5 usw.

[rendegast]

Auf virtualisierten Gästen läuft keine Hardware-Uhr, was zur Folge hat, dass die Uhr selbst gerne mal ziemlich extrem vor- bzw. nach geht.

Für den Gast ist die "Hardware-Uhr" durch den Host vorgegeben.
Hat der auch solche drifts?

Nochmal zurTheorie:
Kernel übernimmt beim Start die RTC-Zeit,
korrigiert diese anhand der vergangenen offline-Zeit und eines vorhandenen drift-File,
im allgemeinen /etc/adjtime, um eine möglichst korrekte Systemzeit zu erreichen.
Dann läuft nur noch die kernel-Uhr, welche durch einen ntp-Client o.ä. korrekt gehalten werden sollte.
Dabei und/oder beim Herunterfahren wird die Differenz(Drift) der "driftenden" Hardware-Uhr zur "korrekten" Systemzeit vermerkt und noch die Hardware-Zeit aktualisiert.
Bei einem Host<->VM-System:
Sollte die Host-Systemzeit immer aktuall sein (ntp).
Der erste Vorgang, Übernehmen der "Hardware-Zeit", ist als das Übernehmen der Host-Systemzeit.
Ein evtl. im Betrieb generiertes drift-File IN der VM dürfte/sollte eigentlich keine großartige Korrektur veranlassen, da jegliche Korrektur dieser übernommenen Host-Systemzeit ja ein Verfälschen einer korrekten Zeit wäre.
Eine Korrektur dieses Umstands kann durch Löschen oder Zurücksetzen des drift-File beim Beenden der VM erreicht werden.
Das Driften der Systemzeit IN der VM:
Denkbar durch
- verschiedenen Betriebs- oder Schlafzustände der VM,
- technische Gegebenheiten der CPU-Clock IN der VM (denkbar wären Techniken der Virtualisierung, virtio)
- dynamische CPU (neue CPU-Techniken),
- Fehler im Zeitdämon (für das lokale Netz, das würde aber alle Rechner betreffen, also auch den Host, und sollte schnell auffallen(?)).
Beim dritten Punkt denke ich an einen kürzlichen Thread zur recht neuen Technik der intel_pstate für iX Intel-Prozessoren <-> dynamische CPU-Frequenz per ondemand.

Fehlerquellen können sich in ihrer Auswirkung also addieren.

Manchmal 5-10 Sekunden, teilweise auch schon über 60.

60 Sekunden dürfte ein ntp client-Dämon mit seiner normalen "langsamen" Korrektur schwerlich in akzeptabler Zeit korrigieren können.
Wenn sich die Ursache nicht abschalten läßt, so müßte wohl eine Korrektur per ntpdate, chronyc o.a. erfolgen.

so Sachen wie LDAP Replikation, krb5 usw.

krb darf wohl nur im Sekundenbereich differenzieren.
(Hier) toleriert netbios/samba Differenzen im Minuten/Stunden-Bereich, bei Stunden/Tagen kommen Login-Fehler.
Versuch mach kluch.

[hoeschler]

Okay

Was passiert jetzt also, wenn ich auf dem Host einen NTP laufen habe und der seine Hardware Zeit aktualisiert?
Ändert sich dann auch die Zeit auf dem Client? oder tickt die kerneluhr im Gast einfach ohne Änderungen vor sich hin?

Müsste ich eine Zeitanpassung im Host durch ein regelmäßiges hwclock -s setzen?

EDIT: Was ich gefunden habe: Es gibt wohl ein kleines snmp checkscript für nagios, mit dem ich jetzt meine Gäse abfrage

http://meinit.nl/nagios-time-check-using-snmp

Ich weiß nicht wie akkurat das arbeitet, daher noch keine näheren Infos. Ich lass jetzt einfach ein paar weniger zeitkritische hosts einmal mit ntp und einmal ohne alle laufen und schaue was passiert.

[rendegast]

Ha,
wenn ich auf dem Host mit Systemzeit (date -s ....) und RTC-Zeit (hwclock --systohc) herumspiele,
entspricht die Host-Systemzeit der VM-RTC-Zeit.
Eine Korrektur der VM-Systemzeit gegen die VM-RTC-Zeit wäre denkbar
und Bezug auf einen anderen ntp-Server dann nicht nötig.
(Vorraussetzung, die Host-Systemzeit ist ntp-korrekt).

Müsste ich eine Zeitanpassung im Host durch ein regelmäßiges hwclock -s setzen?

Würde die Systemzeit auf eine korrekte Zeit setzen.
Wäre aber ein walkaround mit dem Holzhammer.
Die Ausgabe von 'hwclock' ist nur Sekunden-genau,
zudem gibt es bei Benutzung des Programme eine "Wartezeit" von ca. 1 Sekunde.
Dadurch ist eine kontrollierte(!) automatische Lösung damit unpraktikabel.

Der chrony kann die RTC und dessen adjfile zwar setzen und setzen, aber wohl nicht als Zeitquelle benutzen.

Am einfachsten/genauesten ist also Benutzung eines ntp-Clients,
WENN es sich um eine genügend kleine Drift handelt.


Es sollte also der Ursache für diese starke Drift nachgegangen werden.
Ein Beobachtungswerkzeug in der Art

Code: Alles auswählen

#!/bin/sh
hwclock --show [--directisa]
date
echo "------"
[ -x /usr/sbin/ntpdate ] && ntpdate -q zeitserver    # -> offset

Ein weiteres systematisches Problem,
läuft der chrony (auch andere Zeitdämonen), kann der Zugriff per hwclock auf die RTC-Zeit nicht möglich sein.
Weiterhin, gebe ich mal einen Versatz von ~ 300 Sekunden vor:

Code: Alles auswählen

# hwclock --directisa --show; date
Sat 01 Mar 2014 10:26:39 AM CET  -0.615177 seconds
Sat Mar  1 10:20:30 CET 2014

Dann gibt chrony

Code: Alles auswählen

# service chrony start
Starting /usr/sbin/chronyd...
chronyd is running and online.

# echo rtcdata | chronyc
RTC ref time (UTC) : Sat Mar  1 09:31:58 2014
Number of samples  : 3
Number of runs     : 0
Sample span period :   32
RTC is fast by     :     1.635267 seconds
RTC gains time at  : 63419.281 ppm

# echo sources | chronyc
210 Number of sources = 1
MS Name/IP address           Stratum Poll LastRx Last sample
============================================================================
^* xxxxxxxxxxxxxxxxxxxx        3    8     95    -57us[ -110us] +/-   18ms

wo sind da die ~300s?
Als vertrauenswürdiges Abfragewerkzeug fällt chronyc also erstmal weg.
(die eigentliche Logdatei des Dienstes ist ein für mich nicht richtig nachvollziehbarer Datenwust)
Es kann aber mit

Code: Alles auswählen

echo makestep | chronyc

eine Korrektur eines größeren Fehlers der Systemzeit vorgenommen werden.

[hoeschler]

Danke für die Antwort.

Die Drift auf den Gästen kommt denke ich, wenn irgendwo ein I/O Lock ist. Ich kanns allerdings nur vermuten.

Das

Müsste ich eine Zeitanpassung im Host durch ein regelmäßiges hwclock -s setzen?

war von mir falsch formuliert. Ich wollte eigentlich fragen, ob ich meine Gäste dazu bringen müsste, eine Zeitänderung auf dem Host irgendwie durch Neusetzen der Uhr auch dort zu übertragen.

Das Monitoring übers Wochenende hat aber gezeigt: Nein, ich muss garnichts machen.

Es reicht tatsächlich ein Hostsystem mit einer CPU bestückt, die constant_tsc beherrscht, was praktisch alle können sollten. Dort muss ein NTP laufen, der die Uhr regelmäßig synct.

Dann muss man noch mittels

Code: Alles auswählen

cat /sys/devices/system/clocksource/clocksource0/current_clocksource  

auf den Gästen nachsehen, ob die Uhr auf kvm-clock steht und dann braucht man faktisch nix mehr weiter machen.