今後のERPアップグレードプロジェクト
では、2台の新しいサーバーが必要でした。仮想化戦略に着手し、既にIBMホストマシンを所有していたため、
仮想マシン（VM）として構築することが明確な選択肢でした。物理マシンから仮想マシン（P2V）への変換ではなく、ゼロから構築することになります
。
これまで気づかなかった2つの落とし穴に陥り
、自尊心のあるITプロフェッショナルなら誰もが恥じるようなミスを犯してしまいました。この記事は、ステップバイステップのハウツーというよりは、教訓的な物語です。
アクティベーション失敗
VMの1つは
データベースサーバーになる予定だったので、他のITプロフェッショナルが仮想環境でのSQL Serverの使用を推奨しているという記事を読んで安心しました。さらに、私のIBM
ホストサーバーはWindows Server 2008 R2 Enterpriseで稼働しており、
最大4台のゲストVM用のWindowsライセンスが含まれているため、オペレーティングシステム（OS）の
ライセンスを購入する必要がないことが分かりました。IBMサーバーには、
ホストサーバー用とVMで使用する「仮想キー」の2つのWindowsライセンスキーが提供されていました。
Hyper-V マネージャーでは、新規仮想マシンウィザードを実行するだけで、VM を一から作成できます。必要なメモリを割り当て、
ネットワークに接続せずに VM を作成することを選択し、仮想ハードディスク
(.VHD) ファイルの場所を指定した後、DVD から OS をインストールすることを選択しました (図 A )。
図A
OSインストールオプション
データベースアプリケーションには
Windows Server 2008 R2が必要だったので、そのOSが動作している別のサーバーのOS DVDを入手し
、そこからインストールしました。Windowsのアクティベーションを要求された際に
仮想ライセンスキーを入力しましたが、拒否されました。
調べてみたところ、仮想キーは
ゲストVMでWindows Server 2008 R2 Enterpriseが動作している場合にのみ機能するためだとのことでしたが、これは明らかに不自然な結果でした。
ため息をつきながらIBM
Windows DVDに交換し、セットアッププロセスを再開しました。今回はエンタープライズ
オプションを選択しました。既にWindowsのコピーがインストールされていたので（
ライセンスキーを受け付けなかった方です）、既存の
ファイルをWindows.Oldというフォルダに移動し、後で削除するつもりでいました。ところが、この「インプレース」インストールはエラーで失敗し、
ディスクパーティションをフォーマットして最初からやり直す必要がありました。ようやくインストールが完了し、
アクティベーションプロセスで仮想キーが受け入れられました。
パスワードエラー
セットアッププロセスを続け、選択した管理者パスワードでログインし、
Hyper-V統合サービスのアップグレード
手順に従いました。再起動が必要になり、その後、
再度管理者としてログインしようとしましたが、パスワードがうまく入力できませんでした。
信じられない思いでメモしておいたパスワードを見つめ、何度か試し、さらにいくつかのバリエーションを試してみました。こんな間違いを犯してしまったなんて信じられませんでした
。これまで何度かパスワードを正しく入力できたことはありましたが、
明らかにメモしておいたパスワードではありませんでした。
この厄介な穴から抜け出す、それほど劇的ではない方法があります
。パスワードリセットディスクです。しかし、私はまだ作っていませんでした。普段は絶対に作らないので。絶対に必要になることはないだろう
、少なくともそう思っていました。そこで残されたのは、OSを再インストールするという劇的な解決策だけでした。再インストールの際には、セキュリティは変わりませんが、誤入力の可能性ははるかに低い管理者パスワードを選択しました。
パスワード
リセット ディスクはまだ作成していません。もちろん、必要になることはないからです。
もう一枚ディスクをお願いします
新しいVMは、
C:ドライブとして機能する単一の.VHDファイルで作成されました。両方のVMに追加のドライブが必要でした。
そのためには、まずVMをシャットダウンする必要があります。VMの「設定」ダイアログで
IDEコントローラーを選択すると、新しいハードドライブを追加するオプションが表示されます。
ドライブの作成はウィザード形式で、ディスクの種類、サイズ、場所などを選択できます。SQL
Serverのパフォーマンスを最大限に引き出すため、動的に拡張するのではなく、固定サイズのディスクを使用することにしました。「完了」をクリックすると、ウィザードによって新しい
.VHDファイルが作成されます。
そして、
250GBのドライブで少なくとも20分は待たされます。それだけでなく、
別の仮想サーバー上のアプリケーションが応答しないという苦情も届くようになりました。
どうやら原因は、固定サイズの.VHDを作成する際に、Hyper-Vが新しい.VHDで使用するディスクのすべての部分を明示的にゼロクリアしてしまうことにあるようです。これは
セキュリティ上の理由です。（注：今日、MSDNブログへのリンクを試したところ、見たことのないサインアップ/ログインページが表示されました
。リンクにアクセスするには、まずそのダイアログをキャンセルしてから再試行する必要がありました。）
私の推測では、このゼロ化
処理は大量のディスクI/Oを必要とし、
同じホスト上の他のVMに影響を与えているのではないかと思いました。予想通り、ディスクの作成が完了すると、
アプリケーションは正常に動作し始めました。
ユーザーに謝罪し、
追加したい
他のディスクについても、この遅くてリソースを大量に消費するプロセスを回避できないかと考えました。MSDNの記事には
、ディスクの該当領域を事前に消去せずに上書きすることで、この遅い作成を回避するMicrosoftツールを紹介するフォローアップ記事へのリンクがありました。
私のホストマシンのディスクにはデータがほとんど入っていなかったので、そのツールを使っても安全だったでしょう
。しかし最終的には、通常の方法を続けることにしましたが、
今回は同僚たちに連鎖的な影響について事前に警告しておくことにしました。
私も (そして彼らも)ディスクが作成されるのを辛抱強く待ち、ついに新しい VM の準備が整いました。
まとめ
2つの新しいHyper-V VMを作成したところ、
Windows Server 2008 R2 Enterpriseに付属する「仮想ライセンスキー」は、
ゲストVMでもWindows Server 2008 R2
Enterpriseが動作している場合にのみ機能することがわかりました。また、VMに固定サイズのハードディスクを追加すると、
処理速度が遅く、リソースを大量に消費し、同じ
ホスト上の他のVMに影響を与える可能性があることもわかりました。
セットアップ中に
管理者パスワードを忘れてしまい、OSのインストールをやり直さなければなりませんでした。
誰か、私だけが
こんな罠に陥ったわけではないと教えてください。
