第1の仮想計算機と、第2の仮想計算機と、前記第1、第2の仮想計算機を管理するハイパバイザと、を格納する記憶部と、前記第1、第2の仮想計算機が利用する共有IOデバイスと、を有する計算機装置であって、前記共有IOデバイスは、物理IOデバイスと、前記物理IOデバイスが制御する仮想IOデバイスと、を備え、前記第1の仮想計算機は、物理IOデバイスを制御する第1のドライバを備え、前記第2の仮想計算機は、仮想IOデバイスを制御する第2のドライバを備え、前記ハイパバイザは、前記物理IOデバイスを停止させる停止信号の前記第1のドライバによる送信を検出した場合に、前記停止信号の前記共有IOデバイスへの伝達を抑止し、前記仮想IOデバイスに対して前記第2のドライバが送信した処理要求が完了しているか否かを判定し、前記仮想IOデバイスに対して前記第2のドライバが送信した処理要求が完了したことを契機として前記物理IOデバイスの停止を行う、ことを特徴とする計算機装置。請求項1に記載の計算機装置であって、前記第1の仮想計算機から前記物理IOデバイスへの第1の接続と、前記第2の仮想計算機から前記仮想IOデバイスへの第2の接続と、を管理するルートブリッジを更に有し、前記ルートブリッジは、前記前記仮想IOデバイスに対して前記第2のドライバが送信した処理要求が所定の期間内に完了しない場合に前記計算機装置の停止処理を行う、ことを特徴とする計算機装置。請求項1に記載の計算機装置であって、前記仮想IOデバイスは、受信した処理要求を受信順序に従って実行し、前記ハイパバイザは、前記仮想IOデバイスに対して処理要求を送信し、前記ハイパバイザが前記仮想IOデバイスに対して送信した処理要求の完了を検知した場合に、前記仮想IOデバイスに対して前記第2のドライバが送信した処理要求が完了していると前記判定する、ことを特徴とする計算機装置。請求項1に記載の計算機装置であって、前記ハイパバイザは、前記第2の仮想計算機から前記仮想IOデバイスへの接続を制御する際に用いる仮想IOデバイスのアドレスを管理し、前記管理するアドレスを変更することで、前記停止信号の前記共有IOデバイスへの伝達を抑止する、ことを特徴とする計算機装置。請求項1に記載の計算機装置であって、前記ハイパバイザは、前記第1のドライバが前記停止信号を前記物理IOデバイス宛に送信して以降に前記第2のドライバが前記仮想IOデバイスに対して送信する処理要求の前記物理IOデバイスへの到達を抑止する、ことを特徴とする計算機装置。請求項1に記載の計算機装置であって、複数の前記共有IOデバイスを備え、前記ハイパバイザは、前記物理IOデバイスと、前記物理IOデバイスが制御する前記仮想IOデバイスと、を対応付けて管理し、前記停止信号の送信を検出した場合に、前記対応付けに基づいて、前記停止信号の宛先である前記物理IOデバイスに前記対応付けられた前記仮想IOデバイスを抽出し、前記抽出した前記仮想IOデバイスに対して前記第2のドライバが送信した処理要求が完了しているか否かの前記判定を行い、前記抽出した前記仮想IOデバイスに対して前記第2のドライバが送信した処理要求が完了したことを契機として前記停止信号の宛先である前記物理IOデバイスの停止を行う、ことを特徴とする計算機装置。請求項1に記載の計算機装置であって、前記仮想IOデバイスは、受信した処理要求が完了した場合に前記ハイパバイザに対して割り込みをあげ、前記ハイパバイザは、前記割り込みに基づいて、前記仮想IOデバイスに対して前記第2のドライバが送信した処理要求が完了していると前記判定する、ことを特徴とする計算機装置。請求項1に記載の計算機装置であって、前記共有IOデバイスはSRIOVに対応したデバイスであり、前記物理IOデバイスは前記SRIOVに対応したデバイスのPhysicalFunctionであり、前記仮想IOデバイスは前記SRIOVに対応したデバイスのVirtualFunctionである、ことを特徴とする計算機装置。第1の仮想計算機と、第2の仮想計算機と、前記第1、第2の仮想計算機を管理するハイパバイザと、を格納する記憶部と、前記第1、第2の仮想計算機が利用する共有IOデバイスと、を有する計算機装置の制御方法であって、前記共有IOデバイスに、物理IOデバイスと、仮想IOデバイスと、を設け、前記物理IOデバイスが前記仮想IOデバイスを制御し、前記第1の仮想計算機に、物理IOデバイスを制御する第1のドライバを設け、前記第2の仮想計算機に、仮想IOデバイスを制御する第2のドライバを設け、前記ハイパバイザが、前記第1のドライバによる前記物理IOデバイスを停止させる停止信号の送信を検出した場合に、前記リセット信号の前記共有IOデバイスへの伝達を抑止し、前記仮想IOデバイスに対して前記第2のドライバが送信した処理要求が完了しているか否かを判定し、前記仮想IOデバイスに対して前記第2のドライバが送信した処理要求が完了したことを契機として前記物理IOデバイスの停止を行う、ことを特徴とする計算機装置の制御方法。請求項9に記載の計算機装置の制御方法であって、前記計算機装置が備えるルートブリッジによって、前記第1の仮想計算機から前記物理IOデバイスへの第1の接続と、前記第2の仮想計算機から前記仮想IOデバイスへの第2の接続と、を管理し、前記ルートブリッジが、前記前記仮想IOデバイスに対して前記第2のドライバが送信した処理要求が所定の期間内に完了しない場合に前記計算機装置の停止処理を行う、ことを特徴とする計算機装置の制御方法。請求項9に記載の計算機装置の制御方法であって、前記仮想IOデバイスが、受信した処理要求を受信順序に従って実行し、前記ハイパバイザが、前記仮想IOデバイスに対して処理要求を送信し、前記ハイパバイザが前記仮想IOデバイスに対して送信した処理要求の完了を検知した場合に、前記仮想IOデバイスに対して前記第2のドライバが送信した処理要求が完了していると前記判定する、ことを特徴とする計算機装置の制御方法。請求項9に記載の計算機装置の制御方法であって、前記ハイパバイザが、前記第2の仮想計算機から前記仮想IOデバイスへの接続を制御する際に用いる仮想IOデバイスのアドレスを管理し、前記管理するアドレスを変更することで、前記停止信号の前記共有IOデバイスへの伝達を抑止する、ことを特徴とする計算機装置の制御方法。請求項9に記載の計算機装置の制御方法であって、前記ハイパバイザが、前記第1のドライバが前記停止信号を前記物理IOデバイス宛に送信して以降に前記第2のドライバが前記仮想IOデバイスに対して送信する処理要求の前記物理IOデバイスへの到達を抑止する、ことを特徴とする計算機装置の制御方法。請求項9に記載の計算機装置の制御方法であって、前記計算機装置が複数の前記共有IOデバイスを備え、前記ハイパバイザは、前記物理IOデバイスと、前記物理IOデバイスが制御する前記仮想IOデバイスと、を対応付けて管理し、前記停止信号の送信を検出した場合に、前記対応付けに基づいて、前記停止信号の宛先である前記物理IOデバイスに前記対応付けられた前記仮想IOデバイスを抽出し、前記抽出した前記仮想IOデバイスに対して前記第2のドライバが送信した処理要求が完了しているか否かの前記判定を行い、前記抽出した前記仮想IOデバイスに対して前記第2のドライバが送信した処理要求が完了したことを契機として前記停止信号の宛先である前記物理IOデバイスの停止を行う、ことを特徴とする計算機装置の制御方法。請求項9に記載の計算機装置の制御方法であって、前記共有IOデバイスはSRIOVに対応したデバイスであり、前記物理IOデバイスは前記SRIOVに対応したデバイスのPhysicalFunctionであり、前記仮想IOデバイスは前記SRIOVに対応したデバイスのVirtualFunctionである、ことを特徴とする計算機装置の制御方法。例えば上述のSRIOVデバイスのような共有機能を持った物理的なIOデバイスを利用する仮想計算機システムにおいては、一つの物理計算機上で稼働する複数の仮想計算機が一つのIOVデバイスを利用してIO処理を行う。この際に、例えば、ユーザ用の仮想計算機であるユーザ仮想計算機がIOVデバイスのVFを利用して稼働中である時に、システム管理者が利用する仮想計算機である管理用仮想計算機がメンテナンス等の為に当該IOデバイスのPFをリセット等して停止させると、当該VFを含むIOデバイス全体が停止する。あるいは、明示的にリセット等を行わない場合であっても、IOデバイスの設定変更時にデバイスの仕様によりリセットがかかり、IOデバイス全体が一時的に停止または再起動することがある。これらの場合、当該VFのIO処理は開始から完了までにタイムラグがあるため、当該IOVデバイスが接続されるRootBridgeには当該VF由来の仕掛中のIO処理が残ったままとなる。しかし、当該IOVデバイスは停止しているためVF由来の仕掛中のIO処理への応答が行えず、RootBridgeにVF由来の仕掛中のIO処理が滞留し続ける。そのため、最終的にはRootBridgeは仕掛中のIO処理のタイムアウトを検出し、システム障害と判断し当該物理計算機をダウンさせる。このように、一つのIOVデバイスを複数の仮想計算機が共有してIO処理に利用すると、PFを停止させた場合にVF由来の仕掛中のIO処理が滞留し続けることで物理計算機のダウンが発生し、仮想計算機や仮想計算機システムの信頼性が低下する恐れがあった。本発明の目的は、上記の課題を解決し、複数の仮想計算機がIOデバイスを共有しながら物理計算機上で稼働する場合に、仮想計算機が稼働する物理計算機が、VF由来の仕掛中のIO処理が滞留し続けることによりダウンすることを防止する仮想計算機、仮想計算機システム、及びそれらの制御方法を提供することにある。本願において開示される発明の代表的な一例を示せば以下の通りである。すなわち、第1の仮想計算機と、第2の仮想計算機と、前記第1、第2の仮想計算機を管理するハイパバイザと、を格納する記憶部と、前記第1、第2の仮想計算機が利用する共有IOデバイスと、を有する計算機装置を制御する際に、前記共有IOデバイスに、物理IOデバイスと、仮想IOデバイスと、を設け、前記物理IOデバイスが停止した場合に前記仮想IOデバイスは停止し、前記ハイパバイザが、前記第1の仮想計算機が送信した前記物理IOデバイスを停止させる信号を検出した場合に、前記仮想IOデバイスに対して前記第2の仮想計算機が送信した処理要求が完了したことを契機として前記物理IOデバイスの停止を行う。本発明により、複数の仮想計算機が共有して使用するIOVデバイスについて、VF由来のIO処理が全て完了した状態でPFを停止させることが出来る為、PFを停止させることに起因した物理計算機のダウンを防止し、仮想計算機や仮想計算機システムの信頼性を向上することが可能となる。以下、本発明の各種の実施例を図面に従い説明する。本実施例では最初に、本発明を実施する際の装置構成の例を示した後に、全体の概要を示し、その後詳細を解説する。図1に本実施例における物理計算機の構成を示す。b1の物理計算機内は内部に、代表部品としてb2の物理CPU、b300の物理主記憶、b40のRootBridge、b50のIOVデバイス、b6のアドレス保護機構を持ち、物理計算機の外部にはb7のコンソールが接続されている。本実施例を実施するためにはこれらの構成と同様の機能を達成するモジュールがあれば良く、例えば近年ではb40のRootBridgeやb6のアドレス保護機構がCPUと同じチップ内に実装及び販売されることがある。あるいは実装によってはアドレス保護機構の一部または全てをソフトウェアとしてHypervisorに実装してもよい。また、物理計算機内にこれらの機能ブロックを複数搭載してもよい。本実施例中ではPCIの用語を用いて解説を行うが、本発明の全体はPCIやPCIX、PCIExpressといったPCI互換のプロトコルに限定されるものではない。各部位について順に解説を行う。b2の物理CPUは内部にb21のタイマを備え、ある時刻からある時刻までの経過時間を測定すると共に、一定時間が経過したことを知ることができる。b300の物理主記憶内にはb310のユーザ仮想計算機、b320の管理用仮想計算機、b330のHypervisorが格納されている。これらの中にはCPUが実行可能な命令プログラムが記述されており、これらの命令プログラムを物理CPUが実行することで動作する。b310のユーザ仮想計算機の中には、b311仮想CPUとb312の仮想主記憶があり、物理計算機と同様に動作可能である。b312の仮想主記憶の中にはb313のVFドライバが格納されている。b313のVFドライバは、通常はb312の仮想主記憶内に格納されているb314のOSと協調動作することが多いが、必ずしもOSに頼る必要はなく、例えばb312内に格納されたBasicInputOutputSystemやExtensibleFirmwareInterface等をはじめとするファームウェアと強調動作してもよいし、あるいはb313のVFドライバ単体で動作してもよい。さらには、b312の仮想主記憶内でVirtualMachineMonitorが動作している場合には、そのVMMと協調動作してもよい。本実施例では代表的な構成である、b314のOSと協調動作する場合のみを記載するが、例えばBIOSと協調動作する場合にはb314のOSをBIOSと読み替えればよい。同様にb320の管理用仮想計算機には、b321の仮想CPUとb322の仮想主記憶があり、b310のユーザ仮想計算機と同様に動作可能である。b322の仮想主記憶にはb323のPFドライバが格納され、b324のOSと協調動作する。b310のユーザ仮想計算機やb320の管理用仮想計算機は複数あってもよく、その場合は複数のb310のユーザ仮想計算機内には別々のb311の仮想CPUやb312の仮想主記憶を、複数のb320のユーザ仮想計算機内には別々のb321の仮想CPUやb322の仮想主記憶を持つ。ただし、b313のVFドライバやb323のPFドライバは最低1つずつあれば良い。すなわちb313のVFドライバを全てのb310ユーザ仮想計算機が持っている必要はなく、同様にb323のPFドライバを全てのb320管理用仮想計算機が持っている必要は無い。b310のユーザ仮想計算機が複数ある場合には、各ユーザ仮想計算機には固有のユーザ仮想計算機IDを持つ。b320の管理用仮想計算機は、必ずしもb330のHypervisorと切り離された機能ブロックである必要はない。その場合、例えばHypervisor内にPFドライバが組み込まれる構成となる。さらに、b324のOSが存在しないこともある。b330のHypervisorは、b1の物理計算機内でb310のユーザ仮想計算機やb320の管理用仮想計算機の複数の仮想計算機を動作させる機構である。b330のHypervisorはこの実施例では物理主記憶の中に格納されているが、必ずしも物理主記憶上に格納されていなくてもよく、例えば同様の機能を持つハードウェアが物理計算機内にある構成でも構わない。b330のHypervisor内には、b331の障害処理部、b332のVF割り当て表、b333の仮想計算機スケジューラ、b334の仮想計算機スケジュール表が格納されている。b331の障害処理部の挙動については、図2以降を用いて後述する。CPUは、これらプログラムを実行し、その処理結果を主記憶に格納する。IOVデバイスb50や非IOVデバイスb53等のIOデバイスは、IO処理を行うためのデバイスであり、その例としては、ネットワーク通信を行うためのネットワークIOデバイスや、ストレージを操作するためのストレージIOデバイス、ディスプレイに出力するためのグラフィックIOデバイス等がある。これらのIOデバイスは、ディスプレイb56、ネットワークb55、外部記憶b54の機器等と接続する。ここで、IOVデバイスb50や非IOVデバイスb53等のIOデバイスが接続する機器は、ディスプレイ、ネットワーク、外部記憶に限らなくても良く、接続しない機器があっても良く、また同一の機器を複数接続していても良い。例えば、複数のIOデバイスがネットワークに接続しており、ディスプレイに接続しているIOデバイスが存在しない構成があっても良い。SRIOVデバイスのような共有機能を持った物理的なIOデバイスであるIOVデバイスb50は、少なくとも1つのb51のPhysicalFunctionと少なくとも1つのb52のVirtualFunctionを備えている。PF及びVFは、それぞれがIOデバイスとしてIO処理を行える機能ブロックである。PFは、複数のVFを管理するための機能を持っており、例えばIOVデバイスb50内のVF数を変化させたり、IOVデバイスb50内のVF設定を変更する機能を持っていることがある。PFおよびVFは、IOVデバイス内に実装された回路であっても、IOVデバイス内でソフトウェアプログラムによって実現されていてもよい。各b52のVFは、必ず1つのb51のPFに関連付けられており、b51のPFをリセットすると関連付けられているb52のVFも同時にリセットされる。b51のPFをリセットしても、リセット対象のb51のPFに関連付けられていないb52のVFはリセットされない。また、b50のIOVデバイスの種類によってはb51のPFはb52のVFを制御することも可能である。b53の非IOVデバイスは、IOVに非対応のデバイスもしくはIOVとして使用されていない通常のIOデバイスを示している。b50のIOVデバイスはこの図に示すように複数あってもよいし、あるいはひとつだけであってもよい。また、b53の非IOVデバイスも複数あってもよいし、あるいは存在しなくてもよい。非IOVデバイスは、各時刻においては単一のユーザ仮想計算機b310もしくは単一の管理用仮想計算機によってのみ操作される。例えば非IOVデバイスにネットワークが接続された場合は、ディスプレイ上には単一のユーザ仮想計算機b310もしくは単一の管理用仮想計算機のみがネットワークに接続される。IOVデバイスb50の場合は、IOVデバイス内の各PFや各VFが単一のユーザ仮想計算機b310もしくは単一の管理用仮想計算機によってのみ操作される。この構成の場合は、VF同士は異なるユーザ仮想計算機b310や管理仮想計算機によって操作されていてもよい。そのため、例えばIOVデバイスb50がネットワークに接続されている場合に、複数の管理用仮想計算機やユーザ仮想計算機b310が同時にネットワーク通信できる。ユーザ仮想計算機b310もしくは管理用仮想計算機b320は、自身が操作している非IOVデバイスb53、PF、VFに対し、IO要求を出すことによって入出力を行う。このとき、直接非IOVデバイス、PF、VFに対してIO要求を行うのではなく、物理CPUに命令プログラムを実行させる。命令プログラム中には、非IOVデバイス、PF、VFのアドレスが記入されており、物理CPUは該当アドレスにアクセスしようとする。すると、そのアクセスをアドレス保護機構b6は解釈し、ユーザ仮想計算機b310もしくは管理用仮想計算機が操作可能な非IOVデバイス、PF、VFである際にはRootBridgeに対してアクセスを転送する。この手続きについては図14を用いて後述する。アクセスを受け取ったRootBridgeは、該当する非IOVデバイス、PF、VFに対して操作を行う。この手続きについては図11を用いて後述する。b40の中にはb41の未完了操作履歴があり、ここにはデバイスに対する仕掛中のIO処理が記録されている。b7のコンソールはRootBridgeに接続され、システム管理者、ユーザ等の人間がHypervisorの起動や、VFに対する設定値を設定するためのインタフェースを提供する。一般的に物理計算機には、このコンソールに代表されるような外部出力を行う機器が搭載されている。これら図1で示した構成は、代表的な構成であるが、これらの機能を持っている構成であれば名称やブロックが違うものであってもよい。先立って、アドレス保護機構b6及びRootBridgeが持つ通信規格について解説する。この通信規格は、例えばPCIやUSBといった規格が存在する。この通信規格は、必ずしも標準化された規格に限られたものである必要はない。この通信規格を介して、物理CPUやユーザ仮想計算機、管理用仮想計算機、あるいはユーザ仮想計算機内のVFドライバや管理用仮想計算機内のPFドライバはIO要求を行うことができる。図15を用いて通信規格でのIO要求の処理概要を示す。まず、物理CPUやユーザ仮想計算機b310、管理用仮想計算機等の仮想計算機、あるいはユーザ仮想計算機内のVFドライバb313や管理用仮想計算機内のPFドライバb323等のドライバ、が通信規格にのっとった電気信号をRootBridge宛に送信することによりIO要求を発行する。このIO要求をまずアドレス保護機構b6が処理する。アドレス保護機構b6はそのIO要求が処理してもよいものであると判断すれば、手続きa910に、処理してはよくないものであると判断すれば手続きa920に進む。この手続きの詳細については図14を用いて後述する。手続きa910では、アドレス保護機構b6からRootBridgeに対してIO要求を中継し、その後に続く手続きa915ではRootBridgeがIOVデバイスb50や非IOVデバイスb53等のデバイスに対してさらにIO要求を中継する。手続きa920ではアドレス保護機構b6はRootBridgeに対してIO要求を中継しない。次に、図5を用いてアドレス保護機構b6が有するアドレス保護表b61の例について説明する。アドレス保護表b61の要素として例えば、ユーザ仮想計算機b310を識別するための識別子であるc101のユーザ仮想計算機ID、ユーザ仮想計算機b310から見たPFまたはVFの物理アドレスを意味するc102のゲスト物理アドレス範囲、ユーザ仮想計算機b310から見たPFまたはVFの物理アドレスと、物理計算機から見たPFまたはVFの物理アドレスの差分を意味するc103のOffset、ユーザ仮想計算機b310が該当するゲスト物理アドレス範囲にアクセス可能かどうかを判定するc104のアクセス可否フラグがある。アドレス保護表b61は、Hypervisorが設定することができ、Hypervisorによって仮想計算機からのIO要求を制御するものである。アドレス保護機構b6がどのように動作するかについて図14を用いて解説する。ユーザ仮想計算機b310が、RootBridgeに対してIO要求を行うことを契機として、アドレス保護機構b6の動作が開始される。アドレス保護機構b6は、ユーザ仮想計算機b310が行ったIO要求に対して、アドレス保護表b61を参照し、IO要求元の仮想計算機ID、IO要求のアドレスを調べ、のIO要求元の仮想計算機IDがc101のユーザ仮想計算機IDと等しく、かつのIO要求のアドレスがc102のゲスト物理アドレス範囲に含まれる行があるかどうかを調べる。a805にて、発見された行があり、かつその行のアクセス可否フラグが許可になっている場合には、a810の手続きを、そうでない場合にはa820の手続きを行う。例えば、図5中の例でa810に進む例としては、ユーザ仮想計算機IDが1かつIO要求のアドレスが0x020000の場合、ユーザ仮想計算機IDが1かつIO要求のアドレスが0x407000の場合、ユーザ仮想計算機IDが2かつIO要求が0x010000の場合、などがある。一方、a820の手続きに進む例としては、ユーザ仮想計算機IDが1かつIO要求のアドレスが0x800000の場合、ユーザ仮想計算機IDが3の場合、ユーザ仮想計算機IDが1かつIO要求のアドレスが0x600000の場合などがある。a810の手続きについて、説明する。アドレス保護機構b6はIO要求のアドレスに対して、c103のOffsetを足したアドレスが指し示すアドレスにアクセスする。その結果、当該アドレスをアドレス範囲に持つIOデバイスにアクセスする。例えばユーザ仮想計算機IDが1かつIO要求のアドレスが0x020000の場合は、Line1のOffsetが0x100000であるため、0x120000に対してアクセスする。別の例としてユーザ仮想計算機IDが1かつIO要求のアドレスが0x407000の場合、Line2のOffsetが0x100000であるため、0x307000にアクセスをする。さらに別の例として、ユーザ仮想計算機IDが2かつIO要求が0x010000の場合、Line4のOffsetは0x200000であるため、0x210000にアクセスする。a820の操作について説明する。手続きa805において、発見された行がなかった場合もしくは発見された行のアクセス可否フラグが拒否であった場合に、アドレス保護機構b6はHypervisorに対して例外の割り込みをあげる。このことにより、不正なIO要求を仮想計算機が行ったことをHypervisorが知ることができる。しかし、実装形態によっては割り込みをあげずにHypervisorが定期的にアドレス保護機構b6に問い合わせる、あるいは不正なIO要求をHypervisorが知らなくてもよい場合には何もしないことも許される。次に、図6に示すVF割り当て表b332について説明する。VF割り当て表には、例えば、PFを識別するための識別子であるc201のPF識別番号、VFを識別するための識別子であるc202のVF識別番号、ユーザ仮想計算機b310を識別するための識別子であるc203のユーザ仮想計算機ID、PF識別番号とVF識別番号で識別されたVFが、ユーザ仮想計算機b310によって操作される際のアドレスを意味するc204のゲスト物理アドレス範囲、PF識別番号とVF識別番号で識別されたVFがIO要求を処理するのに必要な最大時間を意味するc205の待機時間を持つ。PF識別番号とVF識別番号の組み合わせは必ず一意である。すなわち、例えばPF識別番号が1でVF識別番号が1である行が複数存在しないように構成されている。このVF割り当て表b332はHypervisorが設定できるものである。HypervisorはこのVF割り当て表b332を用い、PFやVFの関係を管理する。例えば、PFのPF識別番号が1でVF識別番号が2であるVFは、この表によるとユーザ仮想計算機IDが1のユーザ仮想計算機b310に割り当てられており、ユーザ仮想計算機IDが1のユーザ仮想計算機b310がこのVFにIO要求を出す際には0x010000から0x03ffffまでのアドレスを用いてIO要求を行う。本実施例は、障害処理部b331がVFドライバb313のアクセスを停止し、その後VFドライバb313の全てのIO処理が完了したことを確認する。この処理を説明するため、まずPCIのRootBridgeの挙動について説明する。RootBridgeの動作は大きく3つある。このそれぞれの詳細を次に述べる。ユーザ仮想計算機b310、管理用仮想計算機、HypervisorからのデバイスIO処理要求があった場合、RootBridgeは内部の未完了操作履歴b41に履歴を格納した後、IOVデバイスb50や非IOVデバイスb53等のIOデバイスに操作IDと共にIO処理の処理要求を送信する。未完了操作履歴b41の持つデータ構成の例について、図18を用いて説明する。未完了操作履歴b41は、例えば操作を一意に特定するための操作IDとその操作を行った主体を特定するための操作主体、操作を行った時刻である操作時刻を持つ2次元の表である。操作を行った主体としては、例えばユーザ仮想計算機b310や管理用仮想計算機、あるいはHypervisorがありうる。RootBridgeが未完了操作履歴b41に履歴を格納する手続きを、図19を用いて示す。図19の手続きは、Hypervisorまたは仮想計算機が出したIO要求がRootBridgeに到着することで開始される。その後手続きa2105として、RootBridgeは一意なIDとして、未完了操作履歴b41中で使用されていない操作IDを一つ決定する。その後、RootBridgeは手続きa2105で決定された操作IDと、手続きa2100で到着したIO要求の操作主体、そしてその際の時刻をそれぞれ未完了操作履歴b41内の操作ID、操作主体、捜査時刻に格納する。ここで使用された操作IDは、IOデバイスに対しても送信され、次の手続きではIOデバイスはこの操作IDと共に応答を返す。先のデバイスIO処理要求に対して、操作IDと共に応答がデバイスから返ると、その応答をユーザ仮想計算機b310、管理用仮想計算機b320、Hypervisorb330へ中継する。またこの際、その応答に対応するIO処理を未完了操作履歴b41から探し、削除する。より詳細に述べると、RootBridgeは未完了操作履歴b41から操作IDが該当する行を読み出し、該当行に記録されている操作主体に対して応答を中継する。さらに、中継すると共に、該当行を削除する。このRootBridgeのの動作は、例えば図11のように説明される。まず、デバイスドライバがデバイスに対してIO要求を発行する場合、このIO要求はRootBridgeが受け取る。RootBridgeは、このIO要求が未完了操作履歴b41に記録される類の操作であるかどうかを判定する。未完了操作履歴b41に記録する操作であった場合には、RootBridgeはこのIO要求を未完了操作履歴b41に記録する。その後RootBridgeはIO要求をデバイスに対して中継する。手続きa1010で中継されたIO要求を、デバイスは処理し、処理の完了をもって完了をRootBridgeに通知する。通知を受けたRootBridgeはa1005で記録された未完了操作履歴b41内にある、a1005のIO要求を削除する。一方、操作時刻から一定時間たっても未完了操作履歴b41から削除されないIO処理があった場合、デバイスにエラーが発生したと判定し、安全のため物理計算機をダウンさせる。これには、デバイスにエラーが発生すると、主記憶をはじめとするシステム全体をデバイスが破壊し続ける可能性があるためで、その破壊を食い止めるために物理計算機をダウンさせる。この動作によって、デバイスの障害を発見し、物理計算機を停止する契機とすることができる。ここで、物理計算機を停止される契機としての当該障害発見についての正当性を、図12を用いて説明する。図12は、デバイスによるIO要求の処理中に、デバイスに障害が発生した場合のRootBridgeの動作を示すフロー図である。手続きa1000、a1005、a1010、a1015については図11と差異がないため、説明を省略する。手続きa1100で障害が発生した場合、図11においては行われたRootBridgeに対する完了報告が行われないまま、一定時間が経過する。これにより、手続きa1110において、未完了操作履歴b41に対する完了が書かれていないため、完了報告が無いと判定して物理計算機を停止する。図12はデバイスによるIO要求の処理中に、デバイスに障害が発生した場合を想定したが、IO要求の発行前に障害があった場合においても、図11においては行われたRootBridgeに対する完了報告が行われないまま、一定時間が経過するため、同様の動作となる。これにより、IOデバイスの障害をRootBridgeが検知することができ、IOデバイスによる物理計算機への破壊を食い止めることが可能である。次に、図13を用いて、IOVデバイスb50においてVFドライバb313によるIO処理の直後にPFドライバb323によるPFリセットを同時に行った場合のRootBridgeの挙動を説明する。ここでは、VFドライバb313がVFに対してIO処理を行い、デバイスから応答が返る前にPFドライバb323がPFをリセットした場合のRootBridgeの挙動を記述する。VFドライバb313がVFに対するIO処理を行うと、のデバイスIO処理要求が発生し、RootBridge内の未完了IO処理履歴に履歴が残る。ここで、デバイスからの応答前にPFをリセットすると、同時にVFもリセットされるため、のデバイスからの応答が返ってくることはなくなる。したがって、一定時間後にRootBridgeはのエラー判定を行い、物理計算機をダウンさせる。図13中の手続きa1200、a1205、a1210、a1215は、図11及び図12中のa1000、a1005、a1010、a1015とほぼ同等であるが、IOVデバイスb50内のVFに対してIO要求を行っている点のみが異なるため、改めて解説する。手続きa1200では、VFドライバb313がIOVデバイスb50内のVFに対してIO要求を行う際に、RootBridgeに対してIO要求を出す。このIO要求をRootBridgeが受け取り、未完了操作履歴b41に記録する。その後手続きa1210では、RootBridgeはIOVデバイスb50内のVFに対して中継する。IOVデバイスb50内のVFは、a1210で中継されたIO要求を実行するが、その最中にPFドライバb323がIOVデバイスb50に対してリセットを発行すると、PFとVFがともにリセットされる。このとき、VFが処理中であったa1200のIO要求についてもリセットに伴い廃棄される。すると、図12中でデバイスに障害が発生した場合と同様に、一定時間が経過し、a1200のIO要求に対する完了報告をVFから受信していないことを理由にRootBridgeは物理計算機を停止させる。図13では物理計算機がダウンしたが、実際にはデバイス不良でないため、物理計算機への破壊が行われることはなく、本来は物理計算機をダウンさせる必要はない。そこで本実施例においては、このダウンを防ぐために、障害処理部b331が後続のVFドライバb313のアクセスを停止し、その後VFドライバb313の全てのIO処理が完了したことを確認、そして最後にIOVデバイスb50をリセットする。この手続きについて、図2を用いて説明する。図2はb311の障害処理部b331が行う手続きについて記載したフローチャートの例である。物理計算機のダウンを防ぐためには、PFドライバb323が発行するリセット時に、全てのVFドライバb313によるIO要求への応答が完了していれば良い。そのため、PFドライバb323が発行したリセットを障害処理部b331が検知したことを契機として動作する。この手続きにはいくつかの方法があるが、代表的なものとしてはアドレス保護表b61中の、リセットを行うアドレスへのアクセス可否を拒否に設定しておき、該当アドレスにアクセスがあった場合にはHypervisorが処理を行うなどの方法がある。リセットを行うアドレスについては、多くの場合は通信規格によって定められているため、HypervisorはPFドライバやVFドライバのようなデバイス固有の仕様を持ったソフトウェアを用いなくともリセットが検知できる。ただし、デバイス固有のリセット仕様をHypervisorが知っている場合には、そのデバイス固有のリセットを検知してもよい。本検知後に、障害処理部b331はVF割り当て表b332を用いてリセット対象のPFと同一IOVデバイス内のVFを列挙する。すなわち、図6のVF割り当て表b332中で、PF識別番号がリセット対象のPFの識別番号と同一の行を全て選択し、それらの行の中のVF識別番号を全て記録する。この手続きによって列挙されるVFは、例えば、図6のようなVF割り当て表b332であり、かつ手続きa100でリセットを行う対象であったPFのPF識別番号が1であれば、VF識別番号が1及び2のVFである。また、手続きa100でリセットを行う対象であったPFのPF識別番号が2であれば、VF識別番号が3及び4のVFである。手続きa102が完了すると、VFドライバb313による後続のIO要求を停止する。次に手続きa105でIO要求を停止する以前に行われた、全てのIO要求への応答が完了したことを確認する。さらにHypervisorが改めてPFをリセットする。リセット手続きについては、多くの場合は通信規格によって定められているため、PFドライバb323やVFドライバb313を介さずに行うことが可能である。ただし、デバイス固有のリセット仕様をHypervisorが知っている場合には、そのデバイス固有のリセットを発行してもよい。さらには、Hypervisorは管理用仮想計算機に対して、改めてリセット発行を頼む等してもよい。この際にはHypervisorはアドレス保護表b61を書き換える等の方法で、リセットを許可する。手続きa105、手続きa110、手続きa115をこの順で実行することが重要であり、例えば仮に手続き110がなかった場合、VFドライバb313によるIO要求が仕掛中であり、その間にa115のリセットを発行すると物理計算機のダウンにつながる。そのため、本手続きをこの順で実行することが本発明の効果を得ることが可能となる。さらに、本実施例では図3を用いて図2中の手続きa105の詳細を示す。図3は手続きa105に示したVFドライバb313による後続のIO要求を停止する手続きとして、b6のアドレス保護機構b6を用いる例である。図3は図1と比較すると手続きa105が手続きa200に変更されただけであるため、手続きa200のみについて説明する。手続きa102でリストアップされたVFのそれぞれについて、図6のVF割り当て表を用いて説明したc204のゲスト物理アドレス範囲を元に、アドレス保護機構b6内のc102ゲスト物理アドレス範囲を抽出する。この際、図6のVF割り当て表を参照する。例えば、VF識別番号が1のVFが抽出された場合、そのゲスト物理アドレスは0x0100000x03ffffである。このゲスト物理アドレスに該当するゲスト物理アドレスと、VF識別番号1のVFが割り当てられているユーザ仮想計算機IDが1のユーザ仮想計算機b310から、アドレス保護機構b6内の表のLine1が該当すると判定する。この場合、図5においてアドレス保護機構b6のLine1のアクセス可否フラグc104を拒否に設定することで、VFドライバb313による後続のIO要求を停止する。このように後続のIO要求を遮断し、新たにVFがIO要求を受け付けることを防止することによって、a110の確認に要する時間を最小限に抑えることが可能になるとともに、図4や図20を用いて後述する完了順序が保証されるIO要求を用いた完了確認を適正に開始することが可能となる。アクセス可否フラグによる拒否の方法としては、大きく2種類の方法が存在する。アドレス保護機構b6が該当アドレスへのアクセスを拒否できる場合、その機能を有効にする。この場合は単純にアクセス可否フラグを拒否に設定するだけでよい。そうでない場合には、アドレス変換後のアドレスが、無効なアドレスになるように設定する。例えば、物理計算機が使用しているアドレスが0x00xafffffffであれば、0xb00000000xffffffffのアドレスは無効であり、このアドレスに変換すれば実質的に無効化される。このようにアドレス保護機構b6や、アドレス保護機構b6が管理するアドレスを制御変更することで、IO要求の完了未完了を管理するRootBridgeにIO要求が到達することを防ぐことができる。手続きa200の後、b311の仮想CPUに対して仮想的に割り込みをあげ、VFが使用不可能となったことをユーザ仮想計算機b310に知らせてもよい。例えば、RootBridgeに対してb314のOSが割り込み番号を設定していた場合には、その割り込み番号を用いてb311の仮想CPUに対して仮想的な割り込みをあげることで、b314のOSに通知を行う。その他、システム由来の割り込み番号を用いて通知を行ってもよいし、OSが自動認識するのであれば特に通知を行わなくてもよい。これらの手続きにより、VFドライバb313による後続のIO要求が停止する。図4を用いて、手続きa110のVFドライバb313のIO処理完了を確認する具体的手続きについて説明する。図4は図2中のa110の手続きを手続きa300、a305で置き換えたものであり、その他の部分は図2と同じであるため、手続きa300とa305のみについて説明する。それに先立ち、完了順序が保証されるIO要求について説明する。完了順序が保証されるIO要求とは例えば、PCI互換のプロトコルのPCIConfigurationspaceに対するreadwriteリクエスト、MemoryMappedIOに対するreadリクエスト等は、NonPostedリクエストと呼ばれ、実行を行った順で完了されるという特徴がある。これらのNonPostedアクセスをIO要求として用い、IO要求の完了を待つと、そのIO要求以前に行われた全てのNonPostedリクエストは、完了したことが保証されている。図20を用いてその具体例を説明する。図20は、上述のような完了順序が保証されるIO要求のVFでの受信、処理完了のフローの一例を示している。この例では、IO要求P1IO要求P2IO要求P3IO要求P4IO要求P5がこの順でVFドライバb313やHypervisor等から発行されていることを前提とする。まず、手続きa2200において、VFはIO要求P1を受信する。次に、手続きa2201において、VFはIO要求P2を受信する。次に、手続きa2202において、VFは手続きa2200で受信したIO要求P1の処理を行ってIO要求P1を処理完了する。次に、手続きa2203において、VFはIO要求P3を受信する。次に、手続きa2204において、VFはIO要求P4を受信する。次に、手続きa2205において、VFは手続きa2201で受信したIO要求P2の処理を行ってIO要求P2を処理完了する。次に、手続きa2206において、VFは手続きa2203で受信したIO要求P3の処理を行ってIO要求P3を処理完了する。次に、手続きa2207において、VFはIO要求P5を受信する。次に、手続きa2208において、VFは手続きa2204で受信したIO要求P4の処理を行ってIO要求P4を処理完了する。次に、手続きa2209において、VFは手続きa2207で受信したIO要求P5の処理を行ってIO要求P5を処理完了する。このように、VFでは一つのIO要求の完了を待たずに、次のIO要求を受信することは可能であるが、完了順序はIO要求の受信順序と同様にP1P2P3P4P5である。このように完了順序が保証されるIO要求を用いると、例えばP5のIO要求の完了を観測すれば、P5に先立って行われたIO要求であるP1P2P3P4のIO要求についても完了が保証されることになる。図4に戻って、この完了順序が保証されるIO要求を用いた手続きである、手続き300305について解説する。すでに図2で示したa105の手続きが完了した上で、障害処理部b331はそれぞれのVFに対して上述のような完了順序が保証されるIO要求を行う。そして、a300のIO要求の完了を確認することで、a300のIO要求の発行以前にa102で列挙されたVFが受信していたNonPostedのIO要求が全て完了したことを確認する。例えば、a300のIO要求としてPCIの中のNonPostedの要求の一つであるPCIConfigurationreadを用いた場合であれば、Hypervisorが値を読み終えたことを持って、a300以前に発行されたNonPostedなIO要求の完了を判断できる。また、例えばPCIであれば、NonPostedリクエストでないリクエストは、未完了操作履歴b41に格納されない特性があるため、例え完了していないとしても物理計算機のダウンにはつながらない。例えば、Hypervisorの障害処理部b331が図3の手続きa200でアクセス可否フラグを拒否に設定するまでに発行されたIO要求P1IO要求P2IO要求P3IO要求P4をa102で列挙したVFが受信していた場合、手続きa300において障害処理部b331が、IO要求P5を当該VFに対して発行し、手続きa305において障害処理部b331がa2209のIO要求P5の処理完了を確認することで、当該VFがa200でアクセス可否フラグを拒否に設定するまでに発行されたIO要求P1IO要求P2IO要求P3IO要求P4の処理を完了していることを確認することができる。以上、実施例1について説明した物理計算機、仮想計算機、仮想計算機システムの構成動作によって、複数の仮想計算機がIOデバイスを共有しながら物理計算機上で稼働する場合に、仮想計算機が稼働する物理計算機がVF由来の仕掛中のIO処理が滞留し続けることによりダウンすることを防止することが可能である。また、手続きa102においてリセットの発行されたPFに対応するVFのみを列挙し、手続きa300及びa305においては列挙されたVFのみに対してIO要求を発行し、完了を確認することにより、リセットの影響するVFのみを選択的に停止することが出来、停止する必要のないIOVデバイスや、IOVに非対応のデバイスについては停止させないことが可能となる。さらに、本実施例の場合、例えばSRIOV規格に準拠したIOVデバイスとそのドライバがあれば装置を実現できる。実施例2では、実施例1と異なり、図2の手続きa102及びa105の異なる実現方式について、図7を用いて説明する。それに先立ち、図16及び図17を用いて、仮想計算機のスケジューリングについて解説を行う。まず図17を用いてHypervisorが持つ仮想計算機スケジュール表b334の例について解説する。仮想計算機スケジュール表b334は、各ユーザ仮想計算機b310が物理計算機上でどの程度動作するか、を保持している表である。仮想計算機スケジュール表b334は例えば、c301のユーザ仮想計算機ID、c302の連続走行時間、c303の実行可否フラグ、c304の実行状態を持つ。各仮想計算機は、実行可否フラグが可の場合のみ、連続走行時間分だけ実行状態となる。例えば図17に示した仮想計算機スケジュール表b334の場合は、ユーザ仮想計算機1が10msec、ユーザ仮想計算機2が10msec、ユーザ仮想計算機3が5msec、ユーザ仮想計算機1が10msec、ユーザ仮想計算機2が10msec、ユーザ仮想計算機3が5msecというように、ユーザ仮想計算機123の3つが順に動作する。ユーザ仮想計算機4は、実行可否フラグが不可のため動作しない。次にこれを実現するためのプログラムである、仮想計算機スケジューラb333の動作について図16を用いて解説する。図16を用いてHypervisor内の仮想計算機スケジューラb333が行う動作について説明する。まずHypervisorは、手続きa2000として仮想計算機スケジュール表b334の中の全ての実行状態を中断とする。次にa2005として、仮想計算機スケジュール表b334の中で実行可否フラグが可である行を一行選択し、実行状態を実行中とする。この際に選択する行は実行可否フラグが可であればどれでもよく、例えば一番上にある行や一番下にある行、あるいはランダムで選択した行等を用いる。その後手続きa2010として、実行状態が実行中となっている行の連続走行時間だけCPU内のタイマb21を設定する。手続きa2005の直後に手続きa2010が行われている際には、手続きa2005で選択された行の連続走行時間が用いられるが、後述するa2040が実行された直後に手続きa2010が実行されている際には手続きa2040で選択された行の連続走行時間が用いられる。次に手続きa2015として、実行状態が実行中となっている行の仮想計算機を動作させる。その後手続きa2020では、手続きa2010で設定したタイマb21が完了したことを契機として、手続きa2025に進む。なお、タイマb21が完了したことを監視するには、例えば定期的にCPU内のタイマb21を監視しておく方法、タイマb21の機能としてタイマb21が完了した際に割り込みを挙げる仕組みを持っている場合には、その割り込みを設定する方法等がある。手続きa2025では、実行状態が実行中となっている行の実行状態を中断とする。その後手続きa2030で、次の行へ移動する。手続きa2035では、手続きa2030で見ることになった行の実行可否フラグが可であるかどうかを判定する。仮に、不可であった場合には再度手続きa2035に戻り、次々と先の行へ移動する。これを、実行可否フラグが可の行を発見するまで続ける。手続きa2035で実行可否フラグが可となっている行を見つけた場合、手続きa1040として該当行の実行状態を実行中とし、手続きa2010に移動する。このように、実行可否フラグが可となっているユーザ仮装計算機のみを順に稼動させることにより、実行可否フラグが不可となっている行に記載されているユーザ仮想計算機b310には処理が移さないことが可能になる。図7は、図1と比較するとa102、a105の手続きの代わりにa500、a510の手続きを用いている点と、a115の手続き後にa525の手続きが行われる点が異なるだけであるため、この3つの手続きのみについて説明する。手続きa500について説明を行う。本実施例においては、障害処理部b331は、図2の手続き100でPFのリセットを検知すると、VF割り当て表b332からリセット対象のPFと同一IOVデバイスb50内のVFを使用している仮想計算機を列挙する。例えば障害処理部b331は、図6のVF割り当て表を参照し、リセット対象のPFのPF識別番号が1であった場合は、Line1とLine2が該当する。この場合、ユーザ仮想計算機IDは1のみであるため、列挙される仮想計算機は仮想計算機IDが1の仮想計算機だけである。一方、リセット対象のPFのPF識別番号が2であった場合は、Line3とLine4が該当する。この場合、ユーザ仮想計算機IDは1と2の二つがあるため、列挙される仮想計算機は仮想計算機IDが1の仮想計算機と仮想計算機IDが2の仮想計算機である。次に手続きa510においては、列挙された仮想計算機が使用している仮想CPUの動作を止める。Hypervisorの具体的な動作としては例えば仮想計算機を動作させるためのスケジューラのスケジューリングから、列挙された仮想計算機をはずす、などの方法がある。例えば前述した図17の仮想計算機スケジュール表b334を用いている場合であれば、列挙された仮想計算機の実行可否フラグを全て不可とすればよい。既に述べたように、実行可否フラグが不可であれば、スケジューリングからはずれ、実行中とならなくなる。最後に手続きa525について説明する。手続きa510で停止させたユーザ仮想計算機の仮想CPUを、再開させる。この手続きとしては、a510で行った処理の逆を行えばよく、例えば仮想計算機を動作させるためのスケジューラのスケジューリングから仮想計算機をはずした場合、その仮想計算機を再度スケジューリングに追加する。この手続きは、例えば列挙された仮想計算機の実行可否フラグを可とすればよい。実施例2について説明した物理計算機、仮想計算機、仮想計算機システムの構成動作によって、Hypervisorがユーザ仮想計算機b310のスケジューリングを行っている仮想計算機システムであれば適用でき、例えばアドレス保護機構b6を持っていないシステムにおいても物理計算機のダウンを避けることが可能となる。第3の実施例では、第1の実施例と異なり、図2の手続きa110の異なる実現方式について図8を用いて説明する。本実施例はIOVデバイスの中でも特殊な構成を持つデバイスを前提とした手法である。図8は、a110の代わりに手続きa600、a605、a610、a615、a620、a625、a630が増えている点が図1と異なるため、手続きとしてはこの新たに加わったこれらの手続きについてのみ説明を行う。まず、特殊なIOVデバイスの構成について、図21を用いて解説する。IOVデバイスb50内のVFには、IO要求完了割り込み番号記録領域b54を持つ。VFのIO要求完了割り込み番号記録領域b54に割り込み番号を設定すると、その割り込み番号を用いて適切なタイミングで仮想計算機やHypervisorに割り込みがあげる。このIO要求完了割り込み番号記録領域に割り込み番号を設定した場合の適切なタイミングとは、各VFに対するIO要求が完了した際である。次に、図8を用いて障害処理部b331による手続きについて解説する。手続きa600では、手続きa105で列挙した全てのVFに対し、まずIO要求が完了した際にHypervisorに対してあげる割り込みを設定する。すなわち、IO要求完了割り込み記録領域に、割り込み番号を設定する。こうすることで、列挙したそれぞれのVFへのIO要求が完了した時点でHypervisorに割り込みがあがる。次に手続きa605でカウンタをVF数に設定する。これは、全てのVFについて割り込みがあがったことを確認するために用意する。手続きa610では、手続きa600で設定した割り込みが届くのを待ち、a620で割り込みを受信する。割り込みを受信すると、a625で先に設定したカウンタの値を一つ減らす。手続きa630では、a620で受け取った割り込みでa600で設定した割り込みが全て届いたかどうかを確認するため、カウンタの値が0かどうかをチェックする。カウンタの値が0であれば、全ての割り込みが届いていると判断して手続きa115へ、そうでなければ手続きa610へ戻る。例えば、a600で10個のVFに対して割り込みを設定した場合には、a630では9回NOに進んだ後、10回目でYESに進む。実施例3について説明した物理計算機、仮想計算機、仮想計算機システムの構成動作によって、PCIのような特定の通信規格を用いなくとも、デバイスが特殊な割り込みに対応するだけで実現できる点が有益である。以上で実施例3の説明を終える。第4の実施例では、第1または第3の実施例と異なり、図2の手続きa110の異なる実現方式について図9を用いて説明する。そのため、a110に代わる手続きである、a715のみについて詳細に説明を行う。a715では、a102でリストアップされたVFにおいて、VF割り当て表b332を参照し、VF割り当て表b332からリセット対象であったPFに対応する待機時間c205を取得し、その最大値分だけ待つ。例えば、図6に示したVF割り当て表b332の場合について説明する。a100でリセット対象であったPFのPF識別番号が1の場合には、Line1とLine2が該当し、その二つの行の待機時間の最大値分待つ。すなわちこの場合は10msecである。A100でリセット対象であったPFのPF識別番号が2の場合には、Line3とLine4が該当するが、この場合には100msec待つ。この待つ時間については、最低でもその時間だけ待てばよく、それ以上の時間待ってもよい。VF割り当て表内の待機時間を設定するためのユーザインタフェースの例として、例えば図10に示すコンソール画面を用いる方法がある。このコンソールには、VF割り当て表内のPF識別番号とVF識別番号が出力され、VF割り当て表の待機時間のみを更新することができる。ここでは、PF識別番号とVF識別番号を用いたが、VFごとに値を設定できるのであれば別の値を用いてもよい。また、PF単位で待機次官を設定するインタフェースにしてもよい。ユーザは、デバイスの仕様や経験等から適切な値を入力することが可能である。どの程度待てばよいかどうかはデバイスや物理計算機などの構成に大きく依存するが、例えば1秒程度待てば十分に全てのIO処理が完了したとみなせる、などとユーザは判断する。実施例4について説明した物理計算機、仮想計算機、仮想計算機システムの構成動作によって、PCIのような特定の通信規格を用いなくともよいし、実施例3のようにデバイスが対応する必要すらなく、ユーザが値を指定するだけで障害処理部を動作させることが可能となる。