Time sync settings for windows server on Hyper-V (Updated)

一般に、仮想マシン上でのActive Directoryの実行が推奨されない理由として、時刻同期の問題がある。

が、同じプロジェクトで「仮想マシン上で時刻同期できないのでADは動かない」と言い切ったバカがいたので、理由と対処法を再度整理した。

（こういう浅はかな見識を大きな声でキャッチーに言うやつ、システム設計行程を混乱させるので害でしかない・・・ほんと詩んでほしい）

Hyper-Vの時刻同期機能

Hyper-V仮想環境で、仮想マシン統合サービスを導入すると、「時刻の同期」機能が利用できるようになる。
他の仮想化基盤でも、仮想ホストと仮想マシンの時刻同期を仕組みがある。

ゲスト時刻が遅れる場合

仮想マシンの設定で、統合サービスの「時刻の同期」を有効にすると、

ゲスト時刻　＜　5秒　＜　ホスト時刻

となったときに、5秒以上遅れたゲストの時刻を、ホストの時刻に修正する。

仮想マシンのタイマーをエミュレートしているCPUが高負荷になると、仮想マシン内でタイマーが遅れ、仮想マシンの時刻が遅れる（らしい）。

ゲスト時刻が進む場合

ゲスト時刻がホスト時刻を追い越した場合は、統合サービスによる時刻の同期は行われない。
（時刻同期機能に関するTechnet「Hyper-V 仮想化環境におけるゲスト OS の時刻同期について」より。実機検証はしていません）

• どうせOSの時刻同期機能を使うからと、ハードウェアクロックがいい加減だったり、
• 古い機器を転用して検証環境を作っていたりすると、システムボードのCMOSバッテリーが切れていたり

ホストのハードウェアクロックが遅れるが、エミュレートしている仮想マシンのクロックは遅れない・・・本当にそんなことが起こるのかわからないが。
ホストOSのw32timeのタイムプロバイダがハードウェアクロックを参照する場合は、統合サービスによる時刻同期が行われなくなる。

Active Directory環境で時刻がずれる影響

Kerberosによる統合Windows環境を実行する場合は、Active Directoryサーバと、クライアントの時刻の不一致は、Kerberos認証の不具合を引き起こす。
実際問題、本当に、ゲスト時刻が進む、なんてことが起こる可能性はとても低いと思う。
けれど、PDCエミュレータとの時刻不一致が起きてしまったら、その影響は甚大です。

対処法=Windows Timeによる外部NTPとの時刻同期の有効化

ハードウェアクロックに依存しない時刻同期構成となっていれば、問題は発生しない。
実際、時刻ずれによるKerberos認証の不具合が問題になるような「まともな環境」で、NTPホストが利用できないことはないでしょう。

1.ゲストのドメインコントローラ（PDCエミュレータ）の時刻同期の構成

• 統合サービスの「時刻の同期」を無効にする。
• 外部タイムソースを指定する。
• 自分を「信頼できるタイムソース」に設定する。

外部タイムソースを利用しない設定の場合は、Windows Time Serviceが停止している可能性があるので、スタートアップを「手動」に設定し、起動しておく。
以下の例では、OS標準の「time.windows.com」を、タイムソースに指定する。

sc.exe config w32time start= demand
sc.exe start w32time
w32tm.exe /config /manualpeerlist:time.windows.com /syncfromf
lags:manual /reliable:yes /update
w32tm.exe /resync

"start=" と "demand" の間にスペースが必要。トリッキーなので注意。

2.メンバーサーバの時刻同期の構成

• 統合サービスの「時刻の同期」を無効にする。
• ドメインに参加すれば、OSが勝手に、Active DirectoryのPDCエミュレータと時刻同期するようになる。