Masalah
Saya punya masalah yang sama dan saya belum menemukan solusi yang baik. Inilah yang saya temukan:
Masalahnya adalah bahwa setelah melanjutkan, waktu jam sistem dan perangkat keras pada tamu berbeda:
root @ guest: ~ # date; jam
Sabtu 11 Oktober 13:09:38 UTC 2014
Sabtu 11 Oktober 13:10:42 2014 -0.454380 detik
Di tuan rumah, mereka setuju:
root @ four: ~ # date; jam
Sabtu 11 Oktober 13:11:35 UTC 2014
Sabtu 11 Oktober 13:11:36 2014 -1.000372 detik
Solusinya adalah menjalankan hwclock --hctosys
pada tamu setelah itu dilanjutkan. Namun, saya belum menemukan cara untuk melakukan ini dengan perubahan pada sistem tamu saja, karena tamu tidak menyadari bahwa itu ditangguhkan dan dilanjutkan.
Agen Tamu QEmu
Ada kemungkinan untuk menjalankan perangkat lunak yang disebut QEmu Guest Agent pada tamu dan memberi tahu dari tuan rumah untuk memperbarui jam sistem tamu dari jam perangkat keras tamu. Namun, halaman tersebut menyebutkan bahwa agen tamu membuat tuan rumah dan tamu rentan terhadap serangan satu sama lain karena masalah dengan parser JSON (setidaknya saya percaya bahwa kode yang terpengaruh juga berjalan di host, saya tidak yakin tentang itu ). Bagaimanapun, inilah cara mengaturnya:
Siapkan saluran serial virtio untuk agen sebagaimana disebutkan dalam wiki libvirt (lihat juga dokumentasi format domain libvirt ).
Setelah saluran serial tersedia, instal dan mulai Agen Tamu QEmu pada tamu. (Debian:. apt-get install --no-install-recommends qemu-guest-agent
)
Memicu jam diimbangi dengan menangguhkan, menunggu, dan melanjutkan. Kemudian jalankan perintah berikut pada host untuk memperbaikinya: virsh qemu-agent-command backup '{"execute":"guest-set-time"}'
The wiki halaman yang menggunakan virsh qemu-agent-command
adalah tidak didukung , tapi saya belum menemukan perintah lain yang melakukan pekerjaan.
Saya menemukan dua diskusi tentang mengotomatisasi dalam libvirt panggilan untuk guest-set-time
melanjutkan dari penundaan:
Namun, sejauh ini belum ada yang dilaksanakan.
Saya menemukan informasi tentang cara mengirimkan perintah ke agen tamu di wiki dari stoney-cloud.org .
Saya juga sudah mencoba pengaturan tickpolicy="catchup"
dalam pengaturan waktu libvirt tetapi ini tidak menyelesaikan masalah.
NTP
Alternatif untuk menggunakan agen adalah dengan menggunakan daemon ntp atau untuk memanggil ntpdate secara berkala dari pekerjaan cron. Saya tidak akan merekomendasikan yang terakhir, karena dapat menyebabkan waktu untuk mundur, yang dapat membingungkan program (misalnya, server IMAP Dovecot tidak mencoba untuk menangani waktu mundur dan dapat mengakhiri).
Saya mencoba daemon ntp berikut:
openntpd : Mengoreksi waktu dengan sangat lambat dengan laju sekitar 2 detik per 60 menit dalam pengujian saya. Offset waktu adalah 120 detik. Juga, openntpd melempar kesalahan jika waktu offset terlalu besar dan, dalam pengujian saya, gagal untuk memperbaiki waktu dalam kasus itu. Keuntungan dari openntpd: Dapat dijalankan sebagai pengguna biasa di chroot.
Chrony : Mengoreksi waktu offset 120 detik dalam 30 menit dalam pengujian saya. Kronik dapat dikonfigurasi untuk dijalankan sebagai pengguna biasa. dukungan chroot tidak diterapkan. Interval polling server NTP dapat dikonfigurasi untuk setiap server NTP.
systemd-timesyncd : Mengoreksi offset waktu 120 detik dalam 30 detik dalam pengujian saya. Berjalan sebagai pengguna biasa secara default. Namun, interval polling server NTP meningkat hingga 2048 detik, sehingga penangguhan / resume tidak akan terdeteksi hingga 34 menit setelah resume dalam kasus terburuk. Ini sepertinya tidak dapat dikonfigurasi. Juga, saya telah mengamati timesyncd langkah mundur waktu, yang menyebabkan masalah yang sama seperti memanggil ntpdate dalam cron (lihat di atas).
Chrony memecahkan masalah. Openntpd tidak cocok karena tingkat koreksinya terlalu rendah dan tampaknya tidak dapat dikonfigurasi. systemd-timesyncd tidak sepenuhnya menyelesaikan masalah, karena interval pollingnya tidak dapat dikonfigurasi.
Saya menguji versi Debian dari daemon NTP: openntpd 20080406p-10, chrony 1.30-1 dan systemd 215-5 + b1.