仮想マシンのクロックの変動を解決するにはどうすればよいですか?

https://stackoverflow.com/questions/117422

02-07-2019
|

質問

私の仮想マシンのクロックはかなり大きく変動します。これに対処するためのドキュメントは存在しますが、どれもあまりうまく機能していないようです。

誰かが何か提案やうまくいったことなどを持っています...

おそらく、ntp 経由で定期的に更新するのは良い解決策ではありません。

解決

基本的に、ホストはゲストに届けられるダニを可能な限り殺します。やめてください NTP を実行したり、時間制限を設定したり、そのようなジャンクを実行したりします。vmware-guestd をインストールして、ホストにティックを処理してもらうだけです。それでもティックが失われる場合は、他のソリューションでも大きな変動が生じる可能性があります。

可能であれば、周波数チックレートが低いゲスト OS を使用してください。Linux の新しいバージョンには 1000Hz ティックが搭載されていますが、以前は 100Hz のみでした。そのほうがホストにとっても配信しやすいようです。HZ 値を変更するには、通常、カーネルの再構築が必要です。

他のヒント

誰かの意見に耳を傾ける前に、vmware のドキュメントをよく読んでください。ESX5を実行しています。

Linux ゲスト向けの時間管理のベストプラクティスでは、次のように述べられています。参照: http://kb.vmware.com/selfservice/microsites/search.do? language=en_US&cmd=displayKC&externalId=1006427

NTPの推奨注目：VMware では、VMware Tools の定期的な時刻同期の代わりに NTP を使用することをお勧めします。NTP は業界標準であり、ゲストの正確な時刻を保証します。NTP トラフィックを許可するには、ファイアウォール (UDP 123) を開く必要がある場合があります。

これは /etc/ntp.conf のサンプルです。

tinker panic 0
restrict 127.0.0.1
restrict default kod nomodify notrap
server 0.vmware.pool.ntp.org
server 1.vmware.pool.ntp.org
server 2.vmware.pool.ntp.org
driftfile /var/lib/ntp/drift

これはサンプル (RedHat 固有) /etc/ntp/step-tickers です。

0.vmware.pool.ntp.org
1.vmware.pool.ntp.org

設定ディレクティブ tinker Panic 0 は、時間の大幅なジャンプが発生しても諦めないように NTP に指示します。これは、大きな時間のずれに対処したり、仮想マシンをサスペンド状態から再開したりするために重要です。

注記：ディレクティブ tinker Panic 0 は、ntp.conf ファイルの先頭になければなりません。

また、ローカルクロック (Undisciplined Local Clock とも呼ばれます) をタイムソースとして使用しないことも重要です。NTP は、時間のずれが大きい場合、リモートサーバーを優先してこれにフォールバックする傾向があります。

このような構成の例は次のとおりです。

server 127.127.1.0
fudge 127.127.1.0 stratum 10

両方の行をコメントアウトします。

NTP 構成を変更した後は、NTP デーモンを再起動する必要があります。オペレーティングシステムベンダーのドキュメントを参照してください。

NTPD が適切なソリューションではない理由についてのデータを追加します。NTPD は、ローカルクロックのドリフトを補正しようとするデーモンです。「内部クロック」が 1 日に X 秒ずれた場合、「ntpdate」のような強制コマンドのように先に進んだり戻ったりする代わりに、NTPD はクロックにいくつかのサイクルを追加または削除しようとします。 15 分以内であれば、時計は十分に正確に動作し、サーバーが 1 日に増減するこの X 秒数を補償が上回ります。これには、1 日のどの時間も繰り返されることがなくなるという利点があり、これはトランザクションシステムにとって必須です。

しかし、これを行うには、NTPD はローカルクロックが適切に機能することを必要とします。これは、通常、ローカルクロックが 1 日あたり 42 秒を超えて変動しないことを意味します (多かれ少なかれ、正確な数字は分かりません）。これは通常、仮想マシンの問題です。クロックはソフトウェアで制御されているため、ホストの過負荷が大きすぎると、クライアントのクロックの動作が遅くなることがわかり、そうでない場合はクロックも動作する可能性があります。速い。ここでの NTPD の問題は、ローカルクロックが信頼できず、時間の変動が一定ではないことです。ホストシステムの過負荷に応じて多少変わる可能性があります。

したがって、この場合は、提案されているようにクライアントツールをインストールし、クライアントの時計をホストの時計（通常は「壁時計」と呼ばれます）と同期させることをお勧めします。

いくつかの方法が存在し、それぞれに長所と短所があるため、決定的な答えはありません。どちらを選択するかは、タスク、サーバー負荷、オペレーティングシステムなどによって異なります。

読む vmware_timekeeper.pdf 問題を徹底的に理解するために。

Linux の簡単なレシピは別のセクションにあります。 KB 記事

仮想マシンの追加機能 (ツール) をインストールすると、ゲスト OS とホスト OS の間でクロックが同期されませんか?

おそらくNTP経由で定期的に更新することは良い解決策ではありません

ただし、それが私がお勧めする解決策です。あなたの場所ではなぜそれが良くないと考えられますか?

NTP をまだインストールしていない場合はインストールします。

ntpdate がクロックを正しく設定すると、ntpd はクロックを正確に保つことができます。

の NTPプールプロジェクトには、選択できる NTP サーバーの大規模なプールが用意されています。

編集 NTP は良い解決策ではないと考えているとおっしゃっていましたが、なぜですか?クロックの変化による影響が心配な場合は、NTP が最適です。ntpd はクロックを前後にジャンプさせるのではなく、クロックの速度をわずかに上げたり下げたりしてクロックを「スルー」し、クロックが一致するまで戻します。正しい時間。

私も同じ問題を抱えていましたが、それを解決しました

vmware-guestd のインストール
カーネルにオプション Clocksource=acpi_pm を送信します
root として hwclock -s を 1 時間ごとに実行します。

これは古い問題ですが、最近私たちに影響を及ぼした問題です。私が発見したのは、vmware ツールを実行している VM のいずれかがこの問題の影響を受けているということでした。

最近、open-vm-tools を使用し始めましたが、それらの VM ではオプションが設定されていませんでした。open-vm-tools は Vmware によって完全にサポートされ推奨されているため、vmware tools よりも open-vm-tools を使用することをお勧めします。 http://kb.vmware.com/selfservice/microsites/search.do? language=en_US&cmd=displayKC&externalId=2073803

open-vm-tools が使用するリポジトリ内にある場合は、次の方法で簡単にインストールすることもできます。 yum install または apt-get install 等

cmd を使用できます。

net time \\computer_name /set

リモートで (またはスクリプトなどで) 時計を設定するには

ライセンス： CC-BY-SA と帰属

所属していません StackOverflow