なぜ時刻同期にvmwareツールを使用しないのですか？

（主に）Redhat 5.9および6.4ゲストの束を実行する2つのVMWare環境があります。時間のずれ（週あたり数分先）に問題があります。ローカルドメインコントローラーに同期するntpを使用します。

VMWareによるこの推奨事項は、時間同期にvmware-toolsを使用しないことを具体的に示しています。どうして？多くの人がNTPに問題を抱えているようで、vmware-toolsは一般に予測可能な方法で動作します。Redhatの以降のバージョンのvmware-toolsに特定の問題はありますか？

コンテキストでは、これはntp.confです（コメント行はすべて削除されています）。

tinker panic 0
restrict default kod nomodify notrap nopeer noquery
restrict -6 default kod nomodify notrap nopeer noquery
restrict 127.0.0.1
restrict -6 ::1
server our.domain.server.com
driftfile /var/lib/ntp/drift
keys /etc/ntp/keys

一部のお客様は、時間を守るのに全く問題はありません。他のものは大きな差で出ています。

正直なところ、仮想環境と最新のオペレーティングシステムでNTPに問題はないはずです... その問題の根本原因を見つける価値があります。

可能な場合は、適切なNTPインフラストラクチャ（通常は外部NTPソースを使用するか、すべてをコアスイッチまたはルーターに向けます）があり、ESXiホストのハードウェアクロックが時間内に設定されて閉じるなどの基本的なものがあることを確認します。場合によっては、ハードウェアクロックスキューのある別のホストへのvMotionが、仮想マシン内で発生している問題を引き起こす可能性があります。

ゲストツールのアプローチに関しては、少しハックです。ゲストツールを実行しないVM（サポートされていないOSまたはアプライアンスの状況）、またはゲストツールが最適でない状態にある場合（Linuxカーネルの更新後のVMwareツールなど）。

VMwareがツールの時刻同期を推奨しないのは、VMで2つの時刻同期方法が同時にアクティブになる状況を回避したいからだと思います。

ドメインに参加しているWindows VMはデフォルトでDCと同期し、Linux管理者は（仮想であるか物理であるかに関係なく）NTP用にマシンを構成します。VMwareツールを2番目の同期ソースとして追加すると、絶え間ない調整のような望ましくない効果が生じます。

VMWareによるこの推奨事項は、時間同期にvmware-toolsを使用しないことを具体的に示しています。どうして？多くの人がNTPに問題を抱えているようで、vmware-toolsは一般に予測可能な方法で動作します。

ほとんどの場合、VMwareと物理ホストまたは他の異種環境が混在しているという事実以外に、正式な理由は知りません。したがって、ホストとVMだけでなく、すべてが同期するように、NTPなどを推奨します。NTPのような標準を使用すると、どのタイプの環境でもOSとハードウェアプラットフォーム間で標準のタイムクロックを同期させることができます。