すべてのVMでNTPサーバーを実行する必要がありますか？

ゲストはどういうわけかホストのシステム時間を継承できませんでしたか？

同じデーモンを実行して同じマシンで同じ結果を複数回取得するのは無意味に思えますが、KVMまたはXenの記事を読むときに時間に関連するものは見つかりませんでした。私の理解では、ゲストは起動時にホスト時間を取得しますが、その後はばらばらになる可能性があります。あれは正しいですか？

virtualization ntp

— ジンバム
ソース

linux-kvm.org/page/KVMClock

— Hauke Laging

NTPクライアントを意味すると思いますか？

— マイケルハンプトン

@MichaelHampton：はい、NTPクライアントとサーバーの区別は、ntpパッケージが常に両方を提供するため、私には決して明確ではありませんでした。

— -zimbatm

この質問に関連して：Debianおよび派生物では、openntpパッケージはntpパッケージよりもはるかに軽量です。デフォルトではバインドしないため、ここで必要なのはまさにクライアントとして機能します。

— zimbatm

回答:

正解です。時間だけ離れて漂流「することができます」ではなく、ことに留意すべきだろう原因（多くの場合に基づいているOS上の計時）タイマ割り込みの間隔が伸びおよびハイパーバイザはフィットを参照してくださいと同じように圧縮されているという事実のために離れてドリフトします。

ほとんどの仮想化プラットフォーム（Hyper-V統合サービス、VMWareツール）で一般的に行われている回避策は、ゲストでデーモンを実行し、定期的にクロックをVMホストと同期します。質問へのコメントでHaukeが述べたように、KVMは、ゲストOSにロードされたそれぞれのドライバーが動作するために必要な準仮想化クロックをさらに提供します。

参考文献：

VMWare仮想マシンのタイムキーピング（vmware.com）
KVMゲストのクロック同期（s19n.net）

— ワビット
ソース

どうもありがとう。EC2の場合、Xenはクロックソースも提供しているようです：cat /sys/devices/system/clocksource/clocksource0/current_clocksource=> xen

— zimbatm

ホストとしてサーバー、VMをクライアントとしてkvm-clockを使用する場合でも、chronydをお勧めします。

— アコスタディノフ

完璧な世界では、VMゲストは完璧な時間を維持するか、少なくともホストが提供するのと同じくらい完璧です。残念ながら、私たちは完璧な世界に住んでいません。

人に知られているほぼすべてのハイパーバイザーでの経験に基づいて、例外なく、常に仮想マシンでNTPクライアントを実行しています。私の通常のセットアップは、-gオプションを指定したntpd、または古いシステムの直前に開始するntpdateで、クロックをステップします（システムのブート時に同期がとれなくなる可能性があります）。

KVMは準仮想化されたリアルタイムクロックを備えたほぼ完璧なセットアップを備えています。適切なドライバー（少なくとも最近のすべてのLinux）を持つゲストは、ホストと同様に時間を保持します。ただし、ここでも問題が発生します。たとえば、ホストでNTPが実行されていない、ホストのタイムゾーンが正しく設定されていない、ホストのクロックが単純に間違っているなどです。

VMwareとHyper-Vは中間に位置します。それぞれに、ホストでクロックを定期的に同期するゲストで実行されるツールがありますが、これもホストクロックの既存の問題に対して脆弱です。

私のテストHyper-Vサーバー上のゲストも奇妙な動作を示しました：統合サービスを使用しても、ゲストクロックは500ppmより速くドリフトし、ntpdが動作しなくなります（これよりも速くドリフトするとクロックの異常を考慮します）。これらのゲストをchronyに切り替える必要がありました。これにより、この値を調整できます。

この点でXenは最悪です。同期は絶対に行われず、ゲストでNTPを実行することはほとんど必要です。（Xenのごく最近のバージョンには何らかの同期がありますが、個人的にはまだ動作していません。）

パブリッククラウドなど、ホストハイパーバイザーが制御できない場合、事態はさらに悪化します。ホストクロックに関してプロバイダーの容赦があり、同期を維持することに熱心でなければ、負けになります。

それだけで、準正確なクロックが必要な場合は、仮想マシンでNTPクライアントを実行することが非常に必要です。注意：Windows仮想マシンを実行している場合は、クロックを継続的に調整するサードパーティのNTPクライアントを入手してください。Windowsに付属しているクライアントの貧弱な言い訳は、週に一度だけ時計を調整するだけで、これはまったくばかげています。

— マイケル・ハンプトン
ソース

ntpdate毎日のcronジョブで実行されていますか、それともntpデーモンである必要がありますか？

— AngerClown

クロックを連続的に同期するために何かが本当に必要です。それは問題を引き起こすために1日で十分に同期しなくなる可能性があるからです。また、一部のプログラムでは、クロックがステップするのを嫌います。

— マイケルハンプトン

ntpデーモンの問題は、主に他の人に時間を提供することを意図しているため、時間のずれが大きすぎると機能しなくなることです。継続的に実行され、ポートをバインドしないntpdateのようなものがあればいいのにと思います。

— -zimbatm

@JonasPfenniger ntpdがうまく機能しない場合は、代わりにchronyを使用してみてください（上記を参照）。仮想マシンで見られる奇妙なシナリオに対応するために、ntpdよりもかなり調整できます。

— マイケルハンプトン

あなたが言ったことの95％には同意しますが、NTPを使用するWindowsクライアントは週に1回のクロック変更に限定されないことを指摘したかっただけです。次のregキーを使用すると、更新間隔を効果的に定義できます：HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Config\UpdateInterval値は秒単位で定義され、通常360000（100時間）に設定されますが、アプリケーションが特に時間に敏感な場合は15分ごとに同期するように900に設定できます。その後、忘れずにW32Timeサービスを再起動してください。

— ケイジェイ

NTPはよく知られており、長い間使用されてきたため、NTPを使用することをお勧めします。クロックの調整は簡単ではありません。NTPはこの問題を解決しました。

VMwareの公式ラインでは、1つのメカニズムを使用しますが、NTPの方がよりきめ細かく、時間を調整するための手順が小さいため、NTPが優先されます。VMwareの内部ソリューションはより大きなステップを踏みます。両方を実行すると、お互いに戦うことができます。VMwareの内部ソリューションは大きな一歩を踏み出し、NTPで調整して少し元に戻しました。

ただし、実際には両方を同時に実行しますが、まだ問題は発生していません。

$ ntpq   
ntpq> peers
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
something.org  172.2.1.5          2 u   57   64  377    1.597   -2.409   5.952


$  vmware-toolbox-cmd  timesync status
Enabled


$ vmware-toolbox-cmd help timesync
timesync: functions for controlling time synchronization on the guest OS
Usage: vmware-toolbox-cmd timesync <subcommand>

Subcommands:
  enable: enable time synchronization
  disable: disable time synchronization
  status: print the time synchronization status

— jris198944
ソース