Ev sahibimde libvirt ve KVM konuğu kullanıyorum. Ev sahibi kapanırken libvirt konuğu askıya alır. Ev sahibi çalışmaya başladığında libvirt konuyu devam ettirir. Sorun, örneğin konuk 24 saat sonra ertelenir ve devam ettirilirse, o zaman konuk saatinin 24 saat geçmiş olmasıdır.

Belki sorunun saat kaynağı ile ilgili olduğunu düşündüm, ama zaten "kvm-saat" olarak ayarlanmış.

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

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

Sorun

Aynı sorunu yaşadım ve iyi bir çözüm bulamadım. İşte bulduğum:

Sorun, özgeçmişten sonra, konuktaki sistem ve donanım saat sürelerinin farklı olmasıdır.

root @ guest: ~ # tarih; hwclock
Cmt 11 Eki 13:09:38 UTC 2014
Cts 11 Eki 13:10:42 2014 -0.454380 saniye

Ev sahibinde aşağıdakileri kabul ediyorlar:

dördüncü kök: ~ # tarih; hwclock
Cmt 11 Eki 13:11:35 UTC 2014
Cts 11 Eki 13:11:36 2014 -1.000372 saniye

Çözüm, hwclock --hctosysdevam ettirildikten sonra konuk üzerinde çalışmak olacaktır . Ancak, misafirin askıya alındığını ve devam ettirildiğini fark etmediği için bunu yalnızca konuk sistemindeki değişikliklerle yapmanın bir yolunu bulamadım.

QEmu Misafir Acentesi

Konukta QEmu Guest Agent adlı bir yazılımı çalıştırma ve konuk donanım saatinden konuk sistem saatini güncellemek için ana bilgisayardan bildirim alma olasılığı vardır . Ancak, sayfa bir JSON ayrıştırıcısı ile ilgili sorunlar nedeniyle konuk ajan ana bilgisayar ve konuk birbirlerinden saldırılara karşı savunmasız yaptığını belirtmektedir (en azından etkilenen kodun ana bilgisayarda da çalıştığına inanıyorum, bundan emin değilim) ). Her neyse, bunu nasıl ayarlayacağınız aşağıda açıklanmıştır:

1. Libvirt wiki'de belirtildiği gibi aracı için bir virtio seri kanalı oluşturun (ayrıca bkz. Libvirt alan formatı belgeleri ).

2. Seri kanal kullanılabilir hale geldikten sonra, konuğa QEmu Konuk Aracısını kurun ve başlatın. (Debian:. apt-get install --no-install-recommends qemu-guest-agent)

3. Askıya alarak, bekleyerek ve devam ettirerek saat ofsetini tetikleyin. : Sonra düzeltmek için ana bilgisayarda aşağıdaki komutu çalıştırın virsh qemu-agent-command backup '{"execute":"guest-set-time"}'kullanarak o wiki sayfasını virsh qemu-agent-commandolan desteksiz ama iş yok başka komutu bulamadım.

Libvirt'te guest-set-timeaskıya alma işleminden devam etme çağrısını otomatikleştirme hakkında iki tartışma buldum :

• http://thread.gmane.org/gmane.comp.emulators.libvirt/92431 (Şubat 2014)
• http://thread.gmane.org/gmane.comp.emulators.libvirt.user/7051 (Eylül 2014)

Ancak, görebildiğim kadarıyla hiçbir şey uygulanmadı.

Stoney-cloud.org'un wiki'sinde konuk aracıya komutların nasıl gönderileceği hakkında bilgi buldum .

Ayrıca ayarı denedim tickpolicy="catchup"içinde libvirt zamanlayıcı yapılandırması ama bu sorunu çözmedi.

NTP

Aracıyı kullanmanın bir alternatifi, bir ntp arka plan programı kullanmak veya ntpdate'i periyodik olarak bir cron işinden çağırmak olacaktır. İkincisini tavsiye etmem, çünkü zamanın geriye gitmesine neden olabilir, bu da programları karıştırabilir (örneğin, Dovecot IMAP sunucusu geriye doğru gitmeye çalışmaz ve sonlanabilir).

Aşağıdaki ntp artalanlarını denedim:

• openntpd : Testimdeki zamanı 60 dakikada yaklaşık 2 saniyede çok yavaş düzeltir. Zaman farkı 120 saniyeydi. Ayrıca, zaman ofseti çok büyükse ve testimde bu durumda zamanı düzeltmek için başarısız olursa , openntpd bir hata atar . Openntpd'nin avantajları: Krootta normal kullanıcı olarak çalışabilir.

• chrony : Testimde 30 dakikada 120 saniyelik bir zaman farkını düzeltir. chrony normal kullanıcı olarak çalışacak şekilde yapılandırılabilir. chroot desteği uygulanmadı. NTP sunucusu yoklama aralığı her NTP sunucusu için yapılandırılabilir.

• systemd-timesyncd : Testimde 30 saniyede 120 saniyelik bir zaman ofsetini düzeltir. Varsayılan olarak normal kullanıcı olarak çalışır. Ancak, NTP sunucularının yoklama aralığı 2048 saniyeye kadar artar, böylece en kötü durumda devam ettirildikten sonra 34 dakikaya kadar bir askıya alma / devam etme algılanmaz. Bu yapılandırılabilir gibi görünmüyor. Ayrıca, timeyncd adımı geriye doğru geriye doğru izledim, bu da bir cronda ntpdate çağırma ile aynı sorunlara neden oluyor (yukarıya bakınız).

chrony problemi çözer. Openntpd uygun değil çünkü düzeltme oranı çok düşük ve yapılandırılabilir görünmüyor. yoklama aralığı yapılandırılamadığından, systemd-timesyncd de sorunu tamamen çözmez.

NTP cinlerinin Debian'ın şu versiyonlarını test ettim: openntpd 20080406p-10, kronik 1.30-1 ve systemd 215-5 + b1.

Konuk üzerindeki birçok sanallaştırma ana bilgisayarı işlemi duraklatma - devam ettirmeye neden olabilir. Bu, konuktaki sistem saatini olumsuz etkileyecektir. Örneğin, bir VM'nin klonlanması, klonlama sırasında duraklamaya neden olur. Daha sonra misafir saati geride kaldı. NTP'nin saati senkronize etmesini sağlamak için konuğu yeniden başlatmanız gerekir - her durumda iyi bir çözüm değil. Alternatif olarak ntpd'yi konuk olarak yeniden başlatabilirsiniz, ancak bu da uygun değildir. İdeal olarak, konuk için bu tür bir düzeltme için isteğe bağlı olarak kullanabileceğiniz bir olay (VM devam ettirildi) olmalıdır.

Bunu araştırmak için biraz zaman geçirdikten sonra, ana saati doğrudan CentOS 7 konuk işletim sistemi sistemi saati için referans olarak kullanmaya karar verdim.

Konukta ntpd çalıştırmak yerine, her 15 dakikada bir, crontab aracılığıyla, konukların donanım saatinden konuk sistem saatini ayarlayacağımı kararlaştırdım. Konuk donanım saati, sanallaştırma ana bilgisayarında çalışan ntpd aracılığıyla kontrol edilen sanallaştırma ana bilgisayarındaki zamanı yansıtır. Bu bana konuk işletim sisteminde güvenilir zaman sağlar. En kötü durumda, saat, konuk devam ettirildikten sonra uygun zamana senkronize edilmeden önce 15 dakikaya kadar kapalı olabilir.

# crontab -e

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

Konuk yeniden başlatıldığında zaman senkronizasyonunu başlatacak bir etkinliğin konukta hazır olması çok daha iyi olur, ancak görünüşe göre bu mevcut değildir. Crontab yaklaşımı, her 15 dakikada bir hwclock çağrısı yapması nedeniyle bir çözümdür. İşi yapar, ama istediğim kadar zarif değil.

kvm-clock konuk zamanını konuk başlangıcındaki zamana ev sahipliği yapmak için senkronize eder . Konukta ve ntp istemcisini, askıya alma / devam ettirme yerine kapatma / başlatma kullanmalısınız.

libvirt, 2015 yılından bu yana konuk saati senkronizasyonunu desteklemektedir . Debian Çekerek seçenek için daha sonraki bir görünüm üzerinde SYNC_TIMEde /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

Zaman senkronizasyonunu ana bilgisayar sisteminden aşağıdakilerle test edebilirsiniz:

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

Bu komut {"return":{}}başarıya dönmelidir .

VM askıya alma / devam ettirmeden sonra zaman senkronizasyonu için benzer bir yol kullanıyorum, ancak doğru yönde senkronize edilmesi gerektiğini ve kısa farktan daha uzun olduğunu tahmin etmenin daha iyi olduğunu düşünüyorum, bu NTPD tarafından düzeltilebilir.

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

PS. Yeni centos 6.7 changelog, bunun sadece kvm-saat saat kaynağı ile otomatik olarak yapılabileceğini söylüyor.