第4回 運用に役立つHyper-Vライブ・マイグレーションのノウハウ：Hyper-V 2.0実践ライブ・マイグレーション術（2/5 ページ）
ライブ・マイグレーションの運用フェイズで役立つノウハウを解説。実用的なPowerShellスクリプトなども紹介する。
サーバ仮想化は、重要度の小さいシステムからテストを兼ねて始めていくケースが多い。「スモール・スタート」や「フェイズド・アプローチ」と呼ばれる段階的なシステム導入手法だ。多くの場合、導入後半年〜1年の様子を見て「より重要なシステムまで仮想化を広げても問題ないか？」を検討する。問題ないと判断できれば、機材を追加購入して第2フェイズに進んでいくだろう。つまり、第2フェイズの構築時期は、第1フェイズから半年〜1年以上経過することになる。
このような流れでサーバ・マシンを追加増強する場合、重大な問題が1つある。増強しようとしても、ライブ・マイグレーションの要件である「同一ベンダかつ同一世代のプロセッサ」が販売終了で購入できないことがあるのだ。サーバ向けプロセッサはIntel／AMDともに約1年のペースでラインアップが一新される。既存システムで利用しているプロセッサは、後継製品に置き換えられてしまうのが普通だ。
新しくリリースされるプロセッサの強化点として毎回挙げられる中に「拡張命令」というものがある。特定の処理を高速化するために、各社が独自に追加している命令セットのことだ。SSEや3DNow!などクライアントPCでも多く利用されているため、ご存じの方も多いだろう。Hyper-Vの要件であるIntel VTやAMD-Vも拡張命令の一種だ。ここ1年で実装されたIntel EPTやAMD RVIのように、新しいプロセッサがリリースされるたびに両社が競うように新たな拡張命令を追加し続けている。
■拡張命令の互換性チェックとガード機能
では、この拡張命令を意識しながら、ライブ・マイグレーションの動作を考えてみよう。
（1） 最新プロセッサを搭載したホスト上で仮想マシンがアプリケーションを実行している。アプリケーションは自身の処理を高速化するために、最新の拡張命令「SSE4.2」を利用したとする。
（2） ライブ・マイグレーション（またはクイック・マイグレーション）を実行。仮想マシンはアプリケーションを実行したまま別のホストへ移動する。
（3） 仮想マシンの移動が完了。アプリケーションはホストの移動に気付かないため、当然ながらSSE4.2をそのまま利用し続けようとする。しかし、移動先ホストは1年前に購入したサーバ・マシンであり、プロセッサがSSE4.2に対応していない。
（4） アプリケーションやOSのクラッシュなど、深刻なエラーが発生する。
プロセッサの拡張命令とライブ・マイグレーション
世代の異なるプロセッサ間でライブ・マイグレーションを実行すると、拡張命令の有無による致命的なエラーが引き起こされることがある。このため、Hyper-V 2.0では移動前に双方のプロセッサに対して拡張命令の互換性をチェックするようになった。
このように、世代の異なるプロセッサ間では、拡張命令の非互換によってライブ・マイグレーションで致命的なエラーを誘発することがある。プロセッサの製造ベンダが異なる場合も、ほとんどの拡張命令が非互換であるため同様だ。
この致命的な問題は、Hyper-V 1.0時代のクイック・マイグレーションで実際に発生していた（「Hyper-V実践サーバ統合術 第4回 Hyper-Vによるクイック・マイグレーションの実践」−コラム「異なるプロセッサ間でクイック・マイグレーションするとどうなるか？」参照のこと）。こういった深刻なエラーを防ぐために、Hyper-V 2.0では実行前に移動元と移動先プロセッサの拡張命令の互換性をチェックし、非互換の場合は実行をキャンセルするガード機能が搭載されている。
拡張命令が非互換の場合のガード機能
Hyper-V 2.0は、互換性チェックとガード機能により、拡張命令の非互換による深刻なエラーを回避するように改善されている。上の画像はライブ・マイグレーション実行時、下の画像はクイック・マイグレーション実行時に実際にガードされた画面だ。
■拡張命令の互換性を確認する方法
互換性チェックの話を聞いてしまうと「このプロセッサは、どのプロセッサと拡張命令が一致するだろうか？」と疑問がわいてくる。評価・テスト環境やサーバ・マシンを追加増強するといったケースでは、同一型番のプロセッサを用意できないことも多い。もちろん、ライブ・マイグレーションの環境を構築して実際に試してみれば確実であるが、共有ストレージなども必要となるため、大掛かりになってしまう。
（1）GetCompatibility.vbs
共有ストレージを用意できなくても、サーバ・マシンだけで、互換性チェックを行えるツールが公開されているので紹介しよう。
- R2: Script release for Hyper-V host compatibility checks for VM quick / live migrations（Ravikanth Chaganti’s Web Blog）
このVBSスクリプトは、互換性をチェックしたいHyper-Vホストのコンピュータ名を指定するだけで、実際に互換性チェックで使用されているAPIにアクセスし、結果を出力してくれる非常に便利なツールである。
コマンド・プロンプト上で次のように実行してみよう。
cscript //nologo GetCompatibility.vbs /SRCHOST:＜移動元ホスト名＞】 /DESTHOST:＜移動先ホスト名＞ /VM:＜仮想マシン名＞
共有ストレージのない環境で実際と同じチェックが行える「GetCompatibility.vbs」
拡張命令が一致している場合は（1）のようなメッセージが出力される。
これに対し、拡張命令が一致しない場合は（2）のようなメッセージが出力される。XML形式で出力されているが、これは実際のAPIに直接アクセスしてチェックしているためだ。
なお、2010年3月現在、このスクリプトには一部不具合がある。上記のようにエラー・メッセージを正しく出力させるためには、テキスト・エディタで開き26行目の最後に「, reason」と文字を付け加えよう。
GetCompatibility.vbsでエラー・メッセージを正しく出力できるようにする
テキスト・エディタで26行目の最後に「, reason」と文字を付け加えよう。
（1）ここに、「,reason」と加える。
（2）プロセッサのモデルナンバーから予測を立てる
サーバ・マシンの手配前など、実機を用意することができない場合は、プロセッサのモデルナンバーからある程度予測することも可能だ。Intel／AMDともにサーバ向けプロセッサのモデルナンバーは次のように4けたの数字となっており、このうち先頭から2けた目の数字が世代を示している。
Intel／AMDの各プロセッサ内で、この2けた目が同じ数字であれば、拡張命令に互換性があると予測を立てることができる（2010年3月現在の命名規則の場合）。なお、2けた目が同じであってもIntelプロセッサとAMDプロセッサには互換性はない。
もし、これらのチェックで非互換と判明しても、まだあきらめないでほしい。次ページで説明する「プロセッサ互換性モード」で救済できるかもしれない。
Copyright© Digital Advantage Corp. All Rights Reserved.