JP2009151745A - 仮想マシンモニタ及びマルチプロセッサシステム - Google Patents

Abstract

【課題】 Ｉ／Ｏデバイスの専有割付機能を有する仮想マシンモニタ上で、Ｉ／Ｏデバイスの物理位置情報を取得するインタフェースを持ち、取得した物理位置情報を使って仮想サーバに対するリソースの割付を、指定されたポリシーに従って最適化する。
【解決手段】 ゲストＯＳに要求されるＩ／Ｏデバイス、ＣＰＵ数、メモリ量に対して、与えられたポリシー（リソース配分において何を優先するかを決めるパラメータ）に従いリソースを割り当てるインタフェースを仮想マシンモニタが備える。また、仮想マシンモニタが割り当てたリソースの物理位置情報を、ゲストＯＳに対して適切に変換して通知するインタフェースを仮想マシンモニタに備える。
【選択図】 図１

Description

本発明は、仮想マシンモニタによって物理計算機上で仮想サーバを稼動させ、Ｉ／Ｏデバイスを仮想サーバに割り当てる仮想計算機に関する。

近年の半導体技術の進行に伴い、１つのダイ上に複数のコアを集積するマルチコアプロセッサや、メモリコントローラをプロセッサダイ上に搭載するメモリコントローラ統合プロセッサが登場している。このように集積された計算機リソースを有効活用するために、従来複数のサーバに分散していた処理を一つのサーバに集約しコストを削減する動きが多
く見られる。このようなサーバの集約に際して有効となる手段が、サーバ分割により、複
数のオペレーティングシステムを１台のサーバ上で稼動させる方法である。サーバ分割に
は、ノード単位、あるいはプロセッサ（コア）やＩ／Ｏデバイスなどのコンポーネント単
位でハードウェアによる分割をサポートする物理分割方式と、ハイパバイザや仮想マシン
モニタと呼ばれるファームウェアによって実現される論理分割方式とがある。

論理分割方式では、各オペレーティングシステム（ゲストＯＳ）は仮想マシンモニタが
提供する論理プロセッサ上で実行され、仮想マシンモニタにより複数の論理プロセッサが
物理プロセッサへマッピングされることにより、ノードよりも細かい単位に区画を分割で
きる。さらにプロセッサ（コア）に関しては複数の論理区画間で１つの物理プロセッサ（
コア）を時分割で切り替えながら実行することもできる。これにより、物理プロセッサ（
コア）の数よりも多くの論理区画を生成して同時に実行することが可能になる。論理分割
を目的とした仮想マシンモニタソフトウェアとしては特許文献１に記載されるような技術
が代表的である。

しかし高集積化が比較的易しいプロセッサやメモリに比べて、入出力の口（経路）を持
つ必要があるため本質的に集積しにくいＩ／Ｏデバイスに関しては数が減らせず、従来の
ＣＰＵとＩ／Ｏデバイスとのバランスが崩れていく傾向が見られる。Ｉ／Ｏデバイスの数
を増やすためには、Ｉ／Ｏスイッチを用いてスロットを増設するといった対策が考えられ
る。しかしＩ／ＯスイッチによってプロセッサやメモリとＩ／Ｏデバイスとの距離が離れ
ることでＩ／Ｏ性能を十分に引き出せないケースが出てきた。

そこで従来は複数の仮想サーバで共有してきたＩ／Ｏデバイスを、特定の仮想サーバに
専有させ、十分なＩ／Ｏ性能を確保するというアプローチが採られるようになってきてい
る。このような仮想サーバによるＩ／Ｏデバイスの専有をサポートする機能として、非特
許文献１に開示されるように、Intel社の制定しているＶＴ−ｄなどが知られている。

一方、マルチコア化の進行やメモリコントローラを統合したプロセッサの登場により、
プロセッサ・メモリ・Ｉ／Ｏデバイスといったリソースの配置が不均衡となる傾向にある
。このような不均衡なシステム上で性能や信頼性を確保するためには、物理位置情報を用
いたリソース配分が必要である。従来のＯＳでは、特定のプロセッサとメモリを対応付け
るAffinity制御という仕組みがあり、これをサポートするために物理位置情報を取得する
標準インタフェースとしてＡＣＰＩ(Advanced Configuration and Power Interface)が規
定されている(非特許文献２)。このaffinity制御では、ＯＳあるいはアプリケーションが
どのＣＰＵとメモリを使用するかという関係付けにより、リソースの割り当てを行う。

米国特許第６４９６８４７号 Intel Virtualization Technology for Directed I/O Architecture Specification、[online]、Intel Corp,、平成１９年８月２４日検索、 インターネット＜ftp://download.intel.com/technology/computing/vptech/Intel(r)_VT_for_Direct_IO.pdf＞ Advanced Configuration and Power Interface Specification Revision 3.0、[online]、Hewlett-Packard, Intel, Microsoft, Phoenix, and Toshiba、平成１９年８月２４日検索、 インターネット＜http://www.acpi.info/＞

しかしながら、上記のような従来のＯＳでは、プロセッサとメモリの位置情報はＡＣＰ
Ｉの仕組みを使って制御することができる。しかしＩ／Ｏデバイスは全アプリケーション
から共通的に参照されるリソースであるため、Ｉ／Ｏデバイスの物理位置情報を使ったAf
finity制御という概念は存在しなかった。実際、ＡＣＰＩの中で規定されているSystem R
esource Affinity Table（ＳＲＡＴ）やSystem Locality Distance Information Table（
ＳＬＩＴ）では、プロセッサとメモリの物理的な位置情報のみが対象であり、Ｉ／Ｏデバ
イスの物理位置情報は管理の対象外である。

一方、仮想マシンモニタを使ってＩ／Ｏデバイスを特定の仮想サーバに専有させるよう
に割り付けようとすると、Ｉ／Ｏデバイスの物理位置情報は、仮想サーバの性能や信頼性
を確保する上で重要なパラメータとなる。しかし従来のＡＣＰＩベースのインタフェース
では、Ｉ／Ｏの物理位置情報を取得する手段がなかった。

また、仮に仮想マシンモニタが適切なリソースを仮想サーバに対して割り当てたとして
も、仮想サーバ上のゲストＯＳがその物理位置情報を正しく利用できない場合、ゲストＯ
ＳのAffinity制御が正しく働かず、結果として物理サーバと同等の性能や信頼性を確保で
きない、という問題点があった。

本発明は、Ｉ／Ｏデバイスの専有割付機能を有する仮想マシンモニタ上で、Ｉ／Ｏデバ
イスの物理位置情報を取得するインタフェースを持ち、取得した物理位置情報を使って仮
想サーバに対するリソースの割付を、指定されたポリシーに従って最適化することを目的
とする。さらに仮想マシンモニタが取得した物理位置情報を仮想サーバへと適切に変換し
て通知するインタフェースを持ち、ゲストＯＳを物理サーバ上で実行した時と同様のAffi
nity制御を仮想サーバ上のゲストＯＳに対しても実行可能にすることを目的とする。

本発明は、１つ以上のプロセッサと、１つ以上のメモリと１つ以上のＩ／Ｏデバイスと
を内部ネットワークで接続し、前記プロセッサとメモリ及びＩ／Ｏデバイスを仮想サーバ
に割り当てる仮想マシンモニタを備えたマルチプロセッサシステムであって、前記仮想マ
シンモニタは、前記マルチプロセッサシステムの前記プロセッサとメモリとＩ／Ｏデバイ
ス及びネットワークを含むハードウェアの物理的な位置情報を含むハードウェアの構成情
報を取得する物理ハードウェア情報取得部と、生成する仮想サーバのプロセッサの数とメ
モリ量とＩ／Ｏデバイス及びリソースの割り当てポリシーとを含む生成要求を受け付ける
受付部と、前記受け付けた生成要求に基づいてＩ／Ｏデバイスを前記仮想サーバに割り当
ててから、前記割り当てポリシーを満たすように前記プロセッサとメモリを前記仮想サー
バに割り当てる割り当て処理部と、を備える。

さらに、前記仮想マシンモニタは、前記仮想サーバに対して割り当てたプロセッサとメ
モリ及びＩ／Ｏデバイスの物理的な位置情報を前記仮想サーバに通知する通知部をさらに
備える。

したがって、本発明は、Ｉ／Ｏデバイスの物理位置情報を取得して、取得した物理位置
情報を用いて仮想サーバに対するリソースの割り当てを、生成要求で指定されたリソース
の割当ポリシーに従って最適化することが可能となる。

さらに、仮想マシンモニタが割り当てたリソースの物理位置情報を仮想サーバへ通知す
ることで、物理サーバ上と同様の制御を仮想サーバ上で実現することができる。

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

図１は第１の実施形態を示し、本発明を適用するマルチプロセッサシステム（計算機）
、およびその上で動作する仮想マシンモニタとゲストＯＳとの関係を示したブロック図で
ある。

マルチプロセッサシステム１００は、１つ以上のＣＰＵソケット（プロセッサパッケー
ジ）１１０、メモリコントローラ１３０、Ｉ／Ｏハブ１６０ａ、１６０ｂをモジュール間
接続Ｉ／Ｆ（インターフェース）２００にて接続した構成を採る。なお、モジュール間接
続Ｉ／Ｆ２００は、マルチプロセッサシステム１００の内部ネットワークを構成する。こ
こでＣＰＵソケット１１０とメモリコントローラ１３０間、ＣＰＵソケット１１０とＩ／
Ｏハブ１６０ａ、１６０ｂ間、メモリコントローラ１３０とＩ／Ｏハブ１６０ａ、１６０
ｂ間のモジュール間接続Ｉ／Ｆ２００が必ずしも同じＩ／Ｆである必要はない。それらが
異なるＩ／Ｆであったとしても以下の説明には差異を生じない。なお、Ｉ／Ｏハブ１６０
ａ、１６０ｂの総称をＩ／Ｏハブ１６０とする。また、メモリコントローラ１３０やＩ／
Ｏハブ１６０の機能を搭載したチップセットが存在していても良い。さらに、図１に示す
ように、メモリコントローラ１３０がＣＰＵソケット１１０上に搭載されたような構成で
あっても良い。ＣＰＵソケット１１０は１つ以上のＣＰＵコア（プロセッサコア）１２０
を含む。メモリコントローラ１３０はメモリＩ／Ｆ１４０を介して１つ以上のＤＩＭＭ（
Dual Inline Memory Module）１５０と接続する。Ｉ／Ｏハブ１６０はＩ／Ｏ接続Ｉ／Ｆ
１７０を介して１つ以上のＩ／Ｏアダプタ１８０ａ〜１８０ｆを搭載し、Ｉ／Ｏアダプタ
１８０ａ〜１８０ｆの先にはＩ／Ｏデバイス１９０ｄが接続される。さらにＩ／Ｏ接続Ｉ
／Ｆ１７０の先にＩ／ＯブリッジやＩ／Ｏスイッチがあり、多段のＩ／Ｏを構成していて
も良い。なお、Ｉ／Ｏアダプタ１８０ａ〜１８０ｆは、ＮＩＣやＨＢＡ（Host Bus Ada
pter）などで構成され、これらの総称をＩ／Ｏアダプタ１８０とする。

マルチプロセッサシステム１００上には１つ以上のサービスプロセッサ２２０があり、
上記各モジュール（物理的構成要素）の物理位置情報や接続情報をモジュール情報取得Ｉ
／Ｆ２１０を介して収集する。サービスプロセッサ２２０はマルチプロセッサシステム１
００のオプションとして外付けされる形で搭載されても良いし、Ｉ／Ｏデバイスの一つと
して搭載される形態でも良い。また、ＬＡＮなどで接続された別のコンピュータ上にサー
ビスプロセッサ２２０の機能があっても良い。また、Ｉ／Ｏデバイスは、データの入出力
を行う装置で構成される。

マルチプロセッサシステム１００上には、仮想マシンモニタ３００が実行され、マルチ
プロセッサシステム１００上のリソースを１つ以上の仮想サーバへと分割してゲストＯＳ
３６０ａ〜３６０ｃに対して提供する。仮想マシンモニタ３００はサービスプロセッサ２
２０が収集したモジュールの物理構成情報と接続情報を、物理ハードウェア構成情報取得
インタフェース３２０を介して受け取る。なお、ゲストＯＳ３６０ａ〜３６０ｃの総称を
ゲストＯＳ３６０とする。

ゲストＯＳ３６０は、仮想サーバとして必要なリソースを論理ハードウェア要求Ｉ／Ｆ
３５０によって仮想マシンモニタ３００へと通知する。なお、ゲストＯＳ３６０の起動時
（すなわち、仮想サーバの起動時）では、マルチプロセッサシステム１００の管理者がコ
ンソール２３０で設定した論理ハードウェア要求Ｉ／Ｆ３１０を仮想マシンモニタ３００
へ通知する。仮想マシンモニタ３００は、仮想マシンモニタ３００上にある物理−論理ハ
ードウェア割当表３１０などを参照し、論理ハードウェア要求Ｉ／Ｆ３５０に含まれるリ
ソース割当ポリシーを考慮した上で、必要な物理リソースの情報を物理−論理ハードウェ
ア割当インタフェース３３０を通じて取得する。仮想マシンモニタ３００は、取得した物
理リソースの情報と、論理ハードウェア要求Ｉ／Ｆ３１０に基づいて物理リソースを論理
ハードウェアとして割り当てる論理ハードウェア割当処理部８０１を備える。仮想マシン
モニタ３００が割り当てた物理リソースの情報は、仮想マシンモニタ３００によって論理
ハードウェア構成情報へと変換され、論理ハードウェア構成情報通知Ｉ／Ｆ３４０を介し
てゲストＯＳ３６０へと通知される。

また、マルチプロセッサシステム１００には、入力装置と出力装置を備えて管理者が使
用するコンソール２３０が接続され、仮想マシンモニタ３００やサービスプロセッサ２２
０に指令を与えたり、仮想マシンモニタ３００やサービスプロセッサ２２０から処理の結
果を受信して出力装置に表示を行う。

＜マルチプロセッサシステムの構成＞
さらに本第１実施形態におけるマルチプロセッサシステム１００の構成をより詳細に説
明する。１１０ａ〜１１０ｄの４つのＣＰＵソケットがモジュール間接続Ｉ／Ｆ２００に
よってリング状に接続されている。それぞれのＣＰＵソケット１１０はＣＰＵコア１２０
を２つずつ持ち、マルチプロセッサシステム１００全体では、８つのＣＰＵコア１２０が
ある。以下の説明において、この８つのＣＰＵコアを図中左からＣＰＵコアの通し番号を
＃０〜＃７と呼ぶ場合がある。

それぞれのＣＰＵソケット１１０上のメモリコントローラ１３０はそれぞれ４本のメモ
リＩ／Ｆ１４０を有し、それぞれ４つのＤＩＭＭ（メモリ）１５０が接続されている。こ
こでは後の説明を簡単にするために、各ＤＩＭＭ１５０は１ＧＢで、１ＣＰＵソケット当
たり４ＧＢ、マルチプロセッサシステム全体では１６ＧＢのメモリを搭載しているとする
。以下の説明において、この１６枚のＤＩＭＭ１５０の通し番号を図中左からＤＩＭＭ＃
０〜＃１５と呼ぶ場合がある。

Ｉ／Ｏハブ１６０は、２つのＩ／Ｏハブ１６０ａと１６０ｂで構成され、それぞれ２つ
ずつのモジュール間接続Ｉ／Ｆ２００を持ち、Ｉ／Ｏハブ１６０ａはＣＰＵソケット１１
０ａと１１０ｂ、Ｉ／Ｏハブ１６０ｂはＣＰＵソケット１１０ｃと１１０ｄとそれぞれ接
続している。Ｉ／Ｏハブ１６０はＩ／Ｏ接続Ｉ／Ｆ１７０をそれぞれ４つずつ持ち、Ｉ／
Ｏ接続Ｉ／Ｆ１７０の先にＩ／Ｏスロット１７５を備え、Ｉ／Ｏアダプタ１８０が接続さ
れている。

Ｉ／Ｏスロット１７５はマルチプロセッサシステム１００全体で８つあり、Ｉ／Ｏスロ
ット１７５の通し番号を図中左から番号を＃０〜７とすると、Ｉ／Ｏスロット＃０にはＩ
／Ｏアダプタ１８０ａが、Ｉ／Ｏスロット＃２にはＩ／Ｏアダプタ１８０ｂが、Ｉ／Ｏス
ロット＃３にはＩ／Ｏアダプタ１８０ｃが、Ｉ／Ｏスロット＃４にはＩ／Ｏアダプタ１８
０ｄが、Ｉ／Ｏスロット＃５にはＩ／Ｏアダプタ１８０ｅが、Ｉ／Ｏスロット＃７にはＩ
／Ｏアダプタ１８０ｆがそれぞれ接続されている。この例ではＩ／Ｏスロット＃１および
Ｉ／Ｏスロット＃６には何も接続されていない。

図６４は，図１の構成に対応するマルチプロセッサシステム100上で，仮想マシンモニタ300，ゲストOS1 360a，ゲストOS2 360b，ゲストOS3 360cが実行されている様子を示した構成図である。仮想マシンモニタ300のプログラムは，いずれかのI/Oデバイス190上，あるいはサービスプロセッサ200のROM201上に存在し，マルチプロセッサシステム300の起動時に前記格納場所からメモリ150(本例ではメモリ150#0)上へと展開され，仮想マシンCPUコア120のいずれかの上で実行される。仮想マシンモニタ300を実行するCPUコア120は，固定されていても良いし，例えばその時空いているCPUコアや処理負荷が少ないＣＰＵコアが実行するなどＣＰＵコアの稼動状態に応じて実行するＣＰＵコアが可変でも良い。
ゲストOS 360は，仮想マシンモニタ300によって分割された論理サーバ370に割り当てられたI/Oデバイス190のいずれかの上にプログラムが存在し，論理サーバ370の起動時に370に割り当てられたメモリ150の上に展開され， 370に割り当てられたCPUコア300によって実行される。図６４の例では，ゲストOS1 360aはメモリ150#5上に，ゲストOS2 360bはメモリ150#10上に，ゲストOS3 360cはメモリ150#13へと展開され，実行されている。なお，本例ではわかりやすいように一つのメモリモジュール上にゲストOS 360を配置した例を示したが，ゲストOSのサイズやメモリインタリーブの設定によっては複数のメモリモジュール上に分散配置されることもあり得る。

図２〜図６で仮想マシンモニタ３００がサービスプロセッサ２２０経由で得たマルチプ
ロセッサシステム１００の物理ハードウェア構成情報取得Ｉ／Ｆ３２０について示す。図
２は物理ハードウェア構成情報取得Ｉ／Ｆ３２０の内訳を示す。物理ハードウェア構成情
報取得Ｉ／Ｆ３２０は、物理コンポーネント構成表４００、Ｉ／Ｏアダプタ構成表４５０
、コンポーネント間距離対応表５００、物理ネットワーク構成表５５０の４種類の表（テ
ーブル）で構成される。これらのテーブルは、仮想マシンモニタ３００が所定の周期また
は所定のタイミングで、サービスプロセッサ２２０がモジュール情報取得Ｉ／Ｆ２１０を
介して収集したハードウェアリソースの情報を問い合わせて生成（または更新）するもの
である。仮想マシンモニタ３００が設定した物理ハードウェア構成情報取得Ｉ／Ｆ３２０
は、図１に示すＩ／Ｏハブ１６０の物理位置情報格納メモリ１６５またはメモリ１５０に
格納される。

図３は物理ハードウェア構成情報取得Ｉ／Ｆ３２０の物理コンポーネント構成表４００
の構成を示す。物理コンポーネント構成表４００は、リソースの通し番号を示すリソース
＃４０５、リソースの種類を示すリソース種別４１０、通し番号に対応するリソースの範
囲を示す範囲４１５、コンポーネント毎の通し番号を示すコンポーネント＃４２０、コン
ポーネントの種類を示すコンポーネント種別４２５、通し番号で特定されたリソースの消
費電力４３０、このリソースを動作させるためのコンポーネントの消費電力４３５、から
構成される。

本実施形態の説明においては、コンポーネント＃４２０はＣＰＵソケット１１０やＩ／
Ｏハブ１６０のように物理的に挿抜あるいは電源のｏｎ／ｏｆｆの対象となるオブジェク
トを指しており、複数のリソースが１つのコンポーネント＃４２０上に接続され得る。本
実施形態の例では、ＣＰＵコア１２０やＤＩＭＭ１５０はＣＰＵソケット１１０というコ
ンポーネントに接続され、Ｉ／Ｏアダプタ１８０はＩ／Ｏハブ１６０というコンポーネン
トに接続される。メモリコントローラ１３０がＣＰＵソケット１１０とは別の場合や、チ
ップセットが存在する場合などは、それらもまた独立したコンポーネントになり得る。物
理コンポーネント構成表４００は、このようなリソースとコンポーネントとの包含関係を
示す表である。範囲４１５で示されるリソースがコンポーネント＃４２０に含まれること
を示している。リソース種別４１０がメモリの場合は、対応するＤＩＭＭ１５０の番号に
加えて、物理アドレスの範囲も示される。この例では１ＤＩＭＭ当たり１ＧＢずつである
ため、０ｘ０＿００００＿００００から０ｘ０＿３＿ＦＦＦＦ＿ＦＦＦＦまでの１６ＧＢ
が属するＣＰＵソケットに応じて４分割されている。各リソースが稼動状態となった場合
の消費電力[Ｗ]が４３０に、リソースの土台となっているコンポーネントが稼動状態とな
った場合の消費電力が４３５に示される。例えばコア＃０が稼動していてコア＃１は稼動
していないとする。この場合リソースの消費電力はコア当たり２０であるため２０だが、
土台となるコンポーネントのＣＰＵソケットの消費電力は物理コンポーネント構成表４０
０によると８０であるため、合計２０＋８０＝１００がコア＃０のみが稼動している場合
の消費電力となる。なお、ここでは物理コンポーネント構成表４００のサイズを小さくす
るために範囲４１５で同じコンポーネントに属する複数のリソースをまとめて１エントリ
で示しているが、リソースごとに異なるエントリを使っても構わない。

また、リソースの消費電力４３０とコンポーネントの消費電力４３５は、サービスプロ
セッサ２２０のＲＯＭ２２１に予め設定したデータを用いる。なお、このＲＯＭにはＩ／
Ｏアダプタ１８０の消費電力や各コンポーネント間の帯域やレイテンシなどコンポーネン
トの性能に係る情報を格納しておく。

図４はＩ／Ｏアダプタ構成表４５０の構成を示す。Ｉ／Ｏアダプタ構成表４５０は、マ
ルチプロセッサシステム１００上の全てのＩ／Ｏアダプタ１８０分のエントリが存在し、
Ｉ／Ｏアダプタ１８０の通し番号を示すＩ／Ｏアダプタ＃４５５、Ｉ／Ｏアダプタの識別
子を示すＩ／Ｏアダプタ４６０、このＩ／Ｏアダプタが装着されたＩ／Ｏスロット＃４６
５、Ｉ／Ｏアダプタの種類を示すアダプタ種別４７０、このＩ／Ｏアダプタの消費電力４
７５の各項目から構成される。アダプタ種別４７０は、ネットワークインタフェースカー
ド（ＮＩＣ）やホストバスアダプタ（ＨＢＡ）といったアダプタの種類が記述される。

図５はコンポーネント間距離対応表５００の構成を示す。コンポーネント間距離対応表
５００は、マルチプロセッサシステム１００上の全てのコンポーネントに対応するエント
リが存在し、コンポーネントの識別子を示すコンポーネント＃４２０と、コンポーネント
の種類を示すコンポーネント種別４２５と、このコンポーネントと他のコンポーネントの
距離を示す対コンポーネント間距離５１０から構成される。対コンポーネント間距離５１
０はまた全てのコンポーネント分だけ分けられており、コンポーネント＃４２０のコンポ
ーネントから対コンポーネント間距離５１０のコンポーネントに到達するまでの距離を示
している。システム全体でＮ個のコンポーネントがある時、対コンポーネント間距離５１
０はＮ×Ｎのマトリックスを構成する。通常、自分自身に到達する距離は０であると考え
られるので、このマトリックスの対角線部分には０が並ぶのが普通である。本実施形態で
はモジュール間接続Ｉ／Ｆ２００の性能は全て等価であると仮定したため、何回モジュー
ル間接続Ｉ／Ｆ２００を渡れば目的のコンポーネントまで辿り着くかという回数を距離と
している。この距離を、コンポーネントの物理的な位置情報として扱う。例えば、ＣＰＵ
ソケット１１０ａからＩ／Ｏハブ１６０ｂまでの距離は、図１において、ＣＰＵソケット
１１０ａからＣＰＵソケット１１０ｄまでの距離がモジュール間接続Ｉ／Ｆ２００を１回
経由し、ＣＰＵソケット１１０ｄからＩ／Ｏハブ１６０ｂまででモジュール間接続Ｉ／Ｆ
２００を１回経由するのでコンポーネント間の距離は合計２となる。

なお、モジュール間接続Ｉ／Ｆが不均一な場合は、後述の物理ネットワーク構成表５５
０にあるレイテンシ５７０の合計値を使って距離を示す、といった方法が考えられる。

また、本実施形態では、メモリ１５０はＣＰＵソケット１１０に直接接続されるため、
ＣＰＵソケット１１０とメモリ１５０の距離は０であるためコンポーネント間距離対応表
５００に含まれないが、メモリ１５０が内部ネットワーク（モジュール間接続Ｉ／Ｆ２０
０）に接続されている場合では、メモリ１５０をコンポーネント＃４２０に加え、各コン
ポーネント間の距離をコンポーネント間距離対応表５００に設定すればよい。

また、コンポーネント間距離対応表５００は、仮想マシンモニタ３００が、物理ハード
ウェア構成情報取得Ｉ／Ｆ３２０の情報に基づいて生成することができる。なお、サービ
スプロセッサ２２０が物理ハードウェア構成情報取得Ｉ／Ｆ３２０の情報に基づいてコン
ポーネント間距離対応表５００を生成し、仮想マシンモニタ３００へ通知するようにして
もよい。

図６は物理ネットワーク構成表５５０の構成を示している。物理ネットワーク構成表５
５０は、マルチプロセッサシステム１００上の全てのモジュール間接続Ｉ／Ｆ２００に対
して、モジュール間接続Ｉ／Ｆ２００の接続の通し番号を示すネットワーク＃５５５と、
どのコンポーネント４２０ａからどのコンポーネント４２０ｂをつないでいるのか、そし
てコンポーネント４２０ａと４２０ｂ間の帯域５６０とレイテンシ５７０を示す項目から
なる。本実施形態では、ＣＰＵソケット１１０間をつなぐネットワークの帯域５６０は６
なのに対して、ＣＰＵソケット１１０とＩ／Ｏハブ１６０の間をつなぐネットワーク帯域
５６０は半分の３であるとした。なお、帯域５６０の単位は、例えば[Ｇｂｐｓ]であり、
レイテンシ５７０の単位は、例えば、[nsec]である。

以上が物理ハードウェア構成情報取得Ｉ／Ｆ３２０の内訳である。これらの情報を、サ
ービスプロセッサ２２０は、モジュール情報取得Ｉ／Ｆ２１０を介して各リソース・コン
ポーネントから収集する。そして、仮想マシンモニタ３００はサービスプロセッサ２２０
から物理ハードウェア構成情報取得Ｉ／Ｆ３２０を取得する。物理ネットワーク構成表５
５０やコンポーネント間距離対応表５００のように、サービスプロセッサ２２０がモジュ
ール単体に問い合わせただけでは得られない情報に関しては、マルチプロセッサシステム
１００の初期化時やあるいは構成変更時に、モジュール情報取得Ｉ／Ｆ２１０およびモジ
ュール間接続Ｉ／Ｆ２００を介する問合せプロトコルを使って接続関係を自動的に検出す
る方法や、構成変更時に管理者が用いるシステム管理ツール（マルチプロセッサシステム
１００の外に存在）の情報をサービスプロセッサ２２０等が不揮発性メモリ等に保存して
おき、その情報を元に構成する、といった方法が考えられる。

＜仮想サーバの構成＞
図７〜図９で、第一の実施形態における仮想サーバ１＿３７０ａの論理ハードウェア要
求Ｉ／Ｆ３５０と、それに対応する仮想サーバの構成を示す。

図７は、ゲストＯＳ３６０を起動する際に、仮想マシンモニタ３００に対して仮想サー
バ１＿３７０ａ（図９、図１６参照）の起動に必要なリソースを要求する論理ハードウェ
ア要求Ｉ／Ｆ３５０ａの構成を示す。この論理ハードウェア要求Ｉ／Ｆ３５０ａは、コン
ソール２３０で管理者が設定したものである。

論理ハードウェア要求Ｉ／Ｆ３５０ａは、仮想サーバの通し番号を示す＃３５１、仮想
サーバで稼動するゲストＯＳ３６０の識別子を示すゲスト名３５２、仮想サーバに割り当
てるＩ／Ｏアダプタ３５３、仮想サーバに割り当てるＣＰＵコア数３５４、仮想サーバに
割り当てるメモリ量３５５、仮想サーバに割り当てるリソースのポリシーを示すリソース
割当ポリシー３５６、仮想サーバの優先度３５７から構成される。仮想サーバ＃３５１は
システム上の仮想サーバを識別するための識別子であり、必ずしも要求するゲスト側が設
定する必要はない。ゲスト名３５２は各ゲストＯＳ３６０を識別するための情報で、例え
ばゲストＯＳ３６０の種類（Ｗｉｎｄｏｗｓ（登録商標）／Ｌｉｎｕｘ等）もここに含ま
れる。Ｉ／Ｏアダプタ３５３は当該ゲストＯＳが要求するＩ／Ｏアダプタ１８０のリスト
である。ここではＩ／Ｏアダプタ１８０ａと１８０ｃを要求している。ＣＰＵコア数３５
４はゲストＯＳ３６０ａが必要なＣＰＵコアの数である。ここでは４コア必要としている
。メモリ量３５５はゲストＯＳ３６０ａが必要とするメモリ量である。ここでは４ＧＢ分
必要としている。リソース割当ポリシー３５６はリソースを割り当てる際のポリシーを示
しており、本発明におけるキーとなるパラメータである。リソース割当ポリシー３５６と
しては、例えば、次のようなポリシーが考えられる。
・性能優先：コンポーネント間の距離を短くするような配置を選ぶ
＊ＣＰＵ−メモリ優先：ＣＰＵとメモリ間の距離が短くなるようにする（ＣＰＵのメモ
リアクセスが多い場合に有効）
＊ＣＰＵ−Ｉ／Ｏ優先：ＣＰＵとＩ／Ｏデバイス間の距離が短くなるようにする（Ｉ／
Ｏ割り込みが多い場合などに有効）
＊Ｉ／Ｏデバイス−メモリ優先：Ｉ／Ｏデバイスとメモリ間の距離が短くなるようにす
る（Ｉ／ＯデバイスからのＤＭＡ転送が多い場合などに有効）
＊ＣＰＵ−Ｉ／Ｏデバイス−メモリ優先：各リソースを近くに配置するようにする（仮
想サーバの全体の性能をバランスさせる場合）
・信頼性優先：仮想サーバ間の共通のコンポーネント・ネットワークが少なくなるように
する
・帯域優先：ネットワークの実効帯域が大きくなるようにする
・省電力優先：システム全体の消費電力が小さくなるようにする
本実施形態の以下の説明では、設定するポリシーの一例を性能優先のうちＣＰＵ−Ｉ／
Ｏ優先としている。ただし、仮想サーバ１（３６０ａ）はマルチプロセッサシステム１０
０上の最初の仮想サーバであるため、基本的に要求したリソースは獲得できる可能性が高
い。優先度３５７は、仮想サーバ間で要求したリソースが競合した場合にどの仮想サーバ
を優先するかを決めるために使うパラメータである。優先度を示す一例としては、ここで
は整数で値が大きいほど優先度が高いことを示すとした。ただし、第一の実施形態では全
ての仮想サーバは等しい優先度を持つとする。

また、本実施形態では仮想サーバに与えるポリシーを１つだけとしているが、優先度の
高いプライマリーポリシーと優先度の低いセカンダリーポリシーを与え、プライマリーポ
リシーを満たす構成の中でさらにセカンダリーポリシーをなるべく満たすような構成を選
択してもよい。さらに複数のポリシーに数値で重み付けを与えるようなインタフェースも
考えられる。ここでは説明の簡略化のために、ポリシーは一つだけとした。

図８は図７に示した仮想サーバ１＿３７０ａの論理ハードウェア要求Ｉ／Ｆ３５０ａに
基づいて仮想マシンモニタ３００の論理ハードウェア割当処理部８０１が物理リソースの
割り当てを行った結果に対応した物理−論理ハードウェア割当表３１０の構成と内容を示
している。なお、仮想マシンモニタ３００がハードウェアリソースを割り当てる処理につ
いては、後述の図５５〜図６３で詳述する。

物理−論理ハードウェア割当表３１０は、仮想サーバの通し番号を示す＃３５１仮想サ
ーバ＃３５１、当該仮想サーバの起動状態を示すｏｎ／ｏｆｆ３１１、当該仮想サーバが
使用するリソースを示す使用リソース＃としてＩ／Ｏアダプタ３１２、ＣＰＵコア３１３
、メモリ３１４、使用コンポーネント＃３１５、使用ネットワーク＃３１６から構成され
る。本実施形態では、論理ハードウェア要求Ｉ／Ｆ３５０ａに従い、Ｉ／Ｏアダプタ＃１
、３、ＣＰＵコア＃０、１、２、３、ＤＩＭＭ＃４、５、６、７を仮想サーバ１＿３７０
ａに割り当てている。また、使用リソース＃のメモリ３１４には対応する物理アドレスが
０ｘ１＿００００＿００００から４ＧＢ分となっている（この０ｘ１＿００００＿０００
０を仮想サーバ１のベースアドレスと呼ぶことがある）。また、これらのリソースが搭載
されたコンポーネントの識別子として１１０ａ、１１０ｂ、１６０ａが使用コンポーネン
ト＃３１５に設定され、接続に使用するネットワーク＃として＃１、５、６が使用ネット
ワーク＃３１６に設定された例を示している。

図７の論理ハードウェア（ＨＷ）要求Ｉ／Ｆ３５０から図８の物理−論理Ｈ／Ｗ割当表
３１０を生成する具体的な手順については、後述する。

図９は、上記論理ハードウェア要求Ｉ／Ｆ３５０ａと物理−論理ハードウェア（ＨＷ）
割当表３１０に基づいて、仮想マシンモニタ３００の論理ハードウェア割当処理部８０１
がマルチプロセッサシステム１００上に割り当てた仮想サーバ１＿３７０ａを示す。図中
点線で囲まれた部分は図１のリソースのうち仮想サーバ１＿３７０ａに割り当てられたリ
ソースを示す。

＜第１実施形態における動作＞
以下、図１０〜１７で、本第１実施形態の動作について説明する。

図１０と図１１は、仮想マシンモニタ３００の論理ハードウェア割当処理部８０１によ
って上記図９で示したように仮想サーバ１＿３７０ａが割り当てられた後で、次の仮想サ
ーバ２に対する論理ハードウェア要求Ｉ／Ｆ３５０ｂおよび３５０ｃを示している。論理
ハードウェア要求Ｉ／Ｆ３５０ｂと３５０ｃは、どちらも同じＩ／Ｏアダプタ３５３、Ｃ
ＰＵコア数３５４、メモリ量３５５を要求している。違いはリソース割当ポリシー３５６
のみで、論理ハードウェア要求Ｉ／Ｆ３５０ｂにおいては「ＣＰＵ−メモリ優先」となっ
ているのに対して、論理ハードウェア要求Ｉ／Ｆ３５０ｃにおいては「Ｉ／Ｏ−メモリ優
先」となっている。以下の例では、これらのポリシーの違いにより、異なるリソースが割
り当てられる様子を示す。

図１２と図１３は、仮想サーバ２に対する上記図１０，図１１の論理ハードウェア要求
Ｉ／Ｆ３５０に対して、仮想マシンモニタ３００の論理ハードウェア割当処理部８０１が
割り当てを行った結果の２通りの物理−論理ハードウェア割当表３１０を示している。ど
ちらもＩ／Ｏアダプタ３１２は＃２で同じだが、使用ＣＰＵコア３１３とメモリ３１４が
異なっている。図１２の物理−論理ハードウェア割当表３１０ｂの方ではＣＰＵコア＃４
、５とＤＩＭＭ＃８、９、１０、１１を割り当てているのに対して、図１３の物理−論理
ハードウェア割当表３１０ｃではＣＰＵコア＃６、７とＤＩＭＭ＃０、１、２、３を割り
当てている。この２通り以外にもリソースの割り当て方は考えられるが、本質的に変わら
ない割り当て方は排除する等として、いくつか割り当て方の候補を絞り込む。

図１０の論理ハードウェア要求Ｉ／Ｆ３５０ｂでは、ＣＰＵ−メモリ優先のポリシーを
要求しているため、ＣＰＵソケット１１０ｃのＣＰＵコア＃４，＃５と、ＣＰＵソケット
１１０ｃに接続されるメモリ＃８〜１１を仮想サーバ２へ割り当てて、リソースの距離を
０とすることでＣＰＵとメモリの距離が短いものを選択している。一方、図１１の論理ハ
ードウェア要求Ｉ／Ｆ３５０ｃでは、Ｉ／Ｏ−メモリ優先のポリシーを要求しているため
、Ｉ／Ｏデバイスとメモリの距離が最も短くなるように、Ｉ／Ｏアダプタ＃２に最も近い
メモリ＃０〜＃３を選択している。このように、仮想マシンモニタ３００の論理ハードウ
ェア割当処理部８０１は、要求されたポリシーに応じて、仮想サーバに割り当てるハード
ウェアリソースを最適化することができる。

図１４は、図１２に示した割当表３１０ｂに対応して、仮想マシンモニタ３００が各リ
ソース間の距離を計算したリソース間距離計算表６００ｂを示している。リソース間距離
計算表６００ｂは、仮想サーバの識別子（または連番）を示す仮想サーバの番号＃３５１
と、各仮想サーバ番号＃３５１ごとに、仮想サーバ内のリソース間の距離を計算するため
の表である。カテゴリ６０１には、リソース割当ポリシーに対応したＣＰＵ−メモリ、Ｉ
／Ｏ−メモリ、ＣＰＵ−Ｉ／Ｏの３種類のカテゴリが存在する。それぞれのカテゴリ６０
１ごとにリソースｆｒｏｍ６０２からリソースｔｏ６０３までのコンポーネント間距離６
０４を、所属するコンポーネント＃と、コンポーネント間距離対応表５００に従って仮想
マシンモニタ３００が計算する。この例では、ＣＰＵコア＃４、＃５とＤＩＭＭ＃８、９
、１０、１１はいずれも同一のコンポーネント１１０ｃ上に搭載されているので、コンポ
ーネント間距離６０４は０となる。一方、Ｉ／Ｏアダプタ＃２が搭載されたコンポーネン
ト１６０ａと、ＤＩＭＭ＃８、９、１０、１１が搭載されたコンポーネント１１０ｃとの
距離は、コンポーネント間距離対応表５００に従うと２であるため、コンポーネント間距
離６０４は２となる。ＣＰＵコア＃４、５とＩ／Ｏアダプタ＃２との間の距離も同様に２
となる。最後にカテゴリ６０１ごとにコンポーネント間距離の総和６０５を計算する。こ
の例では、ＣＰＵ−メモリは０、Ｉ／Ｏ−メモリは２、ＣＰＵ−Ｉ／Ｏは４、となる。

図１５は、図１３に示した物理−論理ハードウェア割当表３１０ｃに対応したリソース
間距離計算表６００ｃを示している。ＣＰＵコア＃６、＃７の搭載されたコンポーネント
１１０ｄと、ＤＩＭＭ＃０、１、２、３の搭載されたコンポーネント１１０ａとの間の距
離は１なので、コンポーネント間距離６０４は１となる。一方Ｉ／Ｏアダプタ＃２の搭載
されたコンポーネント１６０ａとＤＩＭＭ＃０、１、２、３の搭載されたコンポーネント
１１０ａとの間の距離は１なので、コンポーネント間距離６０４は１となる。最後にＣＰ
Ｕコア＃６、７の搭載されたコンポーネント１１０ｄとＩ／Ｏアダプタ＃２の搭載された
コンポーネント１６０ａとの距離は２なので、コンポーネント間距離６０４は２となる。
コンポーネント間距離の総和６０５は、ＣＰＵ−メモリが２、Ｉ／Ｏ−メモリが１、ＣＰ
Ｕ−Ｉ／Ｏが４となる。

以上のようにしてリソース間距離計算表６００を計算したリソース割当候補の中から、
リソース割当ポリシーを最も満たす候補を選択する。３５０ｂにおける「ＣＰＵ−メモリ
優先」の場合は、コンポーネント間距離の総和６０５のＣＰＵ−メモリの値が小さくなる
リソース割当を選ぶ。それに対して「Ｉ／Ｏ−メモリ優先」の場合は、コンポーネント間
距離の総和６０５のＩ／Ｏ−メモリの値が小さくなるリソース割当を選ぶ。物理−論理ハ
ードウェア割当表３１０ｂと３１０ｃを比べた場合、「ＣＰＵ−メモリ優先」の場合は３
１０ｂ、「Ｉ／Ｏ−メモリ優先」の場合は３１０ｃのリソース割当がそれぞれ選択される
。

図１６は図１２に示した物理−論理ハードウェア割当表３１０ｂに対応する仮想サーバ
２＿３７０ｂの構成図である。仮想サーバ２＿３７０ｂは図中一点鎖線で示すように、Ｃ
ＰＵソケット１１０ｃとそれに接続されたメモリ、およびＩ／Ｏアダプタ１８０ｂとから
構成される。

図１７は図１３に示した物理−論理ハードウェア割当表３１０ｃに対応する仮想サーバ
の構成図である。仮想サーバ２＿３７０ｂは図中一点鎖線で示すように、ＣＰＵソケット
１１０ｄ上のＣＰＵコア＃６、７と、ＣＰＵソケット１１０ａ上のＤＩＭＭ＃０、１、２
、３と、Ｉ／Ｏアダプタ１８０ｂとから構成される。

以上の例により、論理ハードウェア要求Ｉ／Ｆ３５０のリソース割当ポリシーの違いに
より、同じＩ／Ｏアダプタ・ＣＰＵコア数・メモリ量を要求した場合でも、異なるリソー
スが割り当てることができ、管理者の希望する仮想サーバを、自動的に構成することが可
能となる。

＜変形例１＞
続いて第一の実施形態の第一の変形例を示す。図１８〜図２０に、本変形例１における
仮想サーバ１＿３７０ａの論理ハードウェア要求Ｉ／Ｆ３５０ｄを図１８に示し、この論
理ハードウェア要求Ｉ／Ｆ３５０ｄから仮想マシンモニタ３００の論理ハードウェア割当
処理部８０１が割り当てを行った結果の物理−論理ハードウェア割当表３１０ｄを図１９
に示し、および仮想サーバ１＿３７０ａの構成を図２０に示す。Ｉ／Ｏアダプタとして１
８０ａと１８０ｃを要求しているのは前記第１実施形態と同じだが、上述の第一の実施形
態と違い、仮想サーバ１は２つのＣＰＵコアと８ＧＢのメモリを要求している。この要求
に対して仮想マシンモニタ３００の論理ハードウェア割当処理部８０１は要求ポリシーで
あるＣＰＵ−Ｉ／Ｏ優先のポリシーから図１９、２０に示すようなリソースの割当を行っ
た。

続いて図２１〜２８で上記図１８〜図２０の仮想サーバ１の割当後に、図２１に示す論
理ハードウェア要求Ｉ／Ｆ３５０ｅによる仮想サーバ２のリソース要求を行い、図２２に
示す論理ハードウェア要求Ｉ／Ｆ３５０ｆによる仮想サーバ２のリソース要求を行った場
合を示す。仮想サーバ２は、前記第一の実施形態と同じく、Ｉ／Ｏアダプタ１８０ｂとＣ
ＰＵコア数２、４ＧＢのメモリを要求している。それに対して、図２１の論理ハードウェ
ア要求Ｉ／Ｆ３５０ｅではリソース割当ポリシー３５６として「ＣＰＵ−メモリ優先」を
、３５０ｆではリソース割当ポリシー３５６として「ＣＰＵ−Ｉ／Ｏ優先」を指定してい
る。

図２３と図２４は、それぞれ上記図２１、図２２の物理−論理ハードウェア割当表３１
０ｅ、３１０ｆの仮想サーバ２に対する異なるリソース割当の例で、仮想マシンモニタ３
００の論理ハードウェア割当処理部８０１が割り当てを行った結果である。物理−論理ハ
ードウェア割当表３１０ｅではＣＰＵコアとメモリが同一のＣＰＵソケット１１０ｃ上に
割り当てられているのに対して、物理−論理ハードウェア割当表３１０ｆではＣＰＵコア
はＣＰＵソケット１１０ａ上に、ＤＩＭＭはＣＰＵソケット１１０ｄ上に割り当てられて
いる。

図２５と図２６は物理−論理ハードウェア割当表３１０ｅと３１０ｆのそれぞれの割当
に従ってリソース間距離計算表６００ｅ、６００ｆを計算した結果である。図２５のリソ
ース間距離計算表６００ｅではコンポーネント間距離の総和６０５はＣＰＵ−メモリが０
、Ｉ／Ｏ−メモリが２、ＣＰＵ−Ｉ／Ｏが４となる。一方、図２６のリソース間距離計算
表６００ｆではコンポーネント間距離の総和６０５はＣＰＵ−メモリが２、Ｉ／Ｏ−メモ
リが２、ＣＰＵ−Ｉ／Ｏが２、となる。この結果、「ＣＰＵ−メモリ優先」の場合にはＣ
ＰＵ−メモリのコンポーネント間距離の総和６０５が小さい３１０ｅの割当が、「ＣＰＵ
−Ｉ／Ｏ優先」の場合には、ＣＰＵ−Ｉ／Ｏのコンポーネント間距離の総和６０５が小さ
い３１０ｆの割当が選択される。

図２７は上記図２３の物理−論理ハードウェア割当表３１０ｅに対応する仮想サーバの
構成図である。仮想サーバ２＿３７０ｂはＣＰＵソケット１１０ｃ上のＣＰＵコア＃４、
５とＤＩＭＭ＃８、９、１０、１１と、Ｉ／Ｏアダプタ１８０ｂとから構成される。

図２８は上記図２４の物理−論理ハードウェア割当表３１０ｆに対応する仮想サーバの
構成図である。仮想サーバ２＿３７０ｂはＣＰＵソケット１１０ａ上のＣＰＵコア＃０、
１と、ＣＰＵソケット１１０ｄ上のＤＩＭＭ＃１２、１３、１４、１５と、Ｉ／Ｏアダプ
タ１８０ｂとから構成される。

以上が第一の実施形態の第一の変形例である。

＜変形例２＞
続いて第一の実施形態の第二の変形例を示す。図２９〜図３１に、本変形例２における
仮想サーバ１＿３７０ａの論理ハードウェア要求Ｉ／Ｆ３５０ｇを図２９に示し、物理−
論理ハードウェア割当表３１０ｇを図３０に示し、および仮想サーバ１＿３７０ａの構成
を図３１に示す。Ｉ／Ｏアダプタとしては１８０ａと１８０ｃを要求しているのは前述の
第１実施形態と同じであるが、ＣＰＵコアは１つ、メモリも２ＧＢしか要求していない。
また、ポリシーとしてはＣＰＵ−メモリ−Ｉ／Ｏ優先ということで、なるべく各コンポー
ネント間の距離が近くなるような配置を選ぶことになる。この場合は最初の仮想サーバで
あるため、まず必要なＩ／Ｏアダプタ１８０ａ、１８０ｃが接続されたＩ／Ｏハブ１６０
ａに近いＣＰＵソケット１１０ａを選択し、１１０ａ上のＣＰＵコアとＤＩＭＭを割り当
てることでこのポリシーは満足させることができる。

図３２〜図３４は、仮想サーバ２に対する、リソース割当ポリシー３５６だけが異なる
３つの論理ハードウェア要求Ｉ／Ｆ３５０を示している。全てに共通して、要求Ｉ／Ｏア
ダプタ３５３は１８０ｂ、要求ＣＰＵコア数３５４は１、要求メモリ量３５５は２ＧＢ、
優先度は５で共通である。図３２の論理ハードウェア要求Ｉ／Ｆ３５０ｈは リソース割
当ポリシー３５６として「信頼性優先」を指定している。図３３の論理ハードウェア要求
Ｉ／Ｆ３５０ｉはリソース割当ポリシー３５６として「帯域優先」を指定している。図３
４の論理ハードウェア要求Ｉ／Ｆ３５０ｊはリソース割当ポリシー３５６として「省電力
優先」を指定している。以下、各ポリシーに従って、どのような構成が選択されるのかを
見ていく。

図３５〜図３６は、２通りのリソース割当に対応した物理−論理ハードウェア割当表３
１０を示している。図３５の物理−論理ハードウェア割当表３１０ｈでは、ＣＰＵコアと
メモリとして、仮想サーバ１が使用しているのとは異なるＣＰＵソケット１１０ｂ上のＣ
ＰＵコア＃２とＤＩＭＭ＃４、５を割り当てて、要求された信頼性優先のポリシーを満足
している。一方、図３６の物理−論理ハードウェア割当表３１０ｉにおいては、仮想サー
バ１が使用しているのと同じＣＰＵソケット１１０ａ上のＣＰＵコア＃１とＤＩＭＭ＃２
、３を割り当てて、要求された帯域優先のポリシーを満足している。

割当ポリシーが、前述の実施形態までのような距離優先でない場合には、リソース割当
の基準として前記リソース間距離計算表６００に代わる別の指標が必要となる。

図３７〜図３８は、前記リソース間距離計算表６００に代わるコンポーネント・ネット
ワーク割当表６５０を示している。コンポーネント・ネットワーク割当表６５０は、複数
仮想サーバ間で共用しているコンポーネントやネットワーク、および実効ネットワーク帯
域を仮想マシンモニタ３００の論理ハードウェア割当処理部８０１が調べるための表であ
り、仮想サーバの識別子または連番を示す仮想サーバ＃３５１、仮想サーバ間で共用して
いるコンポーネントの識別子を示す共用コンポーネント＃６５１、共用しているコンポー
ネントを使用するために利用しているネットワークの識別子を示す共用ネットワーク＃６
５２の項目と、さらに各仮想サーバ内で使用しているネットワーク全てに対応して、ネッ
トワーク＃６５３、共用数６５４、実効帯域６５５、といった各項目から構成される。

図３７のコンポーネント・ネットワーク割当表６５０ｈは、図３５の物理−論理ハード
ウェア割当表３１０ｈのリソース割当に対応した表である。共用コンポーネント＃６５１
としてはＩ／Ｏハブ１６０ａが該当し、共用ネットワーク＃６５２は無しとなる。各ネッ
トワーク＃６５３に対して共用していないため共用数６５４は１となる。実効帯域６５５
は、物理ネットワーク構成表５５０の各ネットワーク＃５５５に対応した帯域５６０の値
を、共用数６５４（つまり仮想サーバの数）で割った値となる。この場合、共用数は１な
ので、ネットワークの帯域５６０の値がそのまま実効帯域６５５となる。

図３８のコンポーネント・ネットワーク割当表６５０ｉは、図３６の物理−論理ハード
ウェア割当表３１０ｉのリソース割当に対応した表である。共用コンポーネント＃６５１
としてはＩ／Ｏハブ１６０ａとＣＰＵソケット１１０ａが該当する。また、共用ネットワ
ーク＃６５２として、Ｉ／Ｏハブ１６０ａとＣＰＵソケット１１０ａを接続するネットワ
ーク＃５が相当する。この場合共用数６５４は２であるため、実効帯域６５５は元のネッ
トワークの帯域５６０の半分の値となる。

リソース割当ポリシー３５６が「信頼性優先」であった場合、共用コンポーネント数・
共用ネットワーク数がなるべく少なくなるような構成を選択する。この場合、仮想サーバ
１と仮想サーバ２の要求するＩ／Ｏアダプタが同じＩ／Ｏハブ１６０ａ上にあるため、共
用コンポーネント数を０とすることは不可能である。しかし物理−論理ハードウェア割当
表３１０ｈと３１０ｉにそれぞれ対応したコンポーネント・ネットワーク割当表６５０ｈ
、６５０ｉを比較した場合、図３５に示した物理−論理ハードウェア割当表３１０ｈに対
応する方が共用コンポーネント数が少ないことがわかる。従って要求されたポリシーが「
信頼性優先」である図３２の論理ハードウェア要求Ｉ／Ｆ３５０ｈの要求に対しては、図
３５に示した物理−論理ハードウェア割当表３１０ｈの割当が選択される。

リソース割当ポリシー３５６が「帯域優先」だった場合、ネットワークの実効帯域がな
るべく大きくなるような構成を選択する。この場合、図３７のコンポーネント・ネットワ
ーク割当表６５０ｈと６５０ｉを比較すると、コンポーネント・ネットワーク割当表６５
０ｈの構成の方が実効帯域が大きい。従ってポリシーが「帯域優先」である論理ハードウ
ェア要求Ｉ／Ｆ３５０ｉの要求に対しては、実効帯域が最大となる図３７の物理−論理ハ
ードウェア割当表３１０ｈの割当が選択される。

図３９は、要求されたポリシーが省電力優先の場合に用いられる図３５の物理−論理ハ
ードウェア割当表３１０ｈに対応した割当リソース消費電力計算表７００ｈを示している
。本表は仮想サーバ単位ではなく、システム全体で使用されているリソースとコンポーネ
ントに対して仮想マシンモニタ３００によって構成され、対象のハードウェアがリソース
かコンポーネントかを示すカテゴリ７０１、リソース種別／コンポーネント種別を示す７
０２、使用リソースまたはコンポーネントの識別子を示す使用リソース／コンポーネント
＃７０３、各リソース毎の消費電力を示す消費電力７０４、そして消費電力の総和７０５
から構成される。リソースとしてはＣＰＵコア、メモリ、Ｉ／Ｏスロット、Ｉ／Ｏアダプ
タの各項目があり、使用されているリソースが列挙されていく。また、消費電力７０４は
、物理コンポーネント構成表４００のリソース消費電力４３０、およびＩ／Ｏアダプタ構
成表４５０の消費電力４７５の項目を参照し、それぞれの値を設定する。カテゴリ７０１
がコンポーネントのエントリでは、各リソースを使用する際に必要となるコンポーネント
が列挙され、コンポーネントの消費電力７０４は、物理コンポーネント構成表４００のコ
ンポーネント消費電力４３５に従って設定される。消費電力の総和７０５は、消費電力７
０４の総和として仮想マシンモニタ３００によって計算される。

図４０は、図３６の物理−論理ハードウェア割当表３１０ｉに対応した割当リソース消
費電力計算表７００ｉを示している。使用しているリソースの数自体は物理−論理ハード
ウェア割当表３１０ｈと３１０ｉで変わらないため、リソースの項目は使用しているリソ
ースの番号＃こそ違うもののほとんど同じある。違いが出るのはコンポーネントの項目で
、物理−論理ハードウェア割当表３１０ｈでは使用するコンポーネントは合計３つであっ
たが、物理−論理ハードウェア割当表３１０ｉでは使用するコンポーネントは合計２つと
なっている。このため、消費電力の総和７０５を比較すると、図３９の割当リソース消費
電力計算表７００ｈでは３４５[Ｗ]という値なのに対して７００ｉでは２６５[Ｗ]という
値になっている。

論理ハードウェア要求Ｉ／Ｆ３５０のリソース割当ポリシー３５６が「省電力優先」だ
った場合、仮想マシンモニタ３００は消費電力の総和７０５がなるべく小さくなるような
割当方法を選択する。従って、ポリシーが「省電力優先」である図３４の論理ハードウェ
ア要求Ｉ／Ｆ３５０ｊの要求に対しては、仮想マシンモニタ３００の論理ハードウェア割
当処理部８０１は図３６の物理−論理ハードウェア割当表３１０ｉの割当を選択する。

図４１は、図３６の物理−論理ハードウェア割当表３１０ｈに対応する仮想サーバの構
成図である。

図４２は、図３７の物理−論理ハードウェア構成表３１０ｉに対応する仮想サーバの構
成図である。

以上が第一の実施形態の第二の変形例である。

なお、上記において消費電力を優先するポリシーの場合、消費電力に代わって各リソー
ス及びコンポーネントの発熱量を用いても良い。

＜第１実施形態１におけるリソース割当の具体的手順＞
ここで、第１の実施形態における、論理ハードウェア構成要求Ｉ／Ｆ３５０から物理−
論理ハードウェア構成表３１０を生成する手順について、図５５〜６２を用いて詳しく説
明する。

図５５は仮想マシンモニタ３００の論理ハードウェア割当処理部８０１で行われる論理
ハードウェア割当処理全体のフローチャートを示している。まず、ゲストＯＳ３６０に要
求されたＩ／Ｏアダプタを割り当て、さらに未割当のＣＰＵ・メモリの中から選んで割り
当て、要求されたポリシーに従って評価を行い、最も要求されたポリシーに近いＣＰＵ・
メモリの組み合わせを選ぶ、という手順となる。

まずステップ８００へと進む。仮想マシンモニタ３００の論理ハードウェア割当処理部
８０１は、物理−論理ハードウェア割り当て表３１０に、仮想サーバ３５１のエントリを
確保する。ステップ８０５へと進む。

ステップ８０５は、論理ハードウェア要求Ｉ／Ｆ３５０ａで要求されたＩ／Ｏアダプタ
３５３の割り当て要求が専有か共有かを判定する。判定の結果専有であればステップ８１
０へ、共有であればステップ８３０へと進む。

ステップ８１０は、要求されたＩ／Ｏアダプタ３５３が割り当て可能かを判定する。既
に他の仮想サーバに割り当てられていて割り当て不可である場合はステップ８２０へ、割
り当て可能であればステップ８３０へと進む。

ステップ８２０は、論理ハードウェア要求Ｉ／Ｆ３５０に対してエラーを応答するステ
ップである。エラー応答後、ステップ８９０へと進む。

ステップ８３０は、Ｉ／Ｏアダプタ割り当て処理となる。Ｉ／Ｏアダプタ割り当て処理
８３０のサブルーチンのフローは図５６に示す。このサブルーチンの完了後、ステップ８
４０へと進む。

ステップ８４０は、割り当て候補ＣＰＵ８４１と割り当て候補メモリ８４２を空集合（
Ф）に設定するステップである。ここで割り当て候補ＣＰＵ８４１と割り当て候補メモリ
８４２は、それまでの組み合わせの中で最も割り当てポリシーに近いＣＰＵとメモリの組
み合わせの候補を示す。この時点ではまだＣＰＵ・メモリは選んでいないため、空集合（
Ф）とする。ステップ８５０へと進む。

ステップ８５０は、未割り当てのＣＰＵ・メモリの中から要求を満たすＣＰＵ・メモリ
を選択する処理である。ＣＰＵ／メモリ選択処理８５０のサブルーチンのフローは図５７
に示す。このサブルーチンの完了時、エラー応答があった場合はステップ８２０へと進む
。そうでない場合はステップ８６０へと進む。

ステップ８６０は、ステップ８５０で選んだＣＰＵ・メモリに対して、割り当てポリシ
ーに従った評価を行うステップである。ポリシー評価８６０のサブルーチンのフローは図
５８に示す。このサブルーチンの完了後、ステップ８７０へと進む。

ステップ８７０は、未割り当てのＣＰＵ／メモリの組み合わせがまだあるか判定するス
テップである。まだ残っている場合はステップ８５０へと戻る。そうでない場合はステッ
プ８８０へと進む。

ステップ８８０は割当候補ＣＰＵ８４１と割当候補メモリ８４２を物理−論理ハードウ
ェア割当表３１０の仮想サーバ３５１へ割り当てる処理である。ＣＰＵ／メモリ割当処理
８８０のサブルーチンのフローは図６３に示す。このサブルーチンが完了すると論理ハー
ドウェア割当処理は完了となる。

ステップ８９０は、ステップ８５０で割り当ての途中でエラーとなった場合（またはス
テップ８１０で割り当てるリソースが足りなかった場合）に、物理−論理ハードウェア割
当表３１０の仮想サーバ３５１のエントリを抹消するステップである。このエントリの抹
消後、論理ハードウェア割当処理は完了となる。

図５６にＩ／Ｏアダプタ割当処理８３０のサブルーチンのフローを示す。まずステップ
９００へと進む。

ステップ９００は、論理ハードウェア要求Ｉ／Ｆ３５０ａのＩ／Ｏアダプタ３５３に対
応するＩ／Ｏアダプタ＃４５５をＩ／Ｏアダプタ構成表４５０から選択し、物理−論理ハ
ードウェア構成表３１０の仮想サーバ３５１のエントリの使用Ｉ／Ｏアダプタ３１２へ追
加するステップである。ステップ９０１へ進む。

ステップ９０１は、Ｉ／Ｏアダプタ３５３に対応するＩ／Ｏスロット＃４６５をＩ／Ｏ
アダプタ構成表４５０から選択し、物理コンポーネント構成表４００のリソース種別４１
０がＩ／ＯスロットのエントリからＩ／Ｏスロット＃４６５に対応するエントリを探し、
対応するコンポーネント４２０を物理−論理ハードウェア構成表３１０の仮想サーバ３５
１のエントリの使用コンポーネント３１５へ追加するステップである。ステップ９０２へ
進む。

ステップ９０２は、全てのＩ／Ｏアダプタ３５３を割り当てたか判定するステップであ
る。まだ割り当てていないアダプタが残っている場合はステップ９００へ戻る。そうでな
い場合はＩ／Ｏアダプタ割り当て処理８３０は完了となる。

図５７にＣＰＵ／メモリ選択処理８５０のサブルーチンのフローを示す。まずステップ
９０５へと進む。

ステップ９０５は、論理ハードウェア要求Ｉ／Ｆ３５０ａで要求されたＣＰＵコア数３
５４とメモリ量３５５が割り当て可能かどうか判定するステップである。割り当て不可能
である場合、ステップ９０７へと進む。割り当て可能ならばステップ９０６へと進む。

ステップ９０６は、未割り当ての組み合わせの中から、論理ハードウェア要求Ｉ／Ｆ３
５０ａで要求されたＣＰＵコア数３５４とメモリ量３５５を満たすＣＰＵコアとメモリを
選び、仮割当ＣＰＵ８５１と仮割当メモリ８５２に設定するステップである。これにより
ＣＰＵ／メモリ選択処理８５０は完了となる。

ステップ９０７は、エラー応答するステップである。これによってＣＰＵ／メモリ選択
処理８５０は完了となる。

図５８に、ポリシー評価８６０のサブルーチンのフローを示す。まずステップ９１０へ
と進む。

ステップ９１０は、論理ハードウェア要求Ｉ／Ｆ３５０ａの割り当てポリシー３５６に
従って条件分岐を行うステップである。割り当てポリシー３５６がＣＰＵ−メモリ優先、
ＣＰＵ−Ｉ／Ｏ優先、Ｉ／Ｏ−メモリ優先、ＣＰＵ−Ｉ／Ｏ−メモリ優先のいずれかであ
る場合、ステップ９２０へと進む。ポリシー３５６が信頼性優先である場合、ステップ９
３０へと進む。ポリシー３５６が帯域優先である場合、ステップ９４０へと進む。ポリシ
ー３５６が省電力優先である場合、ステップ９５０へと進む。

ステップ９２０はコンポーネント間距離算出処理である。図５９にサブルーチンのフロ
ーを示す。このサブルーチンの完了後ステップ９１１へと進む。

ステップ９３０はコンポーネント共有数算出処理である。図６０にサブルーチンのフロ
ーを示す。完了後ステップ９１１へと進む。

ステップ９４０は実効帯域算出処理である。図６１にサブルーチンのフローを示す。完
了後ステップ９１１へと進む。

ステップ９５０は消費電力算出処理である。図６２にサブルーチンのフローを示す。完
了後ステップ９１１へと進む。

ステップ９１１は、割当候補ＣＰＵ８４１と割当候補メモリ８４２が空集合（Ф）かど
うかを判定するステップである。空集合（Ф）である場合、ステップ９１３へ進む。そう
でない場合、ステップ９１２へ進む。

ステップ９１２は、割当候補ポリシー値８４３と比較して、仮割当ポリシー値８５３の
方が小さいかどうかを判定するステップである。ここでポリシー値とは、各割当ポリシー
３５６に従って、割り当てたリソース・コンポーネントの構成を定量的に評価するための
指数であり、小さい値である程より要求されたポリシーに近いと定義する。仮割当ポリシ
ー値８５３の方が割当候補ポリシー値８４３よりも小さい場合にはステップ９１３へと進
む。そうでない場合、ポリシー評価８６０は完了する。

ステップ９１３は、仮割当ＣＰＵ８５１、仮割当メモリ８５２、仮割当ポリシー値８５
３を、それぞれ割当候補ＣＰＵ８４１、割当候補メモリ８４２、割当候補ポリシー値８４
３へと代入するステップである。この処理によって、割当候補ＣＰＵ８４１、割当候補メ
モリ８４２、割当候補ポリシー値８４３には、これまで割り当てた中で最もポリシー値が
小さな組み合わせのＣＰＵ・メモリの組み合わせが保持される。この処理により、ポリシ
ー評価８６０は完了する。

なお、図５８のステップ９１３において、割当候補ポリシー値８４３は仮割当ポリシー
値８５３の値を引き継ぐ形で設定されまており、初回のステップ９１２では割当候補ポリ
シー値８４３の初期値は不定となるが、初回は図５５のステップ８４０において、割当候
補ＣＰＵ８４１と割当候補メモリ８４２がФに設定されるので、ステップ９１１の判定に
て必ずステップ９１３へと向かうことになり、ステップ９１２は通過しない。なお、割当
候補ポリシー値８４３を所定の最大値で初期化しておいてもよい。

図５９にコンポーネント間距離算出９２０のサブルーチンのフローを示す。まずステッ
プ９２１へと進む。

ステップ９２１は、論理ハードウェア要求Ｉ／Ｆ３５０ａの仮想サーバ３５１のＩ／Ｏ
アダプタ３５３と、仮割当ＣＰＵ８５１と、仮割当メモリ８５２とを使って、リソース間
距離計算表６００を作成するステップである。具体的には、
（１） 各リソースの所属するコンポーネントを物理コンポーネント構成表４００より求
める。
（２） 各コンポーネント間の距離をコンポーネント間距離対応表５００に従い、リソー
ス間距離計算表６００のコンポーネント間距離６０４へと設定する。
（３） カテゴリ６０１別にコンポーネント間距離６０４の合計を求めΣ６０５へと代入
する。
といった処理から構成される。次に、ステップ９２２へと進む。

ステップ９２２は、論理ハードウェア要求Ｉ／Ｆ３５０ａの割当ポリシー３５６に従っ
て条件分岐を行うステップである。ポリシー３５６がＣＰＵ−メモリ優先である場合、ス
テップ９２３へと進む。ポリシー３５６がＣＰＵ−Ｉ／Ｏ優先である場合、ステップ９２
４へと進む。ポリシー３５６がＩ／Ｏ−メモリ優先である場合、ステップ９２５へと進む
。ポリシー３５６がＣＰＵ−Ｉ／Ｏ−メモリ優先である場合、ステップ９２６へと進む。

ステップ９２３は、リソース間距離計算表６００のカテゴリ６０１のＣＰＵ−メモリに
対応するΣ６０５を仮割当ポリシー値８５３とするステップである。これによりコンポー
ネント間距離算出９２０は完了する。

ステップ９２４は、リソース間距離計算表６００のカテゴリ６０１のＣＰＵ−Ｉ／Ｏに
対応するΣ６０５を仮割当ポリシー値８５３とするステップである。これによりコンポー
ネント間距離算出９２０は完了する。

ステップ９２５は、リソース間距離計算表６００のカテゴリ６０１のＩ／Ｏ−メモリに
対応するΣ６０５を仮割当ポリシー値８５３とするステップである。これによりコンポー
ネント間距離算出９２０は完了する。

ステップ９２６は、リソース間距離計算表６００の全てのカテゴリ６０１のΣ６０５の
合計を仮割当ポリシー値８５３とするステップである。これによりコンポーネント間距離
算出９２０は完了する。

図６０に、コンポーネント共用数算出９３０のサブルーチンのフローを示す。まずステ
ップ９３１へと進む。

ステップ９３１は、論理ハードウェア要求Ｉ／Ｆ３５０ａのＩ／Ｏアダプタ３５３と、
仮割当ＣＰＵ８５１と、仮割当メモリ８５２とを使った仮想サーバ３５１を含む、全ての
割当済みの仮想サーバに対して、コンポーネント・ネットワーク割当表６５０を作成する
ステップである。具体的には、
（１） 各リソースの所属するコンポーネントを物理コンポーネント構成表４００より求
める。
（２） 異なる仮想サーバ間で共用されるコンポーネントを共用コンポーネント＃６５１
へと設定する。
（３） 共用コンポーネント＃の数を共用数６５４へと設定する。
といった処理から構成される。ステップ９３２へと進む。
ステップ９３２は、コンポーネント・ネットワーク割当表６５０の仮想サーバ３５１に対
応する共用数６５４を仮割当ポリシー値８５３とするステップである。これによりコンポ
ーネント共用数算出９３０は完了する。

図６１に、実効帯域算出９４０のサブルーチンのフローを示す。まずステップ９４１へ
と進む。

ステップ９４１は、論理ハードウェア要求Ｉ／Ｆ３５０ａのＩ／Ｏアダプタ３５３と、
仮割当ＣＰＵ８５１と、仮割当メモリ８５２とを使った仮想サーバ３５１を含む、全ての
割当済みの仮想サーバに対して、コンポーネント・ネットワーク割当表６５０を作成する
ステップである。具体的には、
（１） 各リソースの所属するコンポーネントを物理コンポーネント構成表４００より求
める。
（２） コンポーネント間で使用するネットワークを物理ネットワーク構成表５５０より
求め、ネットワーク＃６５３へと設定する。
（３） 異なる仮想サーバ間で共用されるネットワーク＃６５３共用ネットワーク＃６５
２へと設定する。
（４） 各ネットワークの帯域を物理ネットワーク構成表５５０の帯域５６０より求め、
これを共有数６５４で割った値を実効帯域６５５へと設定する、
といった処理を含む。ステップ９４２へと進む。

ステップ９４２は、コンポーネント・ネットワーク割当表６５０の仮想サーバ３５１に
対応する実効帯域６５５のマイナスを仮割当ポリシー値８５３とするステップである。こ
こでポリシー値８５３は小さいほどより要求したポリシーに近いと定義されている。一方
、実効帯域の絶対値は大きいほど良い。そこで実効帯域の値をマイナスとした値を仮割当
ポリシー値８５３とすることで、最も実効帯域の大きな構成が最終的には選ばれるように
している。これにより、実行帯域算出９４０は完了である。

図６２に、消費電力算出９５０のサブルーチンのフローを示す。まずステップ９５１へ
と進む。

ステップ９５１は、論理ハードウェア要求Ｉ／Ｆ３５０ａのＩ／Ｏアダプタ３５３と、
仮割当ＣＰＵ８５１と、仮割当メモリ８５２とを使った仮想サーバ３５１を含む、全ての
割当済みの仮想サーバに対して、割当リソース消費電力計算表７００を計算するステップ
である。具体的には、
（１） 各リソースの所属するコンポーネントを物理コンポーネント構成表４００より求
める。
（２） 物理コンポーネント構成表４００から、割当済の全てのリソースのリソース消費
電力４３０およびコンポーネントについて消費電力を求め、計算表７００の消費電力７０
４へと設定。
（３）全ての消費電力７０４の合計を計算しΣ７０５へと設定。
といった処理を含む。ステップ９５２へと進む。

ステップ９５２は、割当リソース消費電力計算表７００の消費電力合計７０５を仮割当
ポリシー値８５３とするステップである。これにより、消費電力算出９５０は完了する。

図６３に、ＣＰＵ／メモリ割当処理８８０のサブルーチンのフローを示す。まずステッ
プ９６０へと進む。

ステップ９６０は、割当候補ＣＰＵ８４１を物理−論理ハードウェア構成表３１０の仮
想サーバ３５１のエントリの使用ＣＰＵコア３１３へ、割当候補メモリ８４２を使用メモ
リ３１４へ追加するステップである。ステップ９６１へと進む。

ステップ９６１は、物理コンポーネント構成表４００のリソース種別４１０がＣＰＵコ
アのエントリからＣＰＵコア３１３に対応するエントリを探し、対応するコンポーネント
４２０を物理−論理ハードウェア構成表３１０の仮想サーバ３５１のエントリの使用コン
ポーネント３１５へ追加し、同じくリソース種別４１０がメモリのエントリからメモリ３
１４に対応するエントリの使用コンポーネント３１５へ追加するステップである。ステッ
プ９６２へと進む。

ステップ９６２は、全ての割当候補ＣＰＵ８４１および割当候補メモリ８４２を割り当
てたかどうか判定するステップである。まだ未割当の割当候補ＣＰＵ８４１または割当候
補メモリ８４２が残っている場合はステップ９６０へと戻る。そうでなければＣＰＵ／メ
モリ割当処理８８０は完了する。

以上の一連の動作により、仮想マシンモニタ３００は、コンソール２３０から指示され
た論理ハードウェア要求Ｉ／Ｆ３５０から、物理−論理ハードウェア割当表３１０を作る
ことができる。

以上のように本第１実施形態によれば、仮想マシンモニタ３００は、マルチプロセッサ
システム１００内のコンポーネントの物理的な位置情報を示すコンポーネント間の距離を
取得して、コンポーネント間距離対応表５００を予め設定し、また、物理的なネットワー
クの構成や各リソースの消費電力を取得して物理コンポーネント構成表４００とＩ／Ｏア
ダプタ構成表４５０及び物理ネットワーク構成表を予め設定しておく。そして、仮想マシ
ンモニタ３００は、コンソール２３０から仮想サーバの生成（または設定）要求である論
理ハードウェア要求Ｉ／Ｆ３５０を受け付けて、まず、要求されたＩ／Ｏアダプタ１８０
を選択し、要求された仮想サーバへＩ／Ｏアダプタ１８０の専有割当を行う。次に、仮想
マシンモニタ３００は、仮想サーバに上記コンポーネント間距離対応表５００や物理コン
ポーネント構成表４００からリソースの物理的な位置情報や消費電力を参照し、専有割当
を行ったＩ／Ｏデバイスから、要求されるポリシーを満たすＣＰＵとメモリを選択して仮
想サーバに割り当てることで、要求されたポリシーに対して最適の仮想サーバを提供する
ことができる。

特に、一つの物理計算機で複数の仮想サーバ（ゲストＯＳ）を稼動させる場合、仮想サ
ーバ毎にポリシーが異なっても、Ｉ／Ｏデバイス、ＣＰＵソケット、メモリの物理的な位
置情報から各仮想サーバに最適な構成を自動的に割り当てることが可能となり、仮想計算
機の可用性を向上させることが可能となるのである。

＜第２実施形態＞（論理ハードウェア構成通知Ｉ／Ｆ）
図４３〜図４８にて本発明の第２の実施形態を示す。なお、本第２の実施形態のマルチ
プロセッサシステム１００の構成は、前記第１実施形態と同様である。

図４３は仮想サーバ１＿３７０ａの論理ハードウェア要求Ｉ／Ｆ３５０ｋを示している
。論理ハードウェア要求Ｉ／Ｆ３５０ｋでは、４つのＣＰＵコアと８ＧＢのメモリ、Ｉ／
Ｏアダプタとして１８０ｄと１８０ｆを要求している。

図４４は上記図４３の論理ハードウェア要求Ｉ／Ｆ３５０ｋに対応した物理−論理ハー
ドウェア割当表３１０ｋを示している。図４５に図１のマルチプロセッサシステム１００
上に割り当てた仮想サーバ１＿３７０ａの配置を示す。図中点線で囲まれた部分が仮想サ
ーバ１＿３７０ａである。

ここで仮想サーバ１＿３７０ａ上のゲストＯＳ１＿３６０ａの動作について考える。ゲ
ストＯＳ１＿３６０ａはマルチプロセッサシステム１００上のＯＳであり、上述のような
ＡＣＰＩに準拠したＣＰＵとメモリに関するAffinity制御の機能を持っているとする。Af
finity制御の機能により、ゲストＯＳ３６０上のアプリケーションに対してＣＰＵソケッ
ト１１０ｃ上のＣＰＵコア＃４、５とＤＩＭＭ＃８、９、１０、１１を割り当てる、ある
いはＣＰＵソケット１１０ｄ上のＣＰＵコア＃６、７とＤＩＭＭ＃１２、１３、１４、１
５を割り当てることにより、ＣＰＵコアからメモリへのアクセスのレイテンシを短くし、
性能向上を図る。しかしこのようなAffinity制御の機能を使うためには、ゲストＯＳ１＿
３６０ａが仮想サーバ１のハードウェアの配置を知っている必要がある。そのために、仮
想マシンモニタ３００からゲストＯＳ３６０への構成情報通知Ｉ／Ｆ（論理ハードウェア
構成情報通知Ｉ／Ｆ３４０）が必要となる。

図４６に仮想マシンモニタ３００上にある物理ハードウェア構成情報７５０を示す。こ
れは物理−論理ハードウェア割当表３１０から二次的に作られる情報であり、ＣＰＵコア
１２０の識別子または連番を示すホストＣＰＵコア＃７５１、割り当てたメモリ１５０の
物理アドレスの始点を示すホスト物理アドレスベース７５２、および割り当てたメモリ１
５０の量を示すホスト物理アドレス範囲７５３から成る。しかしこの情報をそのままゲス
トＯＳ１＿３６０ａに対して通知しても、ゲストＯＳ１＿３６０ａは正しくAffinity制御
を行うことはできない。なぜならば、仮想マシンモニタ３００がゲストＯＳ３６０ａに割
り当てたマルチプロセッサシステム１００上のホスト物理アドレスベースと、ゲストＯＳ
１＿３６０ａにおけるゲスト物理アドレスベースとは異なるからである。

図４８にホスト物理アドレス空間とゲスト物理アドレス空間の関係を示す。ホスト物理
アドレスベースの０ｘ２＿００００＿００００に対してゲストＯＳ１＿３６０ａを割り当
てた場合、ゲスト物理アドレスベースの０ｘ０＿００００＿００００がホスト物理アドレ
スベースの０ｘ２＿００００＿００００に相当するようにアドレスのずれが生じる。従っ
て、論理ハードウェア構成情報をゲストＯＳ１＿３６０ａに対して通知する場合には、こ
のずれを考慮して通知する必要がある。

図４７に仮想マシンモニタ３００からゲストＯＳ１＿３６０ａに対する論理ハードウェ
ア構成情報通知Ｉ／Ｆ３４０を示す。論理ハードウェア構成情報通知Ｉ／Ｆ３４０は、ゲ
ストＯＳ３６０に割り当てたＣＰＵコア１２０の識別子または連番を示すゲストＣＰＵコ
ア＃３４１、ゲストＯＳ３６０に割り当てたベースアドレスを示すゲスト物理アドレスベ
ース３４２、ゲストＯＳ３６０に割り当てたアドレス範囲を示すゲスト物理アドレス範囲
３４３から成る。図４７においてゲストＣＰＵコア＃３４１は、ゲストＯＳ３６０内で０
から順番に付け直す。ゲスト物理アドレスベース３４２は、ホスト物理アドレスベース７
５２から、仮想サーバ１＿３７０ａのベースアドレス０ｘ２＿００００＿００００を引い
た値とする。ゲスト物理アドレス範囲３４３は、ホスト物理アドレス範囲７５３と同じ値
とする。以上により、ゲストＯＳ１＿３６０ａがＡＣＰＩに準拠したAffinity制御のため
に利用可能な使用論理ハードウェア構成情報が作られる。仮想マシンモニタ３００は、こ
の論理ハードウェア構成情報通知Ｉ／Ｆ３４０を生成してゲストＯＳ３６０に通知する。
なお、ここではＣＰＵ＃３４１とメモリのアドレス範囲の組だけを通知するとしたが、よ
り高度な情報（たとえばリソース間距離計算表６００のような距離の情報まで含めた）を
通知することも可能である。その場合でも、ホスト物理アドレスをゲスト物理アドレスへ
と変換する、という原則は変わらない。

以上のように本発明の第二の実施形態によれば仮想マシンモニタ３００が適切なリソー
スを仮想サーバに対して割り当てて、仮想サーバ上のゲストＯＳ３６０は仮想マシンモニ
タ３００が生成した論理ハードウェア構成情報通知Ｉ／Ｆ３４０を取得することで、使用
するコンポーネントの物理位置情報を正しく利用することが可能となって、ゲストＯＳ３
６０のAffinity制御を正しく動作させて、物理サーバと同等の性能や信頼性を確保するこ
とが可能となる。

＜第３実施形態＞（リソースの再割当）
図４３〜図４５および図４９〜図５４を使って、本発明の第三の実施形態を説明する。
前記第二の実施形態と同じく、図４３に示す論理ハードウェア要求Ｉ／Ｆ３５０ｋに従っ
て、仮想マシンモニタ３００が図４４に示す物理−論理ハードウェア割当表３１０ｋのよ
うに仮想サーバ１＿３７０ａを割り当てた結果を図４５に示す。

仮想サーバ１＿３７０ａが図４５のように割り当てられた状態で、図４９に示す仮想サ
ーバ２に関する論理ハードウェア要求Ｉ／Ｆ３５０ｍがコンソール２３０から仮想マシン
モニタ３００へ入力されたと仮定する。図４９の論理ハードウェア要求Ｉ／Ｆ３５０ｍで
は、優先度３５７が１０となっており、仮想サーバ１の論理ハードウェア要求Ｉ／Ｆ３５
０ｋの優先度５よりも大きな値となっている。この場合、より優先度の高い仮想サーバ２
のリソース割当ポリシーを満たすように、仮想サーバ１に既に割り当てられたリソースを
再配置することが仮想マシンモニタ３００に求められる。

図５０は仮想サーバ１＿３７０ａに割当済みのリソースをそのままにして、仮想マシン
モニタ３００が仮想サーバ２＿３７０ｂに対してリソースを割り当てた場合の物理−論理
ハードウェア割当表３１０ｍを示す。また、図５１に仮想サーバ１＿３７０ａから割当済
みのリソースを一旦取り上げ、仮想サーバ２＿３７０ｂに対してリソースを割り当てた後
で仮想サーバ１＿３７０ａに改めてリソースを割り当てた場合の物理−論理ハードウェア
割当表３１０ｎを示す。また、図５２に図５０の物理−論理ハードウェア割当表３１０ｍ
に従って計算したリソース間距離計算表６００ｍを示し、図５３に図５１の物理−論理ハ
ードウェア割当表３１０ｎに従って計算したリソース間距離計算表６００ｎを示す。

図４９の論理ハードウェア要求Ｉ／Ｆ３５０ｍのリソース割当ポリシー３５６は「Ｉ／
Ｏ−メモリ優先」となっており、リソース間距離計算表６００の「Ｉ／Ｏ−メモリ」のコ
ンポーネント間距離の総和６０５を比較すると、図５２の計算表６００ｍでは２なのに対
して図５３の計算表６００ｎでは１となっており、リソースの再配置を行った方が、より
仮想サーバ２のリソース割当ポリシーを満たす配置が可能となっていることがわかる。図
５４に物理−論理ハードウェア割当表３１０ｎに従って仮想マシンモニタ３００がマルチ
プロセッサシステム１００上に仮想サーバ１＿３７０ａと仮想サーバ２＿３７０ｂを割り
当てた様子を示す。

このように、優先度が異なる複数の論理ハードウェア要求がある場合、優先度の高い論
理ハードウェア要求Ｉ／Ｆ３５０から順にリソースを割り当てることで、より優先度の高
い要求に対して優先的にリソースを割り当てることが可能となる。ただし、リソースの再
配置を行う場合には、ＣＰＵおよびメモリの移動が必要となるケースがある。ＣＰＵの移
動に関しては、レジスタの内容のコピー、キャッシュやＴＬＢのフラッシュ、等が必要に
なり、またメモリの移動に関してはメモリのコピーが必要となる。ＣＰＵやメモリの具体
的な移動手法については公知または周知の手法を適用すればよい。

以上のように、本発明の第三の実施形態によれば、新たに仮想サーバをマルチプロセッ
サシステム１００へ割り当てる際に、既に割り当てたリソースを一旦解放させてから、仮
想サーバの優先度の高い順にリソースの再割当を行うことで、より最適な仮想サーバを構
成することが可能となる。

以上のように、本発明は複数のプロセッサやＩ／Ｏデバイスによって構成され、複数の
仮想サーバに分割された計算機システムおよびその仮想マシンモニタに対して適用できる
。

第１の実施形態を示し、本発明を適用するマルチプロセッサシステムと仮想マシンモニタの構成を示すブロック図。 第１の実施形態を示し、物理ハードウェア構成情報取得Ｉ／Ｆの構成を示す説明図。 第１の実施形態を示し、物理コンポーネント構成表の構成を示す説明図。 第１の実施形態を示し、Ｉ／Ｏアダプタ構成表の構成を示す説明図。 第１の実施形態を示し、コンポーネント間距離対応表の構成を示す説明図。 第１の実施形態を示し、物理ネットワーク構成表の構成を示す説明図。 第１の実施形態を示し、仮想サーバ１の論理ハードウェア要求Ｉ／Ｆの構成を示す説明図。 第１の実施形態を示し、仮想サーバ１の物理−論理ハードウェア割当表の構成を示す説明図。 第１の実施形態を示し、マルチプロセッサシステム上の仮想サーバ１の一例を示すブロック図。 第１の実施形態を示し、ポリシーをＣＰＵ−メモリ優先とした仮想サーバ２の論理ハードウェア要求Ｉ／Ｆの構成を示す説明図。 第１の実施形態を示し、ポリシーをＩ／Ｏ−メモリ優先とした仮想サーバ２の論理ハードウェア要求Ｉ／Ｆの構成を示す説明図。 第１の実施形態を示し、ポリシーをＣＰＵ−メモリ優先とした仮想サーバ２の物理−論理ハードウェア割当表の構成を示す説明図。 第１の実施形態を示し、ポリシーをＩ／Ｏ−メモリ優先とした仮想サーバ２の論理ハードウェア要求Ｉ／Ｆの構成を示す説明図。 第１の実施形態を示し、ポリシーをＣＰＵ−メモリ優先とした仮想サーバ２のリソース間距離計算表の構成を示す説明図。 第１の実施形態を示し、ポリシーをＩ／Ｏ−メモリ優先とした仮想サーバ２のリソース間距離計算表の構成を示す説明図。 第１の実施形態を示し、ポリシーをＣＰＵ−メモリ優先としたマルチプロセッサシステム上の仮想サーバ１，２の構成を示すブロック図。 第１の実施形態を示し、ポリシーをＩ／Ｏ−メモリ優先としたマルチプロセッサシステム上の仮想サーバ１，２の構成を示すブロック図。 第１の変形例を示し、論理ハードウェア要求Ｉ／Ｆの構成を示す説明図。 第１の変形例を示し、物理−論理ハードウェア割当表の構成を示す説明図。 第１の変形例を示し、マルチプロセッサシステム上の仮想サーバ１の構成を示すブロック図。 第１の変形例を示し、ポリシーをＣＰＵ−メモリ優先とした仮想サーバ２の論理ハードウェア要求Ｉ／Ｆの構成を示す説明図。 第１の変形例を示し、ポリシーをＣＰＵ−Ｉ／Ｏ優先とした仮想サーバ２の論理ハードウェア要求Ｉ／Ｆの構成を示す説明図。 第１の変形例を示し、ポリシーをＣＰＵ−メモリ優先とした仮想サーバ２の物理−論理ハードウェア割当表の構成を示す説明図。 第１の変形例を示し、ポリシーをＣＰＵ−Ｉ／Ｏ優先とした仮想サーバ２の物理−論理ハードウェア割当表の構成を示す説明図。 第１の変形例を示し、ポリシーをＣＰＵ−メモリ優先とした仮想サーバ２のリソース間距離計算表の構成を示す説明図。 第１の変形例を示し、ポリシーをＣＰＵ−Ｉ／Ｏ優先とした仮想サーバ２のリソース間距離計算表の構成を示す説明図。 第１の変形例を示し、ポリシーをＣＰＵ−メモリ優先とした場合のマルチプロセッサシステム上の仮想サーバ１、２のブロック図。 第１の変形例を示し、ポリシーをＣＰＵ−Ｉ／Ｏ優先とした場合のマルチプロセッサシステム上の仮想サーバ１、２のブロック図。 第２の変形例を示し、仮想サーバ１の論理ハードウェア要求Ｉ／Ｆの構成を示す説明図。 第２の変形例を示し、仮想サーバ１の物理−論理ハードウェア割当表の構成を示す説明図。 第２の変形例を示し、マルチプロセッサシステム上の仮想サーバ１の構成を示すブロック図。 第２の変形例を示し、ポリシーを信頼性優先とした仮想サーバ２の論理ハードウェア要求Ｉ／Ｆの構成を示す説明図。 第２の変形例を示し、ポリシーを帯域優先とした仮想サーバ２の論理ハードウェア要求Ｉ／Ｆの構成を示す説明図。 第２の変形例を示し、ポリシーを省電力優先とした仮想サーバ２の論理ハードウェア要求Ｉ／Ｆの構成を示す説明図。 第２の変形例を示し、ポリシーを信頼性優先とした仮想サーバ１、２の物理−論理ハードウェア割当表の構成を示す説明図。 第２の変形例を示し、ポリシーを帯域優先とした仮想サーバ１，２の物理−論理ハードウェア割当表の構成を示す説明図。 第２の変形例を示し、ポリシーを信頼性優先とした仮想サーバ１、２のコンポーネント・ネットワーク割当表の構成を示す説明図。 第２の変形例を示し、ポリシーを帯域優先とした仮想サーバ１、２のコンポーネント・ネットワーク割当表の構成を示す説明図。 第２の変形例を示し、ポリシーを信頼性優先とした場合の割当リソース消費電力計算表の構成を示す説明図。 第２の変形例を示し、ポリシーを消費電力優先とした場合のコンポーネント・ネットワーク割当表の構成を示す説明図。 第２の変形例を示し、ポリシーを信頼性優先とした仮想サーバ１、２のマルチプロセッサシステム上のブロック図。 第２の変形例を示し、ポリシーを帯域優先とした仮想サーバ１、２のマルチプロセッサシステム上のブロック図。 第２の実施形態を示し、仮想サーバ１の論理ハードウェア要求Ｉ／Ｆの構成を示す説明図。 第２の実施形態を示し、仮想サーバ１の物理−論理ハードウェア割当表の構成を示す説明図。 第２の実施形態を示し、マルチプロセッサシステム上の仮想サーバ１の構成を示すブロック図。 第２の実施形態を示し、物理ハードウェア構成情報の構成を示す説明図。 第２の実施形態を示し、論理ハードウェア構成情報通知Ｉ／Ｆの構成を示す説明図。 第２の実施形態を示し、ホスト物理アドレスとゲスト物理アドレスの関係を示すマップ。 第３の実施形態を示し、仮想サーバ２の論理ハードウェア要求Ｉ／Ｆの構成を示す説明図。 第２の実施形態を示し、仮想サーバ１、２の物理−論理ハードウェア割当表の構成を示す説明図。 第２の実施形態を示し、仮想サーバ１、２の物理−論理ハードウェア割当表の他の構成を示す説明図。 第２の実施形態を示し、仮想サーバ２のリソース消費電力計算表の構成を示す説明図。 第２の実施形態を示し、仮想サーバ２のリソース消費電力計算表の他の構成を示す説明図。 第２の実施形態を示し、マルチプロセッサシステム上の仮想サーバ１、２を示すブロック図。 第１の実施形態を示し、仮想マシンモニタで行われる論理ハードウェア割当処理の一例を示すフローチャート。 第１の実施形態を示し、同じく論理ハードウェア割当処理のＩ／Ｏアダプタ割り当て処理のサブルーチンを示すフローチャート。 第１の実施形態を示し、同じく論理ハードウェア割当処理のＣＰＵ及びメモリ選択処理のサブルーチンを示すフローチャート。 第１の実施形態を示し、同じく論理ハードウェア割当処理のポリシー評価処理のサブルーチンを示すフローチャート。 第１の実施形態を示し、同じく論理ハードウェア割当処理のコンポーネント間距離算出処理のサブルーチンを示すフローチャート。 第１の実施形態を示し、同じく論理ハードウェア割当処理のコンポーネント共用数算出処理のサブルーチンを示すフローチャート。 第１の実施形態を示し、同じく論理ハードウェア割当処理の実効帯域算出処理のサブルーチンを示すフローチャート。 第１の実施形態を示し、同じく論理ハードウェア割当処理の消費電力算出処理のサブルーチンを示すフローチャート。 第１の実施形態を示し、同じく論理ハードウェア割当処理のＣＰＵ及びメモリ割り当て処理のサブルーチンを示すフローチャート。 第１の実施形態を示し、マルチプロセッサシステムの構成図。

符号の説明

１００ マルチプロセッサシステム
１１０ ＣＰＵソケット
１２０ ＣＰＵコア
１３０ メモリコントローラ
１４０ メモリインタフェース
１５０ メモリ
１６０ Ｉ／Ｏハブ
１７０ Ｉ／Ｏ接続インタフェース
１８０ Ｉ／Ｏアダプタ
１９０ Ｉ／Ｏデバイス
２００ モジュール間接続インタフェース
２１０ モジュール情報取得インタフェース
２２０ サービスプロセッサ
３００ 仮想マシンモニタ
３１０ 物理−論理ハードウェア割当表
３２０ 物理ハードウェア構成情報取得インタフェース
３３０ 物理−論理ハードウェア割当インタフェース
３４０ 論理ハードウェア構成情報通知インタフェース
３５０ 論理ハードウェア要求インタフェース
４００ 物理コンポーネント構成表
５００ コンポーネント間距離対応表
５５０ 物理ネットワーク構成表
６００ リソース間距離計算表
６５０ コンポーネント・ネットワーク割当表
７００ 割当リソース消費電力系計算表
７５０ 物理ＨＷ構成情報
８０１ 論理ハードウェア割当処理部

Claims (17)

1. １つ以上のプロセッサと、１つ以上のメモリと１つ以上のＩ／Ｏデバイスとを内部ネットワークで接続したマルチプロセッサシステム上で仮想サーバを稼働させる仮想マシンモニタであって、
   前記仮想マシンモニタは、
   前記マルチプロセッサシステムの前記プロセッサとメモリとＩ／Ｏデバイス及びネットワークを含むハードウェアの物理的な位置情報を含むハードウェアの構成情報を取得する物理ハードウェア情報取得部と、
   生成する仮想サーバのプロセッサの数とメモリ量とＩ／Ｏデバイス及びリソースの割り当てポリシーとを含む生成要求を受け付ける受付部と、
   前記受け付けた生成要求に基づいてＩ／Ｏデバイスを前記仮想サーバに割り当ててから、前記割り当てポリシーを満たすように前記プロセッサとメモリを前記仮想サーバに割り当てる割り当て処理部と、
   を備えたことを特徴とする仮想マシンモニタ。
2. 前記仮想マシンモニタは、
   前記仮想サーバに対して割り当てたプロセッサとメモリ及びＩ／Ｏデバイスの物理的な位置情報を前記仮想サーバに通知する通知部をさらに備えたことを特徴とする請求項１に記載の仮想マシンモニタ。
3. 前記受付部が、第２の仮想サーバの生成要求を受け付け、
   前記割り当て処理部は、
   前記仮想サーバに対して既に割り当てたプロセッサとメモリ及びＩ／Ｏデバイスの物理的な位置情報を保存し、前記第２の仮想サーバの生成要求に含まれるプロセッサの数とメモリ量及びＩ／Ｏデバイスの情報とリソース割当ポリシーから、前記マルチプロセッサ上で割り当て可能なプロセッサとメモリ及びＩ／Ｏデバイスの位置情報に基づいて、当該第２の仮想サーバに前記利用可能なＩ／Ｏデバイスとプロセッサ及びメモリを割り当てて、前記割り当て済みの仮想サーバのリソースの割当ポリシーに基づいて当該仮想サーバのプロセッサとメモリを再配置することを特徴とする請求項１に記載の仮想マシンモニタ。
4. 前記物理ハードウェア情報取得部は、前記ハードウェアの物理的な位置情報からプロセッサとメモリ及びＩ／Ｏデバイスの距離を求め、
   前記割り当て処理部は、
   前記リソースの割当ポリシーに基づいて前記プロセッサとメモリ及びＩ／Ｏデバイスの距離の総和が最小となるように、前記仮想サーバへプロセッサとメモリ及びＩ／Ｏデバイスを割り当てることを特徴とする請求項１に記載の仮想マシンモニタ。
5. 前記割り当て処理部は、
   前記ひとつのＩ／Ｏデバイスをひとつの仮想サーバに割り当てることを特徴とする請求項１に記載の仮想マシンモニタ。
6. １つ以上のプロセッサと、１つ以上のメモリと１つ以上のＩ／Ｏデバイスとを内部ネットワークで接続し、前記プロセッサとメモリ及びＩ／Ｏデバイスを仮想サーバに割り当てる仮想マシンモニタを備えたマルチプロセッサシステムであって、
   前記仮想マシンモニタは、
   前記マルチプロセッサシステムの前記プロセッサとメモリとＩ／Ｏデバイス及びネットワークを含むハードウェアの物理的な位置情報を含むハードウェアの構成情報を取得する物理ハードウェア情報取得部と、
   生成する仮想サーバのプロセッサの数とメモリ量とＩ／Ｏデバイス及びリソースの割り当てポリシーとを含む生成要求を受け付ける受付部と、
   前記受け付けた生成要求に基づいてＩ／Ｏデバイスを前記仮想サーバに割り当ててから、前記割り当てポリシーを満たすように前記プロセッサとメモリを前記仮想サーバに割り当てる割り当て処理部と、
   を備えたことを特徴とするマルチプロセッサシステム。
7. 前記物理ハードウェア情報取得部は、前記ハードウェアの物理的な位置情報からプロセッサとメモリ及びＩ／Ｏデバイスの距離を求め、
   前記割り当て処理部は、
   前記リソースの割当ポリシーが、プロセッサのメモリへのアクセスを優先する場合には、前記プロセッサとメモリの距離の総和が最小となるように、前記仮想サーバへプロセッサとメモリ及びＩ／Ｏデバイスを割り当てることを特徴とする請求項６に記載のマルチプロセッサシステム。
8. 前記物理ハードウェア情報取得部は、前記ハードウェアの物理的な位置情報からプロセッサとメモリ及びＩ／Ｏデバイスの距離を求め、
   前記割り当て処理部は、
   前記リソースの割当ポリシーが、プロセッサとＩ／Ｏデバイスのアクセスを優先する場合には、前記プロセッサとＩ／Ｏデバイスの距離の総和が最小となるように、前記仮想サーバへプロセッサとメモリ及びＩ／Ｏデバイスを割り当てることを特徴とする請求項６に記載のマルチプロセッサシステム。
9. 前記物理ハードウェア情報取得部は、前記ハードウェアの物理的な位置情報からプロセッサとメモリ及びＩ／Ｏデバイスの距離を求め、
   前記割り当て処理部は、
   前記リソースの割当ポリシーが、メモリとＩ／Ｏデバイスのアクセスを優先する場合には、前記メモリとＩ／Ｏデバイスの距離の総和が最小となるように、前記仮想サーバへプロセッサとメモリ及びＩ／Ｏデバイスを割り当てることを特徴とする請求項６に記載のマルチプロセッサシステム。
10. 前記物理ハードウェア情報取得部は、前記ハードウェアの物理的な位置情報からプロセッサとメモリ及びＩ／Ｏデバイスの距離を求め、
    前記割り当て処理部は、
    前記リソースの割当ポリシーが、仮想サーバの全体の性能を確保する場合には、前記プロセッサとメモリ及びＩ／Ｏデバイスの距離の総和が最小となるように、前記仮想サーバへプロセッサとメモリ及びＩ／Ｏデバイスを割り当てることを特徴とする請求項６に記載のマルチプロセッサシステム。
11. 前記物理ハードウェア情報取得部は、前記ハードウェアの物理的な位置情報からプロセッサとメモリ及びＩ／Ｏデバイスを接続する内部ネットワークの経路を求め、
    前記割り当て処理部は、
    前記リソースの割当ポリシーが、仮想サーバの信頼性を優先する場合には、既に割り当てた仮想サーバが使用する内部ネットワークと、前記生成要求のあった新たな仮想サーバが使用する内部ネットワークで、重複する内部ネットワークの数の総和が最小となるように、前記新たな仮想サーバへプロセッサとメモリ及びＩ／Ｏデバイスを割り当てることを特徴とする請求項６に記載のマルチプロセッサシステム。
12. 前記物理ハードウェア情報取得部は、前記ハードウェアの物理的な位置情報からプロセッサとメモリ及びＩ／Ｏデバイスを接続する内部ネットワークの経路を求め、
    前記割り当て処理部は、
    前記リソースの割当ポリシーが、内部ネットワークの帯域を優先する場合には、既に割り当てた仮想サーバが使用する内部ネットワークと、前記生成要求のあった新たな仮想サーバが使用する内部ネットワークで、重複する内部ネットワークの帯域を仮想サーバの数で除した値を実効帯域とし、当該実効帯域が最大となるように、前記新たな仮想サーバへプロセッサとメモリ及びＩ／Ｏデバイスを割り当てることを特徴とする請求項６に記載のマルチプロセッサシステム。
13. 前記物理ハードウェア情報取得部は、前記プロセッサとメモリとＩ／Ｏデバイス及び前記ハードウェアを動作させるコンポーネントの消費電力をそれぞれ求め、
    前記割り当て処理部は、
    前記リソースの割当ポリシーが、消費電力を優先する場合には、既に割り当てた仮想サーバのプロセッサとメモリとＩ／Ｏデバイス及びコンポーネントの消費電力と、前記生成要求のあった新たな仮想サーバが使用するプロセッサとメモリとＩ／Ｏデバイス及びコンポーネントの消費電力の総和が最小となるように、前記新たな仮想サーバへプロセッサとメモリ及びＩ／Ｏデバイスを割り当てることを特徴とする請求項６に記載のマルチプロセッサシステム。
14. 前記仮想マシンモニタは、
    前記仮想サーバに対して割り当てたプロセッサとメモリ及びＩ／Ｏデバイスの物理的な位置情報を前記仮想サーバに通知する通知部をさらに備えたことを特徴とする請求項６に記載のマルチプロセッサシステム。
15. 前記通知部は、
    前記仮想サーバに対してＡＣＰＩに準拠した物理的な位置情報に変換して通知することを特徴とする請求項１４に記載のマルチプロセッサシステム。
16. 前記受付部が、第２の仮想サーバの生成要求を受け付け、
    前記割り当て処理部は、
    前記仮想サーバに対して既に割り当てたプロセッサとメモリ及びＩ／Ｏデバイスの物理的な位置情報を保存し、前記第２の仮想サーバの生成要求に含まれるプロセッサの数とメモリ量及びＩ／Ｏデバイスの情報とリソース割当ポリシーから、前記マルチプロセッサ上で割り当て可能なプロセッサとメモリ及びＩ／Ｏデバイスの位置情報に基づいて、当該第２の仮想サーバに前記利用可能なＩ／Ｏデバイスとプロセッサ及びメモリを割り当てて、前記割り当て済みの仮想サーバのリソースの割当ポリシーに基づいて当該仮想サーバのプロセッサとメモリを再配置することを特徴とする請求項６に記載のマルチプロセッサシステム。
17. 前記割り当て処理部は、
    前記ひとつのＩ／Ｏデバイスをひとつの仮想サーバに割り当てることを特徴とする請求項６に記載のマルチプロセッサシステム。

Images