第4回　運用に役立つHyper-Vライブ・マイグレーションのノウハウ：Hyper-V 2.0実践ライブ・マイグレーション術（3/5 ページ）

　前述のとおり、Hyper-V 2.0で搭載された互換性チェック＆ガード機能により、プロセッサの拡張命令が非互換の場合はライブ・マイグレーションを実行できない。しかし、これでは先ほど紹介した「1〜2年後にサーバ・マシンを追加増強する」といった、今後起こり得るシナリオを満たすことができなくなってしまう。Hyper-V 2.0は、こういったケースに備えて「プロセッサ互換性モード」という救済機能が新しく追加されている。

■プロセッサ互換性モード

　プロセッサ互換性モードを簡単に説明すると、移動元と移動先のプロセッサが非互換の場合でも、同一ベンダであれば互換性チェックをパスさせ、ライブ・マイグレーションを実行できるようする機能だ。救済機能といえるが、実はこの機能はアプリケーションの性能を劣化させる副作用も備えている。利用する前に仕組みと効果をきちんと理解しておこう。

プロセッサ互換性モード
プロセッサ互換性モードを利用すると、Hyper-Vの要件を満たす同一ベンダのプロセッサであれば拡張命令が一致しなくてもライブ・マイグレーションを利用できるようになる。仮想マシン単位に設定できるところも魅力だ。
　 （1）ここのチェックを入れると、プロセッサのバージョンが異なっていても、ライブ・マイグレーションが実行できるようになる。

　プロセッサ互換性モードを有効にすると、仮想マシンが利用可能な拡張命令をハイパーバイザが一部マスクする。これがプロセッサ互換性モードの仕組みだ。下表に掲載された拡張命令が仮想マシン上でマスクされて利用できなくなる。

　これらの拡張命令のうち、「AMD 3DNow!」と「Extended AMD 3DNow!」以外は、ここ3年以内に新しく搭載された命令だ。つまり、これらの命令がマスクされるというのは、使用できる拡張命令が約3年前のプロセッサ相当にデグレードされるということである。IntelプロセッサはNetBurstマイクロアーキテクチャの末期、AMDプロセッサはRev.Fあたりになるだろう。

　なお、3年前相当にデグレードされるといっても、クロック周波数やFSB（フロントサイドバス）など、拡張命令以外の部分についてはそのままなので安心してほしい。また、AMDプロセッサは加えて「AMD 3DNow!」「Extended AMD 3DNow!」も無効となるが、現在これらの命令はほとんど使われていないため、影響は少ないと思われる。

　次の画像は、プロセッサ互換モードの有効／無効による拡張命令の不一致を、筆者が実際に確認したものだ。上表にリストされた新しい命令がマスクされ、拡張命令が一致していることが分かるだろう。

プロセッサ互換性モードの有効／無効と拡張命令のマスク
これはUbuntuというLinux OSをHyper-Vの仮想マシン上で実行し、プロセッサの情報を表示させたところである。「flags:」の部分にこのプロセッサで利用可能な機能や拡張命令の名前が表示されている。プロセッサ互換性モードを有効にすると、これまで有効であった拡張命令の一部が無効となり、異なる世代のプロセッサ間で一致していることが分かるだろう。なお、Ubuntuは2010年1月現在Hyper-Vで正式サポートされていないOSであるが、拡張命令の状態を簡単に確認できるためにあえて利用している。

　このように、プロセッサ互換性モードの利用にはデメリットもあるため、無意味に有効にするべきではない。あくまで救済機能ととらえておこう。ライブ・マイグレーションの互換性チェックをパスできない場合に限って利用にするようにしたい。

　また、「ライブ・マイグレーションは不要であるが、障害に備えてHAフェイルオーバー機能だけは対応しておきたい」といったニーズもあるだろう。しかし、HAフェイルオーバーはダウンしたゲストOSを再起動する機能だ。アプリケーションを起動したままホストを移動するわけではないので、拡張命令が不一致であってもプロセッサ互換性モードは無効のままで問題ない。一般的にアプリケーションは、自分自身の起動時に利用可能な拡張命令を調べ、それに対応するようになっているためだ。

■VMwareのEVCとの違い

　VMwareをご存じの方は、Hyper-Vのプロセッサ互換性モードはVMwareのEVC（Enhanced VMotion Compatibility）と同じと思ったかもしれない。しかし、両社の機能は目的こそ同じであるが、それぞれ実装のアプローチが大きく異なっている。

　1つはマスクする拡張命令の範囲だ。Hyper-Vのプロセッサ互換性モードは各プロセッサがどのような拡張命令を所持しているかに関係なく、一定のベースラインまで拡張命令を無効にする。これに対し、VMwareのEVCには複数のベースラインが用意されているため、プロセッサの組み合わせ次第では無効にする拡張命令を最小限に抑えることできる。

　もう1つの違いは適用対象である。VMwareのEVCはホスト単位に適用するため、同一ホスト上で動作するすべての仮想マシンが無条件にマスク対象になってしまう。このため、拡張命令をフルに使用するようなアプリケーションは同一ホストに混在できず、専用のホストを別途用意することになる。これに対し、Hyper-Vのプロセッサ互換性モードは仮想マシン単位で適用できるため、こういったアプリケーションを利用する仮想マシンとライブ・マイグレーション対象の仮想マシンと同一ホスト上に混在させることが可能だ。こういったケースではHyper-Vの方がサーバ・マシンの数を少なく済ませることができる。

■仮想化対応のアプリケーションを開発する場合は注意

　サーバ管理者だけでなく、アプリケーション開発者も注意しなければならない点もある。

　拡張命令を利用するようなアプリケーションを開発する場合、「SSE4.2に対応しているかどうかを確認し、対応している場合は利用する」といった分岐を入れることになるが、このチェックには「CPUID」命令を利用しなければならない。まれにプロセッサのモデル名などの情報から、利用可否を判断しているプログラムがある。例えば「Intel Xeon 5500シリーズであればSSE4.2を利用できる」といった判断方法だ。このように型番だけで判断してしまうと、プロセッサ互換性モードのように物理的には搭載されているものの、ソフトウェアで無効にされているといった場合に問題が発生してしまうし、今後発表される新しいプロセッサにも対応できない（実際には同じシリーズであっても、後発のプロセッサでは利用できる機能が変更されていることがよくあるためだ）。

• インテル プロセッサの識別とCPUID命令［PDF］（Intel）
• CPUID Specification［PDF］（AMD）

　またCPUIDによるチェックは、インストールや初期設定時だけでなく、アプリケーション起動時に毎回行うようにしよう。プロセッサ互換性モードはゲストOSをシャットダウンすればいつでも有効／無効に設定変更できることから、初期設定後に利用できる拡張命令が減ることもあり得るためだ。