システム時刻は、過去のイベントで4時間にリセットされ続けます。タイムゾーンが正しく、時刻が同期されていると考えられます。
ESX環境で実行されているWindows2008サーバー（32ビット）があります。
時刻をタイムサーバー（time.Microsoft.com、tick.gatech.edu、またはその他のタイムサーバー）に手動で同期でき、時刻が適切に設定され、システムトレイクロックに表示されます。また、タイムゾーンを東部標準時に正しく設定しています-DST用に調整されています。
この時点ですべてが良好に見えます。
ただし、システムを再起動すると、システムクロックは4時間早く設定されます。 （つまり、4：00 PMシステムではリアルタイムは12:00 PMになります）。
次に、時間を強制的に再同期するか、手動で時間を正しい時間に設定する必要があります。分は影響を受けませんが、時刻は正確に4時間前に設定されます。
これは私を狂わせています、そして私はこれに対する解決策を探しています。残念ながら、このサーバーのいくつかの重要なタスクは時間に敏感であり、これが実際の問題を引き起こしています。
VMtoolsがESXサーバーにクロックを同期するように設定されていないことを再確認しました。
助けてくれてありがとう。
@ ScottWarren-あなたは正しいです。それは長期的な解決策です。ただし、そもそもなぜこれが発生したのかを十分に説明し、他のユーザーがなぜ発生したのかを理解できるようにしたいと思いました。
覚えておいてください-in VMクライアント内のツールクライアントはシステム時刻をESXホストと同期しないように選択しましたが、これはまだ発生していました。
この理由は VMWareのKB 1189 で説明されています。
基本的に、a VMがESXホストへのゲスト同期を行わないという要求を無視する場合が2回あります。
- 仮想マシンを一時停止すると、次にその仮想マシンを再開するときに、ホストに合わせて調整する時間が同期されます。
- VMotionを使用して仮想マシンを移行する、チェックポイントを取得する、チェックポイントに復元する、仮想ディスクを縮小する、または仮想マシンのツールサービスを再起動すると（、仮想マシンの再起動を含む）、時間が再同期されます）。
これが、このシステムが再起動するたびに時間をリセットする理由です。そもそもVMwareがこれを起こさないというユーザーの要求を無視するのは不思議ですが、今ではそれがどのように、そしてなぜ起こったのかを完全に理解しています。
この場合、環境にESXi 4.1が新しくインストールされたため、時差が見られました。新しいサーバーにはNTP設定がなかったため、クライアントに誤った時刻情報を提供していました。
先週、正確な問題が発生しました。 ESX Hostの時間が本当に重要であることが判明しました。これは、サーバーがリセットされたときにサーバーが開始する時間であるためです（Microsoftのパッチの再起動後に確認しました）。本当に疑わしかったのは、再起動後も同じタイムスケールにリセットされ続けたことです。あなたの場合は今-4時間、私たちの場合は今-42日です。 ESX Hostの時間がまっすぐになると、それは停止し、通常のWindowstime-syncはそれを時間どおりに保つことができました。
私も数日前にまったく同じ問題を抱えていました。要するに、ESXの時刻が正しい必要があるか、BIOS（ESXホストによって提示される）が再起動のたびに誤った時刻を表示し、Windowsの時刻が乱れるということです。時間デルタが大きすぎると、w32tmは同期に失敗します。
最善の策は、ESXホストの時間を修正することですが、それができない場合は、いつでも最大位相修正（ MS KB記事 ）をより大きな数値に変更できます（デフォルトは5のみです）。分）これにより、現在の条件下で同期できるようになります...ただし、これを高い数値に設定すると、ここで潜在的な悪影響があります（-===-）（例については、kbの記事のメモを読んでください）