(57)【要約】      （修正有）【課題】ＳＲ−ＩＯＶ仕様に従ったＩ／Ｏデバイスをハイパバイザと第一のゲストＯＳと第二のゲストＯＳで共有し、ハイパバイザに障害が発生した後の第一のゲストＯＳのＩ／Ｏを継続する。【解決手段】ハイパバイザと第１のゲストＯＳがＩ／Ｏデバイスを共有する方法であって、Ｉ／Ｏデバイスは、物理機能と仮想機能を有し、ハイパバイザは、物理機能を利用する物理ドライバを有し、第１のゲストＯＳは、仮想機能を利用する仮想ドライバを有し、前記ハイパバイザが、物理ドライバを介してＩ／Ｏデバイスの状態を取得し、第１のゲストＯＳが、ハイパバイザを監視して所定の状態になったときには、Ｉ／Ｏデバイスを操作するサブ物理ドライバを起動し、前記第１のゲストＯＳは、メモリ上に予め設定したキューを介して送受信を行う。【選択図】図２
2014106587.tif 000002
【特許請求の範囲】
【請求項１】
プロセッサとメモリ及びＩ／Ｏデバイスを備えた計算機で、ハイパバイザと第１のゲストＯＳが前記Ｉ／Ｏデバイスを共有するＩ／Ｏデバイスの制御方法であって、
前記Ｉ／Ｏデバイスは、物理機能と仮想機能を有し、前記ハイパバイザは、前記物理機能を利用する物理ドライバを有し、前記第１のゲストＯＳは、前記仮想機能を利用する仮想ドライバを有し、
前記方法は、
前記ハイパバイザが、前記物理ドライバを介して前記Ｉ／Ｏデバイスの状態を取得する第１のステップと、
前記第１のゲストＯＳが、前記ハイパバイザを監視して、前記ハイパバイザが所定の状態になったか否かを判定する第２のステップと、
前記第１のゲストＯＳが、前記ハイパバイザが所定の状態になったと判定したときには、前記Ｉ／Ｏデバイスを操作するサブ物理ドライバを起動する第３のステップと、
前記第１のゲストＯＳは、前記メモリ上に予め設定したキューを介して送受信を行う第４のステップと、
を含むことを特徴とするＩ／Ｏデバイスの制御方法。
【請求項２】
請求項１に記載のＩ／Ｏデバイスの制御方法であって、
前記第２のステップは、
前記第１のゲストＯＳが、前記ハイパバイザを監視して、前記ハイパバイザが所定の状態として異常が発生したか否かを判定し、
前記第３のステップは、
前記第１のゲストＯＳが、前記ハイパバイザに異常が発生したと判定したときには、前記Ｉ／Ｏデバイスを操作するサブ物理ドライバを起動することを特徴とするＩ／Ｏデバイスの制御方法。
【請求項３】
請求項１に記載のＩ／Ｏデバイスの制御方法であって、
前記第３のステップは、
前記第１のゲストＯＳが、前記仮想ドライバから前記サブ物理ドライバを介して前記Ｉ／Ｏデバイスの状態を取得するステップを含み、
前記仮想ドライバから前記サブ物理ドライバを介して前記Ｉ／Ｏデバイスから取得する状態として、前記物理機能及び仮装機能毎のリンク状態と帯域状態とを含むことを特徴とするＩ／Ｏデバイスの制御方法。
【請求項４】
請求項３に記載のＩ／Ｏデバイスの制御方法であって、
前記第３のステップは、
前記第１のゲストＯＳが、前記物理機能及び仮装機能毎のリンク状態と帯域状態とを取得した後に、前記サブ物理ドライバを起動することを特徴とするＩ／Ｏデバイスの制御方法。
【請求項５】
請求項１に記載のＩ／Ｏデバイスの制御方法であって、
前記第１のステップは、
前記ハイパバイザが、前記物理ドライバを介して前記Ｉ／Ｏデバイスの状態を取得し、前記取得した状態を、前記第１のゲストＯＳに通知するステップと、
前記第１のゲストＯＳは、前記ハイパバイザから受信した前記状態で前記サブ物理ドライバが利用する状態を更新するステップと、を含み、
前記第３のステップは、
前記第１のゲストＯＳは、前記更新された前記状態で前記サブ物理ドライバを起動することを特徴とするＩ／Ｏデバイスの制御方法。
【請求項６】
請求項２に記載のＩ／Ｏデバイスの制御方法であって、
前記Ｉ／Ｏデバイスは、前記ハイパバイザと前記第１のゲストＯＳに加えて第２のゲストＯＳで共有され、さらに、前記第１のゲストＯＳと第２のゲストＯＳが通信する緊急リンクを有し、
前記第２のステップは、
前記第１のゲストＯＳが、前記ハイパバイザを監視して、前記ハイパバイザが所定の状態として異常が発生したか否かを判定し、
前記第１のゲストＯＳが、前記ハイパバイザに異常が発生したと判定したときには、前記第２のゲストＯＳにＩ／Ｏデバイスの利用の停止を前記緊急リンクを介して通知することを特徴とするＩ／Ｏデバイスの制御方法。
【請求項７】
請求項６に記載のＩ／Ｏデバイスの制御方法であって、
前記第１のゲストＯＳが、前記ハイパバイザに異常が発生したと判定したときには、前記第２のゲストＯＳのＩ／Ｏトランザクションが完了した後に、前記第２のゲストＯＳに前記Ｉ／Ｏデバイスの利用の停止を前記緊急リンクを介して通知することを特徴とするＩ／Ｏデバイスの制御方法。
【請求項８】
プロセッサとメモリ及びＩ／Ｏデバイスを備えた計算機で、ハイパバイザと第１のゲストＯＳが前記Ｉ／Ｏデバイスを共有する仮想計算機システムであって、
前記Ｉ／Ｏデバイスは、物理機能と仮想機能を有し、
前記ハイパバイザは、
前記物理機能を利用する物理ドライバを有し、当該物理ドライバを介して前記Ｉ／Ｏデバイスの状態を取得し、
前記第１のゲストＯＳは、
前記仮想機能を利用する仮想ドライバと、
前記ハイパバイザを監視して、前記ハイパバイザが所定の状態になったか否かを判定する監視部と、
前記ハイパバイザが所定の状態になったと判定したときには、前記Ｉ／Ｏデバイスを操作するサブ物理ドライバを起動するフェイルオーバ部と、
前記メモリ上に予め設定されて送受信を行うキューと、
を備えたことを特徴とする仮想計算機システム。
【請求項９】
請求項８に記載の仮想計算機システムであって、
前記監視部は、
前記所定の状態としてハイパバイザに異常が発生したか否かを判定し、
前記フェイルオーバ部は、
前記ハイパバイザに異常が発生したと判定したときには、前記Ｉ／Ｏデバイスを操作するサブ物理ドライバを起動することを特徴とする仮想計算機システム。
【請求項１０】
請求項８に記載の仮想計算機システムであって、
前記フェイルオーバ部は、
前記仮想ドライバから前記サブ物理ドライバを介して取得する前記Ｉ／Ｏデバイスの状態として、前記物理機能及び仮装機能毎のリンク状態と帯域状態とを含むことを特徴とする仮想計算機システム。
【請求項１１】
請求項１０に記載の仮想計算機システムであって、
前記フェイルオーバ部は、
前記物理機能及び仮装機能毎のリンク状態と帯域状態とを取得した後に、前記サブ物理ドライバを起動することを特徴とする仮想計算機システム。
【請求項１２】
請求項８に記載の仮想計算機システムであって、
前記ハイパバイザは、
前記物理ドライバを介して前記Ｉ／Ｏデバイスの状態を取得し、前記取得した状態を、前記第１のゲストＯＳに通知し、
前記第１のゲストＯＳは、
前記ハイパバイザから受信した状態で前記サブ物理ドライバが利用する状態を物理リンク状態として更新し、
前記フェイルオーバ部は、
前記更新された前記物理リンク状態で前記サブ物理ドライバを起動することを特徴とする仮想計算機システム。
【請求項１３】
請求項９に記載の仮想計算機システムであって、
前記Ｉ／Ｏデバイスは、前記ハイパバイザと前記第１のゲストＯＳに加えて第２のゲストＯＳで共有され、さらに、前記第１のゲストＯＳと第２のゲストＯＳが通信する緊急リンクを有し、
前記監視部は、
前記ハイパバイザを監視して、前記ハイパバイザが所定の状態として異常が発生したか否かを判定し、
前記フェイルオーバ部は、
前記監視部で前記ハイパバイザに異常が発生したと判定したときには、前記第２のゲストＯＳにＩ／Ｏデバイスの利用の停止を前記緊急リンクを介して通知することを特徴とする仮想計算機システム。
【請求項１４】
請求項１３に記載の仮想計算機システムであって、
前記フェイルオーバ部が、
前記ハイパバイザに異常が発生したと判定したときには、前記第２のゲストＯＳのＩ／Ｏトランザクションが完了した後に、前記第２のゲストＯＳにＩ／Ｏデバイスの利用の停止を前記緊急リンクを介して通知することを特徴とする仮想計算機システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は共有Ｉ／Ｏデバイスのアクセス制御方式に関する。
【背景技術】
【０００２】
ハイパバイザ（Ｈｙｐｅｒｖｉｓｏｒ）上で第一のゲストＯＳと第二のゲストＯＳが稼働し、かつ、ハイパバイザに障害が発生した後でも第一のゲストＯＳの稼働の継続を可能にする方法として特許文献１に記載の方法が知られている。
【０００３】
上記方法では、（１）第一のゲストＯＳがハイパバイザ上で稼働する際に使用する物理アドレス（ゲスト絶対アドレス）と、ホスト絶対アドレスが同一になるよう、第一のゲストＯＳに当該物理アドレス領域を占有的に割り当て、（２）第一のゲストＯＳがハイパバイザ上で稼働する際に使用するＣＰＵ番号と同じＣＰＵ番号を持つ物理ＣＰＵを第一のゲストＯＳに占有的に割り当て、（３）第一のゲストＯＳがハイパバイザ上で稼働する際に使用する割り込みと同じ割り込み番号を持つ物理割り込みを第一のゲストＯＳに占有的に割り当てる。そして、ハイパバイザに障害が発生した際には、以降、第一のゲストＯＳはハイパバイザ上ではなく物理ハードウェア上で実行を継続する。ハイパバイザ上でも物理ハードウェア上でも、物理アドレス、ＣＰＵ番号、割り込み番号が同一であるため、ハイパバイザ障害発生後でも第一のゲストＯＳの稼働継続が可能になる。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開平５−１２０４５号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
しかし、上記従来例では、第一のゲストＯＳがＮＩＣをはじめとするＩ／Ｏデバイスに、ハイパバイザ内に実装されたエミュレータを介してアクセスする構成を想定しておらず、そのような構成を取った時に、ハイパバイザに障害が発生した後に第一のゲストＯＳの稼働継続（特にＩ／Ｏ継続）は保証できない。
【０００６】
ＳＲ−ＩＯＶ仕様に従ったＮＩＣをはじめとするＩ／Ｏデバイスをハイパバイザと第一のゲストＯＳと第二のゲストＯＳ間で共有する場合には、ハイパバイザ内のエミュレータがＩ／Ｏデバイスの一部の機能をエミュレートし、第一のゲストＯＳや第二のゲストＯＳがＩ／Ｏデバイスの一部の機能を利用する際には、上記エミュレータを介して当該Ｉ／Ｏデバイスにアクセスする構成をとる。
【０００７】
近年、仮想計算機の普及により、Ｉ／Ｏデバイスを複数の仮想計算機（ゲストＯＳ）で共有する技術が提案され、例えば、ＳＲ−ＩＯＶ（Single Root I/O Virtualization）等が知られている。
【０００８】
上記特許文献１の記載の方法では、上記ＳＲ−ＩＯＶの仕様に従ったＩ／Ｏデバイスをハイパバイザと第一のゲストＯＳと第二のゲストＯＳで共有した際に、ハイパバイザに障害が発生した後では、第一のゲストＯＳのＩ／Ｏの継続を実現できない、という課題があった。
【課題を解決するための手段】
【０００９】
本発明は、プロセッサとメモリ及びＩ／Ｏデバイスを備えた計算機で、ハイパバイザと第１のゲストＯＳが前記Ｉ／Ｏデバイスを共有するＩ／Ｏデバイスの制御方法であって、前記Ｉ／Ｏデバイスは、物理機能と仮想機能を有し、前記ハイパバイザは、前記物理機能を利用する物理ドライバを有し、前記第１のゲストＯＳは、前記仮想機能を利用する仮想ドライバを有し、前記方法は、前記ハイパバイザが、前記物理ドライバを介して前記Ｉ／Ｏデバイスの状態を取得する第１のステップと、前記第１のゲストＯＳが、前記ハイパバイザを監視して、前記ハイパバイザが所定の状態になったか否かを判定する第２のステップと、前記第１のゲストＯＳが、前記ハイパバイザが所定の状態になったと判定したときには、前記Ｉ／Ｏデバイスを操作するサブ物理ドライバを起動する第３のステップと、前記第１のゲストＯＳは、前記メモリ上に予め設定したキューを介して送受信を行う第４のステップと、を含む。
【発明の効果】
【００１０】
本発明により、物理機能（ＰＦ）と仮装機能（ＶＦ）を有するＳＲ−ＩＯＶの仕様に従ったＩ／Ｏをハイパバイザと第一のゲストＯＳと第二のゲストＯＳで共有した際に、ハイパバイザに障害が発生後でも第一のゲストＯＳによるＩ／Ｏを継続することが可能となる。
【図面の簡単な説明】
【００１１】
【図１】本発明の第１の実施例を示し、仮想計算機システムの一例を示すブロック図である。
【図２】本発明の第１の実施例を示し、Ｉ／Ｏデバイスの共有に関する仮想計算機システムの機能ブロック図である。
【図３】本発明の第１の実施例を示し、物理リンク状態のデータ構造の一例を示す図である。
【図４】本発明の第１の実施例を示し、仮想リンク状態のデータ構造の一例を示す図である。
【図５】本発明の第１の実施例を示し、送受信キューのデータ構造の一例を示す図である。
【図６】本発明の第１の実施例を示し、ハイパバイザ状態格納領域のデータ構造の一例を示す図である。
【図７】本発明の第１の実施例を示し、リンク操作部の定期的なポーリングの処理の一例を示すフローチャートである。
【図８】本発明の第１の実施例を示し、物理リンク操作要求を受信したときにリンク操作部で行われる処理の一例を示すフローチャートである。
【図９】本発明の第１の実施例を示し、送受信部の定期的なポーリングの処理の一例を示すフローチャートである。
【図１０】本発明の第１の実施例を示し、データを受信したときに送受信部で行われる処理の一例を示すフローチャートである。
【図１１】本発明の第１の実施例を示し、ＰＦドライバがリンク操作部からの割り込み通知を受信したときに行う処理の一例を示すフローチャートである。
【図１２】本発明の第１の実施例を示し、ＰＦドライバがＶＦドライバから仮想リンク操作要求を受信したときに行う処理の一例を示すフローチャートである。
【図１３】本発明の第１の実施例を示し、ＰＦドライバが定期的なポーリングで行う処理の一例を示すフローチャートである。
【図１４】本発明の第１の実施例を示し、ＶＦドライバがＰＦドライバから割り込み通知を受信したときに行う処理の一例を示すフローチャートである。
【図１５】本発明の第１の実施例を示し、データ送信処理開始を契機にしたＶＦドライバの処理の一例を示すフローチャートである。
【図１６】本発明の第１の実施例を示し、ＶＦドライバが定期的なポーリングで行う処理の一例を示すフローチャートである。
【図１７】本発明の第１の実施例を示し、監視部で行われる処理の一例を示すフローチャートである。
【図１８】本発明の第１の実施例を示し、フェイルオーバ部で行われる処理の一例を示すフローチャートである。
【図１９】本発明の第２の実施例を示し、ＰＦドライバがリンク操作部からの割り込み通知を受信したときに行う処理の一例を示すフローチャートである。
【図２０】本発明の第２の実施例を示し、ＰＦドライバがＶＦドライバから仮想リンク操作要求を受信したときに行う処理の一例を示すフローチャートである。
【図２１】本発明の第２の実施例を示し、フェイルオーバ部で行われる処理の一例を示すフローチャートである。
【発明を実施するための形態】
【００１２】
以下、本発明の一実施形態を添付図面に基づいて説明する。
【実施例１】
【００１３】
まず、本発明を適用する仮想計算機システムの構成を説明する。図１は、仮想計算機システムの構成の一例を示すブロック図である。物理計算機１０は、複数のＣＰＵ１０３−１〜１０３−ｎを有し、これらのＣＰＵ１０３−１〜１０３−ｎはインターコネクト９１を介してチップセット９０や主メモリ１０２に接続される。なお、図中ＣＰＵ１０３−１〜１０３−ｎの総称をＣＰＵ１０３とする。
【００１４】
チップセット１００には、ＰＣＩｅｘｐｒｅｓｓ等を介してＩ／Ｏデバイスや入出力装置を備えたコンソール２３０が接続される。Ｉ／Ｏデバイスとしては、ＬＡＮ（またはネットワーク）１８０に接続されるＮＩＣ（Network Interface Card）１０１や、ＳＡＮ（Storage  Area  Network）２０２を介してストレージ装置２０３や等に接続されるＨＢＡ(Host Bus Adapter)２５１などで構成される。
【００１５】
ＣＰＵ１０３はインターコネクト９１を介して主メモリ１０２にアクセスする。またＣＰＵ１０３はチップセット９０を介してＮＩＣ１０１等のＩ／Ｏデバイスにアクセスして所定の処理を行う。同様にＮＩＣ１０１等のＩ／Ｏデバイスはチップセット１００を介して主メモリ１０２にアクセスする。
【００１６】
また、チップセット９０には、ＢＭＣ（Ｂａｓｅｂｏａｒｄ  Ｍａｎａｇｅｍｅｎｔ  Ｃｏｎｔｒｏｌｌｅｒ）１０４が接続される。ＢＭＣ１０４は、物理計算機１０の状態を監視したり電源制御を行う。ＢＭＣ１０４は、管理ＬＡＮ１９０を介して図示しない管理計算機に接続される。
【００１７】
主メモリ１０２には、ハイパバイザ（図中Ｈｙｐｅｒｖｉｓｏｒ）１１０がロードされ、ＣＰＵ１０３によって実行されることで、物理計算機１０の計算機資源を複数の仮想計算機１１−１，１１−２〜１１−ｎへ割り当てることができる。なお、各仮想計算機１１−１、１１−２〜１１−ｎではそれぞれ第１ゲストＯＳ１１１−１、第２ゲストＯＳ１１１−２〜１１１−ｎ（図２参照）が実行される。なお、以下では、仮想計算機の総称を符号１１で表し、ゲストＯＳの総称を符号１１１で表す。なお、他の構成要素の符号も同様であり、「−ｎ」で個々を識別し、「−」のない符号で総称を示す。
【００１８】
ＮＩＣ１０１は、ＳＲ−ＩＯＶに準拠し、主メモリ１０２上に設定された複数の送受信キュー１３２を有するマルチキューのＩ／Ｏデバイスで構成された例を示す。なお、ＨＢＡ２５１をマルチキューのＩ／Ｏデバイスで構成してもよい。また、物理計算機１０は、ＮＩＣ１０１やＨＢＡ２５１等のＩ／Ｏデバイスを複数備えることができる。
【００１９】
ＮＩＣ１０１は、ＳＲ−ＩＯＶに準拠する物理機能（Ｐｈｙｓｉｃａｌ  Ｆｕｎｃｔｉｏｎ：以下、ＰＦとする）１４１と、仮想機能（Ｖｉｒｔｕａｌ  Ｆｕｎｃｔｉｏｎ：以下、ＶＦとする）１４２とを有する。ＰＦ１４１は、１以上のＶＦ１４２を設定することができる。
【００２０】
ハイパバイザ１１０は、ＮＩＣ１０１のＰＦ１４１を利用するＰＦドライバ１２２を有する。仮想計算機１１−１、１１−２の第１ゲストＯＳ１１１−１、第２ゲストＯＳ１１１−２は、ＮＩＣ１０１のＶＦ１４２を利用するＶＦドライバ１２３をそれぞれ有する。ここで、仮想計算機１１−１の第１ゲストＯＳ１１１−１は、後述するように、ハイパバイザ１１０に障害が発生したときに機能するサブＰＦドライバ（図中ｓｕｂ  ＰＦドライバ）１２２Ａを有する。
【００２１】
そして、ハイパバイザ１１０は、仮想計算機１１−１と１１−２にＶＦ１４２を割り当てて、ＮＩＣ１０１を共有する。本実施例では、ハイパバイザ１１０は、物理計算機１０の計算機資源を論理的に分割して論理資資源（または論理区画）とし、論理資源を仮想計算機１１に割り当てる仮想化部であればよい。
【００２２】
図２は、仮想計算機システムの要部を示す機能ブロック図である。ＣＰＵ１０３では、ハイパバイザ１１０と、第一ゲストＯＳ１１１−１と、第二ゲストＯＳ１１１−２が実行される。これらはＮＩＣ１０１を介してネットワーク１８０とのＩ／Ｏ（入出力）を行うが、このＩ／Ｏの実行に必要なデータ構造を主メモリ１０２上に配置する。また、主メモリ１０２には、ハイパバイザ１１０、第一ゲストＯＳ１１１−１、第二ゲストＯＳ１１１−２が管理するＮＩＣ１０１とのリンク状態の格納領域としても使用される。
【００２３】
ＮＩＣ１０１には、送受信部１２１とリンク操作部１２０が搭載されている。送受信部１２１は第一ゲストＯＳ１１１−１、第二ゲストＯＳ１１１−２のＶＦドライバ１２３から直接起動される。ＮＩＣ１０１が送受信するデータは、主メモリ上１０２の送受信キュー（マルチキュー）１３２を介して送受される。
【００２４】
一方、リンク操作部１２０はハイパバイザ１１０のＰＦドライバ１２２によって操作（物理リンク操作要求を発行）される。また、ＮＩＣ１０１のＰＦ１４１やＶＦ１４２からの割り込みもハイパバイザ１１０のＰＦドライバ１２２に通知される。ＮＩＣ１０１の物理リンクの状態が主メモリ１０２上の物理リンク状態１３０に格納され、ＰＦドライバ１２２によって管理される。
【００２５】
また、ハイパバイザ１１０のＰＦドライバ１２２は、ＮＩＣ１０１で行われるリンク操作をエミュレートする。そして、ＰＦドライバ１２２は、第一ゲストＯＳ１１１−１や第二ゲストＯＳ１１１−２のＶＦドライバ１２３との間で、仮想リンク操作要求や割り込み通知を送受信する。そして、第一ゲストＯＳ１１１−１や第二ゲストＯＳ１１１−２は、ＶＦドライバ１２３が認識している接続状態を主メモリ１０２上の仮想リンク状態１３１−１、１３１−２にそれぞれ格納する。
【００２６】
第一ゲストＯＳ１１１−１は、サブＰＦドライバ１２２Ａも有する。サブＰＦドライバ１２２Ａは、ＢＭＣ１０４を監視してハイパバイザ１１０の稼働状態を監視する監視部１２４と、ハイパバイザ１１０に障害が発生したときにＰＦドライバ１２２の状態をサブＰＦドライバ１２２Ａに引き継ぐフェイルオーバ（図中ｆａｉｌｏｖｅｒ）部１２５を保持する。
【００２７】
ＢＭＣ１０４にはハイパバイザ状態格納領域１３３が格納され、ＰＦドライバ１２２が定期的（所定の周期）に本領域を更新する。なお、ＢＭＣ１０４は図示しないプロセッサとメモリを有し、ハイパバイザ状態格納領域１３３をメモリに格納する。
【００２８】
サブＰＦドライバ１２２Ａの監視部１２４は、上記ハイパバイザ状態格納領域１３３の更新が一定時間を超えて行われていないことを検知することでハイパバイザ１１０の障害発生を検知する。
【００２９】
監視部１２４が障害を検知すると、サブＰＦドライバ１２２Ａはフェイルオーバ部１２５を起動し、物理リンク状態１３０を主メモリ１０２上で再構成し、サブＰＦドライバ１２２Ａ用の物理リンク状態１３０Ａを主メモリ１０２上に生成する。以降、第一ゲストＯＳ１１１−１のＶＦドライバ１２３は、ハイパバイザ１１０のＰＦドライバ１２２に代わって、サブＰＦドライバ１２２Ａを介して仮想リンク操作要求の発行や、割り込み通知を受信することにより、ハイパバイザ１１０の障害発生後の第一ゲストＯＳ１１１−１によるＩ／Ｏの継続が可能になる。サブＰＦドライバ１２２Ａ用の物理リンク状態１３０Ａは、ＰＦドライバ１２２の物理リンク状態１３０と同様に構成される。
【００３０】
なお、第１ゲストＯＳ１１１−１とハイパバイザ１１０の接続と、第２ゲストＯＳ１１１−２とハイパバイザ１１０の接続は、ハイパバイザ１１０が提供する仮想ネットワーク（または仮想スイッチ）を用いる。
【００３１】
一方、サブＰＦドライバ１２２Ａの監視部１２４と第２ゲストＯＳ１１１−２のＶＦドライバ１２３を接続する緊急リンク１５０は、主メモリ１０２上に予め設定された領域を用いて通信を行うもので、ハイパバイザ１１０が停止したときも使用可能なリンクである。
【００３２】
次に、図３から図６で、主メモリ１０２上、及びＢＭＣ１０４に格納される各種データ構造を説明する。
【００３３】
図３は、物理リンク状態１３０及び１３０Ａのデータ構造の一例を示す図である。物理リンク状態１３０は、各ＶＦ１４２及びＰＦ１４１がリンクアップしているかリンクダウンしているかを表す状態としてのリンクアップ状態２０１と、各ＶＦ１４２に設定したリンクアップ時の物理帯域量を表すリンク帯域状態２０２とを含む。
【００３４】
物理リンク状態１３０は、後述するように、ＰＦドライバ１２２によって管理される。まず、リンクアップ状態２０１は、ＰＦ１４１及びＶＦ１４２の物理的な接続状態を示す物理状態２１０と、各仮想計算機１１のゲストＯＳ１１１に通知している各ＶＦ１４２ごとの接続状態を格納する通知状態２１１の２種類の情報で構成される。図３においては、ＶＦ１４２はＶＦ１〜ＶＦｎのｎ個が生成された状態を示す。また、図中「ＵＰ」はＬＡＮ１８０に接続中を示し、「ＤＯＷＮ」はＬＡＮ１８０との接続が遮断されていることを示す。
【００３５】
リンク帯域状態２０２は、ＮＩＣ１０１の物理的な帯域を示す物理状態２２０と、各仮想計算機１１のゲストＯＳ１１１にそれぞれ通知している各ＶＦ１４２ごとの帯域を格納する通知状態２３０の情報で構成される。ＰＦ１４１は、ハイパバイザ１１０自身がＰＦドライバ１２２で利用しているので、通知は不要となる。
【００３６】
物理状態２２０は、各ＶＦ１４２に設定可能な帯域の最大値を示すＭＡＸ２２１と、各ＶＦ１４２に割り当てた帯域である割当２２２から構成される。また、通知状態２３０は、各ＶＦ１４２に通知した割当可能な帯域の最大値を示すＭＡＸ２３１と、実際に仮想計算機１１へ割り当てられた帯域を示す割当２３２から構成される。なお、図３において、帯域の単位はｂｐｓを示す。
【００３７】
なお、第二ゲストＯＳ１１１−１のサブＰＦドライバ１２２Ａの物理リンク状態１３０Ａも、上記図３と同様に構成される。
【００３８】
図４は、仮想リンク状態１３１のデータ構造の一例を示す図である。仮想リンク状態１３１は、各ＶＦドライバ１２３毎に設定される。仮想リンク状態１３１は、各ゲストＯＳ１１１が認識しているＶＦ１４２のリンクアップ状態を示すリンクアップ状態３０１と、各ゲストＯＳ１１１が認識しているリンク帯域を格納するリンク帯域状態３０２を含む。リンクアップ状態は、図３に示した物理リンク状態１３０のリンクアップ状態２０１を構成する通知状態２１１に対応する。
【００３９】
リンク帯域状態３０２は、割当可能な帯域の最大値を格納する「ＭＡＸ値」と、実際に割り当てられた「割当値」を含む。「ＭＡＸ値」は、図３に示した物理リンク状態１３０のリンク帯域状態２０２を構成する通知状態２３０のＭＡＸ２３１と割当２３２に対応する。
【００４０】
図５は、送受信キュー１３２のデータ構造の一例を示す図である。送受信キュー１３２は、送信キュー４０１と受信キュー４０２からなる。
【００４１】
送信キュー４０１は、イネーブルビット（図中ｅｎａｂｌｅ  ｂｉｔ４１０）を持ち、ＮＩＣ１０１が当該キューを介した送信処理を行うべきか否かを制御する。また、送信キュー４０１はアドレス４２０、サイズ４２１、エラー状態４２２からなるエントリのリングキューを持つ。それぞれのリングキューには、リードインデックス（図中ｒｅａｄ  ｉｎｄｅｘ）４１１とライトインデックス（図中ｗｒｉｔｅ  ｉｎｄｅｘ）４１２があり、ＮＩＣ１０１及びＶＦドライバ１２３のうちエンキュー処理を行う側がライトインデックス４１２を設定し、デキュー処理を行う側がリードインデックス４１１を設定することで、キューイングされているデータ（未送信データ）を認識する。
【００４２】
受信キュー４０２は、イネーブルビット（図中ｅｎａｂｌｅ  ｂｉｔ）４３０を有し、ＮＩＣ１０１が当該キューを介した受信処理を行うべきか否かを制御する。また、受信キュー４０２はアドレス４４０、サイズ４４１、エラー状態４４２からなるエントリのリングキューを持つ。それぞれのリングキューには、リードインデックス（図中ｒｅａｄ  ｉｎｄｅｘ）４３１とライトインデックス（図中ｗｒｉｔｅ  ｉｎｄｅｘ）４３２があり、ＮＩＣ１０１及びＶＦドライバ１２３のうちエンキュー処理を行う側がライトインデックス４３２を設定し、デキュー処理を行う側がリードインデックス４３１を設定することで、キューイングされているデータ（未受信データ）を認識する。
【００４３】
図６はハイパバイザ状態格納領域１３３のデータ構造の一例を示す図である。ＢＭＣ１０４の図示しないメモリには、ハイパバイザ状態格納領域１３３が格納される。
【００４４】
ハイパバイザ状態格納領域１３３にはカウンタ５０１が含まれる。ハイパバイザ１１０のＰＦドライバ１２２は、カウンタ５０１のカウントアップを定期的に行う。これにより、サブＰＦドライバ１２２Ａの監視部１２４は、カウンタ５０１のカウントアップが一定時間以上停止することによりハイパバイザ１１０に障害が派生したことを検知することが可能になる。
【００４５】
次に、図７から図１８で、ＮＩＣ１０１、ハイパバイザ１１０のＰＦドライバ１２２、第一ゲストＯＳ１１１−１または第二ゲストＯＳ１１１−２のＶＦドライバ１２３、第一ゲストＯＳのサブＰＦドライバ１２２Ａで行われる処理の一例を示すフローチャートを説明する。
【００４６】
図７及び図８はＮＩＣ１０１のリンク操作部１２０で行われる処理の一例を示すフローチャートである。ＮＩＣ１０１のリンク操作部１２０は、定期的なポーリング及びＰＦドライバ１２２からの物理リンク操作要求の受信を契機に稼働を開始する。
【００４７】
図７は、定期的なポーリングの一例を示すフローチャートである。  
【００４８】
図８は、ＰＦドライバ１２２からの物理リンク操作要求の受信を契機にした処理の一例を示すフローチャートである。
【００４９】
図７は、物理計算機１０のタイマイベント等により、リンク操作部１２０が定期的（所定の周期）に実行するポーリングを示す。ステップ６０１にて、リンク操作部１２０は、定期的にＰＦ１４１、ＶＦ１４２の状態を取得することで物理リンク状態（リンクアップ状態及びリンク帯域状態）のポーリングを行う。ステップ６０２にて、リンク操作部１２０は、物理リンク状態の変更を検知したら、ハイパバイザ１１０のＰＦドライバ１２２に割り込みを通知する。本割り込み通知を契機にＰＦドライバ１２２は物理リンク操作要求を発行し、物理リンク状態１３０の更新を行うが、その詳細は図１１で説明する。
【００５０】
図８は、ＰＦドライバ１２２からの物理リンク操作要求を受信したときにリンク操作部１２０で実行されるフローチャートである。
【００５１】
ステップ７０１にて、リンク操作部１２０は、ＰＦドライバ１２２から物理リンク操作要求（リンクアップ状態／リンク帯域状態の読み出し要求）を受信する。そして、ステップ７０２にて、リンク操作部１２０は、新しい物理リンク状態（リンクアップ状態／リンク帯域状態）をＰＦドライバ１２２に通知する。
【００５２】
図９及び図１０は、ＮＩＣ１０１の送受信部１２１で行われる処理の一例を示すフローチャートである。ＮＩＣ１０１の送受信部１２１は定期的なポーリング、またはデータ受信を契機に処理を開始する。定期的なポーリングを契機にした送受信部１２１で行われる処理のフローチャートを図９に示す。データの受信を契機にして送受信部１２１で行われる処理の一例を示すフローチャートを図１０に示す。
【００５３】
図９は、送受信部１２１の定期的なポーリング処理のフローチャートである。ステップ８０１にて、送受信部１２１は、送信キュー４０１のライトインデックス４１２を定期的（所定の周期）にポーリングする。
【００５４】
そして、ステップ８０２にて、送受信部１２１は、送信キュー４０１のリードインデックス４１１とライトインデックス４１２の値が等しいか（キューイングされている未送信データがあるか）否かを判定し、等しければステップ８０３に進み、等しくなければステップ８０５に進む。
【００５５】
ステップ８０３にて、送受信部１２１は、送信キュー４０１のイネーブルビット４１０がｏｎであるか否かを判定し、ｏｎであれば（送信処理を継続する必要があれば）直ちにステップ８０１に復帰する。一方、イネーブルビット４１０がｏｆｆであれば、ステップ８０４にてイネーブルビット４１０が再びｏｎになるまで待ち合わせ、再びｏｎになればステップ８０１に復帰する。
【００５６】
ステップ８０５では、送受信部１２１は、リードインデックス４１１で指定されるエントリのアドレス４２０及びサイズ４２１フィールドで指定される主メモリ１０２上のデータを、ＮＩＣ１０１から送信する（未送信データの送信処理の実行）。そして、ステップ８０６にて、送受信部１２１は、上記エントリのエラー状態８０６として正常終了を示す所定値（例えば、「０」）に設定する。次に、送受信部１２１は、ステップ８０７にてリードインデックス４１１のインクリメントを行う。その後、ステップ８０１に戻る。
【００５７】
図１０は、送受信部１２１のデータ受信を契機にした処理のフローチャートである。ステップ９０１にて、送受信部１２１は、データをＮＩＣ１０１で受信する。そしてステップ９０２にて送受信部１２１は、受信キュー４０２のライトインデックス４３２がインクリメント可能か否か（受信キュー４０２に空きエントリがあるか否か）を判定する。そして、送受信部１２１は、空きエントリがあればステップ９０３に進み、受信データを破棄してステップ９０１に戻る。
【００５８】
一方、送受信部１２１は、空きエントリがあればステップ９０４に進む。ステップ９０４にて、送受信部１２１は、イネーブルビット４３０がｏｎであるか否かを判定し、ｏｎであれば（受信処理を継続する必要があれば）ステップ９０６に進む。一方、イネーブルビット４３０がｏｆｆであれば、ステップ９０５にてイネーブルビット４３０が再びｏｎになるまで待ち合わせる。そして、イネーブルビット４３０が、再びｏｎになればステップ９０３に進み、受信データの破棄を行う。
【００５９】
ステップ９０６にて、送受信部１２１はライトインデックス４３２で指定されるエントリのアドレス４４０で指定される主メモリ１０２の領域（バッファ領域）に受信データをコピーする。さらに、サイズ４４１を受信データサイズに応じて設定し、エラー状態４４２として正常終了を示す値（例えば「０」）に設定する。そして、ステップ９０７にて送受信部１２１は、受信キュー４０２のライトインデックス４３２をインクリメントし、ステップ９０１に復帰する。
【００６０】
図１１から図１３はハイパバイザ１１０のＰＦドライバ１２２で行われる処理の一例を示すフローチャートである。ハイパバイザ１１０のＰＦドライバ１２２は、リンク操作部１２０からの割り込み通知を受信したときや、第一ゲストＯＳ１１１−１または第二ゲストＯＳ１１１−２のＶＦドライバ１２３からの仮想リンク操作要求を受信（リンクアップ状態／リンク帯域状態の読み出し要求受信）したときに、定期的なポーリングを実行する。
【００６１】
リンク操作部１２０からの割り込み通知の受信を契機にした処理のフローチャートを図１１に示し、ＶＦドライバ１２３からの仮想リンク操作要求の受信を契機にした処理のフローチャートを図１２に示し、定期的なポーリング処理のフローチャートを図１３に示す。
【００６２】
図１１は、ＰＦドライバ１２２がＮＩＣ１０１のリンク操作部１２０からの割り込み通知の受信を契機にした処理のフローチャートを示す図である。
【００６３】
ステップ１０１にて、ＰＦドライバ１２２はＮＩＣ１０１のリンク操作部１２０から割り込み通知を受信する。
【００６４】
ステップ１００２にて、ＰＦドライバ１２２は、ＮＩＣ１０１のリンク操作部１２０に対して、物理リンク操作要求（リンクアップ状態／リンク帯域状態の読み出し要求）を発行する。リンク操作部１２０は、上記図８に示したフローチャートの処理により、現在のＮＩＣ１０１の物理リンク状態（リンクアップ状態／リンク帯域状態）を通知してくる。ＰＦドライバ１２２は、ステップ１００３にて、リンク操作部１２０から通知されたリンクアップ状態及びリンク帯域状態を物理リンク状態１３０のリンクアップ状態２０１及びリンク帯域状態２０２の物理状態２１０、２２０の各フィールドに格納する。
【００６５】
そしてステップ１００４にて、ＰＦドライバ１２２は、物理リンク状態１３０のリンクアップ状態２０１及びリンク帯域状態２０２のそれぞれについて、物理状態２１０、２２０の各フィールドに格納された値と、通知状態２１１、２３０の各フィールドに格納された値が一致しているか否かを検査する。そして、ＰＦドライバ１２２は、リンクアップ状態２０１とリンク帯域状態２０２で、不一致が検出されれば、対応する第一ゲストＯＳ１１１−１もしくは第二ゲストＯＳ１１１−２のＶＦドライバ１２３に割り込み通知を発行する。
【００６６】
図１２は、ＰＦドライバ１２２が、ＶＦドライバ１２３から仮想リンク操作要求を受信したときに実行する処理の一例を示すフローチャートである。
【００６７】
ステップ１１０１にて、ＰＦドライバ１２２は、第一ゲストＯＳ１１１−１もしくは第二ゲストＯＳ１１１−２のＶＦドライバ１２３から仮想リンク操作要求（リンクアップ状態／リンク帯域状態読み出し要求）を受信する。
【００６８】
そして、ステップ１１０２にて、ＰＦドライバ１２２は、物理リンク状態１３０のリンクアップ状態２０１及びリンク帯域状態２０２のそれぞれについて、通知状態２１１、２３０が対応するフィールドの値を物理状態２１０の値に更新する（各ゲストＯＳへ通知した最新状態の値を保存しておく）。そして、ステップ１１０３にてＰＦドライバ１２２は、上記更新した値を各ゲストＯＳ１１１のＶＦドライバ１２３に通知する。
【００６９】
図１１及び図１２に示すように、ハイパバイザのＰＦドライバ１２２は、第一ゲストＯＳ１１１−１もしくは第二ゲストＯＳ１１１−２のＶＦドライバ１２３に対して、仮想リンク操作要求／割り込み通知のインタフェースで接続しており、このインタフェースはＰＦドライバ１２２とＮＩＣ１０１のリンク操作部１２０との間のインタフェースと同様である。すなわち、ＰＦドライバ１２２はリンク操作部１２０をエミュレートすることで、ＶＦドライバ１２３が同一ＮＩＣ１０１を共有しているにも関わらず、通常のＮＩＣと同様の手順でのリンク操作を可能にしている。
【００７０】
図１３は、ＰＦドライバ１２２の定期的（周期的）なポーリング処理のフローチャートを示す図である。ステップ１２０１にてＰＦドライバ１２２は定期的に起動し、ＢＭＣ１０４のハイパバイザ状態格納領域１３３のカウンタ５０１をインクリメントする。そしてステップ１２０２にて一定時間スリープする。上記処理を周期的に繰り返すことで、ハイパバイザ１１０が稼働していれば、周期的にカウンタ５０１が加算されることになる。
【００７１】
図１４から図１６は第一ゲストＯＳ１１１−１もしくは第二ゲストＯＳ１１１−２のＶＦドライバ１２３のフローチャートを示す図である。ＶＦドライバ１２３は、ハイパバイザ１１０のＰＦドライバ１２２からの割り込み通知、データ送信処理の開始、定期的なポーリングを契機に稼働を開始する。ＰＦドライバ１２２からの割り込み通知を契機にした処理のフローチャートを図１４に、データ送信処理開始を契機にした処理のフローチャートを図１５に、定期的なポーリングを契機にした処理のフローチャートを図１６に示す。
【００７２】
図１４は、ＶＦドライバ１２３が、ＰＦドライバ１２２からの割り込み通知を受信したときに実行する処理の一例を示すフローチャートである。
【００７３】
ステップ１３０１にて、ＶＦドライバ１２３は、ＰＦドライバ１２２からの割り込み通知を受信する。そしてステップ１３０２にて、ＶＦドライバ１２３は、ＰＦドライバ１２２に対して仮想リンク操作要求（リンクアップ状態／リンク帯域状態の読み出し要求）を発行する。ＰＦドライバ１２２は、上記図１２に記載した手順に従い、現在のＰＦ１４１、ＶＦ１４２のリンクアップ状態／リンク帯域状態を通知してくるので、ステップ１３０３にて、ＶＦドライバ１２３は、受信した各状態の値を仮想リンク状態１３１のリンクアップ状態３０１及びリンク帯域状態３０２に設定する。
【００７４】
以上の処理により、各ゲストＯＳ１１１毎の仮想リンク状態１３１は、当該ゲストＯＳ１１１に割り当てられたＶＦ１４２の現在のリンクアップ状態とリンク帯域状態で更新される。
【００７５】
図１５は、第二ゲストＯＳ１１１−２のＶＦドライバ１２３が、データ送信の開始を契機にして実行する処理の一例を示すフローチャートである。ステップ１４０１にて、第二ゲストＯＳ１１１−２のＶＦドライバ１２３は、仮想リンク状態１３１のリンクアップ状態３０１フィールドにリンクアップ状態が格納されているか（リンクアップ状態と認識しているか）否かを判定する。そして、リンクアップ状態が格納されていなければステップ１４０２に進んでＶＦドライバ１２３は送信エラーを第二ゲストＯＳ１１１−２に応答する。
【００７６】
次にステップ１４０３では、第二ゲストＯＳ１１１−２のＶＦドライバ１２３がキンを介して監視部１２４から強制停止要求（ＮＩＣ１０１の利用停止の通知）を受信したか否か（ハイパバイザ１１０に障害が発生しているため、第二ゲストＯＳ１１１−２からのさらなるデータ送信処理開始が抑制されているか否か）を判定する。監視部１２４から強制停止要求を受信済みであれば、第２ゲストＯＳ１１１−１のＶＦドライバ１２３はステップ１４０４に進んで送信エラーをゲストＯＳ１１１−２へ応答する。
【００７７】
次にステップ１４０５にて、第二ゲストＯＳ１１１−２のＶＦドライバ１２３は、送信キュー４０１のライトインデックス４１２がインクリメント可能か否か（送信キュー４０１に空きエントリがあるか否か）を判定する。空きエントリがなければステップ１４０６に進んで送信エラーを第二ゲストＯＳ１１１−２へ応答する。
【００７８】
さらに、ステップ１４０７にて、第二ゲストＯＳ１１１−２のＶＦドライバ１２３は、送信データを主メモリ１０２に確保したバッファ領域にコピーし、当該バッファ領域のアドレス及びサイズを、ライトインデックス４１２で指定されるアドレス４２０／サイズ４２１のフィールドに設定する。そしてステップ１４０８にて、ＶＦドライバ１２３は、ライトインデックス４１２をインクリメントする。
【００７９】
なお、第一ゲストＯＳ１１１−１のＶＦドライバ１２３も上記ステップ１４０１〜１４０８の処理を送信開始時に実行する。ただし、第一ゲストＯＳ１１１−１のＶＦドライバ１２３は、ハイパバイザ１１０に障害が発生しても通信を停止しないので、ステップ１４０３の処理は実行する必要は無い。
【００８０】
図１６は、ＶＦドライバ１２３の定期的（周期的）なポーリング処理のフローチャートを示す図である。ステップ１５０１にて、ＶＦドライバ１２３は、受信キュー４０２のライトインデックス４３２の値を定期的にポーリングする。
【００８１】
そしてステップ１５０２にてＶＦドライバ１２３は、リードインデックス４３１とライトインデックス４３２の値が一致しているか否か（未受信のデータがエンキューされているか否か）を判定する。一致している場合（未受信データがない場合）にはステップ１５０１に戻るが、リードインデックス４３１とライトインデックス４３２の値が一致していない場合（未受信データが存在する場合）にはステップ１５０３に進む。
【００８２】
ステップ１５０３にて、ＶＦドライバ１２３は、ライトインデックス４３２で指定されるエントリのエラー状態４４２フィールドが正常終了（例えば、０）であることを判定した後、アドレス４４０／サイズ４４１のフィールドで指定される主メモリ１０２上のバッファ領域のデータを受信する。
【００８３】
そしてステップ１５０４にて、ＶＦドライバ１２３は、新たなバッファ領域を確保し、当該バッファ領域のアドレスをアドレス４４０のフィールドに設定する。さらにステップ１５０５にてＶＦドライバ１２３は、リードインデックス４３１をインクリメントする。
【００８４】
上記処理により、ＮＩＣ１０１が受信して受信キュー４０２に保持されたデータをＶＦドライバ１２３で読み込む（受信）することができる。
【００８５】
図１７及び図１８は、第一ゲストＯＳ１１１−１のサブＰＦドライバ１２２Ａの監視部１２４及びフェイルオーバ部１２５で行われる処理の一例を示すフローチャートである。
【００８６】
サブＰＦドライバ１２２Ａは、監視部１２４及びフェイルオーバ部１２５を稼働させる。そして、ハイパバイザ１１０に障害が発生したときには、図１１及び図１２に示すＰＦドライバ１２２と同様の処理を実行する。
【００８７】
図１７は、監視部１２４で行われる処理の一例を示すフローチャートである。監視部１２４はＢＭＣを定期的（または周期的）にポーリングする。ステップ１６０１にて、監視部１２４は、ＢＭＣ１０４のハイパバイザ状態格納領域１３３のカウンタ５０１の値を定期的に取得する。そしてステップ１６０２にて、当該カウンタ５０１のカウントアップが一定時間以上停止しているか否かを判定する。カウンタ５０１のカウントアップが一定時間以上停止していなければハイパバイザ１１０は正常に稼動中であると判定し、ステップ１６０１に戻る。
【００８８】
一方、カウンタ５０１のカウントアップが一定時間以上停止していれば、ハイパバイザ１１０に異常が発生したと判定し、ステップ１６０３にて第二ゲストＯＳ１１１−２に強制停止要求を送信した後、ステップ１６０４にてフェイルオーバ部１２５を起動する。
【００８９】
ここで、第二ゲストＯＳ１１１−２への強制停止要求は、ハイパバイザ１１０に異常が発生したため、第二ゲストＯＳ１１１−２からのさらなるデータ送信処理開始を抑制するものである。このため、緊急リンク１５０を介して通知する。なお、ゲストＯＳが複数ある場合には、緊急リンク１５０もゲストＯＳの数に応じて複数設定される。そして、複数のゲストＯＳ１１１−２〜ｎへの強制停止要求は、ＮＩＣ１０１（Ｉ／Ｏデバイス）の利用停止を含むものである。
【００９０】
図１８は、フェイルオーバ部１２５で行われる処理の一例を示すフローチャートである。フェイルオーバ部は図１７のステップ１６０４での監視部１２４からの起動を契機に処理を開始する。
【００９１】
フェイルオーバ部１２５は、実行中のネットワークＩ／Ｏが完全に完了するまでの待ち合わせ（ステップ１７０１〜ステップ１７０３）と、物理リンク状態１３０の主メモリ１０２上での再構成（ステップ１７０４〜ステップ１７０６）と、ハイパバイザ１１０及び第二ゲストＯＳ１１１−２のソフトリセット（ステップ１７０７）を行う。
【００９２】
そして、サブＰＦドライバ１２２Ａが物理リンク状態１３０Ａの再構成を行い、かつ、ハイパバイザ１１０の障害発生時には第一ゲストＯＳ１１１−１は仮想リンク操作要求の発行をＰＦドライバ１２２に対してではなくサブＰＦドライバ１２２Ａに対して行うことにより、第一ゲストＯＳ１１１−１のＶＦドライバ１２３は、ハイパバイザ１１０に障害が発生した後も、仮想リンク操作（リンクアップ状態／リンク帯域状態の読み出し）を行うことができる。送受信処理は図１５及び図１６に示した通りハイパバイザ１１０を介さずに行うので、ハイパバイザに障害が発生した後も、第一ゲストＯＳ１１１−１のＶＦドライバ１２３は、ＮＩＣ１０１を介したネットワークとのＩ／Ｏを継続できる。
【００９３】
また、実行中のネットワークＩ／Ｏを完全に完了するまで待ち合わせてからハイパバイザ１１０及び第二ゲストＯＳ１１１−２のソフトリセットを行うことで、ハイパバイザ１１０及び第二ゲストＯＳ１１１−２の再起動中に、これらが使用するメモリ領域が実行中のネットワークＩ／Ｏにより破壊されないことを保証できる。この結果、ハイパバイザ１１０や第二ゲストＯＳ１１１−２の再起動後に、ハイパバイザ１１０や第二ゲストＯＳ１１１−２の正常な稼働の再開を保証でき、再起動後には図２記載の構成での再稼働を実現できる。
【００９４】
フェイルオーバ部１２５はステップ１７０１にてすべての第二ゲストＯＳ１１１−２用の受信キュー４０２のイネーブルビット４３０をｏｆｆにする。これにより、新しいデータ受信により主メモリ１０２の内容が更新されること（図１０のステップ９０６の実行）を防げる。
【００９５】
さらに、ステップ１７０２にて、フェイルオーバ部１２５は第二ゲストＯＳ１１１−２用のすべての送信キュー４０１及び受信キュー４０２において、リードインデックス４１１、４３１とライトインデックス４１２、４３２が同じ値になるまで待ち合わせる。これにより実行中のデータ送信及び受信が完全に停止したことを保証できる。さらにステップ１７０３にて送信キュー４０１のイネーブルビット４１０をオフにする。次にステップ１７０４にて、ＮＩＣ１０１のリンク操作部１２０に対して物理リンク操作要求（リンクアップ状態／リンク帯域状態の読み出し要求）を発行し、リンクアップ状態／リンク帯域状態を取得する。
【００９６】
そしてステップ１７０５にて、フェイルオーバ部１２５は、上記取得した値をサブＰＦドライバ用の物理リンク状態１３０Ａに存在するリンクアップ状態２０１／リンク帯域状態２０２の物理状態２１０の各フィールドに設定する。
【００９７】
さらに、フェイルオーバ部１２５は、ステップ１７０６にて、サブＰＦドライバ１２２Ａ用の物理リンク状態１３０Ａの通知状態２１１、２３０の再構成を行う。当該フィールドの第一ゲストＯＳ１１１−１分のデータは第一ゲストＯＳ１１１−１用の仮想リンク状態１３１のリンクアップ状態３０１及びリンク帯域状態３０２の値をコピーする。
【００９８】
また、それ以外の第二ゲストＯＳ１１１−２分のリンクアップ状態はリンクダウン状態に設定する。最後にステップ１７０７にて、ハイパバイザ１１０及び第二ゲストＯＳ１１１−２のソフトリセットを行う。
【００９９】
＜まとめ＞
本発明では、ハイパバイザ１１０と、第一ゲストＯＳ１１１−１と第二ゲストＯＳ１１１−２が主メモリ１０２及びＮＩＣ１０１を共有する仮想計算機システムで、Ｉ／ＯデバイスとしてのＮＩＣ１０１はＳＲ−ＩＯＶに準拠する。
【０１００】
そして、ＮＩＣ１０１（Ｉ／Ｏデバイス）のデータの送受信に関しては、第一ゲストＯＳ１１１−１と第二ゲストＯＳ１１１−２は、直接、主メモリ１０２上のＮＩＣ１０１の送受信キューを介して送受信要求を発行する（ハイパバイザ１１０を介してデータの送受信は行わない）。
【０１０１】
しかし、ＮＩＣ１０１のリンク状態の取得に関しては、ハイパバイザ１１０はＮＩＣ１０１が提供するリンク状態を取得するインタフェースをエミュレートし、第一ゲストＯＳ１１１−１と第二ゲストＯＳ１１１−２はハイパバイザ１１０を介してリンク状態の取得要求を発行し、ハイパバイザ１１０からリンク状態を取得する。
【０１０２】
上記エミュレーションのため、ハイパバイザ１１０は、「現リンク状態」の他に、ゲストＯＳ１１１毎の「通知済みリンク状態」を主メモリ１０２上で管理する。「現リンク状態」はハイパバイザ１１０が、ＮＩＣ１０１に対してリンク状態の取得要求を発行し、取得したリンク状態を設定する。
【０１０３】
一方、「通知済みリンク状態」は、第一ゲストＯＳ１１１−１または第二ゲストＯＳ１１１−２が上記リンク状態の取得インタフェースを介してリンク状態の取得要求を発行した際に、「現リンク状態」の値を第一ゲストＯＳ１１１−１または第二ゲストＯＳ１１１−２に通知すると共に、「現リンク状態」と同じ値に同期しておく。
【０１０４】
一方、第一ゲストＯＳ１１１−１または第二ゲストＯＳ１１１−２は、通知されたリンク状態の値を「認識されたリンク状態」として主メモリ１０２上に保存する。
【０１０５】
この構成でハイパバイザ１１０に障害が発生した際に、第一ゲストＯＳ１１１−１がＮＩＣ１０１を介したネットワークＩ／Ｏを継続させる。データの送受信については、主メモリ１０２に予め設定された送受信キュー１３２を使用するので、ハイパバイザ１１０を介して送受信を行わないので問題なく継続できる。しかし、第一ゲストＯＳ１１１−１のＶＦドライバ１２３からリンク状態の取得は継続できなくなる。
【０１０６】
そのため、本発明では、第一ゲストＯＳ１１１−１がハイパバイザ１１０の稼動監視を定期的に行い、監視部１２４がハイパバイザ１１０の異常を検知したときには、第一ゲストＯＳ１１１−１のフェイルオーバ部１２５が、サブＰＦドライバ１２２Ａを起動してサブＰＦドライバ１２２Ａ用の物理リンク状態１３０Ａを構築する。物理リンク状態１３０Ａは、「現リンク状態」（図３の物理状態）及び「通知済みリンク状態」（図３の通知状態）の再構成を実行する。
【０１０７】
「現リンク状態」は第一ゲストＯＳ１１１−１が、ＶＦドライバ１２３からサブＰＦドライバ１２２Ａを介して、直接ＮＩＣ１０１に対してリンク状態の取得要求を発行することで取得する。
【０１０８】
また、「通知済みリンク状態」は第一ゲストＯＳ１１１−１が管理している「認識されたリンク状態」のコピーをサブＰＦドライバ１２２Ａの物理リンク状態１３０Ａに設定する。そして、以降の第一ゲストＯＳ１１１−１によるリンク状態取得要求の発行は、ハイパバイザ１１０に対してではなく、自分自身（サブＰＦドライバ１２２Ａ）に対して行うことで、リンク状態取得の継続（及びネットワークＩ／Ｏの継続）が可能になる。つまり、第一ゲストＯＳ１１１−１のＶＦドライバ１２３は、サブＰＦドライバ１２２ＡからＩ／Ｏデバイスの提供を受けて、Ｉ／Ｏデバイスを操作することができ、Ｉ／Ｏ処理を継続することができる。
【０１０９】
さらに、第一ゲストＯＳ１１１−１のサブＰＦドライバ１２２Ａは、障害が発生したハイパバイザ１１０が管理するＰＦドライバ１２２の物理リンク状態１３０を用いずに、第一ゲストＯＳ１１１−１のサブＰＦドライバ１２２Ａでは、ＰＦドライバ１２２のフェイルオーバ部１２５が物理リンク状態１３０Ａを再構成する。
【０１１０】
このとき、継続して稼働する第一ゲストＯＳ１１１−１は、ハイパバイザ１１０が提供するＰＦドライバ１２２を、自己のサブＰＦドライバ１２２Ａに切替えるだけであるので、データの移動などは不要であるので、極めて高速に切替えることができる。
【０１１１】
ここで、障害が発生したハイパバイザ１１０の物理リンク状態１３０は、障害の影響を受けている可能性がある。これにより、本発明では、障害の影響を受けた可能性のある物理リンク状態１３０を用いずに、第一ゲストＯＳ１１１−１でＩ／Ｏデバイスの入出力を継続するため、安定した稼働を確保できる。
【０１１２】
また、本発明では、第一ゲストＯＳ１１１−１とその他のゲストＯＳ１１１−２〜ｎを接続する緊急リンク１５０を設けることで、ハイパバイザ１１０に障害が発生しても、第一ゲストＯＳ１１１−１のＶＦドライバ１２３は、他のゲストＯＳ１１１−２〜ｎにＩ／Ｏ処理の強制停止を通知することが可能となる。
【０１１３】
その後、第一ゲストＯＳ１１１−１以外のゲストＯＳ１１１−２〜ｎと、ハイパバイザ１１０をソフトウェアリセットすることで再起動し、障害の回復を行うことができる。
【０１１４】
また、第一ゲストＯＳ１１１−１のＶＦドライバ１２３のフェイルオーバ部１２５は、他のゲストＯＳ１１１−２〜ｎ及びハイパバイザ１１０に対して、強制停止の指令を送信するが、各ゲストＯＳ１１１−２〜ｎでＩ／Ｏデバイスの送受信が完了するのを待ち合わせる。これにより、各ゲストＯＳ１１１−１〜１１１−ｎに於けるＩ／Ｏトランザクションが全て完了した後に、ゲストＯＳ１１１とハイパバイザ１１０をソフトウェアリセットすることで、送受信データに障害を与えるのを防止できる。つまり、物理的なＩ／ＯデバイスのＩ／Ｏトランザクションが全て完了してから、ゲストＯＳ１１１とハイパバイザ１１０をソフトウェアリセットすることになる。
【０１１５】
また、本発明では、サブＰＦドライバ１２２Ａを有する第一ゲストＯＳ１１１−１が稼働する第１の仮想計算機１１−１に、重要な業務を提供するアプリケーションまたはサービスを配置することで、ハイパバイザ１１０に障害が発生した場合でも、業務を継続する可能となり、冗長性を確保することができる。例えば、第１の仮想計算機１１−１で、ＳＡＮストレージを制御するストレージ制御ＯＳを第一ゲストＯＳ１１１−１として稼働させ、その他の仮想計算機１１−２〜ｎでは、ＳＡＮストレージを利用するゲストＯＳ１１１を稼働させる。この例では、ハイパバイザ１１０に障害が発生しても、第１の仮想計算機１１−１のストレージ制御ＯＳは停止することがないので、冗長性に優れた仮想計算機システムを提供することが可能となる。
【実施例２】
【０１１６】
実施例１では、フェイルオーバ部１２５の起動時に、サブＰＦドライバ１２２Ａ用の物理リンク状態１３０の再構成を行った。実施例２では、ＰＦドライバ１２２がＰＦドライバ１２２用の物理リンク状態１３０を更新するたびに、サブＰＦドライバ１２２Ａ用の物理リンク状態１３０Ａも同様に更新する。これにより、上記実施例１に示した再構成が不要になり、フェイルオーバ処理をより迅速に行うことが可能になる。
【０１１７】
実施例２は、前記実施例１と同様の構成であり、処理の一部が相違する。実施例１との相違点は、ＰＦドライバ１２２が割り込み通知を受信したときの処理（図１９）と、ＰＦドライバ１２２が仮想リンク操作要求の受信を契機にした処理（図２０）と、フェイルオーバ部１２５の処理（図２１）について、以下これらについて説明する。
【０１１８】
図１９は、ＰＦドライバ１２２がＮＩＣ１０１のリンク操作部１２０からの割り込み通知を受信したときに行われる処理のフローチャートである。このフローチャートは、前記実施例１の図１１に記載したフローチャートに対して、ステップ１００３の代わりにステップ１８０３を実行する点である。
【０１１９】
ステップ１８０３では、リンク操作部１２０から通知されたリンクアップ状態及びリンク帯域状態を、ＰＦドライバ１２２用の物理リンク状態１３０のリンクアップ状態２０１及びリンク帯域状態２０２の物理状態２１０、２２０の各フィールドに格納し、これらの値を第一ゲストＯＳ１１１−１１１１−１に通知する。そして第一ゲストＯＳ１１１−１１１１−１は、これらの値をサブＰＦドライバ１２２Ａ用の物理リンク状態１３０Ａの各フィールドに格納する。
【０１２０】
以上の処理により、サブＰＦドライバ１２２Ａの物理リンク状態１３０Ａは、第一ゲストＯＳ１１１−１１１１−１がＰＦドライバ１２２から受信したリンクアップ状態及びリンク帯域状態で更新される。したがって、ＰＦドライバ１２２の物理リンク状態１３０と、サブＰＦドライバ１２２Ａの物理リンク状態１３０Ａは、リンク操作部１２０から通知されたリンクアップ状態及びリンク帯域状態で同期することができる。
【０１２１】
図２０は、ＰＦドライバ１２２がＶＦドライバ１２３からの仮想リンク操作要求を受信したときに行われる処理のフローチャートである。このフローチャートは、前記実施例１の図１２に記載したフローチャートに対して、ステップ１１０２の代わりにステップ１９０２を実行する点である。
【０１２２】
ステップ１９０２では、ＰＦドライバ１２２用の物理リンク状態１３０のリンクアップ状態２０１及びリンク帯域状態２０２のそれぞれについて、通知状態２１１、２３０の対応するフィールドの値を物理状態２１０の値で更新する（各ゲストＯＳへ通知した最新状態の値を保存しておく）。そして、ＰＦドライバ１２２は、これらの値を第一ゲストＯＳ１１１−１１１１−１に通知する。第一ゲストＯＳ１１１−１１１１−１はサブＰＦドライバ１２２Ａ用の物理リンク状態１３０に関して同様の更新を行い、サブＰＦドライバ１２２Ａ用の物理リンク状態１３０のリンクアップ状態２０１及びリンク帯域状態２０２をＰＦドライバ１２２から受信した値で更新する。
【０１２３】
図２１は、サブＰＦドライバ１２２Ａのフェイルオーバ部１２５で行われる処理のフローチャートである。このフローチャートは、前記実施例１の図１８に記載したフローチャートに対して、ステップ１７０４からステップ１７０６を実行する代わりにステップ２００１を実行する点である。
【０１２４】
ステップ２００１では、フェイルオーバ部１２５が、サブＰＦドライバ１２２Ａ用の物理リンク状態１３０Ａのリンクアップ状態２０１の各フィールドについて、第二ゲストＯＳ１１１−２１１１−２分（例えば、図中ＶＦ２）の通知状態２１１のフィールドの値をリンクダウンに設定する。なお、リンクダウンに設定する通知状態２１１のフィールドは、第一ゲストＯＳ１１１−１１１１−１以外のＶＦドライバ１２３が利用しているＶＦ１４２である。
【０１２５】
サブＰＦドライバ１２２Ａ用の物理リンク状態１３０Ａの他フィールドに関しては、図１９に示したステップ１８０３及び図２０に示したステップ１９０２にて上述のように既に設定されているので、フェイルオーバ部１２５が改めて設定する必要はない。
【０１２６】
以上の処理により、実施例２においても、障害が発生したハイパバイザ１１０の物理リンク状態１３０を複製することなく、第一ゲストＯＳ１１１−１１１１−１ではリンク操作部１２０からの通知に応じて同期していた物理リンク状態１３０ＡをサブＰＦドライバ１２２Ａが用いる。これにより、ハイパバイザ１１０に障害が発生した場合でも、第一ゲストＯＳ１１１−１１１１−１のＶＦドライバ１２３でＩ／Ｏ処理を停止することなく、Ｉ／Ｏ処理を継続して業務やサービスの提供を継続することが可能となる。
【０１２７】
なお、上記各実施例では、Ｉ／ＯデバイスとしてＮＩＣ１０１を用いる例を示したが、ＳＲ−ＩＯＶに対応したＩ／Ｏデバイスであれば良く、例えば、ＳＲ−ＩＯＶに対応したＨＢＡやＣＮＡ（Converged Network Adapter）に適用することができる。
【０１２８】
また、前記実施例１、２では、ハイパバイザ１１０の障害を、ＢＭＣ１０４のカウンタ５０２により検出する例を示したが、ハイパバイザ１１０のハートビートなど公知または周知の手法を適用することができ、上記に限定されるものではない。また、ハイパバイザ１１０の障害の監視は、第１ゲストＯＳ１１１−１のサブＰＦドライバ１２２Ａの監視部１２４ｎが実行する例を示したが、これに限定されるものではなく、監視部１２４はサブＰＦドライバ１２２Ａではなく第一ゲストＯＳ１１１−１で稼働すれば良い。
【０１２９】
なお、本発明において説明した計算機等の構成、処理部及び処理手段等は、それらの一部又は全部を、専用のハードウェアによって実現してもよい。
【０１３０】
また、本実施例で例示した種々のソフトウェアは、電磁的、電子的及び光学式等の種々の記録媒体（例えば、非一時的な記憶媒体）に格納可能であり、インターネット等の通信網を通じて、コンピュータにダウンロード可能である。
【０１３１】
また、本発明は上記した実施例に限定されるものではなく、様々な変形例が含まれる。例えば、上記した実施例は本発明をわかりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。
【符号の説明】
【０１３２】
１０１  ＮＩＣ１０１
１０２  主メモリ１０２
１０３  ＣＰＵ
１０４  ＢＭＣ
１１０  ハイパバイザ
１１１  第一ゲストＯＳ１１１−１
１１２  第二ゲストＯＳ１１１−２
１２０  リンク操作部
１２１  送受信部
１２２  ＰＦドライバ
１２２Ａ  サブＰＦドライバ
１２３  ＶＦドライバ
１２４  監視部
１２５  フェイルオーバ部
１３０  物理リンク状態
１３１  仮想リンク状態
１３２  送受信キュー
１３３  ハイパバイザ状態格納領域
【図１】
2014106587.tif 000003
【図２】
2014106587.tif 000004
【図３】
2014106587.tif 000005
【図４】
2014106587.tif 000006
【図５】
2014106587.tif 000007
【図６】
2014106587.tif 000008
【図７】
2014106587.tif 000009
【図８】
2014106587.tif 000010
【図９】
2014106587.tif 000011
【図１０】
2014106587.tif 000012
【図１１】
2014106587.tif 000013
【図１２】
2014106587.tif 000014
【図１３】
2014106587.tif 000015
【図１４】
2014106587.tif 000016
【図１５】
2014106587.tif 000017
【図１６】
2014106587.tif 000018
【図１７】
2014106587.tif 000019
【図１８】
2014106587.tif 000020
【図１９】
2014106587.tif 000021
【図２０】
2014106587.tif 000022
【図２１】
2014106587.tif 000023