Na moim hoście korzystam z libvirt i gościa KVM. Gdy host się wyłącza, libvirt zawiesza gościa. Podczas uruchamiania hosta libvirt wznawia gościa. Problem polega na tym, że jeśli gość zostanie zawieszony i wznowiony na przykład po 24 godzinach, wówczas czas gościa wynosi 24 godziny w przeszłości.

Pomyślałem, że może problem dotyczy źródła zegarowego, ale jest już ustawiony na „zegar kvm”.

$ cat /sys/devices/system/clocksource/clocksource0/available_clocksource
kvm-clock tsc hpet acpi_pm 

$ cat /sys/devices/system/clocksource/clocksource0/current_clocksource
kvm-clock

Problem

Mam ten sam problem i nie znalazłem dobrego rozwiązania. Oto, co znalazłem:

Problem polega na tym, że po wznowieniu czasy systemowe i sprzętowe zegara gościa są różne:

root @ guest: ~ # date; hwclock
Sob. 11 października 13:09:38 UTC 2014
Sob. 11 października 13:10:42 2014 -0,454380 sekund

W przypadku hosta zgadzają się:

root @ four: ~ # date; hwclock
Sob. 11 października 13:11:35 UTC 2014
Sob. 11 października 13:11:36 2014 -1.000372 sekund

Rozwiązaniem byłoby uruchomienie hwclock --hctosysgościa po jego wznowieniu. Jednak nie znalazłem sposobu, aby to zrobić tylko ze zmianami w systemie gościa, ponieważ gość nie zauważa, że ​​jest zawieszony i wznowiony.

QEmu Guest Agent

Istnieje możliwość uruchomienia oprogramowania o nazwie QEmu Guest Agent na gościu i powiadomienia go przez hosta o aktualizacji zegara systemowego gościa z zegara sprzętowego gościa. Jednak strona wspomina, że agent-gość naraża hosta i gościa na ataki między sobą z powodu problemów z parserem JSON (przynajmniej uważam, że kod, którego dotyczy problem, jest również uruchamiany na hoście, nie jestem tego pewien ). W każdym razie oto jak to skonfigurować:

1. Skonfiguruj kanał szeregowy virtio dla agenta, jak wspomniano w wiki libvirt (zobacz także dokumentację formatu domeny libvirt ).

2. Po udostępnieniu kanału szeregowego zainstaluj i uruchom agenta gościa QEmu na gościu. (Debian:. apt-get install --no-install-recommends qemu-guest-agent)

3. Uruchom przesunięcie zegara, zawieszając, czekając i wznawiając. Następnie uruchom następujące polecenie na hoście, aby je poprawić: virsh qemu-agent-command backup '{"execute":"guest-set-time"}'Strona wiki, która używa, nievirsh qemu-agent-command jest obsługiwana , ale nie znalazłem żadnego innego polecenia, które wykonuje to zadanie.

Znalazłem dwie dyskusje na temat automatyzacji w libvirt, do której wezwanie guest-set-timepo wznowieniu zawieszenia zostało zawieszone:

• http://thread.gmane.org/gmane.comp.emulators.libvirt/92431 (luty 2014)
• http://thread.gmane.org/gmane.comp.emulators.libvirt.user/7051 (wrzesień 2014)

Jednak, o ile mogłem zobaczyć, nic nie zostało jeszcze wdrożone.

Znalazłem informacje na temat przesyłania poleceń agentowi-gościowi na wiki stoney-cloud.org .

Próbowałem również ustawić tickpolicy="catchup"w konfiguracji timera libvirt, ale to nie rozwiązało problemu.

NTP

Alternatywą dla korzystania z agenta byłoby użycie demona NTTP lub okresowe wywoływanie NTPTP z zadania CRON. Nie polecałbym tego drugiego, ponieważ może to spowodować cofnięcie się czasu, co może dezorientować programy (na przykład serwer IMAP Dovecot nie próbuje obsługiwać czasu cofania się i może zostać zakończony).

Próbowałem następujących demonów NTTP:

• openntpd : W moim teście bardzo powoli koryguję czas w tempie około 2 sekund na 60 minut. Przesunięcie czasu wynosiło 120 sekund. Również openntpd zgłasza błąd, jeśli przesunięcie czasowe jest zbyt duże i, w moim teście, całkowicie nie koryguje czasu w tym przypadku. Zalety openntpd: Może działać jako zwykły użytkownik w chroot.

• chrony : Koryguje przesunięcie czasowe o 120 sekund w ciągu 30 minut w moim teście. Chrony można skonfigurować do działania jako zwykły użytkownik. obsługa chroot nie jest zaimplementowana. Interwał odpytywania serwera NTP można skonfigurować dla każdego serwera NTP.

• systemd-timesyncd : W moim teście koryguje przesunięcie czasowe o 120 sekund w 30 sekund. Domyślnie działa jako zwykły użytkownik. Jednak interwał odpytywania serwerów NTP wzrasta do 2048 sekund, więc zawieszenie / wznowienie nie zostanie wykryte aż do 34 minut po wznowieniu w najgorszym przypadku. To nie wydaje się być konfigurowalne. Zauważyłem też, że timesyncd krok wstecz, co powoduje te same problemy, co wywoływanie ntpdate w cronie (patrz wyżej).

chrony rozwiązuje problem. Openntpd nie jest odpowiedni, ponieważ jego współczynnik korekcji jest zbyt niski i nie wydaje się być konfigurowalny. systemd-timesyncd również nie rozwiązuje całkowicie problemu, ponieważ jego interwału odpytywania nie można konfigurować.

Testowałem następujące wersje demonów NTP Debiana: openntpd 20080406p-10, chrony 1.30-1 i systemd 215-5 + b1.

Wiele operacji hosta wirtualizacji na gościu może spowodować wstrzymanie - wznowienie. Wpłynie to negatywnie na zegar systemowy u gościa. Na przykład klonowanie maszyny wirtualnej powoduje pauzę podczas klonowania. Zegar gościa jest za nimi. Aby NTP zsynchronizował zegar, musisz ponownie uruchomić gościa - na pewno nie jest to dobre rozwiązanie we wszystkich przypadkach. Alternatywnie możesz po prostu zrestartować ntpd na gościu, ale to też nie jest optymalne. Idealnie byłoby, gdyby było dostępne zdarzenie (wznowione VM), które można opcjonalnie wykorzystać do tego typu korekty dla gościa.

Po spędzeniu czasu na badaniu tego postanowiłem użyć zegara hosta bezpośrednio jako odniesienia do zegara systemowego systemu operacyjnego CentOS 7.

Zamiast uruchamiać ntpd na gościu, zdecydowałem, że co 15 minut ustawię, za pośrednictwem crontab, zegar systemowy gościa z zegara sprzętowego gościa. Zegar sprzętowy gościa odzwierciedla czas na hoście wirtualizacji, który jest kontrolowany przez ntpd działający na hoście wirtualizacji. To zapewnia mi niezawodny czas w systemie operacyjnym gościa. W najgorszym przypadku zegar może być wyłączony na maksymalnie 15 minut, zanim zostanie zsynchronizowany z właściwym czasem po wznowieniu gościa.

# crontab -e

0,15,30,45 * * * * /sbin/hwclock --hctosys

O wiele lepiej byłoby mieć wydarzenie dostępne u gościa, które zainicjowałoby synchronizację czasu po wznowieniu gościa, ale najwyraźniej nie jest ono dostępne. Metoda crontab stanowi obejście polegające na tym, że co 15 minut wykonuje wywołanie hwclock. Wykonuje pracę, ale nie tak elegancko, jak bym chciał.

kvm-clock synchronizuje czas gościa z czasem hosta podczas uruchamiania gościa . Powinieneś użyć klienta i ntp na gościu oraz zamknąć / uruchomić zamiast używać zawieszenia / wznowienia.

libvirt obsługuje synchronizację czasu gościa od 2015 roku . W Debian Stretch, a później poszukaj opcji SYNC_TIMEw /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

Możesz przetestować synchronizację czasu z poziomu systemu hosta za pomocą:

virsh qemu-agent-command INSERT_YOUR_DOMAIN_HERE '{"execute":"guest-set-time"}'

To polecenie powinno powrócić {"return":{}}po sukcesie.

Używam podobnego sposobu do synchronizacji czasu po zawieszeniu / wznowieniu VM, ale myślę, że lepiej jest zgadywać, że powinien on synchronizować we właściwym kierunku i jest dłuższy niż krótka różnica, którą można naprawić za pomocą NTPD.

https://gist.github.com/jhrcz/7138803

PS. Nowy dziennik zmian Centos 6.7 mówi, że można to zrobić automatycznie tylko przy użyciu źródła zegara kvm.