JP2010218151A - 仮想計算機管理機構及び仮想計算機システムにおけるｃｐｕ時間割り当て制御方法 - Google Patents

Abstract

【課題】複数のゲストＯＳのサーバ／クライアント関係を認識して、各ゲストＯＳにＣＰＵが割り当てられる時間を、その関係に基づいて調整することで、効率の向上を図る。
【解決手段】ＶＭＭ２０のゲストＯＳインターフェイス部２０１は、ゲストＯＳ３１０-0〜３１０-3のうちの任意のゲストＯＳがクライアントとして機能して、サーバとして機能する他のゲストＯＳに処理を要求する際に、処理の要求元のゲストＯＳがクライアントであり、処理の要求先のゲストＯＳがサーバであるサーバ／クライアント関係を、要求元のゲストＯＳからＶＭＭ２０に通知するのに用いられるインターフェイスを含む。ＶＭＭ２０のゲストＯＳスケジューラ２０５は、このインターフェイスによって通知されたサーバ／クライアント関係に基づいて、ゲストＯＳ３１０-0〜３１０-3にＣＰＵ１１０を割り当てる時間を調整する。
【選択図】 図２

Description

本発明は、複数の仮想計算機が動作する仮想計算機システムに係り、特に、同システムにおいて複数の仮想計算機で実行される複数のゲストＯＳにＣＰＵを時分割で割り当てるのに好適な仮想計算機管理機構及び仮想計算機システムにおけるＣＰＵ時間割り当て制御方法に関する。

古くから、メインフレームにおいてハードウェア（ＨＷ）による仮想計算機（Virtual Machine：ＶＭ）支援機構を使った仮想計算機システムが知られている。また、近年は、パーソナルコンピュータのような計算機においても仮想計算機の技術を応用した研究や開発が行われている。

典型的な仮想計算機システムでは、計算機（物理計算機）のハードウェア上に仮想計算機管理機構（Virtual Machine Manager/Monitor：ＶＭＭ）が存在する。物理計算機のハードウェアは、ＣＰＵ（実ＣＰＵ）、メモリ（実メモリ）、各種入出力装置（実入出力装置）等で構成されている。ＶＭＭは一般にソフトウェアモジュールを用いて構成される。ＶＭＭは、ハードウェアを直接管理し、それを仮想化して仮想計算機（仮想マシン）を構築する。仮想計算機は、仮想ＣＰＵ、仮想入出力（Ｉ／Ｏ）装置等から構成される。つまりＶＭＭは、仮想ＣＰＵ、仮想Ｉ／Ｏ装置のイメージを作り、実ＣＰＵや実Ｉ／Ｏ装置、実メモリ等のＨＷリソースを時間的、領域的に仮想ＣＰＵ、仮想Ｉ／Ｏ装置、仮想計算機のメモリとして割り当てる。このようにしてＶＭＭは仮想計算機を構築する。つまりＶＭＭは、仮想計算機（仮想的な計算機）が実行可能な仮想計算機実行環境を提供する。仮想計算機にはゲストＯＳと呼ばれるオペレーティングシステム（ＯＳ）がロードされる。このゲストＯＳは、仮想ＣＰＵ（つまり実ＣＰＵを割り当てることによって実現される仮想ＣＰＵ）により実行される。

このような仮想計算機システムでは、目的に合わせて複数のゲストＯＳを稼動させることができる。これは、通常の計算機システム（非仮想計算機システム）にはない、仮想計算機システムの利点である。

仮想計算機システムでは、複数のサーバ計算機で実行されていた複数のＯＳを、例えば特許文献１にも記載されているように、１つの物理計算機を用いて実現される仮想計算機システムの環境（仮想計算機環境）の中で、複数のゲストＯＳとして動作させることが可能になる。このため、複数のＯＳを実行させるのに必要な物理計算機（実計算機）の台数を減らすことができ、消費電力を削減することもできる。また、物理計算機の数が減ることにより管理も容易になる。更に、仮想計算機では、必要なときに必要なゲストＯＳを実行すればよい。

これに対し、複数の物理計算機でそれぞれＯＳを実行する計算機システムでは、ＯＳによる処理が不要な期間、当該ＯＳがロードされている物理計算機が非稼動状態となることから、当該物理計算機の資源を有効に利用することができない。

特開２００８−１６５４１０号公報

上述のように、仮想計算機システムでは、物理計算機の数を減らしつつ、物理計算機の資源を複数のゲストＯＳのうち実行が必要なゲストＯＳに割り当てることで、当該物理計算機の資源を有効利用することが可能になる。しかし従来の仮想計算機システムでは、当該システム内で動作する複数のゲストＯＳで、サーバ／クライアント関係を構築する際には、以下に述べるように注意が必要となる。

仮想計算機システム内のＶＭＭは、当該システム内で動作する複数のゲストＯＳに物理計算機の資源としての例えば実ＣＰＵをある割合で時分割で割り当てるのが一般的である。最も単純な実ＣＰＵの割り当て手法として、各ゲストＯＳに実ＣＰＵを割り当てる時間の割合を予め静的に決める手法が知られている。

ここで、仮想計算機システム内で４つのゲストＯＳ＃０，＃１，＃２及び＃３が動作し、これらのゲストＯＳ＃０，＃１，＃２及び＃３に、それぞれ２０％，２０％，４０％及び２０％の割合で、ＣＰＵ時間が割り当てられるものとする。ユーザは、これらのゲストＯＳ毎のＣＰＵ時間の割り当て比率（ＣＰＵ割り当て比率）を、例えば、ＶＭＭのためのシステムコンソールを用いて直接指定することができる。

ゲストＯＳ＃０，＃１及び＃２の間にはサーバ／クライアントの関係があるものとする。具体的には、ゲストＯＳ＃０及び＃１がクライアントとして機能して、ゲストＯＳ＃２がデータベースサーバとして機能するものとする。

ゲストＯＳ＃０及び＃１は処理要求をゲストＯＳ＃２に発行し、ゲストＯＳ＃２は要求されたデータベースサーバとしての処理を行って結果を要求元に返す。ここで、ゲストＯＳ＃０及び＃１が、ネットワーク経由で外部から与えられる問い合わせ処理の依頼を受けて、データベースサーバであるゲストＯＳ＃２にデータ照合を要求し、結果をネットワーク経由で問い合わせ元に返す処理を実行するものとする。このような処理はＯＬＴＰ（On Line Transaction Processing）と呼ばれる。

上述のように、ゲストＯＳ毎にＣＰＵ割り当て比率が予め静的に決定されていると、ゲストＯＳ＃０及び＃１からの処理要求に対して、ゲストＯＳ＃２の処理が追いつかなくなることがある。このような状態が発生すると、ゲストＯＳ＃０及び＃１の要求する時間内に処理を終えることができない場合が生じ得る。その場合、ゲストＯＳ＃０及び＃１はタイムアウト処理などにより、実際には有効な処理を終えることができないまま、エラー処理やリトライ処理を行うことになる。

例えば、ユーザの操作によりユーザ端末のＷｅｂインターフェイスからネットワーク経由でクライアントにアクセスすることによって各種サービスをクライアントに要求するシステムでは、システムのレスポンスが遅い場合、更にユーザはＷｅｂインターフェイスからクライアントに問い合わせ（サービス要求）を送る傾向がある。これが更なるクライアントの負荷になり、システムの状況を悪化させる。

上述のような状況においてクライアントは、サーバに対して先に出した処理の取り消しを要求したり、或いはタイムアウトエラーを問い合わせ元に返す。すると、更に同じ要求が問い合わせ元からクライアントに送りつけられて、再びサーバに対する問い合わせ処理が発生する。結局、このような状況になると、元々ＣＰＵ時間が不足しているところに、更にユーザからのリクエストやエラー処理にＣＰＵの時間が使われてしまう割合が大きくなり、システムの効率が非常に悪化する。

一方、上記特許文献１に記載の仮想計算機システムでは、スケジュール周期と呼ばれる一定周期毎に、スケジュール対象となる複数のゲストＯＳに実ＣＰＵが時分割で割り当てられる。この特許文献１に記載の仮想計算機システムでは、当該システム内のＶＭＭが、相互に通信を行うゲストＯＳの組を特定して、この特定された組に属する各ゲストＯＳに対して１スケジュール周期内で実ＣＰＵを割り当てる回数を、対応する平均通信時間に基づいて動的に決定している。ここで、１スケジュール周期内の割り当て回数が標準（例えば１回）のｎ倍になれば、１回当たりの実ＣＰＵの割り当て時間は１／ｎとなる。

つまり、特許文献１に記載の仮想計算機システムでは、各ゲストＯＳに対して１スケジュール周期内に実ＣＰＵが割り当てられる回数は動的に決定される一方、各ゲストＯＳに実ＣＰＵが割り当てられる時間の割合は予め静的に決められている。このため、特許文献１に記載の仮想計算機システムでは、ゲストＯＳ間の通信に要する時間の影響が大きい場合には、システム効率を向上することができるものの、上述の各ゲストＯＳでサーバ／クライアント関係を構築する場合のように、各ゲストＯＳの処理に要する時間の影響が大きい場合には、システム効率を向上することが困難となる。

本発明は上記事情を考慮してなされたものでその目的は、サーバ／クライアント関係にある複数のゲストＯＳが動作する場合に当該サーバ／クライアント関係を認識し、各ゲストＯＳにＣＰＵが割り当てられる時間を当該サーバ／クライアント関係に基づいて調整することによりシステム効率を向上することができる、仮想計算機管理機構及び仮想計算機システムにおけるＣＰＵ時間割り当て制御方法を提供することにある。

本発明の１つの観点によれば、ＣＰＵを含むハードウェアを仮想化することによって複数の仮想計算機を構築し、当該複数の仮想計算機で複数のゲストＯＳを時分割で実行させるための管理を行う仮想計算機管理機構が提供される。この仮想計算機管理機構は、前記複数のゲストＯＳのうちの任意のゲストＯＳがクライアントとして機能して、前記複数のゲストＯＳのうちのサーバとして機能する他のゲストＯＳに処理を要求する際に、処理の要求元のゲストＯＳがクライアントであり、処理の要求先のゲストＯＳがサーバであるサーバ／クライアント関係を、前記処理の要求元のゲストＯＳから前記仮想計算機管理機構に通知するのに用いられるサーバ／クライアント関係通知インターフェイスを含むゲストＯＳインターフェイス手段と、前記複数のゲストＯＳに前記ＣＰＵを時分割で割り当てるためのスケジュールを管理するスケジューラであって、前記サーバ／クライアント関係通知インターフェイスによって通知されたゲストＯＳ間のサーバ／クライアント関係に基づいて、前記複数のゲストＯＳに前記ＣＰＵを割り当てる時間を調整するスケジューラとを具備する。

本発明によれば、複数のゲストＯＳを時分割で実行させるための管理を行う仮想計算機管理機構が、複数のゲストＯＳのサーバ／クライアント関係をサーバ／クライアント関係通知インターフェイスを介して認識して、各ゲストＯＳにＣＰＵが割り当てられる時間を、その認識した関係に基づいて調整することにより、従来技術においてゲストＯＳ間で密に相互に通信を行いながらサーバ／クライアントの関係で連携して処理を行うような場合に発生していたＣＰＵ割り当て時間の不適切な配分による効率悪化の状況を改善して、システム効率を高めることができる。

本発明の一実施形態に係る仮想計算機システムを含むネットワークシステムの構成を示すブロック図。 同仮想計算機システムの構成を示すブロック図。 図２に示されるゲストＯＳ依存関係テーブルの第１のデータ構造の例を示す図。 図２に示されるＣＰＵ割り当てテーブルのデータ構造の例を示す図。 単純なサーバ／クライアントの関係を表すゲストＯＳ依存関係ツリー構造の例を示す図。 複雑なサーバ／クライアントの関係を表すゲストＯＳ依存関係ツリー構造の例を示す図。 図２に示されるゲストＯＳ依存関係テーブルの第２のデータ構造の例を示す図。 同実施形態におけるＣＰＵ時間再割り当て処理の手順を示すフローチャート。 図４に示されるＣＰＵ割り当てテーブルのＣＰＵ時間再割り当て処理後の状態の一例を示す図。 同実施形態の変形例で適用されるＣＰＵ割り当てテーブルのデータ構造の例を示す図。 同実施形態の変形例におけるＣＰＵ時間再割り当て処理の手順を示すフローチャート。

以下、本発明の実施の形態につき図面を参照して説明する。
図１は本発明の一実施形態に係る仮想計算機システム１を含むネットワークシステムの構成を示すブロック図である。
図１において、仮想計算機システム１は、ネットワーク２に接続されている。このネットワーク２には、１つ以上のユーザ端末、例えば複数のユーザ端末３が接続されている。本実施形態においてユーザ端末３の１つは、仮想計算機システム１のためのシステムコンソールとして用いられる。

図２は、図１に示される仮想計算機システム１の構成を示すブロック図である。仮想計算機システム１は、パーソナルコンピュータやサーバコンピュータのような物理計算機１０を用いて実現される。物理計算機１０は、仮想計算機（仮想マシン）の実行環境を提供するのに必要なハードウェア１１を備えている。ハードウェア１１は、ＣＰＵ（実ＣＰＵ）１１０、更には図示せぬＩ／Ｏ（入出力）装置（実Ｉ／Ｏ装置）及びメモリ（実メモリ）を含む。

物理計算機１０のハードウェア１１上では、例えばソフトウェアモジュールを用いて構成される仮想計算機管理機構（Virtual Machine Manager/Monitor：ＶＭＭ）２０が動作する。ＶＭＭ２０は、仮想計算機システム１の管理を行い、仮想計算機実行環境を提供する。更に具体的に述べるならば、ＶＭＭ２０は、物理計算機１０のハードウェア１１を構成する、ＣＰＵ１１０を含む物理資源を管理すると共に、当該物理資源の時間的、領域的な配分を管理することにより、複数の仮想計算機が動作する仮想計算機実行環境を提供する。図２の仮想計算機システム１の例では、ＶＭＭ２０は、４台の仮想計算機３０-0，３０-1，３０-2及び３０-3が動作する仮想計算機実行環境を提供している。

仮想計算機３０-0，３０-1，３０-2及び３０-3上では、それぞれゲストＯＳ３１０-0（＃０），３１０-1（＃１），３１０-2（＃２）及び３１０-3（＃３）が動作する。更に具体的に述べるならば、ゲストＯＳ３１０-0〜３１０-3は、それぞれ仮想計算機３０-0〜３０-3にロードされて、当該仮想計算機３０-0〜３０-4内の仮想ＣＰＵによって実行される。この仮想ＣＰＵは、ＣＰＵ１１０を割り当てることによって実現される。ゲストＯＳ３１０-0〜３１０-3には、それぞれＩＤ（ゲストＯＳＩＤ）０〜３が割り当てられている。本実施形態では、ゲストＯＳ３１０-0〜３１０-3のうちの２つ以上のゲストＯＳは、サーバ／クライアント関係にあるように設定されるものとする。

ＶＭＭ２０は、ゲストＯＳインターフェイス部２０１、ゲストＯＳ依存関係テーブル２０２、ゲストＯＳ依存関係作成モジュール２０３、ＣＰＵ割り当てテーブル２０４、ゲストＯＳスケジューラ２０５及びディスパッチャ２０６を含む。

ゲストＯＳインターフェイス部２０１は、ＶＭＭ２０が提供する種々のサービスを利用するためのゲストＯＳ３１０-0〜３１０-4からの要求を、当該ＶＭＭ２０に通知するのに用いられる、いわゆるシステムコール機構である。ゲストＯＳ３１０-0〜３１０-4は、ゲストＯＳインターフェイス部２０１が提供するインターフェイスをシステムコールによって利用することにより、ＶＭＭ２０に種々のサービスを要求することができる。そこで、ゲストＯＳインターフェイス部２０１が提供するインターフェイスを、ＨＶＣ（HypervisorCall）と呼ぶこともある。ＨＶＣはＶＭＭ２０がゲストＯＳに対して行うサービスの種類だけ用意される。本実施形態では特に、第１のＨＶＣ（サーバ／クライアント関係通知インターフェイス）が用意される。

第１のＨＶＣは、例えば
HVC_register_server_guestOS()
のような、インターフェイス関数を用いて実現される。括弧内には引数が設定される。

第１のＨＶＣは、クライアントとして機能するゲストＯＳ（以下、クライアントゲストＯＳと称する）から処理が依頼されるサーバとして機能するゲストＯＳ（以下、サーバゲストＯＳと称する）が存在する場合に、その関係を、当該クライアントゲストＯＳが予めＶＭＭ２０に通知するためのインターフェイスである。第１のＨＶＣの引数により、サーバゲストＯＳを示すＩＤが指定される。

例えば、ゲストＯＳ３１０-0（＃０）がクライアントゲストＯＳであり、当該ゲストＯＳ３１０-0（＃０）がゲストＯＳ３１０-2（＃２）をサーバゲストＯＳとして指定する場合には、
HVC_register_server_guestOS(2)
のような第１のＨＶＣを呼び出せば（コールすれば）よい。ゲストＯＳ依存関係作成モジュール２０３はこの第１のＨＶＣを受けることにより、呼び出し元のゲストＯＳ３１０-0（＃０）が「クライアント（クライアントゲストＯＳ）」であり、引数で指定されたゲストＯＳ３１０-2（＃２）が「サーバ（サーバゲストＯＳ）」として位置付けられていること、つまりゲストＯＳ３１０-0（＃０）及び３１０-2（＃２）の間のサーバ／クライアント関係を認識する。この認識結果は、ゲストＯＳ依存関係テーブル２０２に登録される。

ゲストＯＳインターフェイス部２０１は、第１のＨＶＣに基づいてゲストＯＳ依存関係テーブル２０２に登録された内容を、対応するサーバ／クライアント関係が解消された際にキャンセルするのに用いられるインターフェイスも有する。しかし、このインターフェイスは第１のＨＶＣと同様のＨＶＣで容易に実現できるので、その詳細については省略する。

ゲストＯＳ依存関係テーブル２０２は、ＶＭＭ２０によって管理される（仮想計算機上で動作する）各ゲストＯＳ相互の依存関係、特にサーバ／クライアント関係を示す情報を格納する関係情報格納手段として用いられる。ゲストＯＳ依存関係テーブル２０２は、ＶＭＭ２０によって管理される全てのゲストＯＳの各々に対応付けられるエントリを有する。ゲストＯＳ依存関係テーブル２０２は、ハードウェア１１に含まれているメモリの一部の領域に格納される。

図３は、ゲストＯＳ依存関係テーブル２０２の第１のデータ構造の例を示す。ゲストＯＳ依存関係テーブル２０２の各エントリは、ゲストＯＳＩＤフィールド２０２ａと、サーバゲストＯＳＩＤフィールド２０２ｂと、サーバ／クライアントグループＩＤフィールド２０２ｃとの組を含む。

ゲストＯＳＩＤフィールド２０２ａは、ゲストＯＳのＩＤを例えば予め登録するのに用いられる。サーバゲストＯＳＩＤフィールド２０２ｂは、当該フィールド２０２ｂと同一の組に属するゲストＯＳＩＤフィールド２０２ａの示すゲストＯＳによって呼び出された第１のＨＶＣによって通知されるサーバゲストＯＳのＩＤを登録するのに用いられる。サーバ／クライアントグループＩＤフィールド２０２ｃは、第１のＨＶＣによって通知されるサーバ／クライアントの関係を持つゲストＯＳのグループ（以下、サーバ／クライアントグループと称する）を識別するためのサーバ／クライアントグループＩＤを登録するのに用いられる。

つまりゲストＯＳ依存関係テーブル２０２は、ＶＭＭ２０によって管理される全てのゲストＯＳのうち、クライアントとして機能するゲストＯＳについて、当該ゲストＯＳ（クライアントゲストＯＳ）に対してサーバの関係にあるサーバゲストＯＳのＩＤと、これらサーバ／クライアントの関係にあるゲストＯＳが属するサーバ／クライアントグループのＩＤとを登録するのに用いられる。また、ゲストＯＳ依存関係テーブル２０２は、サーバとして機能するゲストＯＳについて、当該ゲストＯＳ（サーバゲストＯＳ）のＩＤと、当該ゲストＯＳが属するサーバ／クライアントグループのＩＤとを登録するのに用いられる。

図３のゲストＯＳ依存関係テーブル２０２の例では、ＩＤが０〜３のゲストＯＳ３１０-0〜３１０-3のうち、ＩＤが０〜２のゲストＯＳ３１０-0〜３１０-2が、同一のサーバ／クライアントグループに属し、そのグループのサーバ／クライアントグループＩＤが０であることが示されている。また図３のゲストＯＳ依存関係テーブル２０２の例では、同一のサーバ／クライアントグループ内で、ゲストＯＳ３１０-2がサーバとして機能し、ゲストＯＳ３１０-0及び３１０-1がクライアントとして機能することも示されている。また、図３のゲストＯＳ依存関係テーブル２０２の例では、ゲストＯＳ３１０-2がサーバとして機能することが、ゲストＯＳ３１０-0及び３１０-1の各々が呼び出した第１のＨＶＣによって通知されたことも示されている。

ゲストＯＳ依存関係作成モジュール２０３は、第１のＨＶＣに基づいてゲストＯＳ依存関係テーブル２０２のエントリ情報を生成して、当該エントリ情報をゲストＯＳ依存関係テーブル２０２に登録する。つまりゲストＯＳ依存関係作成モジュール２０３は、ゲストＯＳ間の依存関係（特にサーバ／クライアント関係）を示す情報を作成する関係情報作成手段として機能する。

ＣＰＵ割り当てテーブル２０４は、ＶＭＭ２０によって管理される全てのゲストＯＳの各々に対応付けられるエントリを有する。ＣＰＵ割り当てテーブル２０４は、ハードウェア１１に含まれているメモリの一部の領域に格納される。

図４はＣＰＵ割り当てテーブル２０４のデータ構造の例を示す。ゲストＯＳ依存関係テーブル２０２の各エントリは、ゲストＯＳＩＤフィールド２０４ａと、ＣＰＵ割り当て比率初期値フィールド（以下、初期値フィールドと略称する）２０４ｂと、ＣＰＵ利用率フィールド２０４ｃと、ＣＰＵ割り当て比率調整値フィールド（以下、調整値フィールドと略称する）２０４ｄとの組を含む。

ゲストＯＳＩＤフィールド２０４ａは、ゲストＯＳのＩＤを例えば予め登録するのに用いられる。初期値フィールド２０４ｂは、当該フィールド２０４ｂと同一の組に属するゲストＯＳＩＤフィールド２０４ａの示すゲストＯＳにＣＰＵ１１０が割り当てられる時間（以下、ＣＰＵ時間と称する）の比率（ＣＰＵ割り当て比率）の初期値（初期ＣＰＵ割り当て比率）Ｒｉ（％）を登録するのに用いられる。

ＣＰＵ利用率フィールド２０４ｃは、当該フィールド２０４ｃと同一の組に属するゲストＯＳＩＤフィールド２０４ａの示すゲストＯＳに割り当てられているＣＰＵ１１０の利用率（以下、ＣＰＵ利用率と称する）を登録するのに用いられる。調整値フィールド２０４ｄは、ＣＰＵ割り当て比率の調整後の値を示す調整値（調整ＣＰＵ割り当て比率）Ｒａ（％）を登録するのに用いられる。

ＣＰＵ利用率フィールド２０４ｃに登録されるＣＰＵ利用率とは、ゲストＯＳに割り当てられているＣＰＵ時間のうち当該ゲストＯＳが実際に使用している時間の割合を示す。例えば、ＣＰＵ割り当て比率が２０％のゲストＯＳが、実際には１０％に相当する時間しかＣＰＵ１１０を使用していない場合には、当該ゲストＯＳのＣＰＵ使用率は５０％となり、割り当てられたＣＰＵ時間の半分しか使用していないことを示す。

本実施形態において、ゲストＯＳ３１０-0〜３１０-3は、当該ゲストＯＳに割り当てられていたＣＰＵ時間の途中で実行すべき処理がなくなった場合、その段階で、ＣＰＵ１１０を開放して（つまり手放して）ＶＭＭ２０に返す。具体的には、該当するゲストＯＳは、例えば処理がなくなった際に実行されるアイドルループの処理の中で、ＣＰＵ１１０をＶＭＭ２０に返すための専用のＨＶＣをコールする。ＶＭＭ２０のゲストＯＳインターフェイス部２０１には、このようなＨＶＣが用意されている。このＨＶＣが呼び出されると、呼び出し元のゲストＯＳに対応付けられたＣＰＵ割り当てテーブル２０４のエントリのＣＰＵ利用率フィールド２０４ｃに登録されているＣＰＵ利用率が、ゲストＯＳスケジューラ２０５のＣＰＵ割り当てテーブル管理部２０５ａによって更新される。上述の例であれば、ＣＰＵ利用率が５０％に更新される。このようにして、各ゲストＯＳの最新のＣＰＵ利用率がＣＰＵ割り当てテーブル２０４に保持される。つまりＣＰＵ割り当てテーブル管理部２０５ａは、各ゲストＯＳのＣＰＵ利用率をＣＰＵ割り当てテーブル２０４を用いて管理する管理手段として機能する。

またゲストＯＳ３１０-0〜３１０-3は、当該ゲストＯＳに割り当てられていたＣＰＵ時間が経過したにも拘わらずに実行すべき処理が残っていても、その段階で、ＣＰＵ１１０をＶＭＭ２０に返す。つまり、ゲストＯＳ３１０-0〜３１０-3は、当該ゲストＯＳに割り当てられていたＣＰＵ時間を超えてＣＰＵ１１０を使用することはできない。この場合、ＣＰＵ使用率は１００％となる。

本実施形態では、ゲストＯＳ３１０-0〜３１０-3に割り当てられていたＣＰＵ時間を全て利用した際に、ＣＰＵ１１０をゲストＯＳ３１０-0〜３１０-3からＶＭＭ２０に返すための専用のＨＶＣもゲストＯＳインターフェイス部２０１に用意されている。また、ゲストＯＳ３１０-0〜３１０-3からＶＭＭ２０にＣＰＵ１１０を返す際に、ＣＰＵ利用率自体を当該ゲストＯＳからＶＭＭ２０に通知するのに用いられるＨＶＣがゲストＯＳインターフェイス部２０１に用意されていても構わない。この他に、予め定められた周期で、ゲストＯＳ３１０-0〜３１０-3からＶＭＭ２０にその周期における例えば平均のＣＰＵ利用率が専用のＨＶＣを用いて通知されてもよい。この周期は、スケジュール周期よりも長い周期に設定される。

図４のＣＰＵ割り当てテーブル２０４の例では、ＩＤが０〜３のゲストＯＳ３１０-0〜３１０-3のうち、ゲストＯＳ３１０-0〜３１０-2にはそれぞれＣＰＵ割り当て比率の初期値として３０％が割り当てられ、ゲストＯＳ３１０-3にはＣＰＵ割り当て比率の初期値として１０％が割り当てられていることが示されている。また図４のＣＰＵ割り当てテーブル２０４の例では、ＣＰＵ割り当て比率の調整値は未登録であり、ＣＰＵ割り当て比率は調整されていない。

ゲストＯＳスケジューラ２０５は、適切なタイミングで起動される。本実施形態において、適切なタイミングとは、一定周期である。ゲストＯＳスケジューラ２０５は、ＶＭＭ２０が管理する全てのゲストＯＳ（ここではゲストＯＳ３１０-0〜３１０-3）の各々にどの程度の時間の割合でＣＰＵ１１０を割り当てるかを、ゲストＯＳ依存関係テーブル２０２によって示されるサーバ／クライアントの関係及びＣＰＵ割り当てテーブル２０４によって示されるサーバゲストＯＳのＣＰＵ利用率等に基づいて決定して、ＣＰＵ割り当てテーブル２０４を更新する。ゲストＯＳスケジューラ２０５は、ＣＰＵ割り当てテーブル管理部２０５ａ、判定部２０５ｂ、クライアントゲストＯＳ探索部２０５ｃ、サーバゲストＯＳスケジュール部２０５ｄ及びクライアントゲストＯＳスケジュール部２０５ｅを含む。これら各部の機能については後述する。

ディスパッチャ２０６は、ＣＰＵ割り当てテーブル２０４によって示されるＣＰＵ割り当て比率に基づいて、各ゲストＯＳに実際にＣＰＵ１１０を割り当てるディスパッチ処理を行う。本実施形態では、予め定められた各スケジュール周期Ｔを、ＣＰＵ割り当てテーブル２０４によって示されるゲストＯＳ３１０-0（＃０）〜３１０-3（＃３）のＣＰＵ割り当て比率で分割して、その分割された時間だけＣＰＵ１１０を対応するゲストＯＳ３１０-0（＃０）〜３１０-3（＃３）に割り当てる。図４に示されるＣＰＵ割り当てテーブル２０４の例では、ゲストＯＳ３１０-0（＃０），３１０-1（＃１），３１０-2（＃２）及び３１０-3（＃３）には、それぞれ、０．３Ｔ，０．３Ｔ，０．３Ｔ，０．１ＴだけＣＰＵ１１０が割り当てられる。

＜サーバ／クライアントグループ分け処理＞
次に、本実施形態の動作について、ＶＭＭ２０のゲストＯＳ依存関係作成モジュール２０３によって実行されるサーバ／クライアントグループ分け処理（以下、グループ分け処理と略称する）を例に説明する。

仮想計算機システム１には、複数のサーバ／クライアントグループが存在する可能性がある。そこでゲストＯＳ依存関係作成モジュール２０３は、ＶＭＭ２０が管理する全てのゲストＯＳをサーバ／クライアントグループにグループ分けするためのグループ分け処理を、ゲストＯＳ依存関係テーブル２０２に基づいて実行する。このグループ分け処理が実行されるまでは、ゲストＯＳ依存関係テーブル２０２の各エントリのサーバ／クライアントグループＩＤフィールド２０２ｃには、有効なサーバ／クライアントグループＩＤは登録されない。

グループ分け処理は、ゲストＯＳ依存関係テーブル２０２のサーバゲストＯＳＩＤフィールド２０２ｂの内容（つまりサーバゲストＯＳのＩＤ）が同一のエントリの群を、ゲストＯＳ依存関係作成モジュール２０３が検出することにより行われる。ゲストＯＳ依存関係作成モジュール２０３は、検出されたエントリの群の各サーバ／クライアントグループＩＤフィールド２０２ｃに、同一のサーバ／クライアントグループに属すことを示すために、同一のサーバ／クライアントグループＩＤを登録する。

またゲストＯＳ依存関係作成モジュール２０３は、検出されたエントリの群のサーバゲストＯＳＩＤフィールド２０２ｂの内容に一致するゲストＯＳＩＤが登録されているゲストＯＳＩＤフィールド２０２ａを含むエントリのサーバ／クライアントグループＩＤフィールド２０２ｃにも、同じサーバ／クライアントグループＩＤを登録する。これにより、図３のゲストＯＳ依存関係テーブル２０２の例であれば、ゲストＯＳＩＤフィールド２０２ａの内容が０〜２の３つのエントリの各サーバ／クライアントグループＩＤフィールド２０２ｃに、同一のサーバ／クライアントグループＩＤ（ここでは０）が登録される。

またゲストＯＳ依存関係作成モジュール２０３は、グループ分け処理の最後で、サーバ／クライアントグループ（を示すサーバ／クライアントグループＩＤ）毎に、当該グループに属するゲストＯＳの依存関係を示すツリー構造（ゲストＯＳ依存関係ツリー構造）のデータを作成する。

図３のゲストＯＳ依存関係テーブル２０２の例では、サーバ／クライアントグループＩＤが０のサーバ／クライアントグループのゲストＯＳ依存関係ツリー構造のデータが作成される。図５は、このゲストＯＳ依存関係ツリー構造の例を示す。図５の例では、図の下方にクライアントゲストＯＳ（クライアントノード）３１０-0（＃０）及び３１０-1（＃１）が配置され、その上方に、当該クライアントゲストＯＳ３１０-0（＃０）及び３１０-1（＃１）に対するサーバゲストＯＳ（サーバノード）３１０-2（＃２）が配置されている。図５において、矢印の始点はクライアントゲストＯＳ、終点はサーバゲストＯＳを示す。

なお、実際には、図２よりも複雑なサーバ／クライアントの関係があり得る。このようなサーバ／クライアントの関係を表すゲストＯＳ依存関係ツリー構造の例を図６に示す。図６（ａ）に示すゲストＯＳ依存関係ツリー構造は、ゲストＯＳ３１０-2（＃２）とゲストＯＳ３１０-3（＃３）とが互いにサーバ／クライアントの関係になっていることを表している。

図６（ｂ）に示すゲストＯＳ依存関係ツリー構造は、ゲストＯＳ３１０-2（＃２）が、ゲストＯＳ３１０-0（＃０）及びＯＳ３１０-1（＃１）のサーバであると同時に、ゲストＯＳ３１０-3（＃３）をサーバとしていること、つまり自身をゲストＯＳ３１０-3（＃３）のクライアントとしていることを表している。図６（ｃ）に示すゲストＯＳ依存関係ツリー構造は、ゲストＯＳ３１０-1（＃１），３１０-2（＃２）及び３１０-3（＃３）が互いにサーバク／ライアントの関係になっていることを表している。また、図６（ｄ）及び（ｅ）のような関係もあり得る。

このように、複数のゲストＯＳの間には種々の依存関係が発生し得る。しかし、ここでは、クライアントゲストＯＳとサーバゲストＯＳとを単純に次のように定義する。
（１）サーバとなっていないクライアントであるゲストＯＳを「クライアントゲストＯＳ」と定義する。
（２）他のゲストＯＳのサーバとして処理を行うゲストＯＳを「サーバゲストＯＳ」として定義する。つまり、あるゲストＯＳに対してはクライアントであったとしても、他のゲストＯＳのサーバとして処理を行うゲストＯＳは、「サーバゲストＯＳ」である。

これらの定義によれば、図６（ａ）乃至（ｅ）の例では、それぞれ枠６０ａ乃至６０ｅ内に配置されているゲストＯＳが「クライアントゲストＯＳ」である。また、枠６０ａ乃至６０ｅ外に配置されているゲストＯＳ、つまりサーバ／クライアントグループ内の「クライアントゲストＯＳ」以外のゲストＯＳが、「サーバゲストＯＳ」である。

このように、本実施形態では、サーバとクライアントとを兼ねているゲストＯＳは「サーバ（サーバゲストＯＳ）」として定義される。そして本実施形態では、後述するように、ＶＭＭ２０のゲストＯＳスケジューラ２０５が、「クライアントゲストＯＳ」に本来割り当てられるＣＰＵ時間の一部を「サーバゲストＯＳ」に割り当てるように制御している。しかしながら、「サーバ」と「クライアント」を兼ねているゲストＯＳに関しても、ＶＭＭがそのゲストＯＳに割り当てられるＣＰＵ時間の一部を、より上位の「サーバゲストＯＳ」に再割り当てするようにすることは可能である。

ここで、図１の仮想計算機システム１において、図５に示されるような単純なサーバ／クライアント関係のみが存在する場合を想定する。つまり、仮想計算機システム１に、サーバとクライアントとを兼ねているゲストＯＳが存在しないものとする。このような場合、図３に示されるデータ構造のゲストＯＳ依存関係テーブル２０２から、簡単にサーバゲストＯＳとクライアントゲストＯＳとを区別することができ、必ずしもゲストＯＳ依存関係ツリー構造のデータを作成する必要はない。

次に、図１の仮想計算機システム１において、図６に示されるような複雑なサーバ／クライアント関係が存在する場合を想定する。つまり、仮想計算機システム１に、サーバとクライアントとを兼ねているゲストＯＳが存在するものとする。このような場合、図３に示されるデータ構造のゲストＯＳ依存関係テーブル２０２から、上述の定義によって分類される「クライアントゲストＯＳ」及び「サーバゲストＯＳ」とを簡単に区別することは困難である。この区別を容易にするためには、ゲストＯＳ依存関係ツリー構造のデータを作成することが好ましい。しかし、「クライアントゲストＯＳ」及び「サーバゲストＯＳ」とを区別する必要がある都度、ゲストＯＳ依存関係ツリー構造のデータを作成または参照（当該データが記憶部に格納される構成を適用する場合）することは無駄である。もし、作成されたゲストＯＳ依存関係ツリー構造のデータから区別される「クライアントゲストＯＳ」及び「サーバゲストＯＳ」の情報をゲストＯＳ依存関係テーブル２０２に登録するならば、このような無駄を解消することが可能となる。

図７はゲストＯＳ依存関係テーブル２０２の第２のデータ構造の例を示す。図７に示されるゲストＯＳ依存関係テーブル２０２の特徴（つまり第２のデータ構造の特徴）は、上述の定義によって分類される「クライアントゲストＯＳ」及び「サーバゲストＯＳ」の区別を示すためのクライアントゲストＯＳＩＤフィールド２０２ｄが追加されている点にある。

図７のゲストＯＳ依存関係テーブル２０２の例では、各エントリのクライアントゲストＯＳＩＤフィールド２０２ｄに「０」または「１」が登録される。クライアントゲストＯＳＩＤフィールド２０２ｄに「１」が登録されている場合、当該フィールド２０２ｄと同一の組に属するゲストＯＳＩＤフィールド２０２ａの示すゲストＯＳが「クライアントゲストＯＳ」であることを示す。これに対し、クライアントゲストＯＳＩＤフィールド２０２ｄに「０」が登録されている場合、当該フィールド２０２ｄと同一の組に属するゲストＯＳＩＤフィールド２０２ａの示すゲストＯＳが「サーバゲストＯＳ」であることを示す。以下の説明では、図７に示される第２のデータ構造のＣＰＵ割り当てテーブル２０４がＶＭＭ２０に含まれているものとする。

ここで、図６（ｅ）のように、１つのクライアントゲストＯＳに対して２つ（複数）のサーバゲストＯＳが存在する場合も考えられる。このような場合には、図７（ｂ）に示す通り、ゲストＯＳ依存関係テーブル２０２における１つのゲストＯＳ ＩＤの行に対して、複数の「サーバゲストＯＳ ＩＤ」、「サーバ／クライアントグループＩＤ」、「クライアントゲストＯＳ ＩＤ」の行を登録するようにする。以降では、説明を簡単にするため、このようなケースを特別に説明しないが、同様に扱うことが可能である。例えば、後述する図８及び図１１に示すフローチャートで図６に示す他のケース同様、処理することができる。

なお、グループ分け処理は、例えば、ＣＰＵ割り当てテーブル２０４内のエントリのサーバゲストＯＳＩＤフィールド２０２ｂにサーバゲストＯＳのＩＤが新規に登録される場合と、当該フィールド２０２ｂの内容が更新される場合とに実行されればよい。

＜ＣＰＵ時間再割り当て処理＞
次に、各ゲストＯＳに割り当てるＣＰＵ割り当て比率を調整するためのＣＰＵ時間再割り当て処理（以下、単にＣＰＵ時間割り当て処理と称する）について、図８のフローチャートを参照して説明する。この処理は、ＶＭＭ２０のゲストＯＳスケジューラ２０５によって、例えば一定周期で繰り返し実行される。本実施形態において、この周期は１秒である。

仮想計算機システム１には、複数のサーバ／クライアントグループが存在する可能性がある。もし、複数のサーバ／クライアントグループが存在する場合、ＣＰＵ時間割り当て処理は、サーバ／クライアントグループ毎に順に実行される。図８のフローチャートには、１つのサーバ／クライアントグループに対する処理の手順が示されている。

まずゲストＯＳスケジューラ２０５は、ゲストＯＳ依存関係テーブル２０２によって示されている、現在処理の対象となっているサーバ／クライアントグループ（以下、対象サーバ／クライアントグループと称する）内の全てのサーバゲストＯＳの中から、未処理（未選択）のサーバゲストＯＳを１つ、サーバゲストＯＳｉとして選択する（ステップ８０１，８０２）。するとゲストＯＳスケジューラ２０５の判定部２０５ｂは、選択されたサーバゲストＯＳｉのＩＤが登録されているＣＰＵ割り当てテーブル２０４のエントリのＣＰＵ利用率フィールド２０４ｃによって示される当該サーバゲストＯＳｉのＣＰＵ利用率が基準使用率以上であるかを判定する（ステップ８０３）。本実施形態において、基準使用率はＣＰＵ利用率の最大値に一致する１００％である。この場合、判定部２０５ｂはステップ８０３において、サーバゲストＯＳｉのＣＰＵ利用率が１００％であるかを判定することになる。

もし、サーバゲストＯＳｉのＣＰＵ利用率が１００％であるならば（ステップ８０３のＹｅｓ）、ゲストＯＳスケジューラ２０５はステップ８０４に進む。ステップ８０４は、ステップ８０４ａ〜８０４ｃから構成される。まずステップ８０４ａにおいてゲストＯＳスケジューラ２０５のクライアントゲストＯＳ探索部２０５ｃは、ＣＰＵ割り当てテーブル２０４を参照することにより、対象サーバ／クライアントグループ内の全てのクライアントゲストＯＳのうち、現在のＣＰＵ割り当て比率Ｒｃ％が閾値（基準割り当て比率）Ｒ０％を超えているクライアントゲストＯＳを探す。

次のステップ８０４ｂにおいてゲストＯＳスケジューラ２０５のクライアントゲストＯＳスケジュール部２０５ｅは、探し求められたクライアントゲストＯＳに現在割り当てられているＣＰＵ時間から、調整用のＣＰＵ割り当て比率Ａ％に相当する時間を減らす。そして更に次のステップ８０４ｃにおいてゲストＯＳスケジューラ２０５のサーバゲストＯＳスケジュール部２０５ｄは、減らされた時間だけ、サーバゲストＯＳｉに割り当てるＣＰＵ時間を増やす。

ステップ８０４（８０４ａ〜８０４ｃ）の詳細は次の通りである。まずクライアントゲストＯＳ探索部２０５ｃはＣＰＵ割り当てテーブル２０４を、対象サーバ／クライアントグループ内の各クライアントゲストＯＳのＩＤが登録されているＣＰＵ割り当てテーブル２０４のエントリの初期値フィールド２０４ｂ及び調整値フィールド２０４ｄを参照して、現在のＣＰＵ割り当て比率Ｒｃ％を算出する。もし、調整値フィールド２０４ｄに有効な調整値が登録されていないならば、初期値フィールド２０４ｂに登録されている初期値（初期ＣＰＵ割り当て比率）Ｒｉ％が現在のＣＰＵ割り当て比率Ｒｃ％（Ｒｃ＝Ｒｉ）として求められる。これに対し、調整値フィールド２０４ｄに有効な調整値Ｒａ％が登録されているならば、このＲａ％が現在のＣＰＵ割り当て比率Ｒｃ％（Ｒｃ＝Ｒａ）として求められる。これによりクライアントゲストＯＳ探索部２０５ｃは、現在のＣＰＵ割り当て比率Ｒｃ％が閾値Ｒ０％を超えているクライアントゲストＯＳを探す（ステップ８０４ａ）。

クライアントゲストＯＳスケジュール部２０５ｅは、現在のＣＰＵ割り当て比率Ｒｃ％が閾値Ｒ０％を超えているクライアントゲストＯＳについて、当該現在のＣＰＵ割り当て比率がＲｃ％からＡ％だけ減少されるように、対応するエントリの調整値フィールド２０４ｄの調整値を更新する（ステップ８０４ｂ）。具体的には、調整値フィールド２０４ｄに有効な調整値が登録されていないならば、調整値Ｒａ％として（Ｒｉ−Ａ）％が登録される。これに対し、調整値フィールド２０４ｄに有効な調整値Ｒａ％が登録されているならば、当該調整値Ｒａ％が（Ｒａ−Ａ）％に更新される。

現在のＣＰＵ割り当て比率Ｒｃ％が閾値Ｒ０％を超えているクライアントゲストＯＳの数がｎであるものとすると、サーバゲストＯＳスケジュール部２０５ｄは、サーバゲストＯＳｉに割り当てられるＣＰＵ時間を、ｎ・Ａ％に相当する時間だけ増やす（ステップ８０４ｃ）。そのためサーバゲストＯＳスケジュール部２０５ｄは、サーバゲストＯＳｉのＩＤが登録されているＣＰＵ割り当てテーブル２０４のエントリの初期値フィールド２０４ｂ及び／または調整値フィールド２０４ｄの内容に基づいて、当該調整値フィールド２０４ｄの調整値を更新する。具体的には、調整値フィールド２０４ｄに有効な調整値が登録されていないならば、調整値Ｒａ％として（Ｒｉ＋ｎ・Ａ）％が登録される。これに対し、調整値フィールド２０４ｄに有効な調整値Ｒａ％が登録されているならば、当該調整値Ｒａ％が（Ｒａ＋ｎ・Ａ）％に更新される。

各ゲストＯＳのＣＰＵ割り当て比率の初期値Ｒｉ（％）、閾値Ｒ０及び調整用のＣＰＵ割り当て比率Ａ％はシステムパラメータであり、例えば専用のＨＶＣで事前に登録されるものとする。また、これらのパラメータが、ユーザ（システム管理者）の操作に基づき、ユーザ端末３から設定される構成であっても構わない。また、仮想計算機システム１を実現する物理計算機１０にＶＭＭ２０の制御のためのシステムコンソール（コンソール端末）を接続し、当該コンソールからＶＭＭ２０に対して上述のパラメータを直接指定することも可能である。また、システムコンフィグレーションを記述したスクリプトファイルをＶＭＭ２０に読ませることにより、上述のパラメータを当該ＶＭＭ２０に設定することも可能である。また、Ｒ０及びＡが、サーバ／クライアントグループ毎に設定されても構わない。本実施形態では、Ｒ０及びＡの値として、それぞれ５（％）及び１（％）が設定されている場合を想定している。

上述のステップ８０４の処理により、現在（つまりステップ８０５の開始時）のＣＰＵ割り当て比率Ｒｃ％がＲ０％を超えている各クライアントゲストＯＳから、サーバゲストＯＳｉに対してＡ％ずつＣＰＵ割り当て時間が与えられることになる。ゲストＯＳスケジューラ２０５は、ステップ８０４を実行し終えると、ステップ８０１に戻る。

ＣＰＵ割り当てテーブル２０４及びゲストＯＳ依存関係テーブル２０２が、それぞれ図４及び図７で示される状態にあり、且つゲストＯＳ３１０-0（＃０），３１０-1（＃１）及び３１０-2（＃２）が全てＣＰＵ利用率１００％の状態で、ステップ処理８０４が行われた結果を、図９のＣＰＵ割り当てテーブル２０４に示す。つまり図４に示されるＣＰＵ割り当てテーブル２０４は図９に示されるように更新される。

図４に示されるＣＰＵ割り当てテーブル２０４と、図９に示されるＣＰＵ割り当てテーブル２０４とを比較すれば明らかなように、ゲストＯＳ３１０-0（＃０）及び３１０-1（＃１）からそれぞれＣＰＵ割り当て比率１％に相当するＣＰＵ時間がゲストＯＳ３１０-2（＃２）に移動される。これによりゲストＯＳ３１０-0（＃０），３１０-1（＃１）及び３１０-2（＃２）の最新のＣＰＵ割り当て比率Ｒｃ（つまり調整ＣＰＵ割り当て比率Ｒａ）は、それぞれ２９％、２９％、３２％に変更される。

このようなＣＰＵ割り当て比率を調整するためのＣＰＵ時間割り当て処理が、サーバゲストＯＳｉとしてのゲストＯＳ３１０-2（＃２））のＣＰＵ利用率が１００％未満となるまで一定周期で繰り返される。但し本実施形態では、最大に調整したとしてもゲストＯＳ３１０-0（＃０）及び３１０-1（＃１）のＣＰＵ割り当て比率Ｒｃ（調整ＣＰＵ割り当て比率Ｒａ）がＲ０％以下になることはない。つまり、ゲストＯＳ３１０-0（＃０）及び３１０-1（＃１）のＣＰＵ割り当て比率が５％より低くなることはなく、したがってゲストＯＳ３１０-2（＃２）のＣＰＵ割り当て比率が８０％より高くなることもない。

このように本実施形態においては、サーバゲストＯＳ３１０-2（＃２）のＣＰＵ利用率が１００％である限り（ステップ８０３のＹｅｓ）、クライアントゲストＯＳ３１０-0（＃０）及び３１０-1（＃１）のＣＰＵ割り当て比率がＲ０（＝５）％になるまで、当該サーバゲストＯＳ３１０-2（＃２）のＣＰＵ割り当て比率が増やされる（ステップ８０４）。この結果、サーバ／クライアント処理の真のボトルネックとなっているサーバゲストＯＳ３１０-2（＃２）の処理が促進され、システム全体（ここではＩＤが０のサーバ／クライアントグループ全体）の処理効率が改善される。

なお、クライアントゲストＯＳにおいてエラー処理が頻繁に発生した場合や、当該クライアントゲストＯＳに対してユーザからの処理能力以上のリクエストがある場合に、当該クライアントゲストＯＳに、サーバゲストＯＳ以上にＣＰＵ時間を割り当てることが考えられる。しかし、クライアントゲストＯＳにより多くのＣＰＵ時間を割り当てることにより当該クライアントゲストＯＳの処理能力を高めると、元々負荷が高いサーバゲストＯＳの負荷が一層高くなって、システム全体として処理効率が低下する。しかも従来技術では、ＶＭＭ２０が管理している複数のゲストＯＳがそれぞれクライアントゲストＯＳまたはサーバゲストＯＳのいずれであるかを当該ＶＭＭ２０が認識できないため、負荷が高いクライアントゲストＯＳを選択して、この選択したクライアントゲストＯＳにより多くのＣＰＵ時間を割り当てることすらできなかった。

ここで、上述の例のように、サーバ／クライアントグループ内の全てのゲストＯＳ３１０-0〜３１０-2のＣＰＵ利用率が１００％となり、いずれもフル稼働している状況を想定する。このような状況では、余分なＣＰＵ時間は存在しないため、従来技術であれば、ＶＭＭ２０は、予め指定されているＣＰＵ割り当て比率に従ってＣＰＵ時間を割り当てることしかできなかった
さて、ステップ８０４の繰り返しでサーバゲストＯＳｉ（ここではゲストＯＳ３１０-2（＃２））のＣＰＵ割り当て比率が段階的に増加されたことにより、当該ゲストＯＳｉの負荷が下がって、当該ゲストＯＳｉのＣＰＵ利用率が１００％より低くなったものとする（ステップ８０３のＮｏ）。つまり、サーバゲストＯＳｉのアイドル時間が生じるようになったものとする。この場合、ゲストＯＳスケジューラ２０５の判定部２０５ｂは、サーバゲストＯＳｉの現在のＣＰＵ割り当て比率Ｒｃが初期ＣＰＵ割り当て比率Ｒｉよりも高いか、つまり現在のＣＰＵ割り当て比率Ｒｃが調整後のものであるかを判定する（ステップ８０５）。

もし、ステップ８０５の判定がＹｅｓであるならば、ゲストＯＳスケジューラ２０５はステップ８０６に進む。ステップ８０６は、ステップ８０６ａ〜８０６ｃから構成される。まずステップ８０６ａにおいてゲストＯＳスケジューラ２０５のクライアントゲストＯＳ探索部２０５ｃは、ＣＰＵ割り当てテーブル２０４を参照することにより、対象サーバ／クライアントグループ内の全てのクライアントゲストＯＳのうち、現在のＣＰＵ割り当て比率Ｒｃが初期ＣＰＵ割り当て比率Ｒｉよりも低いクライアントゲストＯＳを探す。ここで、探し求められたクライアントゲストＯＳの数がｎであるものとする。

次のステップ８０６ｂにおいてゲストＯＳスケジューラ２０５のサーバゲストＯＳスケジュール部２０５ｄは、探し求められた各クライアントゲストＯＳにサーバゲストＯＳｉからＡ％に相当するＣＰＵ時間を返却するために、当該サーバゲストＯＳｉに割り当てられるＣＰＵ時間を、ｎ・Ａ％に相当する時間だけ減らす。このステップ８０６ｂの処理は、サーバゲストＯＳｉの現在のＣＰＵ割り当て比率がＲｃ％からｎ・Ａ％だけ減少されるように、ＣＰＵ割り当てテーブル２０４の対応するエントリの調整値フィールド２０４ｄの調整値を更新することによって実現される。

更に次のステップ８０６ｃにおいてゲストＯＳスケジューラ２０５のクライアントゲストＯＳスケジュール部２０５ｅは、探し求められた各クライアントゲストＯＳに現在割り当てられているＣＰＵ時間に、サーバゲストＯＳｉから返却された、ＣＰＵ割り当て比率Ａ％に相当する時間を追加する。このステップ８０６ｂの処理は、探し求められた各クライアントゲストＯＳの現在のＣＰＵ割り当て比率がＲｃ％からＡ％だけ増加されるように、ＣＰＵ割り当てテーブル２０４の対応するエントリの調整値フィールド２０４ｄの調整値を更新することによって実現される。

ゲストＯＳスケジューラ２０５は、ステップ８０６を実行し終えると、ステップ８０１に戻る。
これに対し、ステップ８０５の判定がＮｏの場合には、ゲストＯＳスケジューラ２０５はステップ８０６をスキップしてステップ８０１に戻る。

一方、対象サーバ／クライアントグループ内の全てのサーバゲストＯＳについて処理し終えたならば（ステップ８０１のＮｏ）、ゲストＯＳスケジューラ２０５は、図８のフローチャートで示される処理を終了する。この後、ディスパッチャ２０６は、図８の処理で作成されたＣＰＵ割り当てテーブル２０４のＣＰＵ割り当て比率調整値に基づいて、対象サーバ／クライアントグループにＣＰＵ時間を割り当てる。

ゲストＯＳスケジューラ２０５は図８の処理を実行し終えると、対象サーバ／クライアントグループについての１回分のＣＰＵ時間割り当て処理を終了する。前述したたように、このＣＰＵ時間割り当て処理は、一定周期で繰り返し実行される。

［変形例］
次に上記実施形態の変形例について説明する。この変形例の主要な特徴は、ＣＰＵ割り当てテーブル２０４の各エントリに、サーバ関係の処理の実行中であるかを示すサーバ関係処理実行中フラグフィールド（以下、実行中フラグフィールドと略称する）２０４ｅ（図１０参照）が追加された点と、サーバゲストＯＳが「サーバ関係の処理」を行っている状態にあることをＶＭＭ２０に通知する点にある。

図１０は、本変形例で適用されるＣＰＵ割り当てテーブル２０４のデータ構造例を示す。図１０から明らかなように、ＣＰＵ割り当てテーブル２０４の各エントリは、ゲストＯＳＩＤフィールド２０４ａ、初期値フィールド２０４ｂ、ＣＰＵ利用率フィールド２０４ｃ及び調整値フィールド２０４ｄに加えて、実行中フラグフィールド２０４ｅを含む。実行中フラグフィールド２０４ｅは、対応するゲストＯＳがサーバ関係の処理の実行中であるか否かを示すサーバ関係処理実行中フラグ（以下、実行中フラグと略称する）を保持するのに用いられる。本変形例では、サーバゲストＯＳがサーバ関係の処理の実行中、当該サーバゲストＯＳに対応付けられた実行中フラグがセットされ、サーバ関係の処理を実行し終えると当該実行中フラグがリセットされる。

さて本変形例では、サーバゲストＯＳがサーバ関係の処理を行っている状態にあることをＶＭＭ２０に通知するのを可能とするために、ＶＭＭ２０のゲストＯＳインターフェイス部２０１に、第２のＨＶＣ（第１のサーバ関係処理中通知インターフェイス）及び第３のＨＶＣ（第２のサーバ関係処理中通知インターフェイス）が用意されている。

第２のＨＶＣは、例えば
HVC_Start_server_Processing()
のような、インターフェイス関数を用いて実現される。

第３のＨＶＣは、例えば
HVC_Stop_server_Processing()
のような、インターフェイス関数を用いて実現される。

第２のＨＶＣは、サーバゲストＯＳがサーバ関係の処理の実行を開始する際に呼び出される。例えば、サーバゲストＯＳ上で動作するアプリケーション（サーバアプリケーション）自身が第２のＨＶＣを呼び出してもよいし、或いはサーバゲストＯＳ自身が予め登録されているサーバプロセス（サーバ関係の処理を実行するためのプロセス）にＣＰＵ１１０をディスパッチする（実行する）際に、第２のＨＶＣを呼び出してもよい。

ＶＭＭ２０のゲストＯＳスケジューラ２０５は、サーバゲストＯＳにより第２のＨＶＣが呼び出されると、当該サーバゲストＯＳに対応するＣＰＵ割り当てテーブル２０４のエントリの実行中フラグをセットする。例えば、実行中フラグフィールド２０４ｅ（図１０参照）の内容が「０」から「１」に変更される。

第３のＨＶＣは、サーバゲストＯＳがサーバ関係の処理を実行し終える際にコールする。例えば、サーバアプリケーション自身が第３のＨＶＣをコールしてもよいし、或いはサーバゲストＯＳ自身が予め登録されているサーバプロセスからＣＰＵ１１０を横取りする（実行をやめる）際に、第３のＨＶＣをコールしてもよい。

ＶＭＭ２０のゲストＯＳスケジューラ２０５は、サーバゲストＯＳにより第３のＨＶＣが呼び出されると、当該サーバゲストＯＳに対応するＣＰＵ割り当てテーブル２０４のエントリの実行中フラグをリセットする。例えば、実行中フラグフィールド２０４ｅ（図１０参照）の内容が「１」から「０」に変更される。

結局、図１０に示されるＣＰＵ割り当てテーブル２０４のエントリの実行中フラグ（実行中フラグフィールド２０４ｅの内容）は、そのエントリのゲストＯＳＩＤフィールド２０４ａによって示されるゲストＯＳがサーバ関係の処理を行っている状態にある間だけセット（「１」にセット）される。

＜ＣＰＵ時間再割り当て処理＞
次に、本変形例におけるＣＰＵ時間再割り当て処理（ＣＰＵ時間割り当て処理）について、上記実施形態と相違する点を中心に、図１１のフローチャートを参照して説明する。なお、図１１において、図８のフローチャートと等価なステップには同一参照符号を付してある。

ゲストＯＳスケジューラ２０５は、対象サーバ／クライアントグループ内の全てのサーバゲストＯＳの中から、未処理のサーバゲストＯＳを１つ、サーバゲストＯＳｉとして選択すると（ステップ８０１，８０２）、ステップ１１００に進む。このステップ１１００においてゲストＯＳスケジューラ２０５の判定部２０５ｂは、サーバゲストＯＳｉに対応するＣＰＵ割り当てテーブル２０４内のエントリの実行中フラグフィールド２０４ｅを参照することにより、実行中フラグがセットされているかを判定する。

判定部２０５ｂは、実行中フラグがセットされている場合だけ（ステップ１１００のＹｅｓ）、つまりサーバゲストＯＳｉがサーバ関係の処理の実行中である場合だけ、前述のステップ８０３に進む。このステップ８０３において判定部２０５ｂは、サーバゲストＯＳｉのＣＰＵ利用率が１００％であるかを判定する。この判定結果に基づく処理は上記実施形態のそれ（図８のフローチャート参照）と同様であり、ステップ８０３の判定がＹｅｓの場合、サーバゲストＯＳｉのＣＰＵ割り当て比率が増すように調整される。

このように本変形例においては、サーバゲストＯＳｉの実行中フラグがセットされている間だけ、つまり当該サーバゲストＯＳｉがサーバ関係の処理の実行中の間だけ、当該サーバゲストＯＳｉのＣＰＵ割り当て比率を増すように調整される（但し、サーバゲストＯＳｉのＣＰＵ利用率が１００％である場合）。

これに対し、実行中フラグがリセットされている場合（ステップ１１００のＮｏ）、つまりサーバゲストＯＳｉがサーバ関係の処理の実行中でない場合には、判定部２０５ｂは、サーバゲストＯＳｉのＣＰＵ利用率が１００％でない場合と同様に前述のステップ８０５に進む。このステップ８０５において判定部２０５ｂは、サーバゲストＯＳｉの現在のＣＰＵ割り当て比率Ｒｃが初期ＣＰＵ割り当て比率Ｒｉよりも高いかを判定する。この判定結果に基づく処理は上記実施形態のそれ（図８のフローチャート参照）と同様である。

このように本変形例においては、サーバゲストＯＳｉの実行中フラグがリセットされているならば、つまり当該サーバゲストＯＳｉがサーバ関係の処理の実行中でないならば、たとえ当該サーバゲストＯＳｉのＣＰＵ利用率が１００％であっても、当該サーバゲストＯＳｉのＣＰＵ割り当て比率を増すように調整されることはない。

本変形例によれば、サーバゲストＯＳｉが真にサーバ関係の処理を行っている間だけ、即ちクライアントゲストＯＳからのリクエストを処理している間だけ、サーバゲストＯＳｉのＣＰＵ利用率が１００％であることを条件に、ＣＰＵ割り当て時間が増やされる。これに対して上記実施形態では、サーバゲストＯＳｉが、サーバ関係の処理以外の負荷によりＣＰＵ利用率が１００％になっている場合にも、当該サーバゲストＯＳｉのＣＰＵ割り当て比率を増すように調整される。このため本変形例では、上記実施形態と比較して、より正確に、サーバ関係の処理を行っているサーバゲストＯＳｉにＣＰＵ割り当て比率を増すことができるようになる。

なお、本発明は、上記実施形態またはその変形例そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。例えば、上記実施形態またはその変形例では、ＶＭＭ２０によって管理されるゲストＯＳの数が４であるが、複数のゲストＯＳがＶＭＭ２０によって管理される構成であればよい。また、サーバ／クライアントグループの数も１つに限らない。

また、上記実施形態またはその変形例に開示されている複数の構成要素の適宜な組み合わせにより種々の発明を形成できる。例えば、実施形態またはその変形例に示される全構成要素から幾つかの構成要素を削除してもよい。

１…仮想計算機システム、２…ネットワーク、３…ユーザ端末、１０…物理計算機、１１…ハードウェア、２０…ＶＭＭ（仮想計算機管理機構）、３０-1〜３０-3…仮想計算機、１１０…ＣＰＵ、２０１…ゲストＯＳインターフェイス部、２０２…ゲストＯＳ依存関係テーブル、２０３…ゲストＯＳ依存関係作成モジュール、２０４…ＣＰＵ割り当てテーブル、２０５…ゲストＯＳスケジューラ、２０５ａ…ＣＰＵ割り当てテーブル管理部、２０５ｂ…サーバゲストＯＳ選択部、２０５ｃ…クライアントゲストＯＳ探索部、２０５ｄ…サーバゲストＯＳスケジュール部、２０５ｅ…クライアントゲストＯＳスケジュール部、２０６…ディスパッチャ、３１０-0〜３１０-3…ゲストＯＳ。

Claims (7)

1. ＣＰＵを含むハードウェアを仮想化することによって複数の仮想計算機を構築し、当該複数の仮想計算機で複数のゲストＯＳを時分割で実行させるための管理を行う仮想計算機管理機構において、
   前記複数のゲストＯＳのうちの任意のゲストＯＳがクライアントとして機能して、前記複数のゲストＯＳのうちのサーバとして機能する他のゲストＯＳに処理を要求する際に、処理の要求元のゲストＯＳがクライアントであり、処理の要求先のゲストＯＳがサーバであるサーバ／クライアント関係を、前記処理の要求元のゲストＯＳから前記仮想計算機管理機構に通知するのに用いられるサーバ／クライアント関係通知インターフェイスを含むゲストＯＳインターフェイス手段と、
   前記複数のゲストＯＳに前記ＣＰＵを時分割で割り当てるためのスケジュールを管理するスケジューラであって、前記サーバ／クライアント関係通知インターフェイスによって通知されたゲストＯＳ間のサーバ／クライアント関係に基づいて、前記複数のゲストＯＳに前記ＣＰＵを割り当てる時間を調整するスケジューラと
   を具備することを特徴とする仮想計算機管理機構。
2. 前記サーバ／クライアント関係通知インターフェイスによって通知されたゲストＯＳ間のサーバ／クライアント関係を示す情報を格納するための関係情報格納手段を更に具備し、
   前記スケジューラは、前記関係情報格納手段に格納されている情報の示すゲストＯＳ間のサーバ／クライアント関係に基づいて、前記複数のゲストＯＳに前記ＣＰＵを割り当てる時間を調整する
   ことを特徴とする請求項１記載の仮想計算機管理機構。
3. 前記スケジューラは、
   前記複数のゲストＯＳの各々が前記割り当てられた時間に前記ＣＰＵを使用している割合を示すＣＰＵ利用率を管理する管理手段と、
   サーバとして機能するゲストＯＳの前記ＣＰＵ使用率が予め定められた基準使用率以上である場合、当該サーバとして機能するゲストＯＳにより多くの時間前記ＣＰＵを割り当てるサーバゲストＯＳスケジュール手段と
   を含むことを特徴とする請求項１または２に記載の仮想計算機管理機構。
4. 前記スケジューラは、
   前記複数のゲストＯＳの中から、前記ＣＰＵが割り当てられる時間の比率が基準割り当て比率を超えているクライアントとして機能するゲストＯＳを探す探索手段と、
   前記探索手段によって探し求められたクライアントとして機能するゲストＯＳに前記ＣＰＵが割り当てられるべき時間を減らすクライアントゲストＯＳスケジュール手段とを更に含み、
   前記サーバゲストＯＳスケジュール手段は、前記クライアントゲストＯＳスケジュール手段によって減らされる時間だけ、前記サーバとして機能するゲストＯＳに前記ＣＰＵを割り当てる時間を増やす
   ことを特徴とする請求項３記載の仮想計算機管理機構。
5. 前記基準使用率が１００％であり、
   前記サーバゲストＯＳスケジュール手段は、前記サーバとして機能するゲストＯＳの前記ＣＰＵ使用率が１００％よりも低くなるまで、前記ＣＰＵを割り当てる時間を増やす動作を繰り返し、
   前記クライアントゲストＯＳスケジュール手段は、前記サーバとして機能するゲストＯＳの前記ＣＰＵ使用率が１００％よりも低くなるまで、前記ＣＰＵを割り当てる時間を減らす動作を繰り返す
   ことを特徴とする請求項４記載の仮想計算機管理機構。
6. 前記ゲストＯＳインターフェイス手段は、前記サーバとして機能するゲストＯＳが、サーバに関係する処理を行っている状態にあることを、当該サーバとして機能するゲストＯＳから前記仮想計算機管理機構に通知するのに用いられるサーバ関係処理中通知インターフェイスを更に含み、
   前記サーバゲストＯＳスケジュール手段は、サーバに関係する処理を行っている状態にあることが前記サーバ関係処理中通知インターフェイスによって通知された、前記サーバとして機能するゲストＯＳに前記ＣＰＵを優先的に割り当てることを特徴とする請求項３乃至５のいずれかに記載の仮想計算機管理機構。
7. ＣＰＵを含むハードウェアを仮想化することによって複数の仮想計算機を構築し、当該複数の仮想計算機で複数のゲストＯＳを時分割で実行させるための管理を行う、ゲストＯＳインターフェイス手段、関係情報格納手段、関係情報作成手段、及びスケジューラを含む仮想計算機管理機構を有する仮想計算機システムにおけるＣＰＵ時間割り当て制御方法であって、
   前記複数のゲストＯＳのうちの任意のゲストＯＳが、クライアントとして機能して、前記複数のゲストＯＳのうちのサーバとして機能する他のゲストＯＳに処理を要求する際に、処理の要求元のゲストＯＳがクライアントであり、処理の要求先のゲストＯＳがサーバであるサーバ／クライアント関係を、前記サーバ／クライアント関係通知インターフェイスによって前記仮想計算機管理機構に通知するステップと、
   前記通知されたゲストＯＳ間のサーバ／クライアント関係を示す情報を前記関係情報作成手段が前記関係情報格納手段に格納するステップと、
   前記関係情報格納手段に格納されている情報の示すゲストＯＳ間のサーバ／クライアント関係に基づいて、前記複数のゲストＯＳに前記ＣＰＵを割り当てる時間を、前記スケジューラが調整するステップと
   を具備することを特徴とする仮想計算機システムにおけるＣＰＵ時間割り当て制御方法。

Images