NTP がインストールされ、内部 NTP サーバーのピアがレイヤ 2 です。ただし、サーバーを再起動するたびに、仮想マシンの時間はESXホストと同期してから6時間ずつ高速になります。
私はntpdate -s xxxxを実行し、それが修正されました。しかし、再起動後、時間は6時間早くなりました。
なぜNTPはそれを処理しないのですか? ntpを有効にして起動時に起動しますが、時間は常にESX時間です。 Ubuntu 16.04を使用しています。
また、timedatectl
NTPは表示されませんが、systemd.timesyncd
表示されます。systemd.timesyncd
仮想マシンで無効になって停止しました。
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
答え1
VMWare独自のホワイトペーパーでは、Linux VMインストールでNTPサーバーを実行することをお勧めしますが、基本的に、VM時間は、VMがホストされているハイパーバイザー/ホストの時刻と同期されます。
ハイパーバイザー時間と実際の時間に差がある場合またはntpdデーモンが実行されていないと、影響を受けるハイパーバイザーでホストされている仮想マシンにタイミングの違いが発生します。
vSphere ドキュメントセンター - ゲストオペレーティングシステムとホストオペレーティングシステム間の時間同期の設定説明VMware基本アクション:
時刻同期が発生した後、VMware Tools はゲストオペレーティングシステムとホストオペレーティングシステムのクロックがまだ一致していることを確認するために毎分確認します。それ以外の場合、ゲストオペレーティングシステムのクロックはホストのクロックと一致するように同期されます。
ゲスト OS のクロックがホストのクロックより遅い場合、VMware Tools はホストのクロックと一致するようにゲストのクロックを前方に移動します。ゲストオペレーティングシステムのクロックがホストのクロックよりも速い場合、VMware Toolsはクロックが同期されるまでゲストのクロックが遅く実行されるようにします。
VMware Tools の定期的な時刻同期がオンになっているかどうかに関係なく、特定の操作の後に時刻同期が発生します。
VMware Toolsデーモンが起動したとき(再起動または電源投入時など)
中断されたジョブで仮想マシンを再開する場合
スナップショットに戻った後
ディスクを縮小した後
リアルタイム、ハイパーバイザー時間、VM時間の間にこれらの違いが発生した場合に実行する必要があるいくつかのタスクがあります。
- 時間、タイムゾーンを変更し、VMwareホスト/ハイパーバイザーでNTPを有効にします。
- VM/Linux と VM の VMWare 側/vmx ファイルにあるハイパーバイザー間の同期を無効にします。
VM/Linux 側でハイパーバイザーにアクセスできません。起動時に仮想マシンとハイパーバイザーの同期を無効にし、仮想マシンツール、競争しないからいつも、NTPデーモンを使用してVM時間を設定/ドリフトします。
vmware-toolbox-cmd timesync disable
ホスト/ハイパーバイザー時間を変更できない場合は、時刻同期を無効にする必要があります。、これらの違いが大きいほど、状況はより緊急になります。
再引用vSphere ドキュメントセンター - ゲストオペレーティングシステムとホストオペレーティングシステム間の時間同期の設定
デフォルトの時刻同期ソフトウェア(NTP(Network Time Protocolなど)など)は、通常VMware Toolsの定期的な時刻同期よりも正確なため、優先されます。ゲストでは、1つの形式の定期的な時間同期のみを使用してください。デフォルトの時刻同期ソフトウェアを使用している場合は、VMware Toolsの定期的な時刻同期をオフにしてください。
VM側NTPサービスの場合、エンテフード時間差が大きすぎる場合は中断し、無視するように指示された場合は非常に遅く同期します。
ブート/NTP サービスを開始する場合は、すぐに自動的に時刻を変更するには、ntp.conf の最初の行に次を追加します。
tinker panic 0
また見なさい:
VMWare KB - 時間同期を無効にする(1189)、ホストと仮想マシン間の時間同期を完全に無効にするために使用されます。。
30分以上同期しない場合は11分モード詳細な説明tinker panic 0
アデンダ
それにもかかわらず、複数の分野のチームと再び協力する場合は、ホスト側の時間概念を修正し、VMWareチームの注意を喚起することをお勧めします。
ハイパーバイザーのシャットダウン時間は、そのVMWareホストで生成されたログタイムスタンプとVM /ハウスキーピングファイルの作成/変更時間に影響します。
ハイパーバイザーのタイミングエラーの影響は、特に次の状況でより複雑になる可能性があります。
- VMWareファイルが配置されているストレージスペースは、複数のVMWareホストで共有されます。
- ログは中央のsyslogサーバーに送信されます。
- 同じ vCenter で複数の VMWare ホストを管理します。
答え2
背景
ほとんどのコンピュータで起動時:
- 時間はRTCから読み取られます(RTCはコンピュータの電源が切れているときは常にバッテリーに電力を供給されます)。
- コンピュータが最後にシャットダウンされたときに、ファイルに保存されている内容に基づいていくつかの調整が追加されることがあります。
- これはコンピュータの時間である新しい「ハードウェア時間」です。
- ある時点まで、クライアント(sntp、ntpdate、ntpd、chronydなど)またはハードウェアクロック(GPS)はより良い見積もりで時間を更新します。
何らかの理由でRTCバッテリーに障害が発生した場合、開始時間が正確な時間と大きく異なる可能性があります。
回答
仮想マシンでは、RTCは実際のRTCではなく仮想RTCであり、時間はホスト時間に基づいて読み込まれます。ホスト時間がオフの場合、仮想マシンの起動時間も大幅に増加します。 RTCバッテリー不良のようです。
これがまさにこれが起こる理由です(仮想マシンからコピーしたもの)。
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のマニュアルページから:
-rtc [base=utc|localtime|datetime][,clock=host|rt|vm][,driftfix=none|slew]
デフォルトでは、RTCはホストシステムの時間に応じて駆動されます。これにより、RTC をゲスト内部の正確な基準クロックとして使用できます。特に、ホスト時間が正確な外部基準クロック(NTP経由など)にスムーズに従う場合は、はい。