JP2006039763A - ゲストｏｓデバッグ支援方法及び仮想計算機マネージャ - Google Patents

Abstract

【課題】ゲストＯＳに対する従来にはない優れたデバッグ環境を実現し、より効果的にデバッグが行えるように支援できるようにする。
【解決手段】ＶＭＭ（仮想計算機マネージャ）は、第１のゲストＯＳが動作する第１の仮想計算機実行環境とは異なる第２の仮想計算機実行環境を構築する（Ｓ２）。ＶＭＭは、第１のゲストＯＳを、当該第１のゲストＯＳの実行状態及び当該第１のゲストＯＳが使用するメモリの状態を含めて、第２の仮想計算機実行環境にコピーすることにより、第１のゲストＯＳのコピーである第２のゲストＯＳを第２の仮想計算機実行環境に生成する（Ｓ３）。このときＶＭＭは、第２の仮想計算機実行環境に生成された第２のゲストＯＳを停止状態にして当該第２のゲストＯＳの状態を保存する。
【選択図】 図３

Description

本発明は、仮想計算機システムで実行されるゲストＯＳのデバッグを支援するのに好適なゲストＯＳデバッグ支援方法及び仮想計算機マネージャに関する。

近年、パーソナルコンピュータ等の計算機システムにおいて、仮想計算機（Virtual Machine）システム（以下、ＶＭシステムと称する）を実現するためのアプリケーション（アプリケーションプログラム）が利用されるようになってきている。このようなアプリケーションは、ＶＭ（Virtual Machine）アプリケーションと呼ばれる。

さて、計算機システム（実計算機システム）は、一般に、実プロセッサ、各種Ｉ／Ｏ装置（入出力装置）及びメモリ（図示せず）等のハードウェア（ＨＷ）で構成されている。この計算機システムのハードウェア構成上では、ホストＯＳと呼ばれるＯＳが動作する。ホストＯＳ上では各種アプリケーションが実行される。このアプリケーションの１つが上記ＶＭアプリケーションである。このＶＭアプリケーションの実行により、ＶＭシステムを管理する仮想計算機マネージャ（Virtual Machine Manager、以下、ＶＭＭと称する）が実現される。ＶＭＭは、仮想プロセッサ、仮想Ｉ／Ｏ装置及び仮想メモリ装置を含む仮想ＨＷを実現する。ＶＭＭは、これらの仮想プロセッサ、仮想Ｉ／Ｏ装置及び仮想メモリ装置をエミュレートして、仮想計算機実行環境を実現する。この仮想計算機実行環境では、ゲストＯＳと呼ばれるＯＳが動作する。

このように、ＶＭＭは一般的な計算機システム内で、仮想的な計算機実行環境（仮想計算機実行環境）を構築して、その中でゲストＯＳを実行することができる。ここでは、ＶＭＭは、ＯＳ上で動作する１つのアプリケーション（ＶＭアプリケーション）として実装される。この他に、ＶＭＭが、計算機システムの実ＨＷ上にＶＭＭ機構（ＨＷとしての仮想計算機支援機構）として実装された構成も知られている。このＶＭ機構も、実プロセッサや実Ｉ／Ｏ装置を仮想化して各ゲストＯＳに機能として提供する。ＶＭ機構の上には、仮想計算機実行環境が当該ＶＭ機構により構築される。

上述したＶＭシステムにおいて、ゲストＯＳは、計算機の実ＨＷの上で動作するかの如く振舞うのが普通である。その結果、ゲストＯＳに問題があれば当該ゲストＯＳはパニック（クラッシュ）してしまう。このように、ゲストＯＳがパニック（クラッシュ）してしまうと、つまりゲストＯＳに障害が発生すると、従来のＶＭシステムでは、当該ゲストＯＳが停止する。この場合、ＶＭＭは、障害が発生したゲストＯＳの停止時の稼動状態、つまりゲストＯＳの実行イメージを、外部記憶装置にダンプとしてセーブするのが一般的である（例えば、特許文献１参照）。この特許文献１では、外部記憶装置に保存された実行イメージを利用して、障害が発生したゲストＯＳが提供していたサービスの実行を、待機状態にある別のゲストＯＳが引き継ぐことが提案されている。
特開平９−２８８５９０号公報（段落００１２、段落００２１乃至００３０）

上記したように、従来のＶＭシステム（仮想計算機システム）で運用されるゲストＯＳに何らかの障害が発生して当該ゲストＯＳが停止した場合、その時点における当該ゲストＯＳの実行イメージがダンプとして外部記憶装置にセーブされるのが一般的である。そこで、この外部記憶装置にセーブされたダンプを利用して、ゲストＯＳのデバッグを行うことが考えられる。また、ゲストＯＳの障害を模擬して、ゲストＯＳを意図的に停止させ、その時点における当該ゲストＯＳの実行イメージをダンプとして外部記憶装置にセーブすることにより、ゲストＯＳのデバッグを行うことも考えられる。

しかし、いずれも停止状態にあるゲストＯＳの静的なデバッグであり、有効なデバッグとはなり得ない。しかも、ゲストＯＳを停止させて、当該ゲストＯＳが提供するサービスを待機状態にある他のゲストＯＳに引き継がせる場合、その引き継ぎにそれなりの時間がかかるのが一般的であり、（短期間であっても）サービスが中断するため好ましくない。

本発明は上記事情を考慮してなされたものでその目的は、ゲストＯＳに対する従来にはない優れたデバッグ環境を実現し、より効果的にデバッグが行えるように支援できる、ゲストＯＳデバッグ支援方法及び仮想計算機マネージャを提供することにある。

本発明の１つの観点によれば、仮想計算機マネージャ（ＶＭＭ）によって提供される仮想計算機実行環境で動作するゲストＯＳのデバッグを支援するゲストＯＳデバッグ支援方法が提供される。この方法は、第１のゲストＯＳが動作する第１の仮想計算機実行環境とは異なる第２の仮想計算機実行環境を上記仮想計算機マネージャが構築するステップと、上記仮想計算機マネージャが、上記第１のゲストＯＳを、当該第１のゲストＯＳの実行状態及び当該第１のゲストＯＳが使用するメモリの状態を含めて、上記第２の仮想計算機実行環境にコピーすることにより、上記第１のゲストＯＳのコピーである第２のゲストＯＳを上記第２の仮想計算機実行環境に生成するステップと、上記第２の仮想計算機実行環境に生成された第２のゲストＯＳを停止状態にして当該第２のゲストＯＳの状態を保存するステップとを備えることを特徴とする。

このような構成においては、第１の仮想計算機実行環境で動作する第１のゲストＯＳが、当該第１のゲストＯＳの実行状態及び当該第１のゲストＯＳが使用するメモリの状態を含めて、仮想計算機マネージャによって第２の仮想計算機実行環境にコピーされる。これにより、第１のゲストＯＳのコピーである第２のゲストＯＳが、第２の仮想計算機実行環境に生成される。この第２の仮想計算機実行環境に生成された第２のゲストＯＳは、仮想計算機マネージャによって停止状態にされる。これにより、第１のゲストＯＳのコピー時の状態が、第２のゲストＯＳの状態として保存される。

このように上記の構成においては、仮想計算機マネージャの機能を利用して、第１のゲストＯＳのコピー時の状態が、第２のゲストＯＳの状態として保存されることから、この第２のゲストＯＳをデバッグ対象とすることで、第１のゲストＯＳのデバッグのための環境（デバッグ環境）を、当該第１のゲストＯＳを止めることなく実現できる。

ここで、第２のゲストＯＳ（第１のゲストＯＳのコピー）を生成する前に、第１のゲストＯＳを実行されない状態にするならば、その時点の第１のゲストＯＳの状態を第２のゲストＯＳとして確実に保存できる。また、第２のゲストＯＳの生成後に、第１のゲストＯＳを実行可能な状態にするならば、当該第１のゲストＯＳ自身がデバッガにより当該第１のゲストＯＳのコピー時の状態をデバッグ（解析）することができる。勿論、動作状態にある、第１のゲストＯＳ以外のゲストＯＳが、第１のゲストＯＳのコピー時の状態をデバッグ（解析）することも可能である。

ここで、第２のゲストＯＳ（第１のゲストＯＳのコピー）の生成が、第１のゲストＯＳからの要求を受けて仮想計算機マネージャによって行われる構成とすることも、仮想計算機マネージャによって自律的に行われる構成とすることも可能である。また、第２のゲストＯＳ（第１のゲストＯＳのコピー）の生成を仮想計算機マネージャが自律的に行うには、当該仮想計算機マネージャが第１のゲストＯＳを監視し、当該第１のゲストＯＳの異常を検出すると良い。即ち、仮想計算機マネージャが第１のゲストＯＳの異常を検出した際に、第２のゲストＯＳ（第１のゲストＯＳのコピー）を生成すると良い。

また、第２のゲストＯＳ（第１のゲストＯＳのコピー）の生成を、第１のゲストＯＳの異常が検出されるまでの期間、予め定められた時間間隔で、第１のゲストＯＳのコピー先となる第２の仮想計算機実行環境を、一定数の第２の仮想計算機実行環境の範囲内で切り替えながら実行する構成とすることも可能である。この構成においては、常時複数世代の第１のゲストＯＳの状態を保存できることから、当該第１のゲストＯＳで異常が発生した際には、その異常発生直前の複数世代の第１のゲストＯＳの状態をデバッグ（解析）対象とすることにより、異常（問題）発生時点の状態だけでなく、時間を遡って原因を追求することが可能となる。これは従来のデバッガ（デバッグ環境）では得られない利点であり、ユーザはこの環境を利用することで、効果的に問題の原因を追求することが可能になる。

本発明によれば、仮想計算機実行環境（第１の仮想計算機実行環境）で動作しているゲストＯＳ（第１のゲストＯＳ）の状態を、仮想計算機マネージャ（ＶＭＭ）の支援のもとで、もう一つの新たな仮想計算機実行環境（第２の仮想計算機実行環境）上のゲストＯＳ（第２のゲストＯＳ）として保存することができるため、その保存されたゲストＯＳ（第２のゲストＯＳ）をデバッグ（解析）対象とすることが可能なデバッグ環境を、元のゲストＯＳ（第１のゲストＯＳ）を止める（つまりサービスも止める）ことなく実現できる。また、ダンプのための外部記憶装置が使えない状況であっても、新たに第２の仮想計算機実行環境を構築し、そこに第１のゲストＯＳのコピーを保存することにより、ダンプを取る代わりにすることができ、問題解析の重要な手がかりにすることができる。また、問題発生前数世代のゲストＯＳの状態を保存した仮想計算機実行環境を残すことにより、問題発生時点の状態だけでなく、時間を遡って原因を追求することが可能となる。

以下、本発明の一実施形態につき図面を参照して説明する。
図１は本発明の一実施形態に係る仮想計算機システムを実現する計算機システム１の構成を示すブロック図である。計算機システム１は、実計算機を構成するハードウェア（ＨＷ）１０を備えている。ＨＷ１０は、周知のように、実プロセッサ１１、各種Ｉ／Ｏ装置（入出力装置）１２及びメモリ（図示せず）を含む。ＨＷ１０上では、ホストＯＳと呼ばれるＯＳ２０が動作する。ＯＳ（ホストＯＳ）２０上では仮想計算機アプリケーション（ＶＭアプリケーション）３０を含む各種のアプリケーションが実行される。

ＶＭアプリケーション３０の実行により、仮想計算機マネージャ（Virtual Machine Manager、以下、ＶＭＭと称する）３１が実現される。ＶＭＭ３１は、仮想計算機システム（ＶＭシステム）の環境（仮想計算機実行環境）を構築する。図１では、２つの仮想計算機実行環境３２-1（ＶＭ＃１），３２-2（ＶＭ＃２）が構築されている例が示されている。仮想計算機実行環境３２-i（ｉ＝１，２）は、仮想ＨＷ環境（仮想ＨＷ装置）３３-i及びゲストＯＳ実行環境３４-iからなる。仮想ＨＷ環境３３-iは、仮想プロセッサ３３１-i、仮想Ｉ／Ｏ装置３３２-i及び仮想メモリ装置（図示せず）を含む。ＶＭＭ３１は、論理的に、この仮想ＨＷ環境３３-i内の仮想プロセッサ３３１-i、仮想Ｉ／Ｏ装置３３２-i及び仮想メモリ装置をエミュレートして、仮想計算機実行環境３２-i（ＶＭ＃ｉ）を実現する。ＶＭＭ３１は、仮想計算機実行環境３２-i（ＶＭ＃ｉ）内のゲストＯＳ実行環境３４-iに、当該ゲストＯＳ実行環境３４-iで動作するＯＳをゲストＯＳ３４０-i（＃ｉ）としてロードする。ＶＭＭ３１は、仮想ＨＷ環境３４-iに含まれる仮想メモリ装置にゲストＯＳ３４０-i（＃ｉ）のコードを展開し、その実行コードを仮想プロセッサ３３１-iのエミュレートという形で実行する。これによりＶＭＭ３１は、ゲストＯＳ３４０-i（＃ｉ）の処理を進める。ゲストＯＳ３４０-i（＃ｉ）からのＩ／Ｏ要求は、ＶＭＭ３１が仮想Ｉ／Ｏ装置３３２-iのエミュレートを行うことにより処理する。ゲストＯＳ３４０-i（＃ｉ）は、自身の状態のコピー（複製）をＶＭＭ３１に要求するコピー要求機能を有する。ＶＭＭ３１は、ゲストＯＳ３４０-i（＃ｉ）からのコピー要求に応じて、当該ゲストＯＳ３４０-i（＃ｉ）のコピーを生成するゲストＯＳコピー機能を有する。

次に、本実施形態におけるゲストＯＳのデバッグを支援するためのコピー処理について、図２の動作の概要を示す図及び図３のフローチャートを参照して説明する。
まず、図２に示すように、仮想計算機実行環境３２-1（ＶＭ＃１）上でゲストＯＳ３４０-1（＃１）が稼動しているものとする。同時に、仮想計算機実行環境３２-2（ＶＭ＃２）上でゲストＯＳ３４０-2（＃２）が稼動しているものとする。ゲストＯＳ＃１（３４０-1），＃２（３４０-2）は、自身の状態のコピー（複製）をＶＭＭ３１に要求するコピー要求部３４１を備えている。ＶＭＭ３１は、ゲストＯＳ＃ｉ（３４０-i）のコピー要求部３４１からのコピー要求に応じて、当該ゲストＯＳ＃ｉのコピー（ゲストＯＳ＃１’）を生成するゲストＯＳコピー部３１１を備えている。ゲストＯＳコピー部３１１は、ゲストＯＳ起動／停止部３１１ａを含む。ゲストＯＳ起動／停止部３１１ａは、ゲストＯＳ＃ｉを実行されない状態（停止状態）に設定する機能と、実行されない状態（停止状態）にあるゲストＯＳ＃ｉを実行可能な状態に設定する機能を有する。なお、ゲストＯＳ起動／停止部３１１ａがゲストＯＳコピー部３１１から独立して設けられる構成とすることも可能である。

さて、ＶＭ＃１，＃２上でゲストＯＳ＃１，＃２がそれぞれ稼動している状態で、ゲストＯＳ＃１のコピー要求部３４１からＶＭＭ３１に対して、図２において矢印２１で示されるように、当該ゲストＯＳ＃１自身の状態のコピー（複製）を依頼するコピー要求が送られたものとする。

このように、ゲストＯＳ＃１のコピー要求部３４１からコピー要求が送出されるのは、例えば次の２つのケース
(1) ゲストＯＳ＃１自身が、内部に異常な状態を感知した結果、自身のその時点での状態を解析する必要が生じた場合
(2) ＵＮＩＸ（登録商標）系のＯＳのように、ＯＳ内部に矛盾が発生してパニックと呼ばれる状態になって、処理を続けることができなくなったために、実行状態を保存（ダンプ）し後の解析に備える必要が生じた場合
である。

例えば、汎用的なＯＳでは、内部で異常を検出したときには、“assert()”という関数が呼ばれる（ケース(1)の場合）。この関数は、例えば、ＯＳにデバッガがつながっている場合には、当該デバッガに制御を移し、該当するＯＳの状況を解析することを可能とする。なお、デバッガが使えない場合に、以下で説明する関数“panic()”が呼び出される実装もある。

一方、ＯＳ内部で矛盾が生じ、処理を続けられないときには、“panic()”という関数が呼ばれる（ケース(2)の場合）。この関数は、重大なエラーの発生をユーザに通知するために、エラーを端末に表示することを可能とする。この関数は、メモリのダンプを外部記憶装置に記録することも可能とする。その後、システムの停止、或いはＯＳのリブートを可能とする。

本実施形態においてゲストＯＳ＃１のコピー要求部３４１は、上述したケース(1)または(2)に該当する状態になった場合に、ＶＭＭ３１に対してコピー要求を送出することができる。ここでは、ゲストＯＳ＃１がケース(1)に該当する状態になった結果、当該ゲストＯＳ＃１のコピー要求部３４１からＶＭＭ３１に対してコピー要求が送出されたものとする。ＶＭＭ３１はコピー要求を受け取ると、図３のフローチャートに示される処理を、次のように行う。

まずＶＭＭ３１のゲストＯＳコピー部３１１は、ゲストＯＳ起動／停止部３１１ａを用いて、コピー要求元のゲストＯＳ＃１を実行されない状態（停止状態）にして、当該ゲストＯＳ＃１の内部状態が変化しないようにする（ステップＳ１）。次にゲストＯＳコピー部３１１は、仮想計算機実行環境構築機能により、仮想計算機システム内に、新たに仮想計算機実行環境３２-3（ＶＭ＃３）を構築する（ステップＳ２）。この仮想計算機実行環境構築機能を持つ手段（仮想計算機実行環境構築部）を、ゲストＯＳコピー部３１１から独立させることも可能である。

次にゲストＯＳコピー部３１１は、新たな仮想計算機実行環境３２-3（ＶＭ＃３）に、実行されない状態（停止状態）にあるコピー要求元ゲストＯＳ＃１の状態（ゲストＯＳ＃１の実行状態及びゲストＯＳ＃１が使用する全てのメモリの状態）をコピーする（ステップＳ３）。即ちゲストＯＳコピー部３１１は、図２において矢印２２で示されるように、仮想計算機実行環境３２-3（ＶＭ＃３）を構築して、当該実行環境３２-3（ＶＭ＃３）にゲストＯＳ＃１（３４０-1）の状態をコピーする。これにより仮想計算機実行環境３２-3（ＶＭ＃３）に、コピー要求元ゲストＯＳ＃１（３４０-1）と全く同一の構造を持つゲストＯＳ＃１’（３４０-3）が生成される。

ＶＭＭ３１のゲストＯＳコピー部３１１は、上記ステップＳ３においてコピーを行うと、即ちゲストＯＳ＃１のコピーであるゲストＯＳ＃１’を生成すると、ゲストＯＳ起動／停止部３１１ａを用いて当該ゲストＯＳ＃１’を停止状態にする。ゲストＯＳコピー部３１１は、ステップＳ３を実行すると、ゲストＯＳ起動／停止部３１１ａを用いて、コピー要求元ゲストＯＳ＃１を実行可能状態にして、処理を終了する（ステップＳ４）。

このように本実施形態では、ゲストＯＳ＃１からＶＭＭ３１へのコピー要求に応じ、当該ＶＭＭ３１のゲストＯＳコピー部３１１によって、ゲストＯＳ＃１と全く同一の構造を持つゲストＯＳ＃１’が仮想計算機実行環境３２-3（ＶＭ＃１）に生成され、且つ当該ゲストＯＳ＃１’が停止した状態に設定される。このゲストＯＳ＃１’は、メモリデータや実行状態がコピー要求元のゲストＯＳ＃１がコピーを要求したときと全く同じ状態にある。したがって、このゲストＯＳ＃１’を解析することにより、その瞬間のゲストＯＳ＃１の状態を詳しく調べることができる。

さて本実施形態では、ゲストＯＳ＃１はコピー時だけ一時的に実行されない状態に設定されるものの、コピーが終了すると実行可能状態にされる。したがってゲストＯＳ＃１は、コピー終了後直ちに処理を再開できる。このため、本実施形態においては、ゲストＯＳ＃１は、例えばサービスを続けながら、解析したい状況が発生した瞬間にＶＭＭ３１に対してコピー要求を送出することで、当該ゲストＯＳ＃１のコピーであるゲストＯＳ＃１'をＶＭＭ３１によって構築させて、その瞬間の当該ゲストＯＳ＃１の状態を保存させ、その後の任意の時点でゲストＯＳ＃１'を解析（デバッグ）することができる。この場合、ゲストＯＳ＃１を停止せずに、決定的瞬間をデバッグできる。このゲストＯＳ＃１'を対象とするデバッグは、図２において矢印２３で示されるように、ゲストＯＳ＃１自身が行うことも、ゲストＯＳ＃１以外のゲストＯＳ、例えば図２において矢印２４で示されるように、ゲストＯＳ＃２が行うことも可能である。ここで、ゲストＯＳ＃１'はゲストＯＳ＃１のコピーである。したがって本実施形態においては、解析したい瞬間のゲストＯＳ＃１の状態を、当該ゲストＯＳ＃１の動作を止めることなく解析することができる。

なお、ゲストＯＳ＃１からＶＭＭ３１へのコピー要求が、上記ケース(2)に該当する状態で送出された場合にも、図３のフローチャートに示す手順で、仮想計算機実行環境３２-3が生成されて、当該環境３２-3にゲストＯＳ＃１のパニックを発生した際の状態がゲストＯＳ＃１’として保存される。この場合でも、このゲストＯＳ＃１'をゲストＯＳ＃２からデバッグすることが可能となる。また、コピー終了後にゲストＯＳ＃１をリブートするならば、そのリブート後のゲストＯＳ＃１からゲストＯＳ＃１'をデバッグすることも可能である。本実施形態では、例えば、組み込み用途のシステムで、大きな容量の外部デバイスが接続されておらずダンプが残せないときなどでも、メモリを使用してパニック時の状態をゲストＯＳ＃１'として保存でき、その後の任意の時点で当該ゲストＯＳ＃１'を解析することで、等価的にゲストＯＳ＃１を解析することができる。

上記実施形態では、ゲストＯＳ＃１からコピー要求が送出された場合を想定している。しかし、ゲストＯＳ＃２のような、ゲストＯＳ＃１以外のゲストＯＳからコピー要求が送出された場合にも、同様の動作が行われることは勿論である。

［第１の変形例］
上記実施形態では、ゲストＯＳ＃１が上記ケース(1)または(2)に該当する状態となった場合に、当該ゲストＯＳ＃１からＶＭＭ３１に送出されるコピー要求に応じて、ＶＭＭ３１によるコピー処理が実行される。しかし、上記の状態を、ＶＭＭ３１自身が検出して、当該ＶＭＭ３１が自律的にコピー処理を行う構成とすることも可能である。

そこで、ゲストＯＳ＃１からコピー要求が送出されなくても、当該ゲストＯＳ＃１の異常時にＶＭＭ３１が自律的にコピー処理を行うことを可能とした、上記実施形態の第１の変形例について、図面を参照して説明する。

図４は、動作の概要を示す、図２に対応する図である。図４において、図２と等価な要素には同一符号を付してある。図４に示すように、ＶＭＭ３１には、任意のゲストＯＳ＃ｉ（３４０-i）が正常に稼動しているか否かを監視するためのゲストＯＳ応答監視部３１２が追加されている。一方、ゲストＯＳ＃１（３４０-1），＃２（３４０-2）には、コピー要求部３４１（図２参照）に代えて、それぞれ応答部３４２が設けられている。

応答部３４２はＶＭＭ３１に対して、一定期間内に少なくとも１回応答を通知するように構成されている。ゲストＯＳ応答監視部３１２は、各ゲストＯＳ＃ｉの応答部３４２からの応答を監視し、一定期間内に少なくとも１回応答が通知される場合に、「ゲストＯＳ＃ｉが正常に動作している」ことを認識する。応答部３４２は、例えば、ＶＭＭ３１を呼び出すための特別なＶＭＭコールを、ゲストＯＳ＃ｉが一定時間内にコールすることにより実現される。この特別なＶＭＭコールは、例えばゲストＯＳ＃ｉがＶＭＭ３１のサービスを利用するために用意された、ＶＭＭ３１によって提供される、当該ゲストＯＳ＃ｉが使用可能なインタフェースである。この他に、ＶＭＭ３１とゲストＯＳ＃ｉとの共有変数（ゲストＯＳ＃ｉとＶＭＭ３１の両者が参照できるメモリ領域）を設けて、ゲストＯＳ＃ｉの応答部３４２がその値を一定周期でインクリメントなどして変化させるようにしても良い。この場合、ＶＭＭ３１のゲストＯＳ応答監視部３１２は、共有変数の値の変化によりＶＭＭ３１が「ゲストＯＳ＃ｉの応答」であると判断し、共有変数の値が一定時間以上更新されなかった場合にゲストＯＳ＃ｉの異常と判断することができる。

次に、第１の変形例におけるゲストＯＳのデバッグを支援するためのコピー処理について、図４に加えて図５のフローチャートを参照して説明する。
ＶＭＭ３１のゲストＯＳ応答監視部３１２は、監視対象のゲストＯＳ、例えばゲストＯＳ＃１及び＃２の応答部３４２から、一定期間内に応答があるかを監視する（ステップＳ１１）。もし、一定期間内に応答がなかったゲストＯＳ＃ｉを検出したならば、ＶＭＭ３１のゲストＯＳ応答監視部３１２は、当該ゲストＯＳ＃ｉの異常を判断する。ここでは、ゲストＯＳ＃１が異常であると判断されたものとする。この場合、ゲストＯＳ応答監視部３１２からゲストＯＳコピー部３１１に、図４において矢印４１で示されるように、ゲストＯＳ＃１の異常を通知する。

するとゲストＯＳコピー部３１１は、上記ステップＳ１と同様に、ゲストＯＳ起動／停止部３１１ａを用いて、ゲストＯＳ＃１を実行されない状態（停止状態）にする（ステップＳ１２）。次にゲストＯＳコピー部３１１は、上記ステップＳ２と同様に、仮想計算機システム内に、新たに仮想計算機実行環境ＶＭ＃３を構築する（ステップＳ１３）。そしてゲストＯＳコピー部３１１は、上記ステップＳ３と同様に、仮想計算機実行環境ＶＭ＃３に、停止状態にあるゲストＯＳ＃１の状態をコピーする（ステップＳ１４）。即ちゲストＯＳコピー部３１１は、図４において矢印４２で示されるように、仮想計算機実行環境３２-3（ＶＭ＃３）を構築して、当該実行環境３２-3（ＶＭ＃３）にゲストＯＳ＃１の状態をコピーする。ステップＳ１４において、ゲストＯＳコピー部３１１内のゲストＯＳ起動／停止部３１１ａは、ゲストＯＳ＃１のコピー、即ちゲストＯＳ＃１’を停止状態にする。ゲストＯＳ起動／停止部３１１ａは、ゲストＯＳ＃１のコピー（ゲストＯＳ＃１’）を停止状態にすると、図４において矢印４３で示されるように、ゲストＯＳ＃１（つまりゲストＯＳ応答監視部３１２によって異常が判断されたゲストＯＳ＃１）を強制的にリブートする（ステップＳ１５）。

このように第１の変形例によれば、ゲストＯＳ＃１内部の問題などにより、当該ゲストＯＳ＃１がハングして当該ゲストＯＳ＃１の応答部３４２からＶＭＭ３１に対して一定期間内に応答を通知できなくなった異常発生時に、ＶＭＭ３１のゲストＯＳ応答監視部３１２により、その異常状態が検出される。そして、そのゲストＯＳ＃１の状態が、ＶＭＭ３１のゲストＯＳコピー部３１１によって新しく構築されたＶＭ＃３にゲストＯＳ＃１のコピー（ゲストＯＳ＃１’）として複製され保存される。一方、ゲストＯＳ＃１はＶＭＭ３１によって強制的にリブートされる。これによりゲストＯＳ＃１は、リブート後には再びサービス等の必要な処理を再開することができる。またゲストＯＳ＃１は、保存されたゲストＯＳ＃１の複製を対象として、その状態で、デバッガ或いは専用のツールで解析することができる。つまりゲストＯＳ＃１は、当該ゲストＯＳ＃１のサービスを継続したまま、当該ゲストＯＳ＃１の問題解析を行うことができる。また、この第１の変形例においても、上記実施形態と同様に、ダンプを残す仕組みがないシステムにおいて、問題が発生した状態をゲストＯＳ＃１のコピーとしてメモリ上に保存したまま、問題を起こした当該ゲストＯＳ＃１をリブートすることがきる。つまり、ゲストＯＳ＃１のサービスの継続と同時に、問題解析のための情報を残すことができる。なお、解析は、図４において矢印４４で示されるように、リブート後のゲストＯＳ＃１自身が行うことも、ゲストＯＳ＃１以外のＯＳ、例えば図４において矢印４５で示されるように、ゲストＯＳ＃２が行うことも可能である。

上記第１の変形例では、ゲストＯＳ＃１の異常が検出された場合を想定している。しかし、ゲストＯＳ＃２のような、ゲストＯＳ＃１以外のゲストＯＳの異常が検出された場合にも、同様の動作が行われることは勿論である。

［第２の変形例］
上記実施形態の第１の変形例では、ゲストＯＳ＃ｉの応答部３４２からの応答をＶＭＭ３１のゲストＯＳ応答監視部３１２が監視し、その監視結果から当該ゲストＯＳ＃ｉの異常が検出された場合に、ＶＭＭ３１のゲストＯＳコピー部３１１がゲストＯＳ＃ｉのコピーを生成する構成を適用している。しかし、ゲストＯＳ＃ｉの状態に無関係に、ゲストＯＳ＃ｉのコピーを一定期間毎に時系列順に生成し、最新の一定数のコピーを保存する構成とすることも可能である。

そこで、ゲストＯＳ＃ｉのコピーを一定期間毎に生成して、最新の一定数のコピーを仮想計算機実行環境に保存するようにした、上記実施形態の第２の変形例について、図面を参照して説明する。

図６は、動作の概要を示す、図２に対応する図である。図６において、図２と等価な要素には同一符号を付してある。図６には、ゲストＯＳ３４０-1（ゲストＯＳ＃１）のコピーである、３つのゲストＯＳ３４０-4，３４０-5及び３４０-6として、ゲストＯＳ＃１（ｋ−１）、ゲストＯＳ＃１（ｋ）及びゲストＯＳ＃１（ｋ＋１）が、ＶＭＭ３１のゲストＯＳコピー部３１１によって生成されている状態が示されている。ここで、ｋ−１，ｋ，ｋ＋１（ｋは１以上の整数）はコピーの世代を表している。つまり、図６は、矢印６１，６２及び６３で示されるように、時点ｔ（ｋ−１），ｔ（ｋ）及びｔ（ｋ＋１）の順に、ゲストＯＳ＃１のコピーである、３つのゲストＯＳ＃１（ｋ−１）、ゲストＯＳ＃１（ｋ）及びゲストＯＳ＃１（ｋ＋１）が生成されている状態を示す。

ゲストＯＳ＃１のコピーの保存に利用可能なメモリ等のシステムのリソースには限りがある。このため、システムに許される、保存可能なゲストＯＳ＃１のコピーの数には制限がある。図６の例では、保存可能なゲストＯＳ＃１のコピーは３つである。したがって、次の時点ｔ（ｋ＋２）では、その時点で最も古いコピーであるゲストＯＳ＃１（ｋ−１）が削除され、代わりにゲストＯＳ＃１（ｋ＋２）が作成される。

なお、図６では、ゲストＯＳ＃１のコピーである、３つのゲストＯＳ＃１（ｋ−１）、ゲストＯＳ＃１（ｋ）及びゲストＯＳ＃１（ｋ＋１）が生成される仮想計算機実行環境と、ゲストＯＳ＃２は省略されている。

次に、第２の変形例におけるゲストＯＳのコピーについて、図６に加えて図７のフローチャートを参照して説明する。ここでは、説明を簡略化するために、コピー対象がゲストＯＳ＃１のみであるものとする。

ＶＭＭ３１のゲストＯＳコピー部３１１は、一定期間毎に、コピー対象となるゲストＯＳ＃１が異常であるかを判定する（ステップＳ２１，Ｓ２２）。このゲストＯＳ＃１が異常であるかを判定する方法については後述する。もし、ゲストＯＳ＃１が異常でなければ、ゲストＯＳコピー部３１１はゲストＯＳ＃１のコピーが既に３世代分メモリに保存されているか判定する（ステップＳ２３）。もし、ゲストＯＳ＃１のコピーが未だ３世代分保存されていないならば、ゲストＯＳコピー部３１１は、上記実施形態におけるステップＳ１乃至Ｓ３と同様のステップＳ２５乃至Ｓ２７により、ゲストＯＳ＃１を実行されない状態（停止状態）にした後、当該ゲストＯＳ＃１のコピーを仮想計算機実行環境に生成して、当該コピーを停止状態にする。そしてゲストＯＳコピー部３１１は、ゲストＯＳ＃１を実行可能な状態にする（ステップＳ２８）。

ゲストＯＳコピー部３１１は、ゲストＯＳ＃１のコピーが既に３世代分保存されるまでは（ステップＳ２３）、当該ゲストＯＳ＃１が異常とならない限り（ステップＳ２２）、一定期間毎に（ステップＳ２１）、上記ステップＳ２５乃至２８を繰り返す。そして、図６に示すように、ゲストＯＳ＃１のコピーが、ゲストＯＳ＃１（ｋ−１）、ゲストＯＳ＃１（ｋ）及びゲストＯＳ＃１（ｋ＋１）の３世代分生成されてメモリに保存されたものとする。この状態で、ゲストＯＳ＃１の次のコピーであるゲストＯＳ＃１（ｋ＋２）を生成する必要がある場合、ゲストＯＳコピー部３１１はまず、その時点で最も古いゲストＯＳ＃１（ｋ−１）を削除する（ステップＳ２４）。しかる後に、ゲストＯＳコピー部３１１は、上記ステップＳ２５乃至Ｓ２７により、ゲストＯＳ＃１の最新のコピーであるゲストＯＳ＃１（ｋ＋２）を生成する。

このようにして、ゲストＯＳ＃１が正常である限り（ステップＳ２２）、当該ゲストＯＳ＃１についての最新の３つの世代のコピーが常に残される。ここで、ゲストＯＳ＃１の処理がパニック等の異常発生により停止する場合を考える。ゲストＯＳコピー部３１１は、このゲストＯＳ＃１の異常発生を検出する必要がある。ゲストＯＳコピー部３１１がゲストＯＳ＃１の異常を検出する方法として、例えば次のような方法、即ち
(1) ゲストＯＳ＃１が異常発生時に特別なＶＭＭコールを呼び出して、ＶＭＭ３１に異常発生を通知する方法
(2) 上記第１の変形例で適用された、（ゲストＯＳ＃１内の応答部３４２と、ＶＭＭ３１内のゲストＯＳ応答監視部３１２とを用いて）ゲストＯＳ＃１の異常を判断する方法
が適用可能である。

ゲストＯＳコピー部３１１は、ゲストＯＳ＃１の異常を検出すると（ステップＳ２２）、それ以降新たなゲストＯＳ＃１のコピーを作らないようにする。その結果、ゲストＯＳ＃１の異常が検出された時点において既に保存されている当該ゲストＯＳ＃１の３世代のコピーを使って、当該ゲストＯＳ＃１を解析することができる。もし、ゲストＯＳ＃１（ｋ＋１）が生成されて保存された後に、ゲストＯＳ＃１の異常が検出されたものとすると、当該ゲストＯＳ＃１に異常が発生する直前の時点ｔ（ｋ−１），ｔ（ｋ）及びｔ（ｋ＋１）における当該ゲストＯＳ＃１の状態が、それぞれゲストＯＳ＃１（ｋ−１）、ゲストＯＳ＃１（ｋ）及びゲストＯＳ＃１（ｋ＋１）に保存されている。ユーザは、これらゲストＯＳ＃１の３つのコピーに対して、デバッガ或いはアナライザを用いて、上記第１の変形例と同様にして、ゲストＯＳ＃１、またはゲストＯＳ＃２のようなゲストＯＳ＃１以外のゲストＯＳにより、当該ゲストＯＳ＃１の問題の解析を行うことができる。一度に保存できるゲストＯＳのコピーの数が多いほど、問題発生時から時間的により遡った時点での状態を観測することができるため、いつの時点で何が起こったのかを知る手がかりが得られる可能性がある。これは従来のデバッグ手法にはなかった利点である。

また、デバッガ（のステップ実行等）により、保存されているゲストＯＳ＃１の状態を進めることで、何が起こるか再現することも可能である。その場合、例えばゲストＯＳ＃１（ｋ＋１）から問題発生までの間の様子を調べるためには、予めゲストＯＳ＃１（ｋ＋１）のコピーを新たに作り、その新しいコピーのゲストＯＳ＃１（ｋ＋１）の状態を進めるようにすると良い。このようにすると、何回でもゲストＯＳ＃１（ｋ＋１）の時点のコンテクストから解析を進めることが可能になる。

［第３の変形例］
次に、ゲストＯＳ＃１のコピーを時系列順に生成して一定数を保存するだけでなく、ゲストＯＳ毎のＩ／Ｏ（入出力）の履歴をも保存するようにした、上記実施形態の第３の変形例について図面を参照して説明する。

図８は、動作の概要を示す、図６に対応する図である。図８において、図６と等価な要素には同一符号を付してある。図８には、ゲストＯＳ＃１のコピーである３つのゲストＯＳ＃１（ｋ−１）、ゲストＯＳ＃１（ｋ）及びゲストＯＳ＃１（ｋ＋１）が生成されている状態に加えて、ＶＭＭ３１内に、Ｉ／Ｏ履歴バッファ３１３と、当該Ｉ／Ｏ履歴バッファ３１３のコピーである３つのＩ／Ｏ履歴バッファ３１３（ｋ−１），３１３（ｋ），３１３（ｋ＋１）が存在する状態が示されている。なお、図８においても、上記図６と同様に、ゲストＯＳ＃１（ｋ−１）、ゲストＯＳ＃１（ｋ）及びゲストＯＳ＃１（ｋ＋１）が生成される仮想計算機実行環境と、ゲストＯＳ＃２は省略されている。

Ｉ／Ｏ履歴バッファ３１３は、ゲストＯＳ＃１における一定期間毎のＩ／Ｏの履歴（Ｉ／Ｏ履歴）を記録するのに用いられる。ここでは、図７において、矢印７１で示されるように、ゲストＯＳ＃１のＩ／Ｏ事象が発生すると、つまりＶＭＭ３１がゲストＯＳ＃１のＩ／Ｏのために仮想Ｉ／Ｏ装置３３２-1のエミュレートを行うと、当該仮想Ｉ／Ｏ装置３３２-1により、図７において矢印７２で示されるように、ゲストＯＳ＃１のＩ／Ｏ履歴（ログ）がＩ／Ｏ履歴バッファ３１３に記録される。Ｉ／Ｏ履歴バッファ３１３はメモリ上に配置される。つまり、Ｉ／Ｏ履歴は、メモリ上のデータ列として記録される。

Ｉ／Ｏ履歴バッファ３１３には、例えば以下のフォーマット（ログレコード）
「Ｉ／Ｏ事象発生時刻、Ｉ／Ｏデバイスの種類、事象の種類、入出力データ」
で、Ｉ／Ｏのログが記録される。「事象の種類」は、「割り込み発生」、「ＤＭＡ開始／完了」を含む。本実施形態では、データ入出力を伴うＩ／Ｏ事象が発生した場合、可能な限り、そのデータも記録される。ここでは、一定サイズ以下の入出力データは記録される。Ｉ／Ｏ履歴バッファ３１３には、上述のログレコードが、時系列順に記録される。

ゲストＯＳコピー部３１１は、上記第２の変形例と同様の手順で、時点ｔ（ｋ−１），ｔ（ｋ）及びｔ（ｋ＋１）で、図７において矢印７３-1，７３-2及び７３-3に示すように、ゲストＯＳ＃１のコピーであるゲストＯＳ＃１（ｋ−１）、ゲストＯＳ＃１（ｋ）及びゲストＯＳ＃１（ｋ＋１）を順に生成する際には、図７において矢印７４-1，７４-2及び７４-3に示すように、Ｉ／Ｏ履歴バッファ３１３のコピーである、Ｉ／Ｏ履歴バッファ３１３（ｋ−１），３１３（ｋ）及び３１３（ｋ＋１）を併せて生成する。ここで、Ｉ／Ｏ履歴バッファ３１３は、当該Ｉ／Ｏ履歴バッファ３１３のコピーが生成される都度、クリアされる。したがって、例えばＩ／Ｏ履歴バッファ３１３（ｋ）には、時点ｔ（ｋ−１）、つまりゲストＯＳ＃１（ｋ−１）の生成時から、時点ｔ（ｋ）、つまりゲストＯＳ＃１（ｋ）の生成時までに発生したゲストＯＳ＃１のＩ／Ｏの履歴が記録される。同様に、Ｉ／Ｏ履歴バッファ３１３（ｋ＋１）には、時点ｔ（ｋ）、つまりゲストＯＳ＃１（ｋ）の生成時から、時点ｔ（ｋ＋１）、つまりゲストＯＳ＃１（ｋ＋１）の生成時までに発生したゲストＯＳ＃１のＩ／Ｏの履歴が記録される。Ｉ／Ｏ履歴バッファ３１３，３１３（ｋ−１），３１３（ｋ）及び３１３（ｋ＋１）は、ゲストＯＳ、例えばゲストＯＳ＃１のデバッガからＶＭＭ３１に問い合わせることにより、ユーザが参照することが可能なようになっている。

次に、ゲストＯＳ＃１のコピーに加えて、Ｉ／Ｏ履歴バッファ３１３のコピーを利用して行われる、当該ゲストＯＳ＃１のデバッグについて説明する。例えばドライバにバグが存在する場合、Ｉ／Ｏ処理に伴って状態が異常となる虞がある。今、図７において矢印７５で示すように、ゲストＯＳ＃１（ｋ−１）及びゲストＯＳ＃１（ｋ）（つまりゲストＯＳ＃１の２つのコピーイメージ（ｋ−１）及び（ｋ））をゲストＯＳ＃１のデバッガで解析したところ、ゲストＯＳ＃１（ｋ）には、既にバグの影響が確認できたとする。またゲストＯＳ＃１（ｋ−１）には、まだバグの影響が見えなかったとする。この場合、ゲストＯＳ＃１（ｋ−１）及びゲストＯＳ＃１（ｋ）の間、つまりゲストＯＳ＃１の２つのコピーイメージ（ｋ−１）及び（ｋ）間でバグの発生があったと考えられる。

そこで、ゲストＯＳ＃１のコピーイメージ（ｋ−１）と（ｋ）との間に発生したＩ／Ｏ事象を知りたくなる場合がある。この場合、図７において矢印７６で示すように、Ｉ／Ｏ履歴バッファ３１３（ｋ）をゲストＯＳ＃１のデバッガで参照することにより、どのようなＩ／Ｏ事象が発生したか確認することができる。つまり、Ｉ／Ｏ履歴バッファ３１３（ｋ）をゲストＯＳ＃１の解析のための情報とすることができる。

更に、ゲストＯＳ＃１のデバッガが、ゲストＯＳ＃１（ｋ−１）の状態から、例えばステップ実行によって徐々に処理を進めて、状態の変化を調べるならば、バグ発生の瞬間を観察することができるかも知れない。但し、そのためには、Ｉ／Ｏを含めて、ゲストＯＳ（ｋ−１）の生成時よりゲストＯＳ＃１（ｋ）の生成時までの間に発生したゲストＯＳ＃１に関係する全ての事象を再現できなければならない。プロセッサの処理に関しては、ＶＭＭ３１が提供する仮想プロセッサ３３１-1が命令列を実行するだけなので処理の再現の点では問題ない。これに対し、Ｉ／Ｏに関しては、仮想Ｉ／Ｏ装置３３２-1がＩ／Ｏ事象を発生させる必要がある。

そこで、第３の変形例では、仮想Ｉ／Ｏ装置３３２-1は、Ｉ／Ｏ履歴バッファを参照することにより、そこに記録されたＩ／Ｏ事象を、当該Ｉ／Ｏ事象がＩ／Ｏ履歴バッフに記録された時刻に再現するように構成されている。このようにすると、Ｉ／Ｏを含めてゲストＯＳ＃１の状態の再現が可能になり、より詳しくゲストＯＳ＃１の状態を再現することが可能になる。

例えば、ゲストＯＳ＃１（ｋ−１）をデバッグ対象にして、その状態を進めながらゲストＯＳ＃１の状態変化を調べる際には、図７において矢印７７で示されるように、仮想Ｉ／Ｏ装置３３２-1がＩ／Ｏ履歴バッファ３１３（ｋ）を参照して、ゲストＯＳ＃１の処理再現時に忠実にＩ／Ｏ事象も再現するようにする。Ｉ／Ｏ履歴バッファ３１３（ｋ）を参照する理由は、当該Ｉ／Ｏ履歴バッファ３１３（ｋ）には、ゲストＯＳ＃１（ｋ−１）の生成時から次のゲストＯＳ＃１（ｋ）の生成時までの間に発生したゲストＯＳ＃１のＩ／Ｏの履歴が記録されているためである。
このように第３の変形例においては、Ｉ／Ｏを含めて異常発生までの状況を再現できるようにすることで、問題の解析を一層容易にすることができる。

上記実施形態では、ＶＭＭ３１が、ＯＳ２０上で動作する１つのアプリケーション（ＶＭアプリケーション）として実装される場合を想定している。しかし本発明は、ＶＭＭ（仮想計算機マネージャ）が、計算機システムの実ＨＷ上にＶＭＭ機構として実装される場合にも、同様に適用可能である。

なお、本発明は、上記実施形態及びその変形例そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態及びその変形例に開示されている複数の構成要素の適宜な組み合せにより種々の発明を形成できる。例えば、実施形態またはその変形例に示される全構成要素から幾つかの構成要素を削除してもよい。更に、異なる実施形態（変形例）に亘る構成要素を適宜組み合せてもよい。

本発明の一実施形態に係る仮想計算機システムを実現する計算機システム１の構成を示すブロック図。 同実施形態におけるゲストＯＳのデバッグを支援するためのコピー処理の概要を示す図。 同実施形態におけるコピー処理の手順を示すフローチャート。 同実施形態の第１の変形例におけるコピー処理の概要を示す図。 同第１の変形例におけるコピー処理の手順を示すフローチャート。 同実施形態の第２の変形例におけるコピー処理の概要を示す図。 同第２の変形例におけるコピー処理の手順を示すフローチャート。 同実施形態の第３の変形例におけるコピー処理の概要を示す図。

符号の説明

１…計算機システム、３０…ＶＭアプリケーション、３１…ＶＭＭ（仮想計算機マネージャ）、３２-1，３２-2，３２-3…仮想計算機実行環境、３３-1，３３-2…仮想ＨＷ（ハードウェア）環境、３１１…ゲストＯＳコピー部、３１１ａ…ゲストＯＳ起動／停止部、３１２…ゲストＯＳ応答監視部、３１３…Ｉ／Ｏ履歴バッファ、３１３（ｋ−１），３１３（ｋ），３１３（ｋ＋１）…Ｉ／Ｏ履歴バッファ（Ｉ／Ｏ履歴バッファ３１３のコピー），３３２-1，３３２-2…仮想Ｉ／Ｏ装置、３４０-1，３４０-2…ゲストＯＳ、３４０-3，３４０-4，３４０-5，３４０-6…ゲストＯＳ（ゲストＯＳ＃１のコピー）、３４１…コピー要求部、３４２…応答部。

Claims (12)

1. 仮想計算機マネージャによって提供される仮想計算機実行環境で動作するゲストＯＳのデバッグを支援するゲストＯＳデバッグ支援方法であって、
   第１のゲストＯＳが動作する第１の仮想計算機実行環境とは異なる第２の仮想計算機実行環境を前記仮想計算機マネージャが構築するステップと、
   前記仮想計算機マネージャが、前記第１のゲストＯＳを、当該第１のゲストＯＳの実行状態及び当該第１のゲストＯＳが使用するメモリの状態を含めて、前記第２の仮想計算機実行環境にコピーすることにより、前記第１のゲストＯＳのコピーである第２のゲストＯＳを前記第２の仮想計算機実行環境に生成するステップと、
   前記第２の仮想計算機実行環境に生成された前記第２のゲストＯＳを停止状態にして当該第２のゲストＯＳの状態を保存するステップと
   を具備することを特徴とするゲストＯＳデバッグ支援方法。
2. 前記第１のゲストＯＳのコピーである前記第２のゲストＯＳを生成する前に、前記仮想計算機マネージャが前記第１のゲストＯＳを実行されない状態にするステップを更に具備することを特徴とする請求項１記載のゲストＯＳデバッグ支援方法。
3. 前記第２のゲストＯＳを生成した後に、前記仮想計算機マネージャが前記第１のゲストＯＳを実行可能状態にするステップを更に具備し、
   前記第２のゲストＯＳを生成するステップが前記第１のゲストＯＳからの要求に応じて実行されることを特徴とする請求項２記載のゲストＯＳデバッグ支援方法。
4. 前記第２のゲストＯＳを生成した後に、前記仮想計算機マネージャが前記第１のゲストＯＳをリブートするステップを更に具備し、
   前記第２のゲストＯＳを生成するステップが前記第１のゲストＯＳの異常発生に伴う当該第１のゲストＯＳからの要求に応じて実行されることを特徴とする請求項２記載のゲストＯＳデバッグ支援方法。
5. 前記第１のゲストＯＳの異常を前記仮想計算機マネージャが検出するステップと、
   前記第２のゲストＯＳを生成した後に、前記仮想計算機マネージャが前記第１のゲストＯＳを強制的にリブートするステップとを更に具備し、
   前記第２のゲストＯＳを生成するステップが前記第１のゲストＯＳの異常検出に応じて実行されることを特徴とする請求項２記載のゲストＯＳデバッグ支援方法。
6. 前記第２のゲストＯＳを生成した後に、前記仮想計算機マネージャが前記第１のゲストＯＳを実行可能状態にするステップと、
   前記実行可能状態にされた前記第１のゲストＯＳ、または前記第１の仮想計算機実行環境とは異なる別の仮想計算機実行環境で動作中の別のゲストＯＳが、停止状態にある前記第２のゲストＯＳをデバッグするステップと
   を更に具備することを特徴とする請求項２記載のゲストＯＳデバッグ支援方法。
7. 前記第２のゲストＯＳを生成した後に、前記仮想計算機マネージャが前記第１のゲストＯＳを実行可能状態にするステップと、
   前記第１のゲストＯＳの異常を前記仮想計算機マネージャが検出するステップとを更に具備し、
   前記第２のゲストＯＳを生成するステップが、前記第１のゲストＯＳの異常が検出されるまでの期間、予め定められた時間間隔で、前記第１のゲストＯＳのコピー先となる前記第２の仮想計算機実行環境を、一定数の第２の仮想計算機実行環境の範囲内で切り替えながら実行される
   ことを特徴とする請求項２記載のゲストＯＳデバッグ支援方法。
8. 前記第２の仮想計算機実行環境に生成された、前記第１のゲストＯＳのコピーである前記第２のゲストＯＳから、そのコピーである第３のゲストＯＳをデバッグ対象として生成するステップを更に具備することを特徴とする請求項７記載のゲストＯＳデバッグ支援方法。
9. 前記第２のゲストＯＳの生成時点から次の前記第２のゲストＯＳの生成時点までの間に発生した前記第１のゲストＯＳの入出力処理の履歴を仮想入出力装置によって入出力履歴バッファに記録するステップと、
   前記第１のゲストＯＳのコピーである前記第２のゲストＯＳが生成される際に、その時点における入出力履歴バッファのコピーを採取して保存するステップと
   を更に具備することを特徴とする請求項７記載のゲストＯＳデバッグ支援方法。
10. 前記入出力履歴バッファのコピーに記録されている前記第１のゲストＯＳの入出力の履歴に基づき、前記第１のゲストＯＳの入出力発生の事象を再現するステップを更に具備することを特徴とする請求項９記載のゲストＯＳデバッグ支援方法。
11. ゲストＯＳが動作する仮想計算機実行環境を構築する仮想計算機マネージャにおいて、
    第１の仮想計算機実行環境で動作する第１のゲストＯＳのコピー先となる、前記第１の仮想計算機実行環境とは異なる第２の仮想計算機実行環境を構築する仮想計算機実行環境構築手段と、
    前記第１のゲストＯＳを、当該第１のゲストＯＳの実行状態及び当該第１のゲストＯＳが使用するメモリの状態を含めて、前記第２の仮想計算機実行環境にコピーすることにより、前記第１のゲストＯＳのコピーである第２のゲストＯＳを前記第２の仮想計算機実行環境に生成するゲストＯＳコピー手段と、
    前記ゲストＯＳコピー手段によって前記第２の仮想計算機実行環境に生成された前記第２のゲストＯＳを停止状態にして当該第２のゲストＯＳの状態を保存するゲストＯＳ停止手段と
    を具備することを特徴とする仮想計算機マネージャ。
12. 前記ゲストＯＳ停止手段は、前記ゲストＯＳコピー手段により前記第１のゲストＯＳのコピーである前記第２のゲストＯＳが生成される前に、前記第１のゲストＯＳを実行されない状態にし、
    前記仮想計算機マネージャは、前記ゲストＯＳコピー手段により前記第２のゲストＯＳが生成された後に前記第１のゲストＯＳを実行可能状態にするゲストＯＳ起動手段を更に具備する
    ことを特徴とする請求項１１記載の仮想計算機マネージャ。

Images