JP5716830B2 - 情報処理装置及び方法、プログラム - Google Patents

Description

本技術は、仮想化環境におけるハードウェアリソースの管理技術に関する。

コンピュータに電源が投入されると、ＯＳ（Operating System）が起動する前にＰＯＳＴ（Power On Self Test）が行われ、例えばプロセッサやメモリといったハードウェアの診断が行われる。ＰＯＳＴは、ハードウェアの診断に関する特別な権限を有するファームウェアにより、ハードウェアを占有して行われる診断であるため、ハードウェアの診断を詳細に行うことができる。これに対し、ＯＳの起動後ＯＳによって行われるハードウェア診断は、ハードウェアへのアクセスの制限等のため、診断の内容が限定されている。また、もしシステムの稼働中にＯＳによって無理にハードウェア診断を行うと、ＯＳが正常に動作しなくなることがある。

従来、ハードウェアの診断に関して、以下のような従来技術が存在する。具体的には、サービスプロセッサが、待機中である予備プロセッサに対して故障診断を行う。そして、故障診断の結果が正常である場合に、ＯＳが、稼働中の運用プロセッサをコンピュータシステムから切り離して待機させると共に、故障診断が行われた予備プロセッサを、コンピュータシステムに組み込んで稼働させるようにする。しかし、この技術では、サービスプロセッサを搭載しているシステム（サブシステム）がダウンした場合、稼働中のシステム（メインシステム）に搭載されている運用プロセッサに対しては、診断を行うことができなくなる。近年では、部品数が増えたこと等に伴って、サブシステムにおける故障の発生率が増加する傾向にあるため、このような技術では問題がある。

また、装置の動作検証に関して、以下のような技術が存在する。具体的には、仮想計算機制御部が、仮想計算機の創成、削除、中断及び再開の試験を行う。また、仮想計算機が共有する共有装置の情報を仮想計算機制御部が保持することにより、各仮想計算機が共有装置の共有状態を確認しながら動作検証を行えるようにする。しかし、このような技術では、各仮想計算機に割り当てられているハードウェアについては診断を行うことができない。

特開２００６−２５２４２９号公報 特開平８−３０５５９６号公報

従って、本技術の目的は、一側面において、システムの稼働中に適切なハードウェア診断を行えるようにするための技術を提供することである。

本技術の一側面に係る情報処理装置は、メモリと、オペレーティングシステムを実行し、計算機として所定の機能を提供する論理ドメインと、論理ドメインの管理を行うハイパバイザとの処理を実行する処理装置とを有する。そして、上記オペレーティングシステムが、診断を行うべきハードウェアを検出する検出モジュールと、検出モジュールにより診断を行うべきハードウェアが検出された場合、診断のための処理においてオペレーティングシステムが利用する、メモリにおけるメモリ領域を確保し、オペレーティングシステムのカーネルに対して、当該メモリ領域で発生したエラーを看過するように指示する第１指示モジュールと、検出モジュールにより診断を行うべきハードウェアが検出された場合、ハイパバイザに対して、診断において利用する、メモリにおけるメモリ領域で発生したエラーを看過するように指示し且つ診断を行うべきハードウェアの指定を含む診断要求を出力する第２指示モジュールとを有する。そして、上記ハイパバイザが、診断要求を受信した場合、診断を行うべきハードウェアに対して診断を行う診断モジュールと、診断要求を受信した場合、診断モジュールが診断において利用する、メモリにおけるメモリ領域で発生したエラーを看過するための設定を行う設定モジュールとを有する。

図１は、ハードウェアリソースの診断を行う際の問題点を説明するための図である。 図２は、ハードウェアリソースの診断を行う際の問題点を説明するための図である。 図３Ａは、第１の実施の形態における情報処理装置のハードウェア構成を示す図である。 図３Ｂは、第１の実施の形態におけるメインシステムの構成を示す図である。 図４は、第１の実施の形態に係る診断定義テーブルに格納されているデータの一例を示す図である。 図５は、管理テーブルに格納されているデータの一例を示す図である。 図６は、割当テーブルに格納されているデータの一例を示す図である。 図７は、第１の実施の形態におけるメインの処理フローを示す図である。 図８は、第１の実施の形態におけるメインの処理フローを示す図である。 図９は、第１の実施の形態における診断処理の処理フローを示す図である。 図１０は、第１の実施の形態に係るハードウェアリソースの診断方法の概要を示す図である。 図１１は、第２の実施の形態に係る診断定義テーブルに格納されているデータの一例を示す図である。 図１２は、第２の実施の形態におけるメインの処理フローを示す図である。 図１３は、第２の実施の形態における診断処理の処理フローを示す図である。 図１４は、管理テーブルに格納されているデータの一例を示す図である。

例えば図１に示すような情報処理装置においてハードウェアリソースの診断を行うことを考える。図１の情報処理装置は、メインシステムと、サブシステムとを含む。ここで、メインシステムは業務処理を実行するためのシステムであり、メインシステムは論理ドメイン１、論理ドメイン２及び各論理ドメインの管理を行うハイパバイザ等のプログラムを含む。メインシステムに含まれる各プログラムは、ハードウェアリソースに含まれるプロセッサにより実行される。サブシステムは、メインシステムを運用及び管理するためのシステムである。ＰＯＳＴ実行モジュールは、ＰＯＳＴを実行するためのソフトウェアである。ハイパバイザ（hypervisor）は、論理ドメインを起動するためのファームウェアである。オープンファームウェア（オープンブートとも呼ばれる）は、ＯＳを起動するためのソフトウェアである。

このような情報処理装置におけるハードウェアリソースの診断は、例えば図２に示すようにして行われる。具体的には、まず情報処理装置に電源を投入すると、サブシステムが起動し、当該サブシステムからメインシステムの起動指示が出される。そして、メインシステムが起動を開始し、ＰＯＳＴ実行モジュールによるハードウェアリソースの診断（ＰＯＳＴ）が行われる。

なお、ＰＯＳＴが行われると、ハイパバイザが起動し、当該ハイパバイザが論理ドメインを起動する。すると、オープンファームウェアがＯＳ起動の前処理を開始し、さらにＯＳを起動する。そして、論理ドメインの起動が完了し、論理ドメインにおいて業務処理が行われる。

ここで、論理ドメインの稼動中に、論理ドメインをリセットする旨の指示がユーザからあった場合には、指示に係る論理ドメインのみが再起動される。ところが、論理ドメインをリセットしただけでは、メインシステム自体がリセットされるわけではないため、ＰＯＳＴが行われない。そこで、ＰＯＳＴを行うためにメインシステムを再起動することが考えられるが、このようにすると全ての論理ドメインを再起動することになる。

しかし、各論理ドメインでは別々の業務処理が行われているため、複数の論理ドメインを同時に再起動することができるようなタイミングは限られてしまうことが多い。そのため、実際にはメインシステムの再起動をすることができず、ハードウェアリソースの故障の検出が遅れてしまうことがある。

そこで、以下システム稼働中にも適切にハードウェアの診断を行う２つの実施の形態を具体的に説明する。

［実施の形態１］
本実施の形態における情報処理装置１０００のハードウェア構成を図３Ａに示す。図３Ａの例では、情報処理装置１０００は、ハードウェアリソース１を有し、ハードウェアリソース１により、業務処理を実行するためのメインシステムと、メインシステムを運用及び管理するためのサブシステムとを実行する。ハードウェアリソース１は、例えばプロセッサ、メモリ、ＰＣＩ（Peripheral Component Interconnect）等のハードウェアリソースを含む。各ハードウェアリソースの数は１又は複数であるが、診断が行われるハードウェアリソースについては、数は２以上である。なお、サブシステムは、本実施の形態における主要な処理を行うわけではないので、サブシステムについての詳細な説明は省略する。

図３Ｂに、メインシステムの構成を示す。メインシステムは、論理ドメイン１１と、論理ドメイン１２と、ハイパバイザ１３と、ＰＯＳＴ実行モジュール１４とを含む。論理ドメイン１１及び１２は、ハイパバイザ１３により仮想的に実現されたシステムである。

論理ドメイン１１は、オープンファームウェア１１０１と、ＯＳ１１０２とを含む。また、ＯＳ１１０２は、カーネル１１０３と、管理モジュール１１０４と、診断定義テーブル１１０９と、管理テーブル１１１０と、割当テーブル１１１１とを含む。また、管理モジュール１１０４は、検出モジュール１１０５と、第１指示モジュール１１０６と、第２指示モジュール１１０７と、通知モジュール１１０８とを含む。

なお、オープンファームウェア１１０１、ＯＳ１１０２、カーネル１１０３及び各モジュールは、例えばハードウェアリソース１に含まれるプロセッサに実行されると、以下で説明する機能を実現する。

オープンファームウェア１１０１は、ＯＳ１１０２を起動するための処理を行う。カーネル１１０３は、例えば情報処理装置１０００におけるリソースの管理やプロセス間通信の提供等、一般的なＯＳのカーネルが行う周知の処理を行う。検出モジュール１１０５は、診断定義テーブル１１０９及び管理テーブル１１１０に格納されているデータを用いて、診断を行うべきハードウェアリソースを検出する処理を行う。第１指示モジュール１１０６は、カーネル１１０３に対して後述のマスク指示を出力する処理等を行う。第２指示モジュール１１０７は、ハイパバイザ１３に対して後述のマスク指示を出力する処理等を行う。通知モジュール１１０８は、ハードウェアリソースの異常をユーザ（例えば情報処理装置１０００の管理者）に提示するための処理等を行う。

論理ドメイン１２は、オープンファームウェア１２１と、カーネル１２３を含むＯＳ１２２とを含む。これらの機能は、論理ドメイン１１におけるオープンファームウェア１１０１及びＯＳ１１０２の機能と同じであるので、説明を省略する。

なお、図３Ｂでは論理ドメインを２つ示しているが、論理ドメインの数に限定は無い。また、本実施の形態では、論理ドメイン１１と同様の機能を有する論理ドメインは他には無いとする。すなわち、論理ドメイン１１において一元的に診断を管理している。

ハイパバイザ１３は、設定モジュール１３１及び診断モジュール１３２を含む管理モジュール１３０と、割当テーブル１３３とを含む。ハイパバイザ１３及び当該ハイパバイザ１３に含まれる各モジュールは、例えばハードウェアリソース１に含まれるプロセッサに実行されると、以下で説明する機能を実現する。

設定モジュール１３１は、所定のメモリ領域で発生したエラーをハイパバイザ１３が看過するための設定等を行う。診断モジュール１３２は、ハードウェアリソースの故障を検出するための診断を行う。

図４に、診断定義テーブル１１０９に格納されているデータの一例を示す。図４の例では、診断を実施するか否かを指定するためのデータと、診断対象を指定するためのデータと、診断間隔を指定するためのデータとが格納されている。これらのデータは、情報処理装置１０００のユーザによって指定されたデータである。

図５に、管理テーブル１１１０に格納されているデータの一例を示す。図５の例では、ハードウェアリソースに付与された番号と、ハードウェアリソース名と、最終診断時刻のデータと、診断結果と、追加診断をするか否かを示すデータとが格納されるようになっている。ハードウェアリソースが正常であれば診断結果は「ＯＫ」となり、ハードウェアリソースが故障していれば診断結果が「ＮＧ」となる。また、再度診断を行うべきであれば追加診断は「ＯＫ」となり、再度診断を行うべきでなければ追加診断は「ＮＧ」となる。

図６に、割当テーブル１１１１に格納されているデータの一例を示す。図６の例では、割り当て先の情報と、ハードウェアリソース名とが格納されるようになっている。割当テーブルは、情報処理装置１０００が有するハードウェアリソースの割り当てを管理するためのテーブルであり、割り当てが変更された場合には内容が更新される。なお、割当テーブル１３３にも、割当テーブル１１１１と同じデータが格納されている。

次に、第１の実施の形態における情報処理装置１０００の処理内容について説明する。まず、論理ドメイン１１における検出モジュール１１０５は、診断を行うべきハードウェアリソース（以下、対象リソースと呼ぶ）を検出する（図７：ステップＳ１）。ステップＳ１においては、管理テーブル１１１０に格納されている最終診断時刻のデータと、診断定義テーブル１１０９に格納されている診断間隔のデータとを用いて、最後に診断を行ってから所定時間以上診断が行われていないハードウェアリソースを検出する。但し、追加診断の欄に「ＮＧ」が格納されているハードウェアリソースは検出されない。

そして、第１指示モジュール１１０６は、対象リソースに対する診断のための処理においてＯＳ１１０２が利用するメモリ領域を確保する（ステップＳ３）。そして、第１指示モジュール１１０６は、ステップＳ３において確保されたメモリ領域のアドレス及びステップＳ１において検出された対象リソースの指定（ここでは、ハードウェアリソース名）を含むマスク指示をカーネル１１０３に出力する（ステップＳ５）。

カーネル１１０３は、第１指示モジュール１１０６からマスク指示を受信する（ステップＳ７）。また、カーネル１１０３は、通知されたメモリ領域上で発生したエラーをＯＳ１１０２が看過するための設定を行う（ステップＳ９）。

また、第２指示モジュール１１０７は、マスク指示をハイパバイザ１３に出力する（ステップＳ１１）。

ハイパバイザ１３は、第２指示モジュール１１０７からマスク指示を受信する（ステップＳ１３）。そして、ハイパバイザ１３における設定モジュール１３１は、診断モジュール１３２のためのメモリ領域（すなわち、診断モジュール１３２を実現するためのプログラムが配置されるメモリ領域）で発生したエラーを看過するための設定を行う（ステップＳ１５）。処理は端子Ａ及びＢを介して図８の処理に移行する。

図８の処理の説明に移行して、第２指示モジュール１１０７は、ステップＳ１において検出された対象リソースの指定を含む診断要求をハイパバイザ１３に出力する（図８：ステップＳ１７）。

ハイパバイザ１３における診断モジュール１３２は、第２指示モジュール１１０７から診断要求を受信する（ステップＳ１９）。そして、診断モジュール１３２は、診断処理を実施する（ステップＳ２１）。診断処理については、図９を用いて詳細に説明する。

まず、診断モジュール１３２は、診断要求において指定されている対象リソース名で割当テーブル１３３を検索することにより、対象リソースがいずれかの論理ドメインに割り当て済みであるか判断する（図９：ステップＳ４１）。いずれの論理ドメインにも割り当てられていない場合（ステップＳ４１：Ｎｏルート）、対象リソースに対する診断を行っても問題は無いため、診断モジュール１３２は対象リソースに対する診断を行う（ステップＳ４３）。そして元の処理に戻る。

なお、本実施の形態においては、診断モジュール１３２はハードウェアリソースの診断に関する特別な権限を利用して、例えば対象リソースのレジスタにアクセスすることにより、対象リソースに対する診断を行う。

一方、対象リソースがいずれかの論理ドメインに割り当てられている場合（ステップＳ４１：Ｙｅｓルート）、診断モジュール１３２は、割当テーブル１３３において未割り当てのハードウェアリソースが有るか判断する（ステップＳ４５）。未割り当てのハードウェアリソースが有ると判断された場合（ステップＳ４５：Ｙｅｓルート）、診断モジュール１３２は、当該未割り当てのリソースに対して診断を行う（ステップＳ４７）。

そして、診断モジュール１３２は、診断結果が「正常」を示しているか判断する（ステップＳ４９）。診断結果が「正常」を示していない場合（ステップＳ４９：Ｎｏルート）、当該未割り当てリソースを論理ドメインに割り当てると論理ドメインに不具合が生じる可能性があるので、ステップＳ４５に戻る。

一方、診断結果が「正常」を示している場合（ステップＳ４９：Ｙｅｓルート）、診断モジュール１３２は、当該未割り当てリソースを対象リソースの代わりに論理ドメインに割り当てる（ステップＳ５１）。そして、診断モジュール１３２は、割り当てから解放された対象リソースに対する診断を行う（ステップＳ５３）。そして元の処理に戻る。

一方、未割り当てのハードウェアリソースが無いと判断された場合（ステップＳ４５：Ｎｏルート）、対象リソースを割り当てから解放することができず、診断を行うことができないため、元の処理に戻る。

このようにすれば、対象リソースが割り当て済みであったとしても、稼働中の論理ドメインに影響を与えることなく、対象リソースの診断を行うことができるようになる。

また、未割り当てのハードウェアリソースが正常であることを確認したうえで論理ドメインに割り当てるので、論理ドメインに不具合が発生することを防止できる。さらに、対象リソースを割り当てから解放して診断を行った後、対象リソースを再度割り当てることをしていないので、論理ドメインに割り当てられるハードウェアリソースが入れ替わることになる。これにより、特定のハードウェアリソースが論理ドメインに割り当てられ続けるような、使用の偏りを抑制することができるようになる。

図８の説明に戻り、診断モジュール１３２は、診断結果をＯＳ１１０２における管理モジュール１１０４に出力する（ステップＳ２３）。

管理モジュール１１０４における通知モジュール１１０８は、診断結果を診断モジュール１３２から受信する（ステップＳ２５）。そして、通知モジュール１１０８は、管理テーブル１１１０に格納されているデータを更新する（ステップＳ２７）。なお、診断結果が「正常」を示している場合には、診断結果及び追加診断の欄に「ＯＫ」を格納し、診断結果が「正常」を示していない場合には、診断結果及び追加診断の欄に「ＮＧ」を格納する。また、診断が行われていない、すなわちステップＳ４５のＮｏルートを経由している場合には、追加診断の欄に「ＮＧ」を格納する。

そして、通知モジュール１１０８は、診断結果が「正常」を示していない場合には、故障の発生をユーザに認識させるためのデータを生成し、生成したデータを表示部（図示せず）に表示させることにより、ユーザに対する通知を行う（ステップＳ２９）。また、通知モジュール１１０８は、イベントログテーブル（図示せず）に、故障が発生したハードウェアリソースの名前と発生日時とを登録しておく。

以上のような処理を実施することにより、ハードウェアリソースの診断中に所定のメモリ領域で発生したエラーによって、ＯＳ１１０２及びハイパバイザ１３が悪影響（例えばパニック状態に陥る等）を受けることはなくなる。よって、論理ドメインの稼働中であっても、ハイパバイザ１３の特権を利用して適切なハードウェア診断を行うことができ、故障の検出が遅れてしまうことを防ぐことができるようになる。すなわち、早期にハードウェアリソースの故障を検出し、メインシステムの安定稼働を実現できるようになる。

ここで、第１の実施の形態に係るハードウェアリソースの診断方法の概要を図１０に示す。第１の実施の形態によれば、論理ドメインの稼働中に各ハードウェアリソースに対して定期的な診断を行うことができるようになる。すなわち、メインシステム又は論理ドメインをリセットしなくても、ハードウェアリソースに対する診断を行うことができるようになっている。

［実施の形態２］
次に、第２の実施の形態について説明する。第２の実施の形態は、対象リソースが割り当て済みであり且つ未割り当てのハードウェアリソースが無い場合であっても、対象リソースに対して強制的に診断を行える点で第１の実施の形態とは異なっている。

第２の実施の形態における情報処理装置１０００の構成について、第１の実施の形態との相違点を説明する。

図１１に、診断定義テーブル１１０９に格納されているデータの一例を示す。図１１の例では、診断を実施するか否かを指定するためのデータと、診断対象を指定するためのデータと、診断間隔を指定するためのデータと、強制診断を有効にするか否かを指定するためのデータとが格納されている。

その他の部分については、第１の実施の形態と同様である。

次に、第２の実施の形態における情報処理装置１０００の処理内容について説明する。まず、論理ドメイン１１における検出モジュール１１０５は、診断を行うべきハードウェアリソース（以下、対象リソースと呼ぶ）を検出する（図１２：ステップＳ６１）。検出の方法については、ステップＳ１の説明で述べたとおりである。

そして、検出モジュール１１０５は、割当テーブル１１１１において未割り当てのハードウェアリソースが有るか判断する（ステップＳ６３）。未割り当てのハードウェアリソースが有ると判断された場合（ステップＳ６３：Ｙｅｓルート）、強制診断の可否について判断するまでもなく、対象リソースに対する診断を行うことができるので、ステップＳ６９の処理に移行する。

一方、未割り当てのハードウェアリソースが無いと判断された場合（ステップＳ６３：Ｎｏルート）、検出モジュール１１０５は、診断定義テーブル１１０９において強制診断が有効になっているか判断する（ステップＳ６５）。強制診断が有効ではないと判断された場合（ステップＳ６５：Ｎｏルート）、対象リソースに対する診断を行うことはできないので、処理を終了する（ステップＳ６７）。

一方、強制診断が有効であると判断された場合（ステップＳ６５：Ｙｅｓルート）、割り当て済みであるハードウェアリソースを未割り当てのハードウェアリソースであるとみなして診断を行うことができる。よって、第１指示モジュール１１０６は、対象リソースに対する診断のための処理においてＯＳ１１０２が利用するメモリ領域を確保する（ステップＳ６９）。そして、第１指示モジュール１１０６は、ステップＳ６９において確保されたメモリ領域のアドレスを含むマスク指示をカーネル１１０３に出力する（ステップＳ７１）。

カーネル１１０３は、第１指示モジュール１１０６からマスク指示を受信する（ステップＳ７３）。また、カーネル１１０３は、通知されたメモリ領域上で発生したエラーをＯＳ１１０２が看過するための設定を行う（ステップＳ７５）。

また、第２指示モジュール１１０７は、マスク指示をハイパバイザ１３に出力する（ステップＳ７７）。

ハイパバイザ１３は、第２指示モジュール１１０７からマスク指示を受信する（ステップＳ７９）。そして、ハイパバイザ１３における設定モジュール１３１は、診断モジュール１３２のためのメモリ領域（すなわち、診断モジュール１３２を実現するためのプログラムが配置されるメモリ領域）で発生したエラーを看過するための設定を行う（ステップＳ８１）。そして処理は端子Ａ及びＢを介して図８の処理に移行する。

このような処理を実施することにより、ハイパバイザ１３における診断モジュール１３２に強制診断を行わせることができるようになる。

また、第２の実施の形態における診断処理は、第１の実施の形態における診断処理とは異なっている。そこで、第２の実施の形態における診断処理について図１３を用いて説明する。

まず、診断モジュール１３２は、診断要求において指定されている対象リソースのハードウェアリソース名で割当テーブル１３３を検索することにより、対象リソースがいずれかの論理ドメインに割り当て済みであるか判断する（図１３：ステップＳ９１）。いずれの論理ドメインにも割り当てられていない場合（ステップＳ９１：Ｎｏルート）、対象リソースに対する診断を行っても問題は無いため、診断モジュール１３２は対象リソースに対する診断を行う（ステップＳ９３）。そして元の処理に戻る。

なお、第１の形態と同様に、診断モジュール１３２はハードウェアリソースの診断に関する特別な権限を利用して、例えば対象リソースのレジスタにアクセスすることにより、対象リソースに対する診断を行う。

一方、対象リソースがいずれかの論理ドメインに割り当てられている場合（ステップＳ９１：Ｙｅｓルート）、診断モジュール１３２は、割当テーブル１３３において未割り当てのハードウェアリソースが有るか判断する（ステップＳ９５）。未割り当てのハードウェアリソースが有ると判断された場合（ステップＳ９５：Ｙｅｓルート）、診断モジュール１３２は、当該未割り当てのリソースに対して診断を行う（ステップＳ９７）。

そして、診断モジュール１３２は、診断結果が「正常」を示しているか判断する（ステップＳ９９）。診断結果が「正常」を示していない場合（ステップＳ９９：Ｎｏルート）、当該未割り当てリソースを論理ドメインに割り当てると論理ドメインに不具合が生じる可能性があるので、ステップＳ９５に戻る。

一方、診断結果が「正常」を示している場合（ステップＳ９９：Ｙｅｓルート）、診断モジュール１３２は、当該未割り当てリソースを対象リソースの代わりに論理ドメインに割り当てる（ステップＳ１０１）。そして、診断モジュール１３２は、割り当てから解放された対象リソースに対する診断を行う（ステップＳ１０３）。そして元の処理に戻る。

一方、未割り当てのハードウェアリソースが無いと判断された場合（ステップＳ９５：Ｎｏルート）、診断モジュール１３２は、診断定義テーブル１１０９において強制診断が有効になっているか判断する（ステップＳ１０５）。強制診断が有効ではない場合（ステップＳ１０５：Ｎｏルート）、対象リソースを割り当てから解放できず、診断を行うことができないため、元の処理に戻る。

一方、強制診断が有効である場合（ステップＳ１０５：Ｙｅｓルート）、診断モジュール１３２は、割当テーブル１３３において割り当て済みであるハードウェアリソースを１つ特定し（ステップＳ１０７）、当該ハードウェアリソースに対して診断を行う（ステップＳ９７）。ステップＳ９９以降の処理は上で述べたとおりである。

このような処理を実施すれば、対象リソースが論理ドメインに割り当て済みであり且つ未割り当てのハードウェアリソースが無いような場合、すなわち余剰のハードウェアリソースが少ないような場合においても、確実に診断を行うことができるようになる。

以上本技術の一実施の形態を説明したが、本技術はこれに限定されるものではない。例えば、上で説明した情報処理装置１０００の構成は必ずしも実際のプログラムモジュール構成に対応するものではない。

また、上で説明した処理フローは、処理結果が変わらなければ処理の順番を入れ替えることも可能である。さらに、並列に実行させるようにしても良い。

なお、図５に示した管理テーブルにおいては、最終診断時刻を管理するような例を示したが、図１４に示すように、最後に診断を行ってから経過した時間（すなわち稼働時間）を管理するようにしてもよい。このような場合には、稼働時間が診断間隔を超えた場合に診断を行うようにすることで、ハードウェアリソースに対する定期的な診断を行えるようになる。

また、第２の実施の形態では、ＯＳ１１０２における検出モジュール１１０５がステップＳ６５において強制診断が有効であるかを確認した際に、強制診断が有効であるか否かをハイパバイザ１３における診断モジュール１３２に通知するようにしてもよい。このようにすれば、診断モジュール１３２がステップＳ１０５において強制診断が有効であるかを判断しなくても済む。

また、上で述べた例では、対象リソースがいずれかの論理ドメインに割り当て済みである場合に、他のハードウェアリソースを対象リソースの代わりに割り当てた後、対象リソースに対する診断を行っている。そして、対象リソースに対する診断の終了後に、対象リソースを論理ドメインに再度割り当てるようにはしていなかったが、対象リソースが故障していないのであれば、論理ドメインに再度割り当てるようにしてもよい。

また、ステップＳ１７においては、第２指示モジュール１１０７からハイパバイザ１３に対して対象リソースの指定を通知するようにしているが、マスク指示を受信したカーネル１１０３が、ハイパバイザ１３に対して対象リソースの指定を通知するようにしてもよい。

以上述べた本実施の形態をまとめると以下のようになる。

本情報処理装置は、（Ａ）メモリと、（Ｂ）オペレーティングシステムを実行し、計算機として所定の機能を提供する論理ドメインと、論理ドメインの管理を行うハイパバイザとの処理を実行する処理装置（例えばプロセッサ）とを有する。そして、上記オペレーティングシステムが、（ｂ１−１）処理装置に実行されるときには、診断を行うべきハードウェアを検出する検出モジュールと、（ｂ１−２）処理装置に実行されるときには、検出モジュールにより診断を行うべきハードウェアが検出された場合、診断のための処理においてオペレーティングシステムが利用する、メモリにおけるメモリ領域を確保し、オペレーティングシステムのカーネルに対して、当該メモリ領域で発生したエラーを看過するように指示する第１指示モジュールと、（ｂ１−３）処理装置に実行されるときには、検出モジュールにより診断を行うべきハードウェアが検出された場合、ハイパバイザに対して、診断において利用する、メモリにおけるメモリ領域で発生したエラーを看過するように指示し且つ診断を行うべきハードウェアの指定を含む診断要求を出力する第２指示モジュールとを有する。そして、上記ハイパバイザが、（ｂ２−１）処理装置に実行されるときには、診断要求を受信した場合、診断モジュールが診断において利用する、メモリにおけるメモリ領域で発生したエラーを看過するための設定を行う設定モジュールと、（ｂ２−２）処理装置に実行されるときには、診断要求を受信した場合、診断を行うべきハードウェアに対して診断を行う診断モジュールとを有する。

このような構成であれば、論理ドメインの稼動中であっても、オペレーティングシステム及びハイパバイザの処理に対して悪影響を及ぼすことなく、ハイパバイザによる適切なハードウェア診断を行えるようになる。なお、上で述べた処理装置は、例えばプロセッサと当該プロセッサにより実行されるプログラムとにより実現される。

また、上で述べた診断モジュールが、（ｂ２−２１）処理装置に実行されるときには、診断を行うべきハードウェアがいずれかの論理ドメインに割り当てられている場合、情報処理装置が有するハードウェアのうちいずれの論理ドメインにも割り当てられていないハードウェアを、診断を行うべきハードウェアの代わりに割り当てた後、診断を行うべきハードウェアに対して診断を行うようにしてもよい。このようにすれば、診断を行うべきハードウェアが論理ドメインに割り当てられている場合であっても、論理ドメインの稼動を継続しつつ診断を行うことができるようになる。また、特定のハードウェアが論理ドメインに割り当てられ続けるような、ハードウェアの使用の偏りを防ぐことができるようになる。

また、上で述べた診断モジュールが、（ｂ２−２２）処理装置に実行されるときには、情報処理装置が有するハードウェアのうちいずれの論理ドメインにも割り当てられていないハードウェアに対して診断を行い、当該診断の結果が正常である場合に、当該ハードウェアを診断を行うべきハードウェアの代わりに割り当てるようにしてもよい。このようにすれば、故障しているハードウェアを論理ドメインに割り当ててしまうことによる不具合の発生を防ぐことができる。

また、上で述べた診断モジュールが、（ｂ２−２３）処理装置に実行されるときには、診断を行うべきハードウェアがいずれかの論理ドメインに割り当てられており且ついずれの論理ドメインにも割り当てられていないハードウェアが無い場合、診断方法を定義する定義データをテーブルから読み出し、強制診断が指定されているか判断し、強制診断が指定されていると判断した場合、既にいずれかの論理ドメインに割り当てられているハードウェアを、診断を行うべきハードウェアの代わりに割り当てるようにしてもよい。このようにすれば、余剰のハードウェアが少ないような場合においても、確実に診断を行うことができるようになる。

また、上で述べた診断モジュールが、（ｂ２−２４）処理装置に実行されるときには、診断の結果をオペレーティングシステムに出力するようにしてもよい。そして、オペレーティングシステムが、（ｂ１−３）処理装置に実行されるときには、診断の結果が、診断が行われたハードウェアが故障していることを示している場合、当該故障を論理ドメインのユーザに通知するためのデータを生成する通知モジュールをさらに有するようにしてもよい。このようにすれば、ユーザが故障に対する対処を行うことができるようになる。

また、上で述べた検出モジュールは、（ｂ１−１１）処理装置に実行されるときには、情報処理装置が有するハードウェアのうち、所定時間以上診断が行なわれていないハードウェアを検出するようにしてもよい。これにより、定期的な診断が行えるようになる。

また、上で述べた検出モジュールは、（ｂ１−１２）処理装置に実行されるときには、情報処理装置が有するハードウェアのうち、所定時間以上診断が行なわれておらず且つ前回診断において正常であると診断されたハードウェアを検出するようにしてもよい。これにより、前回診断において故障があると診断されたハードウェアに対して再度診断を行ってしまう無駄を解消することができるようになる。

また、ハイパバイザにより実現された論理ドメインのうちいずれか１つの論理ドメインに含まれるオペレーティングシステムが、検出モジュール、第１指示モジュール及び第２指示モジュールを有するようにしてもよい。これにより、ハードウェア診断を適切に管理できるようになる。

本情報処理方法は、（Ｃ）診断を行うべきハードウェアを検出するステップと、（Ｄ）仮想的に実現されたシステムである論理ドメインに含まれるオペレーティングシステムが診断のための処理において利用するメモリ領域を確保し、オペレーティングシステムのカーネルに対して、当該メモリ領域で発生したエラーを看過するように指示するステップと、（Ｅ）論理ドメインを実現するためのハイパバイザに対して、診断において利用するメモリ領域で発生したエラーを看過するように指示し且つ診断を行うべきハードウェアの指定を含む診断要求を出力するステップとを含む。

このようにすれば、論理ドメインの稼働中にハードウェアの診断を行ったとしても、オペレーティングシステム及びハイパバイザの処理に悪影響を及ぼすことがなくなる。

本実施の形態の第２の態様に係る情報処理方法は、（Ｆ）ハードウェアの診断において利用するメモリ領域で発生したエラーを看過するように指示し且つ診断を行うべきハードウェアの指定を含む診断要求を、仮想的に実現されたシステムである論理ドメインに含まれるオペレーティングシステムから受信した場合、論理ドメインを実現するためのハイパバイザが診断において利用するメモリ領域で発生したエラーを看過するための設定を行うステップと、（Ｇ）診断を行うべきハードウェアに対して診断を行うステップとを含む。

このようにすれば、ハイパバイザの処理に悪影響を及ぼすことなく、ハイパバイザによる適切なハードウェア診断を行えるようになる。

なお、上記方法による処理をコンピュータに行わせるためのプログラムを作成することができ、当該プログラムは、例えばフレキシブルディスク、ＣＤ−ＲＯＭ、光磁気ディスク、半導体メモリ、ハードディスク等のコンピュータ読み取り可能な記憶媒体又は記憶装置に格納される。尚、中間的な処理結果はメインメモリ等の記憶装置に一時保管される。

Claims (8)

1. メモリと、
   オペレーティングシステムを実行し、計算機として所定の機能を提供する論理ドメインと、前記論理ドメインの管理を行うハイパバイザとの処理を実行する処理装置と、
   を有し、
   前記オペレーティングシステムが、
   診断を行うべきハードウェアを検出する検出モジュールと、
   前記検出モジュールにより前記診断を行うべきハードウェアが検出された場合、前記診断のための処理において前記オペレーティングシステムが利用する、前記メモリにおけるメモリ領域を確保し、前記オペレーティングシステムのカーネルに対して、当該メモリ領域で発生したエラーを看過するように指示する第１指示モジュールと、
   前記検出モジュールにより前記診断を行うべきハードウェアが検出された場合、前記ハイパバイザに対して、前記診断において利用するメモリ領域で発生したエラーを看過するように指示し且つ前記診断を行うべきハードウェアの指定を含む診断要求を出力する第２指示モジュールと、
   を有し、
   前記ハイパバイザが、
   前記診断要求を受信した場合、前記診断を行うべきハードウェアに対して前記診断を行う診断モジュールと、
   前記診断要求を受信した場合、前記診断モジュールが前記診断において利用するメモリ領域で発生したエラーを看過するための設定を行う設定モジュールと、
   を有する
   情報処理装置。
2. 前記診断モジュールが、
   前記診断を行うべきハードウェアがいずれかの論理ドメインに割り当てられている場合、前記情報処理装置が有するハードウェアのうちいずれの論理ドメインにも割り当てられていないハードウェアを、前記診断を行うべきハードウェアの代わりに割り当てた後、前記診断を行うべきハードウェアに対して前記診断を行う
   請求項１記載の情報処理装置。
3. 前記診断モジュールが、
   前記情報処理装置が有するハードウェアのうちいずれの論理ドメインにも割り当てられていないハードウェアに対して診断を行い、当該診断の結果が正常である場合に、当該ハードウェアを前記診断を行うべきハードウェアの代わりに割り当てる
   請求項２記載の情報処理装置。
4. 前記診断モジュールが、
   前記診断を行うべきハードウェアがいずれかの論理ドメインに割り当てられており且ついずれの論理ドメインにも割り当てられていないハードウェアが無い場合、診断方法を定義する定義データをテーブルから読み出し、強制診断が指定されているか判断し、
   前記強制診断が指定されていると判断した場合、既にいずれかの論理ドメインに割り当てられているハードウェアを、前記診断を行うべきハードウェアの代わりに割り当てる
   請求項１記載の情報処理装置。
5. 前記診断モジュールが、
   前記診断の結果を前記オペレーティングシステムに出力し、
   前記オペレーティングシステムが、
   前記診断の結果が、前記診断が行われたハードウェアが故障していることを示している場合、当該故障を前記論理ドメインのユーザに通知するためのデータを生成する通知モジュール
   をさらに有する
   請求項１乃至４のいずれか１つ記載の情報処理装置。
6. コンピュータにおいて仮想的に実現されたシステムである論理ドメイン内のオペレーティングシステムに含まれる管理プログラムであって、
   前記コンピュータ内のプロセッサに、
   診断を行うべきハードウェアを検出し、
   前記診断のための処理において利用するメモリ領域を確保し、前記オペレーティングシステムのカーネルに対して、当該メモリ領域で発生したエラーを看過するように指示し、
   前記論理ドメインの管理を行うハイパバイザに対して、前記診断において利用するメモリ領域で発生したエラーを看過するように指示し且つ前記診断を行うべきハードウェアの指定を含む診断要求を出力する
   処理を実行させるための管理プログラム。
7. コンピュータにおいて仮想的に実現されたシステムである論理ドメインの管理を行うためのプログラムであって、
   前記コンピュータ内のプロセッサに、
   ハードウェアの診断において利用するメモリ領域で発生したエラーを看過するように指示し且つ前記診断を行うべきハードウェアの指定を含む診断要求を、前記論理ドメインに含まれるオペレーティングシステムから受信した場合、前記診断において利用するメモリ領域で発生したエラーを看過するための設定を行い、
   前記診断を行うべきハードウェアに対して前記診断を行う
   処理を実行させるためのプログラム。
8. 仮想的に実現されたシステムである論理ドメイン内のオペレーティングシステムに含まれる検出モジュール及び指示モジュールと、前記論理ドメインの管理を行うハイパバイザに含まれる診断モジュール及び設定モジュールとを含むコンピュータにおいて実行される情報処理方法であって、
   前記検出モジュールが、
   診断を行うべきハードウェアを検出し、
   前記指示モジュールが、
   前記診断のための処理において利用するメモリ領域を確保し、前記オペレーティングシステムのカーネルに対して、当該メモリ領域で発生したエラーを看過するように指示し、
   前記設定モジュールが、
   前記診断において利用するメモリ領域で発生したエラーを看過するための設定を行い、
   前記診断モジュールが、
   前記診断を行うべきハードウェアに対して前記診断を行う
   処理を実行する情報処理方法。

Images