(57)【要約】  仮想マシンモニタ上の仮想マシンを密に連携させるシステムにおいて、仮想マシン内のオペレーティングシステムやアプリケーションを変更することなく、代理応答を持つ高速な仮想マシン間通信を実現する。同一の仮想マシンモニタ（１００）上に複数の仮想マシン（２０１〜２０３）を実行させて、仮想マシン（２０１〜２０３）間の通信を行う仮想マシン間通信装置を提供する。仮想マシン（２０１）のソケットＡＰＩのラッパライブラリ（ソケットラッパ）（５０１）は、仮想マシンモニタ１００により提供される通信チャネルの管理を行う通信チャネル管理部（５１０）と、前記通信チャネルを用いた仮想マシン間通信の代理応答を行う代理応答部（５２０）と、を有する。
2010064411.tif 000002
【特許請求の範囲】
【請求項１】
仮想マシンモニタと、
前記仮想マシンモニタ上で実行させ、相互に通信を行う複数の仮想マシンと、を備え、
前記複数の仮想マシンのうち少なくとも１つは、ソケットＡＰＩ（Application Program Interface）のラッパライブラリを備え、
前記ソケットＡＰＩのラッパライブラリは、
前記仮想マシンモニタにより提供される通信チャネルの管理を行う通信チャネル管理手段と、
前記通信チャネルを用いた仮想マシン間通信の代理応答を行う代理応答手段と、を有する仮想マシン間通信装置。
【請求項２】
前記通信チャネル管理手段は、ソケットディスクリプタに、通信先の仮想マシンと、通信チャネル又は代理応答モジュールと、を関連付けたエントリを管理する通信チャネル管理テーブルを具備し、
前記複数の仮想マシン間の通信の際に、前記通信チャネル管理テーブルを参照し、前記代理応答モジュールが関連付けられている場合に、前記代理応答手段に代理応答を行わせることを特徴とする、請求項１記載の仮想マシン間通信装置。
【請求項３】
前記通信チャネル管理手段は、仮想マシンのマイグレーションの際に、
前記マイグレーションが、前記仮想マシンを前記仮想マシンモニタ上から削除するものである場合に、前記通信チャネル管理テーブルから前記仮想マシンに関連するエントリを削除し、
前記マイグレーションが、前記仮想マシンを前記仮想マシンモニタ上に追加するものである場合に、前記通信チャネル管理テーブルへ前記仮想マシンに関連するエントリを追加することを特徴とする、請求項２記載の仮想マシン間通信装置。
【請求項４】
前記代理応答手段は、仮想マシン間通信で代理応答を適用するか否かを判断する基準となる適用ポリシを管理する適用ポリシ管理テーブルを具備し、
前記ソケットＡＰＩのラッパライブラリは、前記通信チャネルを用いた通信を行う際に、前記適用ポリシ管理テーブルの情報に基づいて、代理応答を適用するか否かを判断し、適用すると判断した場合、代理応答を実行する代理応答モジュールに代理応答を実行させ、適用しないと判断した場合、前記通信チャネルを用いて通信を行うことを特徴とする、請求項１から３のいずれか１項記載の仮想マシン間通信装置。
【請求項５】
前記適用ポリシ管理テーブルは、通信チャネルの上限数と利用中の通信チャネル数を仮想マシン毎に関連付けて格納し、
前記代理応答を適用するか否かの判断は、前記適用ポリシ管理テーブルに仮想マシン毎に格納されている前記通信チャネルの上限数と前記利用中の通信チャネル数とを比較した結果に基づき行われるものであることを特徴とする、請求項４記載の仮想マシン間通信装置。
【請求項６】
同一の仮想マシンモニタ上にある複数の仮想マシン間で通信を行う仮想マシン間通信方法であって、
前記複数の仮想マシンのうち少なくとも１つが備えるソケットＡＰＩのラッパライブラリは、
前記仮想マシンモニタにより提供される通信チャネルを管理し、
前記通信チャネルを用いた仮想マシン間通信の代理応答を行う仮想マシン間通信方法。
【請求項７】
前記通信チャネルの管理は、
仮想マシン間通信の際に、ソケットディスクリプタに、通信先の仮想マシンと、通信チャネル又は代理応答モジュールと、を関連付けた通信チャネル管理テーブルを参照し、
前記代理応答は、
前記通信チャネル管理テーブルの参照の結果、前記代理応答モジュールが関連付けられている場合に、行うことを特徴とする、請求項６記載の仮想マシン間通信方法。
【請求項８】
仮想マシンモニタ上で実行される仮想マシンを、
前記仮想マシンモニタにより提供される通信チャネルの管理を行う通信チャネル管理手段と、
前記通信チャネルを用いた仮想マシン間通信の代理応答を行う代理応答手段として機能させることを特徴とする、ソケットＡＰＩのラッパライブラリ。
【請求項９】
仮想マシンモニタ上で実行される仮想マシンに、
前記仮想マシンモニタにより提供される通信チャネルの管理を行う通信チャネル管理手順と、
前記通信チャネルを用いた仮想マシン間通信の代理応答を行う代理応答手順と、を実行させるプログラムを格納した、コンピュータで読み取り可能な記録媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、仮想マシン間通信装置、方法及びソケットＡＰＩ（Application Program Interface）のラッパライブラリに関し、特に、仮想マシン間通信の高速化に関する。
【背景技術】
【０００２】
通常、仮想マシン（以下、ＶＭ）間の通信オーバヘッドは大きく、ＶＭを用いない場合と比較してＶＭ間通信を用いた方式は系全体の性能を著しく低下させることが知られている。また、複数のＶＭが密に連携するシステムにおいてＶＭ間での通信が頻繁に行われる場合、ある１つのＶＭがマイグレーションなどで停止してしまうとその影響が他のＶＭに伝播してしまい、システムの運用に大きな影響を与える虞がある。【０００３】
したがって、仮想マシンモニタ（以下、ＶＭＭ）上で複数のＶＭが密に連携するシステムの課題は、ＶＭ間通信の高速化とシステムの可用性の向上の両立である。また、これらの機能がＶＭ内のオペレーティングシステム（以下、ＯＳ）やアプリケーションを変更せずに実現できることが重要である。【０００４】
ＶＭ間通信の高速化は管理ＶＭと呼ばれる通信を管理するＶＭを経由せずに直接ＶＭＭの通信チャネルを利用することで実現できる。中でも、ＯＳやソケットを使ったアプリケーションを変更せずに利用可能なＶＭ間通信方式として、ＸｅｎＬｏｏｐ（非特許文献１）やＸＷａｙ（非特許文献２）が提案されている。【０００５】
ＸｅｎＬｏｏｐは通信プロトコルスタックのＩＰレイヤとデータリンクレイヤの間で実現されたドライバである。そのため、ＸｅｎＬｏｏｐはアプリケーションから送信されたデータをパケットの形式で受信する。もし、送信先の計算機が同一ＶＭＭ上に存在するＶＭならばＶＭＭの通信チャネルを利用して送信し、そうでなければそのままデータリンクレイヤにパケットを渡すようになっている。【０００６】
ＸＷａｙは通信プロトコルスタックのソケットＡＰＩのレイヤとトランスポートレイヤの間で実現されたスイッチである。ソケットＡＰＩから受け取ったデータを同一ＶＭＭ内のＶＭに送信する場合はＶＭＭの通信チャネルを利用し、ＸＷａｙプロトコルにて通信する。そうでなければトランスポートレイヤにデータを渡すようになっている。【０００７】
これらを用いれば、ＯＳやソケットを使ったアプリケーションを変更することなく、ＶＭ間通信の高速化が実現できる。【０００８】
一方、システムの可用性を向上させるには、あるＶＭがマイグレーションなどによって応答不能になった場合の対処が必要になる。例えば、ＶＭ１がＶＭ２にリクエストを送信する場合、ＶＭ２がマイグレーション処理に入って応答できなければＶＭ１の送信処理はブロックしてしまう。したがって、ＶＭ１では応答待ちの状態を保存するためにリソースを消費してしまい、あるいは、ＶＭＭでは通信チャネルのためにリソースが消費されてしまう。【０００９】
この問題に対処するには代理応答が有効である。さらに、アプリケーションレベルでの柔軟な対応ができることが望ましい。なぜなら、連携させるＶＭが搭載するアプリケーションに合わせた対処方法が必要だからである。例えば、マイグレーション中のＨＴＴＰのＧＥＴアクセスに対して、サービス利用不可を示すステータスコード５０３を返したいアプリケーションもあれば、一時的に別のリソースにリダイレクトするステータスコード３０７を返したいアプリケーションもある。【００１０】
しかし、アプリケーションレベルの柔軟な代理応答を実現するにはアプリケーション自体の改変が必要になり、アプリケーションの開発コストの問題が発生してしまう。したがって、アプリケーションレベルの代理応答機能をＶＭ間通信の機構の中に取り入れることで、アプリケーションの開発コストを抑えることが可能になる。つまり、ＶＭ上のＯＳやアプリケーションを変更せずにＶＭ間通信の高速化とシステムの可用性の向上を両立した代理応答可能なＶＭ間通信方式が望まれる。【００１１】
しかし、このような代理応答機能をＸｅｎＬｏｏｐで実現しようとすると、ＸｅｎＬｏｏｐはパケット形式でデータを受け取るため、パケットの再構築とメッセージの解釈が必要になる。よって、本来は必要のなかったパケットの再構築処理のため代理応答機能の実行コスト及び開発コストが増大してしまうという課題がある。【００１２】
一方、ＸＷａｙで実現する場合はＸｅｎＬｏｏｐに比べてメッセージの解釈が簡単にできるが、プロトコルスタックの中にコードを埋め込むため、ＯＳの改良が必要となり、開発コストが増大してしまうという課題がある。【００１３】
また、このようなシステムの運用を考えた場合、代理応答により系全体の可用性を向上させるための作業と、ＶＭマイグレーションなどによりシステムの性能改善を行う作業とが分離されていない問題がある。例えば、ＶＭ配置を管理するＶＭＭ管理者が、性能改善のために物理マシン１のＶＭＭ１に配置されたＶＭ１を物理マシン２にあるＶＭＭ２上にマイグレーションさせたいとする。【００１４】
その際、ＶＭＭ管理者はマイグレーションを開始する前にサービス運用者にＶＭＭ１にある他のＶＭ（例えばＶＭ２）からＶＭ１へのアクセスを停止させ、マイグレーション完了後に物理マシン２への通信として再開させる、といった設定の作業が必要になってしまう。これは、ＶＭのマイグレーション時にＶＭＭ管理者とサービス運用者の両方の作業が必要になることを意味しており、システムの運用コストの増大に繋がることになる。したがって、可用性の向上と性能改善の作業が分離できることが重要である。
【先行技術文献】
【非特許文献】
【００１５】
【非特許文献１】Jian Wang, Kwame-Lante Wright, and Kartik Gopalan, XenLoop : A Transparent High Performance Inter-VM Network Loopback, To appear in the International Symposium on High Performance Distributed Computing (HPDC), Boston, MA, June 2008.
【非特許文献２】Kim, K., Kim, C., Jung, S., Shin, H., and Kim, J. 2008. Inter-domain socket communications supporting high performance and full binary compatibility on Xen. In Proceedings of the Fourth ACM SIGPLAN/SIGOPS international Conference on Virtual Execution Environments (Seattle, WA, USA, March 05 - 07, 2008). VEE '08. ACM, New York, NY, 11-20.
【発明の概要】
【発明が解決しようとする課題】
【００１６】
上述の技術の第１の課題は、ＶＭＭ上のＶＭを密に連携させるシステムにおいて、ＶＭ間通信の高速化とシステムの可用性を向上させる際に、ＶＭ上のＯＳやソケットを利用したアプリケーションを変更しないことである。【００１７】
第２の課題は、上記システムにおいて系全体の可用性を高めるために、アプリケーションレベルの柔軟な代理応答が可能であることである。【００１８】
第３の課題は、上記システムにおいて、可用性の向上と性能改善（ＶＭマイグレーション）の作業を独立に実行できることである。【００１９】
本発明は、上記実情に鑑みて、仮想マシンモニタ上の仮想マシンを密に連携させるシステムにおいて、仮想マシン内のオペレーティングシステムやアプリケーションを変更することなく、代理応答を持つ高速な仮想マシン間通信を実現することを目的とする。
【課題を解決するための手段】
【００２０】
上記目的を達成するために、本発明の仮想マシン間通信装置の一態様は、仮想マシンモニタと、前記仮想マシンモニタ上で実行させ、相互に通信を行う複数の仮想マシンと、を備え、前記複数の仮想マシンのうち少なくとも１つは、ソケットＡＰＩ（Application Program Interface）のラッパライブラリを備える。前記ソケットＡＰＩのラッパライブラリは、前記仮想マシンモニタにより提供される通信チャネルの管理を行う通信チャネル管理手段と、前記通信チャネルを用いた仮想マシン間通信の代理応答を行う代理応答手段と、を有する。【００２１】
また、本発明に係る仮想マシン間通信方法の一態様は、同一の仮想マシンモニタ上にある複数の仮想マシン間で通信を行う仮想マシン間通信方法であって、前記複数の仮想マシンのうち少なくとも１つが備えるソケットＡＰＩのラッパライブラリは、前記仮想マシンモニタにより提供される通信チャネルを管理し、前記通信チャネルを用いた仮想マシン間通信の代理応答を行うことを特徴とする。【００２２】
本発明に係るソケットＡＰＩのラッパライブラリの一態様は、仮想マシンモニタ上で実行される仮想マシンを、前記仮想マシンモニタにより提供される通信チャネルの管理を行う通信チャネル管理手段と、前記通信チャネルを用いた仮想マシン間通信の代理応答を行う代理応答手段として機能させることを特徴とする。【００２３】
本発明に係るコンピュータで読み取り可能な記録媒体の一態様は、仮想マシンモニタ上で実行される仮想マシンに、前記仮想マシンモニタにより提供される通信チャネルの管理を行う通信チャネル管理手順と、前記通信チャネルを用いた仮想マシン間通信の代理応答を行う代理応答手順と、を実行させるプログラムを格納した。
【発明の効果】
【００２４】
本発明によれば、仮想マシンモニタ上の仮想マシンを密に連携させるシステムにおいて、仮想マシン内のオペレーティングシステムやアプリケーションを変更することなく、代理応答を持つ高速な仮想マシン間通信を実現することが可能になる。
【図面の簡単な説明】
【００２５】
【図１】本発明を実施するための形態を含む全体構成を示すブロック図である。
【図２】本発明を実施するための形態の構成を示すブロック図である。
【図３】本発明を実施するための形態のＶＭ情報管理テーブルの具体例を示す図である。
【図４】本発明を実施するための形態の通信チャネル管理部の通信チャネル管理テーブルの具体例を示す図である。
【図５】本発明を実施するための形態の代理応答部の適用ポリシ管理テーブルの具体例を示す図である。
【図６】本発明を実施するための形態の代理応答モジュール群の具体例を示す図である。
【図７】本発明を実施するための形態の動作を示すフローチャート図である。
【発明を実施するための形態】
【００２６】
まず、本実施形態の概要を説明する。
以下で説明する本実施形態に係るＶＭ間通信方式は、ＶＭ情報管理テーブルと通信チャネル管理テーブルを持つ通信チャネル管理部と、適用ポリシ管理テーブルと代理応答モジュール群を持つ代理応答部と、を備えたソケットＡＰＩのラッパライブラリ（以降、「ソケットラッパ」）として実現される。
【００２７】
このような構成を採用することで、ＶＭ内のＯＳやアプリケーションを変更することなく、代理応答を持つ高速なＶＭ間通信を実現可能である。さらに、本実施形態に係るシステムでは、ポリシに合致した時点で代理応答が自動的に行われるため、ＶＭＭ管理者は、サービス運用者に伝えることなくマイグレーションを自由に行える。
以下、本実施形態について図面を参照しながら詳細に説明する。
【００２８】
図１を参照すると、本実施形態はＶＭＭ（１００）上のＶＭ（２０１〜２０３）にてアプリケーション（３０１〜３０３）にリンクされたソケットラッパ（５０１〜５０３）として実現されている。
【００２９】
なお、本実施形態は、ＣＰＵ（Central Processing Unit）やプロセッサ等の演算／処理装置、メモリ等の記憶装置を備えた汎用のコンピュータを利用して、所定の情報処理を行うソフトウェアプログラムによって実現される。また、そのようなソフトウェアプログラム、及び、当該ソフトウェアプログラムを格納したコンピュータ読取可能な記録媒体も本発明を構成する。
【００３０】
各アプリケーションはソケットＡＰＩを通じて他のアプリケーションと通信する。ＶＭＭ（１００）はＶＭ間の通信機構として通信チャネル（７０１、７０２）を提供する。例えば、図１において、アプリケーションＡ（３０１）がソケットラッパのＡＰＩをコールし、ＶＭＭ（１００）が提供する通信チャネル（７０１）を介してアプリケーションＢ（３０２）と通信する。同様に、アプリケーションＢ（３０２）は通信チャネル（７０２）を介してアプリケーションＣ（３０３）と通信する。
【００３１】
次に、ソケットラッパ５０１〜５０３の構成について説明する。図２を参照すると、ソケットラッパ５０１は、通信チャネル管理部５１０と代理応答部５２０を有する。通信チャネル管理部５１０は、ＶＭ情報管理テーブル５１１と通信チャネル管理テーブル５１２とを持つ。代理応答部５２０は、適用ポリシ管理テーブル５２１と代理応答モジュール群５２２を持つ。以下、図２に示した各テーブル又はモジュール群について図３ないし図６に具体例を示して説明するが、これらは説明のための一例であって本発明を限定するものではない。
【００３２】
図３にＶＭ情報管理テーブル５１１の一例を示す。本テーブルでは、送信先ＶＭのＩＰアドレスと、ＶＭ識別子（以下、ＶＭ−ＩＤ）と、を一組のエントリとして管理する。本テーブルのエントリはＶＭがマイグレーションにてＶＭＭ上に移動が完了した際に追加され、マイグレーションにて他のＶＭに移動が完了した際に削除される。従って、任意のＶＭ（例えば、送信先ＶＭ）が同一のＶＭＭ上に存在するか否かを、ＶＭ情報管理テーブル５１１を参照して判定することができる。ここで、同一のＶＭＭとは、任意の物理マシンの一つのＶＭＭを意味する。従って、任意のＶＭが同一のＶＭＭ上に存在するとは、任意のＶＭと自己のＶＭとが一つのＶＭＭ上に存在することになる。
【００３３】
また、図４に通信チャネル管理テーブル５１２の一例を示す。本テーブルでは、ソケットディスクリプタ番号と、利用するＶＭＭのチャネル番号、又は、代理応答を行う場合は代理応答のモジュール識別子を示すチャネルＩＤと、通信相手のＶＭ識別子であるＶＭ−ＩＤと、を一組のエントリとして管理する。なお、モジュール識別子とチャネル番号は重複しない。
【００３４】
また、図５に適用ポリシ管理テーブル５２１の一例を示す。本テーブルでは、通信相手のＶＭ識別子ＶＭ−ＩＤと、代理応答を適用する条件となる上限チャネル数を示す閾値と、利用中のチャネル数を示すカウンタと、実際に代理応答処理を行うモジュール識別子（Ｍｏｄｕｌｅ  ＩＤ）と、を一組のエントリとして管理する。
【００３５】
また、図６に代理応答モジュール群５２２の一例を示す。本テーブルでは、モジュール識別子（Ｍｏｄｕｌｅ  ＩＤ）と、そのモジュールが配置されているアドレスと、を一組のエントリとして管理する。代理応答モジュールの設定ではサービスや状況に適した機能を配置することが可能である。
【００３６】
次に、図１，図２，図４，図５及び図７のフローチャートを参照して本実施の形態の全体の動作について詳細に説明する。
【００３７】
まず、アプリケーションＡ３０１は通信相手に接続するため、ソケットラッパ５０１の接続要求ＡＰＩ（例えばｃｏｎｎｅｃｔ（））を呼び出す（図７のステップＳ１０１）。
【００３８】
次に、ソケットラッパ５０１は通信チャネル管理部５１０のＶＭ情報管理テーブル５１１を確認し、送信先ＩＰアドレスをキーに通信相手が同一ＶＭＭ上に存在するか（ＶＭ情報管理テーブル５１１にエントリが存在するか）を検索する（ステップＳ１０２）。
【００３９】
もし、同一ＶＭＭ上に存在しない場合、ソケットラッパ５０１は通常のソケットＡＰＩを呼び出して通信を行う（ステップＳ１０３〜Ｓ１０４）。
【００４０】
同一ＶＭＭ上に存在する場合は、ソケットラッパ５０１はＶＭ情報管理テーブル５１１からＶＭ−ＩＤを取得し、ＶＭ−ＩＤをキーにして代理応答部５２０の適用ポリシ管理テーブル５２１を検索する（ステップＳ１０５）。
【００４１】
その結果、代理応答の適用条件（図５ならば対応するＶＭ−ＩＤのエントリの「カウンタ＞閾値」）が成立していなければ、ソケットラッパ５０１はＶＭＭの通信チャネルを確保し、通信チャネル管理テーブル５１２にエントリ（ディスクリプタ番号、チャネルＩＤ、ＶＭ−ＩＤ）を追加して通信処理を開始する（ステップＳ１０６、Ｓ１０７）。
【００４２】
もし、代理応答の適用条件が成立していれば、ソケットラッパ５０１は適用ポリシ管理テーブル５２１に指定された代理応答モジュール（Ｍｏｄｕｌｅ  ＩＤ）を取得し、通信チャネル管理テーブル５１２のエントリ（ディスクリプタ番号、Ｍｏｄｕｌｅ  ＩＤ、ＶＭ−ＩＤ）を追加して代理応答処理を開始する（ステップＳ１０６、Ｓ１０８）。
【００４３】
次に、本実施形態におけるＶＭマイグレーション時の処理について説明する。
【００４４】
今、ＶＭ１、ＶＭ２、ＶＭ３が連携したシステムで、ＶＭ２がマイグレーションにて別の物理マシン上のＶＭＭへ移動を開始したとする。すると、ＶＭ２への接続が不可能となるため、ＶＭ１、ＶＭ３のソケットラッパでは代理応答の適用条件に合致した段階で代理応答処理が開始される。
【００４５】
ＶＭ２（２０２）の移動が完了すると、ＶＭＭ１００からマイグレーション完了イベントを受け取った通信チャネル管理部５１０はＶＭ情報管理テーブル５１１のエントリを削除する。また、同時に通信チャネル管理テーブル５１２と適用ポリシ管理テーブル５２１にあるＶＭ２に対応するエントリを削除する。これにより、ＶＭ１、ＶＭ３からＶＭ２への接続要求は通常のソケットＡＰＩを利用したアクセスに切り替わる（図７のステップＳ１０３，Ｓ１０４のフロー参照）。
【００４６】
一方、マイグレーションにより同一ＶＭＭ上にＶＭ４が追加された場合、ＶＭＭからマイグレーション完了イベントを受け取った通信チャネル管理部５１０はＶＭ情報管理テーブル５１１にＶＭ４の情報をエントリとして追加する。
【００４７】
次に、本実施の形態の効果について説明する。
【００４８】
第１の効果は、ＶＭ間通信の高速化とシステムの可用性を向上させる際に、ＶＭ上のＯＳやソケットを利用したアプリケーションを変更しない点である。その理由は、本発明がソケットＡＰＩのラッパとして実現されているためである。
【００４９】
第２の効果は、あるＶＭがマイグレーション等で応答できない場合のシステムの可用性を高めた点である。その理由は、本発明がアプリケーションレベルの柔軟な対応が可能な代理応答の機構を備えており、アプリケーションによるリソースの解放を促すためである。その結果、他のＶＭやシステム全体への影響を最小限に抑えられる。
【００５０】
第３の効果は、システムの可用性の向上とＶＭマイグレーションによる性能改善の作業を独立に実行できる点である。その理由は、本発明がＶＭ間通信機構の中に代理応答機能を持っているため、マイグレーション時の代理応答をシステムが自動的に行ってくれるためである。したがって、ＶＭＭ管理者はサービス構築者に連絡することなくＶＭのマイグレーションを自由に行える。
【００５１】
以上、本発明の各実施形態について説明したが、上記各実施形態に限定されるものではなく、その要旨を逸脱しない範囲において種々の変形が可能である。
【００５２】
例えば、上述した実施形態における動作（フローチャートに示す動作）は、ハードウェア、又は、ソフトウェア、あるいは、両者の複合構成によって実行することも可能である。
【００５３】
ソフトウェアによる処理を実行する場合には、処理シーケンスを記録したプログラムを、専用のハードウェアに組み込まれているコンピュータ内のメモリにインストールして実行させてもよい。あるいは、各種処理が実行可能な汎用コンピュータにプログラムをインストールして実行させてもよい。
【００５４】
例えば、プログラムは、記録媒体としてのハードディスクやＲＯＭ（Ｒｅａｄ  Ｏｎｌｙ  Ｍｅｍｏｒｙ）に予め記録しておくことが可能である。あるいは、プログラムは、ＣＤ−ＲＯＭ（Ｃｏｍｐａｃｔ  Ｄｉｓｃ  Ｒｅａｄ  Ｏｎｌｙ  Ｍｅｍｏｒｙ），ＭＯ（Ｍａｇｎｅｔｏ  ｏｐｔｉｃａｌ）ディスク，ＤＶＤ（Ｄｉｇｉｔａｌ  Ｖｅｒｓａｔｉｌｅ  Ｄｉｓｃ）、磁気ディスク、半導体メモリなどのリムーバブル記録媒体に、一時的、あるいは、永続的に格納（記録）しておくことが可能である。このようなリムーバブル記録媒体は、いわゆるパッケージソフトウエアとして提供することが可能である。
【００５５】
なお、プログラムは、上述したようなリムーバブル記録媒体からコンピュータにインストールする他、ダウンロードサイトから、コンピュータに無線転送してもよい。または、ＬＡＮ（Ｌｏｃａｌ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）、インターネットといったネットワークを介して、コンピュータに有線で転送してもよい。コンピュータでは、転送されてきたプログラムを受信し、内蔵するハードディスク等の記録媒体にインストールすることが可能である。
【００５６】
また、上記実施形態で説明した処理動作に従って時系列的に実行されるのみならず、処理を実行する装置の処理能力、あるいは、必要に応じて並列的にあるいは個別に実行するように構築することも可能である。
【００５７】
以上、実施の形態を参照して本願発明を説明したが、本願発明は上記によって限定されるものではない。本願発明の構成や詳細には、発明のスコープ内で当業者が理解し得る様々な変更をすることができる。
【００５８】
この出願は、２００８年１２月２日に出願された日本出願特願２００８−３０７２４８を基礎とする優先権を主張し、その開示の全てをここに取り込む。
【産業上の利用可能性】
【００５９】
本発明は、ＶＭＭ上でソケットを利用してＶＭ間通信を行うシステムに適用できる。より具体的には、Ｗｅｂサービスを提供するＶＭを連携させるシステムに適用できる。また、他にもソケットを利用しているならば、アプリケーションプロトコル（例えば、ＨＴＴＰ、ＳＭＴＰ、ＰＯＰ、ＦＴＰ、ＳＩＰ、ＤＮＳ、Ｔｅｌｎｅｔなど）にて通信するサービスへの適用も可能である。
【符号の説明】
【００６０】
１００    仮想マシンモニタ（ＶＭＭ）
２０１〜２０３    仮想マシン（ＶＭ）１〜３
３０１〜３０３    アプリケーションＡ〜Ｃ
４０１〜４０３    オペレーティングシステム（ＯＳ）Ａ〜Ｃ
５０１〜５０３    ソケットラッパ
７０１、７０２    ＶＭＭ内通信チャネル
５１０    通信チャネル管理部
５１１    ＶＭ情報管理テーブル
５１２    通信チャネル管理テーブル
５２０    代理応答部
５２１    適用ポリシ管理テーブル
５２２    代理応答モジュール群
【図１】
2010064411.tif 000003
【図２】
2010064411.tif 000004
【図３】
2010064411.tif 000005
【図４】
2010064411.tif 000006
【図５】
2010064411.tif 000007
【図６】
2010064411.tif 000008
【図７】
2010064411.tif 000009
【手続補正書】
【提出日】平成23年6月1日(2011.6.1)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
仮想マシンモニタと、
前記仮想マシンモニタ上で実行させ、相互に通信を行う複数の仮想マシンと、を備え、
前記複数の仮想マシンのうち少なくとも１つは、ソケットＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ  Ｐｒｏｇｒａｍ  Ｉｎｔｅｒｆａｃｅ）のラッパライブラリを備え、
前記ソケットＡＰＩのラッパライブラリは、
前記仮想マシンモニタにより提供される通信チャネルの管理を行う通信チャネル管理手段と、
前記通信チャネルを用いた仮想マシン間通信の代理応答を行う代理応答手段と、を有する仮想マシン間通信装置。
【請求項２】
前記通信チャネル管理手段は、ソケットディスクリプタに、通信先の仮想マシンと、通信チャネル又は代理応答モジュールと、を関連付けたエントリを管理する通信チャネル管理テーブルを具備し、
前記複数の仮想マシン間の通信の際に、前記通信チャネル管理テーブルを参照し、前記代理応答モジュールが関連付けられている場合に、前記代理応答手段に代理応答を行わせることを特徴とする、請求項１記載の仮想マシン間通信装置。
【請求項３】
前記通信チャネル管理手段は、仮想マシンのマイグレーションの際に、
前記マイグレーションが、前記仮想マシンを前記仮想マシンモニタ上から削除するものである場合に、前記通信チャネル管理テーブルから前記仮想マシンに関連するエントリを削除し、
前記マイグレーションが、前記仮想マシンを前記仮想マシンモニタ上に追加するものである場合に、前記通信チャネル管理テーブルへ前記仮想マシンに関連するエントリを追加することを特徴とする、請求項２記載の仮想マシン間通信装置。
【請求項４】
前記代理応答手段は、仮想マシン間通信で代理応答を適用するか否かを判断する基準となる適用ポリシを管理する適用ポリシ管理テーブルを具備し、
前記ソケットＡＰＩのラッパライブラリは、前記通信チャネルを用いた通信を行う際に、前記適用ポリシ管理テーブルの情報に基づいて、代理応答を適用するか否かを判断し、適用すると判断した場合、代理応答を実行する代理応答モジュールに代理応答を実行させ、適用しないと判断した場合、前記通信チャネルを用いて通信を行うことを特徴とする、請求項１から３のいずれか１項記載の仮想マシン間通信装置。
【請求項５】
前記適用ポリシ管理テーブルは、通信チャネルの上限数と利用中の通信チャネル数を仮想マシン毎に関連付けて格納し、
前記代理応答を適用するか否かの判断は、前記適用ポリシ管理テーブルに仮想マシン毎に格納されている前記通信チャネルの上限数と前記利用中の通信チャネル数とを比較した結果に基づき行われるものであることを特徴とする、請求項４記載の仮想マシン間通信装置。
【請求項６】
同一の仮想マシンモニタ上にある複数の仮想マシン間で通信を行う仮想マシン間通信方法であって、
前記複数の仮想マシンのうち少なくとも１つが備えるソケットＡＰＩのラッパライブラリは、
前記仮想マシンモニタにより提供される通信チャネルを管理し、
前記通信チャネルを用いた仮想マシン間通信の代理応答を行う仮想マシン間通信方法。
【請求項７】
前記通信チャネルの管理は、
仮想マシン間通信の際に、ソケットディスクリプタに、通信先の仮想マシンと、通信チャネル又は代理応答モジュールと、を関連付けた通信チャネル管理テーブルを参照し、
前記代理応答は、
前記通信チャネル管理テーブルの参照の結果、前記代理応答モジュールが関連付けられている場合に、行うことを特徴とする、請求項６記載の仮想マシン間通信方法。
【請求項８】
仮想マシンモニタ上で実行される仮想マシンを、
前記仮想マシンモニタにより提供される通信チャネルの管理を行う通信チャネル管理手段と、
前記通信チャネルを用いた仮想マシン間通信の代理応答を行う代理応答手段として機能させることを特徴とする、ソケットＡＰＩのラッパライブラリ。
【請求項９】
仮想マシンモニタ上で実行される仮想マシンに、
前記仮想マシンモニタにより提供される通信チャネルの管理を行う通信チャネル管理手順と、
前記通信チャネルを用いた仮想マシン間通信の代理応答を行う代理応答手順と、を実行させるプログラム。
【国際調査報告】
2010064411.tif 000010
2010064411.tif 000011
2010064411.tif 000012
2010064411.tif 000013