私のホストでは、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:〜#日付; hwclock 2014年10月11日13:09:38 UTC 2014 2014年10月11日13:10:42 2014 -0.454380秒
ホスト上で、彼らは同意します:
root @ four:〜#日付; hwclock 2014年10月11日13:11:35 UTC 2014 2014年10月11日13:11:36 2014 -1.000372秒
解決策は、ゲストが再開された後、ゲストでhwclock --hctosys
を実行することです。ただし、ゲストが一時停止および再開されたことにゲストが気付かないため、ゲストシステムの変更のみでこれを行う方法は見つかりませんでした。
ゲストで QEmu Guest Agent と呼ばれるソフトウェアを実行し、ホストから通知して、ゲストのハードウェアクロックからゲストのシステムクロックを更新する可能性があります。ただし、ページでは、ゲストエージェントが、JSONパーサーの問題のために、ホストとゲストが相互に攻撃に対して脆弱になると述べています(少なくとも、影響を受けるコードもホスト上で実行します、それについてはわかりません)。とにかく、これを設定する方法は次のとおりです。
libvirt wiki で説明されているように、エージェントのvirtioシリアルチャネルをセットアップします( libvirtドメイン形式のドキュメント も参照)。
シリアルチャネルが利用可能になったら、ゲストにQEmu Guest Agentをインストールして起動します。 (Debian:apt-get install --no-install-recommends qemu-guest-agent
。)
一時停止、待機、再開して、クロックオフセットをトリガーします。次に、ホストで次のコマンドを実行して修正します。virsh qemu-agent-command backup '{"execute":"guest-set-time"}'
virsh qemu-agent-command
を使用しているWikiページはunsupportedですが、他には見つかりませんでした仕事をするコマンド。
サスペンドからの再開時にguest-set-time
の呼び出しをlibvirt内で自動化することに関する2つの議論が見つかりました:
しかし、私が見る限り、まだ何も実装されていません。
wiki of stoney-cloud.org でゲストエージェントにコマンドを送信する方法に関する情報を見つけました。
libvirtタイマー設定 でtickpolicy="catchup"
を設定してみましたが、これで問題が解決しませんでした。
エージェントを使用する代わりに、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は、ポーリング間隔を設定できないため、問題を完全には解決しません。
次のDebianバージョンのNTPデーモン:openntpd 20080406p-10、chrony 1.30-1およびsystemd 215-5 + b1をテストしました。
ゲストでの仮想化ホストの操作の多くは、一時停止(再開)を引き起こす可能性があります。これは、ゲストのシステムクロックに悪影響を及ぼします。たとえば、VMを複製すると、複製中に一時停止が発生します。その後、ゲストクロックが遅れます。NTPを取得するには、クロックを同期するために、再起動する必要があります。ゲスト-すべてのケースで確かに良い解決策ではありません。代わりに、ゲストでntpdを再起動することもできますが、それも最適ではありません。理想的には、このためにオプションで使用できるイベント(VMが再開された)が必要ですゲストへの修正のタイプ。
これを調査した後、ホストクロックをCentOS 7ゲストOSシステムクロックのリファレンスとして直接使用することにしました。
ゲストでntpdを実行する代わりに、ゲストのハードウェアクロックからゲストシステムクロックをcrontab経由で15分ごとに設定することにしました。ゲストのハードウェアクロックは、仮想化ホストで実行されているntpdを介して制御される仮想化ホストでの時間を反映します。これにより、ゲストOSで信頼できる時間を確保できます。最悪の場合、ゲストが再開した後、適切な時刻に同期される前に、時計が最大15分間オフになることがあります。
# crontab -e
0,15,30,45 * * * * /sbin/hwclock --hctosys
ゲストが再開されたときに時刻の同期を開始するイベントをゲストで利用できるようにした方がはるかに優れていますが、明らかにそれは利用できません。 crontabアプローチは、15分ごとにhwclock呼び出しを行うという点での回避策です。それは仕事を成し遂げるが、私が望むほどエレガントではありません。
kvm-clockはゲスト時間をゲストのホスト時間に同期しますstartup。ゲストではntpクライアントを使用し、サスペンド/レジュームではなくシャットダウン/スタートアップを使用する必要があります。
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/71388
PS。新しいcentos 6.7の変更ログでは、これはkvm-clockクロックソースのみで自動的に実行できると述べています。