JP2008033392A - 仮想計算機システム及びその動作方法 - Google Patents

Abstract

【課題】カーネルイメージの共有が可能か否かの判定を自動的に行う仮想計算機システムを提供すること。
【解決手段】本発明に係る仮想計算機システムは、物理メモリ６０１とＶＭＭ３０１とを備える。ＶＭＭ３０１は、物理メモリ６０１上にロードされているカーネルイメージの状態を示す管理テーブル７０１を有する。ゲストＯＳの起動時、ＶＭＭ３０１は、管理テーブル７０１を参照することによって、そのゲストＯＳのカーネルイメージと同一のカーネルイメージが物理メモリ６０１上に存在するか否かを判定する。
【選択図】図８

Description

本発明は、仮想計算機システム及びその動作方法に関する。特に、本発明は、仮想計算機環境における資源管理技術に関する。

近年、計算機の仮想化技術が注目されている。その仮想化技術によれば、１台の実計算機上に複数の計算機を仮想的に構築し、複数のＯＳを独立に稼動させることが可能となる。実計算機（Real Machine）に対して、その仮想的な計算機は、「仮想計算機（VM: Virtual Machine）」と呼ばれている。ＶＭは、実計算機上で動作するソフトウェアである「仮想マシンモニタ（ＶＭＭ：Virtual Machine Monitor）」によって構築され、また、制御される。実計算機上で動作するＯＳ（ホストＯＳ）に対して、ＶＭＭによって提供されるＶＭ上で稼動するＯＳは、「ゲストＯＳ」と呼ばれる。

同一の実計算機上において、複数のＶＭはそれぞれ独立したマシンとして動作することを前提として構築される。複数のＶＭが互いに完全に隔離されるため、基本的には、ＶＭ毎にメモリ資源を準備する必要がある。

図１は、従来のＶＭ環境におけるメモリ資源の割り当てを概念的に示している。同一の実計算機上で２つのＶＭ（ＶＭ１，ＶＭ２）が動作している。ＶＭＭは、マッピングテーブルを用いることによって、ＶＭが有する仮想メモリの物理アドレス空間と、実計算機が有する物理メモリの実物理アドレス空間とのマッピングを行う。例えば、ＶＭ１物理アドレス空間におけるカーネルテキスト部の先頭アドレス“ｘｘｘ”は、実物理アドレス空間におけるアドレス“ＡＤＤ１”にマッピングされている。一方、ＶＭ２物理アドレス空間におけるカーネルテキスト部の先頭アドレス“ｙｙｙ”は、実物理アドレス空間におけるアドレス“ＡＤＤ２”にマッピングされている。

このように、実物理アドレス空間において、ＶＭ１のカーネルテキスト部とＶＭ２のカーネルテキスト部には別々の領域が割り当てられている。ＶＭ１とＶＭ２上で稼動しているゲストＯＳが同じ場合、すなわち、ＶＭ１とＶＭ２との間でカーネルテキスト部が同一である場合、そのカーネルテキスト部のメモリイメージが物理メモリ上で重複することになる。言い換えれば、複数のＶＭ上に同一のカーネルテキストがロードされる場合、メモリ資源が有効に活用されない。

そこで、物理メモリ上の同一のメモリイメージを複数のＶＭ間で共有させることが提案されている。図２は、メモリイメージの共有を概念的に示している。図２で示される例の場合、ＶＭ２に関するマッピングテーブルにおいて、ＶＭ２物理アドレス空間におけるアドレス“ｙｙｙ”は、実物理アドレス空間におけるアドレス“ＡＤＤ１”に対応付けられている。その結果、ＶＭ２がカーネルテキスト部を参照する際、ＶＭＭは、実物理アドレス空間のアドレス“ＡＤＤ１”から始まる領域にアクセスする。つまり、ＶＭ１とＶＭ２は、物理メモリ上のカーネルテキスト部を共有する。これにより、メモリ資源が節約される。

ＶＭ間でメモリイメージを共有させるための手法として、次のものが知られている。例えば、予めＶＭＭにＯＳカーネルやアプリケーションプログラムのテンプレートが複数用意される。ユーザは、どのテンプレートを起動／実行させるかを選択し、同じテンプレートが用いられる場合はＶＭ間でメモリイメージが共有される。

特許文献１に記載された技術によれば、複数のＯＳに関して、カーネルのロードを含むＯＳブートが全て完了した後、メモリイメージの共有化処理が行われる。つまり、複数のＯＳが稼動している最中のあるタイミングで、メモリ資源の共有化処理が行われる。そのために、専用のアプリケーション（共有メモリ化要求アプリケーション）が用意され、その専用アプリケーションが、複数のＯＳのそれぞれによって実行される。第１のＯＳ上の専用アプリケーションは、メモリ領域をあるエントリで予め登録する。ユーザは、そのエントリと第２のＯＳを指定し、その第２のＯＳ上の専用アプリケーションに対して共有化を指示する。ユーザの指示に応じて、第２のＯＳ上の専用アプリケーションは、指定されたメモリ領域におけるメモリイメージを共有できるか否かをチェックする。このように、ユーザは、専用アプリケーションを用意し、また、共有にかかわるＯＳ及び対象を指定する必要がある。また、特許文献１には、ＯＳのシャットダウン時の処理は記載されていない。

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

上述の従来技術によれば、ユーザは、予めＶＭＭにテンプレートを準備したり、共有にかかわるＯＳや対象を指定したりする必要があった。しかしながら近年、インターネットの普及に伴うウィルスの増加を受けて、ＯＳ／アプリケーションプログラムのアップデート頻度が高くなっている。また、ＯＳリモートインストールやＳＡＮ（Storage Area Network）ブートの普及に伴い、様々な種別・バージョンのＯＳが混在するようなシステムも可能となってきている。そのような環境においては、ＶＭ間でメモリイメージを共有させるためにユーザが介入する必要があると、ユーザあるいはシステム構築者・管理者の負担が増大する懸念がある。

以下に、［発明を実施するための最良の形態］で使用される番号・符号を用いて、［課題を解決するための手段］を説明する。これらの番号・符号は、［特許請求の範囲］の記載と［発明を実施するための最良の形態］との対応関係を明らかにするために括弧付きで付加されたものである。ただし、それらの番号・符号を、［特許請求の範囲］に記載されている発明の技術的範囲の解釈に用いてはならない。

本発明に係る仮想計算機システムは、物理メモリ（６０１）とＶＭＭ（３０１）とを備える。ＶＭＭ（３０１）は、物理メモリ（６０１）上にロードされているカーネルイメージの状態を示す管理テーブル（７０１）を有する。ゲストＯＳの起動時、ＶＭＭ（３０１）は、管理テーブル（７０１）を参照することによって、そのゲストＯＳのカーネルイメージと同一のカーネルイメージが物理メモリ（６０１）上に存在するか否かを判定する。

このように、本発明によれば、現在物理メモリ（６０１）上にロードされているカーネルイメージの状態を示す管理テーブル（７０１）が設けられている。ＶＭＭ（３０１）は、その管理テーブル（７０１）を参照することによって、ゲストＯＳの起動時に、カーネルイメージの共有の可否を自動的に判定することができる。

本発明に係る仮想計算機システムによれば、ゲストＯＳの起動時にＶＭＭが、カーネルイメージの共有が可能か否かの判定を自動的に行う。ユーザは、予めＶＭＭにテンプレートを準備したり、共有にかかわるＯＳや対象を指定したりする必要はない。従って、ユーザあるいはシステム構築者・管理者の負担が軽減される。

添付図面を参照して、本発明の実施の形態に係る仮想計算機システム及びその動作方法を説明する。

１．構成
１−１．全体構成
図３は、本実施の形態に係る仮想計算機システムを概略的に示すブロック図である。計算機１は、実計算機であり、ハードウェア資源（Ｈ／Ｗ）４０１を備えている。ハードウェア資源４０１には、物理ディスク５０１や物理メモリ（ＲＡＭ）６０１が含まれる。実計算機１には、仮想マシンモニタ（ＶＭＭ）３０１が実装されている。ＶＭＭ３０１は、実計算機１上に複数の仮想計算機（ＶＭ）を構築し、また、それらの動作を制御することができる。

例えば図３において、ＶＭＭ３０１は、第１仮想計算機２０１と第２仮想計算機２０２を提供している。第１仮想計算機２０１にはゲストＯＳ１０１がインストールされ、第２仮想計算機２０２にはゲストＯＳ１０２がインストールされている。ゲストＯＳ１０１及びゲストＯＳ１０２のそれぞれのインストール先は、物理ディスク５０１上のディスク領域５１１及び５１２である。ディスク領域５１１及び５１２は、ＶＭＭ３０１によって、それぞれの仮想計算機２０１、２０２に割り当てられている。

ゲストＯＳ１０１の起動時、ＶＭＭ３０１は、ディスク領域５１１からゲストＯＳ１０１のカーネルイメージＫＮＬ１を読み出し、そのカーネルイメージＫＮＬ１を物理メモリ６０１にロードする。また、ゲストＯＳ１０２の起動時、ＶＭＭ３０１は、ディスク領域５１２からゲストＯＳ１０２のカーネルイメージＫＮＬ２を読み出し、そのカーネルイメージＫＮＬ２を物理メモリ６０１にロードする。

１−２．ＶＭＭ
本発明に係るＶＭＭ３０１は、ゲストＯＳの起動時に、カーネルイメージ（カーネルテキスト部）の共有が可能か否かの判定を自動的に行う。そのために、本発明に係るＶＭＭ３０１には、次のような機能が実装されている。

（第１の機能）
ゲストＯＳのカーネルイメージを物理メモリ６０１にロードする際、ＶＭＭ３０１は、ロード先の実物理アドレス（先頭アドレス）とカーネルイメージのサイズを記録する。

（第２の機能）
あるＶＭのカーネルイメージが新規にロードされた際、ＶＭＭ３０１は、他のＶＭのカーネルイメージが既にロードされているかどうか調べる。そして、他のＶＭのカーネルイメージのロードが既に完了していた場合、ＶＭＭ３０１は、新規にロードされたカーネルイメージとロード済のカーネルイメージとの比較を行う。ここで、ＶＭＭ３０１は、第１の機能により記録された情報を参照する。

（第３の機能）
新規にロードされたカーネルイメージがロード済のカーネルイメージと同一の場合、ＶＭＭ３０１は、新規のカーネルイメージへのメモリマッピングを、ロード済のカーネルイメージへのメモリマッピングに変更する。そして、ＶＭＭ３０１は、新規にロードされたカーネルイメージに対応するメモリ領域を解放する。

図４は、本実施の形態に係るＶＭＭ３０１を示すブロック図である。ＶＭＭ３０１は、ＯＳ起動処理部３１１及びシャットダウン処理部３１２を有している。ＯＳ起動処理部３１１は、ゲストＯＳの起動処理を行うモジュールであり、上述の第１〜第３の機能を提供する。シャットダウン処理部３１２は、ゲストＯＳのシャットダウン処理を行うモジュールである。各部の詳細な動作に関しては、後述される。

更に、ＶＭＭ３０１は、テキスト部管理テーブル７０１及びマッピングテーブル７０２を有している。

図５は、テキスト部管理テーブル７０１の一例を示している。テキスト部管理テーブル７０１は、複数のエントリから構成されている。各エントリは、物理メモリ６０１上に展開されている各カーネルイメージ（カーネルテキスト部）の状態を示している。具体的には、各エントリは、ゲストＯＳのＩＤ、カーネルイメージがロードされている実物理アドレス（先頭アドレス）、カーネルイメージのサイズ、及び参照カウンタＣＮＴを有している。

実物理アドレス及びサイズは、上述の第１の機能によって得られる。上述の第２の機能においては、このテキスト部管理テーブル７０１で示された情報に基づいて、新規のカーネルイメージとロード済のカーネルイメージとの比較が行われる。参照カウンタＣＮＴは、当該カーネルイメージを使用しているゲストＯＳの数を表しており、参照カウンタＣＮＴが“０”になった時点で、当該カーネルイメージに対応するメモリ領域が解放される。つまり、参照カウンタＣＮＴは、上述の第３の機能において、当該カーネルイメージがロードされているメモリ領域の解放を行っても良いかどうかの判定に用いられるパラメータである。テキスト部管理テーブル７０１は、上述の第１〜第３の機能を実現するために不可欠である。逆に言えば、テキスト部管理テーブル７０１のおかげで、ＶＭＭ３０１は、上述の第１〜第３の機能を提供することが可能となる。詳細については、後述される。

図６は、マッピングテーブル７０２の一例を示している。マッピングテーブル７０２は、ＶＭ物理アドレスと実物理アドレスとの変換を実現するためのテーブルである。マッピングテーブル７０２は、複数のエントリから構成されており、各エントリは、ゲストＯＳのＩＤ、ＶＭ物理アドレス、及び実物理アドレスの対応関係を示している。例えば図６において、ＶＭ物理アドレス空間上のＶＭ物理アドレス“ｘｘｘ”は、物理メモリ６０１上の実物理アドレス“ＡＤＤ１”にマッピングされている。ゲストＯＳ１０１がＶＭ物理アドレス“ｘｘｘ”にアクセスした時、ＶＭＭ３０１はマッピングテーブル７０２を参照し、指定されたＶＭ物理アドレス“ｘｘｘ”に対応する実物理アドレス“ＡＤＤ１”を得る。そして、ＶＭＭ３０１は、物理メモリ６０１上の実物理アドレス“ＡＤＤ１”にアクセスし、対象データを読み出す。ＶＭＭ３０１は、読み出されたデータをゲストＯＳ１０１に返す。

図７は、ゲストＯＳ起動パラメータ８０１の内容を概念的に示している。このゲストＯＳ起動パラメータ８０１は、ＶＭＭ３０１のＯＳ起動処理部３１１がゲストＯＳの起動処理を実行する際に必要な情報である。ゲストＯＳ起動パラメータ８０１は、起動対象のゲストＯＳのＩＤ８１０、そのゲストＯＳに割り当てられているディスク領域８１１、及びそのゲストＯＳのカーネルイメージが格納されているファイルパスを示すカーネルファイルパス８１２を含んでいる。図７に示された例によれば、ゲストＯＳ１０１にはディスク領域５１１がマウントされ、そのディスク領域５１１上のファイル“／ｂｏｏｔ／ｋｅｒｎｅｌ．ｉｍｇ”がカーネルイメージとして読み出される。

２．処理フロー
次に、本実施の形態に係るＶＭＭ３０１によるゲストＯＳの起動処理及びシャットダウン処理を、既出の図面及び次のフローチャートを参照して説明する。具体的な動作例に関しては、次の第３節において説明される。

２−１．ゲストＯＳの起動（ブート）処理
図８は、本実施の形態におけるゲストＯＳの起動処理を示すフローチャートである。まず、ゲストＯＳ起動パラメータ８０１（図７参照）が、ＶＭＭ３０１のＯＳ起動処理部３１１に入力される（ステップＳ１０）。このゲストＯＳ起動パラメータ８０１には、起動対象のゲストＯＳのＩＤ８１０、ディスク領域８１１、及びカーネルファイルパス８１２が示されている。ＩＤ８１０の入力に応答して、ＯＳ起動処理部３１１は、テキスト管理テーブル７０１を参照する（ステップＳ２０）。そして、ＯＳ起動処理部３１１は、そのＩＤ８１０と一致するエントリをテキスト管理テーブル７０１から検索する（ステップＳ３０）。

もし、ＩＤ８１０と一致するエントリがテキスト管理テーブル７０１に含まれていれば（ステップＳ３０；Ｙｅｓ）、それは、当該ゲストＯＳのカーネルイメージが物理メモリ６０１上に既に存在していることを意味する。この場合、通常のゲストＯＳ起動処理は省略され、特別な処理が実行される（ステップＳ４０）。一方、ＩＤ８１０と一致するエントリがテキスト管理テーブル７０１に含まれていない場合（ステップＳ３０；Ｎｏ）、当該ゲストＯＳのカーネルイメージは物理メモリ６０１上に存在していない。従って、通常のゲストＯＳ起動処理が実行される（ステップＳ５０，ステップＳ６０）。ゲストＯＳの起動処理が完了すると、制御は、ＶＭＭ３０１からゲストＯＳカーネルに移行する（ステップＳ７０）。

ステップＳ４０：
図９は、ステップＳ４０の詳細を示すフローチャートである。この時、ＩＤ８１０と一致するエントリがテキスト管理テーブル７０１に含まれている。よって、ＯＳ起動処理部３１１は、その一致エントリを参照することによって、対応するカーネルイメージがロードされている実物理アドレス（先頭アドレス）と、そのカーネルイメージのサイズを取得することができる（ステップＳ４１）。

次に、ＯＳ起動処理部３１１は、得られたサイズに基づいて、ＶＭ物理アドレス空間にメモリ領域を定義する（ステップＳ４２）。これにより、実物理アドレスに対応するＶＭ物理アドレス（先頭アドレス）が得られる。ＯＳ起動処理部３１１は、得られた実物理アドレスとＶＭ物理アドレスとの対応関係を示すエントリを、マッピングテーブル７０２に追加する（ステップＳ４３）。追加されるエントリのＩＤは、ゲストＯＳ起動パラメータ８０１で指定されるＩＤ８１０である。これにより、マッピングの設定が完了する。

更に、ＯＳ起動処理部３１１は、テキスト管理テーブル７０１中の一致エントリの参照カウンタＣＮＴをインクリメントする（ステップＳ４４）。尚、インクリメントとは、参照カウントＣＮＴの値に１を加える操作である。その後、処理はステップＳ７０に移る。

ステップＳ５０：
図１０は、ステップＳ５０の詳細を示すフローチャートである。今、ゲストＯＳ起動パラメータ８０１が、ＯＳ起動処理部３１１に入力されている。そのゲストＯＳ起動パラメータ８０１には、当該ゲストＯＳに割り当てられているディスク領域８１１、及びカーネルファイルパス８１２が含まれている。

ＯＳ起動処理部３１１は、パラメータ８０１中のディスク領域８１１の指定に基づいて、物理ディスク５０１上のファイルシステムを認識することができる（ステップＳ５１）。例えば、ＯＳ起動処理部３１１は、物理ディスク５０１上の指定されたディスク領域５１１のファイルシステムを認識する。次に、ＯＳ起動処理部３１１は、指定されたカーネルファイルパス８１２に基づいて、当該ゲストＯＳのカーネルイメージを読み出す（ステップＳ５２）。このようにして、ＯＳ起動処理部３１１は、カーネルイメージとそのサイズを取得することができる。

次に、ＯＳ起動処理部３１１は、得られたカーネルイメージのサイズに基づいて、実物理アドレス空間及びＶＭ物理アドレス空間にメモリ領域を確保する（ステップＳ５３）。確保された（割り当てられた）メモリ領域の先頭アドレスが、それぞれ「実物理アドレス」及び「ＶＭ物理アドレス」として用いられる。そして、ＯＳ起動処理部３１１は、カーネルイメージを物理メモリ６０１上に展開する（ステップＳ５４）。つまり、ＯＳ起動処理部３１１は、物理メモリ６０１上の割り当てられたメモリ領域に、カーネルイメージをロードする。

また、ＯＳ起動処理部３１１は、実物理アドレスとＶＭ物理アドレスとの対応関係を示すエントリを、マッピングテーブル７０２に追加する（ステップＳ５５）。追加されるエントリのＩＤは、ゲストＯＳ起動パラメータ８０１で指定されるＩＤ８１０である。これにより、マッピングの設定が完了する。

更に、ＯＳ起動処理部３１１は、当該ゲストＯＳに対応するエントリを、テキスト部管理テーブル７０１に作成する（ステップＳ５６）。そのエントリのＩＤは、ゲストＯＳ起動パラメータ８０１で指定されるＩＤ８１０である。実物理アドレス及びサイズとしては、既出のステップで得られた値が書き込まれる。当該カーネルイメージを使用しているゲストＯＳの数を表す参照カウンタＣＮＴは、“１”に設定される。その後、処理は、ステップＳ６０に進む。

ステップＳ６０：
図１１は、ステップＳ６０の詳細を示すフローチャートである。まず、ＯＳ起動処理部３１１は、テキスト部管理テーブル７０１を参照する。テキスト部管理テーブル７０１において、起動中のゲストＯＳに対応するエントリ、すなわちＩＤ８１０で指定されているエントリは「自エントリ」と参照される。一方、自エントリ以外のエントリは「他エントリ」と参照される。テキスト部管理テーブル７０１に他エントリが無い場合（ステップＳ６１；Ｎｏ）、処理はステップＳ７０に進む。一方、テキスト部管理テーブル７０１に他エントリが有る場合（ステップＳ６１；Ｙｅｓ）、ＯＳ起動処理部３１１は、自エントリと他エントリとの比較を行う（ステップＳ６２）。

まず、ＯＳ起動処理部３１１は、自エントリで示されるサイズと他エントリで示されるサイズとの比較を行う（ステップＳ６３）。サイズが一致しない場合（ステップＳ６３；Ｎｏ）、処理はステップＳ６１に戻り、更に他のエントリに関して同じ処理が行われる。

一方、サイズが一致する場合（ステップＳ６３；Ｙｅｓ）、ＯＳ起動処理部３１１は、自エントリに対応するカーネルイメージと他エントリに対応するカーネルイメージとの比較を行う（ステップＳ６４）。その比較においては、エントリに示されている実物理アドレス（カーネルイメージの開始アドレス）とサイズが用いられる。すなわち、ＯＳ起動処理部３１１は、物理メモリ６０１上の開始アドレスからサイズ分のメモリイメージに関して比較を行うことができる。カーネルイメージが一致しない場合（ステップＳ６５；Ｎｏ）、処理はステップＳ６１に戻り、更に他のエントリに関して同じ処理が行われる。

カーネルイメージが一致する場合（ステップＳ６５；Ｙｅｓ）、カーネルイメージの共有が可能である。従って、ＯＳ起動処理部３１１は、自エントリに関するマッピングを変更する（ステップＳ６６）。具体的には、ＯＳ起動処理部３１１は、マッピングテーブル７０２中の自エントリの実物理アドレスを、テキスト部管理テーブル７０１中の他エントリの実物理アドレスに置き換える。これにより、当該ゲストＯＳがカーネルイメージにアクセスする際、他エントリに対応したカーネルイメージに対してマッピングが行われるようになる。すなわち、メモリ領域（カーネルイメージ）の共有が自動的に実現される。

また、ＯＳ起動処理部３１１は、テキスト部管理テーブル７０１中の他エントリの参照カウンタＣＮＴをインクリメントする（ステップＳ６７）。同時に、ＯＳ起動処理部３１１は、テキスト部管理テーブル７０１中の自エントリの参照カウンタＣＮＴをデクリメントする（ステップＳ６８）。尚、デクリメントとは、参照カウントＣＮＴの値から１を引く操作である。上述のステップＳ５６において、自エントリの参照カウンタＣＮＴは、“１”に設定されていた。従って、このステップＳ６８において、自エントリの参照カウンタＣＮＴは“０”になる。参照カウンタＣＮＴが“０”になることは、対応するカーネルイメージを使用しているゲストＯＳが無くなったことを意味する。従って、当該エントリは削除され、対応する実メモリ領域は解放される（ステップＳ６９）。これにより、物理メモリ６０１のメモリ資源が節約される。

２−２．シャットダウン処理
図１２は、本実施の形態におけるゲストＯＳのシャットダウン処理を示すフローチャートである。まず、ＶＭＭ３０１のシャットダウン処理部３１２は、ゲストＯＳの動作を停止させる（ステップＳ８０）。ゲストＯＳの停止直後、シャットダウン処理部３１２は、そのゲストＯＳが動作していたＶＭの解放処理を行う（ステップＳ９０）。

まず、シャットダウン処理部３１２は、マッピングテーブル７０２を参照し、停止したゲストＯＳのＩＤに基づいて当該ゲストＯＳに対応するエントリを検索する。そして、シャットダウン処理部３１２は、検索されたエントリに示されている実物理アドレスを取得する（ステップＳ９１）。次に、シャットダウン処理部３１２は、テキスト部管理テーブル７０１を参照し、ステップＳ９１で得られた実物理アドレスが格納されているエントリを検索する（ステップＳ９２）。その実物理アドレスが格納されているエントリは、一意に定まる。

次に、シャットダウン処理部３１２は、見つかったエントリの参照カウンタＣＮＴをデクリメントする（ステップＳ９３）。結果として参照カウンタＣＮＴが“０”になった場合（ステップＳ９４；Ｙｅｓ）、上記実物理アドレスにロードされているカーネルイメージを使用しているゲストＯＳが無くなったことを意味する。従って、シャットダウン処理部３１２は、当該エントリを削除し（ステップＳ９５）、対応する実メモリ領域を解放する（ステップＳ９６）。一方、参照カウンタＣＮＴが“０”にならない場合（ステップＳ９４；Ｎｏ）、当該カーネルイメージはまだ必要である。従って、エントリの削除や実メモリ領域の解放は行われない。

また、シャットダウン処理部３１２は、マッピングテーブル７０２の変更を行う。具体的には、シャットダウン処理部３１２は、マッピングテーブル７０２から、停止したゲストＯＳに対応するエントリを削除する（ステップＳ９７）。このようにして、ＶＭが解放される。

３．動作例
次に、既出のフローチャート及び図１３〜図２０を参照して、本実施の形態に係る仮想計算機システムの動作例を説明する。図１３〜図２０は、図３に対応する図であり、重複する説明は省略される。

３−１．第１の例
図１３は、以下に説明される動作例の初期状態を示している。まず、ユーザは、ゲストＯＳ１０１の起動を要求する。その要求に応答して、ＶＭＭ３０１には、ゲストＯＳ起動パラメータ８０１が入力される（ステップＳ１０）。そのゲストＯＳ起動パラメータ８０１は、「ＩＤ：ＯＳ１０１，ディスク領域：５１１，カーネルファイルパス：所定のパス」を示している。ＶＭＭ３０１は、テキスト部管理テーブル７０１を参照する（ステップＳ２０）。現時点で、「ＩＤ：ＯＳ１０１」と一致するエントリは、テキスト管理テーブル７０１に含まれていない（ステップＳ３０；Ｎｏ）。よって、処理はステップＳ５０に進む。

図１４は、ステップＳ５０における状態を示している。ＶＭＭ３０１は、指定されたディスク領域５１１上の指定されたカーネルファイルパスにアクセスし、カーネルイメージＫＮＬ１を取得する（ステップＳ５１，Ｓ５２）。そのカーネルイメージＫＮＬ１のサイズは、“ＳＩＺＥ１”で表される。次に、そのカーネルイメージＫＮＬ１に応じたメモリ領域が、ゲストＯＳ１０１に割り当てられる（ステップＳ５３）。例えば物理メモリ６０１において、実物理アドレス“ＡＤＤ１”から始まるメモリ領域６１１が確保される。ＶＭ物理アドレス空間において、アドレス“ｘｘｘ”から始まるメモリ領域が確保される。

次に、ＶＭＭ３０１は、カーネルイメージＫＮＬ１を、物理メモリ６０１上の割り当てられたメモリ領域６１１にロードする（ステップＳ５４）。また、ＶＭＭ３０１は、マッピングテーブル７０２に、エントリ「ＩＤ：ＯＳ１０１，ＶＭ物理アドレス：ｘｘｘ，実物理アドレス：ＡＤＤ１」を追加する（ステップＳ５５）。更に、ＶＭＭ３０１は、テキスト部管理テーブル７０１に、新たなエントリ「ＩＤ：ＯＳ１０１，アドレス：ＡＤＤ１，サイズ：ＳＩＺＥ１，参照カウンタ：１」を作成する（ステップＳ５６）。

次に、処理はステップＳ６０に進む。ＶＭＭ３０１は、テキスト部管理テーブル７０１を参照する。現時点で、テキスト部管理テーブル７０１に他エントリは存在しない（ステップＳ６１；Ｎｏ）。よって、処理はステップＳ７０に進み、ゲストＯＳ１０１の起動処理が完了する。

次に、ユーザは、ゲストＯＳ１０２の起動を要求する。入力されるゲストＯＳ起動パラメータ８０１は、「ＩＤ：ＯＳ１０２，ディスク領域：５１２，カーネルファイルパス：所定のパス」を示している（ステップＳ１０）。現時点で、「ＩＤ：ＯＳ１０２」と一致するエントリは、テキスト管理テーブル７０１に含まれていない（ステップＳ３０；Ｎｏ）。よって、処理はステップＳ５０に進む。

図１５は、ステップＳ５０における状態を示している。ＶＭＭ３０１は、ゲストＯＳ１０１の場合と同様の処理を行う。ディスク領域５１２からカーネルイメージＫＮＬ２（サイズ＝ＳＩＺＥ２）が得られる。物理メモリ６０１において、実物理アドレス“ＡＤＤ２”から始まるメモリ領域６１２が確保される。ＶＭ物理アドレス空間において、アドレス“ｙｙｙ”から始まるメモリ領域が確保される。カーネルイメージＫＮＬ２は、メモリ領域６１２にロードされる。マッピングテーブル７０２に、エントリ「ＩＤ：ＯＳ１０２，ＶＭ物理アドレス：ｙｙｙ，実物理アドレス：ＡＤＤ２」が追加される。更に、テキスト部管理テーブル７０１に、新たなエントリ「ＩＤ：ＯＳ１０２，アドレス：ＡＤＤ２，サイズ：ＳＩＺＥ２，参照カウンタ：１」が作成される。

その後、処理はステップＳ６０に進む。ＶＭＭ３０１は、テキスト部管理テーブル７０１を参照する。今回は、テキスト部管理テーブル７０１に他エントリ（ＩＤ：ＯＳ１０１）が存在する（ステップＳ６１；Ｙｅｓ）。よって、ＶＭＭ３０１は、自エントリ（ＩＤ：ＯＳ１０２）と他エントリ（ＩＤ：ＯＳ１０１）との比較を行う（ステップＳ６２）。サイズＳＩＺＥ１とサイズＳＩＺＥ２は一致するとする（ステップＳ６３；Ｙｅｓ）。カーネルイメージＫＮＬ１とカーネルイメージＫＮＬ２は一致するとする（ステップＳ６５；Ｙｅｓ）。

よって、図１６に示されるように、ＶＭＭ３０１は、マッピングテーブル７０２中の自エントリ（ＩＤ：ＯＳ１０２）の実物理アドレスを、“ＡＤＤ２”から“ＡＤＤ１”に変更する（ステップＳ６６）。これにより、ゲストＯＳ１０１及び１０２によるメモリ領域６１１の共有が自動的に実現される。

更に、ＶＭＭ３０１は、テキスト部管理テーブル７０１中の参照カウンタＣＮＴを変更する。具体的には、ＶＭＭ３０１は、他エントリ（ＩＤ：ＯＳ１０１）の参照カウンタＣＮＴをインクリメントする（ステップＳ６７）。その結果、他エントリの参照カウンタＣＮＴは“２”となる。これは、２つのゲストＯＳ（１０１、１０２）がアドレスＡＤＤ１に対応するカーネルイメージＫＮＬ１を使用していることを意味する。一方、ＶＭＭ３０１は、自エントリ（ＩＤ：ＯＳ１０２）の参照カウンタＣＮＴをデクリメントする（ステップＳ６８）。その結果、自エントリの参照カウンタＣＮＴは“０”になる。これは、アドレスＡＤＤ２に対応するカーネルイメージＫＮＬ２を使用しているゲストＯＳが無くなったことを意味する。従って、自エントリは削除され、対応するメモリ領域６１２は解放される（ステップＳ６９）。

そして、処理はステップＳ７０に進み、ゲストＯＳ１０２の起動処理が完了する。

次に、図１６に示された状態で、ユーザは、ゲストＯＳ１０２のシャットダウンを指示する。その指示に応答して、ＶＭＭ３０１は、ゲストＯＳ１０２の動作を停止させる（ステップＳ８０）。更に、ＶＭＭ３０１は、マッピングテーブル７０２から当該ゲストＯＳ１０２に対応するエントリ「ＩＤ：ＯＳ１０２，ＶＭ物理アドレス：ｙｙｙ，実物理アドレス：ＡＤＤ１」を見つけ出す（ステップＳ９１）。

次に、ＶＭＭ３０１は、そのエントリに示される実物理アドレス“ＡＤＤ１”を用いて、テキスト部管理テーブル７０１を検索する（ステップＳ９２）。その結果、エントリ「ＩＤ：ＯＳ１０１，アドレス：ＡＤＤ１，サイズ：ＳＩＺＥ１，参照カウンタ：２」が見つけ出される。よって、ＶＭＭ３０１は、そのエントリの参照カウンタＣＮＴをデクリメントする（ステップＳ９３）。その結果、図１７に示されるように、参照カウンタＣＮＴが、“２”から“１”に変わる（ステップＳ９４；Ｎｏ）。この場合、メモリ領域の解放は行われない。また、ＶＭＭ３０１は、マッピングテーブル７０２から、停止したゲストＯＳ１０２に対応するエントリ「ＩＤ：ＯＳ１０２，ＶＭ物理アドレス：ｙｙｙ，実物理アドレス：ＡＤＤ１」を削除する（ステップＳ９７）。

次に、図１７に示された状態で、ユーザは、ゲストＯＳ１０１のシャットダウンを指示する。その指示に応答して、ＶＭＭ３０１は、ゲストＯＳ１０１の動作を停止させる（ステップＳ８０）。更に、ＶＭＭ３０１は、マッピングテーブル７０２から当該ゲストＯＳ１０１に対応するエントリ「ＩＤ：ＯＳ１０１，ＶＭ物理アドレス：ｘｘｘ，実物理アドレス：ＡＤＤ１」を見つけ出す（ステップＳ９１）。

次に、ＶＭＭ３０１は、そのエントリに示される実物理アドレス“ＡＤＤ１”を用いて、テキスト部管理テーブル７０１を検索する（ステップＳ９２）。その結果、エントリ「ＩＤ：ＯＳ１０１，アドレス：ＡＤＤ１，サイズ：ＳＩＺＥ１，参照カウンタ：１」が見つけ出される。よって、ＶＭＭ３０１は、そのエントリの参照カウンタＣＮＴをデクリメントする（ステップＳ９３）。その結果、図１８に示されるように、参照カウンタＣＮＴが、“１”から“０”に変わる（ステップＳ９４；Ｙｅｓ）。これは、アドレスＡＤＤ１に対応するカーネルイメージＫＮＬ１を使用しているゲストＯＳが無くなったことを意味する。従って、ＶＭＭ３０１は、当該エントリを削除し（ステップＳ９５）、対応するメモリ領域６１１を解放する（ステップＳ９６）。また、ＶＭＭ３０１は、マッピングテーブル７０２から、停止したゲストＯＳ１０１に対応するエントリ「ＩＤ：ＯＳ１０１，ＶＭ物理アドレス：ｘｘｘ，実物理アドレス：ＡＤＤ１」を削除する（ステップＳ９７）。

３−２．第２の例
第１の例では、図１６に示された状態から、ゲストＯＳ１０２が最初にシャットダウンされた。第２の例では、図１６に示された状態から、ゲストＯＳ１０１が最初にシャットダウンされる場合を考える。

図１６に示された状態で、ユーザは、ゲストＯＳ１０１のシャットダウンを指示する。その指示に応答して、ＶＭＭ３０１は、ゲストＯＳ１０１の動作を停止させる（ステップＳ８０）。更に、ＶＭＭ３０１は、マッピングテーブル７０２から当該ゲストＯＳ１０１に対応するエントリ「ＩＤ：ＯＳ１０１，ＶＭ物理アドレス：ｘｘｘ，実物理アドレス：ＡＤＤ１」を見つけ出す（ステップＳ９１）。

次に、ＶＭＭ３０１は、そのエントリに示される実物理アドレス“ＡＤＤ１”を用いて、テキスト部管理テーブル７０１を検索する（ステップＳ９２）。その結果、エントリ「ＩＤ：ＯＳ１０１，アドレス：ＡＤＤ１，サイズ：ＳＩＺＥ１，参照カウンタ：２」が見つけ出される。よって、ＶＭＭ３０１は、そのエントリの参照カウンタＣＮＴをデクリメントする（ステップＳ９３）。その結果、図１９に示されるように、参照カウンタＣＮＴが、“２”から“１”に変わる（ステップＳ９４；Ｎｏ）。これは、１つのゲストＯＳ（１０２）がまだカーネルイメージＫＮＬ１を参照していることを意味する。従って、ゲストＯＳ１０１は停止したが、メモリ領域６１１の解放は行われない。ＶＭＭ３０１は、マッピングテーブル７０２から、エントリ「ＩＤ：ＯＳ１０１，ＶＭ物理アドレス：ｘｘｘ，実物理アドレス：ＡＤＤ１」を削除する（ステップＳ９７）。

次に、図１９に示された状態で、ゲストＯＳ１０１の起動が再度要求された場合を考える。入力されるゲストＯＳ起動パラメータ８０１は、「ＩＤ：ＯＳ１０１，ディスク領域：５１１，カーネルファイルパス：所定のパス」を示している。ＶＭＭ３０１は、テキスト部管理テーブル７０１を参照する（ステップＳ２０）。今回は、ゲストＯＳ１０１に対応するエントリ「ＩＤ：ＯＳ１０１，アドレス：ＡＤＤ１，サイズ：ＳＩＺＥ１，参照カウンタ：１」が既に存在している（ステップＳ３０；Ｎｏ）。すなわち、ゲストＯＳ１０１のカーネルイメージＫＮＬ１が、物理メモリ６０１上に既に存在している。よって、処理はステップＳ４０に進む。

ＶＭＭ３０１は、当該エントリを参照して、実物理アドレス“ＡＤＤ１”とサイズ“ＳＩＺＥ１”を取得する（ステップＳ４１）。次に、ＶＭＭ３０１は、サイズ“ＳＩＺＥ１”に基づいて、ＶＭ物理アドレス空間にメモリ領域を定義する（ステップＳ４２）。次に、ＶＭＭ３０１は、図２０に示されるように、エントリ「ＩＤ：ＯＳ１０１，ＶＭ物理アドレス：ｘｘｘ，実物理アドレス：ＡＤＤ１」をマッピングテーブル７０２に追加する（ステップＳ４３）。これにより、マッピングの設定が完了する。

更に、ＶＭＭ３０１は、テキスト管理テーブル７０１中の当該エントリの参照カウンタＣＮＴをインクリメントする（ステップＳ４４）。その結果、参照カウンタＣＮＴは“１”から“２”に変わる。これは、２つのゲストＯＳ（１０１、１０２）がアドレスＡＤＤ１に対応するカーネルイメージＫＮＬ１を共有していることを意味する。その後、処理はステップＳ７０に進み、ゲストＯＳ１０１の起動処理が完了する。

今回のゲストＯＳ１０１の起動処理において、カーネルイメージＫＮＬ１のロード処理が省略されていることに着目されるべきである。これは、ゲストＯＳの起動処理時間の短縮を意味する。ロード処理が省略される理由は、ゲストＯＳ１０１の起動時にカーネルイメージＫＮＬ１が既に物理メモリ６０１上にロードされているからである。ＶＭＭはそのことを、ゲストＯＳの起動時に、テキスト部管理テーブル７０１を参照することによって知ることができる。逆に言えば、物理メモリ６０１上の現在のカーネルイメージの状態を示すテキスト部管理テーブル７０１が設けられているからこそ、ゲストＯＳの起動時にその起動処理時間を短縮することが可能となる。

４．効果
本発明によれば、複数のＶＭ間でカーネルイメージ（カーネルテキスト部）が同一である場合、カーネルイメージがロードされる実メモリ領域の共有が行われる。つまり、複数のＶＭが、物理メモリ上のカーネルイメージを共有する。その結果、メモリ資源が節約され、有効に活用される。またそれによって、プロセッサのキャッシュメモリも有効利用されるようになる。つまり、キャッシュメモリの利用効率が向上し、キャッシュ効果が増大する。従って、計算機システムの処理速度が向上する。

また、本発明によれば、ゲストＯＳの起動時にＶＭＭが、カーネルイメージの共有が可能か否かの判定を自動的に行う。ユーザは、カーネルイメージの共有を実現するために、予めＶＭＭにテンプレートを準備したり、共有にかかわるＯＳや対象を指定したりする必要はない。従って、ユーザあるいはシステム構築者・管理者の負担が軽減される。

更に本発明によれば、物理メモリ６０１上に現在ロードされているカーネルイメージの状態を示すテキスト部管理テーブル７０１が設けられている。ＶＭＭは、このテキスト部管理テーブル７０１を利用することにより、カーネルイメージの共有の可否を容易に判定することができる。また、ＶＭＭは、このテキスト部管理テーブル７０１を参照することによって、ゲストＯＳの起動時に当該ゲストＯＳに対応するカーネルイメージが既に物理メモリ６０１上にロードされているかどうか調べることができる。もし、当該ゲストＯＳに対応するカーネルイメージが既に存在していれば、そのカーネルイメージのロード処理を省くことができる。従って、ゲストＯＳの起動処理時間を短縮できるという効果が得られる。

図１は、従来の仮想計算機環境におけるメモリ資源の割り当てを示す概念図である。 図２は、従来の仮想計算機環境におけるメモリイメージの共有を示す概念図である。 図３は、本発明の実施の形態に係る仮想計算機システムの構成を示すブロック図である。 図４は、本実施の形態に係るＶＭＭの構成を示すブロック図である。 図５は、本実施の形態に係るテキスト部管理テーブルを示す概念図である。 図６は、本実施の形態に係るマッピングテーブルを示す概念図である。 図７は、本実施の形態に係るゲストＯＳ起動パラメータを示す概念図である。 図８は、本実施の形態におけるゲストＯＳの起動処理を示すフローチャートである。 図９は、ステップＳ４０の内容を示すフローチャートである。 図１０は、ステップＳ５０の内容を示すフローチャートである。 図１１は、ステップＳ６０の内容を示すフローチャートである。 図１２は、本実施の形態におけるゲストＯＳのシャットダウン処理を示すフローチャートである。 図１３は、本実施の形態に係る仮想計算機システムの動作の一例を説明するための図である。 図１４は、本実施の形態に係る仮想計算機システムの動作の一例を説明するための図である。 図１５は、本実施の形態に係る仮想計算機システムの動作の一例を説明するための図である。 図１６は、本実施の形態に係る仮想計算機システムの動作の一例を説明するための図である。 図１７は、本実施の形態に係る仮想計算機システムの動作の一例を説明するための図である。 図１８は、本実施の形態に係る仮想計算機システムの動作の一例を説明するための図である。 図１９は、本実施の形態に係る仮想計算機システムの動作の一例を説明するための図である。 図２０は、本実施の形態に係る仮想計算機システムの動作の一例を説明するための図である。

符号の説明

１ 計算機
１０１，１０２ ゲストＯＳ
２０１，２０２ 仮想マシン（ＶＭ）
３０１ ＶＭＭ
３１１ ＯＳ起動処理部
３１２ シャットダウン処理部
４０１ ハードウェア資源
５０１ 物理ディスク
５１１，５１２ ディスク領域
６０１ 物理メモリ
６１１，６１２ メモリ領域
７０１ テキスト部管理テーブル
７０２ マッピングテーブル
８０１ ゲストＯＳ起動パラメータ
８１０ ＩＤ
８１１ ディスク領域
８１２ カーネルファイルパス
ＣＮＴ 参照カウンタ
ＫＮＬ１，ＫＮＬ２ カーネルイメージ

Claims (21)

1. 物理メモリと、
   前記物理メモリ上にロードされているカーネルイメージの状態を示す管理テーブルを有するＶＭＭ（Virtual Machine Monitor）と
   を備え、
   あるゲストＯＳの起動時、前記ＶＭＭは、前記管理テーブルを参照することによって、前記あるゲストＯＳのカーネルイメージと同一のカーネルイメージが前記物理メモリ上に存在するか否かを判定する
   仮想計算機システム。
2. 請求項１に記載の仮想計算機システムであって、
   前記管理テーブルの各エントリは、前記ロードされているカーネルイメージの先頭アドレスとサイズを示す
   仮想計算機システム。
3. 請求項１又は２に記載の仮想計算機システムであって、
   第１ゲストＯＳの起動時、前記ＶＭＭは、前記第１ゲストＯＳのカーネルイメージである第１カーネルイメージを前記物理メモリ上の第１メモリ領域にロードし、且つ、前記第１メモリ領域の先頭アドレスと前記第１カーネルイメージのサイズを示す第１エントリを前記管理テーブルに追加する
   仮想計算機システム。
4. 請求項３に記載の仮想計算機システムであって、
   前記第１ゲストＯＳの起動時、前記ＶＭＭは、前記第１エントリが既に前記管理テーブルに存在しているか否かを判定し、
   前記第１エントリが既に存在する場合、前記ＶＭＭは、前記第１カーネルイメージを前記物理メモリ上にロードすることなく、前記第１エントリに基づいて前記第１ゲストＯＳを起動する
   仮想計算機システム。
5. 請求項３に記載の仮想計算機システムであって、
   第２ゲストＯＳの起動時、前記ＶＭＭは、前記第２ゲストＯＳのカーネルイメージである第２カーネルイメージを前記物理メモリ上の第２メモリ領域にロードし、且つ、前記第２メモリ領域の先頭アドレスと前記第２カーネルイメージのサイズを示す第２エントリを前記管理テーブルに追加し、
   前記ＶＭＭは、前記第１エントリと前記第２エントリを比較することによって、前記第１カーネルイメージと前記第２カーネルイメージが同一か否かを判定する
   仮想計算機システム。
6. 請求項５に記載の仮想計算機システムであって、
   前記第１カーネルイメージと前記第２カーネルイメージが同一である場合、
   前記ＶＭＭは、前記第２カーネルイメージへのマッピングを、前記第１カーネルイメージへのマッピングに変更する
   仮想計算機システム。
7. 請求項６に記載の仮想計算機システムであって、
   前記ＶＭＭは、前記第２エントリを前記管理テーブルから削除し、また、前記第２メモリ領域を解放する
   仮想計算機システム。
8. 請求項３乃至７のいずれかに記載の仮想計算機システムであって、
   前記第１カーネルイメージを使用しているゲストＯＳのシャットダウン時、前記ＶＭＭは、前記第１カーネルイメージを使用中のゲストＯＳが他になければ、前記第１エントリを前記管理テーブルから削除し、また、前記第１メモリ領域を解放する
   仮想計算機システム。
9. 請求項２乃至８のいずれかに記載の仮想計算機システムであって、
   前記管理テーブルの各エントリは、更に、前記ロードされているカーネルイメージを使用しているゲストＯＳの数を示し、
   前記数がゼロになった場合、前記ＶＭＭは、当該エントリの前記先頭アドレス及び前記サイズで規定されるメモリ領域を解放し、また、当該エントリを前記管理テーブルから削除する
   仮想計算機システム。
10. 請求項６又は７に記載の仮想計算機システムであって、
    前記管理テーブルの各エントリは、更に、前記ロードされているカーネルイメージを使用しているゲストＯＳの数を示し、
    前記前記第２カーネルイメージへのマッピングが、前記第１カーネルイメージへのマッピングに変更された際、前記ＶＭＭは、前記第１エントリの前記数をインクリメントし、前記第２エントリの前記数をデクリメントする
    仮想計算機システム。
11. 請求項１０に記載の仮想計算機システムであって、
    前記第１カーネルイメージを使用しているゲストＯＳのシャットダウン時、前記ＶＭＭは、前記第１エントリの前記数をデクリメントする
    仮想計算機システム。
12. 請求項１０又は１１に記載の仮想計算機システムであって、
    前記数がゼロになった場合、前記ＶＭＭは、当該エントリの前記先頭アドレス及び前記サイズで規定されるメモリ領域を解放し、また、当該エントリを前記管理テーブルから削除する
    仮想計算機システム。
13. 物理メモリを有する実計算機上に仮想計算機を構築するＶＭＭ（Virtual Machine Monitor）が搭載された仮想計算機システムの動作方法であって、
    （Ａ）前記物理メモリ上にロードされているカーネルイメージの状態を示す管理テーブルを提供するステップと、
    （Ｂ）あるゲストＯＳの起動時、前記管理テーブルを参照することによって、前記あるゲストＯＳのカーネルイメージと同一のカーネルイメージが前記物理メモリ上に存在するか否かを判定するステップと
    を有する
    仮想計算機システムの動作方法。
14. 請求項１３に記載の仮想計算機システムの動作方法であって、
    前記管理テーブルの各エントリは、前記ロードされているカーネルイメージの先頭アドレスとサイズを示す
    仮想計算機システムの動作方法。
15. 請求項１３又は１４に記載の仮想計算機システムの動作方法であって、
    前記（Ｂ）ステップは、
    （Ｂ１）第１ゲストＯＳの起動時、前記第１ゲストＯＳのカーネルイメージである第１カーネルイメージを前記物理メモリ上の第１メモリ領域にロードするステップと、
    （Ｂ２）前記第１メモリ領域の先頭アドレスと前記第１カーネルイメージのサイズを示す第１エントリを前記管理テーブルに追加するステップと
    を含む
    仮想計算機システムの動作方法。
16. 請求項１５に記載の仮想計算機システムの動作方法であって、
    前記（Ｂ）ステップにおいて、前記第１エントリが既に前記管理テーブルに存在している場合、前記第１カーネルイメージを前記物理メモリ上にロードすることなく、前記第１ゲストＯＳの起動が行われる
    仮想計算機システムの動作方法。
17. 請求項１５に記載の仮想計算機システムの動作方法であって、
    前記（Ｂ）ステップは、
    （Ｂ３）第２ゲストＯＳの起動時、前記第２ゲストＯＳのカーネルイメージである第２カーネルイメージを前記物理メモリ上の第２メモリ領域にロードするステップと、
    （Ｂ４）前記第２メモリ領域の先頭アドレスと前記第２カーネルイメージのサイズを示す第２エントリを前記管理テーブルに追加するステップと
    （Ｂ５）前記第１エントリと前記第２エントリを比較することによって、前記第１カーネルイメージと前記第２カーネルイメージが同一か否かを判定するステップと
    を更に含む
    仮想計算機システムの動作方法。
18. 請求項１７に記載の仮想計算機システムの動作方法であって、
    更に、
    （Ｃ）前記（Ｂ５）ステップにおいて前記第１カーネルイメージと前記第２カーネルイメージが同一である場合、前記第２カーネルイメージへのマッピングを、前記第１カーネルイメージへのマッピングに変更するステップ
    を有する
    仮想計算機システムの動作方法。
19. 請求項１８に記載の仮想計算機システムの動作方法であって、
    更に、
    （Ｄ）前記第２エントリを前記管理テーブルから削除し、また、前記第２メモリ領域を解放するステップ
    を有する
    仮想計算機システムの動作方法。
20. 請求項１５乃至１９のいずれかに記載の仮想計算機システムの動作方法であって、
    更に、
    （Ｅ）前記第１カーネルイメージを使用しているゲストＯＳをシャットダウンするステップと、
    （Ｆ）前記第１カーネルイメージを使用中のゲストＯＳが他になければ、前記第１エントリを前記管理テーブルから削除し、また、前記第１メモリ領域を解放するステップと
    を有する
    仮想計算機システムの動作方法。
21. 仮想計算機環境を提供するコンピュータで実行されるプログラムであって、
    （Ａ）前記コンピュータの物理メモリ上にロードされているカーネルイメージの状態を示す管理テーブルを提供する機能と、
    （Ｂ）あるゲストＯＳの起動時、前記管理テーブルを参照することによって、前記あるゲストＯＳのカーネルイメージと同一のカーネルイメージが前記物理メモリ上に存在するか否かを判定する機能と
    を前記コンピュータに実現させるための
    プログラム。

Images