Hyper-VマシンはNTPを使用しても時間をドリフトします

解決済み 問題はそのマシンのHyper-Vでした。Hyper-Vを削除し、VMware Serverをインストールして、同じVMを実行しました。時間同期の問題は解消されました（1日後に100ミリ秒未満の差）。

私の設定は次のとおりです：

HYV1 - HyperV machine (non domain) - sync irrelevant
AD1  - VM AD server on HYV1, sync'd to time.nist.gov. HyperV time sync off.
S1   - Physical machine, sync'd to domain. 
S2   - Physical machine running HyperV, sync'd to domain.
V1   - Linux VM machine on S2, sync'd to AD1. No HyperV integration.

AD1とS1には細かい同期があります-ストリップチャートは100ms未満の差を示します。

S2は狂ったようにドリフトします。AD1に対するストリップチャートの一部を以下に示します。

18:33:22 d:+00.0010138s o:+05.4101899s 
18:33:24 d:+00.0010138s o:+05.4319765s 
18:33:26 d:+00.0000000s o:+05.4788429s 
18:33:28 d:+00.0000000s o:+05.6089942s 
18:33:30 d:+00.0010138s o:+05.7240269s 
18:33:32 d:+00.0000000s o:+06.0421911s 
18:33:34 d:+00.0081104s o:+06.5613708s 
18:33:37 d:+00.0000000s o:+06.9096594s 
18:33:39 d:+00.0000000s o:+06.8867838s 
18:33:41 d:+00.0010127s o:+06.8936401s 

20秒で、1秒以上ドリフトしました。手動で1秒以内にリセットすると、数分以内に約2秒戻ります。一晩で2秒から5秒になりました。S2内のLinux VMはAD1と完全に同期しています。

これが設定です：

C:\Users\mgg>w32tm /dumpreg /subkey:Parameters

Value Name                 Value Type          Value Data
------------------------------------------------------------

ServiceDll                 REG_EXPAND_SZ       %systemroot%\system32\w32time.dll
ServiceMain                REG_SZ              SvchostEntry_W32Time
ServiceDllUnloadOnStop     REG_DWORD           1
Type                       REG_SZ              NT5DS
NtpServer                  REG_SZ              ad01.mydomain ad02.mydomain


C:\Users\mgg>w32tm /dumpreg /subkey:Config

Value Name                Value Type          Value Data
-----------------------------------------------------------

FrequencyCorrectRate      REG_DWORD           4
PollAdjustFactor          REG_DWORD           5
LargePhaseOffset          REG_DWORD           50000000
SpikeWatchPeriod          REG_DWORD           900
LocalClockDispersion      REG_DWORD           9
HoldPeriod                REG_DWORD           5
PhaseCorrectRate          REG_DWORD           1
UpdateInterval            REG_DWORD           30000
EventLogFlags             REG_DWORD           2
AnnounceFlags             REG_DWORD           5
TimeJumpAuditOffset       REG_DWORD           28800
MinPollInterval           REG_DWORD           2
MaxPollInterval           REG_DWORD           8
MaxNegPhaseCorrection     REG_DWORD           -1
MaxPosPhaseCorrection     REG_DWORD           -1
MaxAllowedPhaseOffset     REG_DWORD           300

イベントログを確認したところ、同期に関する警告（同期が外れた後）を除いて、他の警告はありません。

これをトラブルシューティングするにはどうすればよいですか？この問題が発生している唯一のマシンです。他のすべてのマシン（物理および仮想）は正常に動作しています。

編集：明確にするために：VM（AD1）は統合がオフになっており、time.nist.govと同期しています。AD1で結構です。AD1に同期できない物理マシンS1であり、すべてがドリフトしています。他のすべての物理サーバーは、AD1に問題なく同期できます。

更新 そのため、VMの実行に問題があるようです。VMをオフにすると、クロックがゆっくりとずれます。オンにすると、すぐに秒の損失が始まります。半分のリソースのみを使用するようにVMを切り替えましたが、今のところそれは少し軽減されているようです。ありがとう！

説明から、サーバーS2のマザーボード上のRTC（http://en.wikipedia.org/wiki/Real-time_clock）に実際のハードウェアの問題があるようです。

Hyper-Vゲストは、最初はホスト（HYV1）からクロックを取得しますが、Hyper-Vの時刻同期を無効にしているため、NIST（これは正常に機能しています）からさらにすべてのクロック更新を取得します。Linux VMはHyper-Vと統合されていないため、ドメインから時間を取得していますが、これも正常に機能しています。他の物理マシンは正常に動作しています。これは、20秒ごとに1秒のドリフトがある1つの物理サーバーです（これは、非常に大きなドリフトです）。時間は、ネットワーク時間同期がクロックを正しい時間にリセットできるよりもはるかに速くドリフトしています（私が正しく思い出せば、8時間ごとに行われます）。

S2のエラーの原因としてHyper-Vを除外する場合は、「ハイパーバイザなし」のブートエントリを作成し、Hyper-Vなしで再起動して、時間のずれが続くかどうかを確認します。ここでの手順：http : //blogs.msdn.com/virtual_pc_guy/archive/2008/04/14/creating-a-no-hypervisor-boot-entry.aspx

-ショーン

問題は、さまざまなクロックソース（tsc、jiffies、acpi_pm、cmos_trc）の仮想実装にあります。HyperVでこの問題を修正するために私が見つけた最良の方法は、ゲストマシンのHyperV提供のクロック同期をオフにし、次にadjtimexを使用して時間を調整することです。UbuntuゲストOSでは次のようにします...

# rm /var/log/clocks.log
# /etc/init.d/ntp-server stop
# ntpdate ntp.ubuntu.com
# hwclock -u --systohc
# adjtimex -l -u -h ntp.ubuntu.com

両方の質問に「いいえ」と答えます

# while [ /bin/true ] ; do yes | adjtimex -l -u -h ntp.ubuntu.com ; sleep 60 ; done

キャリブレーションのために数時間実行するには、そのままにしておき、Ctrl-Cを押して終了します。

# adjtimex -r -a -u -h ntp.ubuntu.com

これはあなたの時計の最小二乗分析を行い、適切な調整を見つけるでしょう

# ntpdate ntp.ubuntu.com
# hwclock -u --systohc
# /etc/init.d/ntp-server start

これにより、マシンの時刻が再同期され、ntpはあまりドリフトしないため、同期を保つことができます。

これは、VMの非常に一般的な問題のようです。次のWebサイトを参照してください。

http://www.vmwareinfo.com/2008/04/enabling-ntp-on-esx-servers.html

http://social.technet.microsoft.com/Forums/en-US/winserverhyperv/thread/6fff3eef-1b5b-4059-8618-22ab3f5c293c

私の提案は、外部のタイムサーバーとのみ同期し、統合時間の同期を無効にすることです

うまくいけば、これが役立ちます。

コアでHyper-vをしばらく実行しています。最初は時間同期の問題がありました.....私は古いWindows NT時代からベストプラクティスに戻しました。

サーバーはOSごとに表示されます。Linux、ルーター、Windows、Novellマスターを作成します。

あなたはノベルを持っていないかもしれませんが、私と一緒に我慢してください。

各「マスター」サーバーはルーターと同期します。ストラタムへのルーター。次に、各メンバーサーバーには、マスターOSサーバーと、他のマスターのいずれかのセカンダリがあります。

• Linuxからルーター、次にNovell
• Novellからルーターへ、次にWindowsへ
• Windowsからルーターへ、次にLinuxへ
• ルータをStratum、次にコアスイッチに
• Stratum、次にルーターへのコアスイッチ

この戦略の最後の部分は...すべてにタイムサーバーがあります。タイムサーバーがない場合は、ネットワークに接続されません。トースターから電話のPBX、サーバーに切り替えます。

これは、新しい仕事にたどり着いたときに最初に行うことの1つは、ネットワークをマップして時間を設定する時間を費やすことです。その後、あちこちで確認するだけで、その時点から問題として時間同期を排除できます。

VM内のあらゆる場所で時間がドリフトします。ローカルクロックの信頼性が低すぎるため、NTPサーバーが 'server'ステートメントでローカルクロックを使用していないことを確認する必要があります。私が支援するためにやったことの1つは、VMedマシン上のサーバーに「maxpoll」属性を設定することです。これにより、ntpサービスは、設定されたデフォルトよりもはるかに頻繁にアップストリームクロックをチェックするように強制されるため、trueを維持できます。

server [timeserver] maxpoll 12

いくつかの設定を試して、比較的信頼できる時間を保つために必要な距離を確認してください。12でうまくいきますが、環境はそれぞれ異なります。

面白そうに聞こえるかもしれませんが、マルチプロセッサセットアップを実行しているのではないでしょうか。 特定のメーカーと知られているクロック・ドリフトの問題があり 、咳 AMDの咳マルチコア/マルチソケットのマザーボードで起こります。たとえば、1つまたは2つの仮想マシンを実行するなど、割り込みアクティビティが多いと、ドリフトが悪化します。あなたが経験しているドリフトは、このように非常に疑わしく聞こえます。

価値があるので、私はIntelよりもAMDの製品を好むので、これをそれらのノックとして受け取らないでください。

AD1がドメインコントローラーであると仮定すると、ここでの問題は、Hyper-Vサーバーが独自のゲストVMの1つから時間を設定していることに関連している可能性があります。これが、VMwareに切り替えたときに問題が解消された理由です。VMwareサーバーは、クロックをWindowsドメインコントローラーと同期させる必要がありません。