Auf meinem Host verwende ich libvirt und einen KVM-Gast. Wenn der Host heruntergefahren wird, setzt libvirt den Gast an. Wenn der Host gestartet wird, setzt libvirt den Gast fort. Das Problem ist, wenn der Gast beispielsweise angehalten und nach 24 Stunden fortgesetzt wird, dann liegt die Gastzeit 24 Stunden in der Vergangenheit.
Ich dachte, dass das Problem vielleicht an der Taktquelle liegt, aber diese ist bereits auf „kvm-clock“ eingestellt.
$ cat /sys/devices/system/clocksource/clocksource0/available_clocksource
kvm-clock tsc hpet acpi_pm
$ cat /sys/devices/system/clocksource/clocksource0/current_clocksource
kvm-clock
Antwort1
Das Problem
Ich habe das gleiche Problem und keine gute Lösung gefunden. Folgendes habe ich gefunden:
Das Problem besteht darin, dass nach der Wiederaufnahme die System- und Hardwareuhrzeiten auf dem Gast unterschiedlich sind:
root@guest:~# date; hwclock
Sat Oct 11 13:09:38 UTC 2014
Sat Oct 11 13:10:42 2014 -0.454380 seconds
In Bezug auf den Host sind sie sich einig:
root@four:~# date; hwclock
Sat Oct 11 13:11:35 UTC 2014
Sat Oct 11 13:11:36 2014 -1.000372 seconds
Die Lösung wäre, den Betrieb hwclock --hctosysauf dem Gast nach dessen Wiederaufnahme fortzusetzen. Ich habe jedoch keine Möglichkeit gefunden, dies nur mit Änderungen auf dem Gastsystem zu tun, da der Gast nicht bemerkt, dass er angehalten und wiederaufgenommen wird.
QEmu-Gast-Agent
Es besteht die Möglichkeit, eine Software namensQEmu-Gast-Agentauf dem Gast und Benachrichtigung vom Host, um die Systemuhr des Gastes von der Hardware-Uhr des Gastes zu aktualisieren. Auf der Seite wird jedoch erwähnt, dass dieDer Gastagent macht Host und Gast anfällig für Angriffevoneinander aufgrund von Problemen mit einem JSON-Parser (zumindest glaube ich, dass der betroffene Code auch auf dem Host ausgeführt wird, da bin ich mir nicht sicher). So richten Sie das ein:
Richten Sie einen Virtio-Seriellenkanal für den Agenten ein, wie imLibvirt-Wiki(siehe auchDokumentation zum libvirt-Domänenformat).
Nachdem der serielle Kanal verfügbar ist, installieren und starten Sie den QEmu Guest Agent auf dem Gast. (Debian:
apt-get install --no-install-recommends qemu-guest-agent.)Lösen Sie den Taktversatz durch Anhalten, Warten und Fortsetzen aus. Führen Sie dann den folgenden Befehl auf dem Host aus, um ihn zu korrigieren:
virsh qemu-agent-command backup '{"execute":"guest-set-time"}'Die Wiki-Seite, die verwendet wird,virsh qemu-agent-commandistnicht unterstützt, aber ich habe keinen anderen Befehl gefunden, der das erledigt.
Ich habe zwei Diskussionen zur Automatisierung des Aufrufs zum guest-set-timeFortsetzen aus einem Suspend in libvirt gefunden:
- http://thread.gmane.org/gmane.comp.emulators.libvirt/92431(Februar 2014)
- http://thread.gmane.org/gmane.comp.emulators.libvirt.user/7051(September 2014)
Allerdings wurde bisher noch nichts umgesetzt, soweit ich sehen konnte.
Informationen zum Senden von Befehlen an den Gastagenten fand ich aufWiki von stoney-cloud.org.
Ich habe auch versucht, tickpolicy="catchup"dieLibvirt-Timer-Konfigurationaber das hat das Problem nicht gelöst.
NTP
Eine Alternative zur Verwendung des Agenten wäre die Verwendung eines NTP-Daemons oder der regelmäßige Aufruf von ntpdate von einem Cron-Job aus. Letzteres würde ich nicht empfehlen, da die Zeit dadurch rückwärts laufen kann, was Programme verwirren kann (zum Beispiel dieDer Dovecot IMAP-Server versucht nicht, die Zeit rückwärts zu verarbeitenund kann kündigen).
Ich habe die folgenden NTP-Daemons ausprobiert:
openntpd: Korrigiert die Zeit sehr langsam mit einer Rate von etwa 2 Sekunden pro 60 Minuten in meinem Test. Der Zeitversatz betrug 120 Sekunden. Außerdemopenntpdgibt einen Fehler aus, wenn der Zeitversatz zu groß ist, und schlägt in meinem Test in diesem Fall die Zeitkorrektur vollständig fehl. Vorteile von openntpd: Kann als normaler Benutzer in chroot ausgeführt werden.
Chroniken: Korrigiert in meinem Test einen Zeitversatz von 120 Sekunden in 30 Minuten. Chrony kann so konfiguriert werden, dass es als normaler Benutzer ausgeführt wird. Chroot-Unterstützung ist nicht implementiert. Das Abfrageintervall des NTP-Servers kann für jeden NTP-Server konfiguriert werden.
systemd-timesyncd: Korrigiert in meinem Test einen Zeitversatz von 120 Sekunden in 30 Sekunden. Läuft standardmäßig als normaler Benutzer. Das Abfrageintervall von NTP-Servern erhöht sich jedoch auf bis zu 2048 Sekunden, sodass ein Suspend/Resume im schlimmsten Fall erst 34 Minuten nach dem Resume erkannt würde. Dies scheint nicht konfigurierbar zu sein. Außerdem habe ich beobachtet, dass timesyncd die Zeit zurücksetzt, was dieselben Probleme verursacht wie der Aufruf von ntpdate in einem Cron (siehe oben).
chrony löst das Problem. Openntpd ist nicht geeignet, da seine Korrekturrate zu niedrig ist und nicht konfigurierbar zu sein scheint. systemd-timesyncd löst das Problem auch nicht vollständig, da sein Abfrageintervall nicht konfigurierbar ist.
Ich habe die folgenden Debian-Versionen der NTP-Daemons getestet: openntpd 20080406p-10, chrony 1.30-1 und systemd 215-5+b1.
Antwort2
Viele Virtualisierungshostvorgänge auf dem Gast können zu einer Pause und Wiederaufnahme führen. Dies wirkt sich negativ auf die Systemuhr des Gasts aus. Beispielsweise führt das Klonen einer VM zu einer Pause während des Klonvorgangs. Die Gastuhr ist danach im Rückstand. Um NTP dazu zu bringen, die Uhr zu synchronisieren, müssen Sie den Gast neu starten – das ist sicher nicht in allen Fällen eine gute Lösung. Alternativ könnten Sie einfach ntpd im Gast neu starten, aber das ist auch nicht optimal. Idealerweise muss ein Ereignis (VM wieder aufgenommen) verfügbar sein, das Sie optional für diese Art der Korrektur des Gasts verwenden können.
Nachdem ich einige Zeit mit der Recherche zu diesem Thema verbracht hatte, entschied ich mich, die Host-Uhr direkt als Referenz für die Systemuhr des CentOS 7-Gastbetriebssystems zu verwenden.
Anstatt ntpd im Gastbetriebssystem laufen zu lassen, habe ich beschlossen, alle 15 Minuten die Systemuhr des Gastbetriebssystems über crontab anhand der Hardwareuhr des Gastbetriebssystems einzustellen. Die Hardwareuhr des Gastbetriebssystems spiegelt die Zeit auf dem Virtualisierungshost wider, der über ntpd gesteuert wird, das auf dem Virtualisierungshost läuft. Dadurch erhalte ich eine zuverlässige Zeit im Gastbetriebssystem. Im schlimmsten Fall kann die Uhr bis zu 15 Minuten lang falsch sein, bevor sie nach der Wiederaufnahme des Gastbetriebssystems auf die richtige Zeit synchronisiert wird.
# crontab -e
0,15,30,45 * * * * /sbin/hwclock --hctosys
Es wäre viel besser, wenn beim Gast ein Ereignis verfügbar wäre, das eine Zeitsynchronisierung einleitet, wenn der Gast wieder aufgenommen wird, aber das ist anscheinend nicht möglich. Der Crontab-Ansatz ist ein Workaround, da er alle 15 Minuten einen hwclock-Aufruf ausführt. Damit wird die Arbeit erledigt, aber nicht so elegant, wie ich es gerne hätte.
Antwort3
libvirt unterstützt Gastzeitsynchronisierung seit2015. Suchen Sie unter Debian Stretch und höher nach der Option SYNC_TIMEin /etc/default/libvirt-guests:
# If non-zero, try to sync guest time on domain resume. Be aware, that
# this requires guest agent with support for time synchronization
# running in the guest. For instance, qemu-ga doesn't support guest time
# synchronization on Windows guests, but Linux ones. By default, this
# functionality is turned off.
#SYNC_TIME=1
Sie können die Zeitsynchronisierung innerhalb des Hostsystems mit Folgendem testen:
virsh qemu-agent-command INSERT_YOUR_DOMAIN_HERE '{"execute":"guest-set-time"}'
Dieser Befehl sollte {"return":{}}bei Erfolg zurückkehren.
Antwort4
Seit Linux Kernel 4.11 gibt es PTP-KVM(Precision Time Protocol - Kernel Virtual Machine):PTPist vergleichbar mitNTP, jedoch mit höherer Genauigkeit und für das lokale Netzwerk. Das Linux-Hostsystem exportiert seine aktuelle Zeit zum effizienten Lesen als /dev/ptp_kvm(oder /dev/ptp0) an jedes Gastsystem.
Chronikenist in der Lage, dies innerhalb der VM zu verwenden:
modprobe ptp_kvm
echo ptp_kvm >/etc/modules-load.d/ptp_kvm.conf
apt-get install chrony
echo "refclock PHC /dev/ptp0 poll 2" >/etc/chrony/conf.d/ptp.conf
systemctl restart chronyd
Als Voraussetzung muss auch die Zeit auf dem Host synchronisiert werden.
Möglicherweise möchten Sie die Konfiguration auch makestep 10 -abhängig davon vornehmen, welchen Unterschied Sie tolerieren möchten: In diesem Beispiel würde ein Unterschied unter 10 Sekunden durch Beschleunigen der VM-Uhr ausgeglichen, während größere Unterschiede mit allen (schlechten) Konsequenzen ausgeglichen würden.
Ich fand dies in derRedHat-Dokumentation, also ein großes Lob an sie.