JPWO2012120664A1 - 仮想計算機のマイグレーション評価方法及び仮想計算機システム - Google Patents

Abstract

複数の物理計算機の計算機資源を仮想計算機に割り当てる仮想化部を管理する管理計算機が、仮想計算機を移動させる物理計算機の評価を行う際に仮想計算機システムであって、管理計算機が、移動対象の第１の仮想計算機を選択し、当該第１の仮想計算機が稼動する第１の物理計算機から当該第１の仮想計算機を移動させる第２の物理計算機を選択し、各仮想計算機を稼働させて複数の物理計算機で使用された計算器資源を測定し、前記第１の仮想計算機の通信先を第１の通信先として特定し、特定された第１の仮想計算機の第１の通信先を、移動先の第２の物理計算機上での通信先に変換して第２の通信先として設定し、第１の仮想計算機を第２の物理計算機で稼動させて第２の通信先と通信を行うときに当該第２の物理計算機で使用される計算器資源を演算する。

Description

本発明は、仮想計算機システムにおいて、仮想計算機の移動に関し、特に物理計算機間で仮想計算機を移動させる際のリソース使用を見積もる技術に関する。

仮想計算機システムでは、複数の仮想計算機で複数のサービスをそれぞれ提供しながら、仮想計算機を物理計算機間で移動させることができる。物理計算機に障害が発生したときや、物理計算機の保守や点検のために停止させる以前には、この物理計算機で稼動していた仮想計算機を、待機系や予備系の他の物理計算機に移動させてサービスの提供を継続することが広く行われている。

仮想計算機を移動させる際には、移動先の物理計算機の負荷が過大になるのを防ぐため、移動先の物理計算機の負荷を見積もり、移動先の物理計算機の負荷が許容範囲内であれば仮想計算機の移動を実施する。

物理計算機の負荷を見積もる際には、移動元の物理計算機の負荷と、移動先の物理計算機の負荷とをそれぞれベンチマークソフトウェアなどにより測定し、移動元の物理計算機と移動先の物理計算機で同一の処理を実行した場合にはどのような負荷比率になるかを算出する技術が知られている（例えば、特許文献１）。

特開２００９−１２３１７４号公報

ここで、仮想計算機システムでは、物理計算機上でハイパーバイザやＶＭＭ（Virtual Machine Monitor）等の仮想化部を実行し、仮想化部上で複数の仮想計算機を提供している。そして、仮想化部は、物理計算機上の物理Ｉ／Ｏデバイスを仮想化した仮想Ｉ／Ｏデバイスを仮想計算機に提供する。仮想計算機は仮想Ｉ／Ｏデバイスを介して通信を行っている。仮想計算機システムでは、仮想化部が仮想スイッチを提供しており、各仮想計算機の仮想Ｉ／Ｏデバイスは仮想スイッチに接続される。そして、仮想化部は、同一の物理計算機上の仮想計算機間の通信では、仮想スイッチ内でデータの送受信を行っている。つまり仮想スイッチは、物理計算機上のメモリの内容を仮想計算機間で送受信することで、仮想計算機からは仮想Ｉ／Ｏデバイスが通信を実施したように見せている。仮想スイッチによる物理計算機上の仮想計算機間の通信では、物理Ｉ／Ｏデバイスを利用せずに、ＣＰＵとメモリの物理リソースを使用するだけとなる。

一方、仮想計算機が他の物理計算機と通信を行う際には、仮想Ｉ／Ｏデバイスから仮想スイッチを介して物理Ｉ／Ｏデバイスを使用する。このため、仮想計算機の通信先の物理計算機によって、使用する物理リソースは異なり、通信を行う物理Ｉ／Ｏデバイスの負荷は異なる。

このため、上記従来例では、移動元の物理計算機上での仮想計算機の通信先と、移動先の物理計算機上で仮想計算機の通信先が変化する際には、上記特許文献１で見積もった移動元の物理計算機の負荷と移動先の物理計算機の負荷を利用できない場合がある、という問題があった。

例えば、物理計算機Ａ上の仮想計算機Ｘが同一の物理計算機Ａ上の仮想計算機Ｙと通信を行っている環境で、仮想計算機Ｘの物理リソースの見積量（使用量）は、ＣＰＵとメモリのみとなって物理Ｉ／Ｏデバイスは使用されていない。この見積量を満たす物理計算機Ｂへ仮想計算機Ｘを移動させると、物理計算機Ｂ上の仮想計算機Ｘは、物理計算機Ａ上の仮想計算機Ｙと通信を行うため、物理計算機Ｂでは当初の見積量には含まれない物理Ｉ／Ｏデバイスのリソース使用が増大する。この結果、物理計算機Ｂの他の仮想計算機では物理Ｉ／Ｏデバイスの帯域が不足して処理の遅延や、過負荷による障害が発生する場合があった。

そこで本発明は上記問題点に鑑みてなされたもので、異なる物理計算機へ移動させる仮想計算機のリソースの使用を正確に判定することを目的とする。

本発明は、プロセッサとメモリをそれぞれ備えた複数の物理計算機と、前記物理計算機で実行されて計算機資源を１つ以上の仮想計算機に割り当てる仮想化部と、前記仮想化部を管理して前記仮想計算機を物理計算機間で移動させる管理計算機と、を備えた仮想計算機システムで、前記管理計算機が前記仮想計算機を移動させる物理計算機の評価を行う仮想計算機のマイグレーション評価方法であって、前記管理計算機が、複数の仮想計算機から移動対象の第１の仮想計算機を選択し、当該第１の仮想計算機が稼動する第１の物理計算機から当該第１の仮想計算機を移動させる第２の物理計算機を選択する第１のステップと、前記管理計算機が、前記仮想計算機を稼働させて前記物理計算機で使用された計算器資源を測定し、前記第１の仮想計算機の通信先を第１の通信先として特定する第２のステップと、前記管理計算機が、前記特定された第１の仮想計算機の第１の通信先を、前記移動先の第２の物理計算機上での通信先に変換して第２の通信先として設定する第３のステップと、前記管理計算機が、前記第１の仮想計算機を前記第２の物理計算機で稼動させて前記第２の通信先と通信を行うときに当該第２の物理計算機で使用される計算器資源を演算する第４のステップと、を含む。

本発明によれば、第１の仮想計算機を第１の物理計算機から第２の物理計算機へマイグレーションする以前に、第１の仮想計算機を第２の物理計算機で実行したときに負荷が過大となるか否かを的確に判定することが可能となる。

本発明の第１の実施形態を示し、仮想計算機システムの一例を示すブロック図である。 本発明の第１の実施形態を示し、仮想計算機システムの機能部位の一例を示すブロック図である。 本発明の第１の実施形態を示し、物理計算機と管理計算機の機能部位の詳細を示すブロック図である。 本発明の第１の実施形態を示し、仮想計算機ＶＭ−Ａ１が使用するＣＰＵ利用率を示すリソース使用表６１０Ａの一例を示す図である。 本発明の第１の実施形態を示し、仮想計算機ＶＭ−Ａ１が使用するＣＰＵ利用率を示すリソース使用表６１０Ａの一例を示す図である。 本発明の第１の実施形態を示し、仮想計算機ＶＭ−Ａ１が使用するＩ／Ｏ処理の示すリソース使用表６１０Ｂの一例を示す図である。 本発明の第１の実施形態を示し、管理計算機が保持する全リソース使用表のブロック図である。 本発明の第１の実施形態を示し、仮想計算機ＶＭ−Ａ１と同一の物理計算機１−Ａの仮想計算機とのＩ／Ｏ処理を抽出したリソース使用表６１０Ｂの一例を示す図である。 本発明の第１の実施形態を示し、仮想計算機ＶＭ−Ａ１が送信元で異なる物理計算機とのＩ／Ｏ処理を抽出したリソース使用表６１０Ｂの一例を示す図である。 本発明の第１の実施形態を示し、物理計算機を収容する筐体内と、筐体間の通信コストを示すリソース変換表の一例を示す図である。 本発明の第１の実施形態を示し、物理計算機１−Ａの仮想計算機ＶＭ−Ａ１を物理計算機１−Ｂへ移動したと仮定して、仮想計算機ＶＭ−Ｂｘとして物理計算機１−Ｂで稼動させたときのリソースの使用を示すシミュレーション表である。 本発明の第１の実施形態を示し、ＣＰＵ利用率の予測値Ｘ（ｔ）と実測値のＣＰＵ利用率Ｘａ（ｔ）の画面イメージである。 本発明の第１の実施形態を示し、ＣＰＵ利用率の予測値Ｘ（ｔ）と実測値のＣＰＵ利用率Ｘａ（ｔ）の差分を示す画面イメージである。 本発明の第１の実施形態を示し、サーバ仮想化部６で行われる処理の一例を示すフローチャートである。 本発明の第１の実施形態を示し、管理計算機２で行われる処理の一例を示すフローチャートである。 本発明の第２の実施形態を示し、仮想計算機システムの一例を示すブロック図である。 本発明の第２の実施形態を示し、物理計算機１−Ｂの機能要素の一例を示すブロック図である。 本発明の第２の実施形態を示し、物理計算機１−Ａのリソース使用表６１０Ｂから仮想計算機ＶＭ−Ａ１のＩ／Ｏ処理をダミーアプリケーションＡＰ−Ｄ１の負荷再生部５１が抽出したダミーＶＭ−Ｄ１のリソース使用再生表の一例を示す図である。 本発明の第２の実施形態を示し、物理計算機１−Ａのリソース使用表６１０Ｂから仮想計算機ＶＭ−Ｂｘが送信元のＩ／Ｏ処理を抽出したダミーＶＭ−Ｄ２のリソース使用再生表の一例を示す図である。 本発明の第２の実施形態を示し、物理計算機１−Ａのリソース使用表６１０Ｂから仮想計算機ＶＭ−Ａｘが送信元のＩ／Ｏ処理を抽出したダミーＶＭ−Ｃ２のリソース使用再生表の一例を示す図である。 本発明の第２の実施形態を示し、管理計算機とダミーＶＭ−Ｄ１で行われる処理の一例を示すフローチャートである。 本発明の第２の実施形態を示し、物理計算機１−ＢでダミーＶＭ−Ｄ１を稼動させたときの負荷の再生状況をコンソールのディスプレイに表示した画面イメージである。 本発明の第２の実施形態を示し、物理計算機１−ＢでダミーＶＭ−Ｄ１を段階的に稼動させたときの負荷の再生状況をコンソールのディスプレイに表示した画面イメージである。

以下、本発明の一実施形態について添付図面を用いて説明する。

図１は本発明の第１の実施形態の仮想計算機システムの構成の一例を示すブロック図である。仮想計算機システムは、ＬＡＮ３を介して接続された３つの物理計算機１−Ａ〜１−Ｃと、これら物理計算機１−Ａ〜１−Ｃを管理する管理計算機２を備える。物理計算機１−Ａ〜１−Ｃと管理計算機２はＳＡＮ（Storage Area Network）を介してストレージ装置４に接続される。各物理計算機１−Ａ〜１−Ｃは、筐体８−Ａ〜８−Ｃにそれぞれ格納される。なお、以下では物理計算機１−Ａ〜１−Ｃの総称を物理計算機１とし、筐体８−Ａ〜８−Ｃの総称を筐体８とする。

物理計算機１ではそれぞれ仮想計算機が実行され、各仮想計算機はサービスを提供する。管理計算機２は、各物理計算機１への仮想計算機の割り当てと、仮想計算機の生成、移動、削除を後述するように管理する。

本実施形態の物理計算機１−Ａ〜１−Ｃ及び管理計算機２のハードウェア構成は、同様であり、物理計算機１−Ａの構成を説明する。筐体８−Ａに格納された物理計算機１−Ａは、演算処理を行うプロセッサ（またはＣＰＵ）１００と、プログラムやデータを一時的に格納するメモリ１１０と、プログラム等を保持する記憶媒体としてのローカルストレージ装置１２０と、筐体８−Ａの外部と通信を行うＣＮＡ（Converged Network Adaptor）１３０がインターコネクト１４０を介して相互に接続される。

プロセッサ（ＣＰＵ）１００は、Ｎ個の演算コアを有し、ローカルストレージ装置１２０またはストレージ装置４からプログラムを読み込んでメモリ１１０にロードする。そして、プロセッサ１００は、メモリ１１０にロードしたデータを実行する。

外部との通信を行うＣＮＡ１３０は、ファイバチャネルのプロトコルをイーサネット（登録商標）フレームで扱うFibre Channel over Ethernet（FCoE）技術を用いて、ＬＡＮ３とＳＡＮ５に接続するＩ／Ｏデバイスを統合的に扱うことができる。つまり、ＣＮＡ１３０は、後述するように、ＨＢＡ（Host Bus Adapter）としてＳＡＮ５に接続される物理Ｉ／Ｏデバイスと、ネットワークインターフェースとしてＬＡＮ３に接続される物理Ｉ／Ｏデバイスを含むＩ／Ｏデバイスである。

なお、管理計算機２は、上記物理計算機１の構成に加えて、入出力装置としてキーボードやマウスとディスプレイからなるコンソール７を有し、指令の入力と表示を行う。

なお、図示の例ではプロセッサ１００が、複数の演算コア＃１〜＃Ｎを備える例を示すが、シングルコアであっても良い。

また、一つの筐体８にひとつの物理計算機１を格納する例を示したが、ブレードサーバのように複数の物理計算機１をひとつの筐体８に格納してもよい。

また、上記ではＣＮＡ１３０でＨＢＡとネットワークインターフェースを統合した例を示したが、ＨＢＡとネットワークインターフェースがそれぞれ独立した物理Ｉ／Ｏデバイスとして実装されてもよい。

また、上記ではローカルストレージ装置１２０からプログラムを読み込む例を示したが、ローカルストレージ装置１２０に代わって、ＳＡＮ５を介したストレージ装置４からプログラムをロードして起動するようにしても良い。

図２は、仮想計算機システムの論理的な構成の一例を示すブロック図である。物理計算機１−Ａ〜１−Ｃでは、仮想計算機に対する計算機資源の割り当てを制御するサーバ仮想化部６−Ａ〜６−Ｃがそれぞれ稼動する。各サーバ仮想化部６−Ａ〜６−Ｃは管理計算機２のサーバ運用管理プログラム２０によって管理される。以下の説明では、サーバ仮想化部６−Ａ〜６−Ｃの総称をサーバ仮想化部６とする。

サーバ仮想化部６は、物理計算機１の計算機資源を仮想計算機に割り当てるハイパーバイザやＶＭＭ（Virtual Machine Monitor）等で構成することができる。以下では、サーバ仮想化部６をハイパーバイザで構成した例を示す。サーバ仮想化部６は物理計算機１上にｎ個の仮想計算機（ＶＭ）６０−１〜６０−ｎを稼動させることができる。また、サーバ仮想化部６は物理Ｉ／Ｏデバイスを仮想Ｉ／Ｏデバイス１３００−１〜１３００−ｎとして仮想計算機６０−１〜６０−ｎに割り当てる処理を実行する。物理計算機１−Ａ〜１−Ｃを図中物理計算機Ａ〜Ｃで示し、物理計算機１−Ａの仮想計算機６０−１〜６０−ｎ、サーバ仮想化部６−Ａ〜６−Ｃ、物理Ｉ／Ｏデバイス（ＣＮＡ）１３０の添え字をＡ〜Ｃで表す。なお、物理Ｉ／Ｏデバイス１３０Ａ〜１３０Ｃは、図１のＣＮＡ１３０である。また、仮想計算機６０−１〜６０−ｎの総称は仮想計算機６０またはＶＭとする。また、図２で示すように、物理計算機Ａ（１−Ａ）の仮想計算機６０の識別子はＶＭ−Ａ１、ＶＭ−Ａ２のように「Ａ」を付加し、物理計算機Ｂ（１−Ｂ）の仮想計算機６０の識別子はＶＭ−Ｂ１、ＶＭ−Ｂ２のように「Ｂ」を付加し、物理計算機Ｃ（１−Ｃ）の仮想計算機６０の識別子はＶＭ−Ｃ１、ＶＭ−Ｃ２のように「Ｃ」を付加する。

例えば、物理計算機１−Ａでは、物理計算機Ａ示しサーバ仮想化部Ａが仮想計算機ＶＭ−Ａ１〜ＶＭ−Ａｎを稼動させる。ここで、サーバ仮想化部Ａは物理Ｉ／ＯデバイスＡを仮想化した仮想Ｉ／Ｏデバイス１、２（１３００−１、１３００−２）を仮想計算機ＶＭ−Ａ１、ＶＭ−Ａ２へそれぞれ提供する。仮想計算機ＶＭ−Ａ１、ＶＭ−Ａ２では、図示しないゲストＯＳ上でアプリケーションＡＰ−Ａ１（１０−１）、ＡＰ−Ａ２（１０−２）を実行し、ＬＡＮ３を介して図示しないクライアント計算機にサービスを提供する。また、サーバ仮想化部６は、仮想計算機６０に割り当てていない余剰の計算機資源をリソースプールとして扱う。

なお、アプリケーションＡＰ−Ａ１、ＡＰ−Ａ２、（１０−２）の総称は、アプリケーション１０とする。また、図２で示すように、物理計算機Ａ（１−Ａ）の仮想計算機６０で実行されるアプリケーション１０の識別子はＡＰ−Ａ１、ＡＰ−Ａ２のように「Ａ」を付加し、物理計算機Ｂ（１−Ｂ）のアプリケーション１０の識別子はＡＰ−Ｂ１、ＡＰ−Ｂ２のように「Ｂ」を付加し、物理計算機Ｃ（１−Ｃ）のアプリケーション１０の識別子はＡＰ−Ｃ１のように「Ｃ」を付加する。

物理計算機１−Ｂ、１−Ｃも物理計算機１−Ａと同様であり、サーバ仮想化部Ｂ，Ｃが仮想計算機ＶＭ−Ｂ１、ＶＭ−Ｃ１を稼動させ、各仮想計算機上でアプリケーションＡＰ−Ｂ１、ＡＰ−Ｃ１を実行する。以下の説明では、物理計算機Ａの仮想計算機ＶＭ−Ａ１を移動元の仮想計算機とし、物理計算機Ｂへ移動する前にリソース使用率（＝リソースの使用量）を見積もる例を示す。

アプリケーション１０は、仮想計算機６０上で実行されて通信やディスクＩ／ＯなどのＩ／Ｏ処理を仮想Ｉ／Ｏデバイス１３００に対して通信パケット（Ｉ／Ｏ要求）として発行する。仮想Ｉ／Ｏデバイス１３００はＩ／Ｏ要求をサーバ仮想化部６に対して送信する。そして、サーバ仮想化部６は、Ｉ／Ｏ要求の宛先が同一の筐体８内の物理計算機１であるか否かを判定する。宛先が同一の筐体８内でなければサーバ仮想化部６は、Ｉ／Ｏ要求を物理Ｉ／Ｏデバイス１３０に対して発行する。一方、宛先が同一の筐体８内であれば、サーバ仮想化部６はメモリ１１０を介してＩ／Ｏ要求を宛先の仮想計算機に送信する。なお、物理Ｉ／Ｏデバイス１３０が受信したＩ／Ｏ要求は、上記の逆の順序でアプリケーションＡＰに伝達される。

ここで、 サーバ運用管理プログラム２０は、各筐体８で使用されている物理計算機１のリソース使用率（またはリソース使用量）や、各処理における負荷のデータなどを収集し、コンソール７を利用する管理者などにＧＵＩ等を介して提供する。そして、収集した物理計算機１のリソース使用率や負荷のデータから仮想計算機６０の移動が必要であれば、仮想計算機ＶＭ−Ａ１を他の物理計算機１へ移動させる。また、サーバ運用管理プログラム２０は、各物理計算機１のサーバ仮想化部６を管理し、仮想計算機６０の生成、移動、削除を管理する仮想化管理部（図示省略）の機能を有する。なお、仮想化管理部については周知または公知の技術を適用すればよいので、本実施形態では説明を省略する。また、サーバ運用管理プログラム２０は、非一時的な計算機読み取り可能な記憶媒体としてのローカルストレージ装置１２０またはストレージ装置４に格納される。

図３は、仮想計算機６０とサーバ仮想化部６及びサーバ運用管理プログラム２０の詳細な論理構成を示すブロック図である。なお、図３では物理計算機１−Ａについて説明するが、物理計算機１−Ｂ、１−Ｃも同様である。

仮想計算機６０−１、６０−２ではアプリケーションＡＰ−Ａ１、ＡＰ−Ａ２が実行され、各アプリケーション１０はＩ／Ｏ利用ログ１１−１、１１−２を生成する。各Ｉ／Ｏ利用ログ１１−１、１１−２は、アプリケーション１０の仮想Ｉ／Ｏデバイス１３００に対するＩ／Ｏ処理を記録する。このときアプリケーション１０は、Ｉ／Ｏ利用ログ間の依存関係（Ｉ／Ｏ発行順序）も併せて記録する。

なお、図３の例ではアプリケーション１０−１、１０−２がそれぞれＩ／Ｏ利用ログ１１−１、１１−２を生成する例を示したが、各仮想計算機６０のＯＳ（図示省略）がＩ／Ｏ利用ログを生成する構成であっても良い。

物理Ｉ／Ｏデバイス１３０Ａは、図１に示した物理計算機１−ＡのＣＮＡ１３００である。仮想Ｉ／Ｏデバイス１３００−１には複数の仮想Ｉ／Ｏデバイスを含めることができる。

図示の例では、仮想Ｉ／Ｏデバイス１に仮想Ｉ／Ｏデバイス＃１と仮想Ｉ／Ｏデバイス＃２が含まれる例を示し、物理Ｉ／Ｏデバイス１３０ＡがＣＮＡのように複数の物理Ｉ／Ｏデバイスを有する場合には、機能毎に独立した仮想Ｉ／ＯデバイスとしてアプリケーションＡＰ（またはゲストＯＳ）に提供することができる。図示の例では、物理Ｉ／Ｏデバイス１３０Ａのネットワークインターフェースの機能が仮想Ｉ／Ｏデバイス＃１として提供され、ＨＢＡの機能が仮想Ｉ／Ｏデバイス＃２として提供された例を示す。物理Ｉ／Ｏデバイス１３０Ａは、物理Ｉ／Ｏデバイス＃１、＃３がネットワークインターフェースで構成され、物理Ｉ／Ｏデバイス＃２がＨＢＡで構成された例を示す。

次に、サーバ仮想化部６−Ａは、Ｉ／Ｏデバイス制御部６３と、リソース監視部６１及びリソース割当制御部６２を含む。

Ｉ／Ｏデバイス制御部６３は、筐体８Ａ内部及び筐体８Ａの外部とのＩ／Ｏ処理を制御する。筐体８Ａの外部に対するＩ／Ｏ要求である場合には、仮想Ｉ／Ｏデバイス１３００から入力されたＩ／Ｏ処理を物理Ｉ／Ｏデバイス１３０Ａに発行する。筐体８Ａの内部に対するＩ／Ｏ要求である場合には、上述のようにメモリ１１０でＩ／Ｏ処理を実施する。筐体８Ａの内部に対するＩ／Ｏ処理は、前記従来技術に示した仮想スイッチ６３０で実施する。

リソース監視部６１は、各仮想計算機６０によるリソースの使用を監視する。リソース監視部６１は、プロセッサ１００や物理Ｉ／Ｏデバイス１３０Ａにアクセスして、リソースの使用率を取得することができる。なお、リソース監視部６１は、リソースの使用を図示しないゲストＯＳから取得しても良い。また、リソース監視部６１はＩ／Ｏ処理の前後でリソースがどの程度使用されたかを取得することで、Ｉ／Ｏ処理に要するプロセッサ１００等の負荷を測定する。なお、リソース監視部６１は、物理計算機１毎の使用電力を検知するようにしても良い。この場合、各物理計算機１には、電力の測定装置を設置すればよい。

リソース割当制御部６２は、各仮想計算機６０上の処理や、サーバ仮想化部６の各コンポーネントの処理で必要となるリソースを割り当てる機能を有する。

リソース使用表６１０は、筐体８Ａ内の物理計算機１−Ａの仮想計算機６０毎のリソース使用状況をテーブル（またはログ）で記録したものである。リソース使用表６１０は三種類で構成され、各仮想計算機６０がＩ／Ｏ処理以外で使用したプロセッサのリソース使用を記録するリソース使用表６１０Ａと、各仮想計算機６０が発行したＩ／Ｏ処理で使用されたリソースの使用を記録するリソース使用表６１０Ｂと、サーバ仮想化部６がＩ／Ｏ処理に関する処理以外で使用したリソースの使用を記録するリソース使用表６１０Ｃから構成される。なお、各ＶＭのリソース使用表６１０Ａは、Ｉ／Ｏ処理を除いて仮想計算機６０が使用したプロセッサ１００等のリソースの使用を示す。

また、リソース使用表６１０Ｂは、各仮想計算機６０がＩ／Ｏ処理の際に使用したリソースの使用を示し、本実施形態では、各仮想計算機６０がＩ／Ｏ処理の際に使用したプロセッサ１００の使用率と、ＣＮＡ１３０の使用率をリソースの使用として扱う。なお、リソースの使用率に代わって、データサイズなどをリソースの使用量として扱うようにしても良い。

次に、各物理計算機１のサーバ仮想化部６を管理する管理計算機２は、リソース使用状況管理部２１と、負荷検出部２２と、マイグレーション制御部２３と、入出力部２４とを備えて物理Ｉ／Ｏデバイス１３０Ｚ（ＣＮＡ）を介して各物理計算機１と通信を行う。

リソース使用状況管理部２１は、各物理計算機１のサーバ仮想化部６のリソース監視部と通信することで、各筐体８及び仮想計算機６０によって生じる負荷情報（リソース使用情報）を取得する。リソース使用状況管理部２１は、各筐体８のサーバ仮想化部６で生成されたリソース使用表６１０Ａ〜６１０Ｃの一部ないしは全てを保持する。リソース使用状況管理部２１は、各筐体８の物理計算機１から取得したリソース使用表６１０Ａ〜６１０Ｃの内容を、全リソース使用表２１０として保持する。全リソース使用表２１０のフォーマットはリソース使用表６１０Ａ〜６１０Ｃと同一である。

リソース使用状況管理部２１は、各筐体８の物理計算機１から取得したＩ／Ｏ処理のリソース使用表６１０Ｂに基づいて、各筐体８での所定の単位データサイズのＩ／Ｏ処理に要する負荷（通信コスト）を演算する機能を有する。リソース使用状況管理部２１は、この演算結果をリソース変換表２２０として保持する。リソース変換表２２０は、各筐体８の物理計算機１での筐体８内の通信コストと筐体８間の通信コストを保持する。

管理計算機２は、移動対象の仮想計算機ＶＭ−Ａ１が移動候補の物理計算機１−Ｂで正常に動作するか否かの見積を行う際に、リソース変換表２２０を利用する。

マイグレーション制御部２３は、各仮想計算機６０のリソース使用と、各筐体８の物理計算機１のリソース使用から、移動対象の仮想計算機６０を選択して、どの筐体８の物理計算機１にマイグレーションすればよいかを判定する。この移動元の仮想計算機６０と、移動先の物理計算機１を選択する手法については、周知または公知の技術を適宜用いることができるので、ここでは説明を省略する。また、移動対象の仮想計算機６０を選択するパラメータとしては上記リソース使用の他に、曜日あるいは期末などの暦の情報や時刻の情報を加味しても良い。

また、マイグレーション制御部２３は、コンソール７からの指令やスケジュールなどに基づいて、移動対象の仮想計算機６０を移動先の物理計算機１へマイグレーションすることができる。

リソース消費状況管理部２１と負荷検証部２２は、マイグレーション制御部２３が判定したマイグレーション対象の仮想計算機６０と移動先の筐体８内の物理計算機１の情報を取得して、負荷予測を実施する。負荷予測の概要は次のとおりである。

リソース消費状況管理部２１はまず、移動元の仮想計算機６０のサーバ仮想化部６から過去のリソース使用履歴としてリソース使用表６１０Ａ〜６１０Ｃを取得し、また、移動先の物理計算機１−Ｂのリソース使用表６１０Ａ〜６１０Ｃを取得し、全リソース使用表２１０を更新する。

次に、負荷検証部２２は、移動先の物理計算機１の各仮想計算機６０のリソース使用を時刻毎に積算して移動先の物理計算機１の全体のリソース使用率を求める。そして、負荷検証部２２は、移動先の物理計算機１の全体のリソース使用率に、移動対象の仮想計算機６０のリソース使用率を積み重ねて、移動対象の仮想計算機６０をマイグレーションした後の移動先の物理計算機１のリソースの使用率を演算する。なお、各物理計算機１の性能が異なる場合には換算式などで補正すればよい。また、Ｉ／Ｏ処理のリソース使用率を求める際には、移動元の物理計算機１において筐体８内の通信は、移動先の物理計算機では筐体８外の通信に変換し、リソース変換表２２０からリソース使用を換算する。一方、移動元の物理計算機１において筐体８外の通信のうち、移動先の物理計算機で筐体８内通信になる場合は、リソース変換表２２０からリソース使用率を換算する。

以上のようにＩ／Ｏ処理では、負荷検証部２２が筐体８内通信と筐体８外の通信を、移動先の物理計算機１の仮想計算機６０に応じて筐体８内通信と筐体８外通信を変換する。そして、負荷検証部２２は、移動対象の仮想計算機６０をマイグレーションした後の移動先の物理計算機１の全体のリソース使用をリソース変換表２２０を参照して各時刻毎に演算する。

そして、負荷検証部２２は、マイグレーションした後の移動先の物理計算機１の全体のリソース使用率が所定の閾値Ｔｈ１を超えていれば移動先の物理計算機１はマイグレーション先として不適切であり、全体のリソース使用率が所定の閾値Ｔｈ１以内であれば移動先の物理計算機１はマイグレーション先として適切であると判定する。

なお、マイグレーションの可否を判定する閾値Ｔｈ１は、コンソール７からの指令や所定のファイルに格納される。

入出力部２４は、コンソール７へリソース使用状況管理部２１のデータ（全リソース使用表２１０の一部ないしは全部）を表示する。表示方法は、表そのものであってもよいし、別図に示すような、グラフであってもよい。また、これらの表示形式は入出力部２４からの指令などによって、コンソール７の利用者（管理者）が指定することができる。また、入出力部２４は、負荷検証部２２やマイグレーション制御部２３の演算結果の表示や、入力を受け付けるインターフェースを提供することができる。

図４は、サーバ仮想化部６のリソース監視部６１が管理するリソース使用表のうち各仮想計算機６０のリソース使用表６１０Ａの一例を示す。リソース使用表６１０Ａは、各仮想計算機６０で使用されているリソースの推移を管理する。リソース使用表６１０Ａは、仮想計算機６０の識別子を格納するＶＭ識別子６１１Ａと、時刻を格納するｔｉｍｅ６１２Ａと、プロセッサ１００の利用率を格納するＣＰＵ使用率６１３Ａから構成される。図示の例では、物理計算機１−Ａの仮想計算機６０−１（ＶＭ−Ａ１）について１秒おきにプロセッサ１００の利用率を測定した例である。ＣＰＵ使用率６１３Ａは、仮想計算機６０−１のＯＳから見たプロセッサ１００の利用率である。この他、仮想計算機６０が使用しているメモリ１１０の利用率を加えることができる。

なお、リソース使用表６１０Ａ〜６１０Ｃは、ログとしてローカルストレージ装置１２０あるいはＳＡＮ５上のストレージ装置４に格納してもよい。また、筐体８の外部のストレージ装置４にログを格納する場合は、ログを格納するためにＩ／Ｏ処理を行ったときのリソース使用率もＩ／Ｏ利用ログ１１−１に記録することができる。

図５Ａは、物理計算機１−Ａのサーバ仮想化部６−Ａのリソース監視部６１が管理するリソース使用表のうちＩ／Ｏ処理のリソース使用表６１０Ｂの一例を示す。リソース使用表６１０Ｂは、物理計算機１−Ａ上の各仮想計算機６０が実行したＩ／Ｏ処理の履歴を格納する。

リソース使用表６１０Ｂは、時刻を格納するｔｉｍｅ６１１Ｂと、送信元の仮想計算機６０の識別子を格納する送信元識別子６１２Ｂと、送信先の仮想計算機６０の識別子を格納する送信先識別子６１３Ｂと、送受信したデータの容量を格納するデータサイズ６１４Ｂと、Ｉ／Ｏ処理を行ったときのプロセッサ１００の利用率を格納するＣＰＵ利用率６１５Ｂと、Ｉ／Ｏ処理を行ったときのＣＮＡ１３０の利用率を格納するＣＮＡ利用率６１６Ｂからひとつのエントリが構成される。

データサイズ６１４Ｂは、データの容量の他に、Ｉ／Ｏデバイス１３０との間で実際に送受信するＩ／Ｏバッファのサイズを示すチャンクサイズの何個分か、という形式でもよい。ＣＰＵ利用率６１５Ｂは、仮想計算機６０に割り当てられたプロセッサ１００のリソースについて仮想計算機６０のＯＳ（図示省略）から見た利用率を示す。ＣＮＡ利用率６１６Ｂは、仮想計算機６０に割り当てられた仮想Ｉ／Ｏデバイス１３００のリソースについて仮想計算機６０のＯＳ（図示省略）から見た利用率を示す。

図示のデータのうち、＃１ａは、物理計算機１−Ａの仮想計算機Ａ１（ＶＭ−Ａ１）から物理計算機１−Ｂの仮想計算機Ｂ２（ＶＭ−Ｂ２）へのネットワークアクセスで、データ量が２ＭＢであることを示す。図中＃２ａのデータは、物理計算機１−Ａの仮想計算機Ａ２（ＶＭ−Ａ２）からストレージ装置４へのディスクアクセスで、データ量が４ＭＢであることを示す。図中＃３ａのデータは、物理計算機１−Ａの仮想計算機Ａ１（ＶＭ−Ａ１）から物理計算機１−Ａの仮想計算機Ａ４（ＶＭ−Ａ４）へのネットワークアクセスで、データ量が２ＭＢであることを示す。このデータ＃３ａのように、同一の物理計算機１−Ａ上のネットワークアクセスは、ＣＮＡ利用率６１６Ｂは０％となって、ＣＮＡ１３０は経由せずにプロセッサ１００の処理によるメモリ１１０のコピーとなる。すなわち、図３に示した仮想スイッチ６３０によって物理計算機１−Ａの仮想計算機Ａ１（ＶＭ−Ａ１）と仮想計算機Ａ４（ＶＭ−Ａ４）がメモリ１１０上で通信を行ったことを意味する。

以上のように、物理計算機１−Ａのサーバ仮想化部６−Ａでは、仮想計算機６０の処理、仮想計算機６０のＩ／Ｏ処理及びサーバ仮想化部６の処理で使用されたリソースの履歴が、リソース使用表６１０Ａ〜６１０Ｃとして蓄積される。

なお、他の物理計算機１−Ｂ、１−Ｃのサーバ仮想化部６−Ｂ、６−Ｃについても、上記サーバ仮想化部６−Ａと同様に、リソース使用表６１０Ａ〜６１０Ｃが蓄積される。

図５Ｂは、物理計算機１−Ｂのサーバ仮想化部６−Ｂのリソース監視部６１が管理するリソース使用表のうちＩ／Ｏ処理のリソース使用表６１０Ｂの一部を示す。図５Ｂでは、図５Ａのうち、物理計算機１−Ｂの仮想計算機６０が送信先または送信元となっているＩ／Ｏ処理について示したものである。つまり、筐体８間に跨る通信の場合には、各物理計算機１上のサーバ仮想化部６によってＩ／Ｏ処理のリソース使用表６１０Ｂが蓄積される。

なお、リソース使用表６１０Ａ〜６１０Ｃは、ログとしてローカルストレージ装置１１０またはストレージ装置４ディスクに格納してもよい。

以下では、マイグレーション制御部２３が、マイグレーションの対象として物理計算機１−Ａの仮想計算機６０−１（ＶＭ−Ａ１）を選択し、この仮想計算機ＶＭ−Ａ１を物理計算機１−Ｂへ移動させる際の処理について説明する。

＜処理の概要＞

マイグレーション制御部２３が移動対象の仮想計算機ＶＭ−Ａ１と、移動先の物理計算機として物理計算機１−Ｂを選択し、管理計算機２は各物理計算機１−Ａ〜１−Ｃに対して、リソース使用表６１０Ａ〜６１０Ｃをそれぞれ取得するよう指令する。この指令は、例えば、マイグレーション制御部２３が負荷検証部２２に移動対象の仮想計算機ＶＭ−Ａ１と移動先の物理計算機１−Ａを通知し、負荷検証部２２全リソース使用表２１０を更新するようリソース使用状況管理部２１に指令する。

リソース使用状況管理部２１は、各物理計算機１−Ａ〜１−Ｃのサーバ仮想化部６−Ａ〜６−Ｃに対して、それぞれリソース使用表６１０Ａ〜６１０Ｃの更新を指令する。

上記指令により、サーバ仮想化部６−Ａ〜６−Ｃでは、それぞれ図９Ａに示す処理が行われる。図９Ａは、サーバ仮想化部６で行われる処理の一例を示すフローチャートである。

まず、各サーバ仮想化部６では、ステップＳ１で管理計算機２のリソース使用状況管理部２１からリソース使用の計測開始の指示を受信すると、上述のリソース使用表６１０Ａ〜６１０Ｃの取得を実施する（Ｓ１）。

各サーバ仮想化部６では、ステップＳ２で各物理計算機１上で使用されたリソースを測定する。各サーバ仮想化部６は測定したリソース使用率で各リソース使用表６１０Ａ〜６１０Ｃを更新する（Ｓ２）。上記ステップＳ１〜Ｓ３の処理を管理計算機２から測定終了の通知を受信するまで繰り返す（Ｓ３）。

上記の処理により所定期間のリソース使用表６１０Ａ〜６１０Ｃが、各物理計算機１−Ａ〜１−Ｃのそれぞれについて得られる。なお、管理計算機２が各サーバ仮想化部６に対して指令する測定開始（ｔ１）から測定終了（ｔ２）までの所定の期間は、予め定めた時間やコンソール７から入力した時間などである。

リソース監視部６１は、各仮想計算機６０が利用するプロセッサ１００の利用率（ＣＰＵ利用率）を、図４で示すように、仮想計算機６０毎に所定の時間（図示の例では１秒）で取得し、仮想計算機６０毎のリソース使用表６１０Ａを生成する。

Ｉ／Ｏ処理のリソース使用については、Ｉ／Ｏデバイス制御部６３がＩ／Ｏ処理要求を受け付けると、リソース監視部６１にＣＰＵ利用率とＣＮＡ利用率及び処理するデータサイズの取得開始を指令する。Ｉ／Ｏデバイス制御部６３は、受け付けたＩ／Ｏ処理が完了すると、リソース監視部６１にＣＰＵ利用率とＣＮＡ利用率及びデータサイズの取得終了を通知する。リソース監視部６１は、送信元識別子と送信先識別子にＣＰＵ利用率とＣＮＡ利用率及びデータサイズを対にして、Ｉ／Ｏ処理のリソース使用表６１０Ｂを生成する。なお、ＣＰＵ利用率とＣＮＡ利用率は、平均値や最大値など予め設定した処理を加えることができる。

また、リソース監視部６１は、サーバ仮想化部６自身が利用するプロセッサ１００の利用率を所定の時間（例えば、１秒間）間隔で取得し、サーバ仮想化部６のリソース使用表６１０Ｃを生成する。

なお、Ｉ／Ｏ処理のリソース使用については、ＣＰＵ利用率をサーバ仮想化部６のリソース使用表６１０Ｃから差し引いておいても良い。また、各リソース使用率の取得は、公知または周知の手法を適宜適用することができ、上述した手法に限定されるものではない。

各サーバ仮想化部６は、管理計算機２から測定終了の通知を受信すると、リソース使用率の測定を終了し、蓄積したリソース使用表６１０Ａ〜６１０Ｃをそれぞれ管理計算機２のリソース使用状況管理部２１へ送信する。

管理計算機２のリソース使用状況管理部２１は、各サーバ仮想化部６から受信したリソース使用表６１０Ａ〜６１０Ｃを全リソース使用表２１０として保持する。

図５Ｃは、管理計算機２のリソース使用状況管理部２１が保持する全リソース使用表２１０の一例を示す。リソース使用状況管理部２１は、物理計算機１−Ａのサーバ仮想化部６−Ａから受信したリソース使用表６１０Ａ〜６１０Ｃを、リソース使用表６１０Ａ−１〜６１０Ｃ−１として全リソース使用表２１０内に保持する。リソース使用状況管理部２１は、物理計算機１−Ｂのサーバ仮想化部６−Ｂから受信したリソース使用表６１０Ａ〜６１０Ｃを、リソース使用表６１０Ａ−２〜６１０Ｃ−２として全リソース使用表２１０内に保持し、同様に、物理計算機１−Ｃのサーバ仮想化部６−Ｃから受信したリソース使用表６１０Ａ〜６１０Ｃを、リソース使用表６１０Ａ−３〜６１０Ｃ−３として全リソース使用表２１０内に保持する。なお、図中シミュレーション表６１０Ｂ−２ｓは、後述の負荷検証部２２が生成する表である。

次に、リソース使用状況管理部２１は、各物理計算機１−Ａ〜１−Ｃから取得した全リソース使用表２１０よりＩ／Ｏ処理の単価（コスト）を求めて、リソース変換表２２０に設定する。本実施形態では、Ｉ／Ｏ処理のリソース使用表６１０Ｂ−１〜６１０Ｂ−３からＩ／Ｏ処理の単価を求める例について説明する。

図９Ｂは、管理計算機２で行われる処理の一例を示すフローチャートである。この処理は、各物理計算機１−Ａ〜１−Ｃからリソース使用表６１０Ａ〜６１０Ｃを受信した後に実行される。

まず、管理計算機２のリソース使用状況管理部２１は、ステップＳ１０で、筐体８内の通信コストを演算する。通信コストは、予め設定した単位データサイズ（例えば、１２８ｋＢ）を転送する際に使用したリソースの使用率を求める。なお、以下の例では１ＭＢ＝１０２４ｋＢとして演算した例を示す。また、単位データサイズはＣＮＡ１３０が一回の通信で送受可能なデータサイズなどに設定することができる。

この演算は、例えば、図６Ａで示すように、同一の筐体８内の通信を抽出し、データサイズ６１４Ｂ（ｋＢ）とＣＰＵ利用率６１５Ｂから単位データサイズ（１２８ｋＢ）あたりのＣＰＵ利用率ｘを次式により求める。
Ｘ ＝ ＣＰＵ利用率／（データサイズ（ｋＢ）／１２８（ｋＢ）） …（１）

つまり、図５Ａで示したように、物理計算機１−ＡのＩ／Ｏ処理のリソース使用表６１０Ｂには、筐体８内の通信によるＩ／Ｏ処理の履歴と、筐体８間の通信によるＩ／Ｏ処理の履歴が混在している。そこで、リソース使用状況管理部２１は、物理計算機１−ＡのＩ／Ｏ処理のリソース使用表６１０Ｂから、送信元識別子６１２Ｂと送信先識別子６１３Ｂが同一の物理計算機１−Ａ上の仮想計算機ＶＭ−Ａｘ間のＩ／Ｏ処理の履歴を抽出し、図６Ａの同一の筐体８内のＩ／Ｏ処理の履歴を集計する。

図６ＡのＩ／Ｏ処理の履歴では、３つの筐体８内のＩ／Ｏ処理から＃１ａ、＃６ａ、＃９ａのＣＰＵ利用率６１５Ｂから単位データサイズ当たりのＣＰＵ利用率をそれぞれ求め、これらの平均値を筐体８Ａ内のＩ／Ｏ処理にかかるＣＰＵ利用率ｘ＝０．４２９％（小数点以下第４位を四捨五入）として設定する。

同様に、図６Ａで示したように、同一の筐体８内のＩ／Ｏ処理の履歴から、データサイズ６１４Ｂ（ｋＢ）とＣＮＡ利用率６１６Ｂから単位データサイズ（１２８ｋＢ）あたりのＣＮＡ利用率ｙを次式により求める。
Ｙ ＝ ＣＮＡ利用率／（データサイズ（ｋＢ）／１２８（ｋＢ）） …（２）

同一の物理計算機１−Ａ上では、仮想スイッチ６３０による通信となるので、ＣＮＡ利用率６１６Ｂの平均値は０％となる。

以上より、筐体８−Ａ内の通信コストは、
平均ＣＰＵ利用率Ｘａａ＝０．４２９％
平均ＣＮＡ利用率Ｙａａ＝０％
となる。なお、添え字の「ａａ」は送信元の筐体が８−Ａで、送信先の筐体が８−Ａであることを示す。

リソース使用状況管理部２１は、他の物理計算機１−Ｂ，１−Ｃについても、全リソース使用表２１０内のリソース使用表６１０Ｂ−２、６１０Ｂ−３から筐体８−Ｂ内の通信コストと、筐体８−Ｃ内の通信コストとをそれぞれ求める。

次に、ステップＳ１１では、リソース使用状況管理部２１が、全リソース使用表２１０内のリソース使用表６１０Ｂ−１〜６１０Ｂ−３から各筐体８間の通信コストＸｂｂ、Ｙｂｂ、Ｘｃｃ、Ｙｃｃを演算する。

例えば、図５Ａ、図５Ｂで示した物理計算機１−Ａ、１−ＢのＩ／Ｏ処理のリソース使用表６１０Ｂ−１、６１０Ｂ−２から筐体８−Ａ、８−Ｂ間の通信で、筐体８−Ａが送信元になるＩ／Ｏ処理の履歴を抽出すると図６Ｂのように、３つのＩ／Ｏ処理の履歴が抽出される。これらの各行について上記（１）式より単位データサイズ当たりのＣＰＵ利用率Ｘと、単位データサイズ当たりのＣＮＡ利用率＝Ｙを求める。そして、各ＣＰＵ利用率ＸとＣＮＡ利用率＝Ｙの平均値を、筐体８−Ａから筐体８−Ｂへの通信コストとして
平均ＣＰＵ利用率Ｘａｂ＝０．１５０％
平均ＣＮＡ利用率Ｙａｂ＝０．２７５％
となる。なお、添え字の「ａｂ」は送信元の筐体が８−Ａで、送信先の筐体が８−Ｂであることを示す。また、リソース使用状況管理部２１は、送信元の筐体が８−Ｂで、送信先の筐体が８−Ａの通信コストも同様に算出し、平均ＣＰＵ利用率Ｘｂａ、平均ＣＮＡ利用率Ｙｂａとする。

リソース使用状況管理部２１は、他の物理計算機１−Ｂ，１−Ｃについても、全リソース使用表２１０内のリソース使用表６１０Ｂ−２、６１０Ｂ−３から筐体８−Ａ、８−Ｂ、８−Ｃ間の各通信コストをそれぞれ求める。

次に、ステップＳ１２では、リソース使用状況管理部２１は、上記ステップＳ１０、Ｓ１１で求めた筐体８内と筐体８内の通信コストをリソース変換表２２０を書き込んで更新する。

図６Ｃは、リソース変換表２２０の一部を示す図である。図６Ｃは、Ｉ／Ｏ処理のリソース使用表６１０Ｂ−１〜６１０Ｂ−３から各筐体８内及び筐体８間の通信コストを求めたうち、筐体８−Ａと筐体８−Ｂの通信コストに関する部分のリソース変換表２２０の例を示す。図６Ｃにおいて、リソース変換表２２０は、送信元の筐体８の識別子を格納する送信元識別子２２１と、送信先の筐体８の識別子を格納する送信先識別子２２２と、単位データサイズ当たりのＣＰＵ利用率の平均値Ｘｉｊ（ｉ，ｊは筐体８の識別子）を格納するＣＰＵ利用率２２３と、単位データサイズ当たりのＣＮＡ利用率の平均値Ｙｉｊを格納するＣＮＡ利用率２２４とからひとつのエントリが構成される。

送信元識別子２２１が「筐体Ａ」で送信先識別子２２２も「筐体Ａ」のエントリは、筐体８−Ａの筐体内の通信コストＸａａ、ＹａａがそれぞれＣＰＵ利用率２２３とＣＮＡ利用率２２４に格納される。

一方、送信元識別子２２１が「筐体Ａ」で送信先識別子２２２が「筐体Ｂ」のエントリは、筐体８−Ａから筐体８−Ｂへの筐体間の通信コストＸａｂ、ＹａｂがそれぞれＣＰＵ利用率２２３とＣＮＡ利用率２２４に格納される。

なお、リソース使用率の計測開始（ｔ１）から計測終了（ｔ２）までの期間に、Ｉ／Ｏ処理のない仮想計算機６０があった場合には、過去に求めたリソース変換表２２０の値を利用するようにしてもよい。あるいは、上記ステップＳ１２のリソース変換表２２０の更新は、図９Ａの処理で新たにリソース使用表６１０Ｂが更新された仮想計算機６０に関して実行するようにしても良い。

次に、図９ＢのステップＳ１３では、マイグレーション制御部２３が選択した移動対象の仮想計算機ＶＭ−Ａ１と、移動先の物理計算機１−Ａについて負荷検証部２２がリソース使用率の見積を実施する。

まず、負荷検証部２２は、移動対象の仮想計算機ＶＭ−Ａ１のリソース使用率が記録されたリソース使用表６１０Ａ−１、６１０Ｂ−１と、移動先の物理計算機１−Ｂのリソース使用率が記録されたリソース使用表６１０Ａ−２、６１０Ｂ−２、６１０Ｃ−２を全リソース使用表２１０から読み込む。

次に、負荷検証部２２は、移動対象の仮想計算機６０を含む物理計算機１−ＡのＩ／Ｏ処理のリソース使用率が記録されたリソース使用表６１０Ｂ−１から、移動対象の仮想計算機ＶＭ−「Ａ１」を送信元識別子６１２Ｂまたは送信先識別子６１３Ｂに含むエントリを抽出し、「Ａ１」を物理計算機１−Ｂへ移動したことを示す「Ｂｘ」に置き換える。そして、移動対象の仮想計算機ＶＭ−Ａ１を物理計算機１−Ｂへ移動後の通信状態に応じて、負荷検証部２２はＣＰＵ利用率６１５ＢとＣＮＡ利用率６１６Ｂを演算する。この演算の結果は図７に示すようになる。

図７は、物理計算機１−Ａの仮想計算機ＶＭ−Ａ１を物理計算機１−Ｂへ移動したと仮定して、仮想計算機ＶＭ−Ｂｘとして稼動したときのリソース使用率を示すシミュレーション表６１０Ｂ−２ｓである。このシミュレーション表６１０Ｂ−２ｓフォーマットはリソース使用表６１０Ｂと同一である。ただし、移動対象の仮想計算機ＶＭ−Ａ１を含まないエントリは負荷検証部２２で削除されたものである。

図７において、エントリ＃１ａ'は、送信元識別子６１２Ｂが「Ａ１」から「Ｂｘ」に変更され、送信先識別子６１３Ｂが「Ｂ２」なので筐体８間の通信が筐体８−Ｂ内の通信に変更されている。このため、負荷検証部２２は、図６Ｃのリソース変換表２２０から送信元識別子２２１と送信先識別子２２２が「筐体Ｂ」の筐体８内の単位データサイズ当たりの通信コスト（ＣＰＵ利用率＝０．４９２％、ＣＮＡ利用率＝０％）を取得し、図７のエントリ＃１ａ'のデータサイズ＝２ＭＢ＝２０４８ｋＢを、筐体８内の通信で利用するリソース使用率に変換すると新たな仮想計算機ＶＭ−Ｂｘが物理計算機１−Ｂで使用するＣＰＵ利用率＝７．８７％となる。つまり、２ＭＢ＝（１２８ｋＢ×１６）であるため、ＣＰＵ利用率Ｘｂｂは０．４９２％×１６＝７．８７２％（四捨五入して７．８７％） となり、ＣＮＡ利用率は０％となる。

一方、図７において、エントリ＃３ａ'は、送信元識別子６１２Ｂが「Ａ１」から「Ｂｘ」に変更され、送信先識別子６１３Ｂが「Ａ４」なので筐体８内の通信が筐体８−Ｂから筐体８−Ａへの筐体８間の通信に変更されている。このため、負荷検証部２２は、図６Ｃのリソース変換表２２０から送信元識別子２２１が「筐体Ｂ」で、送信先識別子２２２が「筐体Ａ」の筐体８間の通信の単位データサイズ当たりの通信コスト（ＣＰＵ利用率＝０．１３９％、ＣＮＡ利用率＝０．２８６％）を取得し、図７のエントリ＃３ａ'のデータサイズ＝２ＭＢ＝２０４８ｋＢを、筐体８間で通信する際に利用するリソース使用率に変換すると新たな仮想計算機ＶＭ−Ｂｘが物理計算機１−Ｂで使用するＣＰＵ利用率＝２．２２％でＣＮＡ利用率＝４．２６％となる。

負荷検証部２２は、図７の他のエントリについても移動対象の仮想計算機ＶＭ−Ａ１を物理計算機１−Ｂへ移動したと仮定して上記と同様に通信コストの演算を行う。

また、負荷検証部２２は、物理計算機１−ＢのＩ／Ｏ処理のリソース使用表６１０Ｂ−２から仮想計算機ＶＭ−Ａ１を含むエントリを削除する。これは、シミュレーション表６１０Ｂ−２ｓで移動対象の仮想計算機ＶＭ−Ａ１を物理計算機１−Ｂ上のＶＭ−Ｂｘに置き換えてリソース使用率を演算したためである。すなわち、Ｉ／Ｏ処理のリソース使用表６１０Ｂ−２は、仮想計算機ＶＭ−Ａ１を移動する以前の筐体８間の通信で使用するリソースが含まれているため、これを削除しておく。また、負荷検証部２２は、シミュレーション表６１０Ｂ−２ｓを全リソース使用表２１０に保存する。

次に、図９ＢのステップＳ１４では、負荷検証部２２が、仮想計算機ＶＭ−Ａ１を移動した場合について、測定開始時刻ｔ１から測定終了時刻ｔ２までのＣＰＵ利用率を各時刻（リソース使用表のｔｉｍｅ６１１Ｂ）毎に積算する。

ある時刻ｔの物理計算機１−ＢのＣＰＵ利用率の予測値Ｘ（ｔ）は、次のように行う。

元の物理計算機１−Ｂの仮想計算機６０が利用しているＩ／Ｏ処理を除くＣＰＵ利用率Ｘ１（ｔ）を、物理計算機１−Ｂのリソース使用表６４０Ａ−２から求める。

元の物理計算機１−Ｂのサーバ仮想化部６Ｂが利用しているＣＰＵ利用率Ｘ２（ｔ）を、物理計算機１−Ｂのリソース使用表６４０Ｃ−２から求める。

仮想計算機ＶＭ−Ａ１を削除した物理計算機１−ＢのＩ／Ｏ処理のリソース使用表６１０Ｂ−２からＣＰＵ利用率Ｘ３（ｔ）を求める。

最後に、仮想計算機ＶＭ−Ｂｘのリソース使用率を示すシミュレーション表６１０Ｂ−２ｓからＣＰＵ利用率Ｘ４（ｔ）を求める。

そして、負荷検証部２２は、測定開始時刻ｔ１から測定終了時刻ｔ２までの各時刻のＣＰＵ利用率の予測値Ｘ（ｔ）を、

Ｘ（ｔ）＝Ｘ１（ｔ）＋Ｘ２（ｔ）＋Ｘ３（ｔ）＋Ｘ４（ｔ）
として求め、入出力部２４に出力する。

また、負荷検証部２２は、仮想計算機ＶＭ−Ａ１を移動する以前の物理計算機１−ＢのＣＰＵ利用率Ｘａ（ｔ）を次のように求める。負荷検証部２２は、元の物理計算機１−Ｂのリソース使用表６１０Ｂ−２（仮想計算機ＶＭ−Ａ１を削除する以前）からＣＰＵ利用率Ｘ５（ｔ）を求める。そして、負荷検証部２２は、測定開始時刻ｔ１から測定終了時刻ｔ２までの各時刻のＣＰＵ利用率Ｘａ（ｔ）を、

Ｘａ（ｔ）＝Ｘ１（ｔ）＋Ｘ２（ｔ）＋Ｘ３（ｔ）＋Ｘ５（ｔ）
として求め、入出力部２４に出力する。

図９ＢのステップＳ１５では、入出力部２４が仮想計算機ＶＭ−Ａ１を物理計算機１−Ｂへ移動した場合のＣＰＵ利用率の予測値Ｘ（ｔ）と、移動前のＣＰＵ利用率Ｘａ（ｔ）をコンソール７に出力する。

入出力部２４の出力の結果、図８Ａで示すように、仮想計算機ＶＭ−Ａ１を移動する前の物理計算機１−ＢのＣＰＵ利用率Ｘａ（ｔ）が実線で表示され、仮想計算機ＶＭ−Ａ１を移動した場合の物理計算機１−ＢのＣＰＵ利用率の予測値Ｘ（ｔ）が破線で表示される。図８Ａはコンソール７のディスプレイに出力された、ＣＰＵ利用率の予測値Ｘ（ｔ）と実測値のＣＰＵ利用率Ｘａ（ｔ）の画面イメージである。

また、負荷検証部２２が入出力部２４に予め設定されたＣＰＵ利用率の閾値Ｔｈ１をコンソール７に表示させ、破線の予測値Ｘ（ｔ）が閾値Ｔｈ１を超えていれば、この仮想計算機ＶＭ−Ａ１を当該物理計算機１−Ｂへマイグレーションさせると、負荷が過大になると判定することができる。このため、仮想計算機ＶＭ−Ａ１の物理計算機１−Ｂへのマイグレーションは不適切であると判定できる。

一方、破線の予測値Ｘ（ｔ）が閾値Ｔｈ１以内であれば、この仮想計算機ＶＭ−Ａ１を当該物理計算機１−Ｂへマイグレーションさせても負荷が過大になることはないと判定することができる。このため、仮想計算機ＶＭ−Ａ１の物理計算機１−Ｂへのマイグレーションは適切であると判定できる。

また、負荷検証部２２が、予測値Ｘ（ｔ）と実測値Ｘａ（ｔ）の差分を入出力部２４へ出力した場合には、図８Ｂで示すように、ＣＰＵ利用率の変動量を表示することができる。このとき、閾値Ｔｈ１と同様に最大負荷を定めておき、ＣＰＵ利用率の変動量が最大負荷を超える場合には、当該仮想計算機ＶＭ−Ａ１を当該物理計算機１−Ｂへマイグレーションすることができない、と判定することができる。図８Ｂはコンソール７のディスプレイに出力された、ＣＰＵ利用率の予測値Ｘ（ｔ）と実測値のＣＰＵ利用率Ｘａ（ｔ）の差分の画面イメージである。

なお、ＣＮＡ利用率についても上記のＣＰＵ利用率と同様に閾値Ｔｈ１と予測値Ｘ（ｔ）を比較して、仮想計算機ＶＭ−Ａ１のマイグレーションが可能であるか否かを事前に判定することが可能となる。

図８Ａ、図８Ｂの例では、ＣＰＵ利用率の予測値Ｘ（ｔ）が閾値Ｔｈ１を越えるため、マイグレーションを実施すると物理計算機１−Ｂ上の他の仮想計算機６０ないしは自仮想計算機ＶＭ−Ｂｘに高負荷が生じることが分かるため、仮想計算機ＶＭ−Ａ１のマイグレーションをすべきでないと判定できる。また、筐体８−Ｂ以外で同様の閾値Ｔｈ１を越える予測値が生じた場合には、同様に「マイグレーションすべきでない」と判定することができる。また、入出力部２４からコンソール７に出力したデータによって、コンソール７の利用者に判定を促す方法も考えられる。

さらに、移動元となる筐体８−Ａのプロセッサ１００の利用率について考えると、筐体８−Ａの物理計算機１−Ａの全体負荷（元のリソース使用率を積み上げることで算出可能）に対して、
（１）移動元の仮想計算機ＶＭ−Ａ１の負荷を引く（図４）
（２）移動元のＶＭ−Ａ１が発行したＩ／Ｏ処理の負荷を全て引く（図５Ａの＃１ａ， ＃３ａ〜＃９ａ）
（３）移動元の仮想計算機ＶＭ−Ａ１が発行した処理負荷のうち、移動元のＶＭ−Ａ１に対するＩ／Ｏ処理が発生するものについては、移動後のＩ／Ｏ処理が行われた場合の負荷に置き換えた予測負荷を加える。この処理は当該仮想計算機ＶＭ−Ａ１を移動する側の処理となるため、図５Ｂに示した＃１ｂ，＃４ｂ，＃８ｂを上述と同様に負荷を置き換えたものを用いる。

以上より、移動先の物理計算機１−Ｂと同様の処理を実現できる。さらに、筐体８−Ｃについても同様に、外部からの通信に対する負荷をリソース変換表２２０でリソース使用率を置換することで、仮想計算機ＶＭ−Ａ１のマイグレーションした後の負荷を見積もることができる。

このように、各物理計算機１の各仮想計算機６０を所定の測定期間で実行してリソース使用表６１０Ａ〜６１０Ｃを各サーバ仮想化部６で生成する。管理計算機２では、これらのリソース使用表６１０Ａ〜６１０Ｃから、リソース変換表２２０を生成し、同一の物理計算機１上の仮想計算機間の通信コストと、他の物理計算機１間の通信コストをそれぞれ求める。

そして、物理計算機１−Ａの負荷測定で生成したＩ／Ｏ処理のリソース使用表６１０Ｂから、移動対象の仮想計算機ＶＭ−Ａ１が送信元識別子または送信先識別子となっているエントリを抽出する。そして、リソース使用状況管理部２１は抽出したエントリの送信元識別子と送信先識別子を移動先の物理計算機１−Ｂ上の仮想計算機ＶＭ−Ｂｘに置き換える。この置き換え後のシミュレーション表６１０Ｂ−２ｓでＣＰＵ利用率６１５ＢとＣＮＡ利用率６１６Ｂをリソース変換表２２０を用いて演算する。

このシミュレーション表６１０Ｂ−２ｓと物理計算機１−Ｂのリソース使用表６１０Ａ、６１０Ｂ、６１０ＣのＣＰＵ利用率、ＣＮＡ利用率を併せることで、仮想計算機ＶＭ−Ａ１を移動後の物理計算機１−Ｂの負荷を正確に推定することができる。これにより、サービスを提供している他の仮想計算機に影響を与えることなく、移動対象の仮想計算機ＶＭ−Ａ１を移動先の物理計算機１−Ｂ上で実行可能か否かを判定することができる。

なお、上記では、筐体８全体に対する負荷について監視対象としたが、必要に応じて仮想計算機６０も監視対象としてもよい。

また、上記図９Ａでは、同一時間における負荷でマイグレーション後の物理計算機１−Ｂの負荷を見積もったが、例えば、変動する負荷が異なるタイミングで発生する可能性に鑑みて、発生しうる最大負荷量を、移動先の物理計算機１−Ｂで過去に生じた負荷履歴に積み上げることで、図８Ａ等で示したように閾値Ｔｈ１を越えるか否かを判定してもよい。これにより、負荷発生のタイミングがずれている場合にも、マイグレーションすべきか否かの検証をすることが可能となる。
なお、上記図８Ａ、図８Ｂでは、同一時間における負荷量で見積もった例を示したが、例えば、変動する負荷量が違うタイミングで発生する可能性に鑑みて、発生しうる最大負荷量を、移動先で過去に生じた負荷履歴に積み上げることで、閾値を越えるか判断してもよい。これによって、タイミングがずれて負荷が生じた場合についても、検証することが可能となる。

＜第２実施形態＞

図１０は、本発明の第２の実施形態を示し、仮想計算機システムのブロック図である。図１０では、ダミーの仮想計算機を物理計算機１−Ｂで実行して、前記第１実施形態と同様に、仮想計算機ＶＭ−Ａ１のマイグレーション先となる物理計算機１−Ｂに負荷をかける例を示す。その他の構成は、前記第１実施形態と同様である。

前記第１実施形態においては、負荷検証部２２によってマイグレーションを実施した後の負荷の推定値Ｘ（ｔ）を求めて、推定値が閾値Ｔｈ１を超えるとマイグレーションを実施不可能と判定する例を示した。

本第２実施形態では、閾値Ｔｈ１に加えて、マイグレーションを確実に実施可能な閾値Ｔｈ２を設定し、閾値Ｔｈ２を越えない場合はマイグレーション可能と判定するとともに閾値Ｔｈ１を越えた場合には不可能と判定する。なお、閾値Ｔｈ１は、例えばＣＰＵ利用率＝９０％等に設定され、閾値Ｔｈ２は、例えばＣＰＵ利用率＝１０％等に設定され、物理計算機１のプロセッサ１００の利用率が閾値Ｔｈ２以下であれば、物理計算機１−Ａの確実に仮想計算機ＶＭ−Ａ１のマイグレーションを行うことができる、と判定できる。

一方、閾値Ｔｈ１＞推定値Ｘ（ｔ）＞閾値Ｔｈ２となるような負荷の場合には、移動先の物理計算機１−Ｂ上にダミーの仮想計算機６０（以下、ダミーＶＭ−Ｄ１、ダミーＶＭ−Ｄ２とする）及び、移動元の仮想計算機ＶＭ−Ａ１及び移動先の物理計算機１−Ｂとは異なる物理計算機１−Ｃ上にダミーの仮想計算機６０−２（ダミーＶＭ−Ｃ２）を実行させる。あるいは、ダミーのアプリケーションＡＰ−Ｄ３を管理計算機２で実行させる。そして、それぞれのダミーＶＭあるいはアプリケーションＡＰ−Ｄ３が以下のような処理を行うことで、実際に筐体８−Ｂの物理計算機１−Ｂに負荷を掛ける。なお、負荷をかけるためのアプリケーションＡＰ−Ｄ３は、物理計算機１−Ｃ上の仮想計算機６０で実行しても良い。

このため、前記第１実施形態の図９Ａの処理で、各物理計算機１−Ａ〜１−Ｃのリソース使用表６１０Ａ〜６１０−Ｃを生成して、管理計算機２のリソース使用状況管理部２１の全リソース使用表２１０に格納した後に、本第２実施形態を実行することを前提とする。つまり、移動元の仮想計算機ＶＭ−Ａ１のＣＰＵ利用率とＩ／Ｏ処理の送信元と送信先及びデータサイズを、実際の処理の履歴として保持し、本第２実施形態で再生する。

物理計算機１−Ｂには、サーバ運用管理プログラム２０の指令によってサーバ仮想化部６−Ｂが、図２に示したリソースプール（または余剰リソース）にダミーＶＭ−Ｄ１、ダミーＶＭ−Ｄ２を生成する。図１１は、物理計算機１−ＢのダミーＶＭ−Ｄ１及びダミーＶＭ−Ｄ２の詳細を示すブロック図である。

ダミーＶＭ−Ｄ１とダミーＶＭ−Ｄ２は、図１１で示すように、物理計算機１−Ｂに負荷をかけるダミーのアプリケーションＡＰ−Ｄ１とＡＰ−Ｄ２をそれぞれ実行する。ダミーのアプリケーションＡＰ−Ｄ１とＡＰ−Ｄ２は、負荷の履歴を再現するためのリソース使用再生表５０と、リソース使用再生表５０を生成する負荷再生部５１をそれぞれ有する。負荷再生部５１は、リソース使用表変換部５１１と、ＣＰＵ負荷再生部５１２と、Ｉ／Ｏ処理再生部５１３から構成される。

負荷再生部５１のリソース使用量変換部５１１は、リソース使用表６１０Ａ〜６１０Ｃをサーバ仮想化部６−Ｂまたは管理計算機２のリソース使用状況管理部２１の全リソース使用表２１０から、移動元の仮想計算機ＶＭ−Ａ１のＩ／Ｏ処理を含むリソース使用表を取得する。リソース使用量変換部５１１は、仮想計算機ＶＭ−Ａ１が送信元となるＩ／Ｏ処理をリソース使用表から抽出し、発行先及び発行元の情報を変換し、リソース使用再生表５０として保持する。

各ダミーアプリケーションＡＰ−Ｄ１、ＡＰ−Ｄ２のリソース使用再生表５０は、リソース使用量変換部５１１によって変換生成される表である。リソース使用再生表５０の内容に基づいて、ＣＰＵ負荷再生部５１２及びＩ／Ｏ処理再生部５１３の送信処理を実行する。

負荷再生部５１を構成するＣＰＵ負荷再生部５１２は、リソース使用再生表５０に記載されるＣＰＵ負荷を生成する。生成方法はどのような形であってもよく、例えば、ループ演算を実行するなどの単純な方法でもよい。

負荷再生部５１を構成するＩ／Ｏ処理再生部５１３は、リソース使用再生表５０に基づいて、送信先に指定されたダミーＶＭ−Ｄ２またはダミーアプリケーションＡＰ−Ｄ３あるいはＤｉｓｋ（ストレージ装置）装置４などに定められたデータサイズのＩ／Ｏ処理を行う。データの内容については、ダミーデータであってもよい。一方、他のダミーＶＭが再生したＩ／Ｏ処理を受信する必要がある場合には、Ｉ／Ｏ処理再生部５１３で受信処理を実施することも含む。

次に、ダミーＶＭ−Ｄ１で実行されるダミーアプリケーションＡＰ−Ｄ１は、移動元の仮想計算機ＶＭ−Ａ１に相当する負荷を生成する。負荷の発生には、移動元のサーバ仮想化部６−Ａのリソース監視部６１、あるいは管理計算機２の全リソース使用表２１０からリソース使用表６１０Ａ〜６１０Ｃを取得し、Ｉ／Ｏ処理のリソース使用表６１０Ｂに基づいてダミーアプリケーションＡＰ−Ｄ１がＩ／Ｏ処理に関する負荷を発生する。

ダミーアプリケーションＡＰ−Ｄ１の負荷再生部５１が利用するのは、前記第１実施形態の図９Ａの処理で生成した図４に示した物理計算機１−Ａ（筐体８−Ａ）で仮想計算機ＶＭ−Ａ１が使用したＣＰＵ利用率６１３Ａを含むリソース使用表６１０Ａと、図５Ａのリソース使用表６１０Ｂのうち仮想計算機ＶＭ−Ａ１が発行したＩ／Ｏ処理のデータ（こちらはリソース使用のデータは利用しない）である。

ダミーアプリケーションＡＰ−Ｄ１では、図４に示したリソース使用表６１０ＡのＣＰＵ利用率６１３Ａと同様の負荷を図４のｔｉｍｅ６１２Ａと同様のタイミングで発生させる。そして、ダミーアプリケーションＡＰ−Ｄ１のＩ／Ｏ処理については、図１２Ａに示すように、移動元の仮想計算機ＶＭ−Ａ１が送信元となるＩ／Ｏ処理の通信先とデータサイズを上記取得したリソース使用表６１０Ｂから抽出し、リソース使用再生表５０として保持する。

図１２Ａは、物理計算機１−Ａのリソース使用表６１０Ｂから仮想計算機ＶＭ−Ａ１のＩ／Ｏ処理をダミーアプリケーションＡＰ−Ｄ１の負荷再生部５１が抽出したダミーＶＭ−Ｄ１のリソース使用再生表５０の一例を示す図である。リソース使用再生表５０は、時刻を格納するｔｉｍｅ５０１と、送信元の仮想計算機６０の識別子を格納する送信元識別子５０２と、送信先の仮想計算機６０または装置の識別子を格納する送信先識別子５０３と、データサイズ５０４から構成される。前記第１実施形態のＣＰＵ利用率やＣＮＡ利用率は、リソース使用表６１０Ｂから読み込まない。

物理計算機１−ＢのダミーＶＭ−Ｄ１で実行されるダミーアプリケーションＡＰ−Ｄ１のリソース使用表変換部５１１が、図９Ａの処理で測定された物理計算機１−ＡのＣＰＵ利用率とＩ／Ｏ処理についてリソース使用表６１０Ａ、６１０Ｂを取得する。ダミーアプリケーションＡＰ−Ｄ１の負荷再生部５１では、仮想計算機ＶＭ−Ａ１に関するＣＰＵ利用率のリソース使用表６１０Ａについてはそのままリソース使用再生表５０に格納する。

ダミーアプリケーションＡＰ−Ｄ１の負荷再生部５１では、Ｉ／Ｏ処理のリソース使用表６１０Ｂから送信元識別子が移動対象の仮想計算機ＶＭ−Ａ１のエントリを抽出してリソース使用再生表５０として保持する。このとき、ダミーアプリケーションＡＰ−Ｄ１は、図１２Ａで示したリソース使用再生表５０の送信元識別子５０２をダミーＶＭ−Ｄ１に変換し、送信先識別子５０３の仮想計算機ＶＭ−Ｂｘに関する送信先をダミーＶＭ−Ｄ２に変換する。ダミーアプリケーションＡＰ−Ｄ１は、図１２Ａで示した送信先識別子５０３の仮想計算機ＶＭ−Ｃｘに関する送信先をダミーＶＭ−Ｃ２に変換する。

つまり、負荷再生部５１のリソース使用表変換部５１１では、移動対象の仮想計算機ＶＭ−Ａ１を物理計算機１−Ｂへ移動させたときに、筐体８−ＡのＶＭ−Ａ１と、８−Ｂ間の通信を筐体８−Ｂ内の通信に変換し、筐体８−Ａの他のＶＭ−Ａｘと、移動対象の仮想計算機ＶＭ−Ａ１間の通信を、筐体８−Ｂ、８−Ｃ間の筐体外通信に変換する。なお、変換の結果は、Ｉ／Ｏ処理のリソース使用再生表５０を更新しても良いし、識別子を読み替えるように設定してもよい。

そして、ダミーアプリケーションＡＰ−Ｄ１では、Ｉ／Ｏ処理再生部５１３が、図１２Ａのｔｉｍｅ５０１のタイミングに基づいてＩ／Ｏ処理を再生する。ここで、Ｉ／Ｏ処理再生部５１３がＩ／Ｏ処理を実施（再生）する場合には、同一筐体（筐体８−Ｂ）内の仮想計算機６０に対するＩ／Ｏ処理については、ダミーＶＭ−Ｄ２に対してＩ／Ｏ処理を実施し、筐体外の仮想計算機６０に対するＩ／Ｏ処理については、物理計算機１−ＣのダミーＶＭ−Ｃ２または管理計算機２のダミーアプリケーションＡＰ−Ｄ３に対して実施する。さらに、Ｉ／Ｏ処理再生部５１３がリソース使用再生表５０に基づいて再生するＩ／Ｏ処理が、Ｄｉｓｋ（ストレージ装置４またはローカルストレージ装置１２０）への処理である場合には、同一Ｄｉｓｋ装置に対して処理を行う。このＩ／Ｏ処理は、仮想計算機ＶＭ−Ａ１が保存したデータを破壊しないように実施する。一例をあげれば、Ｄｉｓｋ装置（ストレージ装置４またはローカルストレージ装置１２０）に対するＩ／Ｏ処理の再生がリードであればＤｉｓｋ装置のデータを直接読み込むなどしてもよいし、あるいはダミーデータを読み込んでもよい。一方で、Ｄｉｓｋ装置に対するＩ／Ｏ処理の再生がライトであれば、本来書くべきデータとは異なる場所に、すなわち予め設定したダミーの領域へデータを書き込むことでデータの上書きなどによる破壊を防ぐ。また、外部の仮想計算機からダミーＶＭ−Ｄ１に対するＩＯ処理については、データ受信を行う。

ダミーＶＭ−Ｄ２では、物理計算機１−ＡのＩ／Ｏ処理のリソース使用表６１０Ｂのうち、送信元識別子が物理計算機１−Ｂの仮想計算機ＶＭ−Ｂｘを抽出してリソース使用再生表５０として保持する。図１２Ｂは、物理計算機１−Ａのリソース使用表６１０Ｂから仮想計算機ＶＭ−Ｂｘが送信元のＩ／Ｏ処理を抽出したダミーＶＭ−Ｄ２のリソース使用再生表５０の一例を示す図である。

ダミーＶＭ−Ｄ２のＩ／Ｏ処理再生部５１３では、リソース使用再生表５０のｔｉｍｅ５０１のタイミングで、図中仮想計算機ＶＭ−Ｂ２に代わって４ｋＢのデータをダミーＶＭ−Ｄ１へ送信するＩ／Ｏ処理を再生する。

物理計算機１−ＣのダミーＶＭ−Ｃ２も、上記物理計算機１−ＢのダミーＶＭ−Ｄ１と同様に構成される。ダミーＶＭ−Ｃ２では、物理計算機１−ＡのＩ／Ｏ処理のリソース使用表６１０Ｂのうち、送信元識別子が物理計算機１−Ａの移動元の仮想計算機ＶＭ−Ａ１以外の仮想計算機ＶＭ−Ａｘを抽出してリソース使用再生表５０として保持する。図１２Ｃは、物理計算機１−Ａのリソース使用表６１０Ｂから仮想計算機ＶＭ−Ａｘが送信元のＩ／Ｏ処理を抽出したダミーＶＭ−Ｃ２のリソース使用再生表５０の一例を示す図である。

ダミーＶＭ−Ｃ２のＩ／Ｏ処理再生部５１３では、リソース使用再生表５０のｔｉｍｅ５０１のタイミングで、図１２Ｃの仮想計算機ＶＭ−Ａ４に代わって５１２ｋＢのデータをダミーＶＭ−Ｄ１へ送信するＩ／Ｏ処理を再生する。

次に、管理計算機２では、物理計算機１−ＢのダミーＶＭ−Ｄ１でリソース使用の再生を開始すると次の処理を実行する。

管理計算機２のリソース使用状況管理部２１では、上記のダミーＶＭ−Ｄ１、ダミーＶＭ−Ｄ２が、仮想計算機ＶＭ−Ａ１を物理計算機１−Ｂへ移動した後の負荷を再生している間の、負荷量（リソースの使用率）を監視する。また、リソース使用状況管理部２１は、物理計算機１−Ｂのリソースの使用率の監視の結果について、入出力部２４及びコンソール７を介してユーザにリソースの使用率などを提示する。

管理計算機２の負荷検証部２２は、上記物理計算機１−Ｂのリソース使用率の監視中に高負荷状態を示す閾値Ｔｈ１を越えるかどうかを判定する。高負荷状態を示す閾値Ｔｈ１を越えた場合には、ダミーＶＭ−Ｄ１、ＶＭ−Ｄ２、ＶＭ−Ｃ２の処理を速やかに停止する。

以上により、仮想計算機ＶＭ−Ａ１の移動先の物理計算機１−ＢでダミーＶＭ−Ｄ１、ＶＭ−Ｄ２を実行することで、物理計算機１−Ｂ上の他のＶＭ（ＶＭ−Ｂ１）の提供する処理（サービス）に影響がでることを防ぐ。

なお、ダミーＶＭ−Ｄ１で行われるＣＰＵ負荷の発生については、上述したダミーＶＭ−Ｄ１のダミーアプリケーションＡＰ−Ｄ１として負荷を発生させる以外に、サーバ仮想化部６−Ｂの仮想化管理部に依頼して、リソース割当（スケジューリング）をダミーＶＭ−Ｄ１に対して割当てるような方法で実現してもよい。

図１３は、本第２実施形態の処理の流れを示すフローチャートである。このフローチャートは、前記第１実施形態の図９Ａの処理が完了した後に、管理計算機２のサーバ運用管理プログラム２０と、仮想計算機ＶＭ−Ａ１の移動先の物理計算機１−Ｂ上の仮想計算機６０で行われる処理を示す。

まず、ステップＳ２０では、管理計算機２の負荷検証部２２が、移動先の物理計算機１−ＢのＣＰＵ利用率が、上述した閾値Ｔｈ１以下で、かつ閾値Ｔｈ２以上であれば本処理を開始する。なお、物理計算機１−Ａの仮想計算機ＶＭ−Ａ１を物理計算機１−Ｂ上へマイグレーションする予定が生じたときに、予測される負荷（ＣＰＵ利用率）にかかわらず本処理を開始することもできる。

ステップＳ２１では、管理計算機２の負荷検証部２２が、仮想計算機ＶＭ−Ａ１の移動先として選択された物理計算機１−Ｂ上のサーバ仮想化部６−Ｂに対して、ダミーＶＭ−Ｄ１、ダミーＶＭ−Ｄ２の生成と、ダミーアプリケーションＡＰ−Ｄ１、ＡＰ−Ｄ２の起動を指令する。

ステップＳ２２では、負荷検証部２２が、管理計算機２でダミーアプリケーションＡＰ−Ｄ３を起動する。また、負荷検証部２２は、物理計算機１−Ｃ上のサーバ仮想化部６−Ｃに対して、ダミーＶＭ−Ｃ２の生成と、ダミーアプリケーションＡＰ−Ｃ２の起動を指令する。

ステップＳ２３では、負荷検証部２２がサーバ仮想化部６−Ｂ、６−ＣにダミーＶＭ−Ｄ１、Ｄ２、Ｃ２とダミーアプリケーションＡＰ−Ｄ１、Ｄ２、Ｃ２、Ｄ３の起動が完了したかを問い合わせる。ダミーアプリケーションＡＰ−Ｄ１、Ｄ２、Ｃ２、Ｄ３の起動が完了すると、ステップＳ２４の処理へ進む。

ステップＳ２４では、管理計算機２のリソース使用状況管理部２１が、サーバ仮想化部６−Ｂのリソース監視部６１から物理計算機１−ＢのＣＰＵ利用率を取得し、負荷検証部２２が取得したＣＰＵ利用率を監視する。

ステップＳ２５では、負荷検証部２２が監視している物理計算機１−ＢのＣＰＵ利用率が高負荷を示す閾値Ｔｈ１を超えたか否かを判定する。ＣＰＵ利用率が高負荷を示す閾値Ｔｈ１を超えた場合には、ステップＳ２７へ進み、閾値Ｔｈ１以下の場合にはステップＳ２６へ進む。

ステップＳ２７では、負荷検証部２２が物理計算機１−Ｂ上のサーバ仮想化部６−Ｂに対してダミーＶＭ−Ｄ１及びダミーＶＭ−Ｄ２を停止させる。また、負荷検証部２２は、サーバ仮想化部６−Ｃに対してもダミーＶＭ−Ｃ２の停止を指令する。また、負荷検証部２２は、管理計算機２のダミーアプリケーションＡＰ−Ｄ３を停止する。その後、管理計算機２は処理を終了する。

一方、ステップＳ２６では、負荷検証部２２が全てのダミーＶＭ−Ｄ１、ＶＭ−Ｄ２，ＶＭ−Ｃ２から処理の完了通知を受信して、全ての再生処理が完了したか否かを判定する。全ての再生処理が完了するまで、ステップＳ２５の判定処理を繰り返す。そして、負荷検証部２２は、全てのダミーＶＭ−Ｄ１、ＶＭ−Ｄ２，ＶＭ−Ｃ２から処理の完了通知を受信するとステップＳ２８へ進んで、物理計算機１−Ｂの監視を終了する。監視の終了に際して、負荷検証部２２はリソース使用状況管理部２１が取得した仮想計算機ＶＭ−Ａ１の移動先となる物理計算機１−Ｂのプロセッサ１００のＣＰＵ利用率の履歴を、入出力部２４を介してコンソール７へ出力しても良い。

ステップＳ２９では、負荷検証部２２はサーバ仮想化部６−Ｂ、６−Ｃに対してダミーＶＭ−Ｄ１、ＶＭ−Ｄ２、ＶＭ−Ｃ２の停止と削除を通知する。また、負荷検証部２２は管理計算機２のダミーアプリケーションＡＰ−Ｄ３を停止させてから、処理を終了する。

一方、管理計算機２の負荷検証部２２の指令によって生成されたダミーＶＭ−Ｄ１の処理はステップＳ３１〜Ｓ３８のようになる。ダミーアプリケーションＡＰ−Ｄ１、ＡＰ−Ｄ２、ＡＰ−Ｃ２は何れも同様の処理を行う。このため、ダミーアプリケーションＡＰ−Ｄ１の説明のみを行い、他のダミーアプリケーションＡＰ−Ｄ１、Ｃ２の説明を省略する。

まず、ステップＳ３１では、物理計算機１−ＢのダミーＶＭ−Ｄ１で実行されるダミーアプリケーションＡＰ−Ｄ１のリソース使用表変換部５１１が、図９Ａの処理で物理計算機１−ＡのＣＰＵ利用率とＩ／Ｏ処理についてリソース使用表６１０Ａ、６１０Ｂを取得する。ダミーアプリケーションＡＰ−Ｄ１の負荷再生部５１では、仮想計算機ＶＭ−Ａ１に関するＣＰＵ利用率のリソース使用表６１０Ａについてはそのままリソース使用再生表５０に格納する。

ステップＳ３２では、ダミーアプリケーションＡＰ−Ｄ１が、Ｉ／Ｏ処理のリソース使用表６１０Ｂから送信元識別子が移動対象の仮想計算機ＶＭ−Ａ１のエントリを抽出してリソース使用再生表５０として保持する。このとき、ダミーアプリケーションＡＰ−Ｄ１は、図１２Ａで示したリソース使用再生表５０の送信元識別子５０２をダミーＶＭ−Ｄ１に変換し、送信先識別子５０３の仮想計算機ＶＭ−Ｂｘに関する送信先をダミーＶＭ−Ｄ２に変換する。ダミーアプリケーションＡＰ−Ｄ１は、図１２Ａで示した送信先識別子５０３の仮想計算機ＶＭ−Ｃｘに関する送信先をダミーＶＭ−Ｃ２に変換する。

そして、ステップＳ３３では、上記送信元識別子５０２と送信先識別子５０３を変換した表を、リソース使用再生表５０として格納する。

次に、ステップＳ３４では、リソース使用再生表５０の格納が完了して再生の準備が完了すると、管理計算機２の負荷検証部２２へ起動が完了した通知を送信する。そして、ダミーアプリケーションＡＰ−Ｄ１は、ステップＳ３５に進んで、リソース使用再生表５０を再生して、ダミーアプリケーションＡＰ−Ｄ１、ＡＰ−Ｄ２で仮想計算機ＶＭ−Ａ１を物理計算機１−Ｂで実行した状況を再生する。ステップＳ３５では、負荷再生部５１のＣＰＵ負荷再生部５１２が、リソース使用再生表５０に格納した仮想計算機ＶＭ−Ａ１のＣＰＵ利用率を再生し、負荷再生部５１のＩ／Ｏ処理再生部５１３が、リソース使用再生表５０に格納した仮想計算機ＶＭ−Ａ１のＩ／Ｏ処理を再生する。この再生の期間中、物理計算機１−Ｂのリソース監視部６１が、管理計算機２のリソース使用状況管理部２１へプロセッサ１００のＣＰＵ利用率を通知する。

ステップＳ３６では、管理計算機２の負荷検証部２２からダミーアプリケーションＡＰ−Ｄ１の停止の指令を受信したか否かを判定する。ダミーアプリケーションＡＰ−Ｄ１は、管理計算機２から停止の指令を受信した場合には、処理を終了する。

一方、管理計算機２から停止の指令を受信していない場合は、ステップＳ３７で負荷再生部５１がリソース使用再生表５０の再生を完了したか否かを判定する。ステップＳ３７の判定で、再生が完了していなければステップＳ３５へ戻って再生処理を繰り返す。一方、ダミーアプリケーションＡＰ−Ｄ１は、リソース使用再生表５０の全てについて負荷の再生処理が完了すると、ステップＳ３８へ進んで再生処理の完了を管理計算機２へ通知する。

以上の処理により、物理計算機１−Ｂでは、移動対象の物理計算機１−Ａの仮想計算機ＶＭ−Ａ１を移動させた後と同様の負荷とリソース使用率をダミーＶＭ−Ｄ１及びダミーアプリケーションＡＰ−Ｄ１により発生させる。ダミーＶＭ−Ｄ１上のダミーアプリケーションＡＰ−Ｄ１は、物理計算機１−Ａで測定したＣＰＵ利用率と、Ｉ／Ｏ処理を物理計算機１−Ｂ上で再生する。この再生期間中、管理計算機２の負荷検証部２２が物理計算機１−ＢのＣＰＵ利用率を監視して、ＣＰＵ利用率が閾値Ｔｈ１を超えると即座にダミーアプリケーションＡＰ−Ｄ１、ＡＰ−Ｄ２を停止させて、物理計算機１−Ｂ上の他の仮想計算機ＶＭ−Ｂｘに影響を与えるのを防ぐことができる。

また、ダミーアプリケーションＡＰ−Ｄ１の負荷再生部５１では、物理計算機１−Ａの負荷測定で生成したＩ／Ｏ処理のリソース使用表６１０Ｂから、移動対象の仮想計算機ＶＭ−Ａ１が送信元識別子となっているエントリを抽出する。そして、負荷再生部５１は抽出したエントリの送信元識別子と送信先識別子をダミーＶＭ−Ｄ１、ＶＭ−Ｄ２、ＶＭ−Ｃ２に置き換えることで、サービスを提供している他の仮想計算機に影響を与えることなく、移動対象の仮想計算機ＶＭ−Ａ１を実行可能か否かを判定することができる。

なお、上記ではＣＰＵ利用率について述べたが、物理Ｉ／Ｏデバイス１３０ＢとしてのＣＮＡの利用率について適用することができる。

図１４は、上記第２の実施形態における物理計算機１−Ｂの負荷の再生をコンソール７のディスプレイに表示した画面イメージである。

図１４で、点線はダミーＶＭ−Ｄ１を用いて負荷の再生を検証した負荷データである。また、図１４で実践は、ダミーＶＭ−Ｄ１、Ｄ２を稼動させていないときの負荷を示す。図中時刻ｔ３では、物理計算機１−ＢのＣＰＵ利用率が閾値Ｔｈ１を超えるため、ダミーＶＭ−Ｄ１のダミーアプリケーションＡＰ−Ｄ１が停止されたことを示す。

図１５は、上記第２の実施形態における物理計算機１−Ｂの負荷の再生を徐々に行う世にした場合にコンソール７のディスプレイに表示した画面イメージである。

ダミーアプリケーションＡＰ−Ｄ１で負荷の再生処理を行う場合に、ＣＰＵ負荷再生と、Ｉ／Ｏ処理の再生をリソース使用再生表５０のまま行うのではなく、一定の割合ずつ段階的に再生する。

移動元の仮想計算機ＶＭ−Ａ１を物理計算機１−Ｂへ移動することで生じる負荷の予測値が、閾値Ｔｈ１の近傍であるような場合は、実際にシミュレーション（再生）したことで同一筐体８−Ｂ内の仮想計算機６０の負荷が高負荷状態となりサービス停止を招く可能性が高い。そのため、段階的に負荷をかけることで、各仮想計算機ＶＭ−ＢｘとＶＭ−Ｄ１の挙動を確認しながら再生を実施することができる。

物理計算機１−Ｂへ段階的に負荷をかける一例としては、リソース使用再生表５０の処理量（ＣＰＵ利用率）に一定の割合を乗算して行う方法がある。そのほかに、測定したリソース使用表６１０Ａ、６１０Ｂでもっとも高いＣＰＵ利用率及び、最も大きいＩ／Ｏ処理量に一定割合を乗じた負荷（均一な負荷）を実施することが考えられる。これらはどれであってもよい。

また、上記各実施形態では、物理計算機１のリソースの使用量として、ＣＰＵ利用率やＣＮＡ利用率を用いる例を示したが、物理計算機１の負荷を示す値をリソースの使用量として用いることができる。物理計算機１の負荷を示す値としては、動作クロックや動作電圧を動的に変更可能なプロセッサ１００を用いた物理計算機１では、動作クロックや動作電圧を物理計算機１の負荷を示す値として用いることができる。あるいは、動作するコアを動的に変更可能なマルチコアのプロセッサ１００を用いた物理計算機１では、動作するコアの数や、休止または停止するコアの数を物理計算機１の負荷を示す値として用いることができる。

本発明は、仮想計算機でサービスを提供し、仮想計算機のマイグレーションを行う仮想計算機システムに適用することができ、特に、複数の物理計算機で複数の仮想マシンを割り当てる管理計算機に適用することができる。

Claims (12)

1. プロセッサとメモリをそれぞれ備えた複数の物理計算機と、前記物理計算機で実行されて計算機資源を１つ以上の仮想計算機に割り当てる仮想化部と、前記仮想化部を管理して前記仮想計算機を物理計算機間で移動させる管理計算機と、を備えた仮想計算機システムで、前記管理計算機が前記仮想計算機を移動させる物理計算機の評価を行う仮想計算機のマイグレーション評価方法であって、
   前記管理計算機が、複数の仮想計算機から移動対象の第１の仮想計算機を選択し、当該第１の仮想計算機が稼動する第１の物理計算機から当該第１の仮想計算機を移動させる第２の物理計算機を選択する第１のステップと、
   前記管理計算機が、前記仮想計算機を稼働させて前記物理計算機で使用された計算器資源を測定し、前記第１の仮想計算機の通信先を第１の通信先として特定する第２のステップと、
   前記管理計算機が、前記特定された第１の仮想計算機の第１の通信先を、前記移動先の第２の物理計算機上での通信先に変換して第２の通信先として設定する第３のステップと、
   前記管理計算機が、前記第１の仮想計算機を前記第２の物理計算機で稼動させた場合に、前記第１の仮想計算機が前記第２の通信先と通信を行うときに当該第２の物理計算機で使用される計算器資源を演算する第４のステップと、
   を含むことを特徴とする仮想計算機のマイグレーション評価方法。
2. 請求項１に記載の仮想計算機のマイグレーション評価方法であって、
   前記第４のステップは、
   前記仮想計算機を稼働させて前記物理計算機で使用された計算器資源と前記第１の通信先から、前記各物理計算機内の通信コストと前記各物理計算機間の通信コストを演算する第５のステップと、
   前記演算された前記各物理計算機内の通信コストと前記各物理計算機間の通信コストから、前記第２の物理計算機で前記第１の仮想計算機が通信する前記第２の通信先への通信コストを演算し、当該通信コストから第２の物理計算機で使用される計算器資源の量を演算する第６のステップと、
   を含むことを特徴とする仮想計算機のマイグレーション評価方法。
3. 請求項１に記載の仮想計算機のマイグレーション評価方法であって、
   前記第４のステップは、
   前記仮想計算機を稼働させて前記物理計算機で使用された計算器資源から第１の仮想計算機が利用する第１の計算器資源を取得し、前記第２の通信先として前記第２の物理計算機と第３の物理計算機を設定する第７のステップと、
   前記第２の物理計算機で、前記第１の計算器資源を使用する第１のダミーの仮想計算機を稼動させる第８のステップと、
   前記第２の物理計算機で、前記第１のダミーの仮想計算機と通信する第２のダミーの仮想計算機を稼動させる第９のステップと、
   前記第３の物理計算機で、前記第１のダミーの仮想計算機と通信する第３のダミーの仮想計算機を稼動させる第１０のステップと、
   前記第２の物理計算機で使用される計算機資源の量を演算する第１１のステップと、
   を含むことを特徴とする仮想計算機のマイグレーション評価方法。
4. 請求項２に記載の仮想計算機のマイグレーション評価方法であって、
   前記管理計算機が、前記第６のステップで演算された第２の物理計算機で使用される計算器資源の量と所定の閾値を比較して、第２の物理計算機で使用される計算器資源の量が閾値以下であれば前記第１の仮想計算機のマイグレーション先として第２の物理計算機が適切であると判定する第１２のステップを、さらに含むことを特徴とする仮想計算機のマイグレーション評価方法。
5. 請求項３に記載の仮想計算機のマイグレーション評価方法であって、
   前記管理計算機が、前記第１２のステップで演算された第２の物理計算機で使用される計算器資源の量と所定の閾値を比較して、第２の物理計算機で使用される計算器資源の量が閾値を超えたときに、前記第１のダミーの仮想計算機及び第２のダミーの仮想計算機を停止させる第１３のステップを、さらに含むことを特徴とする仮想計算機のマイグレーション評価方法。
6. 請求項１に記載の仮想計算機のマイグレーション評価方法であって、
   前記物理計算機は、他の物理計算機と通信を行うＩ／Ｏデバイスを備え、
   前記仮想化部は、前記第１の仮想計算機が他の物理計算機の仮想計算機と通信を行うときにのみ前記Ｉ／Ｏデバイスを介して通信を行うことを特徴とする仮想計算機のマイグレーション評価方法。
7. プロセッサとメモリをそれぞれ備えた複数の物理計算機と、
   前記物理計算機で実行されて計算機資源を１つ以上の仮想計算機に割り当てる仮想化部と、
   前記仮想化部を管理して前記仮想計算機を物理計算機間で移動させる管理計算機と、を備えた仮想計算機システムであって、
   前記管理計算機は、
   前記複数の仮想計算機から移動対象の第１の仮想計算機を選択し、当該第１の仮想計算機が稼動する第１の物理計算機から当該第１の仮想計算機を移動させる第２の物理計算機を選択するマイグレーション制御部と、
   前記仮想計算機を稼働させて前記物理計算機で使用された計算器資源を測定し、前記第１の仮想計算機の通信先を第１の通信先として特定するリソース使用状況管理部と、を備え、
   前記リソース使用状況管理部は、
   前記特定された第１の仮想計算機の第１の通信先を、前記移動先の第２の物理計算機上での通信先に変換して第２の通信先として設定し、前記第１の仮想計算機を前記第２の物理計算機で稼動させた場合に、前記第１の仮想計算機が前記第２の通信先と通信を行うときに当該第２の物理計算機で使用される計算器資源を演算することを特徴とする仮想計算機システム。
8. 請求項７に記載の仮想計算機システムであって、
   前記リソース使用状況管理部は、
   前記仮想計算機を稼働させて前記物理計算機で使用された計算器資源と前記第１の通信先から、前記各物理計算機内の通信コストと前記各物理計算機間の通信コストを演算してリソース変換情報を設定し、前記リソース変換情報から、前記第２の物理計算機で前記第１の仮想計算機が通信する前記第２の通信先への通信コストを演算し、当該通信コストから第２の物理計算機で使用される計算器資源の量を演算することを特徴とする仮想計算機システム。
9. 請求項７に記載の仮想計算機システムであって、
   前記管理計算機は、
   前記物理計算機にダミーの仮想計算機を実行させる負荷検証部をさらに有し、
   前記リソース使用状況管理部は、
   前記仮想計算機を稼働させて前記物理計算機で使用された計算器資源から第１の仮想計算機が利用する第１の計算器資源を取得し、前記第２の通信先として前記第２の物理計算機と第３の物理計算機を設定し、
   前記負荷検証部は、
   前記第２の物理計算機で、前記第１の計算器資源を使用する第１のダミーの仮想計算機を稼動させ、前記第２の物理計算機で、前記第１のダミーの仮想計算機と通信する第２のダミーの仮想計算機を稼動させ、前記第３の物理計算機で、前記第１のダミーの仮想計算機と通信する第３のダミーの仮想計算機を稼動させ、前記第２の物理計算機で使用される計算機資源の量を演算することを特徴とする仮想計算機システム。
10. 請求項８に記載の仮想計算機システムであって、
    前記管理計算機は、
    前記リソース使用状況管理部が演算した第２の物理計算機で使用される計算器資源の量と所定の閾値を比較して、第２の物理計算機で使用される計算器資源の量が閾値以下であれば前記第１の仮想計算機のマイグレーション先として第２の物理計算機が適切であると判定する負荷検証部をさらに有することを特徴とする仮想計算機システム。
11. 請求項９に記載の仮想計算機システムであって、
    前記負荷検証部は、
    前記第２の物理計算機で使用される計算器資源の量と所定の閾値を比較して、第２の物理計算機で使用される計算器資源の量が閾値を超えたときに、前記第１のダミーの仮想計算機及び第２のダミーの仮想計算機を停止させることを特徴とする仮想計算機システム。
12. 請求項７に記載の仮想計算機システムであって、
    前記物理計算機は、他の物理計算機と通信を行うＩ／Ｏデバイスを備え、
    前記仮想化部は、前記第１の仮想計算機が他の物理計算機の仮想計算機と通信を行うときにのみ前記Ｉ／Ｏデバイスを介して通信を行うことを特徴とする仮想計算機システム。

Images