小川 大地、飯島 徹
日本ヒューレット･パッカード
従来のVMotionは、移行する前と後のホスト機に搭載されているプロセッサの世代が同一である必要があった。プロセッサの命令群は、世代が進むにつれて増えていくが、実行される命令群は仮想マシンの移行前後で同じである必要があるからだ。vSphereでは、この制限を緩和するための機能としてEVC（Enhanced VMotion Compatibility）を実装した。
VMotionは、OSとアプリケーションをひとまとまりにカプセル化する、仮想化だからこそ実現できる画期的な機能である。だが、VMotionでは仮想マシンのゲストOSをシャットダウンせず、アプリケーションを動作させたままホスト間を移行するため、移行元と移行先のプロセッサが、同一ベンダー・同一世代のものでなければならないという制約がある（図1）。
この制約はESXに限ったことではなく、ほかのハイパーバイザーで「ホット・マイグレーション」を実行する場合も同様である。アプリケーションの使用する拡張命令が、移行先のプロセッサでサポートされていれば問題は発生しない。しかし、アプリケーションがどの拡張命令を使うのかESXは予測できないので、安全のためVMotionを実行する前に、必ず両サーバーについてプロセッサの互換性チェックが行われる。不一致がある場合は、図2のようにVMotionの実行がガードされる。
アプリケーションを独自開発した場合など、どの拡張命令を使用するかを熟知している管理者にとって、このガードは不要と感じるかもしれない。しかし、拡張命令はアプリケーションだけではなく、OSによって使われることもある。アップデート・パッチを適用したことで、新しい拡張命令が使われ出す、といったこともあるため、厳格に把握するのは難しい。
では、プロセッサに世代の制約がかかると、管理者にはどのようなデメリットがあるのだろうか。
一つ例を挙げてみよう。サーバー仮想化は、昨今の不況によるIT投資削減の影響もあるが、最初は小さなシステムで試験導入するというケースがほとんどだろう。
スモールスタートで導入を開始した管理者が1年使ってみて仮想化の便利さを感じ、より集約を進めようとサーバーの追加を検討したとする。しかし、業界標準サーバーはライフサイクルが短いので、既存のプロセッサを搭載したサーバー機を入手できないことが多い。
もちろん後継製品を搭載したサーバー機であれば購入可能であるが、VMotionで重要な「プロセッサ世代」が異なるため、既存のホストと新規追加したホスト間でVMotionができないという問題に直面する。
この問題を以前から重要視していたヴイエムウェアは、ESX 3.5 Update 2で新しい技術を実装した。それがEVC（Enhanced VMotion Compatibility）である。
