(57)【要約】  複数のゲストパーティション（２４、２６、２８）を１つのホストハードウェアパーティション（１０）内で実行できるようにする仮想化インフラストラクチャ。ホストシステムは、個別の論理的なまたは仮想のパーティション（２４、２６、２８）へと分割され、特別なインフラストラクチャパーティション（１２〜１４、１６、１８、２０、２２）が実装されて、リソース管理をコントロールし、また物理的なＩ／Ｏデバイスドライバをコントロールし、そしてそれらの物理的なＩ／Ｏデバイスドライバが、他の個別の論理的なまたは仮想のゲストパーティション（２４、２６、２８）内のオペレーティングシステムによって使用される。ホストハードウェアのリソース管理は、リソース管理「ウルトラバイザ」パーティション（１４）内のトラッキングアプリケーションとして実行され、その一方でホストリソース管理の決定は、別個のオペレーションズパーティション（２２）内に保持されているポリシーに基づいて、より高いレベルのコマンドパーティション（２０）内で実行される。従来のハイパーバイザ（３２）は、それぞれのパーティション（２４、２６、２８）ごとにコンテキストの切り替えおよびコンテインメントエレメント（モニタ）まで低減され、その一方でシステムリソース管理機能は、ウルトラバイザパーティション（１４）内に実装される。ウルトラバイザパーティション（１４）は、ハードウェアリソースの割り当てのマスターインメモリデータベース（３３）を保持し、リソースをパーティション（２４、２６、２８）へ割り当てるよう求めるトランザクション要求を受け入れるためのコマンドチャネルを提供する。これはまた、個々のパーティション（２４、２６、２８）の個々の読み取り専用ビューを、関連付けられているパーティションモニタに提供する。ホストハードウェアのＩ／Ｏ管理は、特別な冗長Ｉ／Ｏパーティション（１６、１８）内に実装される。その他の論理的なまたは仮想のパーティション（２４、２６、２８）内におけるオペレーティングシステムは、ウルトラバイザパーティション（１４）によって確立されたメモリチャネルを介して、Ｉ／Ｏパーティション（１６、１８）とやり取りする。それぞれの論理的なまたは仮想のパーティション（２４、２６、２８）内のゲストオペレーティングシステムは、システムコールインターフェースを実装するモニタにアクセスするように修正され、このシステムコールインターフェースを通じて、ウルトラバイザパーティション（１４）、Ｉ／Ｏパーティション（１６、１８）、およびその他のすべての特別なインフラストラクチャパーティション（１２〜１３、２０、２２）は、相互に、またそれぞれのゲストパーティション（２４、２６、２８）とやり取りを開始することができる。これらのゲストオペレーティングシステムは、完全な仮想化システムはトラップを挿入することによって解決しなければならないというｘ８６システム内の「壊れた」命令を使用することを試みないように修正される。
2007510198.tif 000002
【特許請求の範囲】
【請求項１】
少なくとも１つのホストプロセッサと、最も高い特権を有するシステムメモリとより低い特権を有するユーザメモリとに分割されているメモリを含むシステムリソースとを有するホストコンピュータのための仮想化システムであって、
前記より低い特権を有するユーザメモリ内で機能し、前記ホストコンピュータを、少なくとも１つのユーザゲストパーティションと少なくとも１つのシステムパーティションとを含む複数の仮想パーティションへと分割する仮想化ソフトウェアであって、前記少なくとも１つのユーザゲストパーティションは、少なくとも１つのゲストオペレーティングシステムのための仮想化環境を提供し、前記少なくとも１つのシステムパーティションは、前記少なくとも１つのホストプロセッサおよび前記システムリソースの使用を管理する際に使用するためのリソースデータベースを保持する仮想化ソフトウェアと、
前記最も高い特権を有するシステムメモリ内で機能し、前記少なくとも１つのゲストパーティション内のゲストアプリケーションを、前記少なくとも１つのシステムパーティションによって前記少なくとも１つのゲストパーティションに割り当てられているメモリスペース内に保持する少なくとも１つのモニタと、
前記少なくとも１つのホストプロセッサ上で前記パーティション内のソフトウェアのマルチタスク処理をコントロールするための、前記少なくとも１つのモニタと、前記それぞれのゲストパーティションおよびシステムパーティションとの間におけるコンテキストの切り替えとを備えることを特徴とする仮想化システム。
【請求項２】
前記少なくとも１つのシステムパーティションは、リソース管理ソフトウェアアプリケーションを含み、このリソース管理ソフトウェアアプリケーションは、システムリソースをそれぞれのシステムパーティションおよびゲストパーティションに割り当て、前記リソースデータベース内における前記割り当てられたシステムリソースに対するインデックスを提供することを特徴とする請求項１に記載の仮想化システム。
【請求項３】
前記リソース管理ソフトウェアによる前記システムリソースの前記割り当てにおける要求された変更は、前記リソースデータベースを更新するために前記リソース管理ソフトウェアによって処理されるトランザクションとして前記リソース管理ソフトウェアに伝達されることを特徴とする請求項２に記載の仮想化システム。
【請求項４】
前記リソース管理ソフトウェアは、共有メモリをそれぞれのパーティションにメモリチャネルとして割り当て、これらのメモリチャネルを通じて、前記トランザクションは１つのパーティションから別のパーティションへ渡ることができることを特徴とする請求項３に記載の仮想化システム。
【請求項５】
処理上の障害を経験しているシステムパーティションは、前記障害の生じたシステムパーティションをリブートし、前記障害の生じたシステムパーティションのために保存されていたシステムリソースを前記リブートされたシステムパーティションに割り当て直し、前記障害の生じたパーティションによって進行されているあらゆる保留中のトランザクションをロールバックして、前記リソースデータベースエントリのステータスを前記システムパーティションの障害の時点よりも前のステータスに戻すことによって修復されることを特徴とする請求項４に記載の仮想化システム。
【請求項６】
前記少なくとも１つのシステムパーティションは、前記リソースデータベースおよび前記リソース管理ソフトウェアアプリケーションを含むウルトラバイザパーティションと、前記ホストシステムのためのリソース割り当てポリシーを所有するリソース割り当てソフトウェアを含むコマンドパーティションとを含み、このコマンドパーティションは、トランザクション内で指定されているように前記システムリソースを割り当て直すために前記リソース管理ソフトウェアによって処理するための前記コマンドパーティションと前記ウルトラバイザパーティションの間のコマンドメモリチャネルを通じて渡される前記トランザクションを作成することを特徴とする請求項５に記載の仮想化システム。
【請求項７】
前記リソース管理ソフトウェアは、前記障害の生じたシステムパーティションが関与するトランザクションの前記ロールバックを可能にするために、処理されたトランザクションの監査ログを保持し、前記監査ログからのトランザクションの再適用を可能にすることを特徴とする請求項６に記載の仮想化システム。
【請求項８】
前記システムパーティションは、ブートパーティションを含み、このブートパーティションは、他のシステムパーティションをブートおよびリブートすることが必要な場合の修復オペレーションのためのハードウェアパーティションブートファームウェアを含み、前記コマンドパーティションが、リソースを前記他のシステムパーティションに割り当てるためのトランザクションを作成することができるまで、前記他のシステムパーティションのためのリソースを要求する前記リソース管理ソフトウェアアプリケーションに対するトランザクションを開始することを特徴とする請求項６に記載の仮想化システム。
【請求項９】
前記コマンドパーティションは、前記リソース割り当てポリシーに基づいて前記トランザクションを作成するリソース割り当てソフトウェアを含むことを特徴とする請求項６に記載の仮想化システム。
【請求項１０】
前記少なくとも１つのモニタは、前記リソースデータベースを含む１つのシステムパーティションに関連付けられている１つのリードモニタを含み、前記リードモニタは、自分自身を、前記リソースデータベース内に保存されているパーティション記述子への読み取り専用アクセスに制限することを特徴とする請求項１に記載の仮想化システム。
【請求項１１】
前記少なくとも１つのモニタは、１つのゲストパーティションに関連付けられている１つのモニタを含み、前記リードモニタは、前記ゲストパーティションのためのパーティション記述子を前記リソースデータベースから読み取って、前記パーティション記述子を前記モニタに提供するように構成されており、これによって前記モニタは、前記パーティション記述子を使用して、ゲストアプリケーションを前記ゲストパーティション内に制限することができることを特徴とする請求項１０に記載の仮想化システム。
【請求項１２】
前記モニタは、いかなるシステムリソースへのアクセスもコントロールしないことを特徴とする請求項１１に記載の仮想化システム。
【請求項１３】
前記少なくとも１つのモニタは、それぞれの異なるゲストパーティションに関連付けられている１つの異なるモニタインスタンスを含み、それぞれの前記モニタは、その対応するゲストパーティション内の１つのゲストオペレーティングシステムに対してカスタマイズされており、このために、前記リソースデータベース内の前記ゲストオペレーティングシステムのためのパーティション記述子によって、前記ゲストオペレーティングシステムが、前記ゲストパーティションに割り当てられていないリソースを入手することが防止されることを特徴とする請求項１１に記載の仮想化システム。
【請求項１４】
前記ゲストオペレーティングシステムが、ｘ８６プロセッサ用にプログラムされている場合に、前記関連付けられているモニタは、トラップを使用して解決しなければならないセンシティブなオペレーティングシステム命令が前記ゲストオペレーティングシステムによって実行されるのを防止することを特徴とする請求項１３に記載の仮想化システム。
【請求項１５】
いくつかのモニタインスタンスは、別々のパーティションに関連付けられている複数のモニタの間で情報を共有できるようにするために、他のモニタインスタンスによってアクセスできる共有メモリにアクセスすることができることを特徴とする請求項１３に記載の仮想化システム。
【請求項１６】
前記システムリソースは、前記ホストコンピュータのそれぞれのゲストパーティションとシステムパーティションの間でトランザクションをやり取りできるようにするメモリチャネルを含み、前記メモリチャネルは、それぞれのパーティションに割り当てられている共有メモリを含むことを特徴とする請求項２に記載の仮想化システム。
【請求項１７】
前記少なくとも１つのシステムパーティションは、前記ホストコンピュータの物理的なＩ／Ｏハードウェアを前記Ｉ／Ｏパーティション内の１つのＩ／Ｏチャネルサーバのエンドポイントにマップする少なくとも１つの入力／出力（Ｉ／Ｏ）パーティションを含み、前記Ｉ／Ｏチャネルサーバは、前記Ｉ／Ｏパーティションと前記少なくとも１つのゲストパーティションまたはシステムパーティションとの間のメモリチャネルを介して前記物理的なＩ／Ｏハードウェアを少なくとも１つのゲストパーティションまたは別のシステムパーティションと共有し、前記リソース管理ソフトウェアは、共有メモリを前記少なくとも１つのゲストパーティションまたはシステムパーティションに、および前記Ｉ／Ｏパーティションに割り当てて、前記メモリチャネルを形成することを特徴とする請求項１６に記載の仮想化システム。
【請求項１８】
物理的なＩ／Ｏハードウェアにアクセスしたいという、前記少なくとも１つのゲストパーティションまたはシステムパーティションから前記Ｉ／Ｏチャネルサーバへの要求を受け取ると、前記Ｉ／Ｏパーティションは、前記少なくとも１つのゲストパーティションまたはシステムパーティションに関連付けられているモニタ内に保存されているパーティション記述子を使用してチェックを行い、前記要求されている物理的なＩ／Ｏハードウェアへのアクセスが有効であるかを確認することを特徴とする請求項１７に記載の仮想化システム。
【請求項１９】
前記少なくとも１つのＩ／Ｏパーティションによる前記Ｉ／Ｏパーティション内の前記Ｉ／Ｏチャネルサーバのエンドポイントへの前記ホストコンピュータの前記物理的なＩ／Ｏハードウェアの前記マッピングは、共有されている共通の物理的なＩ／Ｏハードウェアを通じて、それぞれのメモリチャネルによって前記Ｉ／Ｏパーティションに接続されている複数のパーティションから前記共通の物理的なＩ／ＯハードウェアへのあらゆるＩ／Ｏ要求を多重化するＩ／Ｏパーティションソフトウェアによって実行されることを特徴とする請求項１７に記載の仮想化システム。
【請求項２０】
前記Ｉ／Ｏパーティションに関連付けられているＩ／Ｏモニタは、前記Ｉ／Ｏモニタと前記Ｉ／Ｏパーティションの間にシステムコールインターフェースを実装し、前記システムコールインターフェースは、クライアントメモリチャネルドライバからそれぞれのメモリチャネルを通じて送信された要求のバッファパラメータとして入手されたクライアントパーティションの相対的なアドレスを、前記共通の物理的なＩ／Ｏハードウェアへのアクセスを要求している前記クライアントパーティションに現在割り当てられているメモリの有効なハードウェアの物理アドレスとして変換および確認することを特徴とする請求項１９に記載の仮想化システム。
【請求項２１】
前記Ｉ／Ｏパーティションのサーバと前記それぞれのクライアントパーティションの間のメッセージは、前記クライアントパーティションによってキューに入れられ、前記Ｉ／Ｏパーティションサーバによってキューから外され、前記パーティションの相対的な物理アドレスは、前記Ｉ／Ｏパーティションサーバによって前記Ｉ／Ｏモニタの助けを借りて物理的なＩ／Ｏハードウェアアドレスに変換され、それによって、前記Ｉ／Ｏモニタと前記共通の物理的なＩ／Ｏハードウェアとの間に接続されているハードウェアＩ／Ｏアダプタとデータをやり取りすることができることを特徴とする請求項２０に記載の仮想化システム。
【請求項２２】
前記少なくとも１つのＩ／Ｏパーティションによる前記Ｉ／Ｏパーティション内の前記Ｉ／Ｏチャネルサーバのエンドポイントへの前記ホストコンピュータの前記物理的なＩ／Ｏハードウェアの前記マッピングは、Ｉ／Ｏアクセスを要求しているクライアントパーティションとインテリジェントな物理的なＩ／Ｏハードウェアの間にパフォーマンスの高いメモリチャネルをセットアップするために前記メモリチャネルを介して前記Ｉ／ＯチャネルサーバにＩ／Ｏセットアップ情報を渡し、前記パフォーマンスの高いメモリチャネルを介して、Ｉ／Ｏアクセスを要求している前記クライアントパーティションと前記インテリジェントな物理的なＩ／Ｏハードウェアの間で直接データを送信することによって実行されることを特徴とする請求項１７に記載の仮想化システム。
【請求項２３】
Ｉ／Ｏアクセスを要求している前記クライアントパーティションは、ユーザモードＩ／Ｏまたはダイレクトメモリアクセスデータ転送オペレーションのうちの１つを使用して、前記Ｉ／Ｏメモリチャネルを介して前記インテリジェントな物理的なＩ／Ｏハードウェアにデータを転送することを特徴とする請求項２２に記載の仮想化システム。
【請求項２４】
前記少なくとも１つのＩ／Ｏパーティションは、２つの冗長Ｉ／Ｏパーティションを含むことを特徴とする請求項１７に記載の仮想化システム。
【請求項２５】
前記システムリソースは、前記ホストコンピュータの入力／出力（Ｉ／Ｏ）ハードウェアリソースを含むことを特徴とする請求項２に記載の仮想化システム。
【請求項２６】
前記システムリソースは、前記ホストコンピュータのそれぞれのホストプロセッサの処理の全体または一部を含むことを特徴とする請求項２に記載の仮想化システム。
【請求項２７】
前記リソース管理ソフトウェアアプリケーションは、前記リソース管理ソフトウェアアプリケーションによるＩＤＴ（Ｉｎｔｅｒｒｕｐｔ  Ｄｅｓｃｒｉｐｔｏｒ  Ｔａｂｌｅ）のコントロールを通じて前記少なくとも１つのホストプロセッサのコントロールを可能にするために仮想プロセッサの特権レベルを制限することによって、前記少なくとも１つのホストプロセッサの処理サイクルを割り当てることを特徴とする請求項２６に記載の仮想化システム。
【請求項２８】
前記リソース管理ソフトウェアアプリケーションは、前記ＩＤＴにアクセスして、前記少なくとも１つのホストプロセッサにタイマの割り込みを提供し、前記タイマの割り込みは、仮想プロセッサコンテキストの切り替えを開始するために前記コンテキストの切り替えによって使用されることを特徴とする請求項２７に記載の仮想化システム。
【請求項２９】
前記システムリソースは、前記ホストコンピュータの物理メモリを含むことを特徴とする請求項２に記載の仮想化システム。
【請求項３０】
前記リソースデータベースのメモリ割り当てページマップは、階層化されたページサイズモデルに従って編成され、この階層化されたページサイズモデルは、倍率として２ｘを使用するスケールの階層を含み、それによって、それぞれの階層化されたページサイズレベルにおける１つのインデックスページは、次に低い階層化されたページサイズレベルのサイズにおいて２ｘのメモリブロックを割り当てることができることを特徴とする請求項２９に記載の仮想化システム。
【請求項３１】
前記リソース管理ソフトウェアアプリケーションは、望ましいパーティション番号［Ｇ，Ｍ，Ｋ］用のパーティション記述子をメモリ内にＭｅｍ（Ｇ，Ｍ，Ｋ）＝（（Ｇ＊２１０＋Ｍ）＊２１０＋Ｋ）＊２１０＊（ワードサイズ）として保存することによって、前記メモリを前記それぞれのシステムパーティションおよびゲストパーティションに割り当て、その場合のワードサイズは２の累乗であることを特徴とする請求項３０に記載の仮想化システム。
【請求項３２】
前記保存されたパーティション記述子は、前記パーティション記述子によって定義されている前記パーティションに関連付けられている前記モニタに提供され、それによって前記モニタは、そのパーティション内のアプリケーションを前記パーティション記述子によって定義されている前記メモリに制限することができることを特徴とする請求項３１に記載の仮想化システム。
【請求項３３】
ｘ＝１０であり、仮想パーティション番号は、前記メモリ割り当てページマップ内において、前記仮想パーティション用の前記仮想パーティション記述子を前記仮想パーティション番号と同一視する４ｋのページのマップへの３２ビットのインデックス（２，１０，１０，１０）として表され、その場合の第１のビットは、より小さなページ内における副次割り当てを示し、３つの連続した２１０の値は、拡大縮小されたページを識別することを特徴とする請求項３０に記載の仮想化システム。
【請求項３４】
前記少なくとも１つのシステムパーティションは、前記リソースデータベースおよび前記リソース管理ソフトウェアアプリケーションを含むウルトラバイザパーティションと、前記ホストシステムのためのリソース割り当てポリシーを所有するコマンドパーティションとを含み、このコマンドパーティションは、トランザクション内で指定されているように前記システムリソースを割り当て直すために前記リソース管理ソフトウェアによって処理するための前記コマンドパーティションと前記ウルトラバイザパーティションの間のコマンドメモリチャネルを通じて渡される前記トランザクションを作成することを特徴とする請求項２に記載の仮想化システム。
【請求項３５】
前記少なくとも１つのシステムパーティションは、オペレーションズパーティションをさらに含み、このオペレーションズパーティションは、構成ポリシーを所有し、前記少なくとも１つのホストコンピュータのそれぞれのパーティションが割り当てられているそれぞれのドメインに関する持続性を追跡監視することを特徴とする請求項３４に記載の仮想化システム。
【請求項３６】
前記オペレーションズパーティションは、安全な接続を介して前記コマンドパーティションとの間でリソーストランザクションをやり取りすることを特徴とする請求項３５に記載の仮想化システム。
【請求項３７】
前記オペレーションズパーティションは、前記少なくとも１つのホストコンピュータの少なくとも１つのドメインのための仮想パーティションの定義の持続的なデータベースを保持するアプリケーションソフトウェアを含むことを特徴とする請求項３５に記載の仮想化システム。
【請求項３８】
前記コマンドパーティションは、最初の始動のための、およびホストコンピュータのパーティションの障害またはハードウェアの障害の場合のブートストラップの目的から、前記少なくとも１つのドメインのための前記仮想パーティションの定義のコピーを保存することを特徴とする請求項３７に記載の仮想化システム。
【請求項３９】
パーティションがアクティブにされる際に、前記オペレーションズパーティションは、前記アクティブにされるパーティションのためのリソースを要求している前記少なくとも１つのホストコンピュータのうちの１つのホストコンピュータを選択し、前記ホストコンピュータのコマンドパーティション内で実行されているリソースサービスに接続し、前記アクティブにされるパーティションの定義および開始コマンドを前記リソースサービスに提供することを特徴とする請求項３７に記載の仮想化システム。
【請求項４０】
前記コマンドパーティションは、前記リソースデータベースのコピーを保存し、前記リソースデータベースの前記コピーを使用して、前記アクティブにされるパーティションのための適切なリソースを選択し、前記コマンドメモリチャネルを介して前記リソースデータベースを更新するためのトランザクションを作成することを特徴とする請求項３９に記載の仮想化システム。
【請求項４１】
前記オペレーションズパーティションは、オペレーションズサービスソフトウェアを含み、このオペレーションズサービスソフトウェアは、前記少なくとも１つのホストコンピュータのオペレーションをモニタし、ホストコンピュータの障害を検出した場合には、障害の生じたホストコンピュータに割り当てられている仮想パーティションのための新しいホストコンピュータを選択することを特徴とする請求項３５に記載の仮想化システム。
【請求項４２】
前記オペレーションズパーティションは、前記少なくとも１つのホストコンピュータのシステムリソースの相互接続されているセットを１つのゾーンに割り当て、それぞれのパーティションは、前記それぞれのパーティションによって要求されている前記システムリソースを有するゾーンに割り当てられ、その場合に１つのゾーンは、１つのコンピュータネットワーク内の前記少なくとも１つのホストコンピュータのシステムリソースのためのリソースの割り当ての単位であることを特徴とする請求項３７に記載の仮想化システム。
【請求項４３】
前記オペレーションズパーティションは、ネットワーク接続を介して、前記オペレーションズパーティションを含まない１つのホストコンピュータの１つのコマンドパーティションにリソーストランザクションを送信することによって、前記オペレーションズパーティションを含まない前記ホストコンピュータに新しいパーティションを割り当てることを特徴とする請求項４２に記載の仮想化システム。
【請求項４４】
前記オペレーションズパーティションは、前記ネットワーク接続を介して１つのアクティブなパーティションのメモリコンテンツを第１のホストコンピュータから第２のホストコンピュータ内のアクティブにされるターゲットパーティションへ転送することによって、前記第１のホストコンピュータ上の前記アクティブなパーティションを前記第２のホストコンピュータへ移動できるようにすることを特徴とする請求項４３に記載の仮想化システム。
【請求項４５】
前記構成ポリシーは、それぞれのホストコンピュータのサービスの質の保証、帯域幅の保証、および物理的な位置のうちの少なくとも１つに基づいてシステムリソースを１つのゾーンに割り当てることを対象とすることを特徴とする請求項３５に記載の仮想化システム。
【請求項４６】
前記構成ポリシーは、別々の時点において別々のシステムリソーススケジュールに基づいて前記システムリソースの構成における変更を認めるようにユーザによって変更することができることを特徴とする請求項３５に記載の仮想化システム。
【請求項４７】
前記少なくとも１つのシステムパーティションは、前記オペレーションズパーティションをホストしている前記ホストコンピュータとは異なる第２のホストコンピュータ内の１つの冗長オペレーションズパーティションをさらに含むことを特徴とする請求項３５に記載の仮想化システム。
【請求項４８】
少なくとも１つのホストプロセッサとシステムリソースとを有する１つのホストコンピュータ上で複数のオペレーティングシステムインスタンスを管理する方法であって、
前記ホストコンピュータを、少なくとも１つのユーザゲストパーティションと少なくとも１つのシステムパーティションとを含む複数の仮想パーティションへと分割するステップであって、前記少なくとも１つのユーザゲストパーティションは、少なくとも１つのゲストオペレーティングシステムのための仮想化環境を提供し、前記少なくとも１つのシステムパーティションは、前記少なくとも１つのホストプロセッサおよび前記システムリソースの使用を管理する際に使用するためのリソースデータベースを保持するステップと、
前記少なくとも１つのゲストパーティション内のゲストアプリケーションを、前記少なくとも１つのシステムパーティションによって前記少なくとも１つのゲストパーティションに割り当てられているメモリスペース内に保持するステップと、
前記少なくとも１つのホストプロセッサ上で前記パーティション内のソフトウェアのマルチタスク処理をコントロールするための、前記それぞれのゲストパーティションとシステムパーティションの間におけるコンテキストの切り替えを提供するステップとを備えることを特徴とする方法。
【請求項４９】
前記少なくとも１つのシステムパーティションは、リソース管理ソフトウェアアプリケーションを含み、このリソース管理ソフトウェアアプリケーションは、システムリソースをそれぞれのシステムパーティションおよびゲストパーティションに割り当てるステップと、前記リソースデータベース内における前記割り当てられたシステムリソースに対するインデックスを提供するステップとを実行することを特徴とする請求項４８に記載の方法。
【請求項５０】
前記リソース管理ソフトウェアによる前記システムリソースの前記割り当てにおける要求された変更を、前記リソースデータベースを更新するために前記リソース管理ソフトウェアによって処理できるトランザクションとして伝達するステップをさらに含むことを特徴とする請求項４９に記載の方法。
【請求項５１】
共有メモリをそれぞれのパーティションにメモリチャネルとして割り当てるステップであって、これらのメモリチャネルを通じて、前記トランザクションは１つのパーティションから別のパーティションへ渡ることができるステップをさらに含むことを特徴とする請求項５０に記載の方法。
【請求項５２】
障害の生じたシステムパーティションをリブートし、前記障害の生じたシステムパーティションのために保存されていたシステムリソースを前記リブートされたシステムパーティションに割り当て直し、前記障害の生じたパーティションによって進行されているあらゆる保留中のトランザクションをロールバックして、前記リソースデータベースエントリのステータスを前記システムパーティションの障害の時点よりも前のステータスに戻すことによって、前記障害の生じたシステムパーティションを修復するステップをさらに含むことを特徴とする請求項５１に記載の方法。
【請求項５３】
前記少なくとも１つのシステムパーティションは、前記リソースデータベースおよび前記リソース管理ソフトウェアアプリケーションを含むウルトラバイザパーティションと、前記ホストシステムのためのリソース割り当てポリシーを所有するリソース割り当てソフトウェアを含み、前記リソースデータベースを更新するためのトランザクションを作成するコマンドパーティションとを含む方法であって、前記コマンドパーティションと前記ウルトラバイザパーティションの間のコマンドメモリチャネルを提供して、前記トランザクション内で指定されているように前記システムリソースを割り当て直すために前記コマンドメモリチャネルを通じて前記リソース管理ソフトウェアアプリケーションへ前記トランザクションを渡すさらなるステップを含むことを特徴とする請求項５２に記載の方法。
【請求項５４】
前記リソース管理ソフトウェアアプリケーションによって処理されたトランザクションの監査ログを提供するさらなるステップと、システムパーティションの障害時に、前記監査ログを使用して、前記障害の生じたシステムパーティションが関与するトランザクションをロールバックして、システムリソースを前記システムパーティションの障害よりも前の時点に戻すステップと、前記監査ログ内に保存されている完了したトランザクションを再び適用するステップのうちの少なくとも１つを実行するさらなるステップとを含むことを特徴とする請求項５３に記載の方法。
【請求項５５】
障害の生じたシステムパーティションをリブートし、障害よりも前の前記障害の生じたシステムパーティションの前記リソースを要求する前記リソース管理ソフトウェアアプリケーションに対するトランザクションを開始し、前記要求されているリソースを前記リブートされたシステムパーティションに割り当て直すことによって、前記障害の生じたシステムパーティションを修復するステップをさらに含むことを特徴とする請求項５３に記載の方法。
【請求項５６】
リソース割り当てポリシーを保持するオペレーションズパーティション、前記リソース割り当てポリシーに従ってリソースを要求するトランザクションを作成するコマンドパーティション、および前記トランザクションを処理して、前記トランザクションの処理に基づいて前記リソースデータベースを更新するリソース管理パーティションという少なくとも３つの別々のパーティション内のアプリケーションによる管理へとリソース管理機能を分離するステップを含むことを特徴とする請求項５３に記載の方法。
【請求項５７】
ゲストアプリケーションを、前記割り当てられているメモリスペース内に保持する前記ステップは、前記リソースデータベースを含む１つのシステムパーティションに関連付けられている１つのリードモニタを提供して、前記リードモニタを、前記リソースデータベース内に保存されているパーティション記述子への読み取り専用アクセスに制限するステップを含むことを特徴とする請求項４８に記載の方法。
【請求項５８】
前記リードモニタが、前記ゲストパーティションのためのパーティション記述子を前記リソースデータベースから読み取るステップと、前記パーティション記述子を、前記ゲストパーティションに関連付けられている１つのモニタに提供するステップと、前記モニタが、前記パーティション記述子を使用して、ゲストアプリケーションを前記ゲストパーティション内に制限するステップとをさらに含むことを特徴とする請求項５７に記載の方法。
【請求項５９】
それぞれの異なるゲストパーティションに関連付けられている１つの異なるモニタインスタンスを提供するステップと、それぞれの前記モニタを、その対応するゲストパーティション内の１つのゲストオペレーティングシステムに対してカスタマイズするステップであって、このために、前記リソースデータベース内の前記ゲストオペレーティングシステムのためのパーティション記述子によって、前記ゲストオペレーティングシステムが、前記ゲストパーティションに割り当てられていないリソースを入手することが防止されるステップとをさらに含むことを特徴とする請求項５８に記載の方法。
【請求項６０】
前記ゲストオペレーティングシステムが、ｘ８６プロセッサ用にプログラムされている場合に、前記関連付けられているモニタは、トラップを使用して解決しなければならないセンシティブなオペレーティングシステム命令が前記ゲストオペレーティングシステムによって実行されるのを防止するステップを実行することを特徴とする請求項５９に記載の方法。
【請求項６１】
別々のパーティションに関連付けられている複数のモニタの間で情報を共有できるようにするために、他のモニタインスタンスによってアクセスできる共有メモリにアクセスすることができるいくつかのモニタインスタンスを提供するステップをさらに含むことを特徴とする請求項５９に記載の方法。
【請求項６２】
前記システムリソースは、前記ホストコンピュータのそれぞれのゲストパーティションとシステムパーティションの間でトランザクションをやり取りできるようにするメモリチャネルを含み、システムリソースを割り当てる前記ステップは、前記メモリチャネルをそれぞれのパーティションに割り当てるステップを含むことを特徴とする請求項４９に記載の方法。
【請求項６３】
前記ホストコンピュータの物理的なＩ／Ｏハードウェアを１つの入力／出力（Ｉ／Ｏ）パーティション内の１つのＩ／Ｏチャネルサーバのエンドポイントにマップするさらなるステップと、前記Ｉ／Ｏチャネルサーバが、前記Ｉ／Ｏパーティションと前記少なくとも１つのゲストパーティションまたはシステムパーティションとの間のメモリチャネルを介して前記物理的なＩ／Ｏハードウェアを少なくとも１つのゲストパーティションまたは別のシステムパーティションと共有するさらなるステップと、前記リソース管理ソフトウェアが、共有メモリを前記少なくとも１つのゲストパーティションまたはシステムパーティションに、および前記Ｉ／Ｏパーティションに割り当てて、前記メモリチャネルを形成するさらなるステップとを含むことを特徴とする請求項６２に記載の方法。
【請求項６４】
物理的なＩ／Ｏハードウェアにアクセスしたいという、前記少なくとも１つのゲストパーティションまたはシステムパーティションから前記Ｉ／Ｏチャネルサーバへの要求を受け取ると、前記Ｉ／Ｏパーティションは、前記少なくとも１つのゲストパーティションまたはシステムパーティションに関連付けられているパーティション記述子を使用してチェックを行い、前記要求されている物理的なＩ／Ｏハードウェアへのアクセスが有効であるかを確認するステップを実行することを特徴とする請求項６３に記載の方法。
【請求項６５】
前記少なくとも１つのＩ／Ｏパーティションによる前記Ｉ／Ｏパーティション内の前記Ｉ／Ｏチャネルサーバのエンドポイントへの前記ホストコンピュータの前記物理的なＩ／Ｏハードウェアの前記マッピングは、共有されている共通の物理的なＩ／Ｏハードウェアを通じて、それぞれのメモリチャネルによって前記Ｉ／Ｏパーティションに接続されている複数のパーティションから前記共通の物理的なＩ／ＯハードウェアへのあらゆるＩ／Ｏ要求を多重化するステップを含むことを特徴とする請求項６３に記載の方法。
【請求項６６】
前記Ｉ／Ｏパーティションに関連付けられているＩ／Ｏモニタと、前記Ｉ／Ｏパーティションとの間にシステムコールインターフェースを実装するステップと、前記システムコールインターフェースが、クライアントメモリチャネルドライバからそれぞれのメモリチャネルを通じて送信された要求のバッファパラメータとして入手されたクライアントパーティションの相対的なアドレスを、前記共通の物理的なＩ／Ｏハードウェアへのアクセスを要求している前記クライアントパーティションに現在割り当てられているメモリの有効なハードウェアの物理アドレスとして変換および確認するステップとをさらに含むことを特徴とする請求項６５に記載の方法。
【請求項６７】
それぞれのクライアントパーティションが、前記Ｉ／Ｏパーティションのサーバと前記それぞれのクライアントパーティションの間のメッセージをキューに入れるさらなるステップと、前記Ｉ／Ｏパーティションサーバが、前記パーティションの相対的な物理アドレスをキューから外すさらなるステップと、前記パーティションの相対的な物理アドレスを物理的なＩ／Ｏハードウェアアドレスに変換するさらなるステップと、前記Ｉ／Ｏモニタと前記共通の物理的なＩ／Ｏハードウェアとの間に接続されているハードウェアＩ／Ｏアダプタとデータをやり取りするさらなるステップとを含むことを特徴とする請求項６６に記載の方法。
【請求項６８】
前記少なくとも１つのＩ／Ｏパーティションによる前記Ｉ／Ｏパーティション内の前記Ｉ／Ｏチャネルサーバのエンドポイントへの前記ホストコンピュータの前記物理的なＩ／Ｏハードウェアの前記マッピングは、Ｉ／Ｏアクセスを要求しているクライアントパーティションとインテリジェントな物理的なＩ／Ｏハードウェアの間にパフォーマンスの高いメモリチャネルをセットアップするために前記メモリチャネルを介して前記Ｉ／ＯチャネルサーバにＩ／Ｏセットアップ情報を渡すステップと、前記パフォーマンスの高いメモリチャネルを介して、Ｉ／Ｏアクセスを要求している前記クライアントパーティションと前記インテリジェントな物理的なＩ／Ｏハードウェアの間で直接データを送信するステップとを含むことを特徴とする請求項６３に記載の方法。
【請求項６９】
Ｉ／Ｏアクセスを要求している前記クライアントパーティションと前記インテリジェントな物理的なＩ／Ｏハードウェアの間で直接データを送信する前記ステップは、ユーザモードＩ／Ｏとダイレクトメモリアクセスデータ転送オペレーションのうちの１つを実行するステップを含むことを特徴とする請求項６８に記載の方法。
【請求項７０】
システムリソースを割り当てる前記ステップは、前記リソース管理ソフトウェアアプリケーションによるＩＤＴ（Ｉｎｔｅｒｒｕｐｔ  Ｄｅｓｃｒｉｐｔｏｒ  Ｔａｂｌｅ）のコントロールを通じて前記少なくとも１つのホストプロセッサのコントロールを可能にするために仮想プロセッサの特権レベルを制限することによって、前記少なくとも１つのホストプロセッサの処理サイクルを割り当てるステップを含むことを特徴とする請求項４９に記載の方法。
【請求項７１】
前記少なくとも１つのホストプロセッサにタイマの割り込みを提供するステップと、前記タイマの割り込みを使用して、仮想プロセッサコンテキストの切り替えを開始するステップとをさらに含むことを特徴とする請求項７０に記載の方法。
【請求項７２】
倍率として２ｘを使用するスケールの階層と、次に低い階層化されたページサイズレベルのサイズにおいて２ｘのメモリブロックを割り当てるそれぞれの階層化されたページサイズレベルにおける１つのインデックスページとを含む階層化されたページサイズモデルに従って、前記リソースデータベースのメモリ割り当てページマップを編成するステップをさらに含むことを特徴とする請求項４９に記載の方法。
【請求項７３】
望ましいパーティション番号［Ｇ，Ｍ，Ｋ］用のパーティション記述子をメモリ内にＭｅｍ（Ｇ，Ｍ，Ｋ）＝（（Ｇ＊２１０＋Ｍ）＊２１０＋Ｋ）＊２１０＊（ワードサイズ）として保存することによって、前記メモリを前記それぞれのシステムパーティションおよびゲストパーティションに割り当てるステップであって、その場合のワードサイズは２の累乗であるステップをさらに含むことを特徴とする請求項７２に記載の方法。
【請求項７４】
前記保存されたパーティション記述子を、前記パーティション記述子によって定義されている前記パーティションに関連付けられているモニタに提供するステップと、前記モニタが、そのパーティション内のアプリケーションを前記パーティション記述子によって定義されている前記メモリに制限するステップとをさらに含むことを特徴とする請求項７３に記載の方法。
【請求項７５】
ｘ＝１０であり、仮想パーティション番号を、前記メモリ割り当てページマップ内において、前記仮想パーティション用の前記仮想パーティション記述子を前記仮想パーティション番号と同一視する４ｋのページのマップへの３２ビットのインデックス（２，１０，１０，１０）として表すステップであって、その場合の第１のビットは、より小さなページ内における副次割り当てを示し、３つの連続した２１０の値は、拡大縮小されたページを識別するステップをさらに含むことを特徴とする請求項７２に記載の方法。
【請求項７６】
前記少なくとも１つのシステムパーティションは、前記リソースデータベースおよび前記リソース管理ソフトウェアアプリケーションを含むウルトラバイザパーティションと、前記ホストシステムのためのリソース割り当てポリシーを所有するコマンドパーティションとを含む方法であって、前記コマンドパーティションと前記ウルトラバイザパーティションの間のコマンドメモリチャネルを通じて渡されるトランザクションを作成するステップと、前記リソース管理ソフトウェアが、前記トランザクション内で指定されているように前記システムリソースを割り当て直すために前記トランザクションを処理するステップとをさらに含むことを特徴とする請求項４９に記載の方法。
【請求項７７】
システムリソースを割り当てる前記ステップは、構成ポリシーに基づいて前記少なくとも１つのホストコンピュータのそれぞれのパーティションを１つのドメインに割り当てるステップを含むことを特徴とする請求項７６に記載の方法。
【請求項７８】
前記少なくとも１つのホストコンピュータの少なくとも１つのドメインのための仮想パーティションの定義の持続的なデータベースを保持するステップをさらに含むことを特徴とする請求項７７に記載の方法。
【請求項７９】
最初の始動のための、およびホストコンピュータのパーティションの障害またはハードウェアの障害の場合のブートストラップの目的から、前記少なくとも１つのドメインのための前記仮想パーティションの定義のコピーを保存するステップをさらに含むことを特徴とする請求項７８に記載の方法。
【請求項８０】
パーティションがアクティブにされる際に、前記アクティブにされるパーティションのためのリソースを要求している前記少なくとも１つのホストコンピュータのうちの１つのホストコンピュータを選択するステップと、前記ホストコンピュータのコマンドパーティション内で実行されているリソースサービスに接続するステップと、前記アクティブにされるパーティションの定義および開始コマンドを前記リソースサービスに提供するステップとを実行することを特徴とする請求項７８に記載の方法。
【請求項８１】
前記リソースデータベースのコピーを前記コマンドパーティション内に保存するステップと、前記リソースデータベースの前記コピーを使用して、前記アクティブにされるパーティションのための適切なリソースを選択するステップと、前記コマンドメモリチャネルを介して前記リソースデータベースを更新するためのトランザクションを作成するステップとをさらに含むことを特徴とする請求項８０に記載の方法。
【請求項８２】
前記少なくとも１つのホストコンピュータのオペレーションをモニタするステップと、ホストコンピュータの障害を検出した場合には、障害の生じたホストコンピュータに割り当てられている仮想パーティションのための新しいホストコンピュータを選択するステップとをさらに含むことを特徴とする請求項７６に記載の方法。
【請求項８３】
前記少なくとも１つのホストコンピュータのシステムリソースの相互接続されているセットを１つのゾーンに割り当てるステップと、それぞれのパーティションを、前記それぞれのパーティションによって要求されている前記システムリソースを有するゾーンに割り当てるステップであって、その場合に１つのゾーンは、１つのコンピュータネットワーク内の前記少なくとも１つのホストコンピュータのシステムリソースのためのリソースの割り当ての単位であるステップとをさらに含むことを特徴とする請求項７８に記載の方法。
【請求項８４】
前記パーティションを割り当てるステップは、ネットワーク接続を介して、新しいパーティションをホストすることになる１つのホストコンピュータの１つのコマンドパーティションにリソーストランザクションを送信することによって、前記ホストコンピュータに前記新しいパーティションを割り当てるステップを含むことを特徴とする請求項８３に記載の方法。
【請求項８５】
前記ネットワーク接続を介して１つのアクティブなパーティションのメモリコンテンツを第１のホストコンピュータから第２のホストコンピュータ内のアクティブにされるターゲットパーティションへ転送することによって、前記第１のホストコンピュータ上の前記アクティブなパーティションを前記第２のホストコンピュータへ移動するステップをさらに含むことを特徴とする請求項８４に記載の方法。
【請求項８６】
別々の時点において別々のシステムリソーススケジュールに基づいて前記構成ポリシーを変更するステップをさらに含むことを特徴とする請求項７７に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ホストシステムの個別の論理的なまたは仮想のパーティション内に実装されているハイパーバイザを使用して、そのホストシステムのその他の個別の論理的なまたは仮想のパーティション内で実行されている複数のオペレーティングシステムを管理するためのコンピュータシステムの準仮想化（ｐａｒａ−ｖｉｒｔｕａｌｉｚａｔｉｏｎ）に関する。ハイパーバイザは、比較的フェイルセーフな方法での仮想パーティションの多かれ少なかれ自動的なオペレーションを提供するパーティションポリシーおよびリソースサービスを実施する。
【背景技術】
【０００２】
コンピュータシステムの仮想化によって、複数のオペレーティングシステムおよびプロセスは、ホストコンピュータのハードウェアリソースを共有することができる。システムの仮想化は、リソースの分離を提供し、これによってそれぞれのオペレーティングシステムは、自分がリソースを別のオペレーティングシステムと共有していることを自覚することなく、他のオペレーティングシステムの実行に悪影響を及ぼさないことが理想的である。このようなシステムの仮想化によって、サーバの連結（ｃｏｎｓｏｌｉｄａｔｉｏｎ）、同一の場所に配置されたホスティングファシリティ、分散型のウェブサービス、アプリケーションのモビリティ、安全なコンピューティングプラットフォーム、および基礎をなすハードウェアリソースの効率的な利用を提供するその他のアプリケーションを含むアプリケーションが可能となる。
【０００３】
ＶＭＭ（ｖｉｒｔｕａｌ  ｍａｃｈｉｎｅ  ｍｏｎｉｔｏｒ）が、１９７０年代の初期から使用されており、このＶＭＭが提供するソフトウェアアプリケーションは、基礎をなすハードウェア（ｕｎｄｅｒｌｙｉｎｇ  ｈａｒｄｗａｒｅ）を仮想化し、これによって、ＶＭＭ上で実行されているアプリケーションは、基礎をなすハードウェアに実際に「タッチ」することなく、基礎をなすマシンによって提供される同じハードウェア機能に対して公開される。たとえばＩＢＭ／３７０メインフレームコンピュータは、基礎をなすハードウェアのオペレーションをエミュレートした複数の仮想ハードウェアインスタンスを提供し、それらの仮想ハードウェアインスタンスの間におけるコンテキストの切り替え（ｃｏｎｔｅｘｔ  ｓｗｉｔｃｈｅｓ）を提供した。しかしＩＡ−３２またはｘ８６アーキテクチャがより普及してきたため、このようなプラットフォーム上で機能するＶＭＭを開発することが望ましくなった。残念なことに、ＩＢＭ／３７０メインフレームシステムとは異なり、ＩＡ−３２アーキテクチャは、完全な仮想化用には設計されていなかった。これは、正しい仮想化のためには特定のスーパーバイザ命令がＶＭＭによって処理されなければならないが、これらのスーパーバイザ命令を使用すると、適切な割り込み処理技術を使用して処理できるトラップが生成されないために、そうしたスーパーバイザ命令を適切に処理できなかったからである。
【０００４】
近年では、ＶＭＷａｒｅおよびＣｏｎｎｅｃｔｉｘが、ＩＡ−３２アーキテクチャに伴うこれらの問題に対処する比較的洗練された仮想化システムを開発しており、この仮想化システムは、ホストされているマシンのコードの一部を動的に書き直して、ＶＭＭの介入が必要とされる可能性がある場合は常にトラップを挿入し、バイナリ変換を使用して、それらのトラップを解決する。この変換は、ゲストオペレーティングシステムのカーネルの全体に適用される。これは、トラッピングなしのトラップを有さない（ｎｏｎ−ｔｒａｐｐｉｎｇ）特権を有する命令はすべて捕らえて解決しなければならないためである。このようなアプローチは、たとえばＢｕｇｎｉｏｎらによる、Proceedings of the 16th Symposium on Operating Systems Principles (SOSP), Saint-Malo, France, October 1997の"Disco: Running Commodity Operating Systems on Scalable Multiprocessors,"という名称の論文に記載されている。
【０００５】
ＶＭＷａｒｅおよびＣｏｎｎｅｃｔｉｘによってとられる完全な仮想化アプローチは、かなりの処理コストを有する。たとえばＶＭＷａｒｅ  ＥＳＸ  Ｓｅｒｖｅｒは、あらゆる更新の試みをトラップすることによって仮想ページテーブルとの整合性を保持するためにシャドーテーブルを実装するが、これは、新しいアプリケーションプロセスの作成など、更新の多いオペレーションのために高い処理コストを有する。さらにＶＭＷａｒｅシステムは、プールされたＩ／Ｏを使用し、ＰＣＩカードのあるパーティションへの予約を可能にするが、このようなシステムは、信頼性のために、およびパフォーマンスの改善のために、共有されたＩ／Ｏをハイパーバイザから掲げる目的でＩ／Ｏパーティションを作成しない。
【０００６】
完全な仮想化の欠点は、基礎をなすハードウェアのオペレーションのほとんどを仮想化するが、すべてを仮想化するわけではないＶＭＭを提供することによって、回避することができる。このアプローチは、ワシントン大学のＷｈｉｔａｋｅｒらによって「準仮想化」と呼ばれている。完全な仮想化とは異なり、準仮想化のアプローチは、ホストされるゲストオペレーティングシステムに対する修正を必要とする。しかし以降の詳細な説明から理解できるように、準仮想化は、ＡＢＩ（ａｐｐｌｉｃａｔｉｏｎ  ｂｉｎａｒｙ  ｉｎｔｅｒｆａｃｅ）に対する変更を必要とせず、これによって、ゲストアプリケーションに対しては修正をまったく必要としない。Ｗｈｉｔａｋｅｒらは、このような「準仮想化」のシステムを、Ｄｅｎａｌｉと呼ばれるスケーラブルな分離カーネルとして開発した。Ｄｅｎａｌｉは、大多数のバーチャルマシンが小規模なポピュラーではないネットワークサービスであると仮定することによって、ネットワークサービスを実行している数千のバーチャルマシンをサポートするように設計されている。Ｄｅｎａｌｉは、たとえＮｅｔＢＳＤ、Ｌｉｎｕｘ、およびＷｉｎｄｏｗｓ（登録商標）ＸＰのＡＢＩ内でｘ８６セグメンテーションが使用されていても、ｘ８６セグメンテーションを完全にはサポートしない。さらにＤｅｎａｌｉシステム内のそれぞれのバーチャルマシンは、シングルユーザかつシングルアプリケーションの保護されていないオペレーティングシステムをホストする。これは、数千の修正されていないユーザレベルのアプリケーションプロセスを順に実行しうる現実の安全なオペレーティングシステムをホストすることとは対照的である。またＤｅｎａｌｉアーキテクチャにおいては、ＶＭＭは、すべてのオペレーティングシステムに関するディスクへのおよびディスクからのすべてのページングを実行し、これによって、それぞれのホストされている「オペレーティングシステム」ごとのパフォーマンスの分離に悪影響を与える。最後に、Ｄｅｎａｌｉアーキテクチャにおいては、バーチャルマシンにはハードウェアアドレスの知識がまったくなく、このため、どのバーチャルマシンも、別のバーチャルマシンのリソースにアクセスすることができない。結果として、Ｄｅｎａｌｉのために、バーチャルマシンは、物理的なリソースに直接アクセスすることができない。
【発明の開示】
【発明が解決しようとする課題】
【０００７】
ＶＭＷａｒｅおよびＣｏｎｎｅｃｔｉｘの完全な仮想化システム、ならびにＷｈｉｔａｋｅｒらのＤｅｎａｌｉアーキテクチャには、別の共通する著しい制約もある。それぞれのシステムは、基礎をなすハードウェア上に直接１つのＶＭＭをロードし、すべてのゲストオペレーティングシステムは、そのＶＭＭ「の上で」実行されるため、そのＶＭＭが、すべてのゲストオペレーティングシステムにとっての単一障害点となる。したがって、サーバを連結するように実装されている場合には、たとえばＶＭＭの障害が、そのＶＭＭ上でホストされているすべてのゲストオペレーティングシステムの障害を引き起こす可能性がある。ゲストオペレーティングシステムが、同じノード上で共存することができ、基礎をなすハードウェアに対して特定のアプリケーションバイナリインターフェースを義務付けることがなく、またそのノードにとっての単一障害点をもたらすことのない仮想化システムを提供することが望ましい。さらに、仮想化要素および／または基礎をなすハードウェアの障害によってノード全体が停止することのないようにフェイルオーバ（ｆａｉｌ  ｏｖｅｒ）な保護を備えた仮想化システムを提供することが望ましい。改善されたシステムの柔軟性を提供し、これによってシステムが拡張可能（ｓｃａｌａｂｌｅ）となり、システムユーザは、希望のシステムリソースを指定することができ、そうしたシステムリソースを、仮想化システムが、１つのデータセンタ内の利用可能なすべてのリソースにわたって効率よく割り当てることができれば、さらに望ましい。本発明は、当分野の現況におけるこれらの制約に対処するものである。
【課題を解決するための手段】
【０００８】
本発明は、仮想化インフラストラクチャを提供することによって当技術分野における上述の制約に対処するものであり、この仮想化インフラストラクチャによって、複数のゲストパーティションを１つのホストハードウェアパーティション内で実行することができるようになる。ホストシステムは、個別の論理的なまたは仮想のパーティションへと分割され、特別なインフラストラクチャパーティションが実装されて、リソース管理をコントロールし、また物理的なＩ／Ｏデバイスドライバをコントロールし、そしてそれらの物理的なＩ／Ｏデバイスドライバが、他の個別の論理的なまたは仮想のゲストパーティション内のオペレーティングシステムによって使用される。ホストハードウェアのリソース管理は、リソース管理「ウルトラバイザ」パーティション内のトラッキングアプリケーションとして実行され、その一方でホストリソース管理の決定は、「オペレーションズ」パーティション内に保持されているポリシーに基づいて、より高いレベルの「コマンド」パーティション内で実行される。この分散型のリソース管理の手法は、システム障害の際には、ポリシー管理のそれぞれの側面の修復を独立して提供する。またウルトラバイザパーティション内には、システムリソース管理機能が実装されているため、それぞれのパーティションごとの従来のハイパーバイザおよびコンテインメントエレメント（モニタ）の役割は、複雑さおよび範囲が減縮される。
【０００９】
模範的な一実施形態においては、ウルトラバイザパーティションは、ハードウェアリソースの割り当てのマスターインメモリデータベースを保持する。この低いレベルのリソースマネージャは、リソースをパーティションへ割り当てるよう求めるトランザクション要求を受け入れるためのコマンドチャネルを供給する。これはまた、個々のパーティションの個々の読み取り専用ビューを、関連付けられているパーティションモニタに提供する。同様に、ホストハードウェアのＩ／Ｏ管理は、特別な冗長Ｉ／Ｏパーティション内に実装される。その他の論理的なまたは仮想のパーティション内におけるオペレーティングシステムは、ウルトラバイザパーティションによって確立されたメモリチャネルを介して、それらのＩ／Ｏパーティションとやり取りする。
【００１０】
本発明によれば、それぞれの論理的なまたは仮想のパーティション内のゲストオペレーティングシステムは、システムコールインターフェースを実装するモニタにアクセスするように修正され、このシステムコールインターフェースを通じて、ウルトラバイザパーティション、Ｉ／Ｏパーティション、およびその他のすべての特別なインフラストラクチャパーティションは、相互に、およびそれぞれのゲストパーティションと、やり取りを開始することができる。さらにゲストオペレーティングシステムは、完全な仮想化システムはトラップを挿入することによって解決しなければならないというｘ８６システム内の「壊れた」命令を使用することを試みないように修正される。これは、比較的少ない行のオペレーティングシステムコードの修正を必要とするが、その一方で、「壊れた」命令を介してカーネル内へと不正に侵入するための多くの機会を排除することによって、システムのセキュリティを著しく高める。
【００１１】
好ましい一実施形態においては、スケーラブルなパーティションメモリマッピングシステムがウルトラバイザパーティション内に実装され、それによって、仮想化されているシステムを実質的に無限の数のページへと拡張することができる。ｌｏｇ（２１０）ベースの割り当てによって、メモリの割り当てを管理するオーバーヘッドが増加させることなく、仮想パーティションメモリのサイズを複数の世代にわたって増大することができる。メモリのそれぞれのページは、ページ階層内の１つのパーティション記述子に割り当てられ、ウルトラバイザパーティションによって管理される。
【００１２】
好ましい実施形態においては、Ｉ／Ｏサーバパーティションは、物理的なホストハードウェアをＩ／Ｏチャネルサーバエンドポイントにマップし、ここではＩ／Ｏチャネルサーバは、Ｉ／Ｏハードウェアリソースの共有を担当する。内部のＩ／Ｏ構成においては、このマッピングは、共有されている共通のＩ／Ｏハードウェアを通じて複数のパーティションのチャネルからの要求を多重化することによって、ソフトウェア内で行われる。パーティションの相対的な物理アドレスは、モニタによって実装されているシステムコールインターフェースから仮想チャネルドライバによって得られ、ウルトラバイザパーティションによってコントロールされている共有メモリによって実装されている通信チャネルを通じて渡される。メッセージは、クライアントパーティションによってキューに入れられ、割り当てられているＩ／Ｏサーバパーティションによってキューから出される。要求されたＩ／Ｏサーバパーティションは、次いでＩ／Ｏパーティションモニタの助けを借りてパーティションの相対的な物理アドレスを物理的なハードウェアアドレスに変換し、ハードウェアＩ／Ｏアダプタとデータをやり取りする。Ｉ／Ｏパーティションモニタはまた、ウルトラバイザパーティションのパーティション（リード（ｌｅａｄ））モニタ、および／または必要に応じてゲストパーティションのモニタのサービスを呼び出すことができる。コマンド要求完了／失敗ステータスは、サーバパーティションによってキューに入れられ、クライアントパーティションによってキューから出される。その一方で、外部のＩ／Ｏ構成においては、セットアップ情報は、通信チャネルを介してインテリジェントＩ／Ｏハードウェアに渡され、このインテリジェントＩ／Ｏハードウェアによって、ゲストパーティションは、「ユーザモードＩ／Ｏ」またはＤＭＡ（ｄｉｒｅｃｔ  ｍｅｍｏｒｙ  ａｃｃｅｓｓ）手法を使用することによって、Ｉ／Ｏの意味部分（ｓｉｇｎｉｆｉｃａｔｉｏｎ  ｐｏｒｔｉｏｎ）を、場合によってはコンテキストの切り替えをまったく伴わずに、直接実行することができる。
【００１３】
本発明のウルトラバイザパーティションの設計によって、それぞれのホストハードウェアパーティション（別々のハードウェアリソース）上で動作している仮想化システムは、特別なインフラストラクチャパーティションを介して相互にやり取りすることがさらに可能となり、これによって、システムリソースを複数のホストノードにわたってさらに割り当てて共有することができる。したがって本発明の仮想化の設計によって、仮想データセンタの開発が可能となり、この仮想データセンタにおいては、ユーザは、自分のハードウェア／ソフトウェアリソース要件を指定することができ、仮想データセンタは、要求されたハードウェア／ソフトウェアリソースを最適に効率的な方法で複数のホストハードウェアパーティションにわたって割り当てて管理することができる。さらに、少数のオペレーションズパーティションを使用して、それぞれのノードのコマンドパーティション内の関連付けられているパーティションリソースサービスを通じて多数のホストノードを管理することができ、かつこれをフェイルオーバな方法で行うことができ、このフェイルオーバな方法によれば、１つのオペレーションズパーティションまたはリソースの障害が生じると、その障害の原因を特定して訂正できるまで、別の機能しているパーティションへ自動的にコンテキストが切り替わる。同様に、それぞれのノード上のそれぞれのコマンドパーティションシステムは、そのノードの１つまたは複数のプロセッサの障害の際には、同じマルチプロセッサノード上の別々のウルトラバイザリソースのリソースデータベースリストにリソースを自動的に割り当て直すことができる一方で、仮想データセンタの実装におけるコントローリングオペレーションズパーティションは、ノードの障害の際には、複数のノードにわたってリソースをさらに自動的に割り当て直すことができる。
【００１４】
本発明の仮想化の設計は、システム内のあらゆる場所におけるハードウェアまたはソフトウェアの障害の影響を最小限に抑え、その一方で、特定の環境においてハードウェアに「タッチ」できるようにすることによってパフォーマンスを改善することもできるということを当業者なら理解されよう。本発明のシステムのこれらおよびその他のパフォーマンスの側面については、当業者なら本発明についての以下の詳細な説明から理解されよう。
【００１５】
本発明による準仮想化システムについては、添付の図面を参照して以降でさらに説明する。
【発明を実施するための最良の形態】
【００１６】
次いで本発明の例示的な実施形態の詳細な説明を、図１〜１５を参照して説明する。この説明は、本発明の可能な実装形態の詳細な例を提供するが、これらの詳細は、例示を目的とするものであり、けっして本発明の範囲を画定するものではないことに留意されたい。
【００１７】
定義、頭字語、および略語：
３Ｄ−ＶＥ−Ｔｈｒｅｅ−Ｄｉｍｅｎｓｉｏｎａｌ  Ｖｉｓｉｂｌｅ  Ｅｎｔｅｒｐｒｉｓｅ。戦略、ビジネスプロセス、アプリケーション、およびインフラストラクチャを含むデータセンタの４層のモデル。
【００１８】
ＡＣＰＩ−Ａｄｖａｎｃｅｄ  Ｃｏｎｆｉｇｕｒａｔｉｏｎ  ａｎｄ  Ｐｏｗｅｒ  Ｉｎｔｅｒｆａｃｅ
ＡＤＳ−Ａｕｔｏｍａｔｅｄ  Ｄｅｐｌｏｙｍｅｎｔ  Ｓｙｓｔｅｍ。サーバハードウェアの「ゼロタッチ」プロビジョニングを提供するように設計されている。もちろん、これは、仮想サーバハードウェアを提供することもできる。詳細については、http://www.microsoft.com/windowsserver2003/technologies/management/ads/default. mspxを参照されたい。
【００１９】
ＡＴＡ−ＡＴ  Ａｔｔａｃｈｍｅｎｔ（低価格ディスク用）
ＣＭＰ−Ｃｅｌｌｕｌａｒ  Ｍｕｌｔｉ−Ｐｒｏｃｅｓｓｉｎｇ
ＤＭＺ−Ｄｅ−Ｍｉｌｉｔａｒｉｚｅｄ  Ｚｏｎｅ。インターネットとイントラネットの間の典型的な周辺ゾーンである。詳細については、http://www.webopedia.com/TERM/D/DMZ. htmlを参照されたい。
【００２０】
ＤＮＳ−Ｄｏｍａｉｎ  Ｎａｍｅ  Ｓｙｓｔｅｍ（ホスト名をネットワークアドレスにマップするためのＴＣＰメカニズム）
ＤＳＩ−Ｄｙｎａｍｉｃ  Ｓｙｓｔｅｍｓ  Ｉｎｉｔｉａｔｉｖｅ。詳細については、http://www.microsoft.com/windowsserversystem/dsi/dsiwp.mspxを参照されたい。
【００２１】
ＥＦＩ−Ｅｘｔｅｎｓｉｂｌｅ  Ｆｉｒｍｗａｒｅ  Ｉｎｔｅｒｆａｃｅ。ＥＦＩの仕様は、オペレーティングシステムとプラットフォームファームウェアの間のインターフェースのための新しいモデルを定義する。詳細については、http://www.intel.com/technology/efiおよびhttp://www.intel.com/technology/framework/を参照されたい。
【００２２】
ＥＭ３２Ｔ−６４ビットの拡張されたｘ８６アーキテクチャのＩｎｔｅｌの実装。
【００２３】
ＨＢＡ−Ｈｏｓｔ  Ｂｕｓ  Ａｄａｐｔｅｒ（ディスクストレージアダプタカード）。
【００２４】
ハイパーバイザ−ホストオペレーティングシステムではなく低いレベルのコンテキストの切り替えに依存するホストコンピュータハードウェアを共有するためのメカニズム。
【００２５】
ＩＰＳＥＣ−Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ  Ｓｅｃｕｒｉｔｙ（ＩＰネットワーク用のセキュリティ標準）
ｉＳＣＳＩ−Ｉｎｔｅｒｎｅｔ  ＳＣＳＩ  ｐｒｏｔｏｃｏｌ
ＪＢＯＤ−Ｊｕｓｔ  ａ  Ｂｕｎｃｈ  ｏｆ  Ｄｉｓｋｓ
ＭＳＣＳ−Ｍｉｃｒｏｓｏｆｔ  Ｃｌｕｓｔｅｒ  Ｓｅｒｖｉｃｅｓ
ＮＩＣ−Ｎｅｔｗｏｒｋ  Ｉｎｔｅｒｆａｃｅ  Ｃａｒｄ
ＰＡＥ−Ｐｈｙｓｉｃａｌ  Ａｄｄｒｅｓｓ  Ｅｘｔｅｎｓｉｏｎｓ（主として３２ビットを上回る物理アドレスを提供するＩｎｔｅｌプロセッサのモード）
ＰＣＩ−Ｐｅｒｉｐｈｅｒａｌ  Ｃｏｍｐｏｎｅｎｔ  Ｉｎｔｅｒｃｏｎｎｅｃｔの略語であり、Ｉｎｔｅｌ  Ｃｏｒｐｏｒａｔｉｏｎによって開発されたローカルバス標準である。詳細については、http://www.webopedia.com/TERM/P/PCI.htmlおよびhttp://www.pcisig.com/homeを参照されたい。
【００２６】
ＰＤＥ−Ｐａｇｅ  Ｄｉｒｅｃｔｏｒｙ  Ｅｎｔｒｙ（ＰＴＥ（ｐａｇｅ  ｔａｂｌｅ  ｅｎｔｒｉｅｓ）の配列を包含するページテーブルの物理ページアドレスを提供する）
ＲＤＭＡ−Ｒｅｍｏｔｅ  Ｄｉｒｅｃｔ  Ｍｅｍｏｒｙ  Ａｃｃｅｓｓ。興味深い開発および関連する標準については、http://www.rdmaconsortium.org/homeに記載されている。
【００２７】
ＳＡＮ−Ｓｔｏｒａｇｅ  Ａｒｅａ  Ｎｅｔｗｏｒｋ
ＳＤＭ−Ｓｙｓｔｅｍ  Ｄｅｆｉｎｉｔｉｏｎ  Ｍｏｄｅｌ。ＳＤＭは、分散システムの定義を作成するために使用される（ＤＳＩの）モデルである。詳細については、http://www.microsoft.com/windowsserversystem/dsi/sdm.mspxを参照されたい。
【００２８】
ＳＳＬ−Ｓｅｃｕｒｅ  Ｓｏｃｋｅｔｓ  Ｌａｙｅｒ
ＶＣＰＵ−Ｖｉｒｔｕａｌ  ＣＰＵ
仮想データセンタ−仮想サーバを連結したもの。
【００２９】
ＶＰＮ−Ｖｉｒｔｕａｌ  Ｐｒｉｖａｔｅ  Ｎｅｔｗｏｒｋ
ＶＴ−Ｖａｎｄｅｒｐｏｏｌ  Ｔｅｃｈｎｏｌｏｇｙ。主要なＩｎｔｅｌプロセッサテクノロジーであり、最近のＩｎｔｅｌ  Ｄｅｖｅｌｏｐｅｒｓ  Ｆｏｒｕｍｓに簡単に記載されている。詳細については、http://www.intel.com/pressroom/archive/releases/20030916corp.htmおよびhttp://www.xbitlabs.com/news/cpu/display/20030918034113.htmlを参照されたい。
【００３０】
システムの概要
本発明は、複数のゲストパーティションを１つのホストハードウェアパーティション内で実行できるようにする仮想化インフラストラクチャを提供する。このアーキテクチャは、最小特権の原則を使用して、実状に即した最低限の特権でコードを実行する。これを行うために、特別なインフラストラクチャパーティションが、リソース管理および物理的なＩ／Ｏデバイスドライバを実行する。図１は、左側にシステムインフラストラクチャパーティションを、そして右側にユーザゲストパーティションを示している。ホストハードウェアのリソース管理は、特別なウルトラバイザパーティション内の１つのウルトラバイザアプリケーションとして実行される。このウルトラバイザアプリケーションは、リソースをパーティションに割り当てるよう求めるトランザクション要求を受け入れるためのコマンドチャネル用のサーバを実装する。ウルトラバイザアプリケーションは、ハードウェアリソースの割り当てのマスターインメモリデータベース（ｍａｓｔｅｒ  ｉｎ−ｍｅｍｏｒｙ  ｄａｔａｂａｓｅ）を保持する。ウルトラバイザアプリケーションはまた、個々のパーティションの読み取り専用ビューを、関連付けられているパーティションモニタに提供する。
【００３１】
図１においては、パーティションで区切られているホスト（ハードウェア）システム（またはノード）１０は、より低い特権を有するメモリを有しており、このより低い特権を有するメモリは、個別の論理的なまたは仮想のパーティションへと分割され、これらには、ブートパーティション１２、アイドルパーティション１３、ウルトラバイザパーティション１４、第１および第２のＩ／Ｏパーティション１６および１８、コマンドパーティション２０、およびオペレーションズパーティション２２、ならびに仮想ゲストパーティション２４、２６、および２８などの特別なインフラストラクチャパーティションが含まれる。図示されているように、パーティション１２〜２８は、基礎をなす特権を有するメモリおよびプロセッサレジスタ３０には直接アクセスしないが、その代わりにハイパーバイザシステムコールインターフェース３２を介して、この特権を有するメモリおよびプロセッサレジスタ３０にアクセスし、このハイパーバイザシステムコールインターフェース３２は、従来の方法でパーティション１２〜２８間におけるコンテキストの切り替えを提供する。しかし従来のＶＭＭおよびハイパーバイザとは異なり、図１のパーティションで区切られているホストシステム１０のリソース管理機能は、特別なインフラストラクチャパーティション１２〜２２内に実装される。以降でさらに詳しく説明するように、これらの特別なインフラストラクチャパーティション１２〜２２は、リソース管理および物理的なＩ／Ｏデバイスドライバをコントロールし、今度はそれらのリソース管理および物理的なＩ／Ｏデバイスドライバが、仮想ゲストパーティション２４〜２８内でゲストとして動作しているオペレーティングシステムによって使用される。もちろん、その他の多くの仮想ゲストパーティションは、本発明の技術に従って特定のパーティションで区切られているホストシステム１０内に実装することができる。
【００３２】
ブートパーティション１２は、はじめにウルトラバイザパーティション、Ｉ／Ｏパーティション、およびコマンドパーティション（要素１４〜２０）をロードするためのホストブートファームウェアおよび機能を包含する。いったん起動されると、リソース管理「ウルトラバイザ」パーティション１４は、本明細書ではウルトラバイザまたはリソース管理アプリケーションと呼ばれるトラッキングアプリケーションを使用してリソースの使用状況を追跡監視する最小限のファームウェアを含む。ホストリソース管理の決定は、コマンドパーティション２０において実行され、１つまたは複数のホスト、パーティションで区切られている、システム１０内の複数のパーティション間で分散された決定は、オペレーションズパーティション２２によって管理される。ディスクドライブなどへのＩ／Ｏは、フェイルオーバ機能とロードバランシング機能の両方を提供するために、Ｉ／Ｏパーティション１６および１８の一方または双方によってコントロールされる。ゲスト仮想パーティション２４、２６、および２８内のオペレーティングシステムは、ウルトラバイザパーティション１４によって確立されたメモリチャネル（図３）を介して、Ｉ／Ｏパーティション１６および１８とやり取りする。仮想パーティションは、メモリチャネルを介してのみ、やり取りを行う。ハードウェアＩ／Ｏリソースは、Ｉ／Ｏパーティション１６、１８に対してのみ割り当てられる。図１の構成においては、ハイパーバイザシステムコールインターフェース３２は、基本的にそれぞれのパーティションごとに１つのコンテキストの切り替えおよびコンテインメントエレメント（モニタ）まで低減される。
【００３３】
ウルトラバイザパーティション１４のリソースマネージャアプリケーションは、パーティションへのリソースの割り当てを追跡するリソースデータベース３３を管理し、またさらにリソースをそれぞれのパーティションに割り当てるよう求めるトランザクション要求を受け入れるためのコマンドチャネル３８（図３）を供給する。図２に示されているように、ウルトラバイザパーティション１４はまた、パーティション（リード）モニタ３４を含み、このパーティション（リード）モニタ３４は、ウルトラバイザパーティション１４内のリソースデータベースの個々の読み取り専用ビューを、それぞれの仮想パーティションの関連付けられている仮想パーティションモニタ３６に提供することを除いて、ＶＭＭ（ｖｉｒｔｕａｌ  ｍａｃｈｉｎｅ  ｍｏｎｉｔｏｒ）に類似している。したがって従来のＶＭＭとは異なり、それぞれのパーティションは、自分自身のモニタインスタンス３６を有し、これによって、モニタ３６の障害のためにホストのパーティションで区切られているシステム１０の全体が停止することはなくなる。以降で説明するように、それぞれの論理的なまたは仮想のパーティション２４、２６、２８内のゲストオペレーティングシステムは、ハイパーバイザシステムコールインターフェース３２と共に通信メカニズムを実装する関連付けられている仮想パーティションモニタ３６にアクセスするように修正され、この通信メカニズムを通じて、ウルトラバイザパーティション、Ｉ／Ｏパーティション、およびその他のすべての特別なインフラストラクチャパーティション１４〜２２は、相互に、およびそれぞれのゲストパーティションとやり取りを開始することができる。しかしこの機能を実装するためには、仮想ゲストパーティション２４、２６、２８内のゲストオペレーティングシステムは、完全な仮想化システムはトラップを挿入することによって解決しなければならないというｘ８６システム内の「壊れた」命令を使用することを試みないように修正されなければならないということを当業者なら理解されよう。基本的には、おおよそ１７の「センシティブな」ＩＡ３２命令（特権を有さないが、特権レベルに関する情報、またはゲストＯＳによって予想されていたのとは異なる実際のハードウェアの使用状況に関するその他の情報を生み出す命令）が「未定義」と定義され、リングゼロ以外において認識していないＯＳを実行しようと試みれば常に、その試みは失敗することになる可能性が高いが、その他のパーティションを危うくすることはない。このような「準仮想化」は、比較的少ない行のオペレーティングシステムコードの修正を必要とするが、その一方で、「壊れた」（「センシティブな」）命令を介してカーネル内へと不正に侵入するための多くの機会を排除することによって、システムのセキュリティを著しく高める。仮想パーティションモニタ３６は、代わりに「スキャンおよび修正」のオペレーションを実施することができ、それによってランタイムの介入を使用してセンシティブな命令を見つけ適切な介入を挿入することによって、実際の値ではなくエミュレートされた値を提供することを当業者なら理解されよう。
【００３４】
それぞれのパーティション内の仮想パーティションモニタ３６は、ゲストＯＳおよびそのアプリケーションを、割り当てられたリソースに制限する。それぞれのモニタ３６は、システムコールインターフェース３２を実装し、このシステムコールインターフェース３２は、そのパーティションのゲストＯＳによって、割り当てられたリソースの使用状況を要求するために使用される。システムコールインターフェース３２は、保護例外を含み、この保護例外は、ゲストＯＳが、特権を有するプロセッサオペコードを使用することを試みる場合に発生する。別々のパーティションは、別々のモニタ３６を使用することができる。これによって、複数のシステムコールインターフェース３２のサポート、およびこれらの標準用のサポートは、時間の経過と共に発展することができる。これによって、別々のパーティション内のモニタコンポーネントを独立してアップグレードすることもできる。
【００３５】
モニタ３６は、プロセッサの性能を認識していることが好ましく、それによって、モニタ３６を最適化して、任意の利用可能なプロセッサ仮想化サポートを活用することができる。適切なモニタ３６およびプロセッササポートによって、ゲストパーティション（たとえば２４〜２８）内のゲストＯＳは、本発明のウルトラバイザシステムを認識している必要はなく、モニタ３６に対して何らかの明示的な「システム」コールを行う必要はない。この場合、プロセッサ仮想化の割り込みは、必要かつ十分なシステムコールインターフェース３２を提供する。しかしパフォーマンスを最適化するためには、ゲストＯＳからモニタシステムコールインターフェース３２への明示的なコールが、依然として望ましい。
【００３６】
ウルトラバイザパーティション１４用のモニタ３４は、２つの特別な役割を有する「リード（ｌｅａｄ）」モニタである。これは、モニタインスタンス３６の作成および破棄を行う。これはまた、作成されたモニタ３６に対して、プロセッサコンテキストの切り替えを補助するためのサービスを提供する。プロセッサコンテキストの切り替え中に、モニタ３４、３６は、仮想プロセッサ構造にゲストパーティションの状態を保存し、特権状態を仮想プロセッサ構造（たとえばＩＤＴＲ、ＧＤＴＲ、ＬＤＴＲ、ＣＲ３）に保存して、ウルトラバイザモニタ切り替えサービスを呼び出す。このサービスは、ターゲットパーティションモニタの特権状態（たとえばＩＤＴＲ、ＧＤＴＲ、ＬＤＴＲ、ＣＲ３）をロードし、ターゲットパーティションモニタに切り替え、そしてこのターゲットパーティションモニタが、ゲストパーティションの状態の残りを復元する。
【００３７】
モニタ３６はまた、自分がモニタするパーティションに割り当てられているリソースのマップを保持し、そのパーティション内のゲストＯＳ（およびアプリケーション）が、必ず、割り当てられているハードウェアリソースのみを使用するようにする。モニタ３６は、そのプロセッサの最も高い特権を有するレベルにおいてそのパーティション内で実行されている第１のコードであるため、これを行うことができる。モニタ３６は、より低い特権においてパーティションファームウェアをブートする。このファームウェアは、次いでＯＳおよびアプリケーションをブートする。通常のプロセッサ保護メカニズムは、ファームウェア、ＯＳ、およびアプリケーションが、そのプロセッサの最も高い特権を有する保護レベルを得ることがけっしてないようにする。
【００３８】
従来のＶＭＭとは異なり、モニタ３６には、Ｉ／Ｏインターフェースがまったくない。すべてのＩ／Ｏは、Ｉ／Ｏパーティション１６、１８にマップされているＩ／Ｏハードウェアによって実行され、これらのＩ／Ｏパーティション１６、１８は、メモリチャネルを使用して、それらのクライアントパーティションとやり取りする。モニタ３６の主要な役割は、代わりにプロセッサが備えるリソース（たとえば、プロセッサの特権機能およびメモリ管理ユニット）を保護することである。モニタ３６はまた、主として、メモリにマップされたＩ／Ｏの保護を通じて、Ｉ／Ｏハードウェアへのアクセスを保護する。モニタ３６は、ゲストパーティションの間におけるＩ／Ｏ機能のための基盤であるチャネルエンドポイント機能をさらに提供する。
【００３９】
最も高い特権を有するプロセッサレベル（すなわちｘ８６のリング０）は、モニタインスタンス３４、３６がシステムコールインターフェース３２の下で実行されているようにすることによって保持される。これは、プロセッサが、ゲストＯＳおよびアプリケーションにとって利用可能な少なくとも３つの別個の保護レベル、たとえばｘ８６リング１、２、および３を実装する場合に、最も効果的である。ウルトラバイザパーティション１４は、それぞれのパーティションのベース（最も高い特権を有するレベル）において、モニタ３４、３６に接続される。モニタ３４は、ウルトラバイザパーティション１４内のパーティション記述子への読み取り専用アクセスを自分自身に認め、ウルトラバイザパーティション１４は、リソースデータベース３３内に保存されているモニタ状態（ｍｏｎｉｔｏｒ  ｓｔａｔｅ）の１つのページへの読み取り専用アクセスを有する。
【００４０】
本発明のモニタ３４、３６は、パーティションをその割り当てられたリソースに制限するという点、必要に応じて特権を有する動作をエミュレートする保護例外を割り込みハンドラが提供するという点、および「認識している」包含されているシステムコード用にシステムコールインターフェースが実装されるという点において、従来のＶＭＭに類似しているということを当業者なら理解されよう。しかし本発明のモニタ３４、３６は、復元を可能にするために仮想（ウルトラバイザ）パーティション内にマスターリソースデータベース３３が包含されるという点、リソースデータベース３３が単純なトランザクションメカニズムを実装するという点、および連携するモニタ３４、３６の集合から仮想化されたシステムが構築され、それによって、１つのモニタ３４、３６内における障害のためにすべての仮想パーティションが運命付けられる必要がなくなる（漏れ出す包含障害（ｃｏｎｔａｉｎｍｅｎｔ  ｆａｉｌｕｒｅ）の場合にのみ、運命付けられることになる）という点において、従来のＶＭＭとは異なる。本発明のモニタ３４、３６はまた、それぞれのパーティションがその割り当てられたモニタによって包含されるという点、より単純な包含要件を有するパーティションが、より単純な、したがってより信頼できる（そしてよりセキュリティの高い）モニタの実装形態を使用できるという点、および別々のパーティション用のモニタの実装形態を、必須ではないが共有できるという点においても、従来のＶＭＭとは異なる。また従来のＶＭＭとは異なり、リードモニタ３４は、他のモニタ３６によるウルトラバイザパーティションリソースデータベース３３へのアクセスを提供する。
【００４１】
Ｉ．ウルトラバイザ準仮想化システム
ウルトラバイザ環境内のパーティションは、ホストノード１０によって編成された利用可能なリソースを含む。ユーザの観点からは、ウルトラバイザ環境内のパーティションの大多数は、実際には仮想パーティションである。仮想パーティションは、ハードウェアシステムプラットフォーム（またはハードウェアパーティション）を独立した動作環境へと「パーティションで区切る」ことを可能にするソフトウェア構成である（これは部分的にハードウェアで補助することもできる）。ハードウェアによる補助の度合いは、プラットフォームによるが、もちろん１００％未満である（当然ながら、１００％ハードウェアによる補助は、ハードウェアパーティションを提供することになるので）。ハードウェアによる補助は、プロセッサまたはその他のプラットフォームハードウェアの機能によって提供することができる。ウルトラバイザパーティション１４の観点からは、ハードウェアパーティションは一般的に、ハードウェアをパーティションで区切っていない市販のハードウェアプラットフォームと区別がつかない。
【００４２】
本出願を通じて、仮想パーティションは、パーティションへのあらゆる制限のない参照のために想定されるべきである。仮想パーティションに関連する（そして一般的には仮想パーティションと同義の）その他の用語としては、仮想サーバ、ＶＭ（ｖｉｒｔｕａｌ  ｍａｃｈｉｎｅ）、仮想世界、および仮想ゲストＯＳが含まれる。
【００４３】
ウルトラバイザ対応型のホストシステム１０内におけるメモリのそれぞれのページは、その仮想パーティションのうちの厳密に１つによって所有されている。ホストシステム１０内の（１つまたは複数の）プロセッサは、複数の仮想プロセッサの間におけるハイパーバイザシステムコールインターフェース３２による頻繁なコンテキストの切り替えによって、仮想パーティションのうちのいくつかの間において時分割方式とすることができる。各ハードウェアＩ／Ｏデバイスは、指定されたＩ／Ｏ仮想パーティション１６、１８のうちの厳密に１つにマップされる。これらのＩ／Ｏパーティション１６、１８（通常は冗長性のために２つ）は、特別なソフトウェアを実行し、この特別なソフトウェアによって、Ｉ／Ｏパーティション１６、１８は、Ｉ／Ｏハードウェアを共有するためのＩ／Ｏチャネルサーバアプリケーションを実行することができる。このようなチャネルサーバアプリケーションは、（ネットワークチャネル用のチャネルサーバエンドポイントを提供する）Ｖｉｒｔｕａｌ  Ｅｔｈｅｒｎｅｔ（登録商標）の切り替え、および（ストレージチャネル用のチャネルサーバエンドポイントを提供する）仮想ストレージの切り替えを含む。使用されていないメモリおよびＩ／Ｏリソースは、特別な「利用可能（Ａｖａｉｌａｂｌｅ）」な疑似パーティション（図示せず）によって所有される。ホストシステム１０のノードごとの１つのこのような「利用可能」な疑似パーティションは、割り当て用に利用可能なすべてのリソースを所有する。
【００４４】
使用されていないプロセッサは、特別な「アイドル（Ｉｄｌｅ）」パーティション１３に割り当てられる。アイドルパーティション１３は、プロセッサのリソースに割り当てられる最も単純な仮想パーティションである。これは、それぞれの利用可能な物理的なプロセッサごとに仮想プロセッサを含み、それぞれの仮想プロセッサは、プロセッサのパワーの使用を最小限に抑えるための適切なプロセッサ命令を含むアイドルループを実行する。アイドル仮想プロセッサは、次のウルトラバイザタイムクオンタム割り込みにおいて時間を譲ることができ、アイドルパーティション１３のモニタ３６は、プロセッサコンテキストを別のパーティション内の仮想プロセッサに切り替えることができる。ホストのブートストラップ中には、ブートパーティション１２のブートプロセッサは、その他のプロセッサをすべてアイドルパーティション１３内へとブートする。
【００４５】
複数のウルトラバイザパーティション１４はまた、単一障害点を回避するための大型のホストパーティション用とすることもできる。それぞれは、ホストシステム１０の適切な部分のリソースを担当することになる。リソースサービスの割り当ては、ホストシステム１０のそれぞれの部分においてパーティションで区切られることになる。これによってクラスタは、ホストシステム１０内で（それぞれのゾーンにおいて１つのクラスタノードを）実行することができ、依然としてウルトラバイザパーティション１４の障害を切り抜ける。
【００４６】
仮想パーティション内のソフトウェアは、通常はゲストＯＳにとって物理アドレスに見えるものを使用することによって機能する。動作環境にとって可能である場合には、パーティションの物理アドレスは、実際のハードウェアの物理アドレスである。実装形態または構成によって４ＧＢに制限されているゲストＯＳの場合のように、これが可能ではない場合、ウルトラバイザパーティション１４は、ハードウェアの物理アドレスの適切な追加の必要なビットを提供することによって、パーティションの物理アドレスを適切なハードウェアの物理アドレスにマップする。最大で４ＧＢのメモリを有するパーティションの場合、モニタ３６は、割り当てられた物理メモリを、１つの８Ｋページマップ（２つの連続したＰＡＥ  ＰＤテーブル）を使用して記述することができる。ただし、３２ビットのパーティションの相対物理アドレスの上位１０ビットが、マップ内の１０２４エントリにインデックスを付ける。各マップエントリは、６４ビットの（ＰＡＥ）ＰＤエントリを備える。慣例によって、ハードウェアの物理アドレスのビット２３〜３２は、インデックスの最下位ビット（ｌｅａｓｔ  ｓｉｇｎｉｆｉｃａｎｔ  ｂｉｔｓ）にマッチさせることができる。
【００４７】
仮想プロセッサの定義は、完全に仮想のものとすることができ、あるいは実在している物理的なプロセッサをエミュレートすることもできる。これらのうちのどちらにするかは、Ｉｎｔｅｌ  ＶＴ（Ｖａｎｄｅｒｐｏｏｌ  Ｔｅｃｈｎｏｌｏｇｙ）が実装されているかどうかによる。ＶＴは、仮想パーティションソフトウェアが実際のハードウェアのプロセッサのタイプを見ることを可能とすることができ、あるいは実装の選択をその他の形で制限することもできる。本発明は、ＶＴを伴って、あるいは伴わずに実装することができる。
【００４８】
ウルトラバイザパーティション１４は、サーバの入力／出力要件に注意を向ける。レガシーな／従来の／クライアントＰＣハードウェアを十分にエミュレートしようとする試みはほとんど、あるいはまったくなされない。プラグ＆プレイのオペレーティングシステムは、ブートタイムドライバとしてインストールされた適切な仮想のポート／ミニポートドライバと共に機能する。主要なドライバのタイプは、下記のとおりである。
・（Ｖｉｒｔｕａｌ  Ｃｈｉｐｓｅｔ）
・Ｖｉｒｔｕａｌ  Ｔｉｍｅｒｓ（ＲＴＣ）
・Ｖｉｒｔｕａｌ  Ｓｔｏｒａｇｅ（ＨＢＡ）
・Ｖｉｒｔｕａｌ  Ｎｅｔｗｏｒｋ（ＮＩＣ）
・Ｖｉｒｔｕａｌ  Ｃｏｎｓｏｌｅ（手動のプロビジョニング用の任意選択のＫＶＭ）
【００４９】
ハイパーバイザシステムコールインターフェース３２は、仮想ファームウェア用の基盤として使用される現代的な保守可能なファームウェア環境を提供するためのＥＦＩ（Ｅｘｔｅｎｓｉｂｌｅ  Ｆｉｒｍｗａｒｅ  Ｉｎｔｅｒｆａｃｅ）を含むことができる。このファームウェアは、仮想ＡＣＰＩテーブルにアクセスするための標準的なメカニズムを提供する。これらのテーブルによって、オペレーティングシステムは、仮想ハードウェアを見つけ出して対話するための標準的なメカニズムを使用することができるようになる。
【００５０】
仮想ブートファームウェア１２は、ＥＦＩローダを備えていないオペレーティングシステムのブートを可能にすることが必要な場合には、特定のＢＩＯＳ互換ドライバを提供することができる。仮想ブートファームウェア１２はまた、これらのオペレーティングシステム用の限られたサポートを提供することもできる。
【００５１】
別のパーティションは、別々のファームウェアの実装形態、あるいは別のファームウェアのバージョンを使用することができる。パーティションポリシーによって識別されたファームウェアは、パーティションがアクティブにされるときにロードされる。ウルトラバイザのアップグレード中には、実行中のパーティションは、引き続きロードされたファームウェアを使用し、次にそのパーティションが再びアクティブにされるときに、有効なパーティションポリシーによる新しいバージョンに切り替えることができる。
【００５２】
上述のように、仮想パーティションモニタ３６は、他の仮想パーティションからの分離の実施を提供する。モニタ３６は、最も高い特権を有するプロセッサレベルにおいて実行され、各パーティションは、特権アドレス空間にマップされた１つのモニタインスタンスを有する。モニタ３６は、必要に応じて保護例外を使用して、仮想パーティション内のソフトウェアをモニタし、関連付けられている仮想パーティションに割り当てられていないリソースを参照しようとするあらゆる（不注意な）試みを阻止する。各モニタ３６は、ゲストＯＳおよびアプリケーションをゲストパーティション２４、２６、２８内に制限し、リードモニタ３４は、リソース管理アプリケーションをウルトラバイザパーティション１４内に制限し、そのアクセスおよび特別なハイパーバイザシステムコールインターフェース３２をリソース管理アプリケーションと共に使用して、関連付けられているパーティションモニタ３６と共に個々のパーティションリソースリストとやり取りする。
【００５３】
異なるパーティションは、異なるモニタの実装形態あるいはモニタバージョンを使用することができる。ウルトラバイザのアップグレード中には、実行中のパーティションは、引き続き既存のモニタ３６を使用し、仮想パーティションのそれぞれが再始動することを選択したときに、有効なパーティションポリシーによる新しいバージョンに切り替えることができる。
【００５４】
仮想パーティション
本発明のウルトラバイザ仮想化システムにおいては、パーティションの２つの主要なカテゴリーがある。「ユーザ」パーティションは、カスタマーアプリケーション用のゲストオペレーティングシステムを実行し、ウルトラバイザシステムインフラストラクチャパーティションは、さまざまなプラットフォームインフラストラクチャサービスを提供する。信頼性のために、ウルトラバイザ仮想化システムアーキテクチャは、仮想パーティション内に包含されていないあらゆる実装を最小限に抑える。これは、１つのパーティション内に１つの障害が含まれることがあっても、その他のパーティションに影響を与えずに済む。
【００５５】
以降でさらに詳しく説明するように、ウルトラバイザシステムパーティションのタイプとしては、下記のものが含まれる。
・ブート  １２
・アイドル  １２
・ウルトラバイザ  １４
・コマンド  ２０
・オペレーションズ  ２２
・Ｉ／Ｏ  １６、１８
【００５６】
ブートパーティション１２
ブートパーティション１２は、１つの（分割された）仮想ＣＰＵを有し、ハードウェアパーティションブートファームウェアを含む。これは、修復オペレーション中にコマンドパーティション２０およびＩ／Ｏパーティション１６、１８をブートおよびリブートすることが必要な場合に使用される。ブートストラップ中に、ブートパーティション１２は、利用可能なメモリのほとんどすべてを確保し、ブートパーティション１２、ウルトラバイザパーティション１４、または「利用可能な」パーティションのいずれかにすべてのメモリを割り当てたリソースデータベース３３内における最初のリソースマップと、ウルトラバイザパーティション１４とを構築する。ブートパーティション１２は、コマンドパーティション２０もブートするまで、リソースマネージャアプリケーションに対するトランザクションを開始する。この時点でウルトラバイザパーティション１４は、コマンドパーティション２０に連結され、そのコマンドトランザクションのみを受け入れる。ブートパーティションブートプロセッサも、すべての追加のプロセッサを初期化して、アイドルパーティション１３を実行する。
【００５７】
アイドルパーティション１３
アイドルパーティション１３は、各物理的なＣＰＵごとに１つの仮想ＣＰＵを有する。これらの仮想ＣＰＵは、ウルトラバイザシステムのＣＰＵスケジュールにおいてプレースホルダとして使用される。ウルトラバイザパーティション１４またはパーティションモニタ３４のエラー修復が、ＣＰＵ／パーティションをスケジュールから削除しなければならない場合、そのＣＰＵ／パーティションは、これらの仮想ＣＰＵのうちの１つへの参照に置き換えられる。アイドルプロセッサは、万一ハードウェアプロセッサがアイドルである間にハードウェアエラーが発生した場合にエラー修復の範囲を少なくするために、ウルトラバイザパーティション１４ではなく、アイドルパーティション１３内で「実行」される。実際には、アイドルパーティションは、（パワーおよび冷却の負荷を少なくするために）次の仮想クオンタム割り込みまでプロセッサを一時停止する。典型的なシナリオにおいては、プロセッサは、相当な量の細切れ時間にわたってアイドルになることがある。アイドルタイムは、ハードウェアパーティション内の現在共有されているプロセッサヘッドルームである。
【００５８】
ウルトラバイザパーティション１４
ウルトラバイザパーティション１４は、リソース割り当てマップを保存するリソースデータベース３３を含むメモリを所有する。これは、メモリ用の「フラクタル」マップ、プロセッサスケジュール、およびマップされたＩ／Ｏハードウェアデバイスを含む。ＰＣＩ  Ｉ／Ｏハードウェアにとっては、このマップは、ＰＣＩバスを列挙するようにＩ／Ｏパーティション１６、１８に要求するのではなく、個々のＰＣＩデバイスを割り当てることになる。同じＰＣＩバス上の異なるデバイスを異なるＩ／Ｏパーティション１６、１８に割り当てることができる。ウルトラバイザパーティション１４内のウルトラバイザリソース割り当てアプリケーションは、リソースを追跡監視し、トランザクションをリソースデータベース３３に適用し、またコマンドおよびコントロールチャネル用のサーバでもある。ウルトラバイザリソース割り当てアプリケーションは、最小限の動作環境と共にウルトラバイザパーティション１４内において実行される。リソースマネージャアプリケーションにとってのすべての状態の変更は、トランザクションとして実行される。その仮想ＣＰＵのうちの１つがアクティブであるときにプロセッサエラーが発生した場合には、いずれの不完全なトランザクションもロールバックすることができる。ハイパーバイザシステムコールインターフェース３２は、仮想プロセッサコンテキストの切り替えと、物理的な割り込みおよび仮想割り込みの送出とを担当し、ウルトラバイザアプリケーションによって管理されるマスターリソースマップへの書き込みは行わない。これは、個々のパーティションに関連付けられているウルトラバイザメモリに対するメモリの書き込みと、ウルトラバイザリソースデータベース３３内のマスターリソースマップの読み取りのみに自分自身を制限する。
【００５９】
図１５に示されているように、複数のウルトラバイザパーティション１４が使用される場合には、関連付けられているコマンドパーティション２０が、それぞれに対して提供される。これによって、大型ホストのリソースデータベース３３を（文字どおり）パーティションで区切ることができ、そのホスト内の最も大きい仮想パーティションのサイズが制限され、その一方でウルトラバイザパーティション１４の障害の影響が軽減される。複数のウルトラバイザパーティション１４は、（きわめて）大きなホストパーティション用として、あるいはパーティションで区切られているウルトラバイザシステムが最大の仮想パーティションを包含できる場合は常に、推奨される。
【００６０】
コマンドパーティション２０
コマンドパーティション２０は、各ハードウェアパーティション１０ごとにリソース割り当てポリシーを所有する。その動作環境は、たとえば．ＮＥＴ  Ｆｒａｍｅｗｏｒｋの実行環境を提供するＸＰ組み込みのものである。別の可能性としては、たとえばＷｉｎｄｏｗｓ（登録商標）ＣＥおよび．ＮＥＴ  Ｃｏｍｐａｃｔ  Ｆｒａｍｅｗｏｒｋがある。コマンドパーティション２０は、ウルトラバイザリソース管理アプリケーションによって管理されるリソース割り当てマップの同期化されたスナップショットを保持し、そのマップに対する変更はすべて、ウルトラバイザパーティション１４によってコマンドチャネル３８（図３）を通じて調整されるトランザクションである。ウルトラバイザアプリケーションは、コマンドパーティション２０からのトランザクションのみを受け入れるためのコマンドチャネル３８を実装する。
【００６１】
複数のホストハードウェアパーティションの環境においては、各ホスト１０内のスタブコマンドパーティション２０は、ＥＦＩ環境内で単純に実行することができ、ＥＦＩアプリケーションを使用して、コマンドチャネル３８をウルトラバイザパーティション１４から、ネットワークを通じて、共有されているリモートコマンドパーティション２０にパイプすることができるということが考えられる。しかしこれは、信頼性と修復時間の双方に影響を及ぼすことになり、その一方でコストの面ではわずかな利点しか提供しない。フェイルオーバ用に構成された複数のコマンドパーティション２０も、特に複数のウルトラバイザパーティション１４が存在する場合には、可能である。他のパーティションが依然として現在のリソースの割り当てで機能している間に、コマンドパーティション２０の再始動が発生する。
【００６２】
コマンドパーティション２０内の１つのリソースサービスのみが、ウルトラバイザパーティション１４内のリソースマネージャアプリケーションの要求を作成する。これによって、実際の割り当てをポリシーによってコントロールすることができる。パーティション（および後述するようにドメイン）を表すエージェントが参加して、実際のポリシーの決定を行う。ポリシーサービスは、仮想パーティションを自律的に管理するためのメカニズムを提供する。標準的なエージェントおよびカスタムのエージェントは、１つまたは複数の物理的なホストパーティション内における、プロセッサスケジューリング、およびメモリ割り当てなど、物理的なコンピューティングリソースの使用に関して交渉および連携する。２つの連携するサービスが存在する。パーティションリソースサービスは、ウルトラバイザリソースマネージャアプリケーションに緊密に結合されているコマンドパーティション２０内の１つのアプリケーションであり、（後述する）オペレーションズパーティション２２内において実行されるより高いレベルのポリシーサービスにサービスを提供し、持続パーティション構成データベースに緊密に結合されており（すなわち、それを実装しており）、リソースサービスのクライアントである。リソースサービスは、プレゼンテーション層用のモニタリングサービスも提供する。パーティションリソースオブジェクトは、厳重にコントロールされている（たとえば管理者は、リソースエージェントをインストールすることができない）。これは、システムの応答性および信頼性が、パーティションリソースオブジェクトに部分的に依存しているためである。これらのオブジェクトの１つにおける壊滅的な障害は、サーバが再始動されている間の応答性に影響を与える。繰り返し発生する壊滅的な障害によって、リソースの割り当てを変更できなくなる場合がある。
【００６３】
オペレーションズパーティション２２
オペレーションズパーティション２２は、１つまたは複数のホストシステム１０内のドメイン用の構成ポリシーを所有する。オペレーションズパーティション２２は、データセンタオペレーションズ（ポリシー）サービスが実行される場所でもある。以降で説明するように、所与の仮想データセンタ内の少なくとも１つのホスト１０は、１つのオペレーションズパーティション２２を有していなければならない。すべてのホストパーティション１０が、１つのオペレーションズパーティション２２を実行するというわけではない。１つのオペレーションズパーティション２２は、ロードバランシングおよびフェイルオーバのために、１つの仮想データセンタ内の複数のホストによって提供することができる。オペレーションズパーティション２２は、１つの所与のハードウェアパーティション内で実行される必要はなく、また１つの仮想パーティションとして実行される必要もない。その動作環境は、たとえばＸＰ  ＰｒｏｆｅｓｓｉｏｎａｌあるいはＷｉｎｄｏｗｓ（登録商標）Ｓｅｒｖｅｒ  ２００３である。このパーティション（クラスタ）は、複数のハードウェアパーティションにわたって共有することができる。構成ポリシーオブジェクトおよびＡＳＰ．ＮＥＴユーザインターフェースコンポーネントは、オペレーションズパーティション２２内において実行される。これらのコンポーネントは、１つの仮想パーティションをコマンドパーティション２０と共有して、単一のホストの配備のためのコストを削減することができる。
【００６４】
利用可能性の理由から、パーティションリソースエージェントのカスタマイズは、ポリシーエージェントのカスタマイズのために抑制される。これは、ポリシーエージェント内における障害が、リソースメカニズムの利用可能性および応答性に対して与える影響が、リソースエージェントと比較して少ないためである。ポリシーエージェントは、標準的なリソースエージェントの要求を作成する。標準的なポリシーエージェントは、カスタムな実装によって拡張することもできる。単純な単一のハードウェアパーティションのインストールにおいては、オペレーションズパーティション２２のサービスは、コマンドパーティション２０内においてホストすることができる。
【００６５】
パーティション定義／構成オブジェクトは、カスタマイズの主要なポイントであることを意図している。パーティションポリシーオブジェクトは、リソースオブジェクトのクライアントである。ポリシーサービスは、プレゼンテーション層のための構成サービスを提供する。
【００６６】
オペレーションズパーティションユーザインターフェースコンポーネントは、通常ではオペレーションズパーティション２２内において統合される。典型的な一実装形態では、ＨＴＭＬ４、ＣＳＳ、およびＪｓｃｒｉｐｔを使用することができる。オペレーションズパーティションユーザインターフェースは、主としては、ポリシーサービスと対話するＡＳＰ．ＮＥＴアプリケーションによって実装されるウェブインターフェースである。ユーザインターフェースは、パーティションポリシーサービスとは直接に、またオペレーションズパーティション２２のパーティションデータベースとは間接的に対話する。
【００６７】
．ＮＥＴスマートクライアントをオペレーションズパーティション２２内に提供することもでき、これによって、ポリシーおよびリソースサービスと直接対話して、現在の（企業の）コンピューティングリソースの豊かなビューを提示できる豊かなクライアントインターフェースが提供される。
【００６８】
図４は、オペレーションズパーティション２２内のオペレーションズポリシーサービスによって管理されるホスト１０を示している。オペレーションズポリシーサービスは、１つの利用可能なホストを選択し、その選択されたホスト１０のコマンドパーティション２０内のリソースサービスにパーティションの記述およびコマンドを送信する。ターゲットコマンドパーティション２０内のリソースサービスは、適切なリソースを選択し、それらのリソースを新しいパーティションに割り当てるためのトランザクションを作成する。このトランザクションは、ウルトラバイザパーティション１４に送信され、このウルトラバイザパーティション１４は、トランザクション要求を、キャッシュされないメモリにトランザクション監査ログエントリとして（前後のイメージと共に）保存する。このトランザクションは、検証されて、リソースデータベース３３に適用される。
【００６９】
監査ログは、リソースデータベース３３が最後にバックアップされた（メモリにフラッシュされた）とき以降のトランザクションによる変更を追跡監視し、これによって、リソースデータベース３３が頻繁にメモリにフラッシュされる必要なくトランザクションをロールバックすることができる。リソースデータベース３３の最後のバックアップ以降に監査ログ内に保存された成功したトランザクションは、その監査ログから再び適用して、障害の生じたパーティションを再始動することができる。完了したトランザクションによって予約済みのリソースを戻すこともできる。完了していないトランザクションは、まったくリソースを確保していない。監査ログは、ウルトラバイザリソース割り当てソフトウェアが、キャッシュよりも長く存続した部分的に完了している任意のトランザクションをロールバックするため使用することができる。完了していないトランザクションは、トランザクション内で指定されているすべてのリソースではなく一部のリソースをパーティションに割り当てていたはずであり、ロールバックは、そのトランザクションがキャッシュよりも長く存続した場合には、その割り当てを取り消すはずであることに留意されたい。
【００７０】
Ｉ／Ｏパーティション１６、１８
少なくとも１つの、通常は２つの、しかし潜在的にはそれを上回る数のＩ／Ｏパーティション１６、１８が、ホストノード１０でアクティブになっている。２つのＩ／Ｏパーティション１６、１８によって、ユーザパーティション２４〜２８からのマルチパスＩ／Ｏが可能となり、またＩ／Ｏパーティション１６、１８の一方における特定のタイプの障害を透過的に修復することができる。ホストハードウェアパーティション内のすべてのＩ／Ｏハードウェアは、Ｉ／Ｏ仮想パーティション１６、１８にマップされる。これらのパーティションは、通常、専用のプロセッサを割り当てられて、待ち時間を最小限に抑え、またＩ／Ｏパーティション１６、１８が現在のコンテキストではない場合に発生する可能性のある割り込みをペンディングするためのオーバーヘッドをまったく伴わない割り込みアフィニティを可能にする。Ｉ／Ｏパーティション１６、１８用の構成は、ストレージコンポーネント、ネットワークコンポーネント、およびコンソールコンポーネントが仮想パーティションを共有するか、あるいは別々の仮想パーティション内で実行されるかを決定する。
【００７１】
ユーザパーティション２４〜２８
ユーザパーティション２４、２６、２８は、ウルトラバイザ仮想化システムが実行されている理由である。これらは、カスタマー用の通常のドメイン内において記述される。これらは、カスタマーの主な対話相手となるパーティションである。その他のすべてのパーティションのタイプは、システムドメイン内において記述され、一般的には見えない所で保持される。
【００７２】
システムの起動
ホストハードウェアパーティション１０がブートされる際には、ＥＦＩファームウェアが最初にロードされる。ＥＦＩファームウェアは、ウルトラバイザオペレーティングシステムをブートする。ＥＦＩファームウェアは、標準的なメカニズムを使用して、ブートターゲットを選択する。ウルトラバイザローダが構成および選択されると仮定すると、ブートは、次のように進行する。
【００７３】
ローダは、利用可能なメモリのほとんどすべてを割り当てて、ファームウェアによってそれらのメモリが使用されることを防止する（ローダは、ファームウェアの適正なオペレーションを可能にするために、小さなプールを残す）。それからローダは、ウルトラバイザリソースデータベースのメモリデータ構造を、割り当てられたメモリ内に作成する（このメモリは、これらの初期データ構造内で事前に定義されたブートコマンドチャネルを含む）。次いでローダは、ＥＦＩ実行可能イメージローダを使用して、ウルトラバイザモニタ３４およびウルトラバイザアプリケーションをウルトラバイザパーティション１４にロードする。ローダはまた、ブートローダが完了する前のどこかの時点で、ブートモニタをブートパーティション１２の下に引き上げる。
【００７４】
次いでローダは、Ｉ／Ｏパーティション１６およびコマンドパーティション２０を作成するためのトランザクションを作成する。これらの特別なブートパーティションは、マスターパーティション定義の特別なレプリカからロードされる。コマンドパーティション２０は、必要に応じてこれらのレプリカを更新する。ブートローダは、モニタを、そしてファームウェアを新しいパーティションにロードする。この時点で、ブートローダは、ブートパスハードウェアの所有権をブートファームウェアからＩ／Ｏパーティション１６へ移す。Ｉ／Ｏパーティション１６は、実行を開始し、Ｉ／Ｏ要求を処理する用意が整う。
【００７５】
ローダは、コマンドパーティション２０からＩ／Ｏパーティション１６へのストレージチャネルと、コマンドパーティション２０からウルトラバイザパーティション１４へのコマンドチャネル３８とを作成するためのトランザクションを作成する。この時点で、ブートローダは、最後のコマンドをウルトラバイザパーティション１４へ送信して、コマンドパーティション２０にコマンドチャネル３８を譲り、コントロールを渡す。コマンドパーティション２０は、実行を開始し、リソースサービスを初期化する用意が整う。
【００７６】
コマンドパーティションの動作環境が、ブートボリュームからブートストレージチャネルパスを通じてロードされる。この動作環境は、コマンドパーティションのリソースサービスアプリケーションをロードする。リソースサービスは、コマンドチャネル３８の所有権を得て、ウルトラバイザパーティションのリソースデータベース３３からリソースのスナップショットを入手する。
【００７７】
ポリシーサービスの断片は、コマンドパーティション２０内においても実行されている。この断片は、このホストに割り当てられているインフラストラクチャパーティションのレプリカを含む。ポリシーサービスは、リソースサービスに接続され、「ブート」パーティションが最初に始動されるよう要求する。リソースサービスは、既に実行されているパーティションを識別する。この時点までに、仮想ブートパーティション１２は分離され、もはや最も高い特権を有するプロセッサレベルでは実行されていない。仮想ブートパーティション１２は、今度はコマンドパーティション２０をリブートするための準備としてＩ／Ｏパーティション１６に接続することができる。万一すべてのＩ／Ｏパーティションに障害が生じた場合、仮想ブートパーティション１２は、ウルトラバイザパーティション１４に接続して、ブートストレージハードウェアを再び入手することもできる。これは、第１のＩ／Ｏパーティション１６をリブートするために使用される。
【００７８】
仮想ブートパーティション１２は、万一オペレーション中にＩ／Ｏパーティション１６およびコマンドパーティション２０に障害が生じた場合には、それらをリブートするために引き続き実行される。ウルトラバイザパーティション１４は、これらの（ならびにその他のあらゆる）パーティション内における障害を検知するためのウォッチドッグタイマを実装する。そしてポリシーサービスは、現在のポリシーによって指示されるように、その他のインフラストラクチャパーティションをアクティブにする。これによって、通常は冗長Ｉ／Ｏパーティション１８が始動されることになる。
【００７９】
このホストシステム１０がオペレーションズパーティション２２のホストである場合には、オペレーションズパーティション２２も、この時点で始動される。そしてコマンドパーティション２０は、分散されているオペレーションズパーティションからの要求に耳を傾ける。以降で説明するように、オペレーションズパーティション２２は、ネットワークチャネルおよびネットワークゾーンを通じて、このホストおよびその他のホスト内のコマンドパーティション２０に接続される。単純な単一のホストの実装形態においては、この接続用に内部のネットワークを使用することができる。この時点で、分散されているオペレーションズパーティション２２は、現在のポリシーが指示するように、残りのパーティションを始動する。
【００８０】
すべての利用可能な（割り当てられていない）メモリリソースは、特別な「利用可能な」パーティションによって所有される。図１および２の例では、利用可能なパーティションは、サイズがゼロであり、したがって見えない。
【００８１】
新しいパーティションの作成に関するトランザクションの性質を説明するため、下記のものは、パーティションＸおよびＹの作成に際してコマンドチャネル３８を通じて送信されるトランザクションのおおよそのバージョンである（仮想プロセッサおよびチャネルを定義するために必要とされるさらなる要求は、示されていない）。
【００８２】
Simulated Transaction Log from create X (4GB ＝ 1 4GB page):
Begin Transaction
Change Owner Map[0, 1, 18], Index(25), from [0, 1, 20], to [0, 1, 25]
Initialize Partition[0, 1, 25] ("X", UserX, ...)
Change Owner Map[0, 1, 0], Index(2), from [0, 1, 20], to [0, 1, 25]
Commit Transaction
Simulated Transaction Log from create Y (1GB ＝ 256 4MB pages):
Begin Transaction
Change Owner Map[0, 1, 18], Index(26), from [0, 1, 20], to [0, 1, 26]
Initialize Partition[0, 1, 26] ("Y", UserY, ...)
Change Owner Map[0, 1, 1], IndexRange(768, 1023), from [0, 1, 20], to [0, 1, 26]
Commit Transaction
【００８３】
次は、これらのパーティションを破棄する後続のトランザクションのログのおおよそのバージョンである（それらのチャネルおよび仮想プロセッサは、既に破棄されているものとする）。
【００８４】
Simulated Transaction Log from destroy X (4GB ＝ 1 4GB page):
Begin Transaction
Change Owner Map[0, 1, 0], Index(2), from [0, 1, 25], to [0, 1, 20]
Change Owner Map[0, 1, 18], Index(25), from [0, 1, 25], to [0, 1, 20]
Destroy Partition[0, 1, 25]
Commit Transaction
Simulated Transaction Log from destroy Y (1GB ＝ 256 4MB pages):
Begin Transaction
Change Owner Map[0, 1, 1], IndexRange(768, 1023), from [0, 1, 26], to [0, 1, 20]
Change Owner Map[0, 1, 18], Index(26), from [0, 1, 26], to [0, 1, 20]
Destroy Partition[0, 1, 26]
Commit Transaction
【００８５】
ウルトラバイザメモリチャネル
仮想チャネルは、パーティションが、ゾーンへ接続するために、また仮想パーティションの間において高速かつ安全で修復可能な通信を提供するために、本発明に従って使用するメカニズムである。これらの「論理的な」チャネルのいくつかは、リソースフィルタに関与するが、ランタイムの動作はまったくない。たとえばパワーチャネルは、ゲストパーティション２４、２６、２８をパワーの特定のゾーンに関連付けるために使用されるが、パワーゾーンとのデータの交換がまったく行われない可能性がある。チャネルタイプに関連付けられているメタデータは、チャネルタイプのいくつのインスタンスを１つのパーティションに関連付けることができるかを定義するカーディナリティルールを定義する。たとえば、０または１以上のすべて、１または２以上のすべて、厳密に１、０または１、０または１以上の最も高いランク、あるいは１または２以上の最も高いランクである。ホストの役割とゲストの役割に対しては、別々のカーディナリティルールが指定される。
【００８６】
仮想チャネルは、同じホスト内のユーザパーティション２４、２６、２８とＩ／Ｏパーティション１６、１８との間における一般のＩ／Ｏおよび専用のクライアント／サーバデータ通信のためのメカニズムを提供する。それぞれの仮想チャネルは、２つの仮想パーティションの間におけるコマンドおよびＩ／Ｏキュー（たとえば、共有メモリのページ）を提供する。１つのチャネル用のメモリは、クライアント仮想パーティション２４、２６、２８によって割り当てられ、「所有」される。ウルトラバイザパーティション１４は、クライアントメモリのチャネル部分を、連結されているサーバ仮想パーティションの仮想メモリスペース内へとマップする。ウルトラバイザアプリケーションは、アクティブなサーバを伴うチャネルを追跡監視して、そのサーバパーティションがそれぞれのチャネルとの接続を切られた後まで、オーナークライアントパーティションの解体中にメモリを保護する。仮想チャネルは、コマンドメカニズム、コントロールメカニズム、およびブートメカニズム用として、ならびに従来のネットワークおよびストレージＩ／Ｏ用として使用される。
【００８７】
図３に示されているように、ウルトラバイザパーティション１４は、チャネルサーバ４０を有し、このチャネルサーバ４０は、コマンドパーティション２０のチャネルクライアント４２と通信して、コマンドチャネル３８を作成する。Ｉ／Ｏパーティション１６、１８はまた、チャネルクライアント４６によってアクセス可能なそれぞれの仮想デバイス用のチャネルサーバ４４を含む。各ゲスト仮想パーティション２４、２６、２８内では、チャネルバスドライバが仮想デバイスを列挙し、そこではそれぞれの仮想デバイスは、仮想チャネルのクライアントである。Ｉ／Ｏａパーティション１６内の点線は、コマンドパーティション２０およびオペレーションズパーティション２２からＩ／Ｏａパーティション１６内の仮想イーサネット（登録商標）スイッチへのメモリチャネルの相互接続を表しており、この仮想イーサネット（登録商標）スイッチも、適切なネットワークゾーンへの物理的な接続を提供することができる。Ｉ／Ｏｂパーティション１８内の点線は、仮想ストレージスイッチへの相互接続を表している。仮想イーサネット（登録商標）スイッチおよび仮想ストレージスイッチへの冗長接続は、図３には示されていない。ウルトラバイザパーティション１４内におけるコマンドチャネルサーバ４０からトランザクショナルリソースデータベース３３への点線は、トランザクショナルリソースデータベース３３へのコマンドチャネル接続を示している。
【００８８】
ファームウェアチャネルバス（図示せず）は、仮想ブートデバイスを列挙する。オペレーティングシステムに合わせてある別個のバスドライバは、これらのブートデバイス、ならびにランタイム専用のデバイスを列挙する。Ｉ／Ｏ仮想パーティション１６、１８を除けば、仮想パーティション内にはＰＣＩバスはまったく存在しない。これによって、複雑さが低減され、その他のすべての仮想パーティションの信頼性が高まる。
【００８９】
仮想デバイスドライバは、それぞれの仮想デバイスを管理する。仮想ファームウェアの実装は、ブートデバイス用に提供され、オペレーティングシステムドライバは、ランタイムデバイス用に提供される。デバイスドライバは、デバイスの要求を仮想デバイスのタイプに適したチャネルコマンドへと変換する。
【００９０】
マルチプロセッサのホスト１０の場合には、すべてのメモリチャネル４８は、他の仮想パーティションによって供給される。これは、ハイパーバイザシステムコールインターフェース３２のサイズおよび複雑さを最小限に抑える上で役に立つ。たとえばＩ／Ｏパーティション１６のチャネルクライアント４６とチャネルサーバ４４の間では、コンテキストの切り替えは必要とされない。これは、それらのチャネルを供給する仮想パーティションが、通常は専用の物理的なプロセッサ上でアクティブであるためである。ウルトラバイザパーティション１４は、シングルプロセッサのホストパーティション内で実行することができるが、これは、そのＩ／Ｏパフォーマンスが最適にはならないため、限られた状況（すなわち、特別なテストシナリオ）においてのみ適切となるであろう。
【００９１】
チャネルサーバ４４とチャネルクライアント４６の間における通信のためのチャネルコマンドキューの低レベルのフォーマットは、たとえば仮想チャネル４８のタイプに依存する。要求は、仮想チャネル４８内のＣＤＢ（Ｃｏｍｍａｎｄ  Ｄｅｓｃｒｉｐｔｏｒ  Ｂｌｏｃｋ）エントリを介して発行される。小さなバッファを伴う要求は、Ｉ／Ｏデータを仮想チャネル４８内に直接含むことができる。ＣＤＢによって参照されるデータは、ＭＤＬ（Ｍｅｍｏｒｙ  Ｄｅｓｃｒｉｐｔｏｒ  Ｌｉｓｔ）によって記述することができる。これによって、サーバＩ／Ｏパーティションは、すべてのＩ／Ｏデータが仮想チャネル４８を通ることを必要とせずに、ｓｃａｔｔｅｒ／ｇａｔｈｅｒ  Ｉ／Ｏを実行することができる。Ｉ／Ｏパーティションソフトウェアは、ウルトラバイザパーティション１４と対話して、仮想物理アドレスを、ハードウェアＩ／Ｏアダプタに対して発行されうるハードウェアの物理アドレスに変換する。ＲＤＭＡの標準が安定しているため、これは、ＲＤＭＡプロトコルのＩ／Ｏパーティションおよびモニタの認識性を通じて、チャネルパフォーマンスを最適化するための大きな機会である。たとえば本発明のウルトラバイザシステムは、ネットワークの読み取りの大部分が、アプリケーションネットワークバッファへのパス上におけるすべてのソフトウェアコピーオペレーションを回避することを可能にすることができる。
【００９２】
仮想チャネルの割り込みは、仮想Ｉ／Ｏの待ち時間を最小限に維持するために提供される。これらは、コマンドの完了を信号で伝えるためのクライアント仮想パーティション内の仮想デバイスドライバと、注意を新しいコマンド要求に向けさせるためのサーバＩ／Ｏパーティション１６の双方のために提供される。割り込みは、それぞれのコマンド要求ごとには必要とされず、あるいは作成されず、むしろコマンドキューの状態の移行のためにのみ作成される。
【００９３】
模範的な一実施形態においては、本発明の仮想化システムは、マルチプロセッサシステムのみを対象とする。これによって、１つまたは複数のプロセッサは、Ｉ／Ｏハードウェアを通じて仮想Ｉ／Ｏを多重化することに専念することができる。利用可能性を最大限に高めるためには、これらのプロセッサ上で実行されるドライバは、Ｉ／Ｏ仮想パーティション１６、１８内では分離される。個々のハードウェアデバイスは、これらのＩ／Ｏ仮想パーティション１６、１８によって使用するために、直接マップされる。通常、特定のゾーン内におけるネットワークおよびストレージＩ／Ｏ要求のためのＱｏＳ（Ｑｕａｌｉｔｙ  ｏｆ  Ｓｅｒｖｉｃｅ）属性を実装するのは、これらのＩ／Ｏパーティション１６、１８である。
【００９４】
Ｉ／Ｏ仮想パーティション１６、１８用の特別なマップされたルートブリッジを提供して、マップされたＩ／Ｏデバイスへのアクセスを提供することができる。このような一実施形態においては、マップされたルートブリッジを有する仮想パーティションのみが、ハードウェアＩ／Ｏデバイスへのあらゆるアクセスを有する。ルートブリッジは、仮想パーティションが、割り当てられているハードウェアデバイスにアクセスするのに必要な最小数のバスをマップする。Ｍａｐｐｅｄ  ＰＣＩ  Ｒｏｏｔ  Ｂｒｉｄｇｅは、ルートにマップされたＰＣＩバスを提供し、これは、修正された列挙メカニズム（および構成空間へのアクセス）以外の通常のパーティション用の同等のバスに類似している。マップされたバスは、特別なＩ／Ｏ仮想パーティション１６、１８内にのみ存在する。Ｗｉｎｄｏｗｓ（登録商標）仮想パーティション内のサポートは、Ｗｉｎｄｏｗｓ（登録商標）ＳｅｒｖｅｒがＩ／Ｏ仮想パーティション１６、１８用の動作環境として提供される場合に、かつその場合に限って、最終的に要求することができる。組み込まれた動作環境においては、マップされたバスは、仮想パーティションメモリ、プロセッサ、および割り込みを全体的にコントロールするカスタムＥＦＩドライバおよびＥＦＩアプリケーションをロードするために使用される単なる仮想ＥＦＩファームウェアとすることができる。
【００９５】
仮想メモリチャネル４８は、ユーザパーティション２４、２６、２８とＩ／Ｏパーティション１６、１８間における信頼できる効率的なパスを提供する。仮想チャネル４８は、高スループットのストレージインターフェースおよびネットワークインターフェースのためにハードウェアインターフェースを効率よく多重化できるようにするＲＤＭＡと同様のメカニズムを実装することが好ましい。これらはまた、パーティションを横断して通信するための唯一のメカニズムとして、コマンドパーティション２０がウルトラバイザパーティション１４と通信するための手段を提供する。模範的な一実施形態においては、下記の仮想チャネルがサポートされる。
・モニタ（コントロール）
・コマンド
・ファームウェア（ブート）
・コンソール
・ストレージ
・ネットワーク
・パワー
・メモリ
・プロセッサ
【００９６】
コントロール
コントロールチャネルは、ウルトラバイザ仮想化システムによってパーティションをコントロールするために使用されるメカニズムである。仮想パーティション内のチャネルバスドライバへのコマンドは、コントロールチャネルを通じて送達される。このチャネルは、スケジューリングに影響を与えて、現在のクオンタム内でＩ／Ｏが完了するまでの待ち時間を少なくするためのＭＳＩ（Ｍｅｓｓａｇｅ  Ｓｉｇｎａｌｅｄ  Ｉｎｔｅｒｒｕｐｔｓ）と同様のメカニズムを提供する。参照されるゾーンは、モニタの実装を選択することができる。
【００９７】
コマンド
前述のように、コマンドチャネル３８は、コマンドパーティション２０がコマンドをウルトラバイザパーティション１４へ送信するために使用するメカニズムである。ウルトラバイザの状態を変更するすべてのコマンドが処理されて、コマンドパーティションとウルトラバイザパーティションの双方の修復が可能となる。参照されるゾーンは、ウルトラバイザパーティション１４を選択する。
【００９８】
ブート
モニタ３６は、まったくＩ／Ｏを実行しない。その代わりに、一時的なブートチャネルによって、アプリケーションレベルのウルトラバイザコードが、新しいパーティションをブートするために必要とされるパーティションファームウェアをロードすることができる。コマンドパーティション２０は、ブートチャネル用のサーバであり、適切なファームウェアイメージをストレージから新しいパーティションのブートチャネルに直接読み込む。したがってブートチャネルは、モニタイメージおよびファームウェアイメージを新しいパーティションまたは「クライアント」にロードするために使用される。コマンドパーティション２０は、Ｉ／Ｏを直接ブートチャネル内へと実行する。いったん仮想パーティションファームウェアがブートされると、チャネルは破棄される。参照されるゾーンは、ファームウェアの実装を選択する。
【００９９】
コンソール
コンソールチャネルは、パーティション用のテキストコンソールおよび／またはグラフィックスコンソールを提供するためのメカニズムである。自動的なプロビジョニングを伴うパーティションは、単純なテキストコンソールを有するＷｉｎｄｏｗｓ（登録商標）Ｓｅｒｖｅｒ  ２００３のヘッドレス機能を使用する。
【０１００】
ストレージ
ストレージチャネルは、本質的には、仮想ストレージドライバから、ハードウェアストレージインターフェースへの要求を多重化するストレージサービス仮想スイッチへのＳＣＳＩ  ＣＤＢ（Ｃｏｍｍａｎｄ  Ｄｅｓｃｒｉｐｔｏｒ  Ｂｌｏｃｋ）パイプである。各ストレージチャネルは、ストレージネットワークゾーンに関連付けられている。ストレージネットワークは、イーサネット（登録商標）（ｉＳＣＳＩ）、ＦＣ、あるいは直接のものとすることができる。ＤＡＳ（Ｄｉｒｅｃｔ  Ａｔｔａｃｈｅｄ  Ｓｔｏｒａｇｅ）は、単一のホストパーティションに関連付けられている明示的な「Ｓｔｏｒａｇｅ  Ｎｅｔｗｏｒｋ」としてモデル化されている。共有されているＳＣＳＩバスの場合には、ストレージチャネルは、少数の（通常は１つまたは２つの）ホストパーティションに関連付けられている。
【０１０１】
ネットワーク
ネットワークチャネルは、仮想ネットワークドライバから、仮想イーサネット（登録商標）スイッチを実装するネットワークサービスへのイーサネット（登録商標）パイプを実装する。このスイッチは、任意選択でハードウェアネットワークインターフェースに接続される。各ネットワークチャネルは、１つのネットワークゾーンに関連付けられている。
【０１０２】
パワー
パワーチャネルは、仮想データセンタのパワーゾーンを定義するために使用される。これらは、仮想データがインスタンス化される物理的な位置の１つに経路指定される潜在的には異なる世代のテクノロジー（石炭／ガソリン／原子力）に由来する別々のパワーフェーズまたは完全に独立したパワーソースとすることができる。ゼロからｎのチャネルインスタンスが許可され、１つのゾーンのみが利用可能である必要がある。これによって、ゲストパーティション２４、２６、２８は、パワーゾーンを明示的に要求することができ、したがって、関連するパーティションを別のパワー障害ゾーンに割り当てることができる。
【０１０３】
メモリ
メモリチャネルは、メモリのパフォーマンスに基づいて仮想データセンタのリソースゾーンを定義するために使用される。ゼロからｎのチャネルインスタンスが許可され、１つのゾーンのみが利用可能である必要がある。最も小さい番号のゲストチャネルのゾーンが好ましい。複数のチャネルを有するホストは、参照されるリソースゾーンのすべてを提供する。
【０１０４】
オペレーション中に、コマンドパーティション２０は、そのチャネル用に使用されるメモリを選択し、メモリをクライアントパーティションに割り当て、チャネル定義を作成するためのトランザクションを、コマンドチャネル３８を介してウルトラバイザパーティション１４に送信する。クライアントパーティション用のモニタ３６は、メモリページをクライアントパーティションメモリ管理（ページ）テーブルに追加し、チャネルサーバを割り当てるためのトランザクションをウルトラバイザアプリケーションへ送信する。サーバパーティション用のモニタ３６は、同様にメモリページをサーバパーティションメモリ管理（ページ）テーブルに追加し、新しいチャネルが利用可能である旨をサーバパーティションコントロールチャネルに知らせるためのトランザクションをウルトラバイザアプリケーションへ送信する。
【０１０５】
プロセッサ
プロセッサチャネルは、プロセッサのパフォーマンスに基づいて仮想データセンタのリソースゾーンを定義するために使用される。ゼロからｎのチャネルインスタンスが許可され、１つのゾーンのみが利用可能である必要がある。最も小さい番号のゲストチャネルのゾーンが好ましい。プロセッサゾーンによって、プロセッサパフォーマンスゾーンを作成することができる。より高いプロセッサパフォーマンスを有するホストは、パフォーマンスの高いプロセッサゾーンに関連付けることができる。そのプロセッサゾーンを参照するゲストパーティションは、そのゾーンに関連付けられているホストのうちの１つの上で実行されることになる。
【０１０６】
プロセッサの共有
メモリを割り当てることに加えて、ウルトラバイザパーティション１４は、仮想プロセッサの実際の特権を制限することによって仮想プロセッサ間で物理的なプロセッサを共有することにより、プロセッサのリソースを割り当てる。これによって、物理的なＣＰＵのコントロールは、ＩＤＴ（Ｉｎｔｅｒｒｕｐｔ  Ｄｅｓｃｒｉｐｔｏｒ  Ｔａｂｌｅ）のコントロールを通じて保持することができる。ＩＤＴのコントロールを保持することによって、ウルトラバイザパーティション１４は、とりわけクオンタムタイマの割り込み用に、必要に応じて物理的なプロセッサのコントロールを取り戻すことができる。ハイパーバイザシステムコールインターフェース３２は、このクオンタムタイマの割り込みを使用して、仮想プロセッサコンテキストの切り替えを開始する。タイマの頻度は、プロセッサの共有の精度およびパフォーマンスのチューニングに依存する。物理的なプロセッサが、１つの仮想プロセッサの専用となっている場合には、プロセッサコンテキストを切り替えるためのクオンタム割り込みが不要なため、パフォーマンス上の理由から、タイマの頻度を少なくすることができる。
【０１０７】
以降の説明では、仮想環境を認識するための高度なＯＳ用の利用可能なメカニズムについて言及する。これは、発生する可能性のある仮想プロセッサ時間の不安定性のために有用である。興味深いことに、ＡＣＰＩを通じてＯＳに対して公開されているパワーセービングメカニズムのうちのいくつかも、同等の不安定性について記述している。
【０１０８】
ＡＣＰＩは、よく知られているＡＣＰＩデバイスパワーステート（Ｄ０〜Ｄ３）およびシステムパワーステート（Ｓ０〜Ｓ５）に加えて、プロセッサパワーステート（Ｃ０〜Ｃ３）、プロセッサパフォーマンスステート（Ｐ１〜Ｐｎ）、およびプロセッサデューティーサイクル：１−ｎ、ただしこのｎは、ハードウェアプラットフォームによって定義される、も定義する。ｎ＝１６の場合には、デューティーサイクルの精度は６．２５％である。
【０１０９】
プロセッサ共有の２つの特徴が、潜在的にＯＳに影響を与える。１つめの特徴は、時間歪みである。２つめの特徴は、パワーの使用に比例するパフォーマンスである。したがってパワーを節約するようＯＳに促すことは、共有をコントロールするための効果的なメカニズムである。１つの目標は、究極的には、１つのＯＳがこれらまたはその他の業界標準のメカニズムを通じてパフォーマンスフィードバックループに参加できるようにすることである。
【０１１０】
仮想プロセッサは、ＡＣＰＩ（仕様２．０ｃ）のプロセッサパワー＆パフォーマンスコンセプトを概念的に使用することによって、ハードウェアの（論理的な）プロセッサを共有する。プロセッサの共有は、ＡＣＰＩプロセッサクロックスロットリングおよびプロセッサパフォーマンスステート上でモデル化される。インターリーブされたプロセッサスロットリングデューティーサイクルのモデルは、ハードウェアプロセッサを共有する仮想プロセッサの動作に対する非常に緊密な適合を提供する。
【０１１１】
ＡＣＰＩプロセッサパワーステートＣ０の仮想プロセッサのみに、実際のプロセッサクロックサイクルを割り当てる必要がある。しかし短期的には、ターゲットオペレーティングシステムは、割り当てられているプロセッサパワーステートを識別することを期待されていない。これは、主として、複数のプロセッサアフィニティが公開されていること、およびこれらのいずれも止めることができるようにすることが困難であることに起因する。
【０１１２】
仮想パーティション内のＡＣＰＩモデルがプロセッサ共有モデルを公開する度合いは、パーティションの定義およびポリシーに依存する。動作環境が適切に処理できるほどに「成熟」していないモデルは、それらから隠される。ＡＣＰＩスロットリングモデルがＡＣＰＩパフォーマンスステート（Ｐｘ）モデルに勝る主な利点は、ウルトラバイザプロセッサの共有動作の不安定性をオペレーティングシステムの予想に直接マップする点である。Ｐ４  Ｓｏｆｔｗａｒｅ  Ｃｏｎｔｒｏｌｌｅｄ  Ｃｌｏｃｋ  Ｍｏｄｕｌａｔｉｏｎ（ＩＡ３２  Ｖｏｌ３,  １３．１４．３）は、１２．５％の共有精度を提供するＩＡ３２＿ＴＨＥＲＭ＿ＣＯＮＴＲＯＬ  ＭＳＲを介して代替メカニズムを提供するということを当業者ならさらに理解されよう。
【０１１３】
ＡＣＰＩスロットリングコントロールを理解できるオペレーティングシステムの場合には、ＡＣＰＩＰ＿ＣＮＴ：ＴＨＴ＿ＥＮ，ＤＵＴＹ＿ＷＩＤＴＨ値を使用して、現在の割り当てを公開することができる。４ビットのデューティー幅は、６．２５％の精度を提供し、３２ｘホストパーティション上で最低限のパフォーマンスの５１２の仮想パーティションを可能にする。パフォーマンスステートは、相対的なパフォーマンスの適切なモデリングを提供するが、キャッシュの有効性を最大限に高めるために必要とされる実際の割り当ての性質につきもののバーストは提供しない。
【０１１４】
図５は、重なり合ったプロセッサスロットリングを示している。当業者に知られているように、ＡＣＰＩデューティーサイクルモデルによって、仮想プロセッサは、物理的なＣＰＵをそれに対する認識を持たずに共有することができる。この例では、３つのパーティション（８、４、４）Ａ、Ｂ、Ｃがある（Ａは、自分が１６のうちの８サイクルを使用していると認識し、Ｂは、自分が１６のうちの４サイクルを使用していると認識し、Ｃは、自分が１６のうちの４サイクルを使用していると認識している）。Ｂのデューティーサイクルを８まで、そしてＣのデューティーサイクルを１２までオフセットすることによって、すべてのパーティションは、自分たちが受け取るプロセッササイクルのバーストの性質を理解し、そのプロセッサがそのサイクルの残りに対してはパワーを節約しているとみなす。実際には、このプロセッサは、別の仮想プロセッサを実行するのに多忙であり、パワーを節約しているわけではない。このモデルを理解しないオペレーティングシステムは、時間の異常性からの混乱を防止するために微調整を必要とするかもしれない。
【０１１５】
（おそらくは、Ｗｉｎｄｏｗｓ（登録商標）Ｓｅｒｖｅｒ  ２００３とは異なる）現在利用されていない仮想プロセッサに関するプロセッサパワーステートを変更できる洗練されたマルチプロセッサオペレーティングシステムによって、ウルトラバイザパーティション１４は、ハードウェアプロセッサリソースに対するよりいっそう優れたコントロールが可能となる。ＡＣＰＩ  Ｃ０プロセッサパワーステートの仮想プロセッサのみが、実際のプロセッサクロックサイクルを割り当てられる。たとえばＣ０ステートのプロセッサを１つだけ伴う４ｘ仮想パーティションは、１つの物理的なプロセッサ（の一部）を必要とするだけであり、依然として残りの仮想プロセッサ上での実行を通じてバックグラウンドアクティビティを保持することができる。仮想パーティション上の需要が増大すると、オペレーティングシステムは、他のプロセッサの一部またはすべてをＣ０ステートへと変更することができる。ウルトラバイザパーティション１４は、現在のポリシーに基づいて、必要に応じて他の優先順位のより低い仮想パーティションを部分的に放置するか、または場合によっては移動させて、アクセスを認めることになる。
【０１１６】
最も長い待ち時間を伴うプロセッサパワーステート（たとえばＣ３）は、プロセッサのリソースを再び要求して利用できる可能性が最も大きい。これは、コマンドパーティション２０内のリソースサービスが、待ち時間の長いパワーステートにおけるプロセッサを完全に除外するプロセッサスケジュールを計算することができるためである。待ち時間の短い状態にあるプロセッサ（たとえばＣ１）は、待機中の優先順位の低いバックグラウンドでの仮想パーティションによる一度に１つのプロセッサクオンタムへのアクセスを認めることしかできない。ウルトラバイザによって提供される仮想デバイスドライバは、フレキシブルでなければならず、ＯＳがプロセッサパワーステートを利用することを妨げてはならない。
【０１１７】
ＡＣＰＩプロセッサパワーステートは、比較的長い時間の間いくつかの仮想ＣＰＵを明示的に手放すためのマルチプロセッサＯＳ用のＡＰＩを提供する。これによって、ウルトラバイザシステムは、（Ｃ０ステートの仮想プロセッサを含むだけの）より効率的なプロセッサスケジュールを計算することができる。プロセッサパワーステートＣ０へ戻るための待ち時間は、ウルトラバイザシステムが、仮想ＣＰＵを含む新しいプロセッサスケジュールを計算するのにどれぐらいの時間を要するかによって定義される。
【０１１８】
マルチプロセッサ動作環境は、需要の少ない間にプロセッサパワーステートＣ２およびＣ３をサポートすることができるという点で有益である。これによって、コマンドパーティション２０内のリソースエージェントは、仮想パーティション上の需要が増大するまで、１つまたは複数の仮想ＣＰＵをプロセッサスケジュールから削除することができる。
【０１１９】
一般的に、ウルトラバイザパーティション１４によって実装されたプロセッサスケジュールは、物理的なプロセッササイクルを複数の仮想プロセッサの間で分割する。プロセッサパワーステートＣ０でない仮想プロセッサは、（もしあれば）スケジュールから除外される。この割り当ては、ノードローカルメモリキャッシュの効果を最大限に高めるために比較的長く保持される。コマンドパーティション２０内のリソースサービスは、新しいスケジュールを計算し、そのスケジュールをトランザクションとしてウルトラバイザパーティション１４に適用し、ウルトラバイザパーティション１４は、（古いスケジュールが、その始まりにラップ（ｗｒａｐ）したと思われる場合は）分割できないオペレーションにおける現在のスケジュールを置き換える。
【０１２０】
図６は、ホストの物理的なプロセッサのタイムクオンタムに対する仮想プロセッサのサンプルマップを示している。「Ｉ／Ｏ−ａ」および「Ｉ／Ｏ−ｂ」の仮想パーティションは、冗長Ｉ／Ｏパーティション１６および１８であり、それぞれＩ／Ｏの待ち時間を最小限に抑えるために専用の物理的なプロセッサを有している。図示されているように、コマンドパーティションとオペレーションズパーティションは、１つの物理的なプロセッサを共有している。残りの１１のパーティションは、ユーザ／ゲストパーティションに相当する。これらのパーティションは、メモリの局所性、キャッシュアフィニティ、およびＩ／Ｏパフォーマンスを最大限に高めるためにリソースを自動的に割り当てられる。
【０１２１】
前述のように、各ハードウェアＩ／Ｏデバイスは、Ｉ／Ｏ仮想パーティション１６、１８のうちの１つにマップされる。メモリにマップされたＩ／Ｏアドレス空間は、Ｉ／Ｏ仮想パーティション１６、１８への割り当てをメモリマップに記録することによって予約される。
【０１２２】
ウルトラバイザコントロールコンポーネント
ウルトラバイザパーティション１４およびそのハイパーバイザシステムコールインターフェース３２のアーキテクチャは、最も重要なコンポーネントが最も単純なメカニズムを有し、より高いレベルのあまり重要ではない（すなわち修復可能な）コンポーネントがより複雑なポリシーを実装するように設計されている。目標は、最も低レベルのメカニズムの厳格な検査を実用的にし、かつ他のすべてのレベルのものを修復可能とすることである。
【０１２３】
仮想パーティションモニタ３６と同様、ハイパーバイザシステムコールインターフェース３２は、最も高い特権を有するプロセッサレベルにおいて実行される。その担当は、仮想プロセッサコンテキストの切り替えと、ハードウェアおよび仮想の割り込みを仮想パーティションへ送達することに限定されている。プロセッサコンテキストの切り替えは、万一切り替え中に深刻なエラーが発生した場合に包含（ｃｏｎｔａｉｎｍｅｎｔ）を可能にするためにトランザクションとして実行される。
【０１２４】
１つのハードウェアの割り込みが、関連付けられているハードウェアプロセッサの１００％を割り当てられていないＩ／Ｏパーティション１６、１８の１つのプロセッサにマップされている場合、ハイパーバイザシステムコールインターフェース３２は、そのＩ／Ｏパーティション１６、１８の次のスケジュールされているクオンタムまでその割り込みを「保留」することを担当する。ハイパーバイザシステムコールインターフェース３２は、何の決定も行わず、ウルトラバイザパーティション１４内のウルトラバイザリソースマネージャによって提供される割り当ておよびスケジュールを実施する。
【０１２５】
直接ハイパーバイザシステムコールインターフェース３２によって開始されることができる一定数の特別なトランザクションが存在する場合がある。このような一例は、追い出されたパーティションの場所におけるアイドルパーティションのプロセッサを参照することによって、仮想パーティションをプロセッサスケジュールから削除している。
【０１２６】
ウルトラバイザパーティション１４用のモニタ３４は、実装においてその他のパーティションモニタに類似している。これは、簡略化された実装とすることができる。というのも、ウルトラバイザパーティション１４は、動的なページングを伴わずに実行されることが予想されるためである。そのモニタは、割り当てられた物理メモリを、ページテーブルエントリによって提供される仮想アドレスにアイデンティティマップすることができる。
【０１２７】
前述のように、ウルトラバイザパーティション１４は、コマンドチャネルサーバ４０を実装するトランザクショナルリソースマネージャアプリケーションを含む。これは、ホストシステム１０用のリードモニタ３４を通じて、パーティションリソースマップを個々のパーティションモニタ３６に提供し、これによってそれぞれのモニタ３６は、それらの関連付けられているパーティション内におけるＯＳの包含を維持することができる。
【０１２８】
トランザクショナルシステムにおいては、リソースマネージャは、リソースを管理しトランザクションを適用するコンポーネントである。したがって、本発明のウルトラバイザシステムの信頼性を最大限に高めるために、リソースの割り当てに対するすべての変更は、トランザクションを介して実行される。トランザクション要求（変更ログとして二役を果たす）は、そのトランザクションが適用される前にメインメモリにフラッシュされる（またはキャッシュされていないメインメモリにコピーされる）。そしてすべての変更は、そのトランザクションが実施される前にメインメモリにフラッシュされる。これによって、リソーストランザクションの処理中に発生する可能性のある特定のハードウェア障害からの修復が可能となる。リソースサービスは、トランザクションを頻繁には開始しない（調整は、ミリ秒単位ではなく分単位で行われる）という点に留意されたい。したがって信頼性の利点によって、あらゆるパフォーマンス上の懸念が目立たなくなる。トランザクション要求は、トランザクションを実施するために必要とされる前提条件として二役を果たす前イメージを明示的に含む。要求を処理しているときに万一プロセッサに障害が生じた場合には、別のプロセッサを使用して、障害の生じたトランザクションをロールバックすることができる。
【０１２９】
ブートパーティション１２
ＥＦＩを組み込んだブートファームウェアは、ハードウェアパーティションシステムディスクからハードウェアパーティションによってブートされる。必須ではないが好ましいアプローチは、ハードウェアパーティションシステムファームウェアとしてファームウェアをロードする機能である。前述のように、ウルトラバイザパーティション１４用のブートストラップコンポーネントは、ブートパーティション１２内のＥＦＩドライバおよび／またはＥＦＩアプリケーションとしてロードされる。これらのコンポーネントは、ウルトラバイザパーティション１４および最初のリソースマップを作成し、ウルトラバイザパーティションリソースメインジャコードをロードし、次いでリードモニタシステムコールインターフェース３２をロードして、複数の仮想パーティション間におけるコンテキストの切り替えを開始する。ウルトラバイザモニタが（リードモニタとして）ロードされ、ウルトラバイザリソースマネージャアプリケーションが、ファームウェアとしてロードされる（このファームウェアは、リソースマネージャアプリケーションを実行するための、余分な装備を取り除いた、あるいは実在しない、最低限十分なファームウェアとすることができる）。（ブートパーティション１２としての）このファームウェアは、次いでコマンドパーティション２０およびＩ／Ｏパーティション１６、１８のブートストラップへと進む。いったんこれらがブートされると、ブートパーティション１２は、修復の目的で必要とされるまでアイドルのままとなる。
【０１３０】
ウルトラバイザパーティション１４
ハイパーバイザシステムコールインターフェース３２は、ウルトラバイザパーティション１４によってマップされる。ブートストラップ中には、このウルトラバイザパーティション１４によってのみ使用される特別な「モニタ」イメージおよび「ファームウェア」イメージがロードされる。このウルトラバイザパーティション１４用のリードモニタ３４は、プロセッサパーティションクオンタムタイマの割り込みを処理し、仮想プロセッサコンテキストの切り替えを実行するようハイパーバイザシステムコールインターフェース３２に指示し、保留して次のクオンタムコンテキストの切り替え時に配信する必要のあるあらゆる割り込みを途中で押えておくことを担当する。割り込みを途中で押えておく必要性は、Ｉ／Ｏの割り込みを、Ｉ／Ｏ仮想パーティション１６、１８を実行するために専用に設けられた物理的なプロセッサに割り当てることによって、最小限に抑えられる。
【０１３１】
ウルトラバイザパーティション１４用の「ファームウェア」は、ハードウェアシステム１０用のウルトラバイザリソースマネージャアプリケーションである。このウルトラバイザリソースマネージャアプリケーションは、その他のパーティション内のファームウェアとまったく同様に、より低い特権を有するレベルにおいて実行される。これによって、ハードウェアは、ウルトラバイザパーティション１４に明示的に割り当てられているメモリ内におけるリソースマネージャの包含を（ゆるやかに）実施することができる。これは、リソースマネージャアプリケーションに対して、新しいメモリインデックステーブルを割り当てる特別なトランザクション中に自分自身のハードウェアページテーブルエントリを修正することを認めることができるためである。このソフトウェアは、コマンドおよびコントロールチャネルの要求を処理するために、特別な仮想プロセッサコンテキストの切り替えを介して、その他の仮想パーティションのスケジュールされているプロセッサクオンタム内でのみ実行される。図１５に示されているように、より大きなホストの物理的なリソースは、パーティションで区切って、別個の独立したウルトラバイザパーティション１４によって管理することができる。
【０１３２】
ウルトラバイザアプリケーションの複数のコンポーネントは、それぞれのウルトラバイザパーティション１４に関連付けられている。リソースマネージャアプリケーションおよびリードモニタ３４は、仮想パーティションインフラストラクチャを提供する。
【０１３３】
ホストパーティションの中核となる低いレベルのコンポーネントは、ハイパーバイザシステムコールインターフェース３２である。この要素はカーネルと呼ぶことができるが、本発明によるウルトラバイザアーキテクチャにおいては従来のカーネルは存在しない。ウルトラバイザパーティション１４のモニタ３４は、伝統的にカーネルに関連付けられているＶＭＭの機能のうちのいくつかを実行する。
【０１３４】
たとえばハイパーバイザシステムコールインターフェース３２の主要な機能は、仮想ＣＰＵコンテキストの切り替えを実行すること、および仮想の割り込みを配信することである。これが参照するデータ構造は、ウルトラバイザパーティション１４および／またはゲストパーティション２４、２６、２８によって所有される。このコンポーネントは、ウルトラバイザパーティションモニタバイナリと共にパッケージされ、ウルトラバイザパーティション１４のモニタ３４としてロードされる。ウルトラバイザパーティション１４内のパーティションリソースマネージャのために、特別なスケジューリングが使用される。コマンドパーティションのＶＣＰＵ（Ｖｉｒｔｕａｌ  ＣＰＵ）からウルトラバイザのＶＣＰＵへの、およびその逆のコンテキストの切り替えは、コマンドパーティション２０のプロセッサデューティーサイクル内で発生する。コマンドパーティション２０内のコマンドチャネル３８用のクライアントドライバは、トランザクションを実行するための要求を実施する。このドライバは、コマンドパーティションのモニタ３６のハイパーバイザシステムコールインターフェース３２を呼び出し、このハイパーバイザシステムコールインターフェース３２は、この物理的なＣＰＵに割り当てられているハイパーバイザパーティションのＶＣＰＵへのコンテキストの切り替えを実行する。ウルトラバイザリソースマネージャは、このトランザクションを完了すると、コマンドパーティションのＶＣＰＵへのコンテキストの切り替えの戻しを実行し、コマンドパーティションのＶＣＰＵは、コマンドチャネルドライバへと戻り、コマンドチャネルドライバは、リソースサービスへと戻る。
【０１３５】
本発明によるホストシステム１０の中核となるコントロールコンポーネントは、ウルトラバイザリソースマネージャである。このリソースマネージャは、物理的なホストパーティション１０のメモリ、プロセッサ、チャネル、およびＩ／Ｏのリソースを管理するコンポーネントである。これは、アクティブなリソースの割り当てのためのデータベースリソースマネージャのようなものである。このコンポーネントは、ウルトラバイザパーティション１４の「ファームウェア」としてロードされる。ウルトラバイザリソースマネージャサービスは、ウルトラバイザ仮想パーティション１４のコンテキスト内で、ただし最小限の動作環境を伴って実行される。仮想ＥＦＩファームウェアは、ウルトラバイザパーティション１４内にはロードされない。これらのＶＣＰＵがアクティブである場合のハードウェア障害は、このパーティション内におけるあらゆるメモリの更新に関する処理される性質のために、残存する可能性がある。
【０１３６】
リソースマネージャは、メモリ、プロセッサ、チャネル、およびＩ／Ｏのリソースを（仮想）パーティションに割り当てるための低レベルのメカニズムを提供する。リソースマネージャは、トランザクショナルリソースマネージャを実装するという点でトランザクショナルデータベースに類似した方法でアクティブなリソースの割り当てを公開する。低レベルのメカニズムは、ポリシーの決定を行わない。これによって、よりいっそう単純で信頼できるハイパーバイザメカニズムの実装が可能となる。リソースマネージャは、仮想パーティションのモニタインスタンス３６にサービスを提供する。コマンドパーティション２０は、唯一の他のクライアントであり、ホストシステム１０用のすべてのハードウェアポリシーの決定を担当する。オペレーションズパーティション２２は、（後述する仮想データセンタの実装における場合と同様に）複数のホストにわたるビジネスポリシーの優先順位および決定を担当するその唯一のクライアントである。
【０１３７】
ホストハードウェアリソースの使用状況を追跡監視するリソースマネージャソフトウェアは、トランザクショナルメカニズムを採用し、これによって、障害の生じたプロセッサからの修復が可能となる。新しい状態を伴うトランザクションログは、実行処理中には常にメインメモリにフラッシュされる。これは、ウルトラバイザトランザクション中の大半のプロセッサ障害によって主要なウルトラバイザデータ構造が脅かされることを防止する。ユーザパーティション内において実行している間のプロセッサ障害は、通常ではそのプロセッサ上でアクティブな仮想パーティションのみが障害を起こすよう求めることになる。
【０１３８】
メモリチャネルは、ウルトラバイザパーティション１４によって管理されるメモリリソースとして取り扱われる。メモリチャネルは、ＲＤＭＡの設計原理にゆるやかに基づいたものである（すなわち、実状に即していてかつ可能な場合は常にＩ／Ｏバッファ内におけるデータのコピーを回避し、順序がバラバラの要求の完了を可能にする）。主要な設計の問題は、ネットワークパケットの受信である。ハードウェアルーティングがサポートされていない場合には、受信されたパケットのコピーが必要となる。ＲＮＩＣスペース内における業界標準の取り組みを利用することができる。しかしコピーによって余分な修復作業が発生する可能性があるため、修復用のバッファセットがゲストパーティション２４、２６、２８内に存在すべきであり、これは、ゲストのモニタ３６の担当とすべきであり、またＩ／Ｏパーティション１６、１８によってハードウェアに割り当てることができる記述子のリングバッファによってマップされるべきである。Ｉ／Ｏパーティション１６、１８は、ネットワークパケットをｄｕｍｂＮＩＣからＩ／Ｏパーティションバッファ内へと読み込むことになる。仮想イーサネット（登録商標）スイッチは、ターゲットパーティションを確定するためにパケットヘッダへのアクセスを必要とする。いったんターゲットパーティションがわかると、仮想イーサネット（登録商標）スイッチは、そのパケットをＩ／Ｏパーティションバッファから直接クライアントパーティションバッファへコピーする。インテリジェントネットワークアダプタであれば、Ｉ／Ｏパーティションバッファへのコピーを介在させることなく、直接ターゲットパーティションを確定することができる。ＲＮＩＣであれば、少なくとも最も大きいパフォーマンス上の影響を有するパケットのかなりの割合に対してこれを行うことができる。Ｉ／Ｏパーティション１６、１８が、パケットをメインメモリ内へと読み込む前にそのヘッダを入手することができるならば、そのパケットにとってＩ／Ｏパーティションバッファは必要とされない。
【０１３９】
モニタ３４は、各仮想パーティション内の「インスタンス」と共に分散されるウルトラバイザパーティション１４の一部である。各モニタインスタンスは、所与の仮想パーティションの最も高い特権を有するレベルを「所有」する。これらの分散されているモニタ３６は、ウルトラバイザシステムとファームウェアまたはオペレーティングシステムとの間で仲裁を行う。複数の実装によって、各仮想パーティションの要件に基づいたトレードオフの最適化が可能となる。それぞれの実装は、（一意の識別子およびバージョン情報を有する）強力に指名された．ＮＥＴアセンブリに類似した方法で識別される。
【０１４０】
オブジェクト指向の関係で考えた場合、実装コードは、ウルトラバイザパーティション１４内へとロードされ、パーティションインスタンスデータは、モニタされているパーティションに関連付けられる。最近Ｉｎｔｅｌによって発表されたＶＴ（Ｖａｎｄｅｒｐｏｏｌ  ｔｅｃｈｎｏｌｏｇｙ）は、モニタインスタンスが仮想パーティションから区別されることを可能にし、モニタから仮想パーティションへコンテキストを切り替えるためのアトミックオペレーションを提供する。１つのハードウェアプロセッサが共有されている場合には、複数のモニタインスタンスが連携して、コンテキストの切り替えを最小限に抑える。ＶＴは、典型的な実施形態において実装することができる。
【０１４１】
図４に示されているように、各モニタ３６は、パーティションコンポーネントとの自らの対話を強調するために、それぞれのパーティションのコンテキスト内で繰り返される。各パーティションの定義は、モニタの実装を選択する。軽い動作環境は、潜在的なオーバーヘッドがより少ない比較的軽いモニタの実装を使用することができる。特別なモニタの実装をアドオンパッケージに含めて流通させることは、技術的に実現可能である。パーティションポリシーは、パーティションのアクションをモニタするためにどのモニタの実装をアクティブにするかを決定する。
【０１４２】
モニタ３６は、リソースマネージャアプリケーションと明示的に連携する。各モニタ３６は、パーティションリソースの割り当ての相補的なビューを管理する。リソースマネージャは、リソースを修復するための外部ビューを保持し、その一方でモニタ３６は、リソースを効率的に活用するための内部ビューを保持する。モニタ３６はまた、パーティションのインスタンスに関する詳細を管理し、そのパーティションの最も高い特権を有するレベルにおいて実行される。モニタ３６は、既に使用可能にされているページングを使用してより低い特権を有するレベルに移行した後に仮想ファームウェアをブートする。モニタ３６は、プロセッサ仮想化テクノロジーが利用可能である場合にはそのプロセッサ仮想化テクノロジーと対話するコンポーネントである。モニタ３６は、パーティションＯＳ内にインストールされている仮想ファームウェア用、ファームウェアブートドライバ用、およびウルトラバイザドライバ（主としてソフトウェアバスドライバ）用のサービスをさらに提供する。ＯＳカーネル用のサービスは、Ｖａｎｄｅｒｐｏｏｌの機能に依存して、検知不能とすることができる。
【０１４３】
仮想ファームウェアは、仮想ストレージチャネルドライバのファームウェアの実装を提供する。これは、ＯＳをブートするためにＯＳローダファームウェアアプリケーションによって使用される。いったんＯＳがブートされると、ＯＳに固有の仮想ドライバが、ファームウェアドライバに取って代わる。仮想ファームウェアは、標準的なＥＦＩシェルならびに仮想ストレージドライバおよび仮想ネットワークドライバを提供し、これは、ＰＸＥベースのプロビジョニングをサポートする。仮想パーティションファームウェアは、仮想パーティション内で実行されるように適合されたＥＦＩ（Ｅｘｔｅｎｓｉｂｌｅ  Ｆｉｒｍｗａｒｅ  Ｉｎｔｅｒｆａｃｅ）のプラットフォームアダプテーションである。これは、ＥＦＩ１．１の仕様に準拠し、そのサンプルの実装に基づく。この仮想ＥＦＩの実装は、標準的なドライバを省略し、本明細書に記載されている必要なメモリチャネルタイプ用のブートドライバを提供する。しかしＥＦＩ  ｉＳＣＳＩイニシエータを使用することができれば、ＯＳをｉＳＣＳＩターゲットからブートすることがさらに可能となるであろう。実状に即している場合には、このファームウェアは、モニタ３６よりも低い特権を有するレベルにおいて実行される。たとえばこのファームウェアは、モニタ３６によってマップされているページ内のリング１で実行される。
【０１４４】
ＯＳは、このファームウェアと同じ（低い特権を有する）レベルにおいて実行される。Ｉｎｔｅｌ  ＶＴ（Ｖａｎｄｅｒｐｏｏｌ  Ｔｅｃｈｎｏｌｏｇｙ）、あるいは同等のサーバによって、オペレーティングシステムは、仮想パーティション内におけるそれらの存在を認識することなく実行することができる。しかしパフォーマンスを最適化するための軽微な変更は、やはりパフォーマンスを改善するために望ましい。これは、より良好なスケーラビリティおよび改善されたプラットフォームのコスト効率へと直接に形を変える。
【０１４５】
Ｗｉｎｄｏｗｓ（登録商標）ＮＴベースのオペレーティングシステム（すなわちＷｉｎｄｏｗｓ（登録商標）Ｓｅｒｖｅｒ  ２００３）にとっては、ソフトウェアバスドライバ、ＮＤＩＳミニポート、およびストレージポートミニポートが、ウルトラバイザコンポーネントと対話する主要なドライバである。
【０１４６】
コマンドパーティション２０
ブートストラップの後では、コマンドパーティション２０が、リソースマネージャアプリケーションの唯一のクライアントである。これは、コマンドチャネル３８を介してウルトラバイザパーティション１４と通信する。これによって、業界標準の動作環境およびランタイム環境（すなわち．ＮＥＴ  Ｆｒａｍｅｗｏｒｋ）を、プラットフォームに固有のリソース割り当てアルゴリズムを実装するリソースサービスソフトウェア用のホストとして使用することができる。万一このパーティション内における致命的なエラーが発生した場合には、コマンドパーティション２０を再始動することができ、最後に実行されたリソーストランザクションのポイントまで回復することができるため、そのエラーは、他の仮想パーティションにとっては致命的とはならない。
【０１４７】
コマンドパーティション２０は常に、自分が管理するホスト１０内の仮想パーティションとして実行される。これは、ローカルコマンドチャネルを通じてリソース要求を送信することを可能にし、いかなるＩ／Ｏコンポーネントに対する依存状態も回避する。これによって、リソースのバランスを取り戻すオペレーションのための待ち時間を最小限に抑えることができ、したがって重要なハイパーバイザコンポーネントは、最小限の独立した機能しか必要としない。
【０１４８】
コマンドパーティション２０のストレージボリューム（イメージ）は、モニタおよびファームウェアのイメージを含む。ブートパーティション１２は、モニタ３６およびファームウェアのイメージをロードするためにホスト１０のブート中にこのストレージボリューム（イメージ）にアクセスすることができる。このストレージボリュームは、組み込まれて連結されたストレージのディスクパーティションとすることができる。２つのセルのホスト（たとえば、１６ｘ  ５２０システム）の典型的な構成においては、それぞれのセルの、組み込まれたディスクは、コマンドパーティション２０のストレージをホストすることになる。これは、コマンドパーティションストレージの冗長性を提供する。
【０１４９】
コマンドパーティション用の動作環境は、Ｗｉｎｄｏｗｓ（登録商標）ＣＥおよび．ＮＥＴ  Ｃｏｍｐａｃｔ  Ｆｒａｍｅｗｏｒｋとすることができる。
【０１５０】
オペレーションズパーティション２２
オペレーションズパーティション２２は、コマンドパーティション２０の唯一認められた（１つまたは複数の）クライアントである。アクティブな仮想パーティションをコントロールするリソーストランザクションをやり取りするために、安全なネットワーク接続が使用される。図４に示されているように、ウルトラバイザパーティション１４内の処理要素５０は、リソースデータベース３３へ、そしてコマンドパーティション２０のリソースサービス５２へ接続される。Ｉ／Ｏパーティション１６、１８内の仮想イーサネット（登録商標）スイッチ５４は、安全なネットワーク接続を提供するためにリソースサービス５２とオペレーションズサービス５６の双方に接続される。オペレーションズパーティション２２は、コマンドパーティション２０を操作する。各ホスト１０は、１つまたは２つのコマンドパーティション２０を有する一方で、それぞれの仮想データセンタは、１つまたは２つのオペレーションズパーティション２２を有する。オペレーションズパーティションのストレージボリューム（イメージ）は、仮想データセンタの１つまたは複数のドメイン用の仮想パーティションの定義を含む。ブートストラップのために必要とされるパーティションの定義の抽出されたコピーは、コマンドパーティションのストレージボリューム内に保存される。ブートパーティション１２は、これらの定義にアクセスして、Ｉ／Ｏパーティション１６、１８およびコマンドパーティション２０をブートする。ホストがオペレーションズパーティション２２を含む場合には、コマンドパーティション２０は、ホストのブートストラップの最終ステージ中にその定義にアクセスする。
【０１５１】
オペレーションズパーティション２２は、複数のコマンドパーティション２０を管理することができ、複数のオペレーションズパーティション２２は、同一のコマンドパーティション２０を管理することができる。オペレーションズパーティション２２は、仮想パーティションとして、あるいは専用のハードウェアパーティションまたは業界標準のシステム内において実行することができる。オペレーションズパーティション２２はまた、その他のプラットフォーム管理ツールとの統合のポイントも提供する。オペレーションズパーティション２２は、ポリシーサービスをその主要なアプリケーションとして実行する。追加のオペレーションズパーティション２２は、任意選択のアドオンであり、プラットフォーム管理ツールの管理コンポーネントのための標準的な記憶場所である。
【０１５２】
図４は、システムおよびユーザの仮想パーティション、ウルトラバイザパーティション１４内の仮想パーティション記述子５８、コマンドパーティション２０内のリソースエージェント６０、ならびにコマンドパーティション２０およびオペレーションズパーティション２２内のポリシーエージェント６２のメモリの割り当てを示している。図４内の実線は、各仮想パーティションを表す４つのエンティティを接続している。図示されているように、オペレーションズパーティション２２内のアクティブパーティションオブジェクト（パーティションオペレーションイベントをモニタしている）は、パーティションＩＤを介してコマンドパーティション２０内のパーティションオブジェクト（パーティションリソースをモニタしている）に関連付けられており、またパーティションＩＤを介してウルトラバイザパーティション１４内のパーティション記述子５８に関連付けられており、このパーティション記述子５８は、割り当てられているリソースについて記述する。同様にウルトラバイザパーティション１４は、パーティションモニタ３６に関連付けられており、このパーティションモニタ３６は、パーティションを、割り当てられているリソースに制限する。
【０１５３】
図４においては、ウルトラバイザパーティション１４は、パーティション記述子５８を有しているが、リソースエージェントまたはポリシーエージェントは有していない。その他のパーティションはすべて、コマンドパーティション２０においてリソースサービス５２によってホストされているリソースエージェント６０を有している。ホストシステム１０を操作するために必要とされるシステムパーティション｛Ｉ／Ｏａ、Ｉ／Ｏｂ、コマンド、オペレーション｝用のポリシーエージェント６２は、コマンドパーティション２０内で実行されているポリシーサービス６４によってシステムドメインにおいてホストされる。ユーザパーティション｛Ｘ、Ｙ、Ｚ｝用のポリシーエージェントは、オペレーションズパーティション２２内で実行されているポリシーサービス５６によってパーティションドメインにおいてホストされる。
【０１５４】
パーティションを停止しているとき、パーティションのリソース再要求は、すべてのサーバパーティションがメモリチャネル４８から接続を切るまで遅延される。これは、クライアントパーティションメモリが再割り当てされる前にあらゆるインフライトのＩ／Ｏが完了するように、必要とされるものである。サーバパーティションを停止しているときには、最初にすべてのチャネルを閉じて接続を切らなければならない。
【０１５５】
図４においては、オペレーションズパーティション２２は、パーティションの定義の「従来の」持続的なデータベースを管理する。パーティションがアクティブにされる際（自動的な起動または明示的な手動による始動のいずれか）、オペレーションズパーティション２２は、必要とされているリソースを有するホストシステム１０を選択し、ホストコマンドパーティション２０内で実行されているリソースサービスに接続し、パーティションの定義および開始コマンドをリソースサービス５２に提供する。コマンドパーティション２０は、要求されているものを所与のホストシステム１０の利用可能なリソースと照合するアプリケーションを含む。コマンドパーティション２０は、ウルトラバイザパーティション１４のリソースデータベースの同期化されたスナップショットを使用して、アクティブにされるパーティションのための適切なリソースを選択する。コマンドパーティション２０は、トランザクションを更新してウルトラバイザパーティション１４内のスナップショットとリソースデータベース３３の双方に適用するためのトランザクションを作成する。
【０１５６】
前述のように、ウルトラバイザパーティション１４は、現在の（ホストごとの）リソースの割り当てのマスターリソースデータベース３３を管理し、コマンドパーティション２０がリソースの割り当てを変更できるようにする単純なトランザクションをサポートする。万一コマンドパーティション２０に障害が発生した場合には、代わりのコマンドパーティション２０が、その時点のスナップショットを入手して、ホストシステム１０のリソースの管理を再開することになる。
【０１５７】
オペレーションズサービスは、ホスト１０をモニタする。万一何らかの理由でホストに障害が発生した場合には、オペレーションズサービス５６が、障害の生じたホストに割り当てられていた仮想パーティション用の新しいホストを選択することになる。オペレーションズサービスはまた、相互にモニタし、万一オペレーションズパーティション２２のホスト１０に障害が発生した場合にはモニタリングの任務をフェイルオーバに処理することができる。
【０１５８】
パーティションを停止するために、オペレーションズパーティション２２は、コマンドパーティション２０に要求を送信する。コマンドパーティション２０は、ウルトラバイザパーティション１４に要求を送信して、ゲストパーティションオペレーティングシステムに対するていねいな要求を開始する（応答のないまたは認識していないオペレーティングシステムは、それらの同意なしに停止または一時停止されることができるという点に留意されたい）。ウルトラバイザパーティション１４は、モニタコントロールチャネルを通じて、ゲストパーティションが接続されているすべてのチャネルのサーバパーティションへ要求を送信する。いったんそれらのチャネルのうちの最後のチャネルが接続を切られると、ウルトラバイザパーティション１４は、コマンドチャネル３８を通じてリソースサービスへイベントを送信し、リソースサービスは、ゲストパーティションのリソースを再び要求するためのトランザクションを作成する。プロセッサのリソースは、すぐに再要求することができるが、メモリは、すべてのメモリチャネル４８が接続を切られた後まで再要求することができないという点に留意されたい。
【０１５９】
したがってオペレーションズパーティション２２は、パーティションの定義の「従来の」持続的なデータベース（図示せず）を管理し、その一方でウルトラバイザパーティション１４は、現在の（ホストごとの）リソースの割り当てのインメモリデータベース３３を管理する。コマンドパーティション２０は、要求されているものを所与のホストの利用可能なリソースと照合するアプリケーションを含み、このアプリケーションは、双方のデータベースに、例えば実際のリソースを割り当てるためにウルトラバイザパーティション１４に、およびたとえばリソース割り当ての利用履歴を記録するためにオペレーションズパーティション２２に、トランザクションを適用する。
【０１６０】
プログラム可能なインターフェース
ウルトラバイザアプリケーションは、ウルトラバイザの実装の拡張性について記述するプログラム可能なインターフェースを含むことができる。プログラム可能であることは、ポリシーサービスによって提供され、ポリシーサービスはまた、パーティションの定義の単純なスクリプトおよびスクリプト化されたインポート／エクスポートを可能にするスクリプトモデルを提供する。すべてのユーザインターフェースは、このプログラム可能なインターフェースのクライアントである。
【０１６１】
ポリシーサービスは、仮想パーティションの持続を担当する。ポリシーサービスは、ウルトラバイザ以外のコンポーネントのための唯一のプログラム可能なインターフェースを提供し、他のポリシーサービスインスタンス（たとえばオペレーションズパーティション）の知識および利用可能なホストハードウェアパーティションの知識を有するドメインの集合の持続を管理する。適切に保護されたウェブサービスと互換性のあるインターフェースを提供することができる。インターフェースは、ポリシーサービスに対する．ＮＥＴリモートアクセス用の抽象的なインターフェースを定義することができる。
【０１６２】
リソースアダプタは、リソースサービスと対話するためにポリシーサービスによって使用することができる。これによって、複数のリソースサービスの実装が可能となる。たとえばＭｉｃｒｏｓｏｆｔのＶｉｒｔｕａｌ  Ｓｅｒｖｅｒ用の特別なアダプタによって、データセンタサービスは、複数のＭＳ  Ｖｉｒｔｕａｌ  Ｓｅｒｖｅｒホストのゲストパーティションを管理することができる。リソースサーバは、ポリシーサービスによって必要とされる要求を．ＮＥＴリモーティングインターフェース、あるいはその他のあらゆる同等のインターフェースとして実装することができる。
【０１６３】
リソースサービスは、ＣＭＰエンタープライズサーバの適正なオペレーションを担当する。標準的なセキュリティ構成は、クライアントをポリシーサービスのインスタンスに制限する。サービス構成は、たとえばカスタム証明書のリストのようなＰＫＩメカニズムを介して、承認されたポリシーサービスインスタンスのリストを含む。
【０１６４】
ＩＩ．ウルトラバイザメモリの割り当て
前述のように、本発明のウルトラバイザアーキテクチャは、ハードウェアリソースを仮想パーティションに対してどのように物理的に割り当てるか、および各仮想パーティションをお互いからどのように分離させるかを定義する。最も低い層は、より高い層によって管理される基本的なメカニズムを提供する。このアプローチは、モノリシックなアプローチに比べて、重要な基本的な層上における強固な信頼性の保証をさらに現状に即したものにする。
【０１６５】
物理的なリソースの割り当ては、ウルトラバイザパーティション１４のオペレーションにとって鍵となる。効率性は、典型的なオペレーティングシステムに比べて非常に粗いスケールで割り当てを行うことによって実現される。オペレーティングシステムと比較して、メモリ領域およびプロセッササイクルは、非常にきめの粗い割り当てを有する。ウルトラバイザパーティション１４の最も低いレベル（モニタ３４）は、単純なメカニズムを提供する。（障害が発生した場合には修復することができる）より高いレベルのコードは、基本的なメカニズムを使用するためのポリシーを担当する。
【０１６６】
本発明の仮想化システムの鍵となる特徴は、さらなるハードウェアリソースが追加されるにつれて容易に拡張できることである。好ましい一実施形態においては、拡張可能なパーティションメモリマッピングシステムがウルトラバイザパーティション１４内に実装され、それによって、仮想化システムを実質的に無限の数のページへと拡張することができる。ｌｏｇ（２１０）ベースの割り当てによって、仮想パーティションメモリのサイズは複数の世代にわたって増大することができ、メモリの割り当てを管理するオーバーヘッドが増加することはない。メモリのそれぞれのページは、ページ階層内の１つのパーティション記述子に割り当てられ、ウルトラバイザパーティション１４によって管理される。
【０１６７】
この典型的な実施形態においては、ＩＡ３２ハードウェア階層化ページサイズモデルが、ウルトラバイザメモリの割り当ての基礎（すなわち、４ＭＢの大きなページのオプションを伴う４ＫＢのページ）である。このアプローチを一般化することによって、わずかな量のオーバーヘッドで、潜在的なフラグメンテーションの問題を招くことなく、非常に大きなメモリサイズの割り当てが可能となる。しかしウルトラバイザパーティション１４は、特別なＰＡＥテーブル（２ＭＢ、１ＧＢ）をマッチさせようとは試みない。これは、ウルトラバイザの４ＭＢのページを記述するためには複数の連続したプロセッサＰＡＥ  ＰＤＥエントリが必要であるということを意味している。モニタ３４は、必要に応じてこれらのプラットフォームハードウェアの違いを埋め合わせる。
【０１６８】
ウルトラバイザパーティション１４は、可能な場合は常に４Ｋページの管理を回避する。これによって、ウルトラバイザパーティション１４が追跡監視する必要のあるページの数が（３桁）少なくなる。個々のパーティションモニタのみが、小さなページの大多数を追跡監視する必要がある。これは、複数のパーティションの間においてネットワーク要求を追跡監視すること、ならびに必要とされるメモリ全体を少なくするためのライトストラテジに関してハードウェアの書き込み保護およびコピーを使用することを通じて複数の仮想パーティションの間でページを透過的に共有する可能性を捨て去る。しかしメモリ容量の動向を与えられれば、これは著しく不利な点ではない。
【０１６９】
ウルトラバイザパーティション１４のリソースデータベースのメモリ割り当て「ページ」マップが、スケーリングファクタとして１Ｋ（１０２４）を使用してスケールの階層として編成される。このマップは、それぞれのスケールにおいて単一の４ＫＢのインデックスページが１０２４の可能な「ページ」の割り当てを記述するため、「フラクタル」な特徴を有する。含まれるスケール用のインデックスページは、それ自体１０２４のページのうちの１つとして割り当てることができ、結果として最も細かい４ＫＢの割り当て精度で０．１％の最大メモリ割り当てオーバーヘッドとなる。したがって、たとえばウルトラバイザパーティション１４は、４ＭＢの精度における４ＧＢのページの割り当てを追跡監視するために４ＫＢのページを１つだけ必要とする。同様にウルトラバイザパーティション１４は、内部のウルトラバイザシステムのデータ構造によって使用するために４ＭＢのページを４ＫＢの精度へと割り当てるために４ＫＢのページを１つだけ必要とする。それらのインデックスページ自体は、ウルトラバイザパーティション１４によって所有される。
【０１７０】
４ＴＢのメモリを有するシステムであれば、１Ｋの４ＧＢのパーティションをサポートすることができる。単一の４ＫＢのページが、この割り当てを記述することになる。単一のページはまた、４ペタバイトおよび１Ｋの４ＴＢのパーティションを有するシステムも同様に記述する。いずれの場合も、内部のウルトラバイザシステムのデータ構造を割り当てるためだけに追加のページが必要とされる。典型的な仮想パーティションは、連続している必要のないいくつかの数の４Ｍのページを割り当てられる。より大きな仮想パーティションには、１つまたは複数の（より大きな）４ＧＢのページを割り当てることができる。
【０１７１】
多くの場合、割り当てられるメモリページは、連続したものとなり、（リソースサービスも選択する）割り当てられる物理的なプロセッサと同じノード／セルから割り当てられることになる。割り当てられるメモリが本当に連続している必要があるかどうか（またはどの程度その必要があるか）は、Ｌ１／Ｌ２／Ｌ３／Ｌ４キャッシュの動作に依存する。リソースサービスは、１つのパーティションがＬ２／Ｌ３／Ｌ４キャッシュのより大きな割合を有するようにしたい場合には、不連続なメモリを意図的に使用することができる。
【０１７２】
それぞれのキャッシュラインは、通常では一定数のメモリ領域にマップされ、そのうちの１つだけが、所与の時点にキャッシュ内に存在することができる。メモリがパーティションに線形に割り当てられる場合、キャッシュの割り当ては、メモリの割り当てに比例する。キャッシュの配分に基づいて割り当てを積み重ねる（または積み重ねから引き出す）ことによって、キャッシュのより小さなまたはより大きな割合を割り当てることができる。このコンテキストにおいて使用する際、積み重ねからの引き出しは、独立したキャッシュラインの数を最大化するようにメモリを割り当てる戦略に関連している。
【０１７３】
ウルトラバイザパーティション１４は、ハードウェアプラットフォームの現在のリソースの需要およびパフォーマンスの特性に基づいてメモリのページを１つの物理的な領域から別の領域へ移動するためのメカニズムを含む。たとえば１つの仮想パーティションがプロセッサの別のセット上へとスケジュールされる場合には、割り当てられているメモリを同じセルに移動することが有利であるかもしれない。
【０１７４】
ウルトラバイザパーティション１４は、パーティションを追跡監視するためにメモリのごく小さな部分しか必要としない。これらは、パーティション、チャネル、およびプロセッサ用のウルトラバイザ記述子／構造のために使用される。メモリは、可能であって実情に即している場合は常に、４ＧＢまたは４ＭＢのユニット（大きなページ）内に割り当てられる。しかし個々の大きなページは、ウルトラバイザシステムのデータ構造用に小さなページへと分割される。必要なウルトラバイザメモリはすべて、さまざまなサイズのページテーブルのような構造から割り当てられる。積み重なりを回避することによって、メモリのフラグメンテーションを解消するためにウルトラバイザパーティション１４を再始動する必要がなくなるため、ウルトラバイザパーティション１４を無限に実行することができる。
【０１７５】
ウルトラバイザリソースマネージャマップは、高速のアクセスを有する必要はない。その目的は、仮想パーティションが破棄された場合にリソースを再び要求するための信頼できるメカニズムを提供することである。これは、リソースサービス内のマップスナップショットを再構築するために、そしてリソースサービスパーティションの修復に続いてそのスナップショットをコマンドパーティション２０に渡すために使用される。
【０１７６】
どのメモリに割り当てるかを選択してプロセッサを割り当てるのは、より高いレベルのコントロールメカニズム（コマンド仮想パーティション２０内のリソースサービス５２）である。仮想パーティションが非アクティブにされる際（あるいはサイズを変更する際）、リソースサービス５２は、パーティションで区切られているメモリのうちのいくつかを再割り当てことを選択することができ、コマンドチャネル３８を介してウルトラバイザパーティション１４内のリソース管理アプリケーションに、適切なトランザクションを送信する。
【０１７７】
各モニタインスタンス３６は、ＰＴＥ（ｐａｇｅ  ｔａｂｌｅ  ｅｎｔｒｙ）のベースアドレスフィールドを検証して拡張するように最適化されている自分自身の部分マップ（各仮想パーティション用のマップ）を管理する。モニタ３６の主要なタスクは、その仮想パーティションをその割り当てられている物理アドレス内に制限することである。
【０１７８】
モニタインスタンス３６は、パーティションメモリの割り当て情報と、パーティションを管理するためにウルトラバイザパーティション１４および／またはモニタ３６によって使用されるコントロールメモリとパーティション自体のコントロール下にあるパーティションメモリを区別するために使用される２つの基本的なメカニズムとを入手する。可能性のある１つのアプローチは、従来のＵ／Ｓ方式において、Ｕ（ビットクリア）を使用してパーティションメモリを示し、Ｓ（ビットセット）を使用してウルトラバイザコントロールメモリを識別して、インデックスパーティション番号の値におけるビット３０を使用することである。代替の手法は、リソースサービスが、パーティションを作成する際にコントロールチャネル内のメモリリストを構築するというものである。
【０１７９】
特別なパーティション記述子（疑似パーティション）が、確保されているメモリの所有権をマークするために使用される（たとえば、利用可能である、インストールされていない、壊れているなど）。これによって、ウルトラバイザパーティション１４の最も低いレベルに対する変更を伴わずにより高いレベルのコンポーネントによって使用するために、新たな予約済みのタイプを導入することができる。これは、最も低いレベルのコンポーネントのバージョンのアップグレードを少なくする上で役に立つ。
【０１８０】
本発明のウルトラバイザシステムは、Ｉｎｔｅｌ  ＩＡ３２およびＥＭ３２Ｔのアーキテクチャによって定義されるページテーブル階層の（ＰＡＥ、ｘ６４の）発展に基づく導出ではなく、常に２１０という累乗に基づくページサイズの階層を使用する。図７は、ウルトラバイザシステムにとって直接関係のある最初の４つのスケールを示している。このより高いスケールによって、システムメモリのサイズにおけるムーアの法則による成長が引き続き提供される。ページテーブルおよびページエントリの列は、ページサイズの階層を参照するための正規化された命名法（ｎｏｍｅｎｃｌａｔｕｒｅ）を提示している。Ｉｎｔｅｌの命名法は、ＰＡＥモードにおいてはスケールが厳密にはマッチしないが、参照のポイントとして含まれる。「２進数の倍数用のプレフィックス」の標準的な定義は、１９９８年１２月に定義されたhttp://physics.nist.gov/cuu/Units/binary.htmlにおいて見つけることができる。本明細書を通じて、標準的なＳＩプレフィックスは、１０進法の定義｛（１０３）n｝ではなく２進法の定義｛（２１０）n｝を指す。
【０１８１】
図７に示されているように、１つの「ページ」は、１Ｋ（３２ビット）の「ワード」として明示的に定義することができる。したがって典型的な１２ビットのページオフセットは、１０ビットの（２１０）ワードのインデックスおよび２ビットのバイトインデックスから構成される。６４ビットのシステムにおいては、１つの「ページ」が、１Ｋの６４ビットの「ワード」であること、および３ビットのバイトインデックスを使用することが妥当である。
【０１８２】
ウルトラバイザメモリマップの概念的な定義は、単純に下記のとおりとなる。
Dim MemoryMap[1024, 1024, 1024, 1024] as Int32.
【０１８３】
概念的なマトリックス内の値は、現在のページオーナーのパーティション番号である。概念的なマトリックスは、実際にはむしろ「まばらな」マトリックスのように、あるいは４ＫＢのページテーブルの階層のように実装される。大きなページが割り当てられている場合には、１０２４のより小さなページをマップするためにメモリはまったく必要とされない。これは、定義によって、すべてが同じオーナーを有しているためである。したがってインデックス付きのプロパティのようなより有用な関数表記は、下記のとおりとなる。
Function GetMemOwner(T, G, M, K) As Int32.
【０１８４】
４ＴＢ未満のメモリを有するハードウェアパーティションにとっては、（右から）４つめの次元は常に０である。４ＧＢ未満のメモリを有するハードウェアパーティションにとっては、３つめの次元も常に０である。メインメモリが４ＰＢを超える用意が整っている場合には、他の次元を１つまたは２つ追加することができる。
【０１８５】
ページの所有権のみが、このウルトラバイザメモリマップによって指定される。（キャッシュの動作などの）その他のメモリ特性は、各仮想パーティションモニタ３６とリソースサービスによって管理される。メモリの実装が、アーキテクチャ上は（１Ｋのノードのそれぞれにおける）最大で１Ｍの仮想パーティションに「制限」される場合には、単一のＩｎｔ３２が、各メモリページのオーナーパーティションを指定することができる。１つの４ＫＢのインデックスページにおいては、これは、１Ｋの「ページ」のうちのそれぞれのページを１Ｍのパーティションのうちの１つにマップする。
【０１８６】
リソースマネージャアプリケーションは、メモリインデックスおよびパーティション記述子をホストシステム１０の複数のノード（または複数のセル）の間で明示的に分配して、参照の局所性を最大限に高めることができる。これは、図８に部分的に示されているように、パーティション番号内のＧＢインデックスをノードインデックスに置き換えることによって達成することができる。これは、インデックス「ページ」が４Ｋから８Ｋバイトへ拡張することを必要とする前に、最大で１Ｍのパーティションを有する１Ｋのノードを提供する。
【０１８７】
仮想パーティション番号は、仮想パーティション記述子を識別する４Ｋのページのマップへの３２ビットのインデックス（２，１０，１０，１０）である。第１のビットは、より小さなページ内における副次割り当て（ｓｕｂａｌｌｏｃａｔｉｏｎ）を示すために割り当てられる。これは、Ｉｎｔｅｌ  ＰＤＥにおける大きなページビットとまさに同様であるが、反対の極性を有している。次のビットは、最初は予約済みである。しかし、このビットをＵ／Ｓとして利用することにより、パーティションによって所有されているがウルトラバイザパーティション１４によって使用するために予約済みのメモリを識別することができる。これによって、拡大縮小されたページを選択するための３つの２１０の値が残り、これは、記述子がすべてハードウェアパーティションの第１の／同じ４ＴＢの範囲（あるいはノード／セルの同じ４ＭＢ）のメモリ内にあることを必要とする。マスターウルトラバイザインデックス記述子は、この４ＴＢの範囲のｉｎｔ６４オフセットを含む。デフォルトの（そして最初は許可されているだけの）オフセット値は、ゼロである。ウルトラバイザパーティション１４の場合には、ウルトラバイザパーティション記述子の前にあるページは、このウルトラバイザインデックス記述子用に予約済みである。
【０１８８】
図８は、２つのユーザパーティションＸ（４ＧＢ）およびＹ（１ＧＢ）用の６４ＧＢのシステムのメモリの割り当てを示す一例である。図８の一番上にあるのは、メモリマップインデックスページ内の値として生じる可能性のある２つの形式のパターンを示したものである。符号ビットが設定されている場合には、この値は、「メモリインデックスリファレンス（Ｍｅｍｏｒｙ  Ｉｎｄｅｘ  Ｒｅｆ）」を表し、これは、このアイテムによって記述されるメモリを分割するインデックスページへの、ただし次のより小さなスケールにおける参照である。符号ビットがクリアである場合には、この値は、このページのオーナーを指定する「パーティション番号」である。図８においては、「［Ｇ，Ｍ，Ｋ］」は、パーティション番号を表し、「［−，Ｇ，Ｍ，Ｋ］」は、次のより小さなページスケールへのメモリインデックス参照を表す（「−」は、Ｉｎｔ３２内の符号ビットの「自明の」表示として意図されている）。マップインデックス［−，Ｇ，Ｍ，Ｋ］に対して、Ｍｅｍ［Ｇ，Ｍ，Ｋ］が、所与のページを１０２４の均等なより小さなページへと分割するマップページのアドレスを提供する。定義によって、パーティション番号［Ｇ，Ｍ，Ｋ］用のパーティション記述子は、Ｍｅｍ［Ｇ，Ｍ，Ｋ］に存在する。この表記によって、有効なパーティション番号を認識することが容易になる。これは、それら自身によって所有されるすべての４ＫＢのページがパーティション記述子ページであるためである。
【０１８９】
図８におけるそれぞれのボックスは、メモリの４ＫＢのページを表している。それぞれのボックスの下のＭｅｍ［Ｇ，Ｍ，Ｋ］のラベルは、そのページの物理メモリアドレスである。陰影のないページは、このハードウェアホストパーティション１０用のメモリ割り当てデータベースを含み、その一方で陰影の付いたボックスは、パーティション記述子を表している。これらのパーティション記述子のそれぞれは、メモリマップインデックスページから参照される有効なパーティション番号に対応している。各パーティション記述子のパーティション番号は、ラベル「Ｍｅ」の隣の記述子内に［Ｇ，Ｍ，Ｋ］の表記で表されている。「欠落している（ｍｉｓｓｉｎｇ）」：［０，１，１９］および「利用可能な（ａｖａｉｌａｂｌｅ）」：［０，１，２０］用の２つの特別なエントリは、欠落している（インストールされていない）および利用可能な（現在使用されていない）メモリ用のメモリマップ内で使用されているパーティション番号を定義する（これらの特別なパーティションにプロセッサのリソースが割り当てられることはないという点に留意されたい）。「ウルトラバイザ」：［０，１，２４］パーティションは、メモリマップ用に必要とされるメモリを所有する。この考察においては、アイドルパーティション１３およびブートパーティション１２は無視する。２つのユーザパーティションＸ：［０，１，２５］およびＹ：［０，１，２６］を作成したトランザクションと、それらのリソースを再び要求するトランザクションについて、以降で説明する。
【０１９０】
図８の第１の行における無地のボックスは、メモリマップのページを表している。これらは、物理メモリＭｅｍ［０，１，０］の第２の４ＭＢのページにおいて開始する。このサンプルではＭｅｍ［０，１，２］からＭｅｍ［０，１，１６］までのページが予約済みであり、メモリの６４ＧＢをすべて４ＭＢのユニット内において割り当てることができる。Ｍｅｍ［０，１，１７］における割り当てられているページの使用については、示されていない。
【０１９１】
「ウルトラバイザインデックス（Ｕｌｔｒａｖｉｓｏｒ  Ｉｎｄｅｘ）」ページは、メモリマップに対するマスターインデックスである。ウルトラバイザインデックスは、マップのアドレスおよびその最大のサイズを提供する。図８では、Ｍｅｍ［０，１，２３］におけるページは、ウルトラバイザインデックスである。このページは、メモリマップをデコードする上で重要な情報を含む。ＭａｐＨｉｇｈ／ＭａｐＬｏｗは、物理メモリを１０２４までのより小さなページへと分割するインデックスページに対する６０ビットの参照を提供する。ＭａｐＨｉｇｈは、どの４ＴＢのメモリがトップインデックスページを含むかを定義する。図８に示されている例では、ＭａｐＨｉｇｈは、［０，０，０］、すなわちＥ＝０、Ｐ＝０、Ｔ＝０でなければならず、これは、この例が４ＴＢを超えるメモリを有していないため、第１の４ＴＢを表している。ＭａｐＬｏｗは、［０，１，０］であり、これは、第２の４ＭＢのページ内における第１の４Ｋを参照する。｛この図におけるラインは、最も大きいスケールのページテーブルに対する本参照を表している。｝「Ｏｒｄｅｒ」の値は、メモリマップによって記述されるメモリのスケールを示している。図８の例では、（図７からのスケールを使用した）３というオーダー値は、最も大きいスケールのページテーブルがＰＧＭ（ＰａｇｅＧｉｇａＭａｐ）であり、そこでは１０２４のＰＧＥ（ＰａｇｅＧｉｇａＥｎｔｒｉｅｓ）のそれぞれがメモリの４ＧＢを記述するということを示している。４ＴＢ超を有するホストは、オーダー４のマップを必要とし、その一方で４ＧＢ以下を有するホストは、オーダー２のマップによって、あるいはより大きなマップにより、メモリの第１の４ＧＢ以外のすべてを利用不能として単純にマークすることによって記述することができるということを理解されよう。Ｉｎｄｅｘ：［０，１，２３］は、検証の目的による自己参照である。Ｕｌｔｒａ：［０，１，２４］の値は、メモリマップのメモリを所有するウルトラバイザパーティション１４のパーティション番号を参照する。不要なＡｖａｉｌ：［０，１，２０］の値は、「利用可能な」疑似パーティションのパーティション番号を識別する。この値は、ウルトラバイザパーティション１４によっては直接使用されないが、診断の目的で有用である。実際のマップにおいては、ホストのそれぞれのノードを記述するページリストへの参照が存在するはずである。それぞれのノードは、自分自身の「利用可能な」疑似パーティションを有するであろう。
【０１９２】
Ｍｅｍ［０，１，０］におけるＰＧＭ（ＰａｇｅＧｉｇａＭａｐ）ページは、メモリを４ＧＢのページ内に割り当てる。ホストは、メモリの６４ＧＢしか有していないため、エントリ１６〜１０２３は、この「欠落している」メモリを「欠落している」疑似パーティションのパーティション番号に割り当てる［０，１，１９］を含むという点に留意されたい。この例では、エントリ０：［−０，１，１］は、第１の４ＧＢがＭｅｍ［０，１，１］におけるＰＭＭ（ＰａｇｅＭｅｇａＭａｐ）によって４ＭＢのページへとさらに分割されていることを記述している。エントリ１：［０，１，２５］は、第２の４ＧＢが、「パーティションＸ」であるパーティション番号［０，１，２５］に割り当てられていることを記述している。図８におけるラインは、パーティションＸへのこの割り当ての参照を示している。エントリ２〜１４は、メモリの５２ＧＢが４ＧＢのページとして利用可能であることを示している。エントリ１５：［−，０，１，１６］は、Ｍｅｍ［０，１，１６］におけるＰＭＭによって４ＭＢのページへとさらに分割されているホスト内の最後の４ＧＢを記述している。図８の例では、最後の４ＧＢ内における４ＭＢのページがすべて偶然にも利用可能になっている。
【０１９３】
Ｍｅｍ［０，１，１］におけるＰＭＭは、第１の４ＧＢを４ＭＢのページ内に割り当てる。ページの上にある「Ｔ＝０  Ｇ＝０」は、マップ上でこのページまで歩を進めることから得られるコンテキストである。このページはＰＧＭ内のインデックス０によって参照されたため、Ｇ＝０である。ホストは、少なくとも４ＧＢを有しているため、エントリのうちのいずれも、「欠落している」疑似パーティションを参照しないという点に留意されたい。エントリ０：［０，１，２２］は、Ｍｅｍ［０，０，０］における物理メモリの第１の４ＭＢのページを「ブート」：［０，１，２２］パーティションに割り当てる。エントリ１：［−，０，１，１８］は、次の４ＭＢがＭｅｍ［０，１，１８］におけるＰＫＭによって４ＫＢのページへとさらに分割されていることを記述している。エントリ２：［０，１，２４］は、次の４ＭＢをウルトラバイザパーティション１４に割り当てる。エントリ３〜７６７：［０，１，２０］は、利用可能なメモリのほぼ３ＧＢを記述している。エントリ７６８〜１０２３：［０，１，２６］は、メモリの１ＧＢ（２５６の連続した４ＭＢのページ）を、パーティションＹであるパーティション番号［０，１，２６］に割り当てる。図８における２つのラインは、ページのこの範囲がパーティションＹに割り当てられていることを表している。
【０１９４】
Ｍｅｍ［０，１，１８］におけるＰＫＭ（ＰａｇｅＫｉｌｏＭａｐ）は、第２の４ＭＢを４ＫＢのページ内に割り当てる。ページの上にある「Ｇ＝０  Ｍ＝１」は、マップ上でこのページまで歩を進めることから得られるコンテキストである。このページはＰＭＭ内のインデックス１によって参照されたため、Ｍ＝１である。より高いスケールのコンテキスト、Ｇ＝０は、ＰＭＭから繰り越される。これらのページのほんのわずかが、マップおよびパーティション記述子によって必要とされるだけであり、したがってエントリ２７〜１０２３：［０，１，２０］は、これらのほとんどを「利用可能な」疑似パーティションによって「所有される」ものとして記述している。エントリ２４、２５、２６は、それぞれウルトラバイザ、Ｘパーティション、およびＹパーティション用のパーティション記述子を参照する。図８におけるこれらのパーティションの隣の３つのラインは、それぞれの記述子への参照を示している。エントリ１９〜２２は示されていないが、欠落パーティション記述子、利用可能パーティション記述子、アイドルパーティション記述子、およびブートパーティション記述子を参照している。エントリ２３は、ウルトラバイザインデックス用のメモリをウルトラバイザパーティション１４に割り当てる。エントリ０、１、１６、１８は、マップのページをウルトラバイザパーティション１４に割り当てる。エントリ２〜１５、１７は、使用されておらず、ウルトラバイザパーティション１４によって利用可能とするか、または予約済みとすることができる。
【０１９５】
Ｍｅｍ［０，１，１６］におけるページは、アドレスＭｅｍ［１５，０，０］における１Ｋの連続した４ＭＢのページ（ｐａｇｅｓ）を記述している（これは、６４ＧＢのハードウェアパーティション内における最後の４ＧＢである）。マップページによって参照されるページは、すべて同じオーナーを有するため、コマンドパーティション２０は、複数のページを１つの４ＧＢのページへとマージするためのトランザクションを作成することができる。下記のものは、このメモリをマージし、次いで再び分割するトランザクションである。
【０１９６】
Merge 1K 4MB into 4GB
Begin Transaction
Merge Map[0, 1, 0], Index(15), {From Map[0, 1, 16], For [0, 1,20]}
Change Owner Map[0, 1, 18], Index(16), from [0, 1, 24] to [0, 1, 20]
End Transaction
Split 4GB at Mem[15, 0, 0] into 1K 4MB pages at Mem[15, 0..1023, 0]
Begin Transaction
Change Owner Map[0, 1, 18], Index(16), from [0, 1, 20], to [0, 1, 24]
Split Map[0, 1, 0], Index(15), Into Map[0, 1, 16], {For[0, 1, 20]}
Commit Transaction
【０１９７】
下記の例は、コマンドパーティション２０が、パーティションＸおよびＹを作成するためにコマンドチャネル３８を通じてウルトラバイザパーティション１４へトランザクションをどのように送信するかを示している。その後に続くのは、仮想プロセッサおよびチャネルを定義するために必要とされるさらなる要求が示されていないためにコマンドチャネル３８を通じて送信されるトランザクションの近似的なバージョンである。
【０１９８】
Simulated Transaction Log from create X (4GB = 1 4GB page):
Begin Transaction
Change Owner Map[0, 1, 18], Index(25), from [0, 1, 20], to [0, 1, 24]
Initialize Partition[0, 1, 25] ("X", UserX, ...)
Change Owner Map[0, 1, 18], Index(25), from [0, 1, 24], to [0, 1, 25]
Change Owner Map[0, 1, 0], Index(2), from [0, 1, 20], to [0, 1, 25]
Commit Transaction
Simulated Transaction Log from create Y (1GB = 256 4MB pages):
Begin Transaction
Change Owner Map[0, 1, 18], Index(26), from [0, 1, 20], to [0, 1, 24]
Initialize Partition[0, 1, 26] ("Y", UserY, ...)
Change Owner Map[0, 1, 18], Index(26), from [0, 1, 24], to [0, 1, 26]
Change Owner Map[0, 1, 1], IndexRange(768, 1023), from [0, 1, 20], to [0, 1, 26]
Commit Transaction
【０１９９】
次は、これらのパーティションを破棄する後続のトランザクションのログのおおよそのバージョンである（それらのチャネルおよび仮想プロセッサは、既に破棄されているものとする）。
【０２００】
Simulated Transaction Log from destroy X (4GB = 1 4GB page):
Begin Transaction
Change Owner Map[0, 1, 0], Index(2), from [0, 1, 25], to [0, 1, 20]
Change Owner Map[0, 1, 18], Index(25), from [0, 1, 25], to [0, 1, 24]
Destroy Partition[0, 1, 25] 
Change Owner Map[0, 1, 18], Index(25), from [0, 1, 24], to [0, 1, 20]
Commit Transaction
Simulated Transaction Log from destroy Y (1GB = 256 4MB pages):
Begin Transaction
Change Owner Map[0, 1, 1], IndexRange(768, 1023), from [0, 1, 26], to [0, 1, 20]
Change Owner Map[0, 1, 18], Index(26), from [0, 1, 26], to [0, 1, 24]
Destroy Partition[0, 1, 26]
Change Owner Map[0, 1, 18], Index(26), from [0, 1, 24], to [0, 1, 20]
Commit Transaction
【０２０１】
ＩＩＩ．Ｉ／Ｏパーティションのオペレーション
前述のように、Ｉ／Ｏパーティション１６、１８は、物理的なホストハードウェアをチャネルサーバエンドポイントにマップする。Ｉ／Ｏチャネルサーバ６６（図９）は、Ｉ／Ｏスロット７０内におけるＩ／Ｏハードウェアリソース６８の共有を担当する。内部のＩ／Ｏ構成においては、Ｉ／Ｏチャネルサーバ６６は、共有されている共通のＩ／Ｏハードウェアを通じて複数のパーティションのチャネルからの要求を多重化することによって、ソフトウェア内でこれを行う。パーティションの相対的な物理アドレスは、メモリチャネル４８を通じてＩ／Ｏサーバパーティション１６、１８へ渡され、Ｉ／Ｏサーバパーティション１６、１８は、そのアドレスを物理的な（ホスト）ハードウェアアドレスに変換し、ハードウェアＩ／Ｏアダプタとデータをやり取りする。その一方で、外部のＩ／Ｏ構成（図１０）においては、Ｉ／Ｏチャネルサーバ６６は、セットアップ情報をインテリジェントＩ／Ｏハードウェア７２に渡すことによって、これを行い、そしてこのインテリジェントＩ／Ｏハードウェア７２によって、ゲストパーティション２４、２６、２８は、たとえば「ユーザモードＩ／Ｏ」またはＲＤＭＡ（Ｒｅｍｏｔｅ  Ｄｉｒｅｃｔ  Ｍｅｍｏｒｙ  Ａｃｃｅｓｓ）の手法を使用して、場合によってはコンテキストの切り替えをまったく伴わずに、Ｉ／Ｏの意味部分を直接実行することができる。
【０２０２】
いかなるパーティションのモニタ３６も、リソースマネージャアプリケーションによってそれに割り当てられている範囲内から物理メモリを割り当てること、およびそのパーティションのオペレーションにとって必要とされるように仮想ページを物理メモリへマップすることを担当する。Ｉ／Ｏメモリチャネル４８は、物理メモリの一部分であり、複数のパーティションによって共有され、パーティションとの間でデータを安全かつ迅速に転送できるようにする方法のセットによってコントロールされる。このチャネルは、ＯＳ仮想ドライバおよびコントロール構造によって定義されている、キューに入れられたＩ／Ｏデータブロックを含む。ゲストモニタは、Ｉ／ＯまたはバスにマップされたＩ／ＯあるいはメモリをゲストＯＳ環境へとマップすることはない。物理的なデバイスドライバは、Ｉ／Ｏパーティション１６、１８内に常駐する。これは、代理機能性、ソフトウェアのアップグレード、Ｑｕａｌｉｔｙ  Ｏｆ  Ｓｅｒｖｉｃｅアルゴリズム、リソースの要求の照合、およびエラーの修復に関する共通のモデルを提供することによって、異なるＯＳイメージおよびハードウェアボックスにわたってＩ／Ｏリソースを一元管理することを容易にする。Ｉ／Ｏパーティションモニタ３６は、プライベートメモリをマップできることに加えて、Ｉ／Ｏデバイスの物理的なリソースをマップすることもできる。
【０２０３】
内部Ｉ／Ｏ
図９に示されているように、内部のＩ／Ｏは、Ｉ／Ｏスロット７０内のＰＣＩアダプタカード６８などのリソースハードウェアを使用して達成される。内部Ｉ／Ｏチャネル４８は、入力キュー、出力キュー、およびエラーキューから構成されている。それぞれの主体（クライアント／サーバ）は、指示を有し、リソースおよびエラーのために他方に割り込むだけである。Ｉ／Ｏの開始および完了は、同じＣＰＵによって処理され、そのようなものとしては、スケジューリングドライバがある。
【０２０４】
仮想チャネルドライバおよびパーティションの相対的な物理アドレスは、ゲストパーティション２４、２６、２８内に存在し、ゲストモニタ３６から入手される。チャネルを通じてゲストパーティション２４、２６、２８からＩ／Ｏパーティション１６、１８へ渡されるのは、ゲスト（読み取り／書き込み）バッファのアドレスである。オペレーション中には、ゲストパーティション２４、２６、２８内の仮想チャネルドライバは、ゲストＯＳからパーティションの相対的な物理アドレスを入手するか、あるいはシステムコールインターフェース３２を使用して、ゲストモニタ３６から物理アドレスを入手し、共通のＩ／Ｏの物理的なハードウェアへのアクセスを要求したそれぞれのメモリチャネル４８を通じて、それらのアドレスをＩ／Ｏパーティション１６、１８へ渡す。その一方でＩ／Ｏパーティション１６、１８は、システムコールインターフェース３２を使用してＩ／Ｏモニタ３６を参照し、パーティションの相対的なアドレスをプラットフォームの物理アドレスに変換するか、あるいはＩ／Ｏリソースを要求しているクライアントからメモリチャネル４８を通じて提供されたアドレスを検証することができる。
【０２０５】
外部Ｉ／Ｏ
図１０に示されているように、外部Ｉ／Ｏは、ゲストパーティションから直接インテリジェントＩ／Ｏアダプタ７２へのデータ接続７４を使用して達成される。図１０においては、これは、「Ｉ／Ｏｂ」パーティション１８のアダプタ内に示されている。Ｉ／Ｏパーティション１６、１８を通るパスは、共有されているアダプタとの接続をセットアップ／解消するために使用される。
【０２０６】
典型的な通信パスは、クライアントパーティションとインテリジェントＩ／Ｏハードウェア７２の間における特別な直接のチャネル７４である。これは、モニタ３６へのコンテキストの切り替え、あるいはＩ／Ｏパーティション１８のコンテキストの切り替えを必要としない。しかしコンテキストの切り替えは、典型的なＯＳのカーネルによって必要とされる可能性がある。この手法は、Ｉ／Ｏパーティション１６、１８およびプロセッササイクルの要求によって処理される割り込みを制限する。この構成においては、Ｉ／Ｏパーティション１６、１８は、通常では物理的なプロセッサの必要な部分のみを割り当てられる。
【０２０７】
Ｉ／Ｏパーティションのコンポーネント
２つのＩ／Ｏ仮想パーティション１６、１８は、ユーザパーティション２４、２６、２８用の独立した仮想メモリチャネル４８を介してマルチパスＩ／Ｏを提供する。ネットワークインターフェースおよびストレージインターフェースは、それらの間で分担される。これによって、万一Ｉ／Ｏパーティション１６、１８に障害が生じた場合の修復時間が最小限に抑えられる。これは、他方のＩ／Ｏパーティション１６、１８によって供給されるチャネルにすぐにフェイルオーバできるためである。障害が生じたＩ／Ｏパーティション１６、１８を修復することができ、パフォーマンスが最適になるようにＩ／Ｏパスを再配分することができる。もちろん、高い帯域幅が必要となる環境に関しては、３つ以上のＩ／Ｏパーティション１６、１８も可能である。信頼性が必要とされないテスト環境に関しては、単一のＩ／Ｏパーティション１６で十分である。
【０２０８】
仮想コンソールは、パーティションメンテナンスコンソール用のＫＶＭ（ｋｅｙｂｏａｒｄ／ｖｉｄｅｏ／ｍｏｕｓｅ）を提供する。Ｗｉｎｄｏｗｓ（登録商標）に関しては、Ｒｅｍｏｔｅ  Ｄｅｓｋｔｏｐが、主要なオペレーションコンソールを提供することができる。リモートコンソールは、コンソールサーバパーティション内で実行されているコンソールチャネルサーバとＴＣＰスタックによって提供される。このサーバは、一方のＩ／Ｏパーティション１６、１８内でホストすることができる。いかなる非アイソクロナスのデバイスも、リモートとすることができる。仮想ＵＳＢは、場合によってはコンソールキーボードとマウスのための実装を提供することができる。
【０２０９】
ビデオの実装は、ＥＦＩ  ＵＧＡの実装を介して提供することができる。しかしＷｉｎｄｏｗｓ（登録商標）は、これをサポートすることはできない。
【０２１０】
仮想ネットワークサービスは、ＩＰｖ６ベースのネットワークとＩＰｖ４ベースのネットワークの双方を提供すべきである。（１６バイトのアドレスを有する）ＩＰｖ６ネイティブの実装がＩＰｖ４と相互運用して提供されることが好ましい。ネットワークコンポーネントは、ＮＩＣ（ｎｅｔｗｏｒｋ  ｉｎｔｅｒｆａｃｅ  ｃａｒｄ）用の、ネットワークタイプのウルトラバイザメモリチャネルの実装を提供する。
【０２１１】
Ｉ／Ｏパーティションドライバの実装は、１つまたは２つのハードウェアＮＩＣデバイス用に制限される。現在Ｗｉｎｄｏｗｓ（登録商標）データセンタープログラムによってサポートされているアダプタを使用することができる。
【０２１２】
ネットワークの実装は、統合された仮想イーサネット（登録商標）スイッチを提供する。仮想ファイアウォールの実装は、Ｌｉｎｕｘファイアウォールを仮想パーティション内で実行されるように構成することによって提供することができる。
【０２１３】
仮想ストレージサービスは、仮想パーティション用のＳＡＮストレージを提供し、ＨＢＡ、ｉＳＣＳＩ、および／またはＦＣのストレージタイプのウルトラバイザメモリチャネルの実装を提供する。Ｗｉｎｄｏｗｓ（登録商標）のｉＳＣＳＩイニシエータは、ネットワークスタック上で実行することができるため、別個のストレージチャネルは、まったく不要というわけではない。
【０２１４】
ネットワークサービスと同様の方法で、Ｉ／Ｏパーティションドライバの実装は、１つまたは２つのハードウェアＨＢＡデバイス用に制限される。同様に、現在Ｗｉｎｄｏｗｓ（登録商標）データセンタープログラムによってサポートされているアダプタを使用することができる。
【０２１５】
ＩＶ．複数のノードにわたる仮想化
ゾーン
ウルトラバイザゾーンは、相互接続されたリソースの集合体である。模範的な一実施形態においては、ゾーンは、ネットワークが目に見える形で表示されたものである。ネットワークの詳細は、ネットワーク管理製品に委ねられる。複数の標準的なゾーンのタイプは、ウルトラバイザパーティション１４によって提供される。これらは、前述のウルトラバイザチャネルのタイプに対応する。ウルトラバイザのアドインは、さらなるゾーンタイプを定義することができ、ウルトラバイザの管理者は、ホストリソースの任意のカテゴリー化のためにさらなるゾーンタイプを定義することができる。これらを使用して、たとえば事業単位あるいは部署ごとにリソースを分離することができる。
【０２１６】
ゲストパーティション２４、２６、２８は、自らが必要とするリソースゾーンに関連付けられる。ホスト１０は、自らが提供するリソースゾーンに関連付けられる。オペレーションズサービス５６は、ゲストをホストに、それらが共有するゾーンを通じて、マッチさせる。
【０２１７】
ネットワークのパーティションは、ネットワークゾーンと呼ばれる。このゾーンは、通信（イーサネット（登録商標））、ストレージ（ＳＡＮ）、パワーなどのためのネットワークへのリソースの割り当ての単位である。その他のリソースを記述するためのゾーンを有する論理的なネットワークは、たとえば、すべてのパーティションによって共有できるモニタコンポーネントおよびファームウェアコンポーネントを含むことができる。しかし実際には、どのパーティションが特定のモニタあるいはファームウェアの実装を共有すべきかを記述することが必要である。さらに別のメカニズムを定義するよりも、論理的なネットワークゾーンをこれらの次元にも適用する方がよりシンプルでより強力である。ホスト１０は、論理的なファームウェアゾーンを特定のファームウェアの実装にマップする。このゾーンを参照するファームウェアチャネルを指定するゲストパーティション２４、２６、２８は、この実装を使用することになる。これは、任意の複雑なコンポーネントライフサイクルパターンをモデル化することを可能にし、単一の実装の単一のバージョンのみが利用可能である平凡なインストールへとさらにスケールダウンする。
【０２１８】
ネットワークゾーンは、データのパケットを交換することができるネットワークギア（スイッチ／ルータ／ケーブル）の集合体である。別々のゾーンは、それらを接続するためのゲートウェイまたはファイアウォールを有する場合もあり有さない場合ある。所与のゾーンに接続されているホストは、何らかのネームスペース内に１つの名前を有する。通常は、ホスト名用のネームスペースとしてＤＮＳ（Ｄｏｍａｉｎ  Ｎａｍｅ  Ｓｙｓｔｅｍ）が使用される。所与のゾーン上のホストがすべて同じＤＮＳサフィックスを共有する（あるいは同じＤＮＳサフィックスを共有しない）必要性はない。ドメインおよびゾーンは問題のスペースの独立した次元であること、ドメインは物のためのネームスペースを提供し、その一方でゾーンは有線接続される物のセットを表すことを当業者なら理解されよう。ゾーンは、パワー接続ならびにメモリおよびプロセッサ機能を記述することもできる。
【０２１９】
ドメイン
ウルトラバイザドメインは、その他のすべてのオブジェクト用のネームスペースを定義し、パーティションオブジェクトおよびゾーンオブジェクト用のコンテナおよびネームスペース（ネットワークの組織）を提供する。図１１に示されているように、１つのドメインは、システム（インフラストラクチャ）パーティションを含み、このシステム（インフラストラクチャ）パーティションは、所与のホストシステム１０内のその他のパーティションによって使用されるＩ／Ｏサービスおよびオペレーションズサービスを実装する。各ホストシステム１０は、オペレーションズパーティション２２内のポリシーサービスによって管理されるシステムドメインの部分的なレプリカである１つの専用のシステムドメインを有する。システムドメインは、ウルトラバイザパーティション１４がホストシステム１０内にインストールされるたびに作成／選択される。ホストクラスタおよびそれに対応するパーティションが、システムドメイン内に作成され、ホストに固有のレプリカへとコピーされる。
【０２２０】
２つの異なったタイプのドメインが存在する。パーティション／ユーザドメイン（パーティション２４〜２８）、およびシステムドメイン（パーティション１２〜２２）である。システムドメインは、多くのホストパーティションを（対応するコマンド／ＩＯパーティションと共に）含むことができる。パーティション／ユーザドメインは、仮想パーティションのポリシーおよび構成用のアクティブなリポジトリである。パーティション／ユーザドメインのパーティションおよびシステムの変形形態は、それぞれユーザパーティションおよびシステムインフラストラクチャパーティションを管理する。パーティション／ユーザドメインは、ユーザパーティション２４〜２８を含む。ウルトラバイザパーティション１４をインストールすると（そして仮想データセンタを作成すると）、結果として少なくとも１つのパーティション／ユーザドメインが作成される。管理者は、任意の時点でさらなるウルトラバイザパーティション／ユーザドメインを作成することができる。各パーティション／ユーザドメインは、潜在的なホストハードウェアパーティションを識別する１つまたは複数のシステムドメインに関連付けられている。その一方でシステムドメインは、システム（インフラストラクチャ）パーティションを含み、このシステム（インフラストラクチャ）パーティションは、所与のホストシステム１０内のその他のパーティションによって使用されるＩ／Ｏサービスおよびオペレーションズサービスを実装する。各ホストシステム１０は、標準あるいはカスタムのテンプレートのレプリカとすることができる１つの専用のシステムドメインを有する。
【０２２１】
オペレーションズパーティション２２内のポリシーサービス５６は、統合インターフェースにシステム管理ソフトウェアを提供する。これは、ＤＳＩ（ｄｙｎａｍｉｃ  ｓｙｓｔｅｍｓ  ｉｎｉｔｉａｔｉｖｅ）のＳＤＭ（ｓｙｓｔｅｍ  ｄｅｆｉｎｉｔｉｏｎ  ｍｏｄｅｌ）用のアダプタを含むことができる。スケーラビリティ、拡張性、およびセキュリティの理由から、パーティションポリシーは、独立したウルトラバイザドメインの集合体へと編成されることが好ましい。
【０２２２】
ドメインは、ウルトラバイザオペレーションズモデルにおける主要なコンテナオブジェクトである。各パーティションは、厳密に１つのドメインのメンバーである。ドメインは、命名、オペレーション、およびセキュリティの境界用に有用である。ドメインは、その他のコンテキスト（すなわちＤＮＳ、アクティブディレクトリなど）において一般的であるが、ウルトラバイザパーティション１４用の本来のコンテナでもある。各ウルトラバイザドメインは、ＤＮＳのドメイン名またはエイリアスに直接、あるいはアクティブディレクトリのドメインを通じて間接的に関連付けることができる。
【０２２３】
ウルトラバイザドメインは、１つのドメイン内の排他的なメンバーシップに基づいてパーティションを部分的に制限することによって個々のパーティションのポリシーを単純化するために使用される。次いで特定のオペレーショナルパラメータが、それぞれのドメインごとに１回指定される。パーティションは、必要に応じて時おりドメイン間で移動することができる。
【０２２４】
構成データベースは、各ドメインごとのシンプルなサブフォルダを有するそれぞれのポリシーサービスインスタンスごとのファイルフォルダツリーとして、オペレーションズパーティション２２内に実装することができる。各ドメインフォルダは、それぞれのパーティションごとに１つのＸＭＬファイルを含む。複数のポリシーサービス５６は、相互にやり取りして、お互いのためにドメインのバックアップコピーを自動的に作成することができる。各ドメインは、独立してデータベースの実装に割り当てられる。データベースの実装は、１つまたは複数のドメイン用のデータストアを提供する。
【０２２５】
ドメインは、ソフトウェアパーティションおよびそれらの構成のための持続性コンテナを定義する。ウルトラバイザパーティション１４がホストシステム１０内にインストールされる際に、１つまたは複数の既存のウルトラバイザドメインを識別することができる。これが第１のウルトラバイザパーティション１４である場合、ドメインウィザードは、第１のドメインを構成する際に管理者を補助する。ハードウェアパーティションシステムドメインに関する持続性は、ＤＡＳ（ｄｉｒｅｃｔｌｙ  ａｔｔａｃｈｅｄ  ｓｔｏｒａｇｅ）とすることもでき、あるいは１つのデータベースを、ホストされているドメインのいずれかと共有することもできる。これらのオブジェクトは、アクティブディレクトリのドメインあるいは組織単位のオブジェクトに関連付けることができる。
【０２２６】
サイトオブジェクトは、ドメインを仮想データセンタへと編成する上で有用であるが、ドメインは、通常では単一のサイトに限定される。
【０２２７】
ネットワークゾーンオブジェクトは、パーティションの相互接続されているセットを定義する。ウルトラバイザパーティション１４は、パーティションがアクティブにされる際に、必要に応じてソフトウェアイーサネット（登録商標）スイッチ、ルータ、およびファイアウォールをインスタンス化することができる。ハードウェアパーティションは、ホストされているドメインによって識別されるすべてのネットワークゾーンをサポートするために必要とされるコンポーネントを事前にロードすることができる。複数のホストハードウェアパーティションを伴う構成は、通常、別々のハードウェアパーティション内の別々のドメインをホストする。
【０２２８】
パーティションの構成は、ネットワークゾーンオブジェクトに関連付けられている利用可能なネットワークチャネルを含むその構成の限界を定義する。仮想パーティションは、１つまたは複数の構成を記述する。個々の構成は、必要に応じてチャネルを無効にし、特定のデフォルトの構成アイテムを無効にすることができる。
【０２２９】
ホストシステム１０は、オブジェクトモデル内において明示的である。そのドメインは、１つまたは複数のホストパーティションに関連付けられている。複数のホストパーティションが１つのドメインに関連付けられており、パーティションがＳＡＮストレージを使用する場合には、ポリシーは、１つのパーティションをアクティブにするために使用されるホスト１０を確定する。
【０２３０】
Ｗｉｎｄｏｗｓ（登録商標）のサーバクラスタおよびネットワークロードバランシングクラスタの個々のノードは、仮想パーティションとすることができる。パーティションクラスタは、複数のホストパーティションにわたることもでき（サーバクラスタ用のデフォルト）、または１つのホストパーティション内に含まれることもでき（中程度に堅固なロードバランシングクラスタ）、あるいは１つのホスト１０内に複数のノードを有して、やはり複数のホストパーティションにわたることもできる。１つのロードバランシングクラスタは、２つのホストパーティションに関連付けることができ、そのノードの半数は、それぞれによってホストされる。これによって、クラスタは、それぞれのプロセッサの利用を最大限に高めつつ、ホストパーティション内の障害を切り抜けることができる。必要に応じてクラスタノードの最大数に達するように追加のホストパーティションを構成することができる。
【０２３１】
チャネルは、タイプに固有の構成情報を保持する。ネットワークチャネルは、ネットワークゾーンオブジェクトと共に双方向の参照を保持する。
【０２３２】
図１１は、４つのホストハードウェアシステム１０ａ、１０ｂ、１０ｃ、および１０ｄを示すベン図である。これらのホストハードウェアシステム１０のそれぞれは、対応するシステムドメイン７６０ａ、７６ｂ、７６ｃ、７６ｄにそれぞれ関連付けられている。そしてシステムドメイン７６は、３つのパーティションドメイン７８、８０、および８２に関連付けられている。「ミッションクリティカル」パーティションドメイン８２内の仮想パーティション８４は、図示されているように、ホストハードウェアシステム１０ｃあるいは１０ｄの２つの上で実行できるようにクラスタ化されている。「実稼働（ｐｒｏｄｕｃｔｉｏｎ）」ドメイン８０内の仮想パーティション８６も、他の２つのホストハードウェアシステム１０ａあるいは１０ｂの上で実行できるようにクラスタ化されている。「テスト」ドメイン７８内の仮想パーティション８８は、実稼働ホストのうちの１つ（１０ａ）の中でのみ実行することができ、ミッションクリティカルなタスクに割り当てられているホスト（１０ｃおよび１０ｄ）内で実行されることはない。したがって図１１においては、テストクラスタが、単一のホストハードウェアシステム１０ａ内で実行されており、その一方で仮想クラスタのその他のノードは、別のホストハードウェアシステム１０内で実行することができる。
【０２３３】
本発明のウルトラバイザシステムのコンテキストにおいては、ウルトラバイザアクティブオブジェクトモデルのキーコンポーネントとしてパーティションエージェントが提供され、それらのエージェントは、イベントをモニタし、パーティションポリシーに基づいてパーティションにとって最大の利益になるように行動することによって、動作の拡張性を提供する。パーティションエージェントは、ポリシーの管理は担当しないが、イベントに関して動作している際にはポリシーを参照する。パーティションエージェントを追加することによって、洗練された動作を追加することができる。
【０２３４】
パーティションエージェントは、ユーザインターフェースの（劇的な）簡略化を可能にする組込みの専門技術を提供する。このエージェントは、管理者のアクションに対するインテリジェントな制約を提供する。パーティションのタイプは、必要なリソースを求めて交渉する（やり取りする）エージェントを定義する。これらのエージェントは、ＥｎｔｅｒｐｒｉｓｅＳｅｒｖｅｒ．Ｐａｒｔｉｔｉｏｎネームスペース内のＥｎｔｅｒｐｒｉｓｅＳｅｒｖｅｒ．Ｐａｒｔｉｔｉｏｎ．Ａｇｅｎｔクラスから導出される．ＮＥＴフレームワーククラスとして実装することができる。
【０２３５】
ドメイン／パーティションという２つの範囲およびポリシー／リソースという２つのコンテキストから生じるパーティションエージェントタイプの４つの基本的な組合せがある。リソースエージェント６０は、ハードウェアリソースの実際の割り当てを担当する。ポリシーエージェント（ｐｏｌｉｃｙ  ａｇｅｎｔｓ）６２は、構成を管理して、どのリソースエージェント６０がそれらの代理を務めるかを選択することを補助する。
【０２３６】
ポリシーサービス５６は、ホスト１０に関連付けられているアダプタを使用して、その他のコンポーネントに接続することができる。それぞれのリソースサービス５２は、対応するリソースアダプタを有し、このリソースアダプタは、リソースの要求を適切なリソースサービスの要求上にマップする。ポリシーサービス５６は、アダプタアセンブリを名指ししてロードし、アクティベータインターフェースを使用してアダプタインスタンスを作成する。
【０２３７】
ドメインポリシーは、ドメイン内のパーティションに対して個別におよび全体として適用される。鍵となる属性は、ドメイン内におけるパーティションの重要度、最大の応答性要件、ならびにドメイン内のパーティションによって分割される指定されたホストのリソースの保証および制限である。これらの属性に関する潜在的な値は、下記のものを含む。
重要度：（ミッションクリティカル／実稼働／テスト／開発）；
応答性：（インフラストラクチャ、対話性、対話型トランザクション、バッチトランザクション、バッチ処理）；および
ホストパーティション：関連付けられているリソースの保証および制限を伴って、利用可能でありそうすることが好ましい。
【０２３８】
ドメインポリシーは、リソースの利用の優先順位を決定するためにドメインエージェントによって使用される。相対的な重要度は、主に、複数のドメインが１つのホストハードウェアパーティションを共有する場合の関心事である。たとえば１つのホスト１０を開発ドメインの専用にすると、ホストハードウェアは開発パーティションの専用になる。
【０２３９】
ドメインエージェントには、２つの基本的なカテゴリー、すなわちドメインリソースエージェントおよびドメインポリシーエージェントがある。それぞれのドメインタイプは、対応するエージェントを有する。ドメインポリシーエージェントは、その仮想パーティションのための適切なホストハードウェアパーティションを選択する。これは、ポリシーエージェントがそのホストに割り当てるそれぞれのパーティションのために、対応するドメインリソースエージェントに実質的に協力を求める。ドメインリソースエージェントは、実際のハードウェアリソースを割り当てる。これは、仮想コンテキストの切り替えの堅牢性およびパフォーマンスに焦点を合わせるために、低いレベルのインフラストラクチャコードを簡略化する。パーティションドメインエージェントの主要なタスクは、関連付けられているシステムドメインエージェントと連絡を取ることであり、そしてそのシステムドメインエージェントは、ゲストパーティションの、要求されているリソースゾーンを、その要求されているリソースゾーンのすべてを有するホスト１０にマッチさせる。
【０２４０】
ドメインエージェントは、パーティションエージェントにサービスを提供する。これらのサービスには、適切なホストパーティションを選択すること、および対応するリソースエージェントとやり取りすることが含まれる。ウルトラバイザパーティション１４の自動処理の多くは、これらのエージェントの対話によって処理される。ドメインは、実際のリソースの利用の「データベース」を保持する。これは、ドメインおよびパーティションポリシーによって認められている範囲内におけるリソースに対するニーズの予測材料としてドメインエージェントによって使用される。予想されたリソースに対するニーズを使用して、リソースのリース（ｌｅａｓｅ）が確立される。これらのリースによって、エージェントは、今後のリソースに対するニーズを満たすように交渉することができ、仮想パーティションの移動を事前にスケジュールすることができる。これは、ホストパーティションの稼働率を自動的に高く維持できるようにする上で鍵となる。
【０２４１】
パーティションポリシー５６は、個々のパーティションに適用される。これは、ドメインポリシーに従属する。たとえばホスト１０は、たとえドメイン内の個々のパーティションを不公平に扱っている場合でも、ドメインのリソースの使用を制限することになる。ドメインの割り当てられているリソースの限界内でリソースをホストパーティションに割り当てることによって、そのパーティションをリソースの欠乏から保護することは、ドメインポリシーエージェントの責任である。
【０２４２】
たとえばパーティションポリシーの属性は、下記のものを含むことができる。
最小／最大のプロセッサ（ｎ分ごとに取り込まれるサイクル）、
最小／最大のメモリ（予約済みの返還）、
チャネルＩ／Ｏ要求速度（確保／取り込み）、
チャネルＩ／Ｏ帯域幅（確保／取り込み）、および
パーティションの相対的な優先順位。
【０２４３】
ウルトラバイザパーティションエージェントは、１つのパーティションのオペレーション上のニーズに焦点を合わせるウルトラバイザ「コンポーネント」である。ウルトラバイザオペレーションズパーティション２２は、これらのエージェントの集合体を管理して、仮想データセンタ内に実装されている場合のパーティションのオペレーションに影響を与える。パーティションエージェントには、２つの基本的なカテゴリー、すなわちリソースエージェントおよびポリシーエージェントがある。それぞれのカテゴリーには、少なくとも１つのエージェントタイプが存在する。オペレーションズフレームワークは、拡張可能であり、これらのカテゴリーに新しいタイプを追加することができる。パーティションの代理を務めるエージェントのタイプは、新しいパーティションが作成される際に選択される属性の１つである。
【０２４４】
ウルトラバイザリソースサービス５２は、パーティションのためのリソースエージェントをホストする。パーティションに割り当てられているポリシーに基づいてパーティションリソースを求めて交渉を行うために、シンプルなエージェントが使用される。アクティブなリソースエージェントを有するパーティションは、アクティブであると言われる。アクティブなおよび非アクティブなパーティションの状態は、リソースエージェントに関連付けられている。
【０２４５】
ポリシーサービス５６は、パーティションポリシーエージェントをホストする。サービス５６は、通常、ユーザパーティション２４、２６、２８のためにオペレーションズパーティション２２によってホストされる。初歩的な単一のホストパーティションのインストールの場合、サービス５６は、コストを最小限に抑えるためにコマンドパーティション２０によってホストすることができる。このサービスは、ウルトラバイザインフラストラクチャパーティションのためにコマンドパーティション２０によって常にホストされる。これらのエージェントは、リソースエージェントをアクティブにするためにホストシステム１０と交渉し、そしてパーティションがアクティブである間にリソースエージェント６０が必要とする構成およびポリシーを提供することによって、リソースエージェント６０と連携する。パーティションのライフサイクルステージは、ポリシーエージェント６２に関連付けられている。アクティブなポリシーエージェント６２を有するパーティションは、動作中と呼ばれる。これらのエージェント６２は、シンプルなパートタイムのパーティションを管理することができる。このエージェントは、スケジューリング要求を追跡監視し、必要に応じてリソースエージェント６０をアクティブにするようにホストシステム１０と交渉する。
【０２４６】
複数のホスト間におけるアクティブなパーティションの移行は、現在のリソースエージェントと代わりのリソースエージェントの間におけるネットワーク通信パスを調整して、ポリシーエージェント６２によって管理される。図１２は、進行中のパーティションの移行を示している。現在のパーティションがまだ実行されている間に、新しいパーティションが準備され、メモリページに対する最後の変更が転送されるまでスタンドバイ状態で待機する。
【０２４７】
図１２においては、オペレーションズパーティション２２内のオペレーションズ（ポリシー）サービス５６が、ＴＣＰソケットに接続されており、そこでは、コマンドパーティション２０内のリソースサービスがリッスンしている。オペレーションズパーティション２２およびコマンドパーティション２０は、双方とも１つのネットワークチャネルを通じて何らかのネットワークゾーンに接続されている。双方のパーティションが偶然にも同一のホスト１０内に存在する場合、物理的なネットワークは実際には通信にまったく関与していない。その一方でコマンドパーティション２０は、常にウルトラバイザパーティション１４と同じホスト１０内で実行され、特別なコマンドチャネル３８を使用して接続される。
【０２４８】
図１２においては、左上のアイテムは、左側のホスト１０ａのコマンドおよびＩ／Ｏパーティションをモニタしている。右上のアイテムは、右側のホスト１０ｂのコマンドパーティションおよびＩ／Ｏパーティションをモニタしている。図１２の中央上部のアイテムは、３つのパーティションを操作している任意のホスト上のオペレーションズサービス５６を示している。１つのパーティションは、左側のホスト１０ａ上でアクティブであり、そしてもう１つのパーティションは、右側のホスト１０ｂ上でアクティブである。第３のパーティションは、左側のホスト１０ａ上で現在アクティブであるが、右側のホスト１０ｂへのパーティションの移行が進行中である。
【０２４９】
図１２においては、オペレーションズパーティション２２は、移行のターゲットとなるホストを既に識別している。オペレーションズサービス５６は、そのターゲットにおけるリソースサービスと連絡を取り、必要なメモリリソースを有するパーティションを作成し、プロセッサのリソースを予約している。オペレーションズサービス５６は、ターゲットの移行サービスのＴＣＰアドレスをソースに提供することによって、ソースのリソースサービスとターゲットのリソースサービスを相互に導入している。クライアントの移行サービスは、メモリコンテンツをターゲットへ転送し、転送を開始した後に生じるメモリへの変更をモニタする。最小限の修正されたページが残ると、ソースパーティションは一時停止され、残っている修正されたページが転送される。チャネルは、ターゲットにおいて適切なゾーンに接続され、パーティションは、予約済みのプロセッサのリソースをスケジュールすることによって、ターゲットにおいて再開される。
【０２５０】
ウルトラバイザソフトウェアのワークロード管理アーキテクチャは、リソースの管理を簡略化し、その一方でホストハードウェアパーティションのより高い稼働率レベルを達成する。ウルトラバイザアーキテクチャはまた、３Ｄ−ＶＥモデルへのマッピングのためのメカニズムを提供し、ＭｉｃｒｏｓｏｆｔのＶｉｒｔｕａｌ  ＳｅｒｖｅｒおよびＶＭＷａｒｅのＥＳＸ仮想パーティションのオペレーションと統合するための単一のメカニズムを提供することもできる。またリソースの割り当ては、ＡＣＰＩの記述とオペレーティングシステムの実装だけに依存するわけではないので、プラットフォームハードウェアの革新のためのさらなる機会を利用することができる。
【０２５１】
３Ｄ−ＶＥの統合の場合、ウルトラバイザソフトウェアは、ビジネスポリシーを仮想パーティション用のリソースの割り当てに適用するためのメカニズムを提供しなければならない。ポリシーをビジネスレベルにおいて取り込んで管理できるようにするインターフェースを提供することが好ましい。ウルトラバイザアーキテクチャは、たとえば、それぞれの仮想パーティションあるいは仮想クラスタが単一のワークロードをサポートすると想定することによって、この統合を提供することが好ましい。インフラストラクチャ内のワークロードオブジェクトは、仮想パーティションへのワークロードの連結をモデル化することを可能にすることができる。仮想パーティション内のウルトラバイザ以外のコンポーネントは、仮想パーティション内のリソースの割り当てを管理および追跡監視する。ビジネスポリシーに基づいてリソースを割り当てることによって、優先順位がより低くあまり差し迫っていないニーズは、そのままであれば役に立たなくなるリソースを活用することができる（たとえば優先順位の低いアプリケーション用の仮想ハードウェアは、ほとんど「空いている」が、当然ながら依然としてパワーおよび冷却を必要とする）。
【０２５２】
図１３においては、Ｇ１〜Ｇ８は、ゲストパーティションを表しており、ＳＡＮ１  ９０、ＳＡＮ２  ９２は、ストレージエリアネットワークを表しており、ＤＡＳ２、ＤＡＳ３  ９４、９６は、それぞれのホストのダイレクトアタッチドストレージ（Ｄｉｒｅｃｔ  Ａｔｔａｃｈｅｄ  Ｓｔｏｒａｇｅ）を表しており、ＮＥＴ１、ＮＥＴ２  ９８、１００は、イーサネット（登録商標）ネットワークを表しており、Ｈ１〜Ｈ５は、ホストパーティション１０を表している。ホストＨ１は、ＳＡＮ１に接続されているＨＢＡと、ＮＥＴ１に接続されているＮＩＣとを有する。Ｈ４およびＨ５は、ＳＡＮ２に接続されているＨＢＡと、ＮＥＴ２に接続されているＮＩＣとを有する。Ｈ２は、Ｈ１のように接続されているが、ＮＥＴ２に接続されている追加のＮＩＣを有し、ゲストパーティションにとって利用可能な直接連結されたストレージボリュームを有する。Ｈ３はＨ２に類似しているが、当然ながらＤＡＳは別個である。
【０２５３】
Ｇ１、Ｇ２、Ｇ３は、ＳＡＮ１上のストレージボリュームおよびＮＥＴ１上の通信を必要とする。Ｇ６、Ｇ７、Ｇ８は、ＳＡＮ２上のストレージボリュームおよびＮＥＴ２上の通信を必要とする。Ｇ４およびＧ５は、ＮＥＴ１とＮＥＴ２を相互接続する相互に冗長な仮想ファイアウォールアプリケーションとすることができる。これらは、それぞれＤＡＳ２とＤＡＳ３上にストレージボリュームを有し、それによって、これらのそれぞれを単一のホストに制限する（これらのストレージボリュームは、ＳＡＮ１に移動することができる）。
【０２５４】
図１３に示されているように、Ｇ１、Ｇ２、Ｇ３は、Ｈ１またはＨ２のいずれかの上で実行することができ、Ｇ６、Ｇ７、Ｇ８は、Ｈ４またはＨ５のいずれかの上で実行することができる（ゾーンに関連付けられているホストの属性は、ＳＡＮおよびＮＥＴの接続が冗長パスを有するかどうかを識別する。おそらくはＳＡＮおよびＮＥＴのインフラストラクチャも、冗長コンポーネントを有する）。
【０２５５】
物理的な表示が単純に１つのウルトラバイザソフトウェアコンポーネントであるゾーンタイプもある。たとえば、｛ファームウェア（Ｆｉｒｍｗａｒｅ），モニタ（Ｍｏｎｉｔｏｒ）｝がある。これらのゾーンによって、ホストパーティションは、どのファームウェアおよびモニタの実装が利用可能であるかを識別することができ、ゲストパーティションは、コンポーネントの要件あるいは好みを識別することができる。物理的な表示をまったく有さないゾーンタイプもある。たとえば、｛パワー（Ｐｏｗｅｒ），プロセッサ（Ｐｒｏｃｅｓｓｏｒ），メモリ（Ｍｅｍｏｒｙ）｝である。これらを使用して、ホストパーティションおよびゲストパーティションの任意に抽象的で利用可能な望ましい機能を記述することができる。パワーゾーンによって、ゲストパーティションは、特定のホストパワーソースを指定することができる。プロセッサゾーンおよびメモリゾーンによって、不均一なホストの集合体を有するデータセンタは、プロセッサおよびメモリのパフォーマンス特性を抽象的に記述することができる。これによって、最も高いプロセッサに対する需要を有するゲストを、最も速いホストプロセッサに関連付けることができ、最も大きいメモリスループットに対する需要を有するゲストを、最も速いメモリサブシステムを有するホストに関連付けることができる。
【０２５６】
カーディナリティパラメータを無視する簡略化されたゾーンマッチング機能が、以下に提示されている（これは、図１３におけるＧ１〜Ｇ３用のＨ１／Ｈ２およびＧ５〜Ｇ８用のＨ４／Ｈ５を自動的に選択する上で十分である）。この機能は、任意選択のゾーンを識別するシンプルなルールを使用して精緻化することができ、ゾーンの優先のランク付けを可能にすることができる。オペレーションズサービスは、必要とされるゾーンのすべてを提供できる１つのホストを選択するために、利用可能なホストについてこの機能を評価する。
【０２５７】
仮想データセンタ
図１および２のシステムの典型的な一実装形態においては、ウルトラバイザアプリケーションおよびハイパーバイザシステムコールインターフェースソフトウェアが、ＥＳ７０００ホストシステムの論理的なまたは仮想のパーティション内で実行されている複数のオペレーティングシステムを管理するためにホストシステム１０上にロードされる。このような複数のホストシステム１０は、複数のノードにわたってウルトラバイザ管理機能を拡張することを通じて、仮想データセンタとして相互接続することができる。本明細書に記載されているウルトラバイザシステムの目的は、利用可能なハードウェアリソースを多くの分離された仮想システムへとフレキシブルにパーティションで区切り直すことを提供することである。そのように構成されているため、本発明のウルトラバイザシステムは、仮想パーティションを、それぞれのホストハードウェアパーティション上で、物理的なサーバのオペレーションと同じぐらい自然で直観的な方法で操作する。本発明によるこのような仮想データセンタによって、大きなシステムの複合体内で革新が可能になり、巨大なサーバが、標準的なデータセンタインターフェースおよびプロトコルを介してその他のデータセンタコンポーネントと対話できるようになる。したがって仮想データセンタによって、リソースの稼働率を最大限に高めることができ、「市販の」プロセッサおよびメモリから構築された巨大なサーバに、市販のサーバおよびブレードサーバに対するコスト競争力を持たせることができる。
【０２５８】
ウルトラバイザソフトウェアは、複数のホストハードウェアパーティション間における仮想パーティションの自動的なリソースの割り当てを提供する。基本的なリソースの使用に関する指標を取り込むことによって、仮想パーティションのワーキングセットを、利用可能なホストハードウェアパーティションのそれぞれに割り当てることができる。最適な割り当ては複雑だが、基本的なメモリ、プロセッサ、および入出力（Ｉ／Ｏ）の利用履歴の適用を通じて、十分に良好な割り当てを達成することができる。
【０２５９】
仮想サーバを仮想データセンタへ連結することを介して、アプリケーションの連結を達成することもできる。これによって、パーティション内における連結は、セキュリティおよび障害の分離の境界に焦点を合わせることができる。仮想データセンタのスケールにおいては、仮想パーティション（あるいは仮想サーバ）は、ラックマウント式のあるいはブレードパッケージ式のサーバとまったく同じぐらい自然である。自然なオペレーションを提供するために、仮想データセンタの設計は、物理的なコンピュータシステムの動作、あるいはデータセンタラック内の物理的なブレードに基づく。これは、仮想データセンタの設計内に鍵となる抽象化を必要とする。たとえば、広々としたネットワークのクローゼット内のどこかにあるいくつかのラックを考えていただきたい。「ストレージ」ラックは、ＪＢＯＤアレイ、ストレージスイッチ、およびＳＡＮストレージ用の関連したコンポーネントを含む。「ネットワーク」ラックは、企業ネットワークとの相互接続用のさまざまなイーサネット（登録商標）スイッチを含む。「サーバ」ラックは、大規模な企業システムの１つまたは複数のセルを含む。これらのセルのうちの少なくともいくつかは、ＳＡＮおよび通信ネットワークに相互接続するＩ／Ｏハードウェアを含む。これらのラックのコンテンツが、仮想データセンタを構成する。
【０２６０】
仮想データセンタは、仮想ＮＩＣによって相互に、そして仮想ＨＢＡによってストレージと相互接続されている（仮想）パーティションの複数の集合体を有する。新しい（仮想）パーティションは、パーティションテンプレートを複製することによって容易に作成することができる。サーバラック内のユニットは、ＨＢＡおよびＮＩＣを有し、ストレージラックおよびネットワークラック内のスイッチに接続されている。
【０２６１】
アプリケーションの展開は、２ステップのプロセスであり、その第１のステップは、複数のアプリケーションによって共有することができる。この第１のステップは、データセンタインフラストラクチャを（この場合は、ウルトラバイザに対して）定義することである。これは最初に、エンタープライズサーバに接続されている通信ネットワークおよびストレージネットワークを識別することを含む。複数のネットワークゾーンをサーバに接続することができ、あるいは１つのバックボーンを物理的な相互接続とすることもでき、これは、ＩＰＳＥＣおよびＶＰＮテクノロジーを介して仮想ネットワークゾーンを提供する。次いでアプリケーションの展開は、ウルトラバイザパーティション１４を介して展開されているコンポーネントへのマッピングを含む。キーコンポーネントは、仮想パーティション、仮想ＨＢＡ、およびそれらが含む仮想ＮＩＣインスタンスである。それぞれの仮想ＮＩＣインスタンスは、事前に定義された仮想ネットワークゾーンにマップされる。典型的なインストールにおいては、それぞれの仮想ＨＢＡは、ＳＡＮテクノロジーを介して提供されるＳＡＮ「ファブリック」（ゾーン）にマップされる。
【０２６２】
図４は、データセンタのシンプルな単一のホストのビューを示している。この実施形態においては、パーティションの最も下の端に示されているモニタインスタンスは、ウルトラバイザパーティション１４内のそれらのパーティション記述子５８に対する読み取り専用のアクセスを有する。オペレーションズパーティション２２内の（ポリシー）オペレーションズサービス５６と、コマンドパーティション２０内のリソースサービス５２は、イーサネット（登録商標）相互接続５４上の認証され保護された「ウェブサービス」インターフェースを介して通信する。これによって、少数のオペレーションズパーティション２２が、関連付けられているコマンドパーティション２０のリソースサービスを通じて多数のホスト１０を管理することができる。オペレーションズサービス５６は、オペレーションズパーティションおよびコマンドパーティション２０が同じネットワークゾーンに接続されているかを確認する。
【０２６３】
図１４は、本発明に従って実装される複数のホストデータセンタを示している。この構成においては、オペレーションズパーティション２２内で実行される分散型のオペレーションズサービスが、適切なホストハードウェアパーティションを選択する。この分散型のサービスは、フェイルオーバを実行することができ、ロードバランシングを実施することができる。図１４においては、上位のホスト内のオペレーションズサービスが、Ｘ、Ｙ、Ｚを操作しており、下位のホスト上でＹをホストしている。下位のホスト内のオペレーションズサービスが、Ａ、Ｂ、Ｃを操作しており、上位のホスト上でＢをホストしている。
【０２６４】
オペレーションズサービスは、ゲストをホストに、それらの関連付けられているリソースゾーンを通じてマッチさせる。たとえばイーサネット（登録商標）ネットワークは、複数のゾーンへと分割され、それぞれのゾーンは、ウルトラバイザオペレーションズモデル内の１つのオブジェクトを介して識別される。ホスト１０は、Ｉ／Ｏアダプタが物理的に接続されているゾーンに関連付けられている。ゲストパーティション２４、２６、２８は、パーティションがアクセスを必要とするゾーンに関連付けられている。オペレーションズサービス５６は、ゲストパーティションを、利用可能なゾーンを有するホストにマッチさせる。
【０２６５】
ゾーンは、通信ネットワークに限定されない。ネットワーク（Ｎｅｔｗｏｒｋ）、ストレージ（Ｓｔｏｒａｇｅ）、コンソール（Ｃｏｎｓｏｌｅ）、ファームウェア（Ｆｉｒｍｗａｒｅ）、モニタ（Ｍｏｎｉｔｏｒ）、パワー（Ｐｏｗｅｒ）、プロセッサ（Ｐｒｏｃｅｓｓｏｒ）、およびメモリ（Ｍｅｍｏｒｙ）を含むさまざまなゾーンタイプが存在する。「ＤＡＳ」（Ｄｉｒｅｃｔ  Ａｔｔａｃｈｅｄ  Ｓｔｏｒａｇｅ）ゾーンは、定義によって単一のホスト１０に関連付けられている。このタイプのストレージゾーンを参照するゲストパーティション２４、２６、２８は、連結されているディスクを含むホスト１０に制限され、ホスト１０に直接接続されているストレージボリュームにアクセスすることができる。「ＳＡＮ」（Ｓｔｏｒａｇｅ  Ａｒｅａ  Ｎｅｔｗｏｒｋ）ゾーンは、識別されたファイバチャネル、インフィニバンド（Ｉｎｆｉｎｉｂａｎｄ）、あるいはｉＳＣＳＩストレージネットワークに接続されているすべてのホスト１０に関連付けられている。このタイプのゾーンを参照するゲストパーティション２４、２６、２８は、そのゾーンへの接続を有するホスト１０のいずれかによってホストすることができる。
【０２６６】
物理的な表示が単純に１つのウルトラバイザソフトウェアコンポーネントであるゾーンタイプもある。たとえば、｛ファームウェア（Ｆｉｒｍｗａｒｅ），モニタ（Ｍｏｎｉｔｏｒ）｝がある。これらのゾーンによって、ホスト１０は、どのファームウェアおよびモニタの実装が利用可能であるかを識別することができ、ゲストパーティション２４、２６、２８は、コンポーネントの要件あるいは優先を識別することができる。物理的な表示をまったく有さないゾーンタイプもある。たとえば、｛パワー（Ｐｏｗｅｒ），プロセッサ（Ｐｒｏｃｅｓｓｏｒ），メモリ（Ｍｅｍｏｒｙ）｝がある。これらを使用して、ホスト１０およびゲストパーティション２４、２６、２８の任意に抽象的で利用可能な望ましい機能を記述することができる。パワー（Ｐｏｗｅｒ）ゾーンによって、ゲストパーティションは、特定のホストパワーソースを指定することができる。プロセッサ（Ｐｒｏｃｅｓｓｏｒ）ゾーンおよびメモリ（Ｍｅｍｏｒｙ）ゾーンによって、不均一なホストの集合体を有するデータセンタは、プロセッサおよびメモリのパフォーマンス特性を抽象的に記述することができる。これによって、最も高いプロセッサに対する需要を有するゲストを、最も速いホストプロセッサに関連付けることができ、最も大きいメモリスループットに対する需要を有するゲストを、最も速いメモリサブシステムを有するホストに関連付けることができる。
【０２６７】
カーディナリティパラメータを無視する簡略化されたゾーンマッチング機能が、以下に提示されている。これは、任意選択のゾーンを識別するシンプルなルールを使用して精緻化することができ、ゾーンの優先のランク付けを可能にすることができる。オペレーションズサービスは、必要とされるゾーンのすべてを提供できる１つのホストを選択するために、利用可能なホストについてこの機能を評価する。
【０２６８】
Private Function ChannelZonesAvailable_
(ByVal guest As IPartitionDefinition, ByVal host As IPartitionDefinition)_
As Boolean
Dim c As Integer
Dim z As Integer
Dim GuestChannel As IPartitionChannel
Dim HostChannel As IPartitionChannel
Dim ZoneFound As Boolean
For c = 1 To guest.ChannelCount
GuestChannel = guest.Channel(c - 1)
ZoneFound = False
For z = 1 To host.ChannelCount
HostChannel = host.Channel(z - 1)
If GuestChannel.TypeId.CompareTo(HostChannel.TypeId) = 0 Then
If GuestChannel.ZoneId.CompareTo(HostChannel.ZoneId) = 0 Then
ZoneFound = True
Exit For
End If
End If
Next z
If Not ZoneFound Then
Return False
End If
Next c
Return True
End Function
【０２６９】
仮想ネットワーク
ネットワークゾーンは、ネットワークケーブルをそれぞれの仮想ＮＩＣから仮想スイッチへ接続するレベルまでのネットワークハードウェアのエミュレーションを必要とするものではなく、むしろウルトラバイザオペレーションズモデル内の主要なオブジェクトの１つである。管理者は、パーティションを、仮想ケーブル接続を介して間接的にではなく、直接１つまたは複数のネットワークゾーンに関連付けることができる。１つまたは複数の標準的なデータセンタパターンが、ウルトラバイザと共に提供される。１つの典型的な例は、ＤＭＺ（ｄｅｍｉｌｉｔａｒｉｚｅｄ  ｚｏｎｅ）、アプリケーションゾーン（Ａｐｐｌｉｃａｔｉｏｎ  Ｚｏｎｅ）、データゾーン（Ｄａｔａ  Ｚｏｎｅ）、インターネットゾーン（Ｉｎｔｒａｎｅｔ  Ｚｏｎｅ）、およびデータセンターバックボーン（Ｄａｔａ  Ｃｅｎｔｅｒ  Ｂａｃｋｂｏｎｅ）である。これらのネットワークゾーンは、（前述の）仮想データセンタのコンポーネントを、他の仮想データセンタボックス内のその他のコンポーネントと、あるいは物理的なデータセンタ自体の中のコンポーネントと接続する。
【０２７０】
仮想ネットワークインフラストラクチャは、望ましい場合にリソースをターゲットとすることができるポリシーメカニズムを順守する。ポリシーメカニズムは、たとえば毎秒の最小／最大の送信／受信要求および毎秒の最小／最大の送信／受信バイトを含む典型的なＱＯＳ（Ｑｕａｌｉｔｙ  ｏｆ  Ｓｅｒｖｉｃｅ）および帯域幅の保証および／または制限を含める必要がある。
【０２７１】
ファイアウォールは、さまざまなネットワークに参加するために使用される主要なメカニズムである。ネットワークは、ウルトラバイザホストハードウェアパーティション内に完全にカプセル化することができ、物理的なネットワークに直接接続することができ、ＩＰＳＥＣならびに／あるいはＩＰＳＥＣおよびＳＳＬ  ＶＰＮ接続を介して相互接続することができる。
【０２７２】
ウルトラバイザホストシステム１０内の各物理的なＮＩＣは、１つのネットワークゾーンに関連付けられている。ネットワークゾーンへの接続用に構成されている仮想パーティションのそれぞれは、仮想スイッチによって直接接続されている。ウルトラバイザオブジェクトモデルにおいては、ＳＡＮは、単に別のタイプのネットワークにすぎない。たとえばｉＳＣＳＩトラフィックは、ストレージ用の別個のネットワークゾーンを定義することによって分離することができる。ファイバチャネル（ＳＡＮ）は、常に別個のストレージネットワークゾーンによって記述される。ＤＡＳ（Ｄｉｒｅｃｔｌｙ  Ａｔｔａｃｈｅｄ  Ｓｔｏｒａｇｅ）は、連結されているホスト１０に限定された特別なタイプのストレージネットワークである。ＡＴＡによって、１つの連結されたパーティションが可能となり、パラレルＳＣＳＩによって、１つまたは２つの連結されたホスト１０が可能となる。
【０２７３】
一例として、データセンタが、８つのホストをサポートするための手段を用いてパーティションで１６に区切られている２つの５４０  Ｇ２システムおよび２つの５４０  Ｇ３システムと共に実装されている場合について考える。Ｇ３システムは、より高速のプロセッサを有する。仮想化されたネットワークを使用すれば、Ｇ３プロセッサゾーンを作成して、Ｇ３ホストパーティションからそれを参照し、またＧ２プロセッサゾーンを作成して、Ｇ２ホストパーティションからそれを参照することができる。そしてゲストパーティションは（おそらくはプロセッサを激しく使用するワークロードを伴って）、より高速のホスト１０上で実行されるためにＧ３プロセッサゾーンを参照することができる。Ｇ２プロセッサゾーンを参照するゲストパーティション２４、２６、２８は、より低速のホスト上で実行されることになる。どちらも参照しないゲストパーティション２４、２６、２８は、どちらかの上で実行することができる（またそうされることになる）。ゲストパーティション２４、２６、２８がＧ３プロセッサゾーンを参照する方法は、パーティションの定義を編集し、タイプ「プロセッサゾーン」のチャネルを追加し、利用可能なゾーンのリストから「Ｇ３」を選択することであろう。仮想ネットワークと関連してゾーンの概念を再利用することによって、ユーザインターフェースは、ホスト／ゲストパーティションをパワー／メモリ／プロセッサのグループ分けのセットへと分類できるようにする上で特別なデバイスを必要としない。
【０２７４】
仮想クラスタ
クラスタはまた、個々のホストハードウェアパーティションを定義する。クラスタインスタンスのノードは、ホスト１０内で実行されるインフラストラクチャゲストパーティションのパターンを定義する。利用可能性を管理するためには、ウルトラバイザアプリケーションは、パーティションがクラスタノードとしてどのようにマップされているかを認識していなければならない。クラスタノードであるパーティションは、他のホスト１０へ移動するための、および需要にマッチするようにアクティブなノードインスタンスの数を動的にコントロールするための第１の候補である。構成されるノードインスタンスの数は、それらの対応するディスクボリュームイメージと共に、動的に作成して、パーティションテンプレートがクラスタに関連付けられている場合には自動的に破棄することもできる。リソース管理アプリケーションは、仮想クラスタのノード用のオペレーションを調整することによって、クラスタの機能停止を防止しなければならない。単一のハードウェアホスト１０内における２つのノードのシンプルなクラスタでさえ、中断のないクラスタサービスを提供することができ、その一方で個々のノードのオペレーティングシステム内の動的なパーティショニング機能を必要とすることなく、ソフトウェアパーティションの構成を動的に変更する（メモリ／プロセッサを追加／削除する）ことができるため、有用である。Ｗｉｎｄｏｗｓ（登録商標）クラスタは、ＭＳＣＳ（利用可能性あるいは障害に対して耐性のあるクラスタ）、ＮＬＢ（ｎｅｔｗｏｒｋ  ｌｏａｄ  ｂａｌａｎｃｉｎｇ  ｃｌｕｓｔｅｒｓ）、ＤＦＳ（ｄｉｓｔｒｉｂｕｔｅｄ  ｆｉｌｅ  ｓｙｓｔｅｍ）、およびＨＰＣ（ｈｉｇｈ  ｐｅｒｆｏｒｍａｎｃｅ  ｃｌｕｓｔｅｒｓ）など、さまざまなタイプから構成される。
【０２７５】
仮想データセンタ内のロードバランシングクラスタは、スケールアップされたハードウェアか、スケールアウトテクノロジーのコスト効率のよい展開を提供することを可能にする。不要なクラスタノードは、パワーの低い状態へ自動的に移行することができ、プロセッサおよびメモリのパワーは、より優先順位の低いタスクに適用される。
【０２７６】
仮想サーバ
エンタープライズサーバのコンテキストにおいては、ハードウェアパーティションが共通であり、「仮想パーティション」は、仮想サーバにとって自然な用語である。仮想データセンタ内の仮想サーバは、物理的なデータセンタ内の物理的なサーバと同様のライフサイクルを有する。効果的なデータセンタオペレーションモデルを提供するためには、仮想パーティションは、持続的な定義および構成をもたなければならない。
【０２７７】
たとえ仮想パーティションがウルトラバイザハードウェアパーティション内にしか存在しない場合でも、パーティションの定義は、実際のサーバハードウェアのより強力なオペレーションモデルを提供することが少ない場合でさえ持続される。これはまた、さまざまな仮想パーティションをホストするための利用可能なリソースを有する適切なハードウェアパーティション（ホスト）１０を自動的に選択することを容易にする。管理者／オペレータのクライアントコンソールからは、仮想パーティションは、ハードウェアサーバとほとんど区別がつかないが、ただし物理的なシステムとは異なり、「ハードウェア」に対する変更は、リモートに行うことができる。
【０２７８】
パーティションは、それ自体あるいはその現在のハードウェアホスト１０がいかなる理由で停止されても、その存在が終了することはない。これは、物理的なサーバがその電源コードを抜かれてもその存在が終了することはないのとまったく同様である。また１つのパーティションは、複数の構成をもつことができる。アクティブなパーティションの構成は、ＯＳが動的なパーティショニングをサポートしている場合にのみ、変更することができる。しかし次の構成は、選択可能であり、パーティションが再始動されたときにアクティブな構成となる。
【０２７９】
それぞれのパーティションの定義は、複数のパーティション構成を明示的にサポートしなければならない。さもなければ、管理者／オペレータは、既存のパーティションのディスクストレージリソースを共有する特別な目的のために代わりのパーティション定義を作成しようと試みることになる。これによって、「ハードウェア」オペレーションモデルが複雑になり、認識される複雑さがユーザインターフェースに加わることになる。代替構成を明確にすることによって、これは防止される。というのも、ウルトラバイザアプリケーションによって、１つのパーティションの１つの構成しかアクティブになれないためである。これによって、持続モデルと、仮想データセンタオペレーションズモデルの双方が強化される。代替構成を使用できる場合の例は、クラスタノードであるパーティションのために季節ごとのあるいは週ごとのリソースサイクルを含み、制限されているリソースと共に実行して、周期的なアップグレードおよびその他のメンテナンスオペレーションを実行することができる。
【０２８０】
パーティションの構成は、少なくとも概念的には、Ｗｉｎｄｏｗｓ（登録商標）ハードウェアプロファイルにマップされる。たとえばＷｉｎｄｏｗｓ（登録商標）は、ＡＣＰＩによって提供されているポータブルコンピュータの「Ｄｏｃｋ  ＩＤ」および「シリアルナンバー」メカニズムを再利用することができる。この統合の主な利点は、より強力なオペレーションモデルとなることであり、通常のオペレーティングシステムメカニズムを使用して仮想ハードウェアと下記のように対話できることによる。
「このデバイスを使用すること（有効化）」
「このデバイスを使用しないこと（無効化）」
「現在のハードウェアプロファイルにおいて、このデバイスを使用しないこと（無効化）」
「いかなるハードウェアプロファイルにおいても、このデバイスを使用しないこと（無効化）」
【０２８１】
「ハードウェア」プロファイルを認識しているウルトラバイザアプリケーションを有することにより、プラットフォームは、使用されていない「ハードウェア」をインスタンス化しないことによってリソースの最適化を実行することもできる。ウルトラバイザオペレーションフレームワークおよびユーザインターフェースは、パーティションプロファイルをＷｉｎｄｏｗｓ（登録商標）ハードウェアプロファイルと同期化するためのメカニズムを提供する。
【０２８２】
本発明による仮想パーティションは、本明細書で説明するようにそれらの使用を容易にするためのライフサイクルを有することが好ましい。具体的には、各パーティションは、任意の時点において、下記のものを含む７つのライフサイクルステージのうちの１つの中に存在する。
・構築
・プロビジョニング（自動）
・オペレーティング（自動）
・手動
・無効化
・廃止
・テンプレート
【０２８３】
パーティションは、構築ステージにおいて作成される。パーティションは、単純に１つの名前および１つのグローバルに一意な識別子を伴って、構築ステージを開始する。パーティションは、パーティションの定義が少なくとも１つのパーティションの構成を含むまで、このステージに留まる。パーティションの定義は、パーティションシステムボリュームのロケーションを含む。これは、パーティション用のＮＶＲＡＭ（ｎｏｎ−ｖｏｌａｔｉｌｅ  ＲＡＭ）の設定（別名、ＢＩＯＳ  ＣＭＯＳ）を含む。
【０２８４】
最初の構築が完了すると、パーティションは、プロビジョニングステージに入る。このステージの間、パーティションはアクティブにされ、ＡＤＳ（Ａｕｔｏｍａｔｅｄ  Ｄｅｐｌｏｙｍｅｎｔ  Ｓｙｓｔｅｍ）のようなネットワークプロビジョニングツールを介して自動的に提供することができる。あるいはパーティションは、仮想パーティションファームウェアにアクセスするためのコンソールを使用して、およびリモートのフロッピー（登録商標）またはＣＤＲＯＭメディアをマウントして、手動で提供する（始動および停止する）こともできる。
【０２８５】
プロビジョニングが完了すると、パーティションは、オペレーティングステージに入る。パーティションは、そのライフタイムのほとんどの間、このステージ内に留まる。ウルトラバイザオペレーションズフレームワークは、パーティションが、割り当てられたビジネスポリシーに基づいて必ず機能しているようにするメカニズムを提供する。最もシンプルなケースにおいては、オペレーションズパーティション２２は、割り当てられたホストシステム１０をモニタする。万一何らかの障害が生じた場合には、オペレーションズパーティション２２は、障害の生じたホストシステム１０を再始動しようと試みる。再始動が失敗した場合には、オペレーションズパーティションは、それぞれのホストされているパーティションごとに代わりのホストを選択する。
【０２８６】
パーティションポリシーは、パーティションの状態：実行中、一時停止、停止｛たとえば、金曜日の午後に始動し、月曜日の朝に停止｝に対して評価を行う（月に一度、四半期に一度、．．．実行するような）スケジュールを含むことができる。スケジュールは、選択された構成も評価する（たとえば、パーティションを土曜日の朝に週末の構成で再始動し、月曜日の朝に再び平日の構成で再始動する）。スケジュールは、割り当てられているが必要とされていないリソース（メモリ、プロセッサ）も評価し、余分なプロセッサおよびメモリは、必要なときに借用して返すことができる。エージェントは、履歴データを使用して、推奨されているポリシーの範囲内における現在のリソース要件を計算することができる。
【０２８７】
パーティションは、別のホストあるいはデータセンタへ時おり移動することができ、そのパーティションが、定義されているクラスタ内のノードである場合には、そのクラスタの利用可能性を最大限に高めるために、アクションが他のノードのアクションと調整される。
【０２８８】
パーティションは、明示的に無効にすることもできる。これは、仮想の電源コードを抜くことに似ている。パーティションは、このステージにおいては、オペレーティングステージへ戻されるまで、あるいは廃止ステージへ移動することによって永久に非アクティブにされるまで、非アクティブなままである。廃止されたパーティションは、参照用として引き続き利用可能とすること、アーカイブに保存すること、あるいは永久に破棄することができる。
【０２８９】
テンプレートステージ内のパーティションは、新しいパーティションを複製するための機能的なプロトタイプとして使用される。パーティションは、構築からテンプレートステージへ直接移動することができる。パーティションテンプレートにプロセッサあるいはメモリが割り当てられることはないが、そのパーティションテンプレートが複製される際に複製するためにターゲットストレージボリューム（あるいはボリュームイメージ）を割り当てることができる。このようなテンプレートを作成するために、停止されたパーティションを（ＳｙｓＰｒｅｐを実行した直後に）プロビジョニングステージからテンプレートステージへ移動することができる。
【０２９０】
パーティションの状態は、アンインストール、非アクティブ、およびアクティブという３つの基本的なカテゴリーの中に存在する。アンインストールのカテゴリーは、ライフサイクルの構築フェーズに対応する。非アクティブ｛停止，保存（ハイバネーション）｝およびアクティブ｛開始，実行，一時停止（スタンバイ）｝のカテゴリーは、プロビジョニングステージおよびオペレーティングステージに対応する。現在、ハードウェアメモリおよび／またはプロセッサのリソースを割り当てられているこれらのステージ内のパーティションは、アクティブである。オペレーティングステージ内のパーティションは、非アクティブな状態とアクティブな状態の間でパーティションを自動的に移行させる関連付けられたスケジュールを有することができる。第４の（無効化）カテゴリーは、無効化ステージ、廃止ステージ、およびテンプレートステージに対応する。
【０２９１】
また本発明の新規の教示および利点から実質的に逸脱することなく、典型的な実施形態において多くの追加の修正が可能であるということを当業者なら容易に理解されよう。たとえばウルトラバイザパーティションのインメモリリソースデータベースは、最も高い利用可能性を提供するためにパーティションで区切ることができるということを当業者なら理解されよう。図１５は、２つのリソースデータベースへとパーティションで区切られているホストリソースを示している。「ウルトラバイザａ」パーティション１４ａおよび「ウルトラバイザｂ」パーティション１４ｂは、それぞれホストシステム１０の１／２に関するリソースを追跡監視する。それぞれは、実際のリソースの決定を行うために、対応するコマンドパーティション２０ａ、２０ｂを有する。共通のオペレーションズパーティション２２は、オペレーション上の決定を行う。仮想データセンタ内の別のホストパーティションは、冗長オペレーションズパーティションを提供することができる。それぞれのプロセッサは、ウルトラバイザパーティションのうちの１つに排他的に割り当てられ、ウルトラバイザパーティション１４ａと１４ｂの間には、限られた対話しか存在しないか、あるいは対話がまったく存在しない。
【０２９２】
したがって、このようなあらゆる修正は、添付の典型的な特許請求の範囲によって定義されるように、本発明の範囲内に含まれるよう意図されている。
【図面の簡単な説明】
【０２９３】
【図１】本発明のウルトラバイザ準仮想化システムを使用してパーティションで区切られているホストシステムの模範的な一実施形態において、左側にシステムインフラストラクチャパーティションを、そして右側にユーザゲストパーティションを示す図である。
【図２】図１のパーティションで区切られているホストと、それぞれの仮想パーティションの関連付けられている仮想パーティションモニタとを示す図である。
【図３】ウルトラバイザパーティション、コマンドパーティション、オペレーションズパーティション、Ｉ／Ｏパーティション、およびゲストパーティションの間でメモリにマップされた通信チャネルを示す図である。
【図４】システムおよびユーザの仮想パーティション、ウルトラバイザパーティション内の仮想パーティション記述子、コマンドパーティション内のリソースエージェント、ならびにコマンドパーティションおよびオペレーションズパーティション内のポリシーエージェントのメモリの割り当てを示す図である。
【図５】重なり合ったプロセッサスロットリングを使用するプロセッサの共有を示す図である。
【図６】ホストの物理的なプロセッサのタイムクオンタムに対する仮想プロセッサのサンプルマップを示す図である。
【図７】本発明のウルトラバイザシステムによって実装されるページテーブル階層を示す図であり、これによってページサイズの階層は、常に２１０という累乗に基づく。
【図８】本発明による２つのユーザパーティションＸ（４ＧＢ）およびＹ（１ＧＢ）用の６４ＧＢのシステムのメモリの割り当ての一例を示す図である。
【図９】本発明のウルトラバイザシステム内におけるＩ／Ｏスロット内の、ＰＣＩアダプタカードなどのリソースハードウェアを使用する単一のホスト内の内部のＩ／Ｏを示す図である。
【図１０】本発明によるゲストパーティションから直接インテリジェントＩ／Ｏアダプタへのデータ接続を使用する外部のＩ／Ｏを示す図である。
【図１１】４つのホストハードウェアパーティションを示すベン図であり、この４つのホストハードウェアパーティションは、対応するシステムドメインに関連付けられており、この対応するシステムドメインは、今度は３つのパーティションドメインに関連付けられている。
【図１２】進行中のパーティションの移行を示す図である。
【図１３】データセンタの構成におけるオペレーションズパーティションによる管理用のゾーンへの複数のホストのハードウェアリソースの割り当てを示す図である。
【図１４】本発明に従って実装される複数のホストデータセンタを示す図であり、これによって、オペレーションズパーティション内で実行されている分散型のオペレーションズサービスは、同じまたは別のホスト上の適切なホストハードウェアパーティションを選択する。
【図１５】２つのウルトラバイザパーティション内の２つのリソースデータベースへとパーティションで区切られているウルトラバイザホストリソースデータベースを示す図である。
【図１】
2007510198.tif 000003
【図２】
2007510198.tif 000004
【図３】
2007510198.tif 000005
【図４】
2007510198.tif 000006
【図５】
2007510198.tif 000007
【図６】
2007510198.tif 000008
【図７】
2007510198.tif 000009
【図８】
2007510198.tif 000010
【図９】
2007510198.tif 000011
【図１０】
2007510198.tif 000012
【図１１】
2007510198.tif 000013
【図１２】
2007510198.tif 000014
【図１３】
2007510198.tif 000015
【図１４】
2007510198.tif 000016
【図１５】
2007510198.tif 000017
【手続補正書】
【提出日】平成18年6月20日(2006.6.20)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
少なくとも１つのホストプロセッサと、最も高い特権を有するシステムメモリとより低い特権を有するユーザメモリとに分割されたメモリを含むシステムリソースとを有するホストコンピュータのための仮想化システムであって、
少なくとも１つのユーザゲストパーティションと少なくとも１つのシステムパーティションとを含む複数の仮想パーティションであって、前記少なくとも１つのユーザゲストパーティションは、前記より低い特権を有するユーザメモリ内の少なくとも１つのゲストオペレーティングシステムのための仮想化環境を提供し、前記少なくとも１つのシステムパーティションは、前記少なくとも１つのホストプロセッサおよび前記システムリソースの使用を管理する際に使用するための前記より低い特権を有するユーザメモリ内のリソースデータベースを保持するための第１のシステムパーティションを有する仮想パーティションと、
前記最も高い特権を有するシステムメモリ内で機能し、かつ前記第１のシステムパーティションに関連付けられたリードモニタであって、自分自身を、前記リソースデータベース内に保存されているパーティション記述子への読み取り専用アクセスに制限し、前記少なくとも１つのユーザゲストパーティションのそれぞれと、前記少なくとも１つのシステムパーティションのそれぞれとに関連付けられた前記少なくとも１つのモニタインスタンスを作成しおよび削除するためのサービスを提供し、前記複数の仮想パーティション間におけるコンテキストの切り替えの実行を支援するリードモニタと、
前記最も高い特権を有するシステムメモリ内で機能し、前記少なくとも１つのゲストパーティションおよび前記少なくとも１つのシステムパーティション内のゲストアプリケーションを、前記リードモニタによって前記少なくとも１つのゲストパーティションおよび前記少なくとも１つのシステムパーティションに割り当てられたメモリスペースに保持する少なくとも１つのモニタとを含み、
前記複数の仮想パーティション間における前記コンテキストの切り替えは、前記少なくとも１つのホストプロセッサ上で前記パーティション内のソフトウェアのマルチタスク処理をコントロールするために使用されることを特徴とする仮想化システム。
【請求項２】
前記第１のシステムパーティションは、前記リソースデータベースと、前記リードモニタと、リソースマネージャアプリケーションとを含むウルトラバイザパーティションを含み、前記リソースマネージャアプリケーションは、
システムリソースをそれぞれのシステムパーティションおよびゲストパーティションに割り当て、前記リソースデータベースにおいて前記割り当てられたシステムリソースに対するインデックスを提供し、
前記リソースデータベースを更新するために前記リソースマネージャアプリケーションによって処理されるトランザクションとして前記リソースマネージャアプリケーションに伝達される、前記システムリソースの前記割り当てにおける要求された変更を受け取り、
共有メモリをそれぞれのパーティションにメモリチャネルとして割り当て、これらのメモリチャネルを通じて、前記トランザクションは１つのパーティションから別のパーティションへ渡ることができることを特徴とする請求項１に記載の仮想化システム。
【請求項３】
前記システムリソースは、
前記ホストコンピュータのそれぞれのゲストパーティションとシステムパーティションとの間でトランザクションをやり取りできるようにするメモリチャネルであって、それぞれのパーティションに割り当てられた共有メモリを含むメモリチャネルと、
前記ホストコンピュータの入力／出力（Ｉ／Ｏ）ハードウェアリソースと、
前記ホストコンピュータの各ホストプロセッサの処理の全体または一部と、
前記ホストコンピュータの物理メモリとを含むことを特徴とする請求項２に記載の仮想化システム。
【請求項４】
前記リソースデータベースのメモリ割り当てページマップは、階層化されたページサイズモデルに従って編成され、この階層化されたページサイズモデルは、スケーリングファクタとして２ｘを使用するスケールの階層を含み、それによって、各階層化されたページサイズレベルにおける１つのインデックスページは、次に低い階層化されたページサイズレベルのサイズにおいて２ｘのメモリブロックを割り当てることができ、
ここで、ｘ＝１０であり、仮想パーティション番号は、前記メモリ割り当てページマップにおいて、前記仮想パーティション用の前記仮想パーティション記述子を前記仮想パーティション番号と同一視する４ｋのページのマップへの３２ビットのインデックス（２，１０，１０，１０）、ただし、第１のビットは、より小さなページ内における副次割り当てを示し、３つの連続した２１０の値は、拡大縮小されたページを識別する、として表されることを特徴とする請求項２に記載の仮想化システム。
【請求項５】
前記リソースマネージャアプリケーションは、所望のパーティション番号［Ｇ，Ｍ，Ｋ］用のパーティション記述子をメモリ内にＭｅｍ（Ｇ，Ｍ，Ｋ）＝（（Ｇ＊２１０＋Ｍ）＊２１０＋Ｋ）＊２１０＊（ワードサイズ）、ただし、ワードサイズは２の累乗である、として保存することによって、前記メモリを前記それぞれのシステムパーティションおよびゲストパーティションに割り当て、
前記保存されたパーティション記述子は、前記パーティション記述子によって定義されている前記パーティションに関連付けられた前記モニタに提供され、それによって前記モニタは、そのパーティション内のアプリケーションを前記パーティション記述子によって定義された前記メモリに制限することができることを特徴とする請求項４に記載の仮想化システム。
【請求項６】
前記少なくとも１つのシステムパーティションは、
リソース割り当てソフトウェアを含むコマンドパーティションと、
前記コマンドパーティションに関連付けられた前記少なくとも１つのモニタインスタンスに対応するコマンドモニタとをさらに含み、
前記リソース割り当てソフトウェアは、前記ホストシステムのためのリソース割り当てポリシーを所有し、トランザクション内で指定されているように前記システムリソースを再割り当てするために前記リソースマネージャアプリケーションによって処理するための前記コマンドパーティションと前記ウルトラバイザパーティションとの間のコマンドメモリチャネルを通じて渡される前記トランザクションを作成することを特徴とする請求項３に記載の仮想化システム。
【請求項７】
前記リソースマネージャアプリケーションは、前記障害の生じたシステムパーティションが関与するトランザクションの前記ロールバックを可能にするために、処理されたトランザクションの監査ログを保持し、前記監査ログからのトランザクションの再適用を可能にし、
前記リソースマネージャアプリケーションによるＩＤＴ（Ｉｎｔｅｒｒｕｐｔ  Ｄｅｓｃｒｉｐｔｏｒ  Ｔａｂｌｅ）のコントロールを通じて前記少なくとも１つのホストプロセッサのコントロールを可能にするために仮想プロセッサの特権レベルを制限することによって、前記少なくとも１つのホストプロセッサの処理サイクルを割り当て、
前記ＩＤＴにアクセスして、前記少なくとも１つのホストプロセッサにタイマ割り込みを提供し、前記タイマ割り込みは、仮想プロセッサコンテキストの切り替えを開始するために前記コンテキストの切り替えによって使用されることを特徴とする請求項６に記載の仮想化システム。
【請求項８】
前記少なくとも１つのシステムパーティションは、ブートパーティションをさらに含み、このブートパーティションは、前記少なくとも１つのシステムパーティションの他のシステムパーティションをブートおよびリブートすることが必要な場合の修復オペレーションのためのハードウェアパーティションブートファームウェアを含み、前記コマンドパーティションが、リソースを前記他のシステムパーティションに割り当てるためのトランザクションを作成することができるまで、前記他のシステムパーティションのためのリソースを要求する前記リソースマネージャアプリケーションに対するトランザクションを開始することを特徴とする請求項６に記載の仮想化システム。
【請求項９】
処理上の障害を経験している前記他のシステムパーティションは、前記他のシステムパーティションをリブートし、前記他のシステムパーティションのために保存されていたシステムリソースをリブートされた前記他のシステムパーティションに割り当て直し、前記他のシステムパーティションによって進行されているあらゆる保留中のトランザクションをロールバックして、前記リソースデータベースエントリのステータスを前記他のシステムパーティションの障害の時点よりも前のステータスに戻すことによって修復されることを特徴とする請求項８に記載の仮想化システム。
【請求項１０】
前記コマンドパーティションは、
前記リソース割り当てポリシーに基づいて前記トランザクションを作成するリソースサービスと、
前記複数の仮想パーティションの自律的な管理を提供するためのポリシーサービスとを含むことを特徴とする請求項６に記載の仮想化システム。
【請求項１１】
前記少なくとも１つのモニタは、各異なるゲストパーティションに関連付けられた少なくとも１つの異なるモニタインスタンスを含み、それぞれの前記少なくとも１つの異なるモニタインスタンスは、その対応する少なくとも１つのゲストパーティション内の１つのゲストオペレーティングシステムに対してカスタマイズされており、これにより、前記リソースデータベース内の前記ゲストオペレーティングシステムのためのパーティション記述子によって、前記ゲストオペレーティングシステムが、前記少なくとも１つのゲストパーティションに割り当てられていないリソースを入手することが防止され、
前記リードモニタは、前記少なくとも１つのゲストパーティションのためのパーティション記述子を前記リソースデータベースから読み取って、前記パーティション記述子を前記モニタに提供するように構成されており、これによって前記モニタは、前記パーティション記述子を使用して、ゲストアプリケーションを前記少なくとも１つのゲストパーティション内に制限することができ、
前記モニタは、いかなるシステムリソースへのアクセスもコントロールせず、
いくつかのモニタインスタンスは、別々のパーティションに関連付けられた複数のモニタ間で情報を共有できるようにするために、他のモニタインスタンスによってアクセスできる共有メモリにアクセスすることができることを特徴とする請求項３に記載の仮想化システム。
【請求項１２】
前記ゲストオペレーティングシステムが、ｘ８６プロセッサ用にプログラムされている場合に、前記関連付けられたモニタは、トラップを使用して解決しなければならないセンシティブなオペレーティングシステム命令が前記ゲストオペレーティングシステムによって実行されるのを防止することを特徴とする請求項１１に記載の仮想化システム。
【請求項１３】
前記少なくとも１つのシステムパーティションは、少なくとも１つの入力／出力（Ｉ／Ｏ）パーティションを含み、前記少なくとも１つのＩ／Ｏパーティションは、
少なくとも１つのＩ／Ｏチャネルサーバと、
前記Ｉ／Ｏパーティションに関連付けられた前記少なくとも１つのモニタインスタンスに対応するＩ／Ｏモニタとを含み、
前記少なくとも１つのＩ／Ｏチャネルサーバは、前記ホストコンピュータの物理的なＩ／Ｏハードウェアを前記Ｉ／Ｏパーティション内の前記少なくとも１つのＩ／Ｏチャネルサーバのエンドポイントにマップし、前記Ｉ／Ｏチャネルサーバは、前記Ｉ／Ｏパーティションと前記少なくとも１つのゲストパーティションとの間のメモリチャネルを介して前記物理的なＩ／Ｏハードウェアを前記少なくとも１つのゲストパーティションと共有し、
前記少なくとも１つのゲストパーティションは、Ｉ／Ｏオペレーションを実行するために前記少なくとも１つのＩ／Ｏチャネルサーバと通信する前記少なくとも１つのゲストパーティションまたは前記少なくとも１つのシステムパーティションに対応し、
前記ウルトラバイザパーティション内の前記リソースマネージャアプリケーションは、共有メモリを前記少なくとも１つのゲストパーティションまたは少なくとも１つのシステムパーティションに、および前記少なくとも１つのＩ／Ｏサーバに割り当てて、前記メモリチャネルを形成することを特徴とする請求項３に記載の仮想化システム。
【請求項１４】
前記Ｉ／Ｏパーティションに関連付けられた前記Ｉ／Ｏモニタは、前記Ｉ／Ｏモニタと前記Ｉ／Ｏパーティションとの間にシステムコールインターフェースを実装し、前記システムコールインターフェースは、前記少なくとも１つのゲストパーティションのメモリチャネルドライバからそれぞれのメモリチャネルを通じて送信された要求のバッファパラメータとして入手された、前記少なくとも１つのゲストパーティションの相対的なアドレスを、前記共通の物理的なＩ／Ｏハードウェアへのアクセスを要求している前記少なくとも１つのゲストパーティションに現在割り当てられているメモリの有効なハードウェアの物理アドレスとして変換しおよび確認し、
物理的なＩ／Ｏハードウェアにアクセスするための、前記少なくとも１つのゲストパーティションからの要求を前記Ｉ／Ｏチャネルサーバが受け取ると、前記Ｉ／Ｏモニタは、前記少なくとも１つのゲストパーティションに関連付けられたモニタに保存されているパーティション記述子の内容をチェックし、前記要求されている物理的なＩ／Ｏハードウェアへのアクセスが有効であることを検証することを特徴とする請求項１３に記載の仮想化システム。
【請求項１５】
前記少なくとも１つのＩ／Ｏパーティションによる前記Ｉ／Ｏチャネルサーバのエンドポイントへの前記物理的なＩ／Ｏハードウェアの前記マッピングは、共有されている共通の物理的なＩ／Ｏハードウェアを通じて、それぞれのメモリチャネルによって前記Ｉ／Ｏパーティションに接続されている複数のゲストパーティションから前記共通の物理的なＩ／ＯハードウェアへのあらゆるＩ／Ｏ要求を多重化するＩ／Ｏチャネルサーバによって実行され、
前記Ｉ／Ｏパーティションサーバと前記それぞれのゲストパーティションとの間のメッセージは、前記少なくとも１つのゲストパーティションによってキューに入れられ、前記Ｉ／Ｏチャネルサーバによってキューから出され、前記少なくとも１つのゲストパーティションの相対的な物理アドレスは、前記Ｉ／Ｏチャネルサーバによって前記Ｉ／Ｏモニタの助けを借りて物理的なＩ／Ｏハードウェアアドレスに変換され、それによって、前記Ｉ／Ｏモニタと前記共通の物理的なＩ／Ｏハードウェアとの間に接続されているハードウェアＩ／Ｏアダプタとデータをやり取りすることができ、
前記少なくとも１つのＩ／Ｏパーティションによる前記Ｉ／Ｏパーティション内の前記Ｉ／Ｏチャネルサーバのエンドポイントへの前記ホストコンピュータの前記物理的なＩ／Ｏハードウェアの前記マッピングは、Ｉ／Ｏアクセスを要求している前記少なくとも１つのゲストパーティションとインテリジェントな物理的なＩ／Ｏハードウェアとの間にパフォーマンスの高いメモリチャネルをセットアップするために前記メモリチャネルを介して前記Ｉ／ＯチャネルサーバにＩ／Ｏセットアップ情報を渡すことによって実行され、
Ｉ／Ｏアクセスを要求している前記少なくとも１つのゲストパーティションと前記インテリジェントな物理的なＩ／Ｏハードウェアとの間で直接データを送信することは、前記パフォーマンスの高いメモリチャネルを使用することを特徴とする請求項１３に記載の仮想化システム。
【請求項１６】
Ｉ／Ｏアクセスを要求している前記少なくとも１つのゲストパーティションは、ユーザモードＩ／Ｏまたはダイレクトメモリアクセスデータ転送オペレーションのうちの１つを使用して、前記Ｉ／Ｏメモリチャネルを介して前記インテリジェントな物理的なＩ／Ｏハードウェアにデータを転送し、
前記少なくとも１つのＩ／Ｏパーティションは、２つの冗長Ｉ／Ｏパーティションを含むことを特徴とする請求項１３に記載の仮想化システム。
【請求項１７】
前記少なくとも１つのシステムパーティションは、アプリケーションソフトウェアを含むオペレーションズパーティションをさらに含み、前記アプリケーションソフトウェアは、構成ポリシーを所有し、前記少なくとも１つのホストコンピュータの各パーティションが割り当てられているそれぞれのドメインについての持続性を追跡監視し、パーティションは、安全な接続を介して前記コマンドパーティションとの間でリソーストランザクションをやり取りすることを特徴とする請求項３に記載の仮想化システム。
【請求項１８】
前記アプリケーションソフトウェアはさらに、
前記少なくとも１つのホストコンピュータの少なくとも１つのドメインのための仮想パーティションの定義の持続的なデータベースを保持し、
最初の始動のための、およびホストコンピュータのパーティションの障害またはハードウェアの障害の場合のブートストラップの目的から、前記少なくとも１つのドメインのための前記仮想パーティションの定義のコピーを保存し、
パーティションがアクティブにされる際に、前記オペレーションズパーティションは、前記アクティブにされるパーティションのためのリソースを要求している前記少なくとも１つのホストコンピュータのうちの１つのホストコンピュータを選択し、前記ホストコンピュータのコマンドパーティション内で実行されているリソースサービスに接続し、前記アクティブにされるパーティションの定義および開始コマンドを前記リソースサービスに提供し、
前記少なくとも１つのホストコンピュータのオペレーションをモニタし、ホストコンピュータの障害を検出した場合には、障害の生じたホストコンピュータに割り当てられている仮想パーティションのための新しいホストコンピュータを選択し、
前記少なくとも１つのホストコンピュータのシステムリソースの相互接続されたセットを１つのゾーンに割り当て、それぞれのパーティションは、前記それぞれのパーティションによって要求されている前記システムリソースを有するゾーン、ただし、ゾーンは、１つのコンピュータネットワーク内の前記少なくとも１つのホストコンピュータのシステムリソースのためのリソース割り当ての単位である、に割り当てられ、
ネットワーク接続を介して、前記オペレーションズパーティションを含まない１つのホストコンピュータの１つのコマンドパーティションにリソーストランザクションを送信することによって、前記オペレーションズパーティションを含まない前記ホストコンピュータに新しいパーティションを割り当て、
パーティションは、前記ネットワーク接続を介して１つのアクティブなパーティションのメモリコンテンツを第１のホストコンピュータから第２のホストコンピュータ内でアクティブにされるターゲットパーティションへ転送することによって、前記第１のホストコンピュータ上の前記アクティブなパーティションを前記第２のホストコンピュータへ移動できるようにすることを特徴とする請求項１７に記載の仮想化システム。
【請求項１９】
前記コマンドパーティションは、前記リソースデータベースのコピーを保存し、前記リソースデータベースの前記コピーを使用して、前記アクティブにされるパーティションのための適切なリソースを選択し、前記コマンドメモリチャネルを介して前記リソースデータベースを更新するためのトランザクションを作成することを特徴とする請求項１８に記載の仮想化システム。
【請求項２０】
前記構成ポリシーは、それぞれのホストコンピュータのサービスの質の保証、帯域幅の保証、および物理的な位置のうちの少なくとも１つに基づいてシステムリソースを１つのゾーンに割り当てることを対象とし、前記構成ポリシーは、別々の時点において別々のシステムリソーススケジュールに基づいて前記システムリソースの構成における変更を認めるように、ユーザによって変更することができることを特徴とする請求項１７に記載の仮想化システム。
【請求項２１】
前記少なくとも１つのシステムパーティションは、前記オペレーションズパーティションをホストしている前記ホストコンピュータとは異なる第２のホストコンピュータ内の１つの冗長オペレーションズパーティションをさらに含むことを特徴とする請求項１７に記載の仮想化システム。
【請求項２２】
少なくとも１つのホストプロセッサとシステムリソースとを有する１つのホストコンピュータ上で複数のオペレーティングシステムインスタンスを管理する方法であって、
前記ホストコンピュータを、少なくとも１つのユーザゲストパーティションと少なくとも１つのシステムパーティションとを含む複数の仮想パーティションに分割するステップであって、前記少なくとも１つのユーザゲストパーティションは、少なくとも１つのゲストオペレーティングシステムのための仮想化環境を提供するステップと、
前記少なくとも１つのホストプロセッサおよび前記システムリソースの使用を管理する際に使用するためのリソースデータベースを保持するステップと、
前記少なくとも１つのゲストオペレーティングシステムのコントロールの下に実行されているゲストアプリケーションを、前記少なくとも１つのシステムパーティションによって前記少なくとも１つのゲストパーティションに割り当てられたメモリスペースに保持するステップと、
前記少なくとも１つのホストプロセッサ上で前記パーティション内の前記ゲストアプリケーションのマルチタスク処理をコントロールするための、前記それぞれの少なくとも１つのゲストパーティションと少なくとも１つのシステムパーティションとの間におけるコンテキストの切り替えを提供するステップとを備えることを特徴とする方法。
【請求項２３】
前記少なくとも１つのシステムパーティションは、
前記リソースデータベース、リソースマネージャアプリケーション、およびリードモニタを含むウルトラバイザパーティションと、
リソース割り当てソフトウェア、コマンドモニタ、およびコマンドメモリチャネルを含むコマンドパーティションとを含み、
前記システムリソースは、前記ホストコンピュータのそれぞれのゲストパーティションとシステムパーティションとの間でトランザクションをやり取りできるようにするメモリチャネルを含み、システムリソースを割り当てるステップは、前記メモリチャネルをそれぞれのパーティションに割り当てるステップを含み、
前記リソース割り当てソフトウェアは、前記ホストシステムのためのリソース割り当てポリシーを所有し、前記リソースデータベースを更新するためのトランザクションを作成することを特徴とする請求項２２に記載の方法。
【請求項２４】
前記リソースマネージャアプリケーションによる前記システムリソースの前記割り当てにおける要求された変更を、前記リソースデータベースを更新するために前記リソースマネージャアプリケーションによって処理できるトランザクションとして伝達するステップと、
システムリソースをそれぞれの少なくとも１つのシステムパーティションおよび少なくとも１つのゲストパーティションに割り当てるステップと、
前記リソースデータベースにおいて前記割り当てられたシステムリソースに対するインデックスを提供するステップと、
前記リソース管理ソフトウェアアプリケーションによって処理されたトランザクションの監査ログを提供するステップとをさらに備え、
前記コマンドパーティションと前記ウルトラバイザパーティションとの間のコマンドメモリチャネルを提供して、前記トランザクション内で指定されているように前記システムリソースを再割り当てするために前記コマンドメモリチャネルを通じて前記リソースマネージャアプリケーションへ前記トランザクションを渡すさらなるステップを含み、
ゲストアプリケーションを、前記割り当てられたメモリスペースに保持するステップは、前記リソースデータベースを含む１つのシステムパーティションに関連付けられた１つのリードモニタを提供して、前記リードモニタを、前記リソースデータベースに保存されているパーティション記述子への読み取り専用アクセスに制限するステップと、
前記リードモニタが、前記ゲストパーティションのためのパーティション記述子を前記リソースデータベースから読み取るステップと、
前記パーティション記述子を、前記ゲストパーティションに関連付けられた１つのモニタに提供するステップと、前記モニタが、前記パーティション記述子を使用して、ゲストアプリケーションを前記ゲストパーティション内に制限するステップと、
異なる各ゲストパーティションに関連付けられた１つの異なるモニタインスタンスを提供するステップと、それぞれの前記モニタを、その対応するゲストパーティション内の１つのゲストオペレーティングシステムに対してカスタマイズするステップであって、これにより、前記リソースデータベース内の前記ゲストオペレーティングシステムのためのパーティション記述子によって、前記ゲストオペレーティングシステムが前記ゲストパーティションに割り当てられていないリソースを入手することが防止されるステップとを含み、
システムリソースを割り当てる前記ステップは、前記リソース管理ソフトウェアアプリケーションによるＩＤＴ（Ｉｎｔｅｒｒｕｐｔ  Ｄｅｓｃｒｉｐｔｏｒ  Ｔａｂｌｅ）のコントロールを通じて前記少なくとも１つのホストプロセッサのコントロールを可能にするように仮想プロセッサの特権レベルを制限することによって、前記少なくとも１つのホストプロセッサの処理サイクルを割り当てるステップと、
共有メモリをそれぞれのパーティションにメモリチャネルとして割り当てるステップであって、これらのメモリチャネルを通じて、前記トランザクションは１つのパーティションから別のパーティションへ渡ることができるステップと、
別々のパーティションに関連付けられた複数のモニタ間で情報を共有できるようにするために、他のモニタインスタンスによってアクセスできる共有メモリにアクセスすることができるいくつかのモニタインスタンスを提供するステップと、
前記少なくとも１つのホストプロセッサにタイマ割り込みを提供するステップと、前記タイマ割り込みを使用して、仮想プロセッサコンテキストの切り替えを開始するステップとを含むことを特徴とする請求項２３に記載の方法。
【請求項２５】
前記少なくとも１つのホストコンピュータのオペレーションをモニタするステップと、ホストコンピュータの障害を検出した場合には、障害の生じたホストコンピュータに割り当てられている仮想パーティションのための新しいホストコンピュータを選択するステップと、
障害の生じたシステムパーティションをリブートし、障害よりも前の前記障害の生じたシステムパーティションの前記リソースを要求する前記リソース管理ソフトウェアアプリケーションに対するトランザクションを開始し、前記要求されているリソースを前記リブートされたシステムパーティションに再割り当てすることによって、前記障害の生じたシステムパーティションを修復するステップ、およびシステムパーティションの障害時に、前記監査ログを使用して、前記障害の生じたシステムパーティションが関与するトランザクションをロールバックして、システムリソースを前記システムパーティションの障害よりも前の時点に戻すステップと、前記監査ログに保存されている完了したトランザクションを再び適用するステップのうちの少なくとも１つを実行するステップと、
障害の生じたシステムパーティションをリブートし、前記障害の生じたシステムパーティションのために保存されていたシステムリソースを前記リブートされたシステムパーティションに割り当て直し、前記障害の生じたパーティションによって進行されたあらゆる保留中のトランザクションをロールバックして、前記リソースデータベースエントリのステータスを前記システムパーティションの障害の時点よりも前のステータスに戻すことによって、前記障害の生じたシステムパーティションを修復するステップとをさらに含むことを特徴とする請求項２４に記載の方法。
【請求項２６】
前記ゲストオペレーティングシステムが、ｘ８６プロセッサ用にプログラムされている場合に、前記関連付けられたモニタは、トラップを使用して解決しなければならないセンシティブなオペレーティングシステム命令が前記ゲストオペレーティングシステムによって実行されるのを防止するステップを実行することを特徴とする請求項２４に記載の方法。
【請求項２７】
前記ホストコンピュータの物理的なＩ／Ｏハードウェアを１つの入力／出力（Ｉ／Ｏ）パーティション内の１つのＩ／Ｏチャネルサーバのエンドポイントにマッピングするステップと、前記Ｉ／Ｏチャネルサーバが、前記Ｉ／Ｏパーティションと前記少なくとも１つのゲストパーティションまたはシステムパーティションとの間のメモリチャネルを介して前記物理的なＩ／Ｏハードウェアを少なくとも１つのゲストパーティションまたは別のシステムパーティションと共有するステップと、前記リソース管理ソフトウェアが、共有メモリを前記少なくとも１つのゲストパーティションまたはシステムパーティションに、および前記Ｉ／Ｏパーティションに割り当てて、前記メモリチャネルを形成するステップとをさらに備え、
物理的なＩ／Ｏハードウェアにアクセスするための、前記少なくとも１つのゲストパーティションまたはシステムパーティションから前記Ｉ／Ｏチャネルサーバへの要求を受け取ると、前記Ｉ／Ｏパーティションは、前記少なくとも１つのゲストパーティションまたはシステムパーティションに関連付けられたパーティション記述子を使用してチェックを行い、前記要求された物理的なＩ／Ｏハードウェアへのアクセスが有効であることを検証するステップを実行し、
前記少なくとも１つのＩ／Ｏパーティションによる前記Ｉ／Ｏパーティション内の前記Ｉ／Ｏチャネルサーバのエンドポイントへの前記ホストコンピュータの前記物理的なＩ／Ｏハードウェアのマッピングは、共有されている共通の物理的なＩ／Ｏハードウェアを通じて、それぞれのメモリチャネルによって前記Ｉ／Ｏパーティションに接続されている複数のパーティションから前記共通の物理的なＩ／ＯハードウェアへのあらゆるＩ／Ｏ要求を多重化するステップと、
前記Ｉ／Ｏパーティションに関連付けられたＩ／Ｏモニタと、前記Ｉ／Ｏパーティションとの間にシステムコールインターフェースを実装するステップと、前記システムコールインターフェースが、ゲストメモリチャネルドライバからそれぞれのメモリチャネルを通じて送信された要求のバッファパラメータとして入手された前記少なくとも１つのゲストパーティションの相対的なアドレスを、前記共通の物理的なＩ／Ｏハードウェアへのアクセスを要求している前記少なくとも１つのゲストパーティションに現在割り当てられているメモリの有効なハードウェアの物理アドレスとして変換しおよび確認するステップと、
それぞれの少なくとも１つのゲストパーティションが、前記Ｉ／Ｏパーティションのサーバと前記それぞれの少なくとも１つのゲストパーティションとの間のメッセージをキューに入れるステップと、前記Ｉ／Ｏパーティションサーバが、前記パーティションの相対的な物理アドレスをキューから出すステップと、前記パーティションの相対的な物理アドレスを物理的なＩ／Ｏハードウェアアドレスに変換するステップと、前記Ｉ／Ｏモニタと前記共通の物理的なＩ／Ｏハードウェアとの間に接続されているハードウェアＩ／Ｏアダプタとデータをやり取りするステップとを含み、
前記少なくとも１つのＩ／Ｏパーティションによる前記Ｉ／Ｏパーティション内の前記Ｉ／Ｏチャネルサーバのエンドポイントへの前記ホストコンピュータの前記物理的なＩ／Ｏハードウェアの前記マッピングは、Ｉ／Ｏアクセスを要求している前記少なくとも１つのゲストパーティションとインテリジェントな物理的なＩ／Ｏハードウェアとの間にパフォーマンスの高いメモリチャネルをセットアップするために前記メモリチャネルを介して前記Ｉ／ＯチャネルサーバにＩ／Ｏセットアップ情報を渡すステップと、前記パフォーマンスの高いメモリチャネルを介して、Ｉ／Ｏアクセスを要求している前記少なくとも１つのゲストパーティションと前記インテリジェントな物理的なＩ／Ｏハードウェアとの間で直接データを送信するステップとを含み、
Ｉ／Ｏアクセスを要求している前記少なくとも１つのゲストパーティションと前記インテリジェントな物理的なＩ／Ｏハードウェアとの間で直接データを送信するステップは、ユーザモードＩ／Ｏとダイレクトメモリアクセスデータ転送オペレーションのうちの１つを実行するステップを含むことを特徴とする請求項２４に記載の方法。
【請求項２８】
スケーリングファクタとして２ｘを使用するスケールの階層と、次に低い階層化されたページサイズレベルのサイズにおいて２ｘのメモリブロックを割り当てる各階層化されたページサイズレベルにおける１つのインデックスページとを含む階層化されたページサイズモデルに従って、前記リソースデータベースのメモリ割り当てページマップを編成するステップと、
所望のパーティション番号［Ｇ，Ｍ，Ｋ］用のパーティション記述子をメモリ内にＭｅｍ（Ｇ，Ｍ，Ｋ）＝（（Ｇ＊２１０＋Ｍ）＊２１０＋Ｋ）＊２１０＊（ワードサイズ）、ただし、ワードサイズは２の累乗である、として保存することによって、前記メモリを前記それぞれのシステムパーティションおよびゲストパーティションに割り当てるステップであって、
前記保存されたパーティション記述子を、前記パーティション記述子によって定義されている前記パーティションに関連付けられたモニタに提供するステップと、前記モニタが、そのパーティション内のアプリケーションを前記パーティション記述子によって定義された前記メモリに制限するステップとをさらに含み、
ここで、ｘ＝１０であり、仮想パーティション番号を、前記メモリ割り当てページマップにおいて、前記仮想パーティション用の前記仮想パーティション記述子を前記仮想パーティション番号と同一視する４ｋのページのマップへの３２ビットのインデックス（２，１０，１０，１０）、ただし、第１のビットは、より小さなページ内における副次割り当てを示し、３つの連続した２１０の値は、拡大縮小されたページを識別する、として表すステップをさらに含むことを特徴とする請求項２４に記載の方法。
【請求項２９】
システムリソースを割り当てる前記ステップは、構成ポリシーに基づいて前記少なくとも１つのホストコンピュータの各パーティションを１つのドメインに割り当てるステップと、
前記少なくとも１つのホストコンピュータの少なくとも１つのドメインのための仮想パーティションの定義の持続的なデータベースを保持するステップと、
最初の始動のための、およびホストコンピュータのパーティションの障害またはハードウェアの障害の場合のブートストラップの目的から、前記少なくとも１つのドメインのための前記仮想パーティションの定義のコピーを保存するステップと、
前記少なくとも１つのホストコンピュータのシステムリソースの相互接続されているセットを１つのゾーンに割り当てるステップと、それぞれのパーティションを、前記それぞれのパーティションによって要求された前記システムリソースを有するゾーン、ただし、ゾーンは、１つのコンピュータネットワーク内の前記少なくとも１つのホストコンピュータのシステムリソースのためのリソースの割り当ての単位である、に割り当てるステップとを含み、
前記パーティションを割り当てるステップは、ネットワーク接続を介して、新しいパーティションをホストすることになる１つのホストコンピュータの１つのコマンドパーティションにリソーストランザクションを送信することによって、前記ホストコンピュータに前記新しいパーティションを割り当てるステップと、
前記ネットワーク接続を介して１つのアクティブなパーティションのメモリコンテンツを第１のホストコンピュータから第２のホストコンピュータ内でアクティブにされるターゲットパーティションへ転送することによって、前記第１のホストコンピュータ上の前記アクティブなパーティションを前記第２のホストコンピュータへ移動するステップと、
別々の時点において別々のシステムリソーススケジュールに基づいて前記構成ポリシーを変更するステップとを含むことを特徴とする請求項２４に記載の方法。
【請求項３０】
パーティションがアクティブにされると、前記アクティブにされるパーティションのためのリソースを要求している前記少なくとも１つのホストコンピュータのうちの１つのホストコンピュータを選択するステップと、前記ホストコンピュータのコマンドパーティション内で実行されているリソースサービスに接続するステップと、前記アクティブにされるパーティションの定義および開始コマンドを前記リソースサービスに提供するステップと、
前記リソースデータベースのコピーを前記コマンドパーティション内に保存するステップと、前記リソースデータベースの前記コピーを使用して、前記アクティブにされるパーティションのための適切なリソースを選択するステップと、前記コマンドメモリチャネルを介して前記リソースデータベースを更新するためのトランザクションを作成するステップとを実行することを特徴とする請求項２９に記載の方法。
【国際調査報告】
2007510198.tif 000018
2007510198.tif 000019