(57)【要約】【課題】ＯＳ固有領域に配置されたデータの移動と変換を廃することによってプロセス移動のオーバーヘッドを低減し、複数の仮想計算機を短時間のうちに一つに統合する機能を提供すること。【解決手段】仮想計算機システムにおいて、第１のゲストＯＳを第２のゲストＯＳから複製によって生成する際に、第１のゲストＯＳで走行する第１のプロセスに対し、第２のゲストＯＳで走行する第２のプロセスが使用している物理固有領域と仮想固有領域と重複しないアドレスを持つ物理固有領域と仮想固有領域をそれぞれ割り当てるとともに、第１のプロセスに前記仮想計算機システム全体で唯一のプロセスＩＤを割り当てる。【選択図】図１
2014139702.tif 000002
【特許請求の範囲】
【請求項１】
記憶装置と、当該記憶装置に接続されたプロセッサと、当該プロセッサ上で実行され、当該プロセッサに複数のＯＳの実行制御をさせるハイパーバイザとを備える仮想計算機システムであって、
前記ハイパーバイザは、
前記複数のＯＳのそれぞれで割り付けるプロセスＩＤが前記仮想計算機システム全体で重複しないように管理するＰＩＤ管理部と、
前記ＯＳに対する仮想アドレス空間および物理アドレス空間の割り当てを指示する領域指示部を備え、
前記領域指示部は、
前記複数のＯＳのそれぞれが利用する前記記憶装置を、全てのＯＳが読み書き可能な領域であるである物理共有領域、および前記物理共有領域以外の領域である物理固有領域として割り当てる物理アドレス管理手段と、
前記複数のＯＳのそれぞれが仮想アドレス空間における仮想固有領域に関する情報を記録し、前記ＯＳから要求があった場合に、前記情報に基づいて、既に他のＯＳに割り当てられている仮想固有領域と重複しない仮想アドレスからなる仮想固有領域を前記ＯＳに割り当てる仮想アドレス管理部と、
を備える仮想計算機システム。
【請求項２】
前記仮想計算機システムは、アプリケーションを実行する場合、前記アプリケーションを走行させる第１のＯＳを、現在走行中の第２のＯＳの複製として生成し、前記第２のＯＳが占有する物理固有領域の代わりに前記第１のＯＳが占有する物理固有領域を割り当てることを特徴とする請求項１に記載の仮想計算機システム。
【請求項３】
前記ＯＳは、少なくともプロセスの生成を行うプロセス生成部を備え、
前記プロセス生成手段は、プロセスを生成する際に、前記ＰＩＤ管理部から前記プロセスのＩＤを取得し、前記プロセスに割り当てることを特徴とする請求項１に記載の仮想計算機システム。
【請求項４】
前記ＯＳは、少なくともプロセスのページテーブルの生成を行うページテーブル管理部を備え、
前記領域指示部は、すべてのプロセスの仮想固有領域の位置を保持し、
前記ページテーブル管理部は、前記ページテーブルを生成する際に、前記領域指示部と通信し、前記プロセスの仮想固有領域が、当該生成するプロセス以外のプロセスの仮想固有領域と重複しないように前記ページテーブルに確保することを特徴とする請求項１に記載の仮想計算機システム。
【請求項５】
前記ページテーブル管理部は、プロセスが当該プロセス以外のプロセスの仮想固有領域と重複する領域を使用しないように、前記重複する領域を前記領域指示部から取得し、前記重複する領域を予約領域として前記プロセスのページテーブルに確保することを特徴とする請求項１に記載の仮想計算機システム。
【請求項６】
前記ハイパーバイザは、走行中の第１のプロセスを前記第１のＯＳから前記第２のＯＳに移動する場合に、前記第１のプロセスを休止状態に遷移させ、前記第１のプロセスのプロセス構造体を前記第１のＯＳのプロセスリストから削除し、前記第２のＯＳのプロセスリストに追加した後、前記第１のプロセスを再開し、前記第１のプロセスの物理固有領域に配置した前記第１のプロセスに固有のデータを前記第２のＯＳの物理固有領域に移動および変換を行うことを特徴とする請求項２に記載の仮想計算機システム。
【請求項７】
前記ハイパーバイザは、走行中の第１のプロセスを前記第１のＯＳから前記第２のＯＳに移動する場合に、前記第１のプロセスのプロセスＩＤと、前記第１のプロセスの共有領域に配置した前記第１のプロセスのデータと、前記第１のプロセスの固有領域に配置した前記第１のプロセスのデータとを、同一の値および同一の配置に保ったまま、前記第１のプロセスを前記第２のＯＳで走行させることを特徴とする請求項２の仮想計算機システム。
【請求項８】
記憶装置と、当該記憶装置に接続されたプロセッサと、当該プロセッサ上で実行され、当該プロセッサに複数のＯＳの実行制御をさせるハイパーバイザとを備える仮想計算機システムにおける制御方法であって、
前記ハイパーバイザが、
前記複数のＯＳのそれぞれで割り付けるプロセスＩＤが前記仮想計算機システム全体で重複しないように管理するＰＩＤ管理ステップと、
前記ＯＳに対する仮想アドレス空間および物理アドレス空間の割り当てを指示する領域指示ステップを備え、
前記領域指示ステップは、
前記複数のＯＳのそれぞれが利用する前記記憶装置を、全てのＯＳが読み書き可能な領域であるである物理共有領域、および前記物理共有領域以外の領域である物理固有領域として割り当てる物理アドレス管理ステップと、
前記複数のＯＳのそれぞれが仮想アドレス空間における仮想固有領域に関する情報を記録し、前記ＯＳから要求があった場合に、前記情報に基づいて、既に他のＯＳに割り当てられている仮想固有領域と重複しない仮想アドレスからなる仮想固有領域を前記ＯＳに割り当てる仮想アドレス管理ステップと、
を備える制御方法。
【請求項９】
記憶装置と、当該記憶装置に接続されたプロセッサと、当該プロセッサ上で実行され、当該プロセッサに複数のＯＳの実行制御をさせるハイパーバイザとを備える仮想計算機システムにおけるプログラムであって、
前記ハイパーバイザに、
前記複数のＯＳのそれぞれで割り付けるプロセスＩＤが前記仮想計算機システム全体で重複しないように管理するＰＩＤ管理ステップと、
前記ＯＳに対する仮想アドレス空間および物理アドレス空間の割り当てを指示する領域指示ステップを実行させ、
前記領域指示ステップでは、
前記複数のＯＳのそれぞれが利用する前記記憶装置を、全てのＯＳが読み書き可能な領域であるである物理共有領域、および前記物理共有領域以外の領域である物理固有領域として割り当てる物理アドレス管理ステップと、
前記複数のＯＳのそれぞれが仮想アドレス空間における仮想固有領域に関する情報を記録し、前記ＯＳから要求があった場合に、前記情報に基づいて、既に他のＯＳに割り当てられている仮想固有領域と重複しない仮想アドレスからなる仮想固有領域を前記ＯＳに割り当てる仮想アドレス管理ステップと、
を実行させるプログラム。
【請求項１０】
記憶装置と、当該記憶装置に接続されたプロセッサと、当該プロセッサ上で実行され、当該プロセッサに複数のＯＳの実行制御をさせるハイパーバイザとを備える集積回路であって、
前記ハイパーバイザは、
前記複数のＯＳのそれぞれで割り付けるプロセスＩＤが前記仮想計算機システム全体で重複しないように管理するＰＩＤ管理部と、
前記ＯＳに対する仮想アドレス空間および物理アドレス空間の割り当てを指示する領域指示部を備え、
前記領域指示部は、
前記複数のＯＳのそれぞれが利用する前記記憶装置を、全てのＯＳが読み書き可能な領域であるである物理共有領域、および前記物理共有領域以外の領域である物理固有領域として割り当てる物理アドレス管理手段と、
前記複数のＯＳのそれぞれが仮想アドレス空間における仮想固有領域に関する情報を記録し、前記ＯＳから要求があった場合に、前記情報に基づいて、既に他のＯＳに割り当てられている仮想固有領域と重複しない仮想アドレスからなる仮想固有領域を前記ＯＳに割り当てる仮想アドレス管理部と、
を備える集積回路。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、単一のハードウェア上で複数のゲストＯＳを実行する仮想計算機システムのうち、ゲストＯＳの生成を稼働中のゲストＯＳの複製によって行う仮想計算機システムにおいて、複数のゲストＯＳに分散して走行中のプロセスを一つのゲストＯＳに統合することで稼働中のゲストＯＳの数を減らし、仮想計算機システムの負荷を低減する方法に関する。
【背景技術】
【０００２】
従来、仮想計算機システムにおいて、アプリケーションを安全に実行するために、物理メモリ上でＯＳを複製する手法によって、親となるゲストオペレーティングシステム（ゲストＯＳ）からアプリケーション実行用のゲストＯＳを複製し、各アプリケーションを独立したゲストＯＳ上で実行する方法があり（例えば、特許文献１および特許文献２参照）、ＶＭフォークと呼ばれている。ＶＭフォークでは、一つのアプリケーションの実行につき一つのゲストＯＳを起動するので、実行中のアプリケーションの数が増加すると、それにしたがってゲストＯＳの数も増加する。安全性などの観点から問題のないアプリケーションは一つのゲストＯＳ上に統合することで実行中のゲストＯＳの数を減らすことが可能であるが、そのためには走行中のアプリケーションをあるゲストＯＳからあるゲストＯＳへ移動する方法が必要となる。
【０００３】
走行中のプロセスを二つのＯＳ間で移動させる方法としては、プロセス移動あるいはプロセスマイグレーションという技術がある（例えば、特許文献３参照）。図２２は、前記特許文献３に記載された従来のプロセス移動を示すものである。プロセス２はＯＳ−Ｂ２３１のプロセスであり、物理共有領域２０２にはプロセスのＯＳに非依存のデータを、物理固有領域Ｂ２０４にはプロセスのＯＳに依存のデータを格納している。プロセス２の仮想共有領域２４３と仮想固有領域Ｂ２４２はそれぞれプロセス２のページテーブル２３２によって物理共有領域２０２とＯＳ−Ｂの物理固有領域Ｂ２０４に変換されアクセスされる。今、プロセス２をＯＳ−Ａ２１１のプロセス１へ移動する。仮想共有領域２４３に格納されているデータは各プロセスのＯＳに依存しないデータであり、ＯＳ−Ａのページテーブル２１２にエントリを追加することでＯＳ−Ａからアクセス可能になり、物理メモリ上でデータを移動する必要はない。一方、仮想固有領域Ｂ２４２に格納されているデータは、各プロセスのＯＳに依存したデータのため、ＯＳ−Ｂの物理固有領域Ｂ２０４からＯＳ−Ａの物理固有領域Ａ２０３へ移動および変換の必要がある。システム全体としては仮想共有領域２４３に配置したデータは物理的な移動がないため、プロセス移動のオーバーヘッドを低減できるとしている。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００４−１３３８９４号公報
【特許文献２】特開２００８−１６５７９５号公報
【特許文献３】特開２０１０−２５０７２２号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
前記従来の構成では、ＯＳ固有領域に配置されたデータに関しては、予め移動先の領域を確保した上で、前記データの物理的な位置を前記領域へ移動し、前記移動先の環境に応じて変換する必要がある。そのため、プロセス移動のオーバーヘッドが増加されるという課題を有していた。
【０００６】
本発明は、前記従来の課題を解決するもので、ＯＳ固有領域に配置されたデータの移動と変換を廃することによってプロセス移動のオーバーヘッドを低減し、複数の仮想計算機を短時間のうちに一つに統合する機能を提供することを目的とする。
【課題を解決するための手段】
【０００７】
前記従来の課題を解決するために、本発明の仮想計算機システムは、記憶装置と、当該記憶装置に接続されたプロセッサと、当該プロセッサ上で実行され、当該プロセッサに複数のＯＳの実行制御をさせるハイパーバイザとを備える仮想計算機システムであって、前記ハイパーバイザは、前記複数のＯＳのそれぞれで割り付けるプロセスＩＤが前記仮想計算機システム全体で重複しないように管理するＰＩＤ管理部と、前記ＯＳに対する仮想アドレス空間および物理アドレス空間の割り当てを指示する領域指示部を備え、前記領域指示部は、前記複数のＯＳのそれぞれが利用する前記記憶装置を、全てのＯＳが読み書き可能な領域であるである物理共有領域、および前記物理共有領域以外の領域である物理固有領域として割り当てる物理アドレス管理手段と、前記複数のＯＳのそれぞれが仮想アドレス空間における仮想固有領域に関する情報を記録し、前記ＯＳから要求があった場合に、前記情報に基づいて、既に他のＯＳに割り当てられている仮想固有領域と重複しない仮想アドレスからなる仮想固有領域を前記ＯＳに割り当てる仮想アドレス管理部と、を備える。
【０００８】
本構成によって、複製によって生成されたゲストＯＳ上のプロセスはシステム全体で唯一のプロセスＩＤと物理固有領域と仮想固有領域とを得る。統合元のゲストＯＳは統合先のゲストＯＳとそのプロセスＩＤと仮想固有領域が重複しないため、統合元のプロセスを統合先に移動する際にデータの移動と変換のオーバーヘッドを低減することができる。
【発明の効果】
【０００９】
本発明によれば、プロセス移動を行う場合に、ＯＳの物理固有領域の物理メモリ上の移動を行わないのでプロセス移動時のオーバーヘッドを低減することができる。
【００１０】
また、プロセス移動後に移動元ＯＳを停止することで、ゲストＯＳ間のコンテキストスイッチ回数およびメモリフットプリントを低減し、システム全体の負荷を低減することができる。
【００１１】
また、ＯＳ固有のデータのＯＳ固有領域への格納と、物理アドレス上で機能するアクセス保護機構の利用と両立できる。
【図面の簡単な説明】
【００１２】
【図１】本発明の実施の形態１における仮想計算機システムの構成の一例を示す機能ブロック図
【図２】本発明の実施の形態１における、物理アドレス管理手段、仮想アドレス管理手段のそれぞれが管理するテーブルの一例を示す図
【図３】本発明の実施の形態１における、ＶＭフォーク前の仮想計算機システムの構成の一例を示す機能ブロック図
【図４】本発明の実施の形態１におけるプロセスリストおよびページテーブルの一例を示す図
【図５】本発明の実施の形態１における、ＶＭフォーク時の親ＯＳの処理の一例を示すフローチャート
【図６】本発明の実施の形態１における、ＶＭＭによるＶＭフォークの処理の一例を示すフローチャート
【図７】本発明の実施の形態１における、ＶＭＭによる物理固有領域確保の処理の一例を示すフローチャート
【図８】本発明の実施の形態１における、ＶＭＭによる仮想固有領域確保の処理の一例を示すフローチャート
【図９】本発明の実施の形態１における、ＶＭフォーク時の子ＯＳの処理の一例を示すフローチャート
【図１０】本発明の実施の形態１における、ＶＭＭによるプロセスＩＤ確保の処理の一例を示すフローチャート
【図１１】本発明の実施の形態１における、ＶＭＭによるプロセスＩＤ管理リストの一例を示す図
【図１２】本発明の実施の形態１における、ＯＳ統合の第一段階での仮想計算機システムの構成の一例を示す機能ブロック図
【図１３】本発明の実施の形態１における、ＯＳ統合の第二段階での仮想計算機システムの構成の一例を示す機能ブロック図
【図１４】本発明の実施の形態１における、プロセス移動時の子ＯＳの処理の一例を示すフローチャート
【図１５】本発明の実施の形態１における、プロセス移動時の親ＯＳの処理の一例を示すフローチャート
【図１６】本発明の実施の形態１における、ＯＳ統合の第一段階完了後のプロセスリストおよびページテーブルの一例を示す図
【図１７】本発明の実施の形態１における、固有データ統合時の親ＯＳの処理の一例を示すフローチャート
【図１８】本発明の実施の形態１における、固有データ統合時のＶＭＭの処理の一例を示すフローチャート
【図１９】本発明の実施の形態１における、ＯＳ統合の第二段階完了後のプロセスリストおよびページテーブルの一例を示す図
【図２０】本発明の実施の形態１における、ＶＭＭによる物理固有領域解放の処理の一例を示すフローチャート
【図２１】本発明の実施の形態１における、ＶＭＭによる仮想固有領域解放の処理の一例を示すフローチャート
【図２２】従来技術における仮想計算機システムの構成の一例を示す機能ブロック図
【発明を実施するための形態】
【００１３】
以下本発明の実施の形態について、図面を参照しながら説明する。
【００１４】
（実施の形態１）
図１は、本発明の実施の形態１における仮想計算機システムの全体図である。仮想計算機システムは計算機システムを時間的・空間的に複数のゲストＯＳに配分する。
【００１５】
仮想計算機システム１０１は、物理メモリ１１１、ＶＭＭ１２１、ＯＳ−Ａ１３１、ＯＳ−Ｂ１４１を備える。
【００１６】
物理メモリ１１１は、連続したアドレス空間を持つ。ゲストＯＳやその上で走行するプロセスは前記物理メモリ１１１にロードされ実行される。前記物理メモリ１１１上でＶＭＭ１２１を実行することも可能である。
【００１７】
ＶＭＭ１２１は、ＣＰＵ、物理メモリなどを時間的・空間的に分割し、ゲストＯＳに割り当てる機能を備える。ＶＭＭ１２１は、ＰＩＤ管理手段１２３と、物理アドレス管理手段１２５、仮想アドレス管理手段１２６を備える領域指示手段１２４と、通信路１２２を備える。なお、ＶＭＭ１２１は、ハイパーバイザとも称される。
【００１８】
通信路１２２は、ゲストＯＳが互いにデータをやり取りするためのＶＭＭ１２１の機能である。ゲストＯＳは、ＶＭＭ１２１に提供されるインタフェースを用いて特定のゲストＯＳにデータを送信することができる。あるいは特定のゲストＯＳからデータを受信することができる。
【００１９】
ＰＩＤ管理手段１２３は、各ゲストＯＳがそのプロセスに割り付けるプロセスＩＤを仮想計算機システム１０１全体にわたって一元的に管理し、各ゲストＯＳで割り付けるプロセスＩＤが仮想計算機システム１０１全体で重複しないようにする。したがって、いったんゲストＯＳによって割り付けられたプロセスＩＤは、他のゲストＯＳで使用されることはない。ＰＩＤ管理手段１２３はたとえば図１１に示すようなリストを有し、現在使用されているプロセスＩＤのインデックスで参照される欄にはｒｅｓｅｒｖｅｄあるいはａｓｓｉｇｎｅｄを、使用されていないプロセスＩＤのインデックスで参照される欄は空欄を記録することで、新たに確保されるプロセスＩＤが使用中のプロセスＩＤでないことを保証する。
【００２０】
領域指示手段１２４は、仮想アドレス空間および物理アドレス空間に関し、ゲストＯＳに対する各アドレス空間の割り当てを指示する。
【００２１】
物理アドレス管理手段１２５は各ゲストＯＳが利用する物理メモリ１１１を管理する。物理共有領域１１２以外の領域は物理固有領域として、各ゲストＯＳの起動時に前記物理アドレス管理手段１２５が割り当てる。共有領域とは全てのゲストＯＳが読み書き可能な領域である。たとえばゲストＯＳ間でデータ通信をする際に共有領域が使用される。物理アドレス管理手段１２５は図２（ｂ）に示すような、領域を使用するＯＳＩＤと領域の開始アドレスと領域の終了アドレスとを記録するテーブルである物理領域表２１０を保持しており、この物理領域表２１０によって新しく確保する領域が他の既に確保された領域と重複しないよう調整する。ＯＳＩＤ＝０は特別なＯＳＩＤであって、物理共有領域を定義するために用いる。
【００２２】
仮想アドレス管理手段１２６は、各ゲストＯＳの仮想アドレス空間における仮想固有領域（たとえば１５２と１６２）に関する情報を記録し、ゲストＯＳから要求があった場合に、前記情報に基づいて、既に他のゲストＯＳに割り当てられている仮想固有領域と重複しない仮想アドレスからなる仮想固有領域を前記ゲストＯＳに割り当てる。仮想アドレス管理手段１２６は図２（ａ）に示すような、領域を使用するゲストＯＳのＯＳＩＤと領域の開始アドレスと領域の終了アドレスとを記録するテーブルである仮想領域表２００を保持しており、この仮想領域表２００によって新しく確保する領域が他の既に確保された領域と重複しないよう調整する。ＯＳＩＤ＝０は特別なＯＳＩＤであって、仮想共有領域を定義するために用いる。
【００２３】
図３にＶＭフォーク前の仮想計算機システムの構成の一例を示す。ＯＳ−Ａ１３１は仮想計算機上で動作するゲストＯＳである。ＯＳ−Ａ１３１は、プロセスリスト１３２と、前記プロセスリスト１３２によって管理されるプロセス構造体１３４と、前記プロセス構造体１３４に関連付けられたページテーブル１３５と、前記ページテーブル１３５を管理するページテーブル管理１３６と、前記プロセス構造体１３４とページテーブル１３５を管理するプロセス生成手段１３３と、フォークフラグ１３７とを備える。
【００２４】
プロセスリスト１３２は、一つのゲストＯＳにつき一つ存在する。図４は、プロセスリストおよびページテーブルの一例を示す図である。図４（ａ）はＯＳ−Ａ、図４（ｂ）はＯＳ−Ｂについてのものである。図４では、プロセスリスト１３２とプロセス構造体１３４とページテーブル１３５の関係を図示している。図４（ａ）に示すようにプロセスリスト１３２は、プロセス構造体のリストであり、図３におけるＯＳ−Ａ１３１はこのプロセスリスト１３２にしたがってプロセスを実行する。図４（ａ）において各行はプロセス構造体を表す。プロセス構造体は、プロセスを特定するためのプロセスＩＤと、プロセスのページテーブルへのリンクをそれぞれ一つずつ備える。一つのプロセス構造体が複数のプロセスＩＤやページテーブルを備えることはない。
【００２５】
プロセス生成手段１３３は、一つのゲストＯＳにつき一つ存在し、プロセス構造体（たとえば１３４）とページテーブル（たとえば１３５）の生成と変更と廃棄を行う。プロセス生成手段１３３はプロセスの生成に先立ち、ＶＭＭ１２１のＰＩＤ管理手段１２３からプロセスＩＤを取得する。あるいはプロセス生成手段１３３はプロセスを廃棄した後、プロセスＩＤをＰＩＤ管理手段１２３に返却する。
【００２６】
プロセスは仮想アドレス空間１５１を有し、この仮想アドレス空間１５１は前記プロセスに固有のページテーブル１３５によって物理アドレスに変換され、アクセス可能となる。
【００２７】
ページテーブル管理１３６はページテーブルの生成と廃棄および更新を行う。
【００２８】
仮想計算機システム１０１は新たなゲストＯＳを起動する際、そのゲストＯＳを、他のゲストＯＳの複製として作成する。フォークフラグ１３７は、新たにゲストＯＳが作成された場合とゲストＯＳが廃棄された場合にＶＭＭ１２１がセットするものである。起動中の各ゲストＯＳのページテーブル管理は、フォークフラグ１３７がセットしてある場合に、ＶＭＭ１２１の仮想アドレス管理手段１２６を呼び出し、前記ページテーブル管理の管理するページテーブルの状態を更新する。前記ページテーブルの状態を更新した後、前記ページテーブル管理は、フォークフラグ１３７をリセットする。
【００２９】
ＯＳ−Ｂ１４１は、ＶＭＭ１２１によりＯＳ−Ａ１３１がフォークされたものであり、機能ブロックの構成は、ＯＳ−Ａ１３１と同様である。
【００３０】
ＶＭＭによるゲストＯＳの生成についてフローチャートを用いて説明する。通常、計算機システムにおいては、ＯＳはアプリケーションを実行する際にプロセスを生成する。仮想計算機システム１０１は、アプリケーションを実行するために、ＶＭフォークを実施する。すなわち、現在走行中のゲストＯＳの物理固有領域を物理メモリ１１１上の別の領域に複製することで新しいゲストＯＳを生成し、前記複製されたゲストＯＳ上でプロセスを生成し、前記プロセスがアプリケーションを実行するところまでをひとまとまりの動作として実施する。図５はＶＭフォーク時の複製元となるゲストＯＳ（親ＯＳ）のフローチャートである。図６はＶＭフォーク時のＶＭＭ１２１のフローチャートであり、図７と図８はそれぞれ物理固有領域と仮想固有領域の確保の詳細を示すフローチャートである。図９はＶＭフォーク時の新規に生成されたゲストＯＳ（子ＯＳ）のフローチャートである。図１０はＰＩＤ取得の詳細を示すフローチャートである。以下、それぞれのフローチャートについて説明する。
【００３１】
説明のため、図１におけるＯＳ−Ａ１３１からＯＳ−Ｂ１４１をＶＭフォークすることを考える。ＶＭフォークの処理は図５のフローから始まる。
【００３２】
図５において、ユーザから新しくアプリケーションの実行の命令を受けると、ＯＳ−Ａ１３１はフォークフラグ１３７の状態を検査する（ステップＳ０７１）。
【００３３】
フォークフラグ１３７がセットされている場合（ステップＳ０７１がＹｅｓ）は仮想領域表２００に変更があることを示しているため、ＯＳ−Ａ１３１はまずＶＭＭ１２１に仮想領域表２００の変更を問い合わせ、その結果をページテーブル管理１３６がページテーブル１３５に反映し、フォークフラグ１３７をリセットする（ステップＳ０７２）。
【００３４】
フォークフラグ１３７がセットされていない場合（ステップＳ０７１がＮｏ）は、ＶＭＭ１２１にＯＳ−Ａ１３１のＶＭフォークを依頼する（ステップＳ０７３）。ステップＳ０７３により、ＶＭＭ１２１が起動する。
【００３５】
ＶＭＭ１２１のＶＭフォークの処理は図６で説明する。
【００３６】
図６において、ＶＭＭ１２１はゲストＯＳからＶＭフォークの要求を受け取ると（ステップＳ００１）、物理メモリ１１１において子ＯＳの物理固有領域を確保し（ステップＳ００２）、さらに、ページテーブル１３５において子ＯＳの仮想固有領域を確保する（ステップＳ００３）。
【００３７】
ＶＭＭ１２１は、ＯＳ−Ａ１３１の物理固有領域をＯＳ−Ｂ１４１の物理固有領域Ｂ１１４にコピーすることでＯＳ−Ａ１３１を複製し、ＯＳ−Ｂ１４１を作成する（ステップＳ００４）。このとき、ＯＳ−Ｂ１４１が使用する仮想固有領域Ｂ１６３を確保したため、前記ＯＳ−Ｂ１４１の使用する仮想固有領域Ｂ１６３を他のゲストＯＳが使用しないようにする必要がある。この目的のため、起動中のすべてのゲストＯＳのフォークフラグをセットする（ステップＳ００５）。仮想計算機システム１０１では、各ゲストＯＳは他のゲストＯＳが使用する仮想固有領域をページテーブル上で仮想予約領域とすることで、他のゲストＯＳと重複する仮想アドレス空間を使用しないようにする。しかしながら、各ゲストＯＳにとっては他のゲストＯＳがどの領域をそのゲストＯＳの仮想固有領域として確保しているか、前記各ゲストＯＳ自身が単独で認識しうる手段を持たない。これに関してはＶＭＭ１２１が各仮想固有領域を、図２（ａ）に示す仮想領域表２００によって管理しているので、仮想領域表２００が更新された場合に、各ゲストＯＳはＶＭＭ１２１に問い合わせを行い、自身のページテーブルを更新する。次にＶＭＭ１２１はＯＳ−Ｂ１４１を起動する（ステップＳ００６）。それと同時に、ＯＳ−Ｂ１４１のために確保した物理固有領域Ｂ１１４をＯＳ−Ｂ１４１に通知する（ステップＳ００７）とともに、仮想固有領域Ｂ１６３をＯＳ−Ｂ１４１に通知する（ステップＳ００８）。以上で、ＶＭフォーク時におけるＶＭＭ１２１の処理は完了する。
【００３８】
ここで、物理固有領域確保の詳細なフローを図７に示す。領域指示手段１２４の物理アドレス管理手段１２５は、物理領域表２１０から未使用の領域を検索し（ステップＳ０１１）、物理領域表２１０に前記未使用の領域とその使用者のＯＳＩＤを登録する（ステップＳ０１２）。前記ステップＳ０１２によって、前記未使用の領域は前記使用者によって使用中の領域として認識される。前記領域は後にＯＳ−Ｂ１４１を起動する段になってＶＭＭ１２１より前記ＯＳ−Ｂ１４１に通知される。
【００３９】
同じく仮想固有領域確保の詳細なフローを図８に示す。領域指示手段１２４の仮想アドレス管理手段１２６は、仮想領域表２００から未使用の領域を検索し（ステップＳ０３１）、仮想領域表２００に前記未使用の領域とその使用者のＯＳＩＤを登録する（ステップＳ０３２）。前記ステップＳ０３２によって、前記未使用の領域は前記使用者によって使用中の領域として認識される。前記領域は後にＯＳ−Ｂ１４１を起動する段になってＶＭＭ１２１より前記ＯＳ−Ｂ１４１に通知される。
【００４０】
次に図９でＶＭフォーク時の子ＯＳの処理を説明する。ＶＭＭ１２１によって起動されたＯＳ−Ｂ１４１は、この時点でＯＳ−Ａ１３１と同等のプロセスが走行している状態である。ＯＳ−Ｂ１４１は、領域指示手段１２４から物理固有領域１１４Ｂを取得する（ステップＳ０８１）とともに仮想固有領域Ｂ１６３を取得する（ステップＳ０８２）。その後、全プロセスを停止する（ステップＳ０８３）。
【００４１】
次に、アプリケーション実行用のプロセスを作成する。まず、ＶＭＭ１２１のＰＩＤ管理手段１２３から新規にプロセスＩＤを取得する（ステップＳ０８４）。
【００４２】
ＯＳ−Ｂ１４１のプロセス生成手段１４３は、プロセスＩＤを取得した後、ページテーブル１４５を作成する（ステップＳ０８５）。
【００４３】
また、プロセス生成手段１４３は、プロセス構造体１４４を作成し、プロセスＩＤとページテーブル１４５へのリンクをプロセス構造体１４４に登録する（ステップＳ０８６）。
【００４４】
前記プロセス生成手段１４３は、プロセス構造体１４４をプロセスリスト１４２に登録し（ステップＳ０８７）、アプリケーションをディスクなどから物理固有領域Ｂ１１４にロードして実行する（ステップＳ０８８）。
【００４５】
以上で、ＶＭフォーク時の子ＯＳの処理は完了である。
【００４６】
プロセスＩＤの取得に関しては図１０と図１１を用いてその詳細を説明する。
【００４７】
ＶＭＭ１２１はゲストＯＳからプロセスＩＤ取得の要求を受け付ける（ステップＳ０５１）。
【００４８】
次にプロセスＩＤ管理リスト１５０から未使用のプロセスＩＤを一つ選び出す（ステップＳ０５２）。たとえば、図１１ではプロセスＩＤ２と４はフラグの欄が空欄なので未使用と判断される。
【００４９】
取得したプロセスＩＤについて、たとえば図１１におけるプロセスＩＤ管理リスト１５０のフラグをａｓｓｉｇｎｅｄとすることでその状態を使用中の状態に更新し（ステップＳ０５３）、ゲストＯＳに前記プロセスＩＤを通知する（ステップＳ０５４）。
【００５０】
前述した図１は、ＶＭフォーク完了後の状態である。ＯＳ−Ａ１３１からフォークしたＯＳ−Ｂ１４１の上でプロセス２が動作している。ＯＳ−Ｂ１４１はＯＳ−Ａ１３１からの複製のため、内部の構造は同一である。ただし、ＯＳ−Ｂ１４１は物理固有領域Ｂ１１４を使用する。ＯＳ−Ｂ１４１で走行するプロセス２は、仮想共有領域１６４と仮想固有領域Ｂ１６３と仮想予約領域Ｂ１６２を備える。一方で、ＯＳ−Ａ１３１で走行するプロセス１は、新たに仮想予約領域Ａ１５３を確保する。
【００５１】
図４（ａ）（ｂ）はＶＭフォーク完了後のプロセスリストおよびページテーブルの状態の一例である。図４（ａ）がＯＳ−Ａ１３１、図４（ｂ）がＯＳ−Ｂ１４１のものである。プロセス１のプロセス構造体１３４とプロセス２のプロセス構造体１４４はそれぞれＯＳ−Ａ１３１のプロセスリスト１３２とＯＳ−Ｂ１４１のプロセスリスト１４２に登録されている。１３２と１４２はそれぞれプロセス１のページテーブルとプロセス２のページテーブルを表す。プロセス１はその物理固有領域として０ｘ０７００００００を確保し、仮想固有領域０ｘ１０００００００を通じてアクセス可能である。プロセス２はその物理固有領域として０ｘ０８００００００を確保し、仮想固有領域０ｘ２０００００００を通じてアクセス可能である。いずれのプロセスも物理共有領域０ｘ００００００００については仮想共有領域０ｘ０９００００００を通じてアクセス可能である。おのおののプロセスの仮想固有領域を互いに使用しないために、プロセス１のページテーブル１３５ではプロセス２の仮想固有領域０ｘ２０００００００を仮想予約領域として定義し、プロセス２のページテーブル１４５ではプロセス１の仮想固有領域０ｘ１０００００００を仮想予約領域として定義している。仮想固有領域の予約はプロセスが三つ以上の場合でも同様である。
【００５２】
次にＯＳの統合について説明する。ＯＳの統合とは、ある二つのゲストＯＳについて、一方のゲストＯＳで稼動しているプロセスをもう一方のゲストＯＳへ移動し、移動元のＯＳを停止することで、元々二つのゲストＯＳ上で分かれて稼動していたプロセスをそのうちの一つのＯＳで稼動させることである。統合は二段階で実施される。まず、統合の第一段階では、プロセスを統合先のゲストＯＳへ移動する。すなわち仮想計算機システムは図１の状態から図１２の状態になる。つまり、ＯＳ−Ｂ１４１によって管理されていたプロセス２のプロセス構造体１４４が、ＯＳ−Ａ１３１に管理されるようになることで、プロセス２はＯＳ−Ａ１３１にスケジューリングされるようになる。このことによって、プロセス２はＯＳ−Ｂ１４１から独立して走行することが可能になる。移動元のゲストＯＳはスリープ状態に遷移するので、この段階でＶＭコンテキストスイッチを低減するという目的は達せられる。さらに統合の第二段階として移動プロセスの物理固有領域を移動先のゲストＯＳの物理固有領域に統合することができる。すなわち図１２の状態から図１３の状態になる。プロセス２のメモリ管理はＯＳ−Ｂ１４１からＯＳ−Ａ１３１に委譲され、プロセス２はＯＳ−Ｂ１４１から独立してメモリアクセスが可能になる。第二段階を完了すると移動元ゲストＯＳの管理する物理固有領域は開放することが可能になり、したがって、移動元ゲストＯＳの終了が可能になる。
【００５３】
以上のＯＳの統合の詳細についてフローチャートを用いて説明する。図１４はプロセス移動時の移動元ＯＳのフローチャートである。図１５はプロセス移動時の移動先のＯＳのフローチャートである。図１７は統合の第二段階における移動先ＯＳのフローチャートであり、図１８は同段階におけるＶＭＭのフローチャートである。以下、それぞれのフローチャートについて説明する。
【００５４】
プロセスの移動は移動元のゲストＯＳから開始する。以下、移動するプロセスを移動プロセスと呼ぶ。図１４においてＯＳ−Ｂ１４１は移動プロセスのプロセス構造体１４４をプロセスリスト１４２から削除する（ステップＳ０９１）。この時点で移動プロセスはＯＳ−Ｂ１４１では走行しなくなる。
【００５５】
次に、ＯＳ−Ｂ１４１は移動プロセスのプロセス構造体１４４の仮想アドレスとプロセスＩＤをＶＭＭ１２１の通信路１２２を使い、ＯＳ−Ａ１３１に通知する。まず、移動プロセスのプロセス構造体が配置されているページテーブルエントリの内容を移動先ＯＳに通知する（ステップＳ０９２）。
【００５６】
次に、移動プロセスのプロセス構造体の、移動元ＯＳにおける仮想アドレスを移動先ＯＳに通知する（ステップＳ０９３）。
【００５７】
次に、稼働中のプロセスがあるか否かを判定する（ステップＳ０９５）。稼働中のプロセスがあれば（ステップＳ０９５がＹｅｓ）、処理をいったん完了し、再び稼働中のプロセスについて同じ処理を行う。稼働中のプロセスがなくなれば（ステップＳ０９５がＮｏ）、ＯＳ−Ｂ１４１はＶＭＭ呼び出しによってスリープし、処理を終了する。
【００５８】
次に移動先ゲストＯＳでの処理を説明する。図１５においてＯＳ−Ａ１３１は、移動プロセスのプロセス構造体１４４にアクセスするためのページテーブルエントリをＯＳ−Ｂ１４１から取得し（ステップＳ１０１）、取得したページテーブルエントリをページテーブル１３５に登録する（ステップＳ１０２）。同様に、ＯＳ−Ｂ１４１から、移動プロセスのプロセス構造体１４４の仮想アドレスを取得する（ステップＳ１０３）とともに、プロセスＩＤを取得する（ステップＳ１０４）。ステップＳ０４１で取得したページテーブルエントリを、ステップＳ０４２でＯＳ−Ａ１３１のページテーブル１３５に登録すると、ＯＳ−Ａから移動プロセスのプロセス構造体１４４にアクセスできるようになる。この際、取得したページテーブルエントリが既存のページテーブルエントリと重複しないようにゲストＯＳの複製時に確保されているため、ＯＳ−Ａ１３１は前記ページテーブルエントリでアクセスされるデータの仮想アドレスの変換を省略することが可能であり、プロセス移動時のオーバーヘッドの低減に貢献している。さらに移動プロセスのページテーブルは、ページテーブルエントリの追加でＯＳ−Ａ１３１からアクセスできるようになるため、物理固有領域Ｂに配置されたままであり、この点でもプロセス移動時のオーバーヘッドの低減に貢献している。この後、ステップＳ０４３とステップＳ０４４で取得した移動プロセスのプロセスＩＤをＯＳ−Ａ１３１のプロセスリスト１３２に登録する（ステップＳ１０５）とともに、プロセス構造体１４４をＯＳ−Ａ１３１のプロセスリスト１３２に登録する（ステップＳ１０６）。この際にも、プロセスＩＤはシステム全体で重複しないように確保されているため、プロセスＩＤの重複によるプロセスＩＤ変換の処理を省くことができるため、プロセス移動のオーバーヘッドの低減に貢献している。この処理が完了するとプロセス２はＯＳ−Ａ１３１上で走行可能となる。
【００５９】
各ゲストＯＳのプロセスリスト１３２と１４２およびページテーブル１３５と１４５の構成は図１６のようになる。図１６（ａ）はＯＳ−Ａ、図１６（ｂ）はＯＳ−Ｂについてのものである。プロセス１のプロセス構造体に関しては、変更はない。プロセス２のプロセス構造体が新たにプロセスリスト１３２に追加されている。プロセス１のページテーブルは物理固有領域Ａ１１３に、プロセス２のページテーブルは物理固有領域Ｂ１１４に配置されている。
【００６０】
統合の第二段階では、移動元ゲストＯＳ（たとえばＯＳ−Ｂ１４１）の物理固有領域内にあるデータを移動先ゲストＯＳ（たとえばＯＳ−Ａ１３１）の物理固有領域に移動し、統合を完了する。図１７はその処理をフローチャートで示したものである。
【００６１】
まず、プロセス２のデータを移動するために、プロセス２を停止する（ステップＳ１１１）。
【００６２】
次に、プロセス２の物理固有領域Ｂ１１４のデータを移動先の物理固有領域Ａ１１３に移動する（ステップＳ１１２）。
【００６３】
この処理によって仮想アドレスと物理アドレスの対応が変更されるため、ページテーブル１４５を更新する（ステップＳ１１３）。
【００６４】
データの移動・変換完了後、前記停止していたプロセス２を再開する（ステップＳ１１４）。
【００６５】
最後にＯＳ−Ｂ１４１の物理固有領域Ｂ１１４を開放するため、データの移動の完了をＶＭＭ１２１に通知する（ステップＳ１１５）。
【００６６】
図１８は統合の完了を受け取ったＶＭＭ１２１の処理を示す。
【００６７】
まず、ＶＭＭ１２１は統合完了の通知を受け取る（ステップＳ１２１）。
【００６８】
プロセス２は完全にＯＳ−Ａ１３１上に移動しており、ＶＭＭ１２１はＯＳ−Ｂ１４１を廃棄できる状態にあると判断し、ＯＳ−Ｂ１４１の使用する資源をすべて解放する（ステップＳ１２２）。この判断は、ステップＳ０９６でＯＳ−Ｂ１４１がスリープすることによって可能になる。ゲストＯＳのスリープはＶＭＭ呼び出しとして実現されており、ＶＭＭはゲストＯＳのスリープ状態を検知することによりステップＳ１２２の処理を実現することが可能である。この処理によって物理固有領域Ｂ１１４と仮想固有領域Ｂ１６３も解放される。
【００６９】
仮想領域表がステップＳ１２２によって更新されたため、ＶＭＭは起動中のすべてのゲストＯＳのフォークフラグをセットし、各ゲストＯＳのページテーブルの更新を開始させる（ステップＳ１２３）。各ゲストＯＳのプロセスリスト１３２と１４２およびページテーブル１３５と１４５の構成は図１９のようになる。図１９（ａ）はＯＳ−Ａ、図１９（ｂ）はＯＳ−Ｂについてのものである。プロセス１およびプロセス２のプロセス構造体に関しては、変更はない。ＯＳ−Ｂ１４１の使用する資源はＶＭＭにより解放されたので、ＯＳ−Ｂのプロセス構造体のリストは消滅している。
【００７０】
物理固有領域の解放と仮想固有領域の解放それぞれの処理について図２０と図２１に示すフローチャートを用いて説明する。
【００７１】
まず、図２０を用いて物理固有領域を解放する処理を説明する。
【００７２】
ＶＭＭ１２１は、物理領域表で検索し、解放する領域の有無を判定する（ステップＳ０２１）。解放する領域が見つからない場合（ステップＳ０２１がＮｏ）、処理を終了する。解放する領域が見つかった場合（ステップＳ０２１がＹｅｓ）、その領域のＯＳＩＤの検査を行う（ステップＳ０２２）。ＯＳＩＤが異なる場合（ステップＳ０２２がＮｏ）、処理を終了する。ＯＳＩＤが一致する場合（ステップＳ０２２がＹｅｓ）、前記領域を未使用の状態に変更する、すなわち物理領域表２１０からエントリを取り除く（ステップＳ０２３）。
【００７３】
次に、図２１を用いて仮想固有領域を解放する処理を説明する。
【００７４】
ＶＭＭ１２１は、仮想領域表を検索し、解放する領域の有無を判定する（ステップＳ０４１）。解放する領域が見つからない場合（ステップＳ０４１がＮｏ）、処理を終了する。解放する領域が見つかった場合（ステップＳ０４１がＹｅｓ）、その領域のＯＳＩＤの検査を行う（ステップＳ０４２）。ＯＳＩＤが異なる場合（ステップＳ０４２がＮｏ）、処理を終了する。ＯＳＩＤが一致する場合（ステップＳ０４２がＹｅｓ）、前記領域を未使用の状態に変更する、すなわち仮想領域表２００からエントリを取り除く（ステップＳ０４３）。
【００７５】
以上のような構成により、本実施の形態に係る仮想計算機システムは、第一のＯＳおよび第一のＯＳからＶＭフォークによって生成された第二のＯＳそれぞれが、ＰＩＤが重複しないようにプロセスを生成することが可能であると共に、物理アドレスと仮想アドレスのいずれもが重複しないように物理固有領域と仮想固有領域を確保することができる。以上により、ＰＩＤの変換、物理アドレス空間上のデータの移動、データのアドレス変換といった処理が不要になるため、プロセス移動に必要な資源の移動を最小化できる。これによって、あるゲストＯＳから別のゲストＯＳへのプロセスの移動のオーバーヘッドを最小にすると共に、プロセス移動によって未使用となったゲストＯＳに関しては、その資源を解放することで、仮想計算機システム全体の資源利用を効率化することができる。
【００７６】
なお、図１に示す仮想計算機システムの各機能ブロックは、典型的にはプロセッサと外部メモリとの協同で処理されるプログラムとして実現されるが、集積回路であるＬＳＩで実現してもよい。これらの各機能ブロックは個別に１チップ化されても良いし、一部又は全てを含むように１チップ化されても良い。ここでは、ＬＳＩとしたが、集積度の違いにより、ＩＣ、システムＬＳＩ、スーパーＬＳＩ又はウルトラＬＳＩと呼称されることもある。
【００７７】
また、集積回路化の手法はＬＳＩに限るものではなく、専用回路又は汎用プロセッサで実現してもよい。ＬＳＩ製造後に、プログラムすることが可能なＦＰＧＡ（Ｆｉｅｌｄ  Ｐｒｏｇｒａｍｍａｂｌｅ  Ｇａｔｅ  Ａｒｒａｙ）や、ＬＳＩ内部の回路セルの接続や設定を再構成可能なリコンフィギュラブル・プロセッサを利用しても良い。
【００７８】
さらには、半導体技術の進歩又は派生する別技術によりＬＳＩに置き換わる集積回路化の技術が登場すれば、当然、その技術を用いて機能ブロックの集積化を行ってもよい。
【００７９】
また、本発明は、プロセッサとタイマとを備えた計算処理装置であれば、あらゆる計算機、電子機器、情報機器、ＡＶ機器、通信機器及び家電機器にも適用可能であり、例えば、ＰＣ（パーソナルコンピュータ）、携帯情報端末（携帯電話、スマートフォン及びＰＤＡなど）、テレビ、ハーディスクレコーダー、ＤＶＤ及びブルーレイディスクなどを用いた各種ディスクレコーダー、ＤＶＤ及びブルーレイディスクなどを用いた各種ディスクプレイヤー、及びカーナビゲーションシステムなどにも応用できる。
【００８０】
また、前述の説明はあらゆる点において本発明の例示に過ぎず、その範囲を限定しようとするものではない。本発明の範囲を逸脱することなく種々の改良や変形を行うことができることは言うまでもない。
【産業上の利用可能性】
【００８１】
低価格帯のプロセッサでは仮想化のサポートがなく、仮想計算機システムを構築する場合に、ゲストＯＳの切換えのコストが前記システムの性能に及ぼす影響は大きい。本発明にかかる仮想計算機システムは、複数のゲストＯＳを統合する機能を有し、前記低価格帯のプロセッサを使用する仮想計算機システムで、ゲストＯＳの複製によるアプリケーション実行環境を構築する場合に、システム全体の負荷軽減の手段として有用である。
【符号の説明】
【００８２】
１０１    仮想計算機システム
１１１    物理メモリ
１１２，２０２    物理共有領域
１１３，２０３    物理固有領域Ａ
１１４，２０４    物理固有領域Ｂ
１２１    ＶＭＭ
１２２    通信路
１２３    ＰＩＤ管理手段
１２４    領域指示手段
１２５    物理アドレス管理手段
１２６    仮想アドレス管理手段
１３１，１４１    ＯＳ
１３２，１４２    プロセスリスト
１３３，１４３    プロセス生成手段
１３４，１４４    プロセス構造体
１３５，１４５，２１２，２３２    ページテーブル
１３６，１４６    ページテーブル管理
１３７，１４７    フォークフラグ
１５０    プロセスＩＤ管理リスト
１５１，１６１    仮想アドレス空間
１５２，２２２    仮想固有領域Ａ
１６３，２４２    仮想固有領域Ｂ
１５３    仮想予約領域Ａ
１６２    仮想予約領域Ｂ
１５４，１６４，２２３，２４３    仮想共有領域
２００    仮想領域表
２１０    物理領域表
４００，４１０    プロセス構造体のリスト
４０１，４１１    ページテーブル
【図１】
2014139702.tif 000003
【図２】
2014139702.tif 000004
【図３】
2014139702.tif 000005
【図４】
2014139702.tif 000006
【図５】
2014139702.tif 000007
【図６】
2014139702.tif 000008
【図７】
2014139702.tif 000009
【図８】
2014139702.tif 000010
【図９】
2014139702.tif 000011
【図１０】
2014139702.tif 000012
【図１１】
2014139702.tif 000013
【図１２】
2014139702.tif 000014
【図１３】
2014139702.tif 000015
【図１４】
2014139702.tif 000016
【図１５】
2014139702.tif 000017
【図１６】
2014139702.tif 000018
【図１７】
2014139702.tif 000019
【図１８】
2014139702.tif 000020
【図１９】
2014139702.tif 000021
【図２０】
2014139702.tif 000022
【図２１】
2014139702.tif 000023
【図２２】
2014139702.tif 000024