• Diese Seite verwendet Cookies. Indem du diese Website weiterhin nutzt, erklärst du dich mit der Verwendung von Cookies einverstanden. Erfahre mehr

bhyve + ntpd

Themenstarter #1
Hallo,
ich hab auf meiner FreeBSD-Kiste (10.1) ein paar VMs mit bhyve aufgesetzt. Da die Uhrzeit nach längerer Uptime von der des Hosts abweicht, hab ich auch auf den VMs ntp konfiguriert.

Die Zeitsynchronisierung funktioniert, jedoch bekomme ich lauter solche Einträge in /var/log/messages:
Code:
Mar 26 08:12:40 merovingian ntpd[49210]: time reset -0.635566 s
Mar 26 08:29:21 merovingian ntpd[49210]: time reset -0.640404 s
Mar 26 08:46:00 merovingian ntpd[49210]: time reset -0.638410 s
Mar 26 09:03:14 merovingian ntpd[49210]: time reset -0.627989 s
Mar 26 09:20:18 merovingian ntpd[49210]: time reset -0.648696 s
Mar 26 09:36:50 merovingian ntpd[49210]: time reset -0.633849 s
Mar 26 09:54:52 merovingian ntpd[49210]: time reset -0.662615 s
Mar 26 10:11:13 merovingian ntpd[49210]: time reset -0.633091 s
Mar 26 10:28:15 merovingian ntpd[49210]: time reset -0.625258 s
Mar 26 10:45:35 merovingian ntpd[49210]: time reset -0.628857 s
Mar 26 11:04:43 merovingian ntpd[49210]: time reset -0.676957 s
Mar 26 11:21:50 merovingian ntpd[49210]: time reset -0.642611 s
Mar 26 11:39:46 merovingian ntpd[49210]: time reset -0.637237 s
Mar 26 11:56:45 merovingian ntpd[49210]: time reset -0.642307 s
Ich hab zwar versucht, das Problem zu googeln, aber dafür scheint bhyve noch zu wenig im Einsatz.

Hat irgendwer Ideen/Vorschläge, wo das herkommen könnte? Oder ist der Ansatz byhve + ntpd grundsätzlich verkehrt?

Schonmal vielen Dank an Euch :-)
 

m4rkus

Well-Known Member
#3
Früher gab es das so genannte Timekeeping-Problem, welches bei Virtualisierungsumgebungen anzutreffen war.
Das hat etwas mit der virtualisierten "HW-Uhr" zu tun und wie gut die "Ticks" verarbeitet werden.

Wenn ich mich richtig erinnere waren die Best-Practices von VMWare die saubere Konfiguration von ntp oder aber die ausschließliche Verwendung der VMWare-Methoden zum "Timekeeping". Ich weiß nicht wie genau die Byhve-Synchronisation läuft und ob es überhaupt Mechanismen dafür gibt. Daher sollte nichts gegen NTP sprechen.

Gruß
Markus
 
Themenstarter #4
Dann scheint es wirklich so zu sein, dass die bhyve-Uhr einfach entsprechend "herumspringt" (also über den step-threshold von 0.128 ms) und dann im ntp einen step auslöst. Ich hoffe einfach mal, dass das nicht schlimmer wird (also bei -0.6 s bleibt), denn zum Beispiel Dovecot mag um mehr als eine Sekunde zurückspringende Uhren gar nicht (da bauen scheinbar diverse Timestamps drauf).

Danke Euch für den Input :-)
 
Themenstarter #5
Scheinbar bietet der ntpd aus base auch keine Möglichkeit, diese Log-Messages zu unterdrücken... Naja, bhyve ist ja noch recht jung, vielleicht wird das ja noch :-)
 

Yamagi

Possessed With Psi Powers
Mitarbeiter
#6
Ja, das ist bekannt. Das die Realtime-Clock springt, ist nur der Gipfel des Problems. Wesentlich schlimmer ist, dass im Moment jeder Zugriff auf die Timecounter einen VM-Exit bedeutet. Die sind extrem teuer, was hauptsächlich den ~5% Performance-Unterschied zwischen Bhyve und KVM erklärt. Man arbeitet daher an der Integration des virtio Zeitmoduls, aber wie weit das ist, weiß ich leider nicht.
 

lme

FreeBSD Committer
#7
Ich habe diese Woche noch "irgendwo" gelesen, dass man im bhyve-Client die kern.timecounter.hardware auf was Bestimmtes setzen soll, aber weiß nicht mehr, wo ich es gelesen habe. :(
 

vto

Active Member
#8
Hatte vor einigen Wochen exakt das gleiche Problem, welches ich mit Setzen von kern.timecounter.hardware in den Griff bekommen hatte.

Die möglichen Werte bekommst Du über 'sysctl kern.timecounter.choice', bei mir war der extreme Shift bei 'TSC-low' behoben. Für dauerhaftes Setzen in die /etc/sysctl.conf eintragen...

Das Problem äußert sich übrigens nicht nur in den Logs sondern auch darin, dass das Drift File von ntpd auf den Maximalwert gesetzt wird, ich glaube 500,00 oder so - mehr verkraftet ntpd nicht, weshalb er ständig nachregelt. Seit TSC-low bleibt das im Bereich von -150 und ntpd muss kaum nachsteuern.

Gruß
 

Firun

New Member
Themenstarter #9
Entschuldigt bitte die späte Antwort, hab das Thema etwas aus den Augen verloren,
Code:
sysctl kern.timecounter.hardware=TSC-low
hat tatsächlich geholfen :-)

Das Offset zum Zeitserver ist stabil bei 0.135 ms, und das Driftfile bei -158. Die ersten ~24 h nach der Umstellung gab es noch ein paar (kleinere) Steps, aber mittlerweile seit knapp 20 h keinen mehr.

Nochmals vielen Dank an euch :-)
 

mark05

Well-Known Member
#10
hi

mal die frage an die kenner .

wie ist zz. der status bezüglich bhyve und ntpd

muss ich in der vm noch den ntpd laufen lassen oder reicht es auf dem host und der reicht die zeit durch ?

Holger