Windows仮想マシン(VMware)の時刻管理のベスト プラクティス（NTP 含む）

VMwareを使用した仮想マシンのWindows Serverに対する時刻同期はどうするのがベストなのでしょうか？

昔のバージョンのVMwareでは、CPUの使い方がよくなかったのか時刻同期がうまく行かずVMware Toolsで時刻同期するのがベストでしたが、最近は違っているようです。

 

VMware仮想マシンに対する時刻同期の必要性

Windows ゲスト OS で正確な時刻管理を実現するには、2 つの重要な考慮事項があります。

時刻同期を正しく構成することと、過度の CPU とメモリのオーバーコミットメントを回避することです。

時刻同期ユーティリティは、ハードウェア時刻のずれとゲスト OS の時刻管理の不正確さによる時刻のずれを修正するために必要です。

過度のオーバーコミットメントは、時刻同期ユーティリティでは修復不可能なペースで時刻のずれを発生させる原因となる可能性があります。

 

VMware社による仮想マシン時刻同期の推奨は、Windows標準ユーティリティ

プライマリの時刻同期ユーティリティとして、 w32time または NTP を使用します。

w32time は Windows に付属の時刻同期ユーティリティです。

NTP （Network Time Protocol デーモン） は、Windows 向けに提供されているさまざまな種類のサード パーティ製ポートを使用することで Windows で利用できます。

ゲストで w32time または NTP を使用する場合は、 VMware Tools の定期的な時刻同期を無効にします。

仮想マシンのVMware ESXサービスコンソールにネットワーク接続できない

仮想マシンでVMware ESX Serverを構築した場合、仮想マシンESXサービスコンソールにネットワーク接続が出来ない。

これは、VMware ESX ServerがデフォルトではプロミスキャスモードOFF(拒否)の設定であるためです。

 

環境：

VMware ESX 4.x 上の仮想マシンとしてVMware ESX Server 3.xを構築したとき

 

解決策

VMware ESX 4.x上で、仮想マシンESX3.xが接続されているポートグループ(仮想スイッチ)のプロミスキャスモードを許可してください。

 

参考： プロミスキャスモードとは

再起動後リモートデスクトップ接続が遅い (ローカルエリア接続が遅い)

VMware ESX 3.5 上で動作する仮想マシンWindows Server 2008で次のような現象が起きた。

仮想マシンのOS再起動後、リモートデスクトップ接続がなかなか出来ない・・・接続できるのに20分程度かかる

 

環境

VMware ESX 3.5 (vCenter 2.5)上仮想マシン

Windows Server 2008 SP2

 

仮想マシンを構築した当初はこんな現象はなかったので、アプリケーションとの競合が考えられた。

 

現象

再起動後、仮想マシンのデスクトップ画面を見ていると以下のような状況であることがわかった。

マイクロソフトライセンス：サーバーファームとは？仮想環境冗長化分のSQL Serverライセンスは必要？

いろんな噂があります、仮想環境でのサーバーライセンスの必要数を求めるのは難しいです。

 

今回、調べた対象は、「SQL Server 2008 R2 Standard Edition」ライセンスについて。

仮想環境で冗長化されている環境(HA)にある、SQL Server 2008 R2 Standard Edition の仮想マシン一台に対し、冗長化された分のライセンスが必要かどうかです。

 

よく、言われるライセンスルール：

ライセンスは物理サーバーに割り当てられ、最後に割り当てた日から 90 日が経過する前にライセンスの再割り当てを行うことはできません。

と、90日間の再割り当てルールの撤回されたライセンスルール：

1 つのサーバー ファーム内のサーバー間で、必要な頻度でライセンスの再割り当てを行うことができます。
この変更により、1 つのサーバー ファーム内のサーバー間で、ライセンスおよび実行するインスタンスの両方を自由に移動できます。

上の例では、ソフトウェアを 2 台のサーバーで同時に実行していない限りライセンスを再割り当て可能で、両方のサーバーにライセンスを同時に割り当てる必要がありません。

どういうことでしょうか？

 

具体的にいうと、VMware vSphere4 環境で、vCenterを冗長化されたVMwareハードウェア環境(例えばESXサーバー2台)上に仮想マシンとして配置した場合、

「SQL Server 2008 R2 Standard Edition」ライセンスは仮想環境の冗長化された分が必要なのでしょうか？

 

結論から言いますと、

VMware仮想マシン、PCI「標準PCI-toPCI ブリッジ」の繰り返しインストール要求

VMware vSphere4の仮想マシンで、PCI「標準PCI-to-PCI ブリッジ」が繰り返し検出される問題にぶつかった。
「新しいハードウェアの検出ウィザード」が何回も表示され、ループ？とも思われる違いのわからない「PCI-toPCIブリッジ」デバイスとドライバの検出。
簡単に言って、検出は正常で35回ほど繰り返しドライバファイルをインストールすることによって解決する。
忍耐と信じる心が大切だと感じさせられた出来事でした。

現象：

VMware ESX Server 3.5 上の仮想マシン(仮想マシンバージョン4)を、VMware ESX Serevr 4.1(VMware vSphere4)上の仮想マシン(仮想マシンバージョン7)へ「仮想ハードウェアのアップグレード」を行ったタイミングで「標準PCI-toPCI ブリッジの繰り返しインストール要求」の問題にぶつかった。

対象仮想マシンのOS（仮想OS）：
Windows 2000 Server SP4
(しかし、全てのWindows 2000 Server SP4というわけではなかった)

対応：

35回くらい同じように見える「標準 PCI-to-PCI ブリッジ」デバイスドライバをインストールすることにより解決

考察：