NTP再起動後は常に時間が正しくありません。NTPセットアップでもESXと同期します
インストールしたNTPと内部NTPサーバーピアはストラタム2です。ただし、サーバーを再起動するたびに、VM時間はESXホストと同期され、6時間進んでいます。
Ntpdate -s x.x.x.xを実行し、修正しました。それにもかかわらず、再起動後、再び6時間先に進みます。
NTP=処理しないのはなぜですか？ntpを有効にしており、起動時に起動しますが、時間は常にESX時間です。Ubuntu16.04を使用しています。
また、timedatectlはNTPを表示しませんが、systemd.timesyncd 表示されています。 systemd.timesyncdが無効になり、VMで停止します。
root@Host001:~# timedatectl
Local time: Fri 2020-05-08 16:00:59 UTC
Universal time: Fri 2020-05-08 16:00:59 UTC
RTC time: Fri 2020-05-08 08:57:03
Time zone: UTC (UTC, +0000)
System clock synchronized: no
systemd-timesyncd.service active: no
RTC in local TZ: no
VMWare独自のホワイトペーパーでは、Linux NTPインストールでVMサーバーを実行することを推奨していますが、デフォルトでは、VM時間はハイパーバイザー/ホストが存在する時間。
ハイパーバイザーの時間と実際の時間に差がある場合、ブート時にまたはntpdデーモンが実行されていない場合、時間差が発生します影響を受けるハイパーバイザーでホストされているVM内。
vSphereドキュメントセンター-ゲストとホストのオペレーティングシステム間の時間同期の構成 VMWareの説明デフォルト動作：
時間同期が発生した後、VMware Toolsは1分ごとにチェックして、ゲストとホストのオペレーティングシステムのクロックがまだ一致しているかどうかを判断します。そうでない場合、ゲストオペレーティングシステムのクロックは、ホストのクロックと一致するように同期されます。
ゲストオペレーティングシステムのクロックがホストのクロックより遅れている場合、VMware Toolsはゲストのクロックを進めてホストのクロックと一致させます。ゲストオペレーティングシステムのクロックがホストのクロックよりも進んでいる場合、VMware Toolsにより、クロックが同期されるまでゲストのクロックの実行が遅くなります。
VMware Toolsの定期的な時刻同期をオンにするかどうかに関係なく、特定の操作の後に時刻同期が発生します。
VMware Toolsデーモンが起動したとき（再起動中または電源オン操作中など）
サスペンド操作から仮想マシンを再開するとき
スナップショットに戻した後
ディスクを圧縮した後
リアルタイム、ハイパーバイザー時間、およびVMの時間の間にそのような違いがある場合、いくつかのアクションを実行する必要があります。
- 時間の修正、タイムゾーン/ VMwareホスト/ハイパーバイザーでのNTPの有効化。
- vMのVMWare側/ vmxファイルで無効化、VM/Linuxとハイパーバイザー間の同期。
ハイパーバイザーにアクセスできない、VMとハイパーバイザーの同期を無効にする、VM/Linux側で、起動時にvmtoolsを使用して競合しないようにする- 常時、NTP時間を設定/ドリフトするVMデーモンを使用：
vmware-toolbox-cmd timesync disableホスト/ハイパーバイザーの時刻を修正できない場合は、timesync disableを実行する必要がありますであり、これらの差が大きい場合はさらに困難になります。
再度引用 vSphereドキュメントセンター-ゲストとホストのオペレーティングシステム間の時間同期の構成
ネットワークタイムプロトコル（NTP）などのネイティブの時刻同期ソフトウェアは、通常、VMware Toolsの定期的な時刻同期よりも正確であるため、推奨されます。ゲストでは、定期的な時刻同期の1つの形式のみを使用してください。ネイティブの時刻同期ソフトウェアを使用している場合は、VMware Toolsの定期的な時刻同期をオフにします。
NTP側のVMサービスについては、時間差が大きすぎる場合はntpdが中止され、無視するように指示された場合は非常にゆっくりと同期されます。それ。
ブート/ NTPサービスの開始時に、時刻の変更が即時かつ自動的に行われるように、ntp.confの最初の行として追加します。
tinker panic 0
以下も参照してください。
VMWare KB-時間同期の無効化（1189） 、ホストとVMの間の時間同期を完全に無効にする。
同期が30分を超えると11分のモードtinker panic 0の詳細な説明
アデンダ
それでも、もう一度説明しますが、学際的なチームで作業している場合は、ホスト側の時間の概念を修正し、VMWareチームの注意を引くことを強くお勧めします。
1つのハイパーバイザーをオフタイムにすると、そのVMWareホストによって生成されるログのタイムスタンプとVM /ハウスキーピングファイルの作成/変更時間に影響します。
ハイパーバイザの時刻が間違っていることの影響は、特に次の場合はさらに複雑になります。
- vMWareファイルが存在するストレージスペースは、複数のVMWareホストによって共有されます。
- ログは中央のsyslogサーバーに送信されています。
- 複数のVMWareホストが同じvCenterで管理されている。
バックグラウンド
ほとんどのコンピューターでは、ブート時に次のことを行います。
- 時間は、RTC（コンピューターがオフのときにバッテリーで動作していた）から読み取られます。
- 前回コンピュータをシャットダウンしたときにファイルに保存された内容によっては、調整が追加される場合があります。
- それは新しい「ハードウェアの時間」であり、コンピュータの時間です。
- しばらくの間、クライアント（sntp、ntpdate、ntpd、chronydなど）、またはハードウェアクロック（GPS）がその時間を更新して、より適切な推定を行います。
何らかの理由でRTCバッテリーが故障した場合、起動時の時刻が大幅にずれている可能性があります。
回答
仮想コンピュータでは、RTCは実際のRTCではなく仮想RTCであり、ホストコンピュータの時間から読み取られます。ホストの時間がオフの場合、VMの起動時間も大幅にオフになります。RTCバッテリーが不良になった場合と同じです。
これが発生する理由です（VMからコピーしたもの）。
root@Host001:~# timedatectl
Local time: Fri 2020-05-08 16:00:59 UTC
Universal time: Fri 2020-05-08 16:00:59 UTC
RTC time: Fri 2020-05-08 08:57:03
Time zone: UTC (UTC, +0000)
System clock synchronized: no
systemd-timesyncd.service active: no
RTC in local TZ: no
RTC時間は、実際の、ローカル、またはUTCとは異なります。
解決
ホストの時刻が正しいことを確認してください。そこでntpまたはGPSを使用します。
たとえば、Qemuのmanページから：
-rtc [base = utc | localtime | datetime] [、clock = Host | rt | vm] [、driftfix = none | slew]
デフォルトでは、RTCはホストシステム時間によって駆動されます。これにより、特にホスト時間がある場合、RTCをゲスト内の正確な基準クロックとして使用できます。 NTPなどを介して、正確な外部基準クロックをスムーズに追跡します。