私のホストでは、libvirtとKVMゲストを使用しています。ホストがシャットダウンされると、libvirtはゲストを一時停止します。ホストが起動すると、libvirtはゲストを再開します。問題は、たとえばゲストが24時間後に一時停止および再開される場合、ゲスト時間は過去24時間であるということです。

おそらくクロックソースに問題があると思いますが、すでに「kvm-clock」に設定されています。

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

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

問題

私は同じ問題を抱えていますが、良い解決策は見つかりませんでした。私が見つけたものは次のとおりです。

問題は、再開後、ゲストのシステムとハードウェアのクロック時間が異なることです。

root @ guest：〜＃date; hwclock
2014年10月11日（土）13:09:38 UTC
2014年10月11日（土）13:10:42 -0.454380秒

ホストで、彼らは同意します：

root @ four：〜＃date; hwclock
2014年10月11日（土）13:11:35 UTC 2014
2014年10月11日（土）13:11:36 -1.000372秒

解決策はhwclock --hctosys、再開後にゲストで実行することです。ただし、ゲストが中断および再開されたことにゲストが気付かないため、ゲストシステムでの変更のみでこれを行う方法を見つけていません。

QEmuゲストエージェント

ゲストでQEmuゲストエージェントと呼ばれるソフトウェアを実行し、ホストからゲストハードウェアクロックからゲストシステムクロックを更新するように通知する可能性があります。ただし、ページには、ゲストエージェントが JSONパーサーの問題のためにホストとゲストを相互の攻撃に対して脆弱にしていると記載されています（少なくとも、影響を受けるコードはホスト上でも実行されると思いますが、それについてはわかりません）。とにかく、これを設定する方法は次のとおりです。

1. libvirt wikiで説明されているように、エージェントのvirtioシリアルチャネルをセットアップします（libvirtドメイン形式のドキュメントも参照）。

2. シリアルチャネルが使用可能になったら、ゲストにQEmuゲストエージェントをインストールして起動します。（Debian：。apt-get install --no-install-recommends qemu-guest-agent）

3. 中断、待機、再開することにより、クロックオフセットをトリガーします。次に、ホストで次のコマンドを実行して修正しvirsh qemu-agent-command backup '{"execute":"guest-set-time"}'ます。using virsh qemu-agent-commandがサポートされていない wikiページですが、ジョブを実行する他のコマンドが見つかりません。

libvirt内でguest-set-time、サスペンドからの再開時に呼び出しを自動化することに関する2つの議論を見つけました。

• http://thread.gmane.org/gmane.comp.emulators.libvirt/92431（2014年 2月）
• http://thread.gmane.org/gmane.comp.emulators.libvirt.user/7051（2014年 9月）

しかし、私が見る限り、まだ何も実装されていません。

stoney-cloud.orgのwikiでゲストエージェントにコマンドを送信する方法に関する情報を見つけました。

またtickpolicy="catchup"、libvirtタイマー構成の設定を試みましたが、これで問題は解決しませんでした。

NTP

エージェントを使用する代わりに、ntpデーモンを使用するか、cronジョブからntpdateを定期的に呼び出すこともできます。時間を遅らせるとプログラムが混乱する可能性があるため、後者はお勧めしません（たとえば、Dovecot IMAPサーバーは時間をさかのぼって処理しようとしないため、終了する可能性があります）。

次のntpデーモンを試しました。

• openntpd：私のテストでは、60分あたり約2秒の割合で非常にゆっくりと時間を修正しています。時間オフセットは120秒でした。また、時間オフセットが大きすぎる場合、openntpdはエラーをスローし、私のテストでは、その場合、時間の修正に完全に失敗します。openntpdの利点：chrootで通常のユーザーとして実行できます。

• chrony：テストの30分で120秒の時間オフセットを修正します。chronyは、通常のユーザーとして実行するように構成できます。chrootサポートは実装されていません。NTPサーバーのポーリング間隔は、NTPサーバーごとに構成できます。

• systemd-timesyncd：テストの30秒で120秒の時間オフセットを修正します。デフォルトで通常ユーザーとして実行されます。ただし、NTPサーバーのポーリング間隔は最大2048秒まで増加するため、最悪の場合、再開後34分までサスペンド/再開は検出されません。これは設定可能ではないようです。また、timesyncdが時間をさかのぼるステップを観察しました。これにより、cronでntpdateを呼び出すのと同じ問題が発生します（上記を参照）。

chronyは問題を解決します。Openntpdは、修正率が低すぎて構成できないため、適切ではありません。systemd-timesyncdは、ポーリング間隔を構成できないため、問題を完全には解決しません。

NTPデーモンの次のDebianバージョンをテストしました：openntpd 20080406p-10、chrony 1.30-1およびsystemd 215-5 + b1。

ゲストでの仮想化ホストの操作の多くは、一時停止（再開）になる可能性があります。これは、ゲストのシステムクロックに悪影響を及ぼします。たとえば、VMを複製すると、複製中に一時停止します。その後のゲスト時計は遅れています。NTPにクロックを同期させるには、ゲストを再起動する必要があります。これはすべての場合に適したソリューションではありません。別の方法として、ゲストでntpdを再起動することもできますが、これも最適ではありません。理想的には、ゲストへのこのタイプの修正にオプションで使用できるイベント（VM再開）が必要です。

これを調査するためにしばらく時間を費やした後、CentOS 7ゲストOSシステムクロックのリファレンスとしてホストクロックを直接使用することにしました。

ゲストでntpdを実行する代わりに、15分ごとに、crontabを使用して、ゲストのハードウェアクロックからゲストシステムクロックを設定することにしました。ゲストのハードウェアクロックは、仮想化ホストで実行されているntpdを介して制御される仮想化ホストでの時間を反映します。これにより、ゲストOSでの信頼できる時間が提供されます。最悪の場合、ゲストを再開してから適切な時刻に同期されるまで、最大15分間クロックがオフになることがあります。

# crontab -e

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

ゲストが再開されたときに時刻同期を開始するイベントをゲストで使用できるようにする方がはるかに良いでしょうが、明らかにそれは使用できません。crontabアプローチは、15分ごとにhwclock呼び出しを行うという回避策です。それは仕事をやり遂げますが、私が望むほどエレガントではありません。

kvm-clockは、ゲスト起動時にゲスト時間をホスト時間に同期します。ゲストでntpクライアントを使用し、suspend / resumeを使用する代わりにshutdown / startupを使用する必要があります。

libvirtは2015年以降、ゲスト時間の同期をサポートしています。Debian Stretchでは、後でオプションSYNC_TIMEを探します/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

以下を使用して、ホストシステム内から時刻同期をテストできます。

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

このコマンドは{"return":{}}成功すると返されるはずです。

VMのサスペンド/レジューム後の時間の同期には同様の方法を使用していますが、正しい方向に同期する必要があり、短い差よりも長く、NTPDで修正できると推測する方が良いと思います

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

PS。新しいCentOS 6.7の変更ログでは、これはkvm-clockクロックソースのみで自動的に実行できると書かれています。