JP5960186B2 - 仮想通信路構築システム、仮想通信路構築方法、及び仮想通信路構築プログラム - Google Patents

Description

仮想マシンが動作可能なホストオペレーティングシステムにおいて、仮想マシン内で動作するゲストＯＳが自仮想マシン外に存在する、外部プロセスとの専用仮想通信路を構築するシステムおよび、仮想通信路の制御方法に関する。

仮想マシンを構成する技術としてＬｉｎｕｘ（登録商標）とＫＶＭ（ｋｅｒｎｅｌ−ｂａｓｅｄ ｖｉｒｔｕａｌ ｍａｃｈｉｎｅ）で構成されたハイパーバイザー環境がよく知られている。この環境では、ＫＶＭモジュールが組み込まれたホストＯＳ（物理サーバ上にインストールされたＯＳをホストＯＳと呼ぶ）がハイパーバイザーとしてカーネル空間（と呼ばれるユーザ空間とは異なるメモリ領域で）動作し、この環境においてユーザ空間にて仮想マシンが動作し、その仮想マシン内にゲストＯＳ（仮想マシン上にインストールされたＯＳをゲストＯＳと呼ぶ）が動作する。

ゲストＯＳが動作する仮想マシンはホストＯＳが動作する物理サーバとは異なり、（イーサーネットカードデバイスなどに代表される）ネットワークデバイスを含むすべてのハードウェアが、ハードウェアからゲストＯＳへの割り込み処理やゲストＯＳからハードウェアへの書き込みに必要なレジスタ制御といった本来物理ハードウェアが実施すべき通知や処理がソフトウェアで擬似的に模倣されるため、性能がホストＯＳ環境に比べ、低いことが一般的である。

この性能劣化において、特にゲストＯＳから自仮想マシン外に存在するホストＯＳや外部プロセスに対して、ハードウェアの模倣を削減し、高速かつ統一的なインタフェースにより通信の性能と汎用性を向上させる技術として、Ｖｉｒｔｉｏというデバイスの抽象化技術、つまり準仮想化技術が開発されており、すでにＬｉｎｕｘ（登録商標）を始め、ＦｒｅｅＢＳＤ（登録商標）など多くの汎用ＯＳに組み込まれ、現在利用されている。

＜Ｖｉｒｔｉｏの仕組み＞
Ｖｉｒｔｉｏでは、コンソール、ファイル入出力、ネットワーク通信といったデータ入出力に関して、転送データの単一方向の転送用トランスポートとして、リングバッファで設計されたキューによるデータ交換とキューのオペレーションを以て定義している。そして、ｖｉｒｔｉｏのキューの仕様を利用して、それぞれのデバイスに適したキューの個数と大きさをゲストＯＳ起動時に用意することにより、ゲストＯＳと自仮想マシン外部との通信を、ハードウェアエミュレーションを実施せずにキューによるオペレーションだけで実現することができる。詳細な仕様については、非特許文献１に記載されている。

具体的には、ＰＣＩデバイスとして仮想マシン内にコンソール、ファイル入出力、ネットワーク通信それぞれに対しＶｉｒｔｉｏデバイスが存在し（コンソールはｖｉｒｔｉｏ−ｃｏｎｓｏｌｅ、ファイル入出力はｖｉｒｔｉｏ−ｂｌｋ、ネットワークはｖｉｒｔｉｏ−ｎｅｔと呼ばれるデバイスとそれに対応するＯＳが持つドライバがｖｉｒｔｉｏキューで定義されている）、ゲストＯＳ起動時に、ゲストＯＳと相手側とのデータの受け渡し端点（送受信端点）を２つ作り、データ送受信の親子関係を構築する。多くの場合、親子関係は仮想マシン側（子側）とゲストＯＳ（親側）で構成する。

図１に示すように、子側は仮想マシン内のデバイスの構成情報として存在し、それぞれのデータ領域のサイズと必要とする端点の組み合わせの個数、デバイスの種別を親側に要求する。親側は子側の要求に従い、必要な分のデータを貯蓄し受け渡すための共有バッファキューのためのメモリを割り当て確保し、子側がアクセスできるようにそのアドレス番地を子側に返す。データの受け渡しに必要とされる共有バッファキューのオペレーションについては、Ｖｉｒｔｉｏではすべて共通であり、親側、子側両方合意済みとして実行される（Ｖｉｒｔｉｏキューのオペレーションについては後述の＜Ｖｉｒｔｉｏキューの操作＞を参考にすること）。さらに共有バッファキューの大きさも両方合意済みとする（つまりデバイスごとに決まっている）。これにより、子側にアドレスを伝えるだけで、親側、子側の双方が共有するキューを操作することが可能となる。

Ｖｉｒｔｉｏにおいて用意する共有バッファキューは単一方向用として用意されるため、例えば、ｖｉｒｔｉｏ−ｎｅｔデバイスと呼ばれる仮想ネットワークデバイスでは送信用、受信用、コントロール用の３つのリングバッファで構成される。親と子の通信は、共有バッファキューへの書き込みとバッファ更新通知により実現し、リングバッファに書き込んだ後、相手側に通知する。相手側は通知を受けると、どの共有バッファキューにどの程度新規のデータが入っているのかをＶｉｒｔｉｏの共通オペレーションを利用して確認し、新規のバッファ領域を取り出す。これにより、親から子または子から親へのデータの受け渡しが成立する。

以上のように、親子でお互いデータ交換用のリングバッファとそれぞれのリングバッファ用のオペレーション方法（Ｖｉｒｔｉｏで共通）を共有することにより、ハードウェアエミュレーションを必要としない、ゲストＯＳと外部との通信を実現する。これにより、従来のハードウェアエミュレーションに比べ、ゲストＯＳと外部とのデータの送受信を高速に実現することが可能である。

＜Ｖｉｒｔｉｏキューの操作＞
（共有バッファキューの構成）
親側（例：ゲストＯＳ）と子側（例：仮想マシン）が共有する共有バッファキューについて説明する。共有バッファキューは、非特許文献１に記載の仕様の通りであるが、本発明の動作（実施例）を説明するにあたり、キュー構成とキュー操作に関するオペレーションを前提とするため、本節にて説明する。共有バッファキューは既に述べたように親側から子側、または子側から親側への単一方向で利用するものであり、図２の通り次の要素で構成される（本発明はネットワークデバイスに関するものであり、データ転送用のキューを送信用、受信用の２つとする（ｖｉｒｔｉｏ−ｎｅｔの仕様の通りである））。

・ディスクリプタポインタ列
転送データを保存する各ディスクリプタを参照するためのポインタ。ディスクリプタは転送データの参照アドレスと、その長さ、転送フラグ（本発明では特に重要ではないため説明は省略する）、後続データがある場合のディスクリプタのポインタの４つで構成される（図２）。

・ａｖａｉｌリング
ａｖａｉｌリングでは、ヘッダ、ａｖａｉｌインデックス（ａｖａｉｌｉｄｘ）、ａｖａｉｌリング列、ｕｓｅｄ＿ｅｖｅｎｔ の４つの要素からなる。ヘッダについては本発明では特に重要ではないので省略する。ａｖａｉｌリング列はそれぞれインデックスが順番に割り振られたリングバッファからなり（図においては０番からインデックスを割り当てている）、それぞれのバッファにはゲストＯＳ側が確保し用意したディスクリプタの番号がインデックスの順番に従って記載される。ａｖａｉｌインデックスは現在消費済みのａｖａｉｌリング列の最終インデックスをゲストＯＳが記載する。ｕｓｅｄ＿ｅｖｅｎｔについても本発明には特に重要ではないので省略する。

・ｕｓｅｄリング
ｕｓｅｄリングでは、ヘッダ、ｕｓｅｄインデックス（ｕｓｅｄｉｄｘ）、ｕｓｅｄリング列、ａｖａｉｌ＿ｅｖｅｎｔの４つの要素から成る。ヘッダは本発明では特に重要ではないので省略する。ｕｓｅｄリング列はそれぞれインデックスが順番に振られたリングバッファからなり、ゲストＯＳが用意したａｖａｉｌリング列より、仮想マシンがインデックス順に取り出したディスクリプタ番号を順番にリングに書き込んだものである。ｕｓｅｄインデックスは現在消費済みのｕｓｅｄリング列の最終インデックスを仮想マシンが記載する。ａｖａｉｌ＿ｅｖｅｎｔについても本発明には特に重要ではないので省略する。

・ｌａｓｔ＿ａｖａｉｌ＿ｉｄｘ
このインデックス値は、子側が保持する値であり、最終的に取り出し回収したａｖａｉｌリングのａｖａｉｌインデックス値となる。親側がアップデートしたａｖａｉｌ＿ｉｄｘと、ｌａｓｔ＿ａｖａｉｌ＿ｉｄｘを比較することで、アップデートされたａｖａｉｌリングの個数を子側が知ることができる。

・ｌａｓｔ＿ｕｓｅｄ＿ｉｄｘ
このインデックス値は、親側が保持する値であり、最終的に取り出し回収したｕｓｅｄリングのｕｓｅｄインデックス値となる。子側がアップデートしたｕｓｅｄ＿ｉｄｘと、ｌａｓｔ＿ｕｓｅｄ＿ｉｄｘを比較することで、アップデートされたｕｓｅｄリングの個数を親側が知ることができる。

（親側（例：ゲストＯＳ）から子側（例：仮想マシン）へのデータ転送）
親側から子側へのデータ転送は送信専用のキューを利用する。初期状態では、ディスクリプタ、ａｖａｉｌリング列、ｕｓｅｄリング列が図３の通り初期化された状態である。転送時ゲストＯＳはデータ１つを仮想マシン側に転送する場合、図４の通り、ａｖａｉｌリングの先頭に確保したディスクリプタ番号（Ｓ−１）を記入する。Ｓはリング列のサイズとする。ディスクリプタＳ−１はゲストＯＳによって転送用データで埋められる。そして、ゲストＯＳはａｖａｉｌｉｄｘを０に進める。その後、ゲストＯＳは仮想マシン側にａｖａｉｌリング更新通知を送付する。

図５において、仮想マシンは更新通知を受け、ａｖａｉｌリング列をチェックする。このとき、ゲストＯＳがどの程度、ａｖａｉｌリング列に書き込んだのかリングの個数を調べるために、仮想マシン側でｌａｓｔ＿ａｖａｉｌ＿ｉｄｘを管理している。ｌａｓｔ＿ａｖａｉｌ＿ｉｄｘは初期値であり、ａｖａｉｌｉｄｘ とｌａｓｔ＿ａｖａｉｌ＿ｉｄｘを比較して、データ１個がａｖａｉｌリングに入れられていることを仮想マシンが認識する。仮想マシンはインデックス０番のリングからディスクリプタ番号を見つけ（Ｓ−１）、ディスクリプタＳ−１を参照して、ゲストＯＳが書き込んだ転送データを回収する。ａｖａｉｌリングからデータを回収した後、回収した分だけ、ｕｓｅｄリング列を次のようにアップデートする。

仮想マシン側はａｖａｉｌリングから１つずつ回収するたびに、ｕｓｅｄｉｄｘの値をインクリメントしながら、ａｖａｉｌリングに書き込まれていたディスクリプタ番号をｕｓｅｄリングに書き込んでいく。書き込み後、ｕｓｅｄｉｄｘを１つずつインクリメントする。仮想マシンがｕｓｅｄリング列のアップデートが終了すると、ｌａｓｔ＿ａｖａｉｌ＿ｉｄｘを０にアップデートして、ｕｓｅｄリング更新通知を利用して、ゲストＯＳに通知する。

図６において、ゲストＯＳは仮想マシンから通知を受けて、ｕｓｅｄｉｄｘとゲストＯＳが管理するｌａｓｔ＿ｕｓｅｄ＿ｉｄｘからｕｓｅｄリング０番に記載されているディスクリプタ番号が参照するデータ領域を解放するとともに、ｌａｓｔ＿ｕｓｅｄ＿ｉｄｘを０に変更する。

以上のようにして、ａｖａｉｌリング列とｕｓｅｄリング列をそれぞれリングバッファとして循環利用しながら、データ転送を実現する。

（子側（例：仮想マシン）から親側（例：ゲストＯＳ）へのデータ転送）
子側から親側へのデータ転送は、受信専用キューを利用する。親側から子側への転送の初期状態とは異なり、子側から親側へ送信する場合は、利用可能なａｖａｉｌリング列に確保済みディスクリプタをできるだけ多く用意する。

図７において、受信専用キューを用意するときに、全ディスクリプタをａｖａｉｌリング列に書き込み、ａｖａｉｌｉｄｘをＳ−１に進めた状態とする。

図８において、仮想マシンがデータをゲストＯＳに転送する場合、利用可能なａｖａｉｌリング列から取り出す。例えば、１つのデータを転送する場合、ｌａｓｔ＿ａｖａｉｌ＿ｉｄｘが初期化されていることからａｖａｉｌリング０番を参照し、ディスクリプタＳ−１を利用して、転送用データを書き込む。ｌａｓｔ＿ａｖａｉｌ＿ｉｄｘは０にアップデートする。その後、ｕｓｅｄｉｄｘが初期化されていることから、ｕｓｅｄリング０番に利用したディスクリプタ番号Ｓ−１を記載して、ｕｓｅｄｉｄｘを０にアップデートした後、ｕｓｅｄリング更新通知をゲストＯＳに送信する。

図９において、ゲストＯＳは仮想マシンからｕｓｅｄリング更新通知を受けて、ｕｓｅｄｉｄｘとゲストＯＳが管理するｌａｓｔ＿ｕｓｅｄ＿ｉｄｘからｕｓｅｄリング０番に記載されているディスクリプタ番号が参照するデータ領域を転送データとして回収するとともに解放し、ｌａｓｔ＿ｕｓｅｄ＿ｉｄｘを０に変更する。

以上のようにして、あらかじめゲストＯＳ側でディスクリプタが確保された状態でａｖａｉｌリング列とｕｓｅｄリング列をそれぞれリングバッファとして循環利用しながら、仮想マシンからゲストＯＳへのデータ転送を実現する。

以上のとおり、ゲストＯＳから仮想マシン側への転送（ゲストＯＳから見ると送信）、仮想マシン側からゲストＯＳ側への転送（ゲストＯＳから見ると受信）について、説明した。これらをまとめた図が、図１０である。

＜Ｖｉｒｔｉｏを利用したゲストＯＳと自仮想マシン外部との通信方法について＞
仮想マシン内のゲストＯＳが外部と通信する場合は、子側が外部と接続し、子側が外部と親側の中継役としてデータを送受信する必要がある。例えば、ゲストＯＳとホストＯＳ間の通信がその例の１つである。ここで、外部をホストＯＳとした場合、既存の通信方法として２パターン存在する。

第１の方法（以下、外部通信方式１と呼ぶ）は、仮想マシン内に子側の端点を構築し、ゲストＯＳと仮想マシン間の通信と、ホストＯＳが提供する通信端点（通常、ｔａｐ／ｔｕｎデバイスと呼ばれる）を、仮想マシン内で接続することにより以下のとおりの接続を構築し、ゲストＯＳからホストＯＳへの通信を実現する。
（参１）［構築される接続］

このとき、ゲストＯＳはｔａｐドライバやホストＯＳが動作するカーネル空間というメモリ領域とは異なる権限を持つユーザ空間というメモリ領域で動作しているため、ゲストＯＳからホストＯＳへの通信には最低１回メモリコピーが発生してしまう（図１２）。

第２の方法（以下、外部通信方式２と呼ぶ）は、これを解決する手段として、ｖｈｏｓｔ−ｎｅｔという技術が存在する。ｖｈｏｓｔ−ｎｅｔでは一度仮想マシン内で構築された親側の構成情報（共有バッファキューの大きさ、キューの数、識別子、リングバッファへアクセスするための先頭アドレス情報など）をホストＯＳ内部のｖｈｏｓｔ−ｎｅｔドライバにコピーし、子側の端点の情報をホスト内部に構築することにより、共有バッファキューの操作をゲストＯＳとホストＯＳ間で直接実施することを可能とする技術である。これにより、コピーは実質０回で済むようになり、Ｖｉｒｔｉｏ−ｎｅｔに比べ、コピー回数が１回少ない分、外部通信方式１と比較し、より高速にデータ転送が実現できる。

ｈｔｔｐ：／／ｏｚｌａｂｓ．ｏｒｇ／〜ｒｕｓｔｙ／ｖｉｒｔｉｏ−ｓｐｅｃ／ｖｉｒｔｉｏ−０．９．５．ｐｄｆ（２０１４年３月１０日検索） ｈｔｔｐ：／／ｗｗｗ．ｉｎｔｅｌ．ｃｏ．ｊｐ／ｃｏｎｔｅｎｔ／ｗｗｗ／ｊｐ／ｊａ／ｃｏｍｍｕｎｉｃａｔｉｏｎｓ／ｃｏｍｍｕｎｉｃａｔｉｏｎｓ−ｐａｃｋｅｔ−ｐｒｏｃｅｓｓｉｎｇ−ｂｒｉｅｆ．ｈｔｍｌ（２０１４年３月１０日検索）

Ｖｉｒｔｉｏでは、ゲストＯＳと仮想マシン（またはその先に存在するホストＯＳ）間を結ぶ、同一物理サーバ内の仮想通信路を構築するトランスポートの抽象化技術として考えられた。ただし、外部との通信を考慮する場合は、仮想マシンと外部との接続を考慮する必要がある。

既存の方式では、外部通信方式１と外部通信方式２が開発されており、ホストＯＳとの通信を基本としている。この場合、データ転送性能向上のためにはホストＯＳを経由した通信をできるだけ高速にするために、コピー回数を少なくすることが課題として挙げられる。この課題に対し、既に述べたようにｖｈｏｓｔ−ｎｅｔという実質ゼロコピーを実現する技術が考えられている。

近年、ソフトウェア実装による通信アプリケーションのスループット向上のためにホストＯＳを経由しないバイパス高速化技術（例えば、非特許文献２のインテルＤＰＤＫ）が考えられており、これにより物理ホスト内の構成は従来、中継機能を持つ仮想スイッチなどのホストＯＳ側で実装されていたものが、外部プロセスで実装され、仮想マシンとともに同じプロセスで動作するケースが多くなる。しかし、ｖｈｏｓｔ−ｎｅｔはプロセス間通信について考慮されておらず、従来の通り、ｔａｐデバイスを利用することにより、実質コピーが最低１回発生することになる（課題１）（図１３を参照のこと）。

また、前述のとおり、ホストＯＳをバイパスするケースでは、仮想マシンと外部プロセス間の通信が多くなると同時に、メンテナンスやエラーによって、各プロセスを接続先へ影響がなく、切り替えや再起動等のユースケースが必ず発生する。しかし、ｖｈｏｓｔ−ｎｅｔはキュー操作のみゲストＯＳとホストＯＳ間で共有することを目的に設計されており、ホストＯＳ上でモジュールとして動作することから、モジュールエラーやモジュールが削除される等の障害系のイベントに対する対処機能が仮想マシンの通信デバイス側、ｖｈｏｓｔ−ｎｅｔのホストＯＳモジュール側両方に備わっていない（課題２）（図１３を参照のこと）。

そこで、本発明は、上記２つの課題を解決するために、バイパス高速化技術において仮想マシンと外部プロセスとの間の通信のスループットを向上でき、障害系のイベントに対する対処機能を有する仮想通信路構築システム、仮想通信路構築方法、及び仮想通信路構築プログラムを提供することを目的とする。

上記目的を達成するために、本願発明は、外部プロセス側と仮想マシン側を仮想通信路で直接接続するとともに、接続相手の状態を検知し、相手の状態に応じて再接続する機能を備えることとした。

具体的には、本発明に係る仮想通信路構築システムは、
仮想マシン及び前記仮想マシン外に形成された外部プロセスが動作可能なホストＯＳを有する物理マシンと、
前記仮想マシン内で動作するゲストＯＳに、前記仮想マシンと前記外部プロセスとを直接接続する仮想通信路を構築させる通信路構築手段と、
を備える。

具体的には、本発明に係る仮想通信路構築方法は、
仮想マシン及び前記仮想マシン外に形成される外部プロセスが動作可能なホストＯＳを有する物理マシン上に、前記仮想マシン及び前記外部プロセスを形成する仮想マシン形成手順と、
前記仮想マシン内で動作するゲストＯＳに、前記仮想マシンと前記外部プロセスとを直接接続する仮想通信路を構築させる仮想通信路構築手順と
を行う。

本発明は、外部プロセス側と仮想マシン側を直接接続することができるため、メモリコピー回数とコンテキストスイッチ切り替え回数を外部通信方式１、２に対し少なくすることができ、高速にデータ転送を実現することができる。従って、本発明は、バイパス高速化技術において仮想マシンと外部プロセスとの間の通信のスループットを向上できる仮想通信路構築システム、及び仮想通信路構築方法を提供することができる。

本発明に係る仮想通信路構築システムの前記通信路構築手段は、
前記仮想マシンと前記ゲストＯＳとの間のデータ転送用として形成された共有バッファキューについて、メモリ操作で前記共有バッファキューのデータ転送先を前記外部プロセスへ拡張して前記仮想通信路を構築するとともに、前記ゲストＯＳと前記外部プロセスとの間の通信に関する手続きを実現させる共有バッファキュー拡張用プロトコル機能を有することを特徴とする。

本発明に係る仮想通信路構築方法の前記仮想通信路構築手順は、
前記仮想マシンと前記ゲストＯＳとの間のデータ転送用として形成された共有バッファキューについて、メモリ操作で前記共有バッファキューのデータ転送先を前記外部プロセスへ拡張して前記仮想通信路を構築するとともに、前記ゲストＯＳと前記外部プロセスとの間の通信に関する手続きを実現させる共有バッファキュー拡張ステップを有することを特徴とする。

本発明は、仮想デバイスとゲストＯＳ間の共有バッファキューで実現されるデータ転送と同様に、ゲストＯＳと外部プロセス間のデータ転送を共有バッファキューのメモリ操作で実現する。

本発明に係る仮想通信路構築システムの前記通信路構築手段は、
前記仮想通信路の状態を検知する接続状態検知機能と、
前記仮想通信路の状態をそれぞれ前記ゲストＯＳと前記外部プロセス上の処理ロジックに通知する接続状態通知機能と、
それぞれの前記通信デバイスが通信断のときに定期的に通信先と再接続する再接続機能と、
をさらに有することを特徴とする。

本発明に係る仮想通信路構築方法の前記仮想通信路構築手順は、
前記仮想通信路の状態を検知する接続状態検知ステップと、
前記仮想通信路の状態をそれぞれ前記ゲストＯＳと前記外部プロセス上の処理ロジックに通知する接続状態通知ステップと、
それぞれの前記通信デバイスが通信断のときに定期的に通信先と再接続する再接続ステップと、
をさらに有することを特徴とする。

さらに、本発明は、想マシン、外部プロセスそれぞれの通信デバイスが、お互い接続相手の状態に関し、状態変化を検知し、自身内部へ通知することにより、ゲストＯＳや外部プロセス内部の処理ロジックに対し、障害発生やメンテナンスなどの事象に対処する機会を創出することができる。また、本発明は、仮想マシン、外部プロセスは切断状態に陥ったときに、正しく状態を把握できることにより、それを契機として、接続相手を切り替える動作に移ることができる。従って、本発明は、バイパス高速化技術において障害系のイベントに対する対処機能を有する仮想通信路構築システム、及び仮想通信路構築方法を提供することができる。

本発明に係る仮想通信路構築プログラムは、仮想マシン及び前記仮想マシン外に形成される外部プロセスが動作可能なホストＯＳを有する物理マシンに、請求項４から６のいずれかに記載の仮想通信路構築方法を実現させる。

仮想マシン及び前記仮想マシン外に形成される外部プロセスが動作可能なホストＯＳを有する物理マシンに、前記仮想通信路構築プログラムを動作させることで前記仮想通信路構築方法を実現できる。

本発明は、バイパス高速化技術において仮想マシンと外部プロセスとの間の通信のスループットを向上でき、障害系のイベントに対する対処機能を有する仮想通信路構築システム、仮想通信路構築方法、及び仮想通信路構築プログラムを提供することができる。

Ｖｉｒｔｉｏ−ｎｅｔデバイスの送受信端点の構成を説明する図である。＜Ａ＞は、親側の端点であり、リングバッファメモリ領域を作成し、子側にそのアドレスを教えて、親子でデータにアクセスできるようにする。＜Ｂ＞は、子側の端点であり、親側に必要なリングバッファの大きさと個数を要求する。ゲストＯＳ起動時にその要求にあわせて、ドライバが親側を用意する。子側は、親側が用意したリングバッファメモリ領域のアクセスのためのアドレスが親側から通知される。 Ｖｉｒｔｉｏキューの構成 を説明する図である。 ゲストから仮想マシンへのデータ転送時のＶｉｒｔｉｏキューのオペレーションを説明する図である。 ゲストから仮想マシンへのデータ転送時のＶｉｒｔｉｏキューのオペレーションを説明する図である。 ゲストから仮想マシンへのデータ転送時のＶｉｒｔｉｏキューのオペレーションを説明する図である。 ゲストから仮想マシンへのデータ転送時のＶｉｒｔｉｏキューのオペレーションを説明する図である。 仮想マシンからゲストＯＳへのデータ転送時のＶｉｒｔｉｏキューのオペレーションを説明する図である。 仮想マシンからゲストＯＳへのデータ転送時のＶｉｒｔｉｏキューのオペレーションを説明する図である。 仮想マシンからゲストＯＳへのデータ転送時のＶｉｒｔｉｏキューのオペレーションを説明する図である。 Ｖｉｒｔｉｏキューの操作と通知（接続先がｔａｐデバイスの場合）を説明する図である。 ＴＡＰデバイスを使った外部通信方式１を説明する図である。 ｖｈｏｓｔ−ｎｅｔドライバを使った外部通信方式２を説明する図である。 ｖｈｏｓｔ−ｎｅｔを利用した仮想マシンと外部プロセス間通信を説明する図である。 本発明に係る仮想通信路構築システムにおける新機能と構成概要を説明する図である。 本発明に係る仮想通信路構築方法における仮想マシンとゲストＯＳの起動シーケンスを説明する図である。 本発明に係る仮想通信路構築システムの具体的な構成図を説明する図である。 外部プロセスのｖｉｒｔｑｕｅｕｅデバイスにおける送信用・受信用共有バッファキュー管理部２における管理データを説明する図である。この図の例では、送信用バッファキュー、受信用バッファキューはそれぞれ１つずつ。またそれぞれのサイズは省略しているがデフォルト２５６である。 共有バッファキュー拡張用プロトコルのシグナリングの制御メッセージシーケンスとフォーマットを説明する図である。 外部プロセス（サーバ側）の制御メッセージ受信フローチャートを説明する図である。 外部プロセスの起動と状態シーケンスを説明する図である。 キューの操作と通知（接続先が外部プロセスの場合）を説明する図である。 キューの操作と通知（接続先が外部プロセスの場合）を説明する図である。 ゲストＯＳ、仮想マシン、及び外部プロセスの動作パターンと状態遷移パターンを説明する図である。 ベーシック認証を利用した接続を説明する図である。 ダイジェスト認証を利用した接続を説明する図である。 ＳＳＬ認証を利用した接続を説明する図である。 本発明を適用したＮＦＶとＳＤＮを利用した仮想ＢＲＡＳネットワークノードのモデルを説明する図である。

添付の図面を参照して本発明の実施形態を説明する。以下に説明する実施形態は本発明の実施例であり、本発明は、以下の実施形態に制限されるものではない。なお、本明細書及び図面において符号が同じ構成要素は、相互に同一のものを示すものとする。

＜本発明の概要＞
本発明に係る「仮想通信路構築システム及び仮想通信路構築方法」は、ゲストＯＳと外部プロセス間の通信路構築システムおよびその制御方法である。本発明は、仮想マシンおよび外部プロセスがそれぞれ具備する通信デバイス（通信インタフェース）への新規機能追加を対象とする（図１４を参照。）。

本発明は、仮想マシン及び前記仮想マシン外に形成された外部プロセスが動作可能なホストＯＳを有する物理マシンと、前記仮想マシン内で動作するゲストＯＳに、前記仮想マシンと前記外部プロセスとを直接接続する仮想通信路を構築させる通信路構築手段と、を備える仮想通信路構築システムである。そして、前記通信路構築手段は、前記仮想マシンと前記ゲストＯＳとの間のデータ転送用として形成された共有バッファキューについて、メモリ操作で前記共有バッファキューのデータ転送先を前記外部プロセスへ拡張して前記仮想通信路を構築するとともに、前記ゲストＯＳと前記外部プロセスとの間の通信に関する手続きを実現させる共有バッファキュー拡張用プロトコル機能を有することを特徴とする。

前記物理マシンで仮想通信路構築プログラムを実行することで、前記物理マシンに仮想マシン及び前記仮想マシン外に形成される外部プロセスが動作可能なホストＯＳを有する物理マシン上に、前記仮想マシン及び前記外部プロセスを形成する仮想マシン形成手順と、前記仮想マシン内で動作するゲストＯＳに、前記仮想マシンと前記外部プロセスとを直接接続する仮想通信路を構築させる仮想通信路構築手順を実現することができる。このとき、前記仮想通信路構築手順は、前記仮想マシンと前記ゲストＯＳとの間のデータ転送用として形成された共有バッファキューについて、メモリ操作で前記共有バッファキューのデータ転送先を前記外部プロセスへ拡張して前記仮想通信路を構築するとともに、前記ゲストＯＳと前記外部プロセスとの間の通信に関する手続きを実現させる共有バッファキュー拡張ステップを有することを特徴とする。

具体的にはゲストＯＳと仮想マシンとのデータ転送用の共有バッファキューによるデータ転送を仮想マシンの通信先である外部プロセスへ拡張し、仮想マシンと外部プロセス間での共有バッファキューのメモリ操作によりデータ送受信を実現とする。

前記通信路構築手段は、
前記仮想通信路の状態を検知する接続状態検知機能と、
前記仮想通信路の状態をそれぞれ前記ゲストＯＳと前記外部プロセス上の処理ロジックに通知する接続状態通知機能と、
それぞれの前記通信デバイスが通信断のときに定期的に通信先と再接続する再接続機能と、
をさらに有する。

前記仮想通信路構築手順は、
前記仮想通信路の状態を検知する接続状態検知ステップと、
前記仮想通信路の状態をそれぞれ前記ゲストＯＳと前記外部プロセス上の処理ロジックに通知する接続状態通知ステップと、
それぞれの前記通信デバイスが通信断のときに定期的に通信先と再接続する再接続ステップと、
をさらに有する。

共有バッファキューによる接続では、仮想マシンと外部プロセスが障害やメンテナンスなどの理由により、それぞれ独立して動作を停止させた場合も、接続相手（仮想マシンまたは外部プロセス）の動作に影響がないように（ハングアップ等が発生しないように）、仮想マシン内と外部プロセスが利用する通信デバイス（通信インタフェース）はそれぞれ次の機能を持つ。
（ａ）通信接続確立手続き、キューの操作モード交換手続き、バッファキューの更新通知手続き、接続終了手続きを実現する共有バッファキュー拡張用プロトコル機能
（ｂ）通信確立中の接続状態検知機能
（ｃ）通信確立中の接続状態通知機能
ここで、接続状態通知機能とは、通信が確立した場合に仮想マシン内部または外部プロセス内部へインタフェースアップの状態通知する機能、及び通信が切断した（またはされた）場合にインタフェースダウンの状態通知する機能である。
（ｄ）切断状態では、再度通信先へ定期的に接続する再接続機能

さらに、本発明では次の拡張が可能である。
・外部プロセスと仮想マシン間の接続プロトコル
・他のバッファ方式
・ネットワーク以外のファイル入出力やコンソール入出力といった共有バッファキューで実現可能な入出力方式

以下に具体的な実施例を説明する。

＜実施例１＞
実施例１においては、親側と子側間で既に説明したＶｉｒｔｉｏで定義された共有バッファキューのオペレーションを前提とする。

（１）仮想マシンと外部プロセスとの接続構成図
図１６を用いて本発明の構成について記載する。
［構成１］
本実施例の仮想通信路構築システムは、
［接続状態管理部１］１１、［受信データ更新通知部１］１２、［受信データバッファキュー設定部１］１３、［デバイス動作・フィーチャ設定部１］１４、［送信データバッファキュー設定部１］１５、［送信データ更新通知部１］１６及び［デバイス種別登録部１］１７から構成される仮想通信デバイスを表現し、ゲストＯＳ側に仮想通信デバイスへのアクセスとゲストＯＳ側で作成される共有バッファキューの情報を仮想デバイス側へ伝達するための［通信デバイスインタフェース部］１０と、
［通信デバイスインタフェース部］１０の［受信データバッファキュー設定部１］１３、［デバイス動作・フィーチャ設定部１］１４及び［送信データバッファキュー設定部１］１５を介して設定される共有バッファキューの送信・受信それぞれのバッファキューの種類、大きさ、個数を管理する［送信用・受信用共有バッファキュー管理部１］２０と、
仮想マシン起動時に起動オプションを処理する［基本設定処理部１］３０と、
［接続状態通知機能部１］４１、［接続状態検知機能部１］４２、［接続・通信処理基本部１］４３、［共有バッファキュー拡張用プロトコル処理部１］４４及び［基本設定管理部１］４５からなる［通信部（クライアント）］４０と、
を備えた、起動オプションに指定されるファイル記述子で指定される接続先に接続する機能を備える、仮想マシン側の［通信デバイス１］１００（ｖｉｒｔｉｏ−ｎｅｔ−ｉｐｃデバイスと呼ぶ）、並びに
［接続状態管理部２］５１、［受信データ出力部２］５２、［受信データ通知部２］５３、［デバイス動作・フィーチャ設定部２］５４、［送信データ入力部２］５５、［送信データ通知部２］５６及び［デバイス種別登録部２］５７から構成される、外部プロセスへ通信インタフェースを提供する、インタフェース部５０と、
［受信用共有バッファキュー処理部２］６１、［送信用・受信用共有バッファキュー管理部２］６２及び［送信用共有バッファキュー処理部２］６３からなるゲストＯＳで作成された共有バッファキューにメモリアクセスし、共有バッファキューを操作可能とする共有バッファキュー操作部６０と、
外部プロセス起動時に起動オプションを処理する［基本設定処理部２］７０と、
［接続状態通知機能部２］８１、［接続状態検知機能部２］８２、［接続・通信処理基本部２］８３、［共有バッファキュー拡張用プロトコル処理部２］８４及び［基本設定管理部２］８５からなる［通信部（サーバ）］８０と、
を備えた、起動オプションに指定されるファイル記述子で指定される接続先に接続する機能を備える、外部プロセス側の［通信デバイス］２００
で構成される。

［構成２］
［送信用・受信用共有バッファキュー管理部１］２０は、ゲストＯＳに［受信データバッファキュー設定部１］１３、［デバイス動作・フィーチャ設定部１］１４、［送信データバッファキュー設定部１］１５を提供することにより、共有バッファキュー情報をゲストＯＳから取得し、その情報を管理することを可能とする。

［構成３］
［通信デバイスインタフェース部］１０は、ゲストＯＳに［接続状態管理部１］１１を提供し、［接続・通信処理基本部１］４３と［接続状態検知機能部１］４２と［接続状態通知機能部１］４１とが連携して、ゲストＯＳに対し、インタフェース状態のオン／オフを認識させることのできる機能を備える。

［構成４］
［送信用・受信用共有バッファキュー管理部１］２０と［共有バッファキュー拡張用プロトコル処理部１］４４は、連携して外部プロセスに共有バッファキュー情報を提供する初期化シーケンス、設定シーケンス、更新通知シーケンス、及び終了シーケンスを実行可能なプロトコルを具備する。各シーケンスについては後述する。

［構成５］
［通信デバイスインタフェース部］１０の動作が割り込み有りの場合、［受信データ更新通知部１］１２、［送信データ更新通知部１］１６及び［共有バッファキュー拡張用プロトコル処理部１］４４２０は、連携して外部プロセスにバッファキュー内容の更新の通知を更新通知シーケンスに従って実施する。

［構成６］
［通信デバイスインタフェース部］１０の動作が割り込みなし（ポーリングモード）の場合、［通信デバイス１］１００は、［受信データ更新通知部１］１２及び［送信データ更新通知部１］１６を利用せずに仮想マシンのデバイスドライバ側がポーリングモードで動作することにより、外部プロセスとの転送データ（送受信ともに）やり取りすることができる。

［構成７］
［送信用・受信用共有バッファキュー管理部１］は、管理する共有するバッファキューの種別・個数・サイズ情報をバージョン番号にマッピングし、そのバージョン情報をもとに仮想マシンと外部プロセス間で共有バッファキューの構成情報を共有することを可能とする。

［構成８］
［デバイス種別登録部１］１７は、仮想マシン起動時の様々なオプション情報を処理する［基本設定処理部１］とそれら情報から共有バッファキュー種別に対応したデバイス情報を登録することができる。［基本設定管理部１］４５３０は、そのオプション情報すべてを管理することができる。

［構成１０］
［通信デバイス１］１００は、仮想マシンから取得したデータ転送モード（割り込み有り／割り込み無し（ポーリングモード））やデバイスフィーチャ情報を、［送信用・受信用共有バッファキュー管理部２］６２を通して、［デバイス動作・フィーチャ設定部２］５４に提供することにより、共有バッファキューの動作モードとフィーチャ情報を外部プロセスに通知する。これにより外部プロセスがゲストＯＳと外部プロセス間の仮想通信路を認識可能となる。

［構成１１］
割り込みありの動作の場合に、仮想マシンからの転送データを受信する場合、更新通知シーケンスで通知される更新通知を［共有バッファキュー拡張用プロトコル処理部２］８４が処理し、［受信用共有バッファキュー処理部２］６１が［受信インタフェース］に転送データを転送し、かつ、転送データがあった旨を［受信データ通知部２］５３に通知する。

［構成１２］
割り込みなし（ポーリングモード）の動作の場合に、仮想マシンからの転送データを受信する場合、［受信用共有バッファキュー処理部２］６１は、［受信データ通知部２］５３を利用せずに、［受信データ出力部２］５２からのデータ取得要求に従い共有バッファキュー処理を実施し、ポーリングモードで転送データを受信する。

［構成１３］
割り込みありの動作の場合に、外部プロセスから仮想マシンへ転送データを送信する場合、［送信データ入力部２］５５が転送データを受け取り、［送信用共有バッファキュー処理部２］６３が共有バッファキュー処理を実行した後、［共有バッファキュー拡張用プロトコル処理部２］８４は、仮想マシン側へ更新通知を送信し、送信データの受け取り完了通知が必要な場合は［送信データ通知部２］５６を通して、処理ロジックへ通知する。

［構成１４］
割り込みなし（ポーリングモード）の動作の場合に、外部プロセスから仮想マシンからの転送データを送信する場合、［送信データ通知部２］５６を利用せずに、処理ロジックから［送信データ入力部２］５５へ入力された転送データについて［送信用共有バッファキュー処理部２］６３が共有バッファキュー処理を実施し、［共有バッファキュー拡張用プロトコル処理部２］８４は、ポーリングモードで転送データを仮想マシン側へ送信する。

［構成１５］
外部プロセスは、［接続・通信処理基本部２］８３と［接続状態検知機能部２］８２と［接続状態通知機能部２］８１とが連携して、外部プロセスの処理ロジックに対し、インタフェース状態のオン／オフを認識させることのできる機能を備える。

［構成１６］
［送信用・受信用共有バッファキュー管理部２］６２と［共有バッファキュー拡張用プロトコル処理部２］８４は、互いに連携して、初期化シーケンス、設定シーケンス、更新通知シーケンス、及び終了シーケンスを通して仮想マシンから提供される共有バッファキュー情報を取得可能なプロトコルを具備する。

［構成１７］
［送信用・受信用共有バッファキュー管理部２］６２は、仮想マシンから受信する共有バッファキューのバージョン情報をバッファキューの種別・個数・サイズ情報に分解・マッピングして管理し、バージョン情報をもとに仮想マシンと外部プロセス間で共有バッファキューの構成情報を共有する。

［構成１８］
［基本設定処理部２］７０は、外部プロセス起動時の様々なオプション情報を処理する。［デバイス種別登録部２］５７は、それら情報から共有バッファキュー種別に対応したデバイス情報を登録することができる。［基本設定管理部２］８５は、オプション情報すべてを管理することができる。

次に、図１５のフローチャートと図１６の各機能部の記載を交えながら、仮想通信路構築システムの動作について説明する。

（２）仮想マシンと外部プロセスとの接続方法
本発明は、仮想マシンと外部プロセス間で共有バッファキューのメモリ共有によるデータ転送を実現する手段として、それぞれの通信デバイスであるｖｉｒｔｉｏ−ｎｅｔ−ｉｐｃデバイスとｖｉｒｔｑｕｅｕｅデバイス間をＩＰＣ（Ｉｎｔｅｒ Ｐｒｏｃｅｓｓ Ｃｏｍｍｕｎｉｃａｔｉｏｎ）を使って接続を実現する。

ＩＰＣでは実装方法として多種多様に存在するが、実施例１では、多くのＯＳで対応しているソケット（または、ＵＮＩＸ（登録商標）ドメインソケットとする）を利用する。ソケットでは、ファイル記述子を利用して接続を確立する。

仮想マシン側は、クライアントとして動作する。仮想マシンは起動時に引数として、外部プロセスと接続する仮想マシンの仮想ネットワークデバイスとしてｖｉｒｔｉｏ−ｎｅｔデバイスの識別子、外部プロセスへの接続に利用するファイル記述子（ここでは、ｓｏｃｋｅｔｐａｔｈとする）、外部プロセスへの再接続インターバル（ここでは、ｃｉｎｔｅｒｖａｌとする。）、仮想マシンと外部プロセスの組み合わせを一意に認識するためのノードＩＤの４つの引数を組み合わせとして起動する（図１５のＳ１０１）。クライアントノード名はオプションである。
（参２）［仮想マシンの起動時引数］

起動後、［基本設定処理部１］において、ｖｉｒｔｉｏ−ｎｅｔデバイスの識別子と、ｓｏｃｋｅｔｐａｔｈ記述子（ファイルパス）とを両方確認し、両方が設定されていた場合は、［デバイス種別登録部１］１７に対し、ｖｉｒｔｉｏ−ｎｅｔデバイスとして登録する。一方で、外部接続先をソケットとするｖｉｒｔｉｏ−ｎｅｔ−ｉｐｃデバイスとして［基本設定管理部１］４５に登録する（図１５のＳ１０２）。また、起動オプションはすべて、［基本設定管理部１］４５に情報登録される。

ここで、ゲストＯＳが起動していなければゲストＯＳを起動させる（図１５のＳ１２１）。ゲストＯＳは、物理マシンのメモリ内に共有バッファキュー用の領域を確保する（図１５のＳ１２２）。ゲストＯＳは、仮想マシンとの間で共有バッファキューの情報及び通信デバイスの機能（フィーチャ）について交換を実施し（図１５のＳ１２３）、起動を完了する（図１５のＳ１２４）。

仮想マシン起動後、外部プロセスとの接続が確立し、後述する設定が正しく完了するまでは、ゲストＯＳに仮想デバイスの状態を通知する［接続状態管理部１］１１ではインタフェースはダウンの状態のままである。

仮想マシンは起動時、［デバイス種別登録部１］１７にｖｉｒｔｉｏ−ｎｅｔデバイスとして登録することで、ゲストＯＳ側からはｖｉｒｔｉｏ−ｎｅｔデバイスとして認識するため、ゲストＯＳ側では起動時にｖｉｒｔｉｏ−ｎｅｔデバイスに対応したｖｉｒｔｉｏ−ｎｅｔドライバを起動させる（しかし、仮想マシンの通信デバイスとしてはｖｉｒｔｉｏ−ｎｅｔ−ｉｐｃデバイスとして動作する）（図１５のＳ１０２））。

［デバイス種別登録部１］１７へ登録が完了した後、［基本設定管理部１］４５に設定されたｓｏｃｋｅｔｐａｔｈが示すファイルパスを［接続・通信処理基本部１］４３に設定し、接続先を登録することにより（図１５のＳ１０３）、接続を試みる（図１５のＳ１０４）。

外部プロセスが接続不能な状態の場合（図１５のＳ１０５において“Ｎｏ”）、仮想マシンの起動オプションで指定された時間待ち（図１５のＳ１１４）、再度接続を試みる（図１５のＳ１０４）。

外部プロセスが接続可能な状態の場合（図１５のＳ１０５において“Ｙｅｓ”）、ｓｏｃｋｅｔｐａｔｈに従って直接ソケットを介して［接続・通信処理基本部１］４３により接続が確立する。以後、外部プロセスとは図１８に示す通りのシーケンスをフェーズに従って実施する（図１５のＳ１０６）。また、仮想マシンのｖｉｒｔｉｏ−ｎｅｔ−ｉｐｃデバイスと外部プロセスのｖｉｒｔｑｕｅｕｅデバイス間のメッセージ交換においては、図１８に示す制御メッセージフォーマットを利用する。

［共有バッファキュー拡張用プロトコル処理部１］４４は、［基本設定管理部１］４５によりノードＩＤ、クライアントノード名（オプション）と、［送信用・受信用共有バッファキュー管理部１］からバッファキューの構成を示すバージョン番号から、初期化メッセージを構成し、［接続・通信処理基本部１］４３を介して、仮想マシン側から外部プロセス側へ送信する（図１５のＳ１０６））。

以下、仮想マシン側のｖｉｒｔｉｏ−ｎｅｔ−ｉｐｃデバイスをクライアント、外部プロセス側のｖｉｒｔｑｕｅｕｅデバイスをサーバとも呼ぶ。
（参３）［初期化メッセージ］

サーバは、クライアントからの制御メッセージ（初期化メッセージ）を受信できる状態へ遷移し、制御メッセージの受信を開始する（図１９のＳ２０１、Ｓ２０２）。

サーバ側はクライアントと同様に、［接続・通信処理基本部２］８３を介して、［共有バッファキュー拡張用プロトコル処理部２］８４により、制御メッセージが処理され、メッセージ種別が初期化メッセージであることを確認し、バージョン番号とノードＩＤを確認する（図１９のＳ２０３）。

外部プロセスも後述の通り、起動時に［基本設定処理部２］を介して、［基本設定管理部２］８５でノードＩＤが管理されているため、外部プロセスのｖｉｒｔｑｕｅｕｅデバイスの持っているノードＩＤとサポートするバージョン番号を比較する（図１５のＳ１０７、図１９のＳ２０３）。

ノードＩＤとバージョン番号の２つの情報がマッチしていれば（図１５のＳ１０７において“Ｙｅｓ”、図１９のＳ２０３において“Ｙｅｓ”）、設定メッセージおよび終了メッセージ受信状態へ遷移する（図１５のＳ１０８及び図１９のＳ２０４）。一方、ノードＩＤとバージョン番号の２つの情報がマッチしていなければ（図１５のＳ１０７において“Ｎｏ”、図１９のＳ２０３において“Ｎｏ”）、接続が確立しないため（図１９のＳ２１１）、クライアント側は再接続状態へ遷移する（図１５のＳ１１４）。再接続は、［基本設定管理部１］４５で管理されるｃｉｎｔｅｒｖａｌ値を確認し、その値の時間間隔で再接続を繰り返し試行する（ｃｉｎｔｅｒｖａｌが０またはマイナス値に設定されていれば、再接続は繰り返さない）。

初期化メッセージ処理が正常に終了すると（図１５のＳ１０８）、仮想マシン側は設定メッセージを送信するフェーズに移行する。また、外部プロセス側は、設定メッセージである制御メッセージを受信するフェーズへ移行する。

設定メッセージでは、初期化メッセージで利用した情報に加え、ゲストＯＳから提供される共有バッファキューにアクセスするためのアドレス情報が必要となる。よって、ゲストＯＳが起動しているか否かを確認する（図１５のＳ１０９）。具体的には、［共有バッファキュー拡張用プロトコル処理部１］４４は［送信用・受信用共有バッファキュー管理部１］にゲストＯＳから設定される共有バッファキューの種別・先頭アドレス・個数・サイズが設定されているかどうか問い合わせる。

当該事項が設定されていなければ（図１５のＳ１０９において“Ｎｏ”）、ゲストＯＳが起動していないと判断して、［送信用・受信用共有バッファキュー管理部１］からの共有バッファキューの設定完了通知を待つ（図１５のＳ１１０、Ｓ１１０）。当該事項の設定が完了していれば（図１５のＳ１０９において“Ｙｅｓ”）、ゲストＯＳからの共有バッファキューの先頭アドレス情報を取得できるため、［共有バッファキュー拡張用プロトコル処理部１］４４はそれら情報を設定メッセージに追加して、外部プロセス（サーバ側）へ下記の内容で設定メッセージを送信する（図１５のＳ１１２）。
（参４）［設定メッセージ］

［送信用・受信用共有バッファキュー管理部１］への共有バッファキューの情報登録はゲストＯＳ側から、［受信データバッファキュー設定部１］１３を介して受信バッファキューの個数とサイズの情報が、［デバイス動作・フィーチャ設定部１］１４を介してデバイスフィーチャやデバイスの動作モード（割り込み有りか無し）が、［送信データバッファキュー設定部１］１５を介して送信バッファキューの個数とサイズが、それぞれ実施される。

サーバ側は設定メッセージを受信する（図１９のＳ２０５）と、初期化メッセージと同様に、［接続・通信処理基本部２］８３を介して、［共有バッファキュー拡張用プロトコル処理部２］８４にて、バージョン番号、ノードＩＤ、メッセージ種別を確認する（図１９のＳ２０６、Ｓ２０７）。

受信した制御メッセージのノードＩＤとバージョン番号がマッチしなければ（図１９のＳ２０６において“Ｎｏ”）、接続を切断する（図１９のＳ２１１）。受信した制御メッセージのノードＩＤとバージョン番号がマッチすれば（図１９のＳ２０６において“Ｙｅｓ”）、制御メッセージが設定メッセージであるか否かを確認する（図１９のＳ２０７）。

制御メッセージが設定メッセージである場合（図１９のＳ２０７において“Ｙｅｓ”）、共有バッファキューのアドレス情報、ｖｉｒｔｉｏ−ｎｅｔ−ｉｐｃデバイスのフィーチャ情報、動作モードを確認し（図１９のＳ２０９）、値がセットされ、かつ動作モードについては割り込み有効か無効どちらかの値が設定されていれば、設定を完了する（図１９のＳ２１０）。

これら情報は、サーバ側の［送信用・受信用共有バッファキュー管理部２］６２に管理される。このとき、バージョン番号に対応する、バッファキュー種別（ｖｉｒｔｉｏキュー）と、バッファキュー先頭アドレス、送信バッファキューの個数とサイズ情報、受信バッファキューの個数とサイズ情報とに分解されて登録される（図１７）。このバージョン情報については後述の（３）で説明する。

なお、メッセージ種別が設定メッセージ以外で終了メッセージでない場合（図１９のＳ２０７において“Ｎｏ”、Ｓ２０８において“Ｎｏ”）、及び共有バッファキューのアドレス情報、ｖｉｒｔｉｏ−ｎｅｔ−ｉｐｃデバイスのフィーチャ情報、動作モードが含まれていない場合（図１９のＳ２０９において“Ｎｏ”）は、設定メッセージの受信を待つ（図１９のＳ２０４）。また、図１９のＳ２０８でメッセージ種別が終了メッセージであれば、接続を切断する。

これらの情報を使い、［送信用・受信用共有バッファキュー管理部２］６２では、さらに仮想マシン上のゲストＯＳの共有バッファキューにアクセスするために、メモリマッピングを使い、内部で共有バッファキュー管理用変数として、送信用バッファキュー変数と受信用バッファキュー変数にそれぞれアドレス情報をマッピングさせる（図１７）。

仮想マシン側は設定メッセージの結果の応答を受け（図１８、図１９）、［共有バッファキュー拡張用プロトコル処理部１］４４は［接続状態通知機能部１］４１を介して、［接続状態管理部１］１１にリンクアップ状態を登録する。これにより、ゲストＯＳは通信デバイス（ｖｉｒｔｉｏ−ｎｅｔ−ｉｐｃデバイス）のリンクアップを認識する（図１５のＳ１１３）。なお、ゲストＯＳは、リンクアップ状態を確認する際に（図１５のＳ１２５）、リンクアップの登録が無ければ、仮想マシンがリンクアップ登録するまで待つ（図１５のＳ１２７、Ｓ１２８）。

外部プロセス側も同様に設定完了後、［共有バッファキュー拡張用プロトコル処理部２］８４は［接続状態通知機能部２］８１を介して、リンクアップ状態を登録する。これにより、通信デバイス（ｖｉｒｔｑｕｅｕｅデバイス）の状態をリンクダウン状態からリンクアップ状態に切り替え、外部プロセスの処理ロジックからデータ通信可能な状態へ切り替える。外部プロセス側の設定については後述の（７）で説明する。

（３）バージョン番号の解釈について
バージョン番号は、「バッファキュー種別」、「キューの個数」、「それぞれキューのサイズ」の組み合わせで表現される。キューは送信用、受信用ともに同じ個数であり、且つそれぞれのキューサイズも同一とする。

例えば、キュー種別４ビット、キュー個数１２ビット、キューサイズ１６ビットとし、‘０００１’の４ビットをｖｉｒｔｉｏキュー種別に割り当てるとする。この場合、図１７に記載のとおり、デフォルトのｖｉｒｔｉｏキューの構成とすると、送受信用キューは１つずつあり、サイズは２５６であるため、バージョン番号は次のように表現される。
（参５）［バージョン番号］

（４）メッセージタイプ依存データフィールド
図１８の制御メッセージフォーマットにおいて、メッセージタイプ依存データフィールドは、設定メッセージと更新通知メッセージにて以下の値で利用される。なお、フィーチャ情報は（５）に後述する。
（参６）［メッセージタイプ依存データフィールド］

（５）Ｖｉｒｔｉｏ−ｎｅｔ−ｉｐｃデバイスのフィーチャ情報と動作モードの合意プロセス
フィーチャ情報は、ゲストＯＳのｖｉｒｔｉｏ−ｎｅｔドライバがサポートするチェックサムオフロードなどの機能と、ｖｉｒｔｉｏ−ｎｅｔ−ｉｐｃデバイスがサポートする機能とがゲストＯＳ起動時に折衝され、合意されたものが、最終的なフィーチャ情報として確立する。このフィーチャ情報はＶｉｒｔｉｏのＳｐｅｃの通りであるため省略する（詳細は、非特許文献１を参照。）。

このフィーチャ情報の合意はゲストＯＳと仮想マシンと外部プロセス３者が同時に実施可能であればよいが、ゲストＯＳと仮想マシン間の合意が優先されるため、ゲストＯＳと仮想マシン間で初期に合意した情報をバージョン情報に変換し、外部プロセスに一方的に強制することで３者合意プロセスをスキップしている。よって、外部プロセス側はすべてのフィーチャに対応することを前提としている。

一方、動作モードについては、親側から子側へのａｖａｉｌリング更新通知の有効／無効、子側から親側へのｕｓｅｄリング更新通知の有効／無効の設定が可能である。更新通知がオフの場合は、相手側がポーリングモードで動作し、更新通知なしで自発的に転送データを回収することを示す。仮想マシンのｖｉｒｔｉｏ−ｎｅｔ−ｉｐｃデバイス、ゲストＯＳのｖｉｒｔｉｏ−ｎｅｔドライバ、外部プロセスのｖｉｒｔｑｕｅｕｅデバイスは両モードに対応している。この更新通知は、ゲストＯＳと仮想マシン、仮想マシンと外部プロセスの２区間で発生するが、ｖｉｒｔｉｏ−ｎｅｔ−ｉｐｃデバイスとｖｉｒｔｉｏ−ｎｅｔドライバ、ｖｉｒｔｑｕｅｕｅデバイスは両モードに対応しているため、別々に設定が可能である。しかし、本発明では、ゲストＯＳと仮想マシン間で折衝し合意した動作モードを外部プロセスにそのまま伝達することとしている。つまり２区間とも同じ動作になる。

（６）仮想マシンと外部プロセスとの切断方法
上記（２）において、仮想マシンと外部プロセスとの接続後、仮想マシン側の［共有バッファキュー拡張用プロトコル処理部１］４４または外部プロセス側の［共有バッファキュー拡張用プロトコル処理部２］８４からそれぞれ［接続・通信処理基本部１］４３、［接続・通信処理基本部２］８３を介して、終了メッセージを相手に送付することにより、切断を実現する。このとき、外部プロセスは、図１９の初期化メッセージや設定メッセージと同様に、バージョン番号、ノードＩＤを確認する（図１９のＳ２０６）。これらがマッチしていれば、接続終了状態となる（図１９のＳ２０７、Ｓ２０８、図１５のＳ１１５、図２０のＳ３１２）。

仮想マシン側は切断状態に遷移した場合、仮想マシン側が動作していれば再度接続を試みる（図１５のＳ１０４）が、仮想マシン自体が終了してしまった場合は当然、再接続は実施しない。

外部プロセス側も同様であり、外部プロセスが動作していれば接続待ち状態となるが（図２０のＳ３０３）、外部プロセス自体終了していれば再接続待ち状態にはならず、そのまま終了する。

（７）外部プロセスの起動シーケンス
外部プロセスは、通信デバイスとしてｖｉｒｔｑｕｅｕｅデバイスをインタフェースとして起動する（図１６）。

ｖｉｒｔｑｕｅｕｅデバイスは子側の共有バッファキューのオペレーション機能を図１６に記載の、［受信用共有バッファキュー処理部２］６１と［送信用・受信用共有バッファキュー管理部２］６２と［送信用共有バッファキュー処理部２］６３により有し、動作モードは前述の通り、割り込みモード及びポーリングモードをサポートするものである。

外部プロセスの起動シーケンスは図２０のとおりである。外部プロセスの起動は仮想マシンやゲストＯＳとは独立である。外部プロセスは起動指示に従って、起動を完了させる（図２０のＳ３１０、Ｓ３１１）とともに、通信デバイスとのリンクアップを開始する。

外部プロセス起動時、ｖｉｒｔｑｕｅｕｅデバイス識別子と仮想マシン起動時と同様に接続先としてｓｏｃｋｅｔｐａｔｈ、さらに接続の対を認識するためのノードＩＤの３つの引数が渡される（図２０のＳ３０１）。サーバのノード名はオプションである。
（参７）［外部プロセスの起動オプション］

外部プロセスはこれらの起動オプション情報を指定されると、図１６の外部プロセス側に記載の［基本設定処理部２］はこれらのパラメータを識別し、［基本設定管理部２］８５に登録する。そして、［デバイス種別登録部２］５７に登録し、デバイス種別が外部プロセス側の処理ロジックから認識できるようにする（図２０のＳ３０２）。

次に、［基本設定処理部２］はｓｏｃｋｅｔｐａｔｈで示されるファイルパスを［接続・通信処理基本部２］８３に設定し、［接続・通信処理基本部２］８３は仮想マシン側からの接続待ち状態で起動する（図２０のＳ３０３）。この状態では、外部プロセスの処理ロジックで確認することのできる［接続状態管理部２］５１においてインタフェースはダウンの状態のままである。

図２０のＳ３０４のとおり、仮想マシンからの接続があると、［接続・通信処理基本部２］８３を介して、［共有バッファキュー拡張用プロトコル処理部２］８４が初期メッセージを識別し、メッセージタイプが初期化メッセージで、且つ、ノードＩＤが［基本設定管理部２］８５で管理するノードＩＤと等しく、サポートしているバージョンであるかと確認する（図２０のＳ３０５）。

条件が満たされていない場合、サーバ側は再接続状態へ遷移する（図２０のＳ３０５において“Ｎｏ”）。条件が満たされている場合、初期化メッセージ処理が正常に終了し、接続が確立する（図２０のＳ３０６）。仮想マシン側は設定メッセージを送信するフェーズに移行し、外部プロセスは、設定メッセージ受信フェーズへ移行する（図１９のＳ２０４）。

その後、仮想マシン側からの設定メッセージを待ち受ける（図２０のＳ３０７、Ｓ３０８）。設定メッセージにおいても同様に、メッセージタイプとノードＩＤとバージョン番号を確認し、マッチしていれば、設定メッセージに含まれる、バージョン番号、共有バッファキューのアドレス情報、ｖｉｒｔｉｏ−ｎｅｔ−ｉｐｃデバイスのフィーチャ情報、動作モードを確認し、値がセットされ、かつ動作モードについては割り込み有効か無効どちらかの値が設定されていれば、設定を完了する（図１９のＳ２１０、図２０のＳ３０９）。これらの設定内容は［共有バッファキュー拡張用プロトコル処理部２］８４から［送信用・受信用共有バッファキュー管理部２］６２に設定・登録される。

その後、［送信用・受信用共有バッファキュー管理部２］６２では、登録内容を確認し、バージョン番号と共有バッファキューのアドレス情報より、図１７に記載のとおり、共有バッファキューを管理するための各種変数と作成する。本内容は上記（２）に説明済みであるため詳説を割愛する。

共有バッファキューの管理情報が［送信用・受信用共有バッファキュー管理部２］６２にて作成されると、［接続状態通知機能部２］８１を通して、［接続状態管理部２］５１にリンクアップ状態を登録する。

これを受け、外部プロセスは通信デバイスが利用可能状態になったことを認識する。

（８）仮想マシンと外部プロセス接続後のゲストＯＳから外部プロセスへのデータ送受信について（共有バッファキューの操作について）
共有バッファキューの操作については、ｖｉｒｔｉｏをベースとするため、従来の技術の＜Ｖｉｒｔｉｏキューの操作＞で説明したものと全く同じである。本発明により、キュー操作の子側の実施者が、仮想マシン上の通信デバイスから図１６に記載の外部プロセス上のｖｉｒｔｑｕｅｕｅデバイスに切り替わったと考えることができる。

ただし、動作モードが割り込み有りの場合の共有バッファキューの更新通知はｖｉｒｔｉｏ−ｎｅｔ−ｉｐｃデバイスとｖｉｒｔｑｕｅｕｅデバイス間のソケットを経由するため、共有バッファキューの通常のオペレーションに手順が１つ多くなる。つまり、動作モードにおいて、割り込みが有効である場合、図１８のとおり、共有バッファキューの更新通知が仮想マシン側と外部プロセス側間で送付することになる（図２１）。

一方、動作モードが割り込み無効である場合は、図１８に示す更新通知は発生しない。ｖｉｒｔｉｏ−ｎｅｔ−ｉｐｃデバイスとｖｉｒｔｑｕｅｕｅデバイスにてポーリングモードで動作し、キューのアップデートが有った場合自発的にアップデートのあったキューの転送データを回収する（図２２）。

＜割り込みモードの場合の処理＞
（ゲストＯＳから仮想マシンを通して、外部プロセスへ送信する場合）
図１６と図２１を利用し説明する。

１．ａｖａｉｌにディスクリプタを積む
ゲストＯＳはａｖａｉｌに送信データをディスクリプタに入れて積む
２．仮想マシンへ通知
ゲストＯＳは仮想マシンの通信デバイスへ通知。つまり、ｖｉｒｔｉｏ−ｎｅｔ−ｉｐｃデバイスの［共有バッファキュー拡張用プロトコル処理部１］４４は［送信データ更新通知部１］１６を通じて、更新があった旨を把握する。
３．外部プロセスへ通知
ｖｉｒｔｉｏ−ｎｅｔ−ｉｐｃデバイスは外部プロセスへ通知する。つまり、［共有バッファキュー拡張用プロトコル処理部１］４４は、外部プロセスのｖｉｒｔｑｕｅｕｅデバイスへ送信用キューのａｖａｉｌの更新通知メッセージを送信。
４．外部プロセスは更新通知を受信し、ａｖａｉｌを確認し、ディスクリプタを回収
（ａ）ｖｉｒｔｑｕｅｕｅデバイスの［共有バッファキュー拡張用プロトコル処理部２］８４において、更新メッセージ内の受信用キューの更新であることを知る。
（ｂ）［共有バッファキュー拡張用プロトコル処理部２］８４は［受信用共有バッファキュー処理部２］６１に更新通知を知らせる。
（ｃ）［受信用共有バッファキュー処理部２］６１は更新のあった、ディスクリプタを回収し、［受信データ通知部２］５３に受信したことを通知する。
（ｄ）処理ロジックからは、［受信データ出力部２］５２を通して、データを取得できるようになる
５．ｕｓｅｄに回収したディスクリプタを積む
［受信用共有バッファキュー処理部２］６１は［共有バッファキュー拡張用プロトコル処理部２］８４にｕｓｅｄに回収したディスクリプタを積んだことを知らせる。
６．ｕｓｅｄのアップデートを通知
［共有バッファキュー拡張用プロトコル処理部２］８４は更新メッセージを仮想マシン側のｖｉｒｔｉｏ−ｎｅｔ−ｉｐｃデバイスに送信。
７．ゲストＯＳへｕｓｅｄのアップデートを通知
ｖｉｒｔｉｏ−ｎｅｔ−ｉｐｃデバイスの［共有バッファキュー拡張用プロトコル処理部１］４４が更新メッセージを受信し、［送信データ更新通知部１］１６にｕｓｅｄのアップデートを通知。
８．ｕｓｅｄから外部プロセスが積んだディスクリプタを回収
ゲストＯＳは［送信データ更新通知部１］１６により、更新通知を受信し、ｕｓｅｄから外部プロセスが積んだディスクリプタを回収する。

（外部プロセスから、ゲストＯＳへ送信する場合）
図１６と図２１を利用して説明する。

１．ａｖａｉｌにディスクリプタを積む
（ａ）初期状態では外部プロセスが送信データを詰め込むための、ディスクリプタを仮想マシン側が用意しておく。つまり、ゲストＯＳが［受信データバッファキュー設定部１］１３と［送信データバッファキュー設定部１］１５を利用してｖｉｒｔｉｏ−ｎｅｔ−ｉｐｃデバイスの［送信用・受信用共有バッファキュー管理部１］へ共有バッファキューの個数・サイズ情報を通知する前に完了済みである。
（ｂ）以後、初期状態以降は、手順９で回収したディスクリプタをａｖａｉｌに積むことを示す。
２．仮想マシンへ通知
（ａ）初期状態では発生しない。
（ｂ）初期状態以降は、ゲストＯＳは［受信データ更新通知部１］１２を通じて、［共有バッファキュー拡張用プロトコル処理部１］４４に、更新があった旨を通知する。
３．外部プロセスへ通知
［共有バッファキュー拡張用プロトコル処理部１］４４は、外部プロセスのｖｉｒｔｑｕｅｕｅデバイスへ受信用キューのａｖａｉｌの更新通知メッセージを送信。
４．ａｖａｉｌから利用可能な、ディスクリプタを回収
（ａ）外部プロセスの処理ロジックから［送信インタフェース］の［送信データ入力部２］５５に送信データを送る。
（ｂ）［送信用共有バッファキュー処理部２］６３は［送信用・受信用共有バッファキュー管理部２］６２から、外部プロセスが送信用で利用するキュー情報（仮想マシンから見ると受信キュー）を参照し、ディスクリプタを用意する。
５．ディスクリプタに転送データを積む
［送信用共有バッファキュー処理部２］６３は転送データをディスクリプタにつめる。
６．ｕｓｅｄに回収したディスクリプタを積む
［送信用共有バッファキュー処理部２］６３は［共有バッファキュー拡張用プロトコル処理部２］８４にｕｓｅｄに回収したディスクリプタを積んだことを知らせる。
７．ｕｓｅｄのアップデートを通知
［共有バッファキュー拡張用プロトコル処理部２］８４は更新メッセージを仮想マシン側のｖｉｒｔｉｏ−ｎｅｔ−ｉｐｃデバイスに送信。
８．ゲストＯＳへｕｓｅｄのアップデートを通知。
ｖｉｒｔｉｏ−ｎｅｔ−ｉｐｃデバイスの［共有バッファキュー拡張用プロトコル処理部１］４４が更新メッセージを受信し、［受信データ更新通知部１］１２にｕｓｅｄのアップデートを通知。
９．ｕｓｅｄから外部プロセスが積んだディスクリプタを回収
（ａ）ゲストＯＳは［受信データ更新通知部１］１２により、更新通知を受信し、ｕｓｅｄから外部プロセスが積んだディスクリプタを取り出す。
（ｂ）ディスクリプタには転送データが含まれるので、そのデータを取得するとともに、ディスクリプタを解放する（回収する）。

＜ポーリングモード（割り込みなし）の場合の処理＞
ゲストＯＳと外部プロセスはそれぞれ、ポーリングモードで動作するため、ｖｉｒｔｉｏ−ｎｅｔ−ｉｐｃデバイスおよびｖｉｒｔｑｕｅｕｅデバイスを介した、更新メッセージは中継されない。

（ゲストＯＳから仮想マシンを通して、外部プロセスへ送信する場合）
図１６と図２２を利用し説明する。

１．ａｖａｉｌにディスクリプタを積む
ゲストＯＳはａｖａｉｌに送信データをディスクリプタに入れて積む
２．ａｖａｉｌを確認し、ディスクリプタを回収
［受信用共有バッファキュー処理部２］６１はポーリングモードで、ａｖａｉｌの更新を確認する。更新があった場合、ディスクリプタを回収し、［受信データ出力部２］５２を通して、転送データを取得できるように、保持しておく。
３．ｕｓｅｄに回収したディスクリプタを積む
［受信用共有バッファキュー処理部２］６１は［共有バッファキュー拡張用プロトコル処理部２］８４にｕｓｅｄに回収したディスクリプタを積む。
４．ｕｓｅｄから外部プロセスが積んだディスクリプタを回収
ゲストＯＳはポーリングモードで、ｕｓｅｄの状態を確認し、ｕｓｅｄの更新があった場合、外部プロセスが積んだディスクリプタを回収する。

（外部プロセスから、ゲストＯＳへ送信する場合）
図１６と図２２を利用して説明する。
１．ａｖａｉｌにディスクリプタを積む
（ａ）初期状態では外部プロセスが送信データを詰め込むための、ディスクリプタを仮想マシン側が用意しておく。つまり、ゲストＯＳが［受信データバッファキュー設定部１］１３と［送信データバッファキュー設定部１］１５を利用してｖｉｒｔｉｏ−ｎｅｔ−ｉｐｃデバイスの［送信用・受信用共有バッファキュー管理部１］へ共有バッファキューの個数・サイズ情報を通知する前に完了済みである。
（ｂ）以後、初期状態以降は、手順５で回収したディスクリプタをａｖａｉｌに積むことを示す。
２．ａｖａｉｌから利用可能な、ディスクリプタを回収
（ａ）外部プロセスの処理ロジックから［送信インタフェース］の［送信データ入力部２］５５に送信データを送る。
（ｂ）［送信用共有バッファキュー処理部２］６３は［送信用・受信用共有バッファキュー管理部２］６２から、外部プロセスが送信用で利用するキュー情報（仮想マシンから見ると受信キュー）を参照し、ディスクリプタを用意する。
３．ディスクリプタに転送データを積む
［送信用共有バッファキュー管理部２］は転送データをディスクリプタにつめる。
４．ｕｓｅｄに回収したディスクリプタを積む
［送信用共有バッファキュー処理部２］６３は回収したディスクリプタをｕｓｅｄに積む。
５．ｕｓｅｄから外部プロセスが積んだディスクリプタを回収
（ａ）ゲストＯＳはポーリングモードで動作し、更新通知なしでｕｓｅｄを確認し、更新があった場合、外部プロセスが積んだディスクリプタを取り出す。
（ｂ）ディスクリプタには転送データが含まれるので、そのデータを取得するとともに、ディスクリプタを解放する（回収する）。

（９）仮想マシンとゲストＯＳの起動シーケンス
図１５に記載の通りであり、仮想マシンが起動し、ゲストＯＳが起動してｖｉｒｔｉｏ−ｎｅｔドライバが起動するときに、フィーチャ情報についてｖｉｒｔｉｏ−ｎｅｔ−ｉｐｃデバイスと折衝を行い、さらに動作モードをお互い設定した上で送信用、受信用の共有バッファキューをゲストＯＳが作成し、共有バッファキューの個数・サイズ・先頭アドレス情報をｖｉｒｔｉｏ−ｎｅｔ−ｉｐｃデバイスに通知する。

この通知は、上記（２）に記載のとおり、ゲストＯＳがｖｉｒｔｉｏ−ｎｅｔ−ｉｐｃデバイスとのインタフェースである、［受信データバッファキュー設定部１］１３、［デバイス動作・フィーチャ設定部１］１４、［送信データバッファキュー設定部１］１５を通して、［送信用・受信用共有バッファキュー管理部１］に通知し設定することで実現する。

以上のように、通常のオペレーションを想定した場合の動作およびシーケンスについて説明した。しかし、図２３に示すように、外部プロセス、仮想マシン、及びゲストＯＳが状態遷移パターン（Ｄ１〜Ｄ９）において、お互い独立して動作に不具合を発生させない通知のしくみが必要である。次節以降、その方式について説明する。

・状態遷移パターン（Ｄ１）
状態遷移パターン（Ｄ１）では、仮想マシンだけが起動、停止する状態遷移について取り扱う。このパターンでは、仮想マシンの異常終了を考慮しなければ行けないがそもそも接続先の外部プロセスやゲストＯＳが存在しないため、影響を与える存在がいない。よって、このケースでは動作への影響は考慮する必要はない。

・状態遷移パターン（Ｄ２）
このケースでは、仮想マシンが起動中でゲストＯＳが停止中と、仮想マシンが起動中でゲストＯＳが起動中の場合の２つの状態の遷移である。この状態で、ゲストＯＳが異常終了した場合の対処が必要である。具体的には、ゲストＯＳが確保した共有バッファキューのメモリ領域が確保されたまま解放されずに異常終了するケースである。この場合は、そのメモリ領域が解放されずに残ってしまうが、この問題については、既存のｖｉｒｔｉｏ−ｎｅｔデバイス含めｖｉｒｔｉｏの共有バッファキューで実現されたｖｉｒｔｉｏデバイスすべてに共通する問題である。また、外部プロセスが起動していないため、動作に影響を与えるという観点では考慮する必要はない。

・状態遷移パターン（Ｄ３）
このパターンでは、仮想マシンとゲストＯＳが起動中で、外部プロセスが停止と動作の状態を遷移するケースである。このケースでは、外部プロセスが異常終了したケースを取り扱う。この場合、ＩＰＣを利用しているため、ＩＰＣの終了通知を仮想マシン側は検知することができ、終了処理を仮想マシン側で実施することができる。つまり、（ｉ）仮想マシン側で終了を検知、（ｉｉ）仮想マシン側からゲストＯＳへリンクダウンを通知、（ｉｉｉ）ゲストＯＳがリンクダウンを認識、することにより外部プロセスの影響でゲストＯＳは通常のリンクダウン処理として扱うことができる。その他の問題として、外部プロセス異常終了時に共有バッファキューが初期化されない問題が残るが、これはＶｉｔｉｏデバイスすべてで共通する問題である。

・状態遷移パターン（Ｄ４）
このパターンでは、仮想マシンとゲストＯＳが停止中であり、外部プロセスの異常終了のみを対処がターゲットとなる。この状態では外部プロセス側の異常終了は相手側が存在しないため、影響は与えない。

・状態遷移パターン（Ｄ５）
このパターンでは、外部プロセスが起動し、ｖｉｒｔｑｕｅｕｅデバイスがサーバとして接続待ち状態になっている状態で、仮想マシンが起動および停止する状態遷移について、仮想マシンが異常終了した場合について説明する。仮想マシンが異常終了した場合は、外部プロセスのｖｉｒｔｑｕｅｕｅデバイスと仮想マシン側のｖｉｒｔｉｏ−ｎｅｔ−ｉｐｃデバイスとのコネクションが切断されるだけであり、共有バッファキューの情報を交換する前であるため、異常終了後、外部プロセスのｖｉｒｔｑｕｅｕｅデバイスが再度待ち状態に入るため、特に外部プロセスの動作に仮想マシンの異常終了動作が影響を与えることはない。

・状態遷移パターン（Ｄ６）
このパターンでは、外部プロセスと仮想マシンが起動している状態で、ゲストＯＳの起動と終了の状態遷移中に、ゲストＯＳが異常終了した場合について説明する。ゲストＯＳが異常終了前に仮想マシン側のｖｉｒｔｉｏ−ｎｅｔ−ｉｐｃデバイスにゲストＯＳが確保した共有バッファキューの情報を提供していた場合、共有バッファキューで利用するメモリ領域も解放されない状態でゲストＯＳが異常終了してしまうため、外部プロセス側はその異常終了がわからない状態で共有バッファキューに書き込んでしまう。この問題については、既存のｖｉｒｔｉｏ−ｎｅｔデバイス含めｖｉｒｔｉｏの共有バッファキューで実現されたｖｉｒｔｉｏデバイスすべてに共通する問題である。

・状態遷移パターン（Ｄ７）
このパターンでは、仮想マシンだけが起動している状態（ｖｉｒｔｉｏ−ｎｅｔ−ｉｐｃデバイスが定期的に接続を繰り返している状態）、において外部プロセスが停止状態と起動状態間を遷移するケースについて取り扱う。このケースでは、外部プロセス側と仮想マシン側ではＩＰＣでの接続が完了しただけであり、共有バッファキューの情報については交換していない状態であるため、外部プロセスの異常終了に対しても、仮想マシン側は再度、再接続状態に遷移するだけであり、仮想マシンの状態に影響を与えるものではない。

・状態遷移パターン（Ｄ８）
このパターンでは、仮想マシンとゲストＯＳが起動している状態で、両方異常終了するケースを取り扱う。この状態では、影響を与える対象の外部プロセスは起動していないため、当然動作に対して影響を与えない。よって、この状態遷移では動作の影響を考慮する必要はない。

・状態遷移パターン（Ｄ９）
このパターンでは、仮想マシンとゲストＯＳと外部プロセスがすべて起動している状態で、仮想マシンとゲストＯＳが同時に異常終了するケースを取り扱う。この場合、仮想マシンのｖｉｒｔｉｏ−ｎｅｔ−ｉｐｃデバイスと外部プロセスのｖｉｒｔｑｕｅｕｅデバイスはＩＰＣで接続しているため、外部プロセス側は異常終了を検知でき、検知するとともに、共有バッファキュー操作を停止することができるため、外部プロセス側へはリンクダウン通知として外部プロセスへも正常に状態変更通知が可能である。これにより、この異常終了においても適切に処理することが可能である。

・その他の状態遷移
仮想マシンとゲストＯＳと外部プロセスがすべて動作している状態ですべて異常終了してしまうケースでは、すべて動作が終了するため、お互い影響を与えるケースは発生しない。よって、その他の状態遷移についても考慮する必要はない。

＜実施例２＞
実施例１では、ユニックスドメインソケットを利用したＩＰＣを利用した接続を取り上げた。ＩＰＣにおいてはユニックスドメインソケット以外に、ファイルパス指定によるＩＰＣの手法としてパイプ、メッセージキュー、ＩＮＥＴソケットが存在し、本発明では、起動オプションに接続種別を設定することで接続手法について切り替えることが可能である。

以上のように、接続手段はこれらの各実装方法で異なるが、上記指定の接続手段を用いて接続を確立した後、初期化メッセージを含む仮想マシンと外部プロセス間でやり取りされる共有バッファキューに関するすべての手順は、制御メッセージフォーマット及びシーケンス（図１８）を含み、実施例１に説明の手順と全く同じである。

ただし、起動時に与えるオプションについては、それぞれの接続手段によって異なるため、実施例２において実施例１と異なる箇所のみ以下の通り、記載する（それ以外の手段に関する実施手順は実施例１と同じであるため、省略する。）

＜接続手段：パイプ＞
パイプを接続手段とする場合、仮想マシン側の起動オプションは下記の通り、ｓｏｃｋｅｔｐａｔｈではなくｆｉｆｏｐａｔｈとして、ファイル記述子を指定して起動する。
（参８）［仮想マシンの起動時引数］

外部プロセス側も同様のファイル記述子を指定することで接続できるようにする。
（参９）［外部プロセスの起動オプション］

それ以外のオプションについては実施例１と同じである。

＜接続手段：メッセージキュー＞
メッセージキューを接続手段とする場合、仮想マシン側の起動オプションは下記の通り、ｓｏｃｋｅｔｐａｔｈではなくｍｓｇｑｐａｔｈとして、ファイル記述子を指定して起動する。
（参１０）［仮想マシンの起動時引数］

外部プロセス側も同様のファイル記述子を指定することで接続できるようにする。
（参１１）［外部プロセスの起動オプション］

それ以外のオプションについては実施例１と同じである。

＜接続手段：ＩＮＥＴソケット＞
ＩＮＥＴソケットを接続手段とする場合、仮想マシン側の起動オプションは下記の通り、ｓｏｃｋｅｔｐａｔｈではなくＩＰアドレスとポート番号を指定して起動する。このとき、レイヤ４プロトコルとしてＴＣＰか、ＵＤＰを指定する。
（参１２）［仮想マシンの起動時引数］

外部プロセス側も同様のファイル記述子を指定することで接続できるようにする。
（参１３）［外部プロセスの起動オプション］

それ以外のオプションについては実施例１と同じである。

＜実施例３＞
実施例１では、同一物理ホスト内においてゲストＯＳの共有バッファキューを仮想マシンから外部プロセスへ拡張する手法について説明した。ＩＰＣにおいて、ソケットの代わりに、セキュアな接続方式を組み合わせ、１対１で接続するケースを適用することが可能である。ベーシック認証、パスワード認証、ＳＳＬ（Ｓｅｃｕｒｅ Ｓｏｃｋｅｔｓ Ｌａｙｅｒ）、を利用した接続方式を適用できる。これにより、仮想マシンと外部プロセス間での認証機能を共通鍵、または公開鍵認証にて実現し、交換するメッセージ内容も暗号化することが可能であり、セキュアに共有バッファキューの操作が可能となる。

（ベーシック認証を利用したケース）
ベーシック認証を利用するケースでは、実施例１において、仮想マシン起動時のオプションに、外部プロセス接続用の認証情報として、ノードＩＤの代わりにユーザ／パスワードを指定し起動する。これらのユーザ／パスワードは、図１６の［基本設定管理部１］４５にて管理される。一方、外部プロセス側も認証許可するためのユーザ／パスワード情報を仮想マシン同様に、図１６の［基本設定管理部２］８５にて管理する。

この場合、これらのオプションは初期化メッセージ前に外部プロセスとやりとりされ、ベーシック認証が正常に終了すると、そのあと、初期化フェーズに移行する。仮想マシンと外部プロセス間の接続確立までの状態遷移については図２４に記載のとおりである。図２４において、Ｂａｓｉｃ認証フェーズの認証要求応答、ユーザ／パスワード、認証ＯＫの各種メッセージフォーマットは図１８に従い、メッセージタイプにｂａｓｉｃ認証、メッセージタイプ依存データにそれぞれ、認証要求応答、ユーザ／パスワード、認証ＯＫの情報が記載され、メッセージがやり取りされる。それ以外の全体の状態遷移等は、実施例１にすべて従うため、省略する。

（ダイジェスト認証）
ダイジェスト認証を利用するケースでは、ベーシック認証の「ユーザ／パスワード」部分をダイジェストに置き換えた形となる（図２５）。各種メッセージフォーマットもベーシック認証と同様に図１８に従う。また、それ以外の全体の状態遷移等は、実施例１にすべて従うため、省略する。

（ＳＳＬ認証）
ＳＳＬ認証を利用するケースでは、クライアント側がサーバ認証用の証明書を所持し、仮想マシン起動時のオプションとして、サーバ証明書のファイルパスを指定する。これらのサーバ証明書のファイルパス情報は、図１６の［基本設定管理部１］４５にて管理される。外部プロセス側は、起動時にＳＳＬの認証を実施するかどうかのオプションを指定する。

これにより、サーバとクライアント間でＳＳＬ認証を実行することにより、接続を実現する（図２６）。初期化フェーズに至るＳＳＬによる接続までは、メッセージフォーマットはＳＳＬに従う。また、それ以外の全体の状態遷移等は、実施例１にすべて従うため、省略する。

＜実施例４＞
実施例１においては、（３）に記載のとおり、バージョン番号を利用してバッファキュー構成（種別・個数・サイズ）の情報対応を示した。これにより、バージョン番号を利用することで送信用、受信用のバッファキューとして、それぞれマルチバッファキューを仮想マシンと外部プロセスで共有することが可能である。

この場合、更新メッセージはのメッセージタイプ依存フィールドには、下記のとおり、更新のあったバッファキューのビットを１、更新がないキューを０、とすることにより、接続相手に知らせることが可能である。

例えば、送信用、受信用にそれぞれ４個のバッファキューを利用する場合、メッセージタイプフィールドは送信用４ビット、受信用４ビットの合計８ビットで構成される。例えば送信用の０番目、１番目のキューが更新された場合は、メッセージタイプ依存フィールドは以下のとおりとなる。
１１００００００ ＝ （送信用４ビット）（受信用４ビット）
これらの更新メッセージをのぞき、実施例１と同じ構成をとるため、実施例４の詳細な手順は省略する。

＜実施例５＞
実施例４では、マルチバッファキューにおいて、１つの接続を利用した。送受信用のバッファキューを１つの接続と対応づけ、マルチキューの個数分接続を確立することにより、並列化が望まれパフォーマンス向上が期待できる。具体的には、仮想マシン、外部プロセスともに起動時に個数分のファイル記述子を指定して起動することにより、マルチバッファキュー、且つマルチ接続の機能を持つバッファキューの共有方式を実現することができる。

具体的な実施例については接続が複数と成るだけであり、実施例１と全く同じであるため、詳細は省略する。

＜実施例６＞
実施例１では、ゲストＯＳと仮想マシン間のキューとしてｖｉｒｔｉｏキューの仕様をベースに外部プロセスへ確証する方式について述べた。キュー操作は一般的に、親側と子側で構造（バッファキューの構成とオペレーション方法）で合意できていれば、他のキュー構造においても本発明は適用可能である。実施例１では、仮想マシンと外部プロセス間を接続する際、バージョン番号により、バッファキュー種別、バッファキュー個数、バッファキューサイズの情報を交換する（実施例１の（３））。

よって、キューの更新通知機能と動作モードを交換するだけであり、実施例１の例に加え、設定メッセージにキューの種別情報を追加することにより、任意のキューに拡張可能である。

状態遷移パターンＤ２、Ｄ６において、Ｖｉｒｔｉｏキューを前提することでＶｉｒｔｉｏキューに起因するドライバ側の再初期化が実装されていないことにより、メモリ解放されないという問題を説明した。本実施例で説明した他のキューでリンクダウンや、リンクアップ時にＶｉｒｔｉｏキューを再初期化する機能を有する共有バッファキューに適用することで、当該問題も解決できる。

＜実施例７＞
今までの実施例では、仮想マシンの通信デバイス（ｖｉｒｔｉｏ−ｎｅｔ−ｉｐｃでバイス）をクライアント、外部プロセスの通信デバイス（ｖｉｒｔｑｕｅｕｅデバイス）をサーバとして、実施例を述べていたが、逆の場合も同様に本発明は実現可能である。この場合、サーバ、クライアントの処理が今まで述べてきた実施例と逆のパターンになるがそれ以外の状態遷移については実施例１で述べたものと全く同じになるため、詳細は省略する。

＜本発明によって生じる効果＞
（ｉ）外部プロセス側と仮想マシン側を直接接続することができるため、メモリコピー回数とコンテキストスイッチ切り替え回数を外部通信方式１、２に対し少なくすることができ、高速にデータ転送を実現することができる。

（ｉｉ）仮想マシン、外部プロセスそれぞれの通信デバイスが、お互い接続相手の状態に関し、状態変化を検知し、自身内部へ通知することにより、ゲストＯＳや外部プロセス内部の処理ロジックに対し、障害発生やメンテナンスなどの事象に対処する機会を創出する（障害対応等は、ゲストＯＳや外部プロセス内部の処理に依存）。これにより、仮想マシン（およびゲストＯＳ）と外部プロセスは異常終了の事象も含め、独立してオペレーションすることができる。つまり、仮想マシンの再起動や、外部プロセス側の再起動においても接続相手にはリンクダウンとして見えるため、動作がハングアップするといったことが一切発生しない。

（ｉｉｉ）仮想マシン、外部プロセスは切断状態に陥ったときに、正しく状態を把握できることにより、それを契機として、接続相手を切り替える動作に移ることができ、さらに再接続機能により、切り離した接続相手と同じ機能を持つ別の接続相手と再接続することによりフェイルオーバー機能を実現することが可能となる。

（ｉｖ）本発明では仮想マシンと外部プロセス間のメッセージの交換内容を提案しており、接続方法を限定しない。これにより、適用するプラットフォームによって実装方法を選択、採用することが可能である。

（ｖ）本発明のｖｉｒｔｉｏ−ｎｅｔ−ｉｐｃデバイスとｖｉｒｔｑｕｅｕｅデバイスを通信インタフェースとして利用することにより、外部プロセスと仮想マシンの接続のあり、なしをゲストＯＳ側にリンクダウンとして状態通知を実施することにより、ゲストＯＳ、外部プロセスはハングアップせずに通常のオペレーションを実施することを可能とする。

（ｖｉ）外部通信方式１、２では仮想マシンと外部プロセス間の通信はｔａｐデバイスやｖｈｏｓｔ−ｎｅｔドライバの他に中継のための仮想スイッチが必要と成るが、この方式では直接接続するため、他のコンポーネントを必要としない。

通常、ＣＰＵについてのサイクルタイムは、ＤＲＡＭのようなメモリへのアクセス時間よりはるかに短い。これは、ＣＰＵが次の命令（メモリエリアを参照する）を実行するための待ちが発生することを意味する。そして、メモリエリアへの参照回数が多いほど待ち時間が多く発生することになりスループットの低下が発生する。このため、従来のように仮想マシン間のパケット転送のために複数のメモリエリアにパケットをコピーをすれば、このコピー動作によりネットワークＩ／Ｏのパフォーマンスが低下することになる。

図２７は、この問題を解決しようとするモデルである。図２７のモデルは、仮想ネットワーク技術のＮＦＶとＳＤＮ（ＯｐｅｎＦｌｏｗ）を利用した仮想ＢＲＡＳ（Ｂｒｏａｄｂａｎｄ Ｒｅｍｏｔｅ Ａｃｃｅｓｓ Ｓｅｒｖｅｒ）ネットワークノードである。ＮＦＶは、ネットワーク機能仮想化（Ｎｅｔｗｏｒｋ Ｆｕｎｃｔｉｏｎ Ｖｉｒｔｕａｌｉｚａｔｉｏｎ）であり、ＳＤＮはソフトウエア制御ネットワーク（Ｓｏｆｔｗａｒｅ−Ｄｅｆｉｎｅｄ Ｎｅｔｗｏｒｋｉｎｇ）である。

各仮想マシン（ＶＭ）は、ＮＦＶとして機能し、それぞれインターネット接続サービス、ＩＰ電話等のＳＩＰサービス、ＮＳＯＤ（Ｎｅｔｗｏｒｋ Ｓｅｒｖｉｃｅ−Ｏｒｉｅｎｔｅｄ Ｄｉｓｔｒｉｂｕｔｏｒ）として機能する例である。ＮＳＯＤは、ＤＰＩ（Ｄｅｅｐ Ｐａｃｋｅｔ Ｉｎｓｐｅｃｔｉｏｎ）やアドレス付与を行い、サービスクライアントとネットワークサービスとの媒介をおこなうものである。仮想ネットワークにおいてパケット転送を行うＯｐｅｎ ｖｓｗｉｃｈやソフトウエアベースＯｐｅｎＦｌｏｗスイッチ等の仮想スイッチが必要である。図２７のモデルは、仮想スイッチと仮想マシンが同じメモリエリアで動作するため、ホストＯＳをバイパスしてパケットのコピー動作を低減でき、ネットワークＩ／Ｏのパフォーマンスを向上することができる。

さらに、このＢＲＡＳに本発明の仮想通信路構築システムを適用すれこともできる。仮想デバイスとゲストＯＳ間の共有バッファキューを介してそれぞれの仮想マシン間を直接接続し、パケット転送が可能になるため、仮想スイッチが不要となる。このため、パケットコピー回数をさらに低減でき、高速データ転送に寄与できる。

［付記］
以下は、本発明の特徴をまとめたものである（図１５、図１９、図２０、図２３）。

１．本発明は、仮想マシンおよび外部プロセスにおいて、互いの独立性を担保しつつ、バッファキューの操作を共有するために、初期化（接続相手の識別、バッファキューの大きさ、種類の整合性の確立）、設定処理（バッファキュー操作の動作モード、バッファキューの先頭アドレス）、バッファキューの更新通知処理（割り込み有りの場合）、終了処理、の４フェーズに分けて接続状態をモデル化し、以下の通りプロトコルを規定したことを特徴とする。
（ａ）接続相手間でそれぞれ同じバッファを操作するため、お互いバッファの種別、大きさの整合性が必要になる。初期化メッセージでは、この整合性を実現するために、接続の度に整合性情報をバージョン情報として交換するための情報領域をプロトコルメッセージ内に規定した。
（ｂ）同様に、設定処理フェーズでは、バッファキューのメモリ情報を相手に伝えるための情報領域をプロトコルメッセージ内に規定した。
（ｃ）データの入出力を取り扱う方式として、割り込みモードと割り込みなしモード（ポーリングモード）が存在する。これを接続完了前に事前に折衝するための同様に、設定処理フェーズでは、動作モード規定領域をプロトコルメッセージ内に規定した。
（ｄ）割り込みモードを実現するために、バッファキューの更新のたびに、相手側に更新通知を通知するメッセージ種別をプロトコルに規定した。

２．本発明は、更新通知なしで、通信デバイスがポーリングモードでデータ転送を実現するために、設定フェーズ時に動作モードとして、割り込み無しモード（ポーリングモード）をサポートしたことを特徴とする。

３．本発明は、仮想マシン、外部プロセスそれぞれにおいて、切断状態を検知した場合、自身の内部へリンクダウン通知することにより、動作の不定状態を防止可能にすることを特徴とする。

４．本発明は、切断状態になった場合、再接続のフェーズにステート遷移することにより、再接続可能にしたことを特徴とする。

５．本発明は、仮想マシン・ゲストＯＳおよび、外部プロセスと、停止・起動の２つのステート状態とを組み合わせ、各状態遷移においても、再接続可能な状態に遷移することを実現する共有バッファキュー拡張用プロトコルのシグナリングを規定したことを特徴とする。

１０：通信デバイスインタフェース
２０：送信用・受信用共有バッファキュー管理部１
３０：基本設定処理部１
４０：通信部（クライアント）
５０：インタフェース部
６０：共有バッファキュー操作部
７０：基本設定処理部２
８０：通信部（サーバ）
１００：通信デバイス１
２００：通信デバイス２

Claims (3)

1. 仮想マシン及び前記仮想マシン外に形成された外部プロセスが動作可能なホストＯＳを有する物理マシンと、
   前記仮想マシン内で動作するゲストＯＳに、前記仮想マシンと前記外部プロセスとを直接接続する仮想通信路を構築させる通信路構築手段と、
   を備える仮想通信路構築システムであって、
   前記通信路構築手段は、
   前記仮想マシンと前記ゲストＯＳとの間のデータ転送用として形成された共有バッファキューについて、前記仮想マシンが前記ゲストＯＳから取得した共有バッファキュー情報を前記外部プロセスへ提供することで前記共有バッファキューのデータ転送先を前記外部プロセスへ拡張して前記仮想通信路を構築するとともに、前記ゲストＯＳと前記外部プロセスとの間の通信に関する手続きを実現させる共有バッファキュー拡張用プロトコル機能と、
   前記仮想通信路において、前記仮想マシンと前記外部プロセスとの通信が確立している又は切断しているという接続状態を検知する接続状態検知機能と、
   前記接続状態をそれぞれ前記ゲストＯＳと前記外部プロセス上の処理ロジックに通知する接続状態通知機能と、
   前記仮想マシンと前記外部プロセスとの通信が切断しているときに定期的に通信先と再接続する再接続機能と、
   を有することを特徴とする仮想通信路構築システム。
2. 仮想マシン及び前記仮想マシン外に形成される外部プロセスが動作可能なホストＯＳを有する物理マシン上に、前記仮想マシン及び前記外部プロセスを形成する仮想マシン形成手順と、
   前記仮想マシン内で動作するゲストＯＳに、前記仮想マシンと前記外部プロセスとを直接接続する仮想通信路を構築させる仮想通信路構築手順とを行う仮想通信路構築方法であって、
   前記仮想通信路構築手順は、
   前記仮想マシンと前記ゲストＯＳとの間のデータ転送用として形成された共有バッファキューについて、前記仮想マシンが前記ゲストＯＳから取得した共有バッファキュー情報を前記外部プロセスへ提供することで前記共有バッファキューのデータ転送先を前記外部プロセスへ拡張して前記仮想通信路を構築するとともに、前記ゲストＯＳと前記外部プロセスとの間の通信に関する手続きを実現させる共有バッファキュー拡張ステップと、
   前記仮想通信路において、前記仮想マシンと前記外部プロセスとの通信が確立している又は切断しているという接続状態を検知する接続状態検知ステップと、
   前記接続状態をそれぞれ前記ゲストＯＳと前記外部プロセス上の処理ロジックに通知する接続状態通知ステップと、
   前記仮想マシンと前記外部プロセスとの通信が切断しているときに定期的に通信先と再接続する再接続ステップと、
   を有することを特徴とする仮想通信路構築方法。
3. 仮想マシン及び前記仮想マシン外に形成される外部プロセスが動作可能なホストＯＳを有する物理マシンに、請求項２に記載の仮想通信路構築方法を実現させるための仮想通信路構築プログラム。

Images