JP2019525312A - オポチュニスティックハイパーバイザを用いたパフォーマンスの変動の低減 - Google Patents

Abstract

オポチュニスティックハイパーバイザは、仮想化ホストのゲスト仮想マシンが物理プロセッサの制御を自発的に解放したことを判定する。ハイパーバイザは、解放されたプロセッサを用いて、完了していない仮想化管理タスクを識別し、開始する。タスクの少なくとも一部が行われたという判定に応じて、ハイパーバイザは、休止状態に入り、物理プロセッサを解放して、ゲスト仮想マシンの再開を可能にする。【選択図】図２２

Description

多くの企業及び他の組織は、コンピューティングシステムが同じ場所に配置される（例えば、ローカルネットワークの一部として）、またはその代わりに、複数の異なる地理的場所に配置される（例えば、1つまたは複数のプライベートまたはパブリックの中間ネットワークを介して接続される）といった、非常に多くのコンピューティングシステムをそれらの運用をサポートするために相互接続するコンピュータネットワークを運用する。例えば、単一の組織によって、かつ単一の組織の代理として運用されるプライベートデータセンター、及び、コンピューティングリソースを顧客に提供するために事業としてエンティティによって運用されるパブリックデータセンターなどの、かなりの数の相互接続されたコンピューティングシステムを収容するデータセンターが一般的になっている。ネットワークアクセス、電源、様々な顧客が所有するハードウェアためのセキュアな設置設備を提供するパブリックデータセンター運用者もいれば、顧客による使用のために利用可能になされたハードウェアリソースをも含む「フルサービス」設備を提供するパブリックデータセンター運用者もいる。

コモディティハードウェアの仮想化技術の出現は、多様なニーズを持つ多くの顧客に対して大規模なコンピューティングリソースを管理する点で利益をもたらし、様々なコンピューティングリソースが複数の顧客によって効率的にかつ安全に共有できるようにしてきた。例えば、仮想化技術は、単一の仮想化ホストによってホストされる１つまたは複数の「ゲスト」仮想マシンを各ユーザに提供することによって、単一の物理仮想化ホストを複数のユーザ間で共有することを可能にし得る。そのような各仮想マシンは、ユーザに所与のハードウェアコンピューティングリソースの唯一の運用者であると錯覚させる個別の論理コンピューティングシステムとして機能するソフトウェアシミュレーションを意味し得、また様々な仮想マシン間にアプリケーションの分離及びセキュリティをも提供する。同一ホスト上にいくつかの異なる仮想マシンのインスタンスを作成することはまた、データセンターでの全体的なハードウェア利用レベルの増加を助け得、投資においてより高いリターンをもたらす。

例えば管理用仮想マシンインスタンス及び／またはハイパーバイザを含み得る各仮想化マネージャは、様々な仮想化環境において各仮想化ホストにインストールされ得る。仮想化マネージャは、タスクの中でもとりわけ、顧客に代わってホスト上のゲスト仮想マシンを開始／停止させること、ゲスト仮想マシンとホスト及びネットワークの様々なハードウェアコンポーネントとの間で仲介役として機能すること、ゲスト仮想マシンに関するメトリクスを収集すること、及びセキュリティルールを実行することに関与し得る。仮想化環境の運用者の観点からすれば、仮想化マネージャによって消費されるリソース（例えば、ホストＣＰＵサイクル、ホストメモリなど）は、ホスト上でインスタンスを作成することができるゲスト仮想マシンの数を減らし、それによってホストハードウェア及び関連するインフラストラクチャにおける運用者の収益化レベルは下がる傾向があり得る。加えて、少なくともいくつかの場合、ゲスト仮想マシンをサポートするために仮想化マネージャによって行われる管理動作またはバックグラウンド動作は、時間依存の顧客アプリケーションと干渉する傾向があり得る。かくして、現在の仮想化環境のセキュリティかつ機能の要件を効率的に満たす仮想化マネージャを設計することは、重要な挑戦を意味し得る。

少なくとも一部の実施形態による、部分的にオフロードされた仮想化マネージャが仮想化コンピューティングサービスで用いられ得る例示的なシステム環境の図である。 少なくとも一部の実施形態による、仮想化ホストの例示的なコンポーネントの図である。 少なくとも一部の実施形態による、ホストにおける仮想化マネージャコンポーネントのサブセットのためのものであり得るオフロードカードの例示的なコンポーネントの図である。 少なくとも一部の実施形態による、仮想化マネージャによって用いられ得るトラステッドプラットフォームモジュールの例示的なコンポーネントの図である。 少なくとも一部の実施形態による、仮想化マネージャで用いられ得る例示的な多段階ブート手順の態様の図である。 少なくとも一部の実施形態による、仮想化マネージャに関連する実行可能なプログラムのために用いられるストレージデバイスのセキュリティを高めるために行われ得る動作の態様を示す流れ図である。 少なくとも一部の実施形態による、仮想化コンピューティングサービスのセキュリティインフラストラクチャ内に仮想化ホストを記録するために行われ得る動作の態様を示す流れ図である。 少なくとも一部の実施形態による、仮想化ホストのコンポーネントに関連する異なる信頼レベルの例の図である。 少なくとも一部の実施形態による、ゲスト仮想マシンを起動するのに仮想コンピューティングサービスコンポーネントの様々な層で必要とされ得る相互作用の例の図である。 少なくとも一部の実施形態による、仮想化ホストにおけるゲスト仮想マシンの例示的な状態遷移の図である。 少なくとも一部の実施形態による、仮想化ホストのメインメモリを、オフロードされた仮想化マネージャコンポーネントによって管理されるセクションとハイパーバイザによって管理されるセクションとに区画する例の図である。 少なくとも一部の実施形態による、ホストメモリのハイパーバイザによって管理されるセクション、及びオフロードされた仮想化マネージャコンポーネントによって管理されるメモリセクションに含まれるメタデータの例示的な内容の図である。 少なくとも一部の実施形態による、仮想化マネージャのコンポーネント間の例示的なメモリインベントリに関する相互作用の図である。 少なくとも一部の実施形態による、仮想化マネージャのコンポーネント間の、ゲスト仮想マシンのインスタンス作成及び終了に関連する例示的なメモリに関する相互作用の図である。 少なくとも一部の実施形態による、仮想化マネージャのコンポーネント間の、ハイパーバイザのライブアップデートに関連する例示的な相互作用の図である。 少なくとも一部の実施形態による、部分的にオフロードされた仮想化マネージャの様々なコンポーネントによって行われ得るメモリ管理関連動作の態様を示す流れ図である。 少なくとも一部の実施形態による、ハイパーバイザのライブアップデートに関連する動作の態様を示す流れ図である。 少なくとも一部の実施形態による、オポチュニスティックハイパーバイザの例示的なサブコンポーネント及び通信機構の図である。 少なくとも一部の実施形態による、オポチュニスティックハイパーバイザによる管理タスクの実行に関連するイベントの例示的なシーケンスの図である。 少なくとも一部の実施形態による、オポチュニスティックハイパーバイザによる管理タスクの実行に関連するイベントの例示的なシーケンスの図である。 少なくとも一部の実施形態による、ハイパーバイザにおける割込み駆動型タスク及びキューベースのタスクの実装に関連する動作の態様を示す流れ図である。 少なくとも一部の実施形態による、ハイパーバイザにおける異なる期待持続時間のタスクの管理に関連する動作の態様を示す流れ図である。 少なくとも一部の実施形態による、オポチュニスティックハイパーバイザの使用によって可能となされ得るアプリケーションの応答時間のばらつきの低減の例の図である。 少なくとも一部の実施形態で使用され得る例示的なコンピューティングデバイスを示すブロック図である。

いくつかの実施形態及び例示の図面の例として実施形態が本明細書中に記載されているが、当業者は、実施形態が、記載された実施形態または図面に限定されないことを認識するであろう。それらについての図面及び詳細な説明は、実施形態を特定の開示された形式に限定することを意図しておらず、逆に、その意図は、添付の特許請求の範囲によって定義される趣旨及び範囲内にある全ての修正物、均等物、及び代替物をカバーすることであることが理解されるべきである。本明細書中で使用される表題は、構成を目的としているにすぎず、説明または特許請求の範囲を限定するために使用されることを意味していない。この出願全体を通じて使用されるように、単語「ｍａｙ」は、必須の意味（すなわち、〜しなければならないを意味する）ではなく、許容的な意味（すなわち、〜する可能性があるを意味する）で使用される。同様に、単語「ｉｎｃｌｕｄｅ（含む）」、「ｉｎｃｌｕｄｉｎｇ（含む）」、及び「ｉｎｃｌｕｄｅｓ（含む）」は、含むが、それに限定しないことを意味する。特許請求の範囲で使用されるとき、用語「ｏｒ（または）」は、包括のｏｒ（または）として使用され、排他のｏｒ（または）としては使用されない。例えば、句「ａｔ ｌｅａｓｔ ｏｎｅ ｏｆ ｘ，ｙ，ｏｒ ｚ（ｘ、ｙまたはｚのうちの少なくとも１つ）」は、ｘ、ｙ及びｚのいずれか1つ、及びそれらの任意の組み合わせを意味する。

仮想化ホストで部分的にオフロードされた仮想化マネージャを用いる仮想マシン管理の方法及び装置の様々な実施形態が記載される。所与の仮想化ホストは、様々な実施形態においてネットワーキング、インタラクティブデバイスなどで使用可能な様々な他のハードウェアコンポーネントに加えて、１つまたは複数のプライマリ物理ＣＰＵ（中央処理装置）またはコア及びメインメモリ（例えば１つまたは複数のランダムアクセスメモリまたはＲＡＭデバイスを備える）を備え得る。様々なクライアントの代わりにゲスト仮想マシンをサポートするために、例えば、ＣＰＵ及び／またはメインメモリの一部の仮想化されたバージョンが、仮想化マネージャのコンポーネントによって作成されてゲスト仮想マシンに割り当てられ得、仮想化ネットワークデバイスが、ゲスト仮想マシンにアクセス可能となされ得る。仮想化ホストの仮想化マネージャは、様々な実施形態においてソフトウェア、ファームウェア及び／またはハードウェアのコンポーネントの様々な組み合わせを備え得、それらは集合的に、ゲスト仮想マシンが仮想化ホスト上で確立され管理されることを可能にする。

「部分的にオフロードされた」という用語は、本明細書中で、様々な実施形態において以下の特徴を有する仮想化マネージャを記載するのに用いられ得る。つまり、仮想化ホスト上のゲスト仮想マシンをサポートするのに必要とされる仮想化管理タスクの少なくともいくつかは、仮想化ホストのプライマリＣＰＵまたはコアを用いて実行されなくてもよいという特徴である。そうしたタスクは、「オフロードされた」タスクと呼ばれ得、ホストの物理ＣＰＵ上の仮想化管理に関するオーバーヘッドを低減させる。ホストのＣＰＵを用いる代わりに、オフロードカード（例えば、あるバージョンのペリフェラルコンポーネントインターコネクト−ＥｘｐｒｅｓｓもしくはＰＣＩ−Ｅ規格、またはＱｕｉｃｋＰａｔｈインターコネクト（ＱＰＩ）もしくはＵｌｔｒａＰａｔｈインターコネクト（ＵＰＩ）などの他のインターコネクトを実装するバスを介して、プライマリＣＰＵ（複数可）からアクセス可能なカード）上に配置された１つまたは複数のプロセッサが、様々な実施形態において、オフロードされたタスクの少なくともいくつかのために用いられ得る。他の実施形態では、いくつかのオフロードされた仮想化管理タスクは、仮想化ホストの外部のコンピューティングデバイスにおいて、例えば、ゲスト仮想マシンが動作する仮想化ホストからネットワーク接続を介してアクセス可能な別のホストにおいて実装され得る。オフロードされたタスクの実装に関与するファームウェア及び／またはソフトウェアのコンポーネントは、一般に、本明細書中で、オフロードされた仮想化マネージャコンポーネント（ＯＶＭＣ）またはオフロードされた仮想化管理コンポーネントと称され得る。仮想化コントローラ及びネットワーク処理オフローダといった、様々な実施形態において用いられ得るいくつかの異なるＯＶＭＣの例が、以下に、より詳細に記載される。

少なくとも一部の実施形態では、ゲスト仮想マシンの管理に関連する作業負荷は、より大きい部分とより小さい部分に高いレベルで分割され得、より大きい部分はオフロードされ、より小さい部分は仮想化ホスト上で動作するオポチュニスティックハイパーバイザによって実装される。以下にさらなる詳細が論じられるように、ハイパーバイザは、主にゲスト仮想マシンによる物理ＣＰＵの自発的な放棄の結果として機会がもたらされたとき（例えば、ゲスト仮想マシンが、入力／出力動作を行う、タイマー値を読み出す、またはゲスト仮想マシンが自らでは完了することはできない何らかの他の動作を行う必要があるとき）に、ホストの物理ＣＰＵをハイパーバイザが利用するという点で、オポチュニスティックであるとして記載され得る。デフォルトでは、ハイパーバイザのサブコンポーネントのプロセスの一部または全ては、休止またはアイドル状態を保っていてもよい（すなわちＣＰＵサイクルを消費しない）。大部分の動作条件下で、サブコンポーネントの１つまたは複数は、ゲスト仮想マシンが物理ＣＰＵを放棄したときのみ休止状態からアクティブ状態に遷移し得る。ハイパーバイザが行う未処理の仮想化管理タスクを備えるキューまたは同様の論理データ構造は、一部のそうした実施形態で保持され得、タスクエントリは、オフロードされた仮想化マネージャコンポーネント（場合によっては、仮想化コンピューティングサービスの制御プレーンコンポーネントからタスクの一部に対する要求を順次受信していてもよい）の要求でキューに追加される。オポチュニスティックハイパーバイザが物理ＣＰＵを利用可能になると、キューから未処理タスクを取得し、対応する動作を行い、そして物理ＣＰＵを放棄して、ゲスト仮想マシンがその処理を再開することを可能にし得る。

一部の実施形態では、オポチュニスティックハイパーバイザによって処理される仮想化管理タスクは、例えばタスクの期待持続時間またはそれらの相対的な複雑性に基づいて、少なくとも２つのカテゴリに分類され得る。より短いまたはより簡単なタスクは完全に実行され得、より複雑な、またはより長いタスクは、それぞれのサブタスクにその状態遷移が対応する状態マシンを用いて扱われ得る。かくして、例えば、長いタスクＴ１は、Ｎ個の異なるサブタスク、ＳＴ１、ＳＴ２、．．．ＳＴＮに分割され得る。オポチュニスティックハイパーバイザに物理ＣＰＵを利用する機会が与えられ、ハイパーバイザが、Ｔ１はまだ完了していないと判定すると、一部の実施形態では、Ｔ１の次の未終了のサブタスクＳＴｋが、Ｔ１の永続的状態マシン表現を用いて識別され得る。そしてハイパーバイザはＳＴｋを実行し、それを行ったことを示すように永続的状態マシンを更新し、ゲスト仮想マシンに対して物理ＣＰＵを放棄し得る。一般に、オポチュニスティックハイパーバイザは、ホストの物理ＣＰＵ（複数可）のその使用を最小化するように、かつ、主にゲスト仮想マシンが少なくともいくらかの期間（例えば、Ｉ／Ｏ動作を完了するのに必要な時間）物理ＣＰＵの使用を見込まないときに物理ＣＰＵを使用するように設計され得る。仮想化管理タスクのそうしたオポチュニスティックなスケジューリングの結果、少なくとも一部の実施形態では、ゲスト仮想マシンで開始される様々なタイプのトランザクションまたは動作のパフォーマンスの変動が実質的に低減され得る。例えば、所与のゲスト仮想マシンが時間依存のトランザクションを含むアプリケーションに対して用いられる場合、トランザクション応答時間のばらつきは、オポチュニスティックハイパーバイザの採用によって、最小化または少なくされ得る（例えば、他の仮想化管理技術と比較して）。アプリケーション動作、特に持続時間の短い時間依存の動作の応答性のばらつきは、本明細書中で、「ジッター」または「ＣＰＵジッター」と称され得る。

少なくとも一部の実施形態では、仮想化マネージャは、プロバイダネットワークの仮想化コンピューティングサービスに実装され得る。分散されたクライアントのセットにインターネット及び／または他のネットワークを介してアクセス可能な１つまたは複数のネットワークアクセス可能なサービス（様々な種類のクラウドベースのコンピューティングまたはストレージサービスなど）を提供するために企業または公共部門機関などのエンティティによって構築されたネットワークは、本明細書中では、プロバイダネットワークと称され得る。プロバイダネットワークは、「パブリッククラウド」環境と呼ばれる場合もある。プロバイダネットワークのリソースは、場合によっては、複数のデータセンターに分散されてもよく、データセンターは多数の都市、州、国に分散されてもよい。少なくとも一実施形態では、本明細書中に記載される仮想化マネージャの種類は、プロバイダネットワークの外部のデータセンターに位置するホストに配置され得る。例えば、仮想化コンピューティングサービスの様々な管理用のまたは制御プレーンコンポーネントは、プロバイダネットワーク内で実行され得、そのような制御プレーンコンポーネントは、顧客所有のデータセンターに（またはプロバイダネットワークの外部の何らかの他の施設に）位置する仮想化ホストで動作している部分的にオフロードされた仮想化マネージャと通信し得る。

仮想化コンピューティングサービスは、少なくとも一部の実施形態では、ゲスト仮想マシンを仮想化ホストに割り当てるマルチテナントモードをサポートし得る。マルチテナントモードでは、所与の仮想化ホストを用いて、いくつかの異なる顧客に対するそれぞれのゲスト仮想マシンのインスタンスを作成し得る。逆に、様々な実施形態でやはり、または代わりにサポートされ得る単一テナントモードでは、所与の仮想化ホストは、単一のクライアントのゲスト仮想マシン（複数可）にのみ用いられ得る。特にマルチテナントモードでは、かつ、単一テナントモードでさえ、クライアントのセキュリティ及び／または分離の要件を満たすことを確保するのは重大なことであり得る。仮想化コンピューティングサービスプロバイダの観点からすれば、仮想化マネージャコンポーネントは、それらのセキュリティ機構が外部攻撃またはバグによって破られることが成功不可能（非常に高い確率で）なように設計されるべきことが理想である。万が一破られた場合、破られたことは可能な限り速く特定されるべきであり、破られたことによる影響を低減させる改善措置がとられるべきである（仮想化マネージャを無効にするまたはシャットダウンするなどの）。

これら及び他のセキュリティ要件を満たすことを助けるために、少なくとも一部の実施形態では、部分的にオフロードされた仮想化マネージャに対して、セキュアな多段階ブート手順が実装され得る。仮想化コントローラ（仮想化マネージャのオフロードされたコンポーネントの１つ）は、様々な実施形態において、所与の仮想化ホストでセキュアなブート手順を編成することに関与し得る。仮想化ホストのコンポーネントを製造する際に、選択されたセキュリティ鍵ペアの公開鍵が、１つまたは複数のオフロードされた仮想化マネージャコンポーネント（仮想化コントローラを含む）が動作予定のカード上に搭載された耐タンパー性デバイスに焼かれ得る。鍵ペアの秘密鍵は、例えば仮想化コンピューティングサービスに（例えば、プロバイダネットワークに実装されたＨＳＭサービスを介して）アクセス可能なハードウェアセキュリティモジュール（ＨＳＭ）機器に別途格納され得る。様々な実施形態では、ブート手順の第１の段階において、公開鍵を用いて、１つまたは複数のファームウェアプログラムの署名を認証し得る。オフロードカードのハードウェアに焼かれた鍵を用いてセキュリティが実行される第１の段階は、通常、仮想化ホストのライフタイム中に変更／更新される確率が低いファームウェア（例えば、オフロードカード上のシリアルペリフェラルインターフェース（ＳＰＩ）フラッシュストレージに格納されている）を実行することを備え得る。少なくとも一部の実施形態では、第１の段階中にロードされたファームウェアの少なくとも一部は、第１の段階が終了した後で用いられなくてもよい。つまり、ブートの第１の段階が完了した後、第１の段階中にロードされたプログラムは、次回のブートまで再度必要とされなくてもよい。第１の段階が失敗した場合（例えば、ファームウェアプログラムの署名を、焼かれた鍵を用いて検証することができない場合）、少なくとも一実施形態では、仮想化ホストはブート不能（またはブートが非常に難しい）と見なされ得る。

第１の段階が成功した場合、様々な実施形態では、ブート手順の第２の段階が開始され得、第２の段階において、様々なファームウェア／ソフトウェアプログラムが、セキュリティモジュール（少なくとも一部の実装例ではやはりオフロードカード上に搭載されている）を用いて「測定され」得る。一部の実施形態では、セキュリティモジュールは、Ｔｒｕｓｔｅｄ Ｃｏｍｐｕｔｉｎｇ Ｇｒｏｕｐコンソーシアムによって策定され、Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｏｒｇａｎｉｚａｔｉｏｎ ｆｏｒ Ｓｔａｎｄａｒｄｉｚａｔｉｏｎ及びＩｎｔｅｒｎａｔｉｏｎａｌ Ｅｌｅｃｔｒｏｔｅｃｈｎｉｃａｌ Ｃｏｍｍｉｓｓｉｏｎ（ＩＳＯ／ＩＥＣ）によって承認された様々なバージョンのトラステッドプラットフォームモジュール仕様のいずれかといった、標準化機構によって承認された仕様にしたがって実装され得る。そうした実施形態において、セキュリティモジュールは、トラステッドプラットフォームモジュールすなわちＴＰＭと称され得る。他の実施形態では、必ずしも完全にＴＰＭ仕様に準拠しないがＴＰＭと同様のセキュリティ関連の特徴をサポートする他のハードウェアコンポーネントまたはデバイスが用いられ得る。以下の記載の大半において、ＴＰＭは、ブート時に、及びホストのソフトウェア状態をチェックするなどの他の動作において、仮想化マネージャによって用いられるセキュリティモジュールの主な例として用いられ得るが、本明細書中に記載されるＴＰＭを利用するアルゴリズムは、ＴＰＭ以外のタイプのセキュリティモジュールが利用可能である実施形態で同じ成果をもって用いられ得る。ＴＰＭなどのセキュリティモジュールは、以下にさらに詳細が論じられるように、様々な暗号化、ハッシング及びランダムナンバー関連の動作で用いられ得る。ＴＰＭによってサポートされる機能の１つは、プロセッサ制御レジスタ（ＰＣＲ）のセットに格納されたハッシュ値を用いてソフトウェア／ファームウェアの状態（そして状態変化）の証拠を格納することであり得る。選択されたＰＣＲを用いて所与のソフトウェア／ファームウェアプログラムＭ１を測定する際、ＰＣＲの現在の内容（Ｈ１）（例えば、ＰＣＲに用いられる何らかの初期値、または何らかの他のソフトウェア／ファームウェアプログラムに対応するハッシュ値）及びプログラムＭ１の内容に基づく暗号強度ハッシュ値Ｈ２が生成され得る。次いで、ＰＣＲの以前の状態及び「測定され」ているプログラム次第である新しいハッシュ値Ｈ２は、「ＰＣＲのＭ１による拡張」と称される動作において、ＰＣＲに格納され得る。実際には、ＰＣＲ拡張機構により、一連の変化またはイベントの履歴が、偽造は（ほぼ）不可能であるが同時に検証可能ではあるように（例えば、一連のハッシュ演算を、期待される、または既知のバージョンのプログラム上で実行し、ＰＣＲの内容をシーケンスの最終的な結果と比較することによって）ハードウェアに格納されることが可能となり得る。ブート手順のこの第２の「測定」段階において、様々な実施形態では、ロードされているファームウェア／ソフトウェアの正確なバージョンの証拠がこのようにしてＴＰＭのＰＣＲの１つまたは複数に格納され得る。ブートの第１の段階で用いられるファームウェアとは逆に、第２の段階でロードされるファームウェアの新しいバージョンは、一部の実施形態において、少なくとも時々、仮想化ホストのライフタイム中に配備され得、次いで、変更されたバージョンのハッシュベースの測定値が、セキュリティモジュールから利用可能となり得る。

ブート手順の第２の段階が終了する少し前に、仮想化コントローラの特殊なストリップドダウンまたは最小バージョンが、様々な実施形態において、オフロードカードの１つまたは複数のプロセッサで起動され得る。特殊な最小バージョンを用いることの主要な目的には、仮想化コントローラのよりフル機能なバージョンへのライブアップデートを行うことを可能にするのに十分な機能性を提供することが含まれ得る。この異なるバージョンは、オフロードカードで、暗号化されたストレージデバイス（例えば、別のフラッシュメモリコンポーネントまたはソリッドステートドライブ）から取得され得る。異なるバージョンを復号化するのに用いられる鍵はセキュリティモジュールに格納され得、セキュリティモジュールの状態（例えば１つまたは複数のＰＣＲ値）がブート手順の前の段階が成功したことを示す場合に仮想化コントローラの最小バージョンに対して利用可能になされるのみであり得る。仮想化コントローラの新しいバージョンのために用いられるストレージデバイスが最初に暗号化される（一番初めにホストが立ち上げられるとき）やり方に関する詳細を以下に提供する。その後、仮想化コントローラの異なるフル機能のバージョンは起動されて、最小バージョンを置き換え得る（すなわち、最小バージョンが動作していたプロセッサと同じオフロードデバイスプロセッサ（複数可）上で）。このインプレース置換技術は、経時的に仮想化コントローラのいくつかの新しいバージョンを配備するのに潜在的に用いられ得、例えば、「測定する」段階が終了する少し前、いずれの場合にも同一の最小バージョンが最初に起動される。

仮想化コントローラのフル機能バージョンの準備が整った後、署名チェックは、様々な実施形態において、部分的にオフロードされた仮想化マネージャの様々な他のコンポーネント（例えばネットワーク処理オフローダ及び／またはハイパーバイザ）の初期化または起動に対するセキュリティ機構として用いられ得る。これらの追加のコンポーネントは、様々な実施形態では、やはりオフロードカード（例えば、仮想化コントローラが動作するのと同一のカードまたは異なるオフロードカードのいずれか）で動作し得るものもあり、仮想化ホストのプライマリＣＰＵで動作し得るものもある。仮想化コントローラのフル機能バージョンは、様々な実施形態では、例えば以下に論じるようにホスト識別管理サービスとの相互作用を介して、様々なソフトウェア及び／またはファームウェアの新しいバージョンが仮想化ホストのライフタイム中に仮想化ホストで安全に取得され得るように、仮想化ホストを仮想化コンピューティングサービスのネットワークセキュリティインフラストラクチャに登録することに関与し得る。仮想化マネージャのコンポーネントの全ての起動に成功し、多段階のセキュアなブート手順が完了した後、通常の仮想化管理動作が仮想コンピューティングサービスのクライアントに代わって開始され得る−例えば、ゲスト仮想マシンが、要求に応じて、仮想化マネージャによってインスタンス作成（または終了）され得る。セキュリティ関連のエラーによってブートの動作のいずれかが失敗した場合、仮想化ホストはブート不能状態に置かれる（エラーが第１の段階中に起きた場合）か、または、失敗の証拠がＴＰＭ及び／またはネットワークセキュリティインフラストラクチャコンポーネントを用いて追跡可能となる。

少なくとも一部の実施形態では、仮想化ホストのメインメモリの大部分に対するメモリ割当て決定は、オフロードされた仮想化マネージャコンポーネントによって処理され得、それによって、さらにオポチュニスティックハイパーバイザの作業負荷を減らし、ハイパーバイザのライブアップデートが行われることを可能にする。そうした実施形態の１つでは、メインメモリの１つのセクション（例えば、数ギガバイトのうち数百メガバイト）は、オポチュニスティックハイパーバイザのために確保され得、残りのセクションの割当ては、オフロードされたコンポーネント（仮想化コーディネータのメモリアロケータなど）によって管理され得る。ハイパーバイザが立ち上げられた後（例えば、上述した多段階ブート手順が終了する少し前）、オフロードされたコンポーネントは、メモリインベントリクエリをハイパーバイザに送信し得、ゲスト仮想マシンに利用可能なメインメモリ（オフロードされたコンポーネントによって個々のゲスト仮想マシンに割り当てられる）の量を示す応答が提供され得る。新しいゲスト仮想マシンが起動されると、ゲスト仮想マシンに（及び、ゲスト仮想マシンのデバイス状態情報などのメタデータに）用いられる物理メモリの特定の部分が、オフロードされた仮想化マネージャコンポーネントによって、利用可能なメモリから選択され得る。ハイパーバイザには、オフロードされた仮想マネージャコンポーネントによって、ゲスト仮想マシンに対する割当て決定に関して通知がされ得る。ハイパーバイザは、ハイパーバイザによって管理されるセクション内でメモリ割当てのために自らのページテーブルを（例えば、４キロバイトといった相対的に小さなページサイズで）セットし得、一方、それぞれのゲスト仮想マシンに対するページテーブルの場所（ハイパーバイザと異なるページサイズを用い得る）は、オフロードされた仮想化マネージャコンポーネントによって選択され得る。ゲスト仮想マシンのページテーブルに用いられる特定のメモリ領域（複数可）は、少なくとも一部の実施形態では、オフロードされた仮想化マネージャコンポーネントによって選択され得、選択された領域（複数可）の表示が、ハイパーバイザに、データ構造で（本明細書中でページングメタデータと称され得る）提供され得る。次いで、ハイパーバイザは、データ構造に含まれる情報を用いて、ゲスト仮想マシンに対するページテーブルをセットし得る。少なくとも一部の実施形態では、メインメモリのハイパーバイザによって管理されるセクションの一部は、ハイパーバイザのライブアップデートのために確保され得る（例えば、ハイパーバイザの新しいバージョンを表す実行可能イメージを格納するために）。ハイパーバイザのメモリ管理及びライブアップデートに関するさらなる詳細を以下に提供する。

例示的なシステム環境
図１は、少なくとも一部の実施形態による、部分的にオフロードされた仮想化マネージャが仮想化コンピューティングサービスで用いられ得る例示的なシステム環境を示す。示すように、システム１００は、様々なクライアント１２０の代わりに複数のネットワークアクセス可能なサービスが実装され得るプロバイダネットワーク１０２を備える。プロバイダネットワークのサービスは、描かれた実施形態では、とりわけ、仮想化コンピューティングサービス（ＶＣＳ）１３２、ならびに、ブロックデバイスストレージサービス１６０（ブロックデバイスレベルプログラマチックインターフェースを介して記憶容量を提供する）及びオブジェクトストレージサービス１７０（非構造化ストレージオブジェクトにアクセスするためのウェブサービスインターフェースを公開する）を含むいくつかのストレージに関するサービスを含み得る。様々な実施形態では、ハードウェアセキュリティモジュール（ＨＳＭ）機器サービス１５０を含むいくつかのセキュリティに関するサービスもプロバイダネットワークでサポートされ得る。サービスのいくつかは、クライアントの要求を満たすために他のサービスを使用し得る−例えば、描かれた実施形態では、仮想化コンピューティングサービスのゲスト仮想マシンのために用いられる永続ストレージの少なくとも一部は、ストレージサービスの１つまたは複数を介して取得され得る、仮想化コンピューティングサービスに関連するセキュリティ鍵は、ＨＳＭサービスに格納され得るなどである。

ＶＣＳ１３２は、描かれた実施形態では、仮想化ホストフリート１４５及び制御プレーンフリート１４０を備え得る。ホストフリート１４５の仮想化ホスト１３４は、ゲスト仮想マシン（ＧＶＭ）１３８のインスタンスを作成するのに用いられ得る。例えば、仮想化ホスト１３４Ａは、ＧＶＭ１３８Ａ及び１３８Ｂを備え得、仮想化ホスト１３４Ｂは、ＧＶＭ１３８Ｋを備える。ＧＶＭは、クライアント１２０によって使用されて各種アプリケーションを動作させ得、それらのいくつかは、プロバイダネットワーク１０２の他のサービスのリソースの使用を含み得、及び／または、プロバイダネットワーク１０２外のリソースの使用を含み得る。仮想化ホスト１３４の少なくともいくつかは、描かれた実施形態では、それぞれ部分的にオフロードされた仮想化マネージャ（ＰＶＭ）１３６を備え得る。例えば、ホスト１３４ＡはＰＶＭ１３６Ａを備え、ホスト１３４ＢはＰＶＭ１３６Ｂを備えるなどである。上述したように、ＰＶＭが用いられるシナリオでは、仮想化ホスト１３４のローカルゲスト仮想マシン１３８の管理を管理することへの全体の関与は、オポチュニスティックハイパーバイザ（仮想化ホストのプライマリＣＰＵを用いる）とオフロードカード（ＰＣＩ−Ｅカードまたはペリフェラルインターコネクトを介して接続された他のカードなど）上に搭載されたプロセッサ上で動作し得る１つまたは複数の他の仮想化管理コンポーネントの間で分割され得る。

ＰＶＭ手法は、クライアントによって要求されるＧＶＭにおいて代わりに配備することができる仮想化ホストのリソース（メインＣＰＵ及びメインメモリなど）を消費する仮想化管理の作業負荷を減らすように設計され得る。様々な実施形態では、ネットワークプロトコル処理（例えば、ＶＣＳで用いられているカプセル化プロトコルに対する）及びもっと言えばゲスト仮想マシンに対するメモリ割当てといった仮想化管理タスクは、以下に論じるように、オフロードされた仮想化マネージャコンポーネントで完全に、または主に行われ得る。ハイパーバイザそれ自体のＣＰＵ使用及びメモリフットプリントは、様々な実施形態で、最少化され得る−例えば、ハイパーバイザのサブコンポーネントの大部分または全ては、デフォルトで休止またはアイドルを保っていてもよく、主に物理ＣＰＵがゲスト仮想マシン１３８によって放棄された場合に、仮想化管理タスクを行う。ＧＶＭが（例外的な状況下を除き）ハイパーバイザによって割り込まれることなく、必要な間物理ＣＰＵサイクルを消費することが可能にされたハイパーバイザ挙動のデフォルトでの休止モードの結果、様々なアプリケーション動作のパフォーマンスのばらつきは低減され得る。セキュリティ鍵、ＴＰＭ測定値などの組み合わせを含むセキュアな多段階ブート手順が、仮想化マネージャコンポーネント自体のために用いられ得る。仮想化マネージャコンポーネントが置き換えられる、またはアップグレードされる必要があるときゲスト仮想マシンのリブートを回避するという全体的な目的をもって、様々なＰＶＭコンポーネントのチェーンローディング及び／またはライブアップデートがサポートされ得る。少なくとも一部の実施形態では、フリート１４５の全ての仮想化ホストが部分的にオフロードされた仮想化マネージャを利用し得るわけではないことに留意されたい。例えば、いくつかのホストは、それぞれの管理用の仮想マシン及び／または本格的な非オポチュニスティックハイパーバイザを備え得、仮想化管理処理をプライマリＣＰＵから迂回させるのに用いることができるオフロードカードを含まなくてもよい。

ＶＣＳ制御プレーンフリート１４０は、描かれた実施形態では、例えばホスト識別マネージャ１７２、配置マネージャ１７４、モニタリングマネージャ１７６などを含むいくつかのサブコンポーネントを備え得る。ホスト識別マネージャ１７２は、描かれた実施形態では、ホストとプロバイダネットワーク１０２の様々な他のコンポーネントの間の通信のセキュリティが強化されるように、ＶＣＳ１３２の公開鍵インフラストラクチャ内に仮想化ホスト１３４を登録し得る。配置マネージャ１７４は、どの仮想化ホスト（複数可）が１つまたは複数のＧＶＭ１３８に対する所与のクライアントの要求を満たすのに用いられるかを正確に判定することに関与し得る。場合によっては、仮想化ホストは、いくつかの異なるクライアントのＧＶＭが単一の仮想化ホストでインスタンス作成されるマルチテナントモードで用いられ得、場合によっては、ホストの少なくともいくつかは、単一のクライアント（単一テナントモード）のＧＶＭ専用であってもよい。モニタリングマネージャ１７６は、ハイパーバイザのサブコンポーネントによって及び／またはオフロードされた仮想化マネージャコンポーネントによって初期に取得され得るメトリクスを含む、個々のＧＶＭ１３８及び／またはホスト１３４に関連する様々なメトリクス（例えば、パフォーマンス測定値、健康状態インジケータなど）を収集し得る。

ＶＣＳ１３２は、描かれた実施形態では、クライアント１３２が、取得、解放、ゲスト仮想マシン１３８との相互作用の要求を送信することを可能にするクライアントフェーシングプログラマチックインターフェース１６０（例えば、アプリケーションプログラミングインターフェースすなわちＡＰＩ、ウェブベースのコンソール、コマンドラインツール、グラフィカルユーザインターフェースなど）のセットを実装し得る。例えば、「ｌａｕｎｃｈＧＶＭｓ」要求またはコマンドの同等物は、指定された特徴を有する１つまたは複数のＧＶＭ１３８のインスタンスを作成するのに用いられ得、「ｔｅｒｍｉｎａｔｅＧＶＭｓ」コマンドまたは要求の同等物は、クライアントのＧＶＭの１つまたは複数を無効にするのに用いられ得る。一般に、ＶＣＳ１３２の制御プレーンコンポーネントで受信されるクライアント要求は、内部形式に変換され、実装のための適切な仮想化ホストにおいてＰＶＭに送信され得る。ＰＶＭ自体内で、一部の実施形態では、オフロードされたコンポーネントがまず内部コマンド／要求を受信し得、必要な場合は実装のためにオポチュニスティックハイパーバイザにコマンド／要求の何らかのバージョンを渡す（例えば、ＧＶＭによるホストリソースの使用に割り込まないように非同期のキューベースのプロトコルを用いて）。ＶＣＳ１３２で用いられ得る様々な低オーバーヘッドのセキュアな仮想化管理技術の様々な態様の詳細を以下に提供する。

例示的な仮想化ホストコンポーネント
図２は、少なくとも一部の実施形態による、仮想化ホストの例示的なコンポーネントを示す。示すように、仮想化ホスト２０２は、プライマリ物理プロセッサセット２０４、メインメモリ（例えば、ランダムアクセスメモリすなわちＲＡＭの１つまたは複数のモジュール）２０８、部分的にオフロードされた仮想化マネージャ（ＰＶＭ）２７０及びＧＶＭ２５０Ａ〜２５０Ｃなどのゼロ以上のゲスト仮想マシンＧＶＭ２５０を備え得る。（仮想化ホスト２０２はまた、混乱を避けるために図２に示さないが、例えば様々な永続ストレージデバイスといったいくつかの他のコンポーネントも備え得る。）プライマリ物理プロセッサセット２０４は、描かれた実施形態では、ｐＣＰＵ２０５Ａ〜２０５Ｃを含むいくつかの物理ＣＰＵ（ｐＣＰＵ）を備え得る。ｖＣＰＵまたは仮想ＣＰＵと呼ばれるｐＣＰＵの仮想化バージョンは、ＧＶＭのライフタイム中に、ＰＶＭ２７０によって個々のＧＶＭに割り当てられ得る。各ＧＶＭ２５０は、動作システムのそれぞれのインスタンス（例えば、オペレーティングシステム２５２Ａ〜２５２Ｃ）、及び、仮想化コンピューティングサービスのクライアントに代わって動作しているアプリケーションのセット（例えば２５４Ａ〜２５４Ｃ）を備え得る。

ＰＶＭ２７０は、描かれた実施形態では、オポチュニスティックストリップドダウンハイパーバイザ２２０（ｐＣＰＵを用いる）、及びｐＣＰＵを用いない１つまたは複数のオフロードされた仮想化マネージャコンポーネント（ＯＶＭＣ）２７２を備え得る。ＯＶＭＣ２７２は、例えば、仮想化コントローラ２１５及びネットワーク処理オフローダ２１６を含み得る。ＯＶＭＣのそれぞれは、一部の実施形態では、それぞれのシステムオンチップ設計を用いて実装され得る。描かれた実施形態では両方のＯＶＭＣ２７２は単一のオフロードカード２１０（例えばＰＣＩ−Ｅカード）内に組み込まれるとして示されるが、異なる実施形態では、ＯＶＭＣの配置及び機構に関する他の手法が用いられ得る。例えば、一実施形態において、単一のシステムオンチップ実装を用いて、仮想化コントローラ及びネットワーク処理オフローダの機能を実行し得、それによって、２つの異なるＯＶＭＣの必要性がなくなる。別の実施形態では、仮想化コントローラ２１５及びネットワーク処理オフローダ２１６に対してそれぞれのオフロードカードが用いられ得る。仮想化コントローラは、その名前によって示唆されるように、描かれた実施形態では、ホスト２０２で行われる仮想化管理作業の多くを調整または編成することに関与し得る−例えば、仮想化コントローラは、以下に論じるようにＰＶＭのコンポーネントの中で最初に、ブートし、ＰＶＭの他のコンポーネントの起動をトリガし、ＶＣＳ制御プレーンと通信し、ゲスト仮想マシンに対するメモリ割当て決定を行うなどし得る。ネットワーク処理オフローダ２１６は、描かれた実施形態では、１つまたは複数のネットワーキングプロトコル（例えば、ＶＣＳ内で用いられるカプセル化プロトコルを含む）を実装すること、及び、ＧＶＭと仮想化ホストの外部のネットワーキングエンドポイントの間の仲介役として機能することに関与し得る。

ハイパーバイザ２２０は、描かれた実施形態では、少なくともいくつかの従来のハイパーバイザによって行われる作業の多くが代わりにＯＶＭＣ２７２によって処理され得、それによってハイパーバイザ２２０の複雑性及びサイズが低減するので、ストリップドダウンとして記載され得る。加えて、ハイパーバイザ２２０は、ほとんどの状況下で、ハイパーバイザがＣＰＵサイクルを用いる前、ＧＶＭがｐＣＰＵ２０５の制御を自発的に放棄するまで待機し得るので、オポチュニスティックとして表され得る。かくして、例えば、特定のＧＶＭ１３８がＩ／Ｏ要求（Ｉ／Ｏは完了に約Ｔ１の時間がかかることが見込まれる）を発行し、Ｉ／Ｏ要求に対する応答が受信されるまでｐＣＰＵを明け渡すと、ハイパーバイザはこの機会を利用して、ＧＶＭがｐＣＰＵの使用を見込まない間、ｐＣＰＵを用いて１つまたは複数の仮想化管理タスク（通常時間Ｔ２がかかり得る、Ｔ２＜＜Ｔ１）を行い得る。このようにして、ハイパーバイザ２２０は、描かれた実施形態では、アプリケーション２５４のパフォーマンスに与える影響は最小限であり得る。

ハイパーバイザ２２０は、描かれた実施形態では、それ自体に、オペレーティングシステムカーネルレベルコンポーネントのセット２２２、ハイパーバイザコーディネータ２２５、１つまたは複数のＧＶＭマネージャ２２８、分離／セキュリティコンポーネント２２９及び／またはメッセージングマネージャ２３１を含むいくつかのサブコンポーネントを備え得る。ハイパーバイザコーディネータ２２５、ＧＶＭマネージャ２２８のそれぞれ、分離／セキュリティコンポーネント２２９及び／またはメッセージングマネージャ２３１は、少なくとも一部の実施形態では、それぞれのユーザモードプロセスとして実装され得る。様々な実施形態では、これらのコンポーネントの少なくともいくつかは、簡易な特化されたプロトコルを用いてパイプを介して互いに通信するそれぞれの静的にリンクされたプログラムのインスタンスとして実装され得る。ハイパーバイザのサブコンポーネントは、記述された実施形態では、デフォルトで受動的な、または休止のままでもよく、イベント（他のサブコンポーネントからのメッセージ、ＧＶＭによって開始されたコンテキストの切替えなどといった）に応じてのみ反応しアクティブ化する。一部の実装例では、例えば、ハイパーバイザのサブコンポーネントのいくつかは、通常、大部分の時間、ポーリングシステムコール（ｅｐｏｌｌ（）または同等物などの）でブロックされたままであってもよい。

カーネルレベルコンポーネント２２２は、ＧＶＭによって発行されたＶＭ ｅｘｉｔ命令（例えば、ＧＶＭがｐＣＰＵを明け渡すとき）への初期応答などの様々な低レベルの演算に対するサポートを提供し得る。ハイパーバイザコーディネータ２２５は、その名前から示されるように、他のサブコンポーネントの動作を編成することに関与し得る。ハイパーバイザコーディネータ２２５は、例えば、ＯＶＭＣ２７２とハイパーバイザの間の通信に対して用いることができるＡＰＩを実装し得、ＧＶＭの起動及び終了を開始する（例えば、ＯＶＭＣの要求により）、ＧＶＭマネージャによって収集されたメトリクスを公開する、デバッグ機能を提供するなどを行う。

各ＧＶＭマネージャ２２８は、コーディネータ２２５によって提供される仕様に基づいて各ＧＶＭを起動またはインスタンス作成すること、ＧＶＭのメトリクス及びログをモニタリングすることなどに関与し得る。一部の実施形態では、ＧＶＭマネージャ２２８はまた、例えばＧＶＭのＩ／Ｏ要求をトラップし、それらをＯＶＭＣの助けを得て完了するメモリマップドＩ／Ｏ動作に変換することによって、特定のデバイスに対するＧＶＭによって要求されたＩ／Ｏ動作を支援し得る。少なくとも一部の実施形態では、セキュリティに関する最小権限の原則にしたがって、ＧＶＭマネージャ２３８は、ＧＶＭのインスタンス作成中に、可能な限り早く、自身の権限の多くを下げ得る。例えば、１つまたは複数のｖＰＣＵ（仮想ＣＰＵ）スレッドがＧＶＭに対して生成され、ＧＶＭのメモリがマッピングされた後、ＧＶＭマネージャは、その権限のいくつかを無効にして、セキュリティが破られる機会を減少させ得る。一実施形態では、ＧＶＭマネージャ２２８は、ＧＶＭメモリのランダムサンプルが期待通りゼロに設定されているかどうかをチェックし得（一度にＧＶＭメモリ全体をチェックする代わりに）、それによって、ＧＶＭを立ち上げる速度を増加させる。一部の実施形態では、ＧＶＭマネージャとＧＶＭの間に１対１のマッピングがあってもよく、他の実施形態では、単一のＧＶＭマネージャが複数のＧＶＭに関与してもよい。

メッセージングマネージャ２３１は、例えば仮想化コントローラによってキューベースのプロトコルを用いて発行されたコマンドをハイパーバイザ内のパイプメッセージに変換することによって、仮想化コントローラ２１５とハイパーバイザの間の仲介役として機能し得る。セキュリティ及び分離コンポーネント２２９は、例えば、ＧＶＭ間のデータの不注意な共有を回避することができるように、ＧＶＭが終了するときにＧＶＭのメモリをスクラブまたはクリーンアップすることに関与し得る。ＰＶＭは少なくとも一部の実施形態では追加のコンポーネント（図２に示さず）を備え得、少なくとも一実施形態では、図２に示すＰＶＭコンポーネントの１つまたは複数は必要とされない場合があることに留意されたい。

例示的なオフロードカードコンポーネント
図３は、少なくとも一部の実施形態による、ホストにおける仮想化マネージャコンポーネントのサブセットに対するものであり得るオフロードカードの例示的なコンポーネントを示す。示すように、オフロードカード３０２は、オフローディングプロセッサ３１７Ａ及び３１７Ｂ（上述の仮想化ホストのプライマリｐＣＰＵとは区別されるような）のそれぞれのセットを有する一対のシステムオンチップ（ＳＯＣ）３１５及び３１６を備え得る。描かれた実施形態では、ＳＯＣの一方（例えば３１５）は仮想化コントローラのために用いられ得、他方はネットワーク処理オフローダのために用いられ得る。セキュアなブートＲＯＭ３２５は、以下にさらなる詳細を論じるように、仮想化コントローラによる多段階ブート動作の初期段階に対して用いられ得る。オフロードカード３０２はまた、ブート手順中に及び／またはブート後の状態検証で拡張的にやはり用いられ得るセキュリティモジュール（トラステッドプラットフォームモジュール（ＴＰＭ）など）３３０も含み得、ＴＰＭの例示的なサブコンポーネントは図４に示される。

加えて、オフロードカード３０２は、様々な実施形態では、いくつかの、ストレージに、電力に、及び接続性に関するコンポーネントを備え得る。例えば、１つまたは複数のフラッシュデバイス／インターフェース（またはＳＳＤ）３３５がオフロードカード内に組み込まれ得る。これらのデバイスは、例えば、様々な仮想化管理コンポーネント、ゲスト仮想マシンコンポーネントなどに対応するファームウェア及び／またはソフトウェアを格納するのに用いられ得る。ＰＣＩ−Ｅインターフェース３４０は、様々な実施形態では、ハイパーバイザと通信するために、及び／または、ＳＯＣ間の通信のために用いられ得る。他の実施形態では、様々な形態のＱｕｉｃｋＰａｔｈインターコネクト（ＱＰＩ）またはＵｌｔｒａＰａｔｈインターコネクト（ＵＰＩ）といった他のタイプのインターコネクト及び対応するインターフェースが用いられ得る。ネットワークインターフェース３４５は、一部の実施形態では、仮想化マネージャと仮想化コンピューティングサービスの制御プレーンの間の通信に対して用いられるとともに、少なくとも一実施形態では、ゲスト仮想マシンと様々なネットワークエンドポイントの間のデータプレーン通信に対して用いられ得る。オフロードカード３０２はまた、一部の実施形態では、例えば広範な停電の場合に少なくとも何らかの目的とした時間または日数の間ＯＶＭＣの動作を維持するために十分な電源３６０も備え得る。一部の実装例では、スーパーキャパシタベースの電源が用いられ得る。

一部の実施形態では、オフロードされた仮想化マネージャコンポーネントのために、同一のカード上の別々のＳＯＣが必要とされない場合もある。例えば、一実施形態では、仮想化コントローラ機能及びネットワークオフローディングタスクを行うことが可能な単一のＳＯＣが利用され得る。他の実施形態では、ネットワーク処理タスクを行うために、仮想化コントローラに対して用いられるのとは別のカードが用いられ得る。図３に示すオフロードカードコンポーネントのセットは包括的であることを意図せず、一部の実施形態では、タイマーなどといったいくつかの他のコンポーネントがカードに組み込まれ得る。様々な実装例では、図３に示すコンポーネントの少なくともいくつかは必要とされない場合がある。

図４は、少なくとも一部の実施形態による、仮想化マネージャによって用いられ得るトラステッドプラットフォームモジュール（ＴＰＭ）の例示的なコンポーネントを示す。先に論じたように、同様の機能性を提供するが必ずしもＴＰＭ基準または仕様に完全に準拠していない他のタイプのセキュリティモジュールまたはデバイスが様々な実施形態で用いられ得る。図３に示すように、トラステッドプラットフォームモジュールは、一部の実施形態では、仮想化コントローラを備えるオフロードカード内に組み込まれ得、他の実施形態では、ＴＰＭは、オフロードカードの外部に位置され得る（例えば、仮想化コントローラからバスまたは他のインターコネクトを介して連絡可能な別のカード上に、または、仮想化ホストの外部のデバイスに）。ＴＰＭを用いて実装される要求またはコマンドは、「トラステッドコンピューティング要求（ＴＣＲ）」と称され得る。一般に言って、例えば仮想化ホスト及び／またはＧＶＭのソフトウェア／ファームウェア構成を認証する要求、ハッシュ値または鍵といった暗号アーチファクトを生成及び／または格納する要求、構成状態が変わった場合に値を復号化することができないように対応する構成状態に暗号化された値を関連付けるすなわち「シール」する要求などを含むいくつかの異なるタイプのＴＣＲが、様々な実施形態でサポートされ得る。多段階ブートのコンテキストで以下に論じるように仮想化マネージャコンポーネントからの発信に加えて、ＴＣＲは、異なる実施形態では、ソフトウェアスタックのいくつかの異なる層から発信され得る。例えば、いくつかのＴＣＲは、ＧＶＭのアプリケーション層から（またはＴＰＭを備える仮想化ホストと通信する外部エンティティから）発信されてもよく、仮想化マネージャなどのソフトウェアの下位レベルからＴＰＭに送信される特定のコマンドシーケンスに変換されてもよい。他のＴＣＲは、オペレーティングシステム層、デバイスドライバ層などから発信されてもよい。

図４のＴＰＭ４１０は、描かれた実施形態では、他のコンポーネントの中でもとりわけ、Ｉ／Ｏインターフェース４８４、ＲＯＭ４７５、プラットフォーム構成レジスタ（ＰＣＲ）セット４７０、鍵セット４２４及び暗号プロセッサ４２６を備え得る。例えばローピンカウント（ＬＰＣ）バス、ＰＣＩ−Ｅバス、シリアルペリフェラルインターフェース（ＳＰＩ）バス、拡張シリアルペリフェラルインターフェース（ｅＳＰＩ）バス、集積回路間通信（Ｉ２Ｃ）バスなどを含むいくつかの異なるタイプの通信バスまたはインターコネクトが、異なる実装例では、Ｉ／Ｏインターフェース４８４を介して用いられ得る。ＲＯＭ４７５は、様々な実施形態では、ＴＰＭファームウェアに対して用いられ得る。

ＰＣＲ０〜ＰＣＲｋなどのいくつかの個々のＰＣＲを備えるＰＣＲセット４７０は、仮想化ホストの様々なコンポーネントに対応するハッシュ署名を格納するのに用いられ得る。特に、様々な実施形態では、ＰＣＲの１つまたは複数は、以下により詳細を論じるように、仮想化マネージャ自体のブートの際に用いられ得る。鍵セット４２４は、例えば、様々なＴＣＲに対して用いられる１つまたは複数のエンドースメント鍵、ストレージルート鍵及び／またはアテステーション鍵を含み得る。エンドースメント鍵は、一般に製造時に、ＴＰＭハードウェアに永続的に組み込まれる暗号鍵であってもよい。エンドースメント鍵は、少なくとも一部の実施形態では、ＴＰＭの外部で解除されなくてもよく、対応する公開鍵はＴＰＭそれ自体が真正であることを検証するのに用いられ得る。エンドースメント鍵は、データを暗号化するのにも用いられ得、対応する公開鍵を用いて、暗号化されたバージョンが後に復号化され得、それによって復号化がＴＰＭで行われたということが検証され得る。ストレージルート鍵は、一部の実施形態では、新しい鍵をＴＰＭなしで用いることができないように、ＧＶＭで、または仮想化マネージャコンポーネントで動作中のアプリケーションに代わって作成された新しい鍵を保護するために用いられ得る。ＴＰＭの製造時に作成及び格納され得るエンドースメント鍵とは異なり、ストレージルート鍵は、一部の実装例では、何らかのエンティティ（プロバイダネットワークアドミニストレータなど）がＴＰＭの所有権を取得したときに作成され得る。アテステーション鍵は、一部の実施形態では、プラットフォームアテスターとの相互作用で用いられ得て、例えば、仮想化ホストの共有コンポーネントが仮想化コンピューティングサービス及び／またはクライアントの要件を満たすことを検証する。

いくつかの異なるタイプの暗号値が、様々な実施形態では、暗号プロセッサ４２６を用いて取得され得る。例えば、暗号強度鍵（リベスト−シャミア−エイドルマン（ＲＳＡ）アルゴリズムまたは他の同様のアルゴリズムに関連する鍵など）は、鍵ジェネレータ４２８を用いて取得され得る。ＳＨＡ−１などのいくつかの形態のＳＨＡ（セキュアハッシュアルゴリズム）のいずれも、ハッシュジェネレータ４３２で用いられて、所望の質レベルを満たすハッシュ値を生成し得る。そのようなハッシュ値は、場合によっては、仮想化マネージャのブートプロセスの１つまたは複数の段階中に用いられてＰＣＲを拡張し得る。高品質なランダムノイズ値またはランダムナンバーは、描かれた実施形態では、ＲＮＧ（ランダムナンバー／ノイズジェネレータ）４３０を用いて取得され得る。単調に増加する連続番号は、連続番号ソース（複数可）４３４から取得され得、ノンス値として、または一意識別子を必要とする他のアプリケーションに対して用いられ得る。一部の実施形態では、他のタイプの暗号機能もまた、または、代わりに、ＴＰＭを用いて行われ得る。一部の実施形態では、対称暗号エンジン及び非対称暗号エンジンは両方ともＴＰＭに含まれ得、他の実施形態では、両方のタイプのエンジンの代わりに、対称暗号エンジンまたは非対称暗号エンジンのいずれかが含まれ得る。

様々な実施形態では、ＴＰＭは、鍵（以下で論じられるブート手順の後の段階に対して用いられる鍵を含む）などの様々なデータ項目の「シーリング」をサポートし得る。鍵などのオブジェクトがシールされると、ＰＣＲの選択されたセット（または全て）の内容は、鍵をシールする要求が受信された時点でＴＰＭに記録され得る。シールされたデータは、選択されたＰＣＲが、シーリング時に有していた値と同一の値を有する場合に抽出され得る。少なくとも一実施形態では、ＴＰＭは、ＧＶＭ固有のサブコンポーネントを、例えば、ＧＶＭ固有のＴＣＲではなくホスト単位で一般に用いられ得る図４に示すコンポーネントに加えて、含み得る。

多段階ブート手順
図５は、少なくとも一部の実施形態による、仮想化マネージャに対して用いられ得る例示的な多段階ブート手順の態様を示す。図５の左側に、様々な段階の概略が順番に示され、右側に、段階のうちいくつかにおいて用いられるプライマリセキュリティ技術が示される。多段階ブート手順は、少なくとも一部の実施形態では、仮想化ホストに電源が入ると開始し得る。初期のセキュアブート段階５０１では、１つまたは複数のファームウェアプログラムが読み込まれ（例えば、オフロードカードのＳＰＩフラッシュストレージから）、オフローディングプロセッサまたはプロセッサ（複数）で（例えば、仮想化コントローラが動作予定のオフロードカードで）実行され得る。この初期の（そして通常非常に短い）段階において、ファームウェアの署名は、ハードウェアに（例えば、ＴＰＭなどのセキュリティモジュール内に組み込まれてもよく、組み込まれなくてもよい、オフロードカードの耐タンパー性のまたはタンパープルーフの格納場所に）焼かれた公開鍵を用いて検証され得る。要素５０４に示すように、公開鍵が属する鍵ペアの対応する秘密鍵は、少なくとも一部の実施形態では、ハードウェアセキュリティモジュール機器に格納され得る。描かれた実施形態では、段階５０１で用いられるファームウェアは、通常、段階が完了した後で再使用される必要はなくてもよい。実際、長時間動作するであろう、または再使用されるであろうファームウェア（例えば、ブート手順の後半及び／またはブート後に、ＰＣＩ−Ｅ構成空間エミュレーションのために用いられるコードなどの）の導入は、ブート手順の第２の段階の開始を意味し得る。段階５０１で用いられるファームウェアは、描かれた実施形態では、仮想化ホストの有用なライフタイム中に変更されないままであることが見込まれ得、そのことは、ハードウェアに焼かれた鍵がその段階に対して適切なセキュリティ手段であり得ることの理由の１つである。逆に、段階５０１に続く段階で用いられるファームウェアまたはソフトウェアは、経時的に修正され得る（例えば、機能を拡張するために、またはバグを取り除くために）。

図５において測定ブート段階５０６と称される第２の段階では、要素５０９に示すように、実行または起動されるファームウェア／ソフトウェアプログラムの１つまたは複数が用いられて、セキュリティモジュールのＰＣＲ（またはいくつかのＰＣＲ）を拡張し得、それによって、プログラムの正確な（かつ偽造が難しい）証拠を残す。例えば、一実施形態では、特定のＰＣＲ、例えばＰＣＲ−ｋは、測定ブート段階において、各ファームウェアプログラムＭ１、Ｍ２及びＭ３ごとに１回で、３回拡張され得る。段階５０６の開始時に、ＰＣＲ−ｋにおいてＶ０を初期値（例えばゼロだけを含み得る）とする。Ｍ１がロード及び実行される直前に、セキュリティモジュールは、Ｖ０及びＭ１を入力としてハッシュ関数Ｈの値を計算し（例えば、図４に示すハッシュジェネレータ４３２または同等物を用いて）、その値をＰＣＲ−ｋに格納し得る。かくして、ＰＣＲ−ｋの新しい値は以下のように設定され得る：ＰＣＲ−ｋ←Ｈ（Ｖ０，Ｍ１）。次に、Ｍ２がロードされると、ＰＣＲ−ｋの現在値及び新しいプログラムＭ２をとるハッシュ関数の出力は、以下のように、ＰＣＲ−ｋに格納され得る：ＰＣＲ−ｋ←Ｈ（Ｈ（Ｖ０，Ｍ１），Ｍ２）。同様に、ＰＣＲ−ｋは、Ｍ３がロードされるときＭ３によって再度拡張され得、したがって、ＰＣＲ−０の最終値が以下のように設定される：ＰＣＲ−ｋ←Ｈ（Ｈ（Ｈ（Ｖ０，Ｍ１）,Ｍ２），Ｍ３）。結果的に、暗号強度ハッシュ関数が用いられると仮定すると、全てのプログラムの暗号強度表現、及びプログラムがアクティブ化されたシーケンスは、セキュリティモジュールに格納され得る。ロードされているファームウェア／ソフトウェアの「測定値」と称され得るＰＣＲ値は、様々な実施形態では、セキュリティモジュールのＩ／Ｏインターフェースを介してアクセス可能になされ得、そしてプログラムの期待されたバージョンが用いられたことを検証するのに用いられ得る。

測定ブート段階の終了時または終了する少し前に、仮想化コントローラの特殊な最小バージョン（本明細書中でＶｍｉｎとして示され得る）が、描かれた実施形態では、要素５１１に示すように、ロード及び起動され得る。様々なプログラムの測定値は１つまたは複数のＰＣＲを拡張することによって格納され得るので、このことは、ＰＣＲ（例えば、上記の例ではＰＣＲ−ｋ）がＶｍｉｎの内容に少なくとも部分的に基づいたハッシュ値を含むことを意味する。最小バージョンの主要な目的には、共通のベースラインに、仮想化コントローラのより本格的なバージョンが経時的に起動される（例えばチェーンローディングを介して）ことを可能にするだけの機能性を提供することが含まれ得る。チェーンローディングとは、例えば現在実行しているプログラムと新しいプログラムの間で情報を渡すための共通データ領域を用いて、現在実行しているプログラムを新しいプログラムで置き換えるのに用いられる技術である。ブート手順の初期段階（仮想化コントローラの新しい本格的なバージョンへのアップデートより前）がセキュリティを破られることなく行われたことを確保するために、要素５１４に示すように、ＰＣＲ（複数可）の内容が、チェーンローディングが開始される前にチェックされ得る。仮想化コントローラの本格的なバージョンＶ４がインストール予定の例示的なシナリオを検討すると、例えば、特定の年の６月１日である。その後、例えば１２月１日に、バージョンＶ５がインストール予定である。両方のケースで、初めの３段階（仮想化コントローラの特殊な最小バージョンであるＶｍｉｎのスタートアップまで）は同一であってもよく（それらの段階におけるファームウェアプログラムの変更がなかったと仮定）、したがってＶｍｉｎが立ち上げられたとき、ＴＰＭのＰＣＲに同一の値が格納され得、ブートの初期の段階で何も変更がなかったことが、ＰＣＲの内容を読み出すことによって検証され得る。６月のシナリオでは、Ｖｍｉｎは、Ｖ４によってチェーンローディングを介して置き換えられ得、１２月のシナリオでは、Ｖｍｉｎは直接Ｖ５によって置き換えられ得る（例えば、Ｖ４または他の中間のバージョンを通過する必要なく）。

仮想化コントローラの新しいバージョン（例えばＶｎｅｗ）は、少なくとも一部の実施形態では、オフロードカードからアクセス可能な暗号化されたストレージデバイス（例えば、フラッシュベースのデバイスまたはＳＳＤ）に格納され得る。Ｖｎｅｗを復号化するために、鍵は、セキュリティモジュールからＶｍｉｎによって取得されなければいけない場合がある（要素５０９に示すように）。描かれた実施形態では、セキュリティモジュールは、ＰＣＲ状態が、測定ブート段階などのブートの初期段階の成功したセキュアな完了を表す場合に鍵を提供するのみであり得る。かくして、少なくとも一部の実施形態では、何らかの形でブートの初期段階が攻撃され破られた場合、ＰＣＲ値は期待値と合致せず、Ｖｎｅｗへのライブアップデートはブロックされ得る。一部の実施形態では、要素５０１に対応する動作で用いられた鍵と同一の鍵がストレージデバイスに対して用いられ得、他の実施形態では、異なる鍵が用いられ得る。

要素５１６に示すように、仮想化コントローラの新しいバージョンＶｎｅｗは、描かれた実施形態では、セキュリティモジュールから取得された鍵を用いて、暗号化されたストレージデバイスから取得され得る。次いで、仮想化マネージャの追加のコンポーネント（その実行可能なバージョンもやはり暗号化されたストレージデバイスから取得され得る）が、仮想化コントローラの本格的なバージョンＶｎｅｗによって起動され得る（要素５２１）。先に論じたように、これらの追加のコンポーネントの少なくともいくつか（ハイパーバイザ及び／またはネットワーク処理オフローダなど）は、仮想化コントローラ自体に対して用いられるプロセッサ（複数可）以外のプロセッサ上で動作し得る。これらのコンポーネントの実行可能なバージョンは、様々な実施形態では、それらが暗号化されたストレージデバイスに書き込まれる前に、仮想化コンピューティングサービスの制御プレーンコンポーネントによって署名され得る。コンポーネントのそれぞれの署名は、要素５１９及び５２４に示すように、仮想化ホストが登録されている公開鍵インフラストラクチャを用いてチェックされ得る。ホストをそうしたインフラストラクチャに登録する手順が図７の文脈で以下に論じられる。

仮想化マネージャのコンポーネント（仮想化コントローラＶｎｅｗ、ネットワーク処理オフローダ、図２の文脈で論じられるオポチュニスティックハイパーバイザのサブコンポーネントなど）の全てがインスタンス作成に成功した後、多段階ブートは完了したと見なされ得る（要素５２６）。少なくとも一部の実施形態では、ハイパーバイザのサブコンポーネントの１つまたは複数は、先に論じたように、休止状態であり得る。次いで、仮想化マネージャは、ＧＶＭのインスタンス作成／起動の要求、既存のＧＶＭの終了要求、ホストのソフトウェア／ファームの状態の認証の要求などのＧＶＭに関する要求の処理を開始し得る。

暗号化されたストレージデバイスに対する初期鍵の生成
図６は、少なくとも一部の実施形態による、仮想化マネージャに関連する実行可能プログラムに対して用いられるストレージデバイスのセキュリティを高めるために行われ得る動作の態様を示す流れ図である。そうしたプログラムは、とりわけ、仮想化コントローラの本格的なバージョン（上記でＶｎｅｗと称される）、ハイパーバイザのバージョン及び／またはネットワーク処理オフローダのバージョンを含み得る。図６に描かれた実施形態においてセキュリティモジュールとしてＴＰＭが用いられるが、他のタイプのセキュリティモジュールが様々な実施形態で用いられ得る。要素６０１に示すように、仮想化ホストの初めてのブート（例えば、仮想化ホストが、製造及びテスト後にデータセンターにインストールされた後にブートされる全く初めての）が開始され得る。図５に示す最初のいくつかのブート段階は、Ｖｍｉｎが起動するときまでに（起動したときを含む）行われ得る（例えば、焼かれた鍵を用いて安全性が保証される第１のブート段階、及び測定ブート段階）（要素６０４）。

次いで、Ｖｍｉｎは、ストレージデバイスが有効状態にあるかどうかを、例えばストレージデバイスのヘッダ部の内容を検査することによってチェックしようと試み得る。ヘッダがヌルである（または、ストレージデバイスに対する暗号鍵がまだ生成されていないことを示す何らかの他の値を有する）場合、このことは、ストレージデバイスが無効状態にあることを示し得る（要素６０７）。次いで、Ｖｍｉｎは、描かれた実施形態では、ＴＰＭの暗号エンジンを用いて、ストレージデバイスに対する暗号鍵（例えば、ＡＥＳ−２５６−ＸＴＳなどのＡｄｖａｎｃｅｄ Ｅｎｃｒｙｐｔｉｏｎ Ｓｔａｎｄａｒｄに準拠した鍵）を生成し得る（要素６１０）。次いで、この鍵は、ＰＣＲの現在の内容（この時点で、要素６０４で記述されたブートプロセスの段階で生成されたハッシュ値を備える）を用いてＴＰＭでシールされ得る（要素６１３）。

描かれた実施形態では、鍵のシールされたバージョンは、ストレージデバイスのヘッダに配置され得（要素６１６）、それは、ストレージデバイスが適切に初期化されていることを示すものとして機能し得る。ストレージデバイスへのその後のアクセスにおいて（例えば、図５の要素５１１に対応する動作のように、仮想化コントローラの本格的なバージョンがストレージデバイスから取得される必要があるたびに）、鍵のシール解除されたバージョンがＴＰＭから取得されて、ストレージデバイスの内容を復号化し得る（要素６１９）。

ＶＣＳネットワークセキュリティインフラストラクチャにおける仮想化ホストの登録
各仮想化ホストは、そのライフタイム中に、仮想化コンピューティングサービス自体を含む１つまたは複数のサービスの制御プレーンエンティティなどの、プロバイダネットワークの様々な他のコンポーネントと安全に通信しなくてはならない場合がある。そうするために、少なくとも一部の実施形態では、ホストで動作中の仮想化マネージャは、ホストを、公開鍵インフラストラクチャの、または何らかの他の同様なセキュリティインフラストラクチャのメンバーとして、仮想化コンピューティングサービスに関連するホスト識別管理サービスとのネットワーク相互作用を介して、登録または記録することが必要とされ得る。そうしたホスト識別管理サービスは、一部の実施形態では、仮想化コンピューティングサービス内のリソースを用いて実装され得（例えば、図１に示すホスト識別マネージャ１７２の１つまたは複数を用いて）、他の実施形態では、ホスト識別管理サービスは、仮想化コンピューティングサービスの外部にあってもよい。一般に言って、様々な実施形態では、ホスト識別管理サービスは、仮想化ホストをセキュリティインフラストラクチャに記録／登録すること、もたらされた証明書を必要に応じて新しくし交代させること、証明書失効リストを管理すること、及び／または個々の仮想化ホスト上の各キーストアの内容を保つことに関与し得る。

図７は、少なくとも一部の実施形態による、仮想化コンピューティングサービスのセキュリティインフラストラクチャ内に仮想化ホストを記録するために行われ得る動作の態様を示す流れ図である。図６のように、図７に描かれた実施形態においてセキュリティモジュールとしてＴＰＭが用いられるが、他の実施形態では他のタイプのセキュリティモジュールが用いられ得る。要素７０１に示すように、仮想化マネージャのコンポーネント（仮想化コントローラの最小化されたバージョンＶｍｉｎなど）は、セキュリティ鍵ペアを（例えば、ＴＰＭを用いて）生成し、そして、ホスト識別管理サービス（ＨＩＭＳ）とのセキュアな通信セッションで用いるための自己署名証明書を作成することによって記録手順を開始し得る。ＴＬＳ（トランスポート層セキュリティ）などの任意の適切なセキュアな／暗号のネットワーキングプロトコルを用いて、セッションのための接続を確立し得る（要素７０４）。少なくとも一部の実施形態では、仮想化コントローラは、記録の目的でＨＩＭＳと相互作用する部分的にオフロードされた仮想化マネージャのコンポーネントであってもよい。

ＨＩＭＳは、チャレンジペイロード（例えば、何らかのランダムデータ、及び仮想化マネージャによってセッションのために提供される公開鍵を備える）を仮想化マネージャに送信することによって、記録手順へのその関与を開始し得る（要素７０７）。チャレンジメッセージは、公開鍵を検証し、チャレンジペイロードをＴＰＭに送信し得る（要素７１０）。ＴＰＭは、例えばアテステーション鍵及び１つまたは複数のＰＣＲの現在の値を用いて応答ペイロードを準備し（要素７１３）、応答ペイロードを仮想化マネージャに提供し得る。

そして、応答ペイロードは、仮想化マネージャによってＨＩＭＳに伝えられ得る（要素７１６）。ＨＩＭＳは、応答ペイロードを用いて、仮想化ホストの状態が記録を受入れ可能である、または記録に対して有効であることを確認し得る。ＨＩＭＳは、次いで、例えばホストに対してＸ５０９識別証明書を生成して識別証明書をホストの仮想化マネージャに送信することによって、仮想化ホストを記録または登録し得る（要素７１９）。識別証明書は、描かれた実施形態では、仮想化ホストからの少なくともいくつかの後続の通信の安全を保証するのに用いられ得る。一部の実施形態では、ＨＩＭＳはまた、仮想化マネージャにアクセス可能なローカルキーストアに（例えば、暗号化されたストレージデバイスにまたはＴＰＭに）格納される１つまたは複数の追加の証明書も送信し得る（要素７２２）。そうした追加の証明書は、様々なコンポーネント（仮想化コントローラのフル機能バージョン、オポチュニスティックハイパーバイザ及び／またはネットワーク処理オフローダを含む）の更新のために生成されるペイロードの署名を検証するのに仮想化マネージャによって用いられ得る。一部の実施形態では、仮想化コントローラのバージョンの署名を検証するのに用いられる証明書は、ＴＰＭのＰＣＲを拡張するのに用いられ得る、つまり、この証明書は、先に論じたブート手順の第２の段階におけるファームウェアコンポーネントが測定されたのと同じ様に測定され得る。

ホストが記録されて仮想化マネージャのフルバージョンが立ち上げられた後、クライアント要求に応答してＧＶＭを起動する／終了するといった様々なＧＶＭに関する動作が開始され得る。仮想化コンピューティングサービスのセキュリティをさらに高めるために、少なくとも一部の実施形態では、仮想化コンピューティングサービスのＨＩＭＳまたは他の制御プレーンコンポーネントは、クエリ（例えばアテステーションクエリ）を仮想化マネージャに、またはＴＰＭに、仮想化マネージャを介して送信することによって、ホストの状態を周期的に（またはトリガ条件に応答して）認証し得る（要素７２５）。そうした認証クエリは、例えば、その測定値または他のインジケータがＴＰＭに格納されている１つまたは複数のソフトウェア／ファームウェアプログラムのバージョンを識別する要求を含み得る。適切な認証データがＴＰＭから取得され得、ＨＩＭＳまたは他の制御プレーンコンポーネントに提供され得る。一部の実施形態では、そうしたクエリに対して応答が受信されない、または期待外の／無効な応答が受信された場合、ＨＩＭＳまたは他の制御プレーンコンポーネントは、ホストが無効状態である、または破られている状態であることを示す警告をトリガし得、適切な改善措置（ホストを無効にし、デバッグするといった）が開始され得る。

仮想化ホスト内の信頼レベル
図８は、少なくとも一部の実施形態による、仮想化ホストのコンポーネントに関連する異なる信頼レベルの例を示す。多段階ブートプロセス、ライブアップデート用の仮想化マネージャコンポーネントの新しいバージョンのための暗号化されたストレージデバイスの使用、ホスト識別管理サービスとの相互作用、及びハイパーバイザの関与の最小化を含む上述の様々な技術の結果、仮想化ホストに存在するセキュリティが破られていることの見逃しの危険性は最小化され得る。図８において矢印８８５で示すように、ストリップドダウンオポチュニスティックハイパーバイザ８２０、ネットワーク処理オフローダ８１６及びゲスト仮想マシン８５０を含む、仮想化ホストで動作するソフトウェア／ファームウェアコンポーネント８０２の大部分は、セキュリティの観点から信頼できないものと見なされ得る。それらのコンポーネントのそれぞれに向けられるセキュリティ攻撃、またはそれらのコンポーネントのそれぞれにもたらされるバグは、仮想化コンピューティングサービスのセキュリティ依存の部分との相互作用の多くが仮想化コントローラによって行われ得るという理由で、影響は局在する傾向があり、広範囲の停電を生じさせない可能性がある。ハイパーバイザによって従来処理される機能性の多くがオフロードされているので、ハイパーバイザのセキュリティが破られる機会は低減され得、ハイパーバイザ自体に向けられたセキュリティ攻撃の成功の影響は最小化され得る。

仮想化コントローラは、矢印８８０で示すように、描かれた実施形態では、ソフトウェア／ファームウェアスタックの主要な信頼できるコンポーネントと見なされ得る。仮想化コントローラのセキュリティを破ることが成功している可能性は、上述のように、セキュリティモジュールの機能及び最も初期のブート段階での焼き付けられた鍵を用いて最小化され得る。さらに、仮想化マネージャの様々なコンポーネントに対するライブアップデートの使用及びホスト識別管理サービスによる仮想化ホストの状態に関するチェックにより、攻撃が検出される速度、及び攻撃が生じたときに改善措置が取られる（動作中のゲスト仮想マシンへの影響は最小で）速度が向上され得る。

ゲスト仮想マシンのインスタンス作成
図９は、少なくとも一部の実施形態による、ゲスト仮想マシンを起動するために仮想コンピューティングサービスのコンポーネントの様々な層の間で必要とされ得る相互作用の例を示す。サービスのクライアント９１０は、ＧＶＭ（メモリサイズ、処理能力レベル、オペレーティングシステムバージョンなどといったＧＶＭの所望の特徴が要求に記されている）をインスタンス作成または起動する要求を、サービスのプログラマチックインターフェース９１５を用いて（例えば、セキュアなハイパーテキスト転送プロトコルベースのウェブサービスインターフェースを用いて）送信し得る。クライアントの要求は、制御プレーンコンポーネント９６０で受信され、選択された仮想化ホストに送信するために内部形式に変換され得る。特定のホストが、例えば制御プレーンの配置マネージャによって、所望のＧＶＭの特徴、ホストにおける利用可能なリソース容量などに基づいて選択され得る。一部の実施形態では、仮想化ホストのオフロードカードで動作している仮想化コントローラによって、ＲＥＳＴ（Ｒｅｐｒｅｓｅｎｔａｔｉｏｎａｌ Ｓｔａｔｅ Ｔｒａｎｓｆｅｒ）アプリケーションプログラミングインターフェースがサポートされ得る。制御プレーンコンポーネントは、仮想化コントローラのプログラマチックインターフェース９１８を用いて、ＧＶＭのインスタンス作成の要求の内部バージョンを仮想化コントローラ９６５に送信し得る。

次いで、オフロードカードベースの仮想化コントローラは、描かれた実施形態では、オポチュニスティックハイパーバイザ９７０を対象とした対応する要求をフォーマットし得る。少なくとも一部の実施形態では、キューベースのプロトコルを用いて、要求をオフロードカードからハイパーバイザに、例えばＰＣＩ−ＥベースのＤＭＡ（ダイレクトメモリアクセス）を用いて送信し得る。ＧＶＭのインスタンス作成の要求がハイパーバイザのプログラマチックインターフェース９２１を介して受信されると、ホストのために設けられる仮想化ホストのリソースのサブセットが識別され得、ゲスト仮想マシンは適切なマシンイメージを用いて起動され得る（要素９８０）。ゲスト仮想マシンに対して用いられるマシンイメージは、様々な実施形態では、１つまたは複数の仮想化マネージャコンポーネントによって格納場所から読み込まれ得る。一部の実施形態では、各仮想化ホストは、スロットマップ９７２のいくつかのＧＶＭ「スロット」９７３（例えばスロット９７３Ａ〜９７３Ｋ）を有し得、各スロットは、所与のＧＶＭのために用いられるリソースを表している。使用中のスロット（スロット９７３Ａまたは９７３Ｋなど）は、対応するリソースが現在クライアントに割り当てられていることを示し得、使われていないスロットは、新しいＧＶＭに対して用いられ得る。少なくとも一部の実施形態では、所与のＧＶＭに割り当てられる仮想化ホストのメインメモリの特定の部分は、さらなる詳細を以下に論じるように、仮想化コントローラによって選択され得る。

図１０は、少なくとも一部の実施形態による、仮想化ホストにおけるゲスト仮想マシンの例示的な状態遷移を示す。図９の文脈で上述した種類の特定のスロットを用いてＧＶＭのインスタンス作成がされるよりも前に、ＧＶＭは非存在状態１００１にあると見なされ得る。例えばホストの仮想化マネージャと共に動作する仮想化コンピューティングサービスの制御プレーンコンポーネントによって、スロットがインスタンスに対して割り当てられると、インスタンスは初めは非アクティブ状態１００４となり得る。次いで、ＧＶＭは、アクティブ状態１００７に、例えばＧＶＭがそこからいくつかの他のアクティブ状態に遷移し得る初期「仕様保留」状態１０１０に移行し得る。

仕様保留状態１０１０で、オポチュニスティックハイパーバイザのＧＶＭマネージャプロセスはＧＶＭに対して割り当てられていてもよいが、ＧＶＭの仕様（ＧＶＭプロセスのインスタンス作成に必要とされる詳細な情報を含む）は、まだＧＶＭマネージャプロセスに提供されていなくてもよい。仕様保留状態１０１０から、ＧＶＭは、一時停止状態１０１３に入り得る。一時停止状態で、仕様はＧＶＭマネージャに提供されていてもよいが、ＧＶＭの仮想ＣＰＵスレッド（ｖＣＰＵ）はまだ、物理ＣＰＵ（ｐＣＰＵ）での実行のためにスケジューリングされていない。一時停止状態は、例えば、デバッグ目的のために、及び／またはデバイスを取り付け／取り外しするために用いられ得る。

ｖＰＣＵがｐＣＰＵ上で動作可能にされると、ＧＶＭは、動作状態１０１６に入り得、クライアントのアプリケーションはｐＣＰＵを用いて動作し得る。以下に論じるように、ＧＶＭのメタデータ（ハイパーバイザのライブアップデートの際に用いられる）のために確保されたメモリの領域にｖＣＰＵ状態を格納することによって、一時停止状態１０１３からシリアライズされた状態１０１９に到達し得る。シリアライズされた状態１０１９または動作状態のいずれかから、ＧＶＭは、例えばハイパーバイザのライブアップデートに必要とされるときハイパーバイザのＧＶＭマネージャコンポーネントによって一時停止され得る。加えて、動作状態または一時停止状態から、ＧＶＭは、描かれた実施形態では、例えばハイパーバイザにＧＶＭを終了する通知がなされたとき、またはスタックしているように見える動作中のＧＶＭを途中停止する動作が必要とされたとき、イクジット状態１０２２に入り得る。ＧＶＭのリブートが計画または要求された場合、様々な実施形態では、ＧＶＭはリスタート後、非アクティブ状態に戻され得る（その後アクティブ状態になる）。

仮想化ホストからＧＶＭを永続的に終了する決定がなされると、ＧＶＭに対して割り当てられていたホストのメインメモリ（ならびに他のリソース）の一部分はスクラブまたはクリーニングされる必要があり得、例えば終了されたＧＶＭからそのスロットを占める予定の次のＧＶＭへのデータの不注意な伝送を防ぐ。このようにして、ＧＶＭは、イクジット状態１０２２からスクラブ状態１０１０に遷移し得、ここでは、ハイパーバイザのセキュリティコンポーネントは、メモリが上書きされている（例えばゼロで）ことを確保する。何らかの理由でメモリをスクラブできない場合、対応するスロットは、「壊れたスロット」１０８０と見なされ得、仮想化コンピューティングサービスの制御プレーンに、スロットは新しいＧＶＭに対して利用可能ではないことが通知され得る。一部の実施形態では、壊れたスロットのメモリを利用可能にする修理動作が開始され得る。スクラブが成功した場合、スロットに関連するメモリは、新しいＧＶＭに対して再使用され得、非存在状態１００１から開始される。

メモリ管理オフローディング
上述したブートに関する動作及びセキュリティに関する動作に加え、少なくとも一部の実施形態では、仮想化ホストにおけるメモリ割当てタスクの大きなサブセットが、オフロードされた仮想化マネージャコンポーネントで行われ得る。特に、少なくとも一部の実施形態では、オポチュニスティックハイパーバイザが仮想化ホストのメインメモリの相対的に小さい部分を管理し得る一方、メモリの残りの部分に関する割当て決定は、仮想化コントローラまたは別のオフロードされたメモリマネージャによってなされ得る。この手法は、ハイパーバイザによってなされなければならない作業の量をさらに減らし、それによって、ｐＣＰＵサイクルのうちより多くをゲスト仮想マシンによって利用可能にするという利益を有し得る。加えて、以下に記述するように、この手法はまた、ハイパーバイザのライブアップデートが行われることを可能にし得、その間、動作中のゲスト仮想マシンはリブートされる必要がなくてもよい。

図１１は、少なくとも一部の実施形態による、仮想化ホストのメインメモリを、オフロードされた仮想化マネージャコンポーネントによって管理されるセクションとハイパーバイザによって管理されるセクションに区切る例を示す。示すように、仮想化ホストのメインメモリ１１１０は、ハイパーバイザによって管理されるセクション１１１５とオフロードされた仮想化マネージャコンポーネント（ＯＶＭＣ）によって管理されるセクション１１２０に分割される。ＯＶＭＣによって管理されるセクションは、描かれた実施形態では、ＧＶＭのメモリ割当てに対してと、さらにはハイパーバイザのアップデート中にＧＶＭデバイス状態を格納するのに用いられ得るＧＶＭごとのメタデータ１１２１に対して用いられ得る。ハイパーバイザによって管理されるセクション１１１５の少なくとも一部は、描かれた実施形態では、ハイパーバイザのライブアップデート中に上書きされ得る。対照的に、ハイパーバイザによって管理されていないことを少なくとも部分的な理由として、ＯＶＭＣによって管理される部分１１２０の内容はハイパーバイザのアップデートを通して存続し得る。

図１２は、少なくとも一部の実施形態による、ホストメモリのハイパーバイザによって管理されるセクションのかつオフロードされた仮想化マネージャコンポーネントによって管理されるメモリセクションに含まれるメタデータの例示的な内容を示す。ハイパーバイザによって管理されるセクション１２１５は、描かれた実施形態では、１つまたは複数のページテーブル１２１７、ハイパーバイザのオペレーティングシステムカーネルレベルコンポーネントによって用いられるデータ構造１２１８、ハイパーバイザコーディネータ、ＧＶＭマネージャなどに割り当てられたメモリの特定の領域といったハイパーバイザプロセスメモリ１２１９、ならびにライブアップデートイメージ格納セクション１２２１を備え得る。ハイパーバイザで用いられるページテーブル１２１７は、一部の実施形態では、４キロバイトまたは８キロバイトのページなどの極めて小さなサイズの個々の割当てを管理するように構成され得る。ハイパーバイザのライブアップデートが行われるとき、ハイパーバイザは、セクション１２２１の内容を用いて適切な場所でブートされ得る。セクション１２２１は、後で、ハイパーバイザのさらに別のより最近アップデートされたバージョンを格納するのに用いられ得る。このようにして、ハイパーバイザによって管理されるメモリセクション１２１５は、様々な時点でのハイパーバイザの２つのバージョン−現在のバージョン及びセクション１２２１のブート予定のバージョンを備え得る。

メインメモリの、ＧＶＭごとのメタデータセクション１２５１は、仮想化ホストでインスタンス作成されることになる様々な異なるＧＶＭに対するメモリのそれぞれの部分を備え得る。ＧＶＭごとのメタデータ部分のそれぞれは、描かれた実施形態では、ＧＶＭに対する１つまたは複数のページテーブル及びデバイス状態保存領域を備え得る。かくして、例えば、ＧＶＭ１−メタデータ部分は、描かれた例では、ページテーブル（複数可）１２５７Ａ及びデバイス状態保存領域１２５９Ａを備え、ＧＶＭ２−メタデータ部分は、ページテーブル（複数可）１２５７Ｂ及びデバイス状態保存領域１２５９Ｂを備える。ＧＶＭ固有のページテーブル１２５７におけるエントリのページサイズは、少なくとも一部の実施形態では、ハイパーバイザによって用いられるページサイズとは異なり得る。例えば、ハイパーバイザは、一実装例では、４キロバイトのページでその一部からメモリを割り当て得、ＧＶＭに対して用いられるページサイズは２メガバイトであり得る。少なくとも一実装例では、同一ホスト上の異なるＧＶＭに対して異なるページサイズが用いられ得る−例えば、ＧＶＭ１のページはそれぞれ２メガバイトであってもよく、ＧＶＭ２のページはそれぞれ４メガバイトのサイズであってもよい。様々な実施形態では、ハイパーバイザ及び異なるＧＶＭに対して用いられるページの特定のサイズは、メモリ割当ての期待パターンに基づいて判定され得る（例えば、仮想化コンピューティングサービスの制御プレーンによって）。ＧＶＭのＩ／Ｏデバイス（例えば、１つまたは複数のパススルーＩ／Ｏデバイス）、ｖＣＰＵなどの状態は、様々な実施形態では、例えばハイパーバイザのライブアップデートが行われるときにＧＶＭが一時停止される短い期間中に、ＧＶＭに対する状態保存領域に保存され得る。少なくとも一部の実施形態では、ＯＶＭＣは、メインメモリのどの領域が所与のＧＶＭ（例えば、ＧＶＭのオペレーティングシステム及びアプリケーション）及びＧＶＭのメタデータに対して用いられるかを判定し、ハイパーバイザにその情報を提供し得る。かくして、ＧＶＭ固有のメモリ割当て決定がＯＶＭＣによってなされ得、それらの決定の結果の少なくとも一部は、そうした実施形態では、ＯＶＭＣによってハイパーバイザに提供され得る。所与のＧＶＭに対するページテーブル及びデバイス状態保存領域は、少なくとも一部の実装例では、連続していなくてもよいことに留意されたい。

ＧＶＭに代わってメモリ割当て決定を行うために、ＯＶＭＣは、様々な実施形態では、最初にメモリに関する情報をハイパーバイザから取得する必要があり得る。図１３は、少なくとも一部の実施形態による、仮想化マネージャのコンポーネントの間の例示的なメモリインベントリに関する相互作用を示す。示すように、ＯＶＭＣ１３１０は、例えば先に記述した多段階ブート動作の後半の段階において、オポチュニスティックハイパーバイザの実行可能ファイル（複数可）１３２５を起動するコマンド１３２２を発行し得る。ハイパーバイザが立ち上がると、ハイパーバイザは、作業準備ができていると示すメッセ―ジ１３２５をＯＶＭＣ１３１０に送信し得る。

ＯＶＭＣは、メモリインベントリ要求１３２８をハイパーバイザに送信し得、事実上、ハイパーバイザに、ＯＶＭＣによって管理されるメモリの領域を示すように依頼する。ハイパーバイザは、要求された情報を、例えば利用可能なメモリ記述子１３３１の形で提供し得る。ＯＶＭＣは、その後、このメモリの様々な部分を、個々のＧＶＭに（例えば、ＧＶＭ内で動作しているオペレーティングシステムプロセス及びアプリケーションプロセスで用いられる）及び／または、ハイパーバイザのライブアップデート中に用いられるＧＶＭごとのメタデータ（ＧＶＭ固有のページテーブル及びデバイス状態格納情報などの）に対して割り当て得る。

図１４は、少なくとも一部の実施形態による、仮想化マネージャのコンポーネントの間での、ゲスト仮想マシンのインスタンス作成及び終了に関連する例示的なメモリに関する相互作用を示す。起動要求１４０２の指示は、ＯＶＭＣ１４１０によって、例えば仮想コンピューティングサービスの制御プレーンコンポーネント（クライアントからのＧＶＭに対する対応する要求が受信されていてもよい）から受信され得る。要求は、例えばＧＶＭに対して構築されるメモリのサイズ、ＧＶＭに割り当てられる処理能力などを含む、インスタンス作成されるＧＶＭの様々な性質を示し得る。ＯＶＭＣ１４１０は、メモリを、ＧＶＭ自体に対して（すなわち、ＧＶＭで実行されるオペレーティングシステム及びアプリケーションに対して）、及び、ＧＶＭがハイパーバイザのライブアップデート中に短時間一時停止される場合／されるときに保存されなくてはならない場合があるＧＶＭのページテーブル及び様々なメタデータエントリに対して割り当て得る。ＧＶＭ及びそのメタデータに対して割り当てられるメモリに関する情報１４２２は、ＯＶＭＣによってオポチュニスティックハイパーバイザ１４３５に提供され得、ＯＶＭＣは、ホストにおける追加のＧＶＭに対して利用可能（もしあれば）のままである使用されていないメモリの量に関するその記録を更新し得る。少なくとも一部の実施形態では、ＧＶＭのメモリ要求に対応するために、バディ割当てアルゴリズム１４２５がＯＶＭＣで用いられ得る。

自らの代わりにＧＶＭがインスタンス作成されるクライアントがＧＶＭ上でそれらのアプリケーションの動作を完了した後で、クライアントは、ＧＶＭ終了要求を仮想化コンピューティングサービスの制御プレーンに送信し得る。ＧＶＭ終了要求の内部バージョン１４０４の指示は、制御プレーンからＯＶＭＣ１４１０に提供され得る。終了コマンド１４２８が、ＯＶＭＣによってオポチュニスティックハイパーバイザ１４３５に送信され得る。それに応じて、ＧＶＭは、ハイパーバイザによってシャットダウンされ得る。ＧＶＭがシャットダウンされた後で、ＧＶＭに割り当てられていた物理メモリの一部は、スクラブまたはクリーニングされ得（例えば、オポチュニスティックハイパーバイザ１４３５のコンポーネントによってメモリをゼロで上書きすることによって）、メモリが他のＧＶＭに対して利用可能であるという表示１４３１がＯＶＭＣ１４１０に提供され得る。ＯＶＭＣは、それに応じて、メモリ割当のその記録を更新し得、必要に応じて、解放されたメモリの少なくとも一部を何らかの他のＧＶＭに対して利用し得る。

図１５は、少なくとも一部の実施形態による、仮想化マネージャのコンポーネントの間での、ハイパーバイザのライブアップデートに関連する例示的な相互作用を示す。オポチュニスティックハイパーバイザの新しいバージョンを配備する要求１５０２が、描かれた実施形態では、仮想化コンピューティングサービスの制御プレーンコンポーネントからＯＶＭＣで受信され得る。それに応じて、新しいバージョンの実行可能イメージを格納するコマンド１５２２が、ＯＶＭＣから、オポチュニスティックハイパーバイザ１５３５の現在動作中のバージョンに送信され得る。一部の実装例では、ＯＶＭＣは、新しいバージョンの内容を送信し得、他の実装例では、ＯＶＭＣは、新しいバージョンが取得される場所の指示を提供し得る。新しいバージョンの内容は、仮想化ホストのメインメモリのハイパーバイザによって管理される部分のライブアップデートイメージ格納セクション１５７５内に保存され得る。少なくとも一部の実施形態では、新しいバージョンは、様々な強化及び／またはバグ修正に加えて、ハイパーバイザの現在のバージョンによってその動作のために用いられる既存のデータ構造（メモリ管理に用いられる構造を含む）をハイパーバイザの新しいバージョンによって用いられる修正バージョンに変換するコードを備え得る。

仮想化ホストフリートにおけるハイパーバイザ１４３５の新しいバージョンの配備は、様々な実施形態では、２つの時間的に切り離されたステップで行われ得る：新しいバージョンがフリートのホストのいくつかまたは全てにおけるホストメモリのハイパーバイザによって管理される部分に格納される分散段階と；新しいバージョンがそれをライブブートすることによってホストで立ち上げられるアクティブ化段階である。２つの段階は、様々な理由で切り離され得る−例えば、新しいバージョンがエラーなしで、（潜在的に非常に多数の）目的とされたホストのセットに格納されていることを確認するには、及び／または、ホストフリートの目的とされる部分の異なる断片は、最終的に、異なるバージョンの動作ハイパーバイザとなるというシナリオの回避を試みるには、かなりの時間量がかかり得るという理由である。

ハイパーバイザの格納された新しいバージョンのアクティブ化をトリガするために、描かれた実施形態では、ライブアップデート要求１５０４がＯＶＭＣ１５１０に送信され得る。そして、ＯＶＭＣ１５１０は、ブートインプレースコマンド１５２８をハイパーバイザ１５３５の現在のバージョンに送信し得る。現在のバージョンは、任意の動作中のＧＭＶを一時的に一時停止し、ＧＶＭの状態を（ＯＶＭＣによって管理されるメモリを用いて）シリアライズし、その後、格納された新しいバージョンを用いてライブアップデート１５６５を実装し得る。新しいバージョンへのリブートが成功した場合、オポチュニスティックハイパーバイザの新しいバージョンは、描かれた実施形態では、一時停止された（もしあれば）ＧＶＭを再アクティブ化し、ハイパーバイザ準備完了メッセージ１５３１をＯＶＭＣに送信し得る。ＧＶＭは、様々な実施形態では、ハイパーバイザのアップデートにおいてリブートされなくてもよく、ＧＶＭが一時停止される期間は、通常、少なくとも何人かのＧＶＭユーザまたはアプリケーションが一時停止に気付かないこともあるほどに短くてもよい。ＧＶＭの状態は、リブートインプレースの前に、ＯＶＭＣによって管理されるメモリの一部に保存されたので、ＧＶＭは、何らかの理由でライブアップデートが失敗し、以前に動作していたハイパーバイザがその動作を再開しなくてはならない場合でも、迅速に再アクティブ化され得る。

図１６は、少なくとも一部の実施形態による、部分的にオフロードされた仮想化マネージャの様々なコンポーネントによって行われ得るメモリ管理に関する動作の態様を示す流れ図である。要素１６０１に示すように、オフロードされた仮想化マネージャコンポーネント（ＯＶＭＣ）は、例えば先に論じた多段階ブート動作の後期段階の１つにおいて、仮想化ホストでオポチュニスティックハイパーバイザの１つまたは複数のコンポーネントをスタートアップし得る。ハイパーバイザは、自らのメモリ割当てを管理するために、第１のページテーブルのためにホストのメインメモリのセクションを確保し得る（すなわち、ＧＶＭに対して割り当てられたメモリとは対照的に、ハイパーバイザコントローラ、ＧＶＭマネージャなどといったハイパーバイザの様々なサブコンポーネントに対するハイパーバイザの内部メモリ割当て）（要素１６０４）。少なくとも一部の実施形態では、このハイパーバイザのページテーブルに表されるページのサイズは、例えばハイパーバイザのサブコンポーネントから期待される典型的なメモリ割当てパターンに基づいて、４キロバイトまたは何らかの他の相対的に小さなページサイズに設定され得る。

ハイパーバイザのライブアップデートのために、ホストのメインメモリのハイパーバイザによって管理される部分の一部も形成するホストのメインメモリの第２の部分は確保されて（要素１６０７）、例えば、アップデートが必要とされるのに応じてハイパーバイザの新しいバージョンを格納し得る。新しいバージョンは、描かれた実施形態では、この段階では必ずしも利用可能でなくてもよいが、それのために最終的に用いられる空間はそれでも確保され得る。

ＯＶＭＣは、メモリインベントリ要求をハイパーバイザに送信して（要素１６１０）、例えばメインメモリのうちどれほどが（及びどの具体的なセクションが）ＧＶＭ及び関連するメタデータのためにＯＶＭＣによって管理されるかを判定し得る。ハイパーバイザは、描かれた実施形態では、メモリのこのＯＶＭＣによって管理される部分のサイズ及び場所の指示をＯＶＭＣに送信して戻し得る（要素１６１３）。ＯＶＭＣによって管理される部分は、利用可能な全物理メモリ（ハイパーバイザによってその初期化中に検出される）とハイパーバイザによって管理される部分の差を備え得る。ＯＶＭＣによって管理される部分は、ハイパーバイザのライブアップデート中、そのまま残され得る（すなわち上書きされなくてもよい）。

ＯＶＭＣによって管理されるメモリ領域に関する情報が処理された後で、ＯＶＭＣは、ホストでのＧＶＭのインスタンス作成を可能にし得る。新しいＧＶＭがインスタンス作成されるとき、ＯＶＭＣは、ＧＶＭのために用いられるメモリの領域（例えば、ＧＶＭ固有のページテーブル、ＧＶＭのオペレーティングシステム及びプロセッサのための空間、ＧＶＭのまとめられたデバイス状態情報を保存するのに用いられるメタデータ領域を含む）をＯＶＭＣによって管理される領域から選択し得る（要素１６１６）。様々な実施形態では、ＧＶＭのページテーブルが構築される特定のメモリアドレス範囲はＯＶＭＣによって選択され得るが、ハイパーバイザは、ページテーブルの実際の作成に関与し得る。ページテーブルのために用いられるアドレス範囲は、ＯＶＭＣによってハイパーバイザにＧＶＭページングメタデータの一部として提供され得る。ＧＶＭ固有のページテーブルは、少なくとも一部の実施形態では、メモリのハイパーバイザによって管理されるセクションのためにハイパーバイザによって用いられるページサイズまたは複数のページサイズと異なるサイズ（または異なる複数のサイズ）のページをサポートし得る。ページングメタデータは、一部の実装例では、ＧＶＭに対して用いられるページサイズの指示を含み得る。ハイパーバイザには、ＯＶＭＣによってＧＶＭに対してなされる割当て決定に関して通知がなされ得る（要素１６１９）。

ＧＶＭが終了する前にハイパーバイザのライブアップデートが行われる場合、ハイパーバイザは、ＧＶＭの仮想ＣＰＵを一時停止し、デバイス状態を、ＯＶＭＣによってＧＶＭに対して割り当てられているメタデータ領域に保存し得る（要素１６２２）。ハイパーバイザのライブアップデートは、ホストのＧＶＭをリブートすることなしに行われ得、その代わりに、描かれた実施形態では、ＧＶＭの状態が、ＧＶＭが一時停止されている短い期間の後で復元され得る。ＧＶＭが最終的に終了されると、ＯＶＭＣによってそれに割り当てられたメモリは、ハイパーバイザによってスクラブされ得（要素１６２５）、ＯＶＭＣには、終了されたＧＶＭのメモリが例えば他のＧＶＭに対して利用可能であることが通知され得る。

図１７は、少なくとも一部の実施形態による、ハイパーバイザのライブアップデートに関連する動作の態様を示す流れ図である。要素１７０１に示すように、仮想化ホストにおけるオフロードされた仮想化マネージャコンポーネント（ＯＶＭＣ）は、オポチュニスティックハイパーバイザの新しいバージョンがホスト上に（そこでは、オポチュニスティックハイパーバイザの現在のバージョンが既に動作中である）インストールまたは配備されるという指示を受信し得る。指示は、例えば、仮想化ホストが用いられている仮想化コンピューティングサービスの制御プレーンコンポーネントから受信され得る。ＯＶＭＣは、新しいバージョンに対する実行可能ファイルの内容（または内容へのポインタ）をハイパーバイザの現在のバージョンに、例えばハイパーバイザコントローラのサブコンポーネントに送信し得る（要素１７０４）。新しいバージョンは、新しい機能、バグ修正などに加えて、一部の実施形態では、ハイパーバイザで用いられる様々なデータ構造に対して用いられる変換機能を備え得る。例えば、新しい属性は、ハイパーバイザの新しいバージョンにおいて特定のメモリ管理に関するデータ構造に追加されていてもよく、変換機能が、古いデータ構造（ＯＶＭＣによって割り当てられたメタデータ領域に格納され得る）を修正されたデータ構造に変換するために提供され得る。

現在のハイパーバイザバージョンは、ライブアップデートのために指定されたホストのメインメモリのセクションに、新しいバージョン用の実行可能ファイルを格納し得る（要素１７０７）。新しいバージョンが安全に格納された後で、ある時点で、ＯＶＭＣは、新しいバージョンをライブアップデートを介してアクティブ化する要求またはコマンドを現在のハイパーバイザに送信し得る（要素１７１０）−例えば、ゲスト仮想マシンがリブートされることを必要としないアップデート手順を用いて。アクティブ化コマンド／要求は、一部の実施形態では、仮想化コンピューティングサービスの制御プレーンからの別の通信に応じて、ＯＶＭＣからハイパーバイザに送信され得る。他の実施形態では、ライブアップデートは、制御プレーンからの任意の追加の通信または指示なしで、ＯＶＭＣによって、または、ハイパーバイザ自体の現在のバージョンによって開始され得る（例えば、新しいバージョンがメインメモリのハイパーバイザによって管理される部分に格納されるとすぐに、ライブアップデートは開始され得る）。

ハイパーバイザの現在のバージョン（例えば、ハイパーバイザのＧＶＭマネージャコンポーネント）は、描かれた実施形態では、ライブアップデートの一部として、動作中のＧＶＭを休止または一時停止させ得る。所与のＧＶＭに関連する状態情報（例えば仮想ＣＰＵ状態、パススルーＩ／Ｏデバイス状態などを含む）は、メインメモリのＯＶＭＣによって管理される部分の適切なＧＶＭごとのメタデータセクションに格納され得る（要素１７１３）。

一時停止してＧＶＭ（複数可）の状態情報を保存した後で、ハイパーバイザは、描かれた実施形態では、例えば「ｋｅｘｅｃ」機構の同等物を用いて、新しいバージョンへのインプレースリブートを行い得る（要素１７１６）。この段階において、ハイパーバイザの更新前バージョンによって以前に用いられていたメインメモリの少なくとも一部は上書きされ得るが、メインメモリのＯＶＭＣによって管理される部分は、修正されないままであってもよい。ハイパーバイザの新しいバージョンがブートした後で、それは、一時停止されているＧＶＭを再アクティブ化し得る（要素１７１９）。一部の実施形態では、ライブアップデートが成功したという通知がＯＶＭＣに提供され得る（要素１７２２）。様々な実施形態では、ハイパーバイザの新しいバージョンが仮想化コンピューティングサービスにおいて開発配備されると、同様の動作セットが、仮想化ホストのライフサイクル中に数回行われ得る。

少なくとも一実施形態では、ゲスト仮想マシンに対する少なくともいくつかのメモリ割当ては、オフロードカードそれ自体の一部ではない、仮想化サービスの制御プレーンコンポーネントで行われ得る。例えば、仮想化ホストとは別のホスト（仮想化ホストからネットワークを介して連絡可能な）で動作中の制御プレーンコンポーネントは、一部のそうした実施形態では、仮想化ホストのハイパーバイザに、ＧＶＭのための利用可能なメモリ、割り当てられたＧＶＭごとのメモリなどに関して問い合わせすることに関与し得る。そうした遠隔制御プレーンコンポーネントは、仮想化ホストに対する、オフロードされた仮想化マネージャコンポーネントの別の変形と見なされ得る。

ハイパーバイザにおけるオポチュニスティックタスク処理
先に記述したように、仮想化マネージャは、様々な実施形態では、そうでなければゲスト仮想マシンに対して用いることができるホストリソース（例えば、物理ＣＰＵ及び物理メモリ）の消費を最小化するように設計され得る。一部の実施形態では、この最小化の一態様は、ＧＶＭによって物理ＣＰＵが自発的に放棄されるまで特定の仮想化管理タスクを先送りし、その後、物理ＣＰＵが利用可能であることをＧＶＭが見込まない期間にタスクを行う機会を利用するハイパーバイザを備え得る。それを行うために、様々な実施形態では、ＯＶＭＣまたは仮想化コンピューティングサービスの制御プレーンによって発行されるコマンド／要求に向けた非同期的なアプローチが取られ得る。さらに、デフォルトで、ハイパーバイザのサブコンポーネントの一部または全ては、休止状態または受動状態を保ち得、ホストリソースを利用する機会が有効になったとき、及び／または、他のサブコンポーネントからのメッセージが受信されたとき、受動状態をイクジットする。このオポチュニスティックアプローチによって、先に記述したように、ＧＶＭで実行されているアプリケーション動作のパフォーマンスにおける変動すなわちジッターの低減が支援され得る。

図１８は、少なくとも一部の実施形態による、オポチュニスティックハイパーバイザの例示的なサブコンポーネント及び通信機構を示す。示すように、仮想化ホスト１８０２は、ｐＣＰＵ１８０５Ａ及び１８０５Ｂを含むいくつかの物理ＣＰＵ（ｐＣＰＵ）１８０５を備え得る。ホストはまた、オポチュニスティックな、デフォルトで休止しているハイパーバイザ１８２０、及びオフロードカード１８１０上の１つまたは複数のオフロードされた仮想化マネージャコンポーネント（ＯＶＭＣ）１８７２も備え得る。ＯＶＭＣは、ネットワーク処理オフローダ１８１５及び仮想化コントローラ１８１６を含み得る。ハイパーバイザ１８２０は、描かれた実施形態では、ハイパーバイザコーディネータ１８２５、カーネルレベルコンポーネント１８２２、１つまたは複数のＧＶＭマネージャ１８２８、分離／セキュリティコンポーネント１８２９及びキューマネージャ１８７５を備え得る。

示す例示的なシナリオでは、ｐＣＰＵ１８０５のそれぞれは、各ＧＶＭによる使用のために指定される−例えば、ＧＶＭマネージャ１８２８Ａは、ＧＶＭ１８５０Ａに割り当てられた仮想ＣＰＵをｐＣＰＵ１８０５Ａにマッピングし、ＧＶＭマネージャ１８２８Ｂは、ＧＶＭ１８５０Ｂに割り当てられた仮想ＣＰＵをｐＣＰＵ１８０５Ｂにマッピングする。他の実施形態では、ＧＶＭとｐＣＰＵの１：１のマッピングは、必ずしも実行されなくてもよい−例えば、単一のｐＣＰＵがいくつかのＧＶＭ間で共有され得、または、所与のＧＶＭが１つより多いｐＣＰＵにマッピングされ得る。

キューマネージャ１８７５は、描かれた実施形態では、仮想化コントローラ１８１６とハイパーバイザの他のコンポーネントの仲介役として動作し得る。一部の実装例では、仮想化コントローラ１８１６は、自らを、ＮＶＭｅ（不揮発性メモリエクスプレス）デバイスとして公開し得、キューマネージャは、仮想化コントローラによって発行された管理用のコマンド／要求を論理「ｔｏ−ｄｏ」タスクキュー１８４８のそれぞれのエントリ（エントリＴ５及びＴ６などの）に変換し得る。そうしたタスクの例として、とりわけ、所与のＧＶＭ、様々なハードウェアのサブコンポーネントまたはハイパーバイザそれ自体に関連するメトリクスを収集すること、既存のＧＶＭのシャットダウンまたは再スタートを開始すること、新しいＧＶＭを起動すること、終了作業中のＧＶＭによって使用されていたメモリをスクラブすることなどが含まれ得る。少なくとも一部の実施形態では、キューを利用した、またはファーストインファーストアウトのプロトコルが、物理キューデータ構造を必ずしも実装しなくても用いられ得ることに留意されたい。つまり、論理ｔｏ−ｄｏタスクキュー１８４８は、バッファの連結リストなどといった、キュー以外の物理データ構造を用いて実装されてもよいことがある。少なくとも一部の実施形態では、ストレイトフォワードなキューの変形が用いられ得る−例えば、エントリは、単なるファーストインファーストアウトポリシーを用いる代わりに相対的優先順位に基づいてキュー内に配置され得る。

ハイパーバイザコーディネータ１８２５といったハイパーバイザの他のコンポーネントは、ＧＶＭによってｐＣＰＵが解放された結果アクティブ化されると、ｔｏ−ｄｏタスクキューの内容を検査し、未処理タスクが存在する場合、応答アクションをとり得る。タスクの性質次第で、ハイパーバイザコーディネータは、タスク自体を行うかまたはタスクを、実装するために別のサブコンポーネントに渡すかのいずれかを行い得る。タスクの完了後、一部の実施形態では、要求された動作の結果を示すエントリ（例えばＴ１またはＴ２）は、任意完了タスクキュー１８４９に配置され得る。キューマネージャは、描かれた実施形態では、対応するエントリが完了タスクキュー１８４９に配置されている場合／配置されているとき、要求されたタスクは完了しているという表示（及び／または要求されたタスクの結果）を仮想化コントローラに提供し得る。一部の実施形態では、完了タスクキューは実装されなくてもよい。少なくとも一実装例では、ハイパーバイザのサブコンポーネントの少なくともいくつかの間で統合内部通信機構としてパイプが用いられ得る。サブコンポーネントのいくつかまたは全ては、通常、時間の多くを、メッセージを待機しながら、ポーリングプリミティブでブロック状態（例えば、ｅｐｏｌｌ（）システムコールまたは論理的同等物を用いて）で費やす。

描かれた実施形態では、ハイパーバイザのサブコンポーネントが、少なくとも、それに割り当てられた所与の仮想化管理タスクの目的とされた部分を完了するとすぐに、デフォルトの受動状態または休止状態に遷移し得、タスクのために用いられたｐＣＰＵは解放され、ｐＣＰＵを放棄したＧＶＭに戻され得る。ＧＶＭは、異なる実施形態では、様々な理由でｐＣＰＵを明け渡し得る。例えば、ＧＶＭはＩ／Ｏ動作が完了するのを待機しなくてはならないという理由で、または、タイマー値が読み出されなくてはならないという理由で、などである。一部の実施形態では、ＧＶＭは、ハイパーバイザコンポーネントによってコーディネートされる、または行われる動作を要求し得、ｐＣＰＵを放棄して、ハイパーバイザが要求された動作を行うのを可能にし得る。オペレーティングシステムコンポーネントまたはデバイスドラバレベルコンポーネントといった、ＧＶＭの管理上のコンポーネントは、様々な実施形態では、通常、ｐＣＰＵを放棄し得る。

一部の実装例では、ＧＶＭによる特定の仮想化命令（「ＶＭ ｅｘｉｔ」命令と呼ばれ得る）の発行は、ｐＣＰＵが放棄されていることをカーネルレベルコンポーネント１８２２に示し得る。カーネルレベルコンポーネントは、ハイパーバイザ１８２０の１つまたは複数の他のコンポーネント（コンテキストを切り替えているＧＶＭに関連するＧＶＭマネージャ１８２８、及び／またはハイパーバイザコーディネータ１８２５など）に、ｐＣＰＵが利用可能になったことを通知し得る。この通知は、ｔｏ−ｄｏタスクキュー１８４８の検査をトリガし得（現在利用可能なｐＣＰＵを用いて）、ひいては、１つまたは複数のキューされているタスク（ならびに、ＧＶＭによるｐＣＰＵの解放へつながったＧＶＭによって要求された動作、そうした動作が要求された場合）の実行につながり得る。解放されたｐＣＰＵは、キューされているタスクの少なくとも一部を行うのに用いられ得る。キューされているタスクが完了されると、タスクを行ったハイパーバイザコンポーネントは、様々な実施形態において、そのデフォルトの受動／休止状態に再遷移し得る。キューされている仮想化管理タスクは、様々な実施形態では、ＧＶＭがｐＣＰＵの使用を見込まない期間中に主に（またはその期間中にのみ）、ｐＣＰＵを用いて行われ得る。

大抵の場合、オポチュニスティックハイパーバイザで処理される個々の仮想化管理タスクは、様々な実施形態において、特にＧＶＭ（そのｐＣＰＵの放棄がタスクの実行につながった）が通常ｐＣＰＵを放棄した後のそれを使用しないことを見込む期間の長さに比べて、非常にわずかな時間をとり得る。結果的に、大部分のタスクは、ハイパーバイザによって、ハイパーバイザ自体がｐＣＰＵを解放する前に、完全に動作し得る。しかしながら、少なくとも一部の実施形態では、ハイパーバイザは、より長期的な仮想化管理タスクを行うことを必要とされ得る、または要求され得ることがある。そうした実施形態では、より長いタスクに必要とされる作業は、状態マシンを用いて管理され得、状態マシンの個々の遷移は、全体のタスクのうち別々に実行可能なサブタスクに対応する。図１８に描かれた実施形態では、状態マシン格納領域１８６２は、そうしたより長期的なタスクに対応するのに用いられ得る。

より長いタスク全体を一挙に行うことに代えて、描かれた実施形態では、対応する状態マシンの１つまたはいくつかの状態遷移が、ハイパーバイザがｐＣＰＵを解放する前に、一度行われ得、状態遷移が完了しているという表示が領域１８６２に格納される。ｐＣＰＵが利用可能になると、ハイパーバイザコンポーネントは、場合によっては、状態マシンによって表されるタスクがまだ完了していないことを判定し得る（例えば、ｔｏ−ｄｏタスクキューのヘッドを検査することによって）。次いで、ハイパーバイザコンポーネントは、マシンの現在の状態を検査し、次の遷移を行うために行われる必要がある作業を識別し、その作業を行い、領域１８６２の状態マシン表現を更新し、そして、さらなる状態遷移が依然完了していない場合でもｐＣＰＵを解放してその休止状態に再エンターし得る。タスクが最終的に完了するまで、ハイパーバイザコンポーネントは、より長期的なタスクの作業をさらに行う機会を得る度に、そのようにし得る。場合によっては、ｐＣＰＵが解放されてＧＶＭに戻される前に、１つより多い状態遷移が完了され得る。

場合によっては、仮想化管理タスクは、例えば仮想化コンピューティングサービスの制御プレーンによって、高い優先順位を割り当てられ得、このタスクはｐＣＰＵがＧＶＭによって自発的に明け渡される前にハイパーバイザコンポーネントをアクティブ化することを要するとしても、可能な限り早く完了されるべきであることを示す。割り込みベースの機構は、そうした高い優先順位のタスクのために用いられ得、このタスクは、大部分の実施形態において通常非常にまれに必要とされ得る。タスクを受動的にキューする代わりに、仮想化コントローラは、ハイパーバイザに割り込みを発行し得、ハイパーバイザコンポーネントに高い優先順位のタスクを呼び起こさせ開始させる。そうした高い優先順位のタスクは、例えば、特定のゲスト仮想マシンの不健康な状態を診断または解決することを含み得る（例えば、ＧＶＭが無限ループにとらわれているように見える、または、正常な通信に無反応である場合）。割り込みベースの機構は、一部の実施形態では、主にキューベースの機構が不十分に見える異常な状況下で用いられる、ＯＶＭＣとハイパーバイザの間の相互作用のバックアップ技術として機能し得る。

図１９及び図２０は、少なくとも一部の実施形態による、オポチュニスティックハイパーバイザによる管理タスクの実行に関連するイベントの例示的なシーケンスを集合的に示す。デフォルト状態１９４５では、ゲスト仮想マシン１９１０はｐＣＰＵ１９５０を利用し、一方、ハイパーバイザ１９２５のプロセス／コンポーネントは休止状態または受動状態にとどまり（すなわちｐＣＰＵサイクルを消費しない）、ＧＶＭ１９１０がｐＣＰＵを解放するのを待機する。

ＧＶＭ１９１０は、最終的に、図１９の要素１９４７で示すように、ｐＣＰＵを自発的に解放し得る。場合によっては、ＧＶＭ１９１０は、要求１９２４（タイマーアクセス要求またはＩ／Ｏ要求などの）をハイパーバイザ１９２５に発行し得、その要求は、ＧＶＭが作業を進めることができる前に応答を必要とし、ｐＣＰＵ１９５０は、応答が取得されるまで放棄される。場合によっては、ＧＶＭ１９１０は、作業要求１９２４を発行することなくｐＣＰＵを明け渡し得る−例えば、ＧＶＭで動作中のアプリケーションがｓｌｅｅｐ（）コマンドまたは同等物を発行する場合。

要素１９４８に示すように、その後、ハイパーバイザ１９２５はｐＣＰＵ１９５０を取得し得る。ハイパーバイザは、ｔｏ−ｄｏタスクキュー１９７１を検査して、未処理の（今のところ未完了な）仮想化管理タスクが存在するかどうかを確認し得る。描かれたシナリオでは、タスクＴ５及びＴ６がｔｏ−ｄｏキュー１９７１に存在し、したがって、ハイパーバイザは、少なくともキューのヘッドのタスク（すなわちＴ５）に対応する作業を開始し得る。ＧＶＭ要求１９２４に関連する作業は継続され得る（例えば、キュー１９７１の検査及びタスクＴ５の実行と並行して）。キューされているタスクの典型的な持続時間は、様々な実施形態では、ＧＶＭ要求１９２４を処理するのに要される時間よりずっと短いものであり得る。

デキューされたタスクは、最終的に、ＧＶＭ１９１０によって明け渡されたｐＣＰＵを用いてハイパーバイザによって完了され得る（図２０の要素１９４９に示すように）。Ｔ５が完了していることを示すエントリは、描かれた実施形態では、完了タスクキュー１９５７に配置され得る。ＧＶＭ要求１９２４に関連する作業は、場合によっては、まだ継続中であり得る。ハイパーバイザは、描かれた実施形態では、タスクＴ６が未処理のままであり得るとしても、Ｔ５を終了した後でｐＣＰＵを明け渡し得る（図２０の要素１９５０に示すように）。一部の実施形態では、ハイパーバイザは、ＧＶＭ要求１９２４がどれくらいかかるかを推定し、その推定が、キューされているタスクはＧＶＭ要求が満たされる前に完了することができると示す場合、１つより多いキューされているタスク（例えばＴ５及びＴ６の両方）を行い得る。ＧＶＭ要求１９２４に対応する応答１９５２は最終的にＧＶＭ１９１０に提供され得る。次いで、ＧＶＭは、ｐＣＰＵを再取得し得、ハイパーバイザはデフォルトの休止状態に再度再エンターし得る（要素１９４５）。

先に記述したように、特定の仮想化管理タスクに対して、ハイパーバイザをアクティブ化するための割り込みベースのアプローチが取られ得る。図２１は、少なくとも一部の実施形態による、割り込み駆動型キューベースのタスクのハイパーバイザでの実装に関連する動作の態様を示す流れ図である。要素２１０１に示すように、仮想化コンピューティングサービスの制御プレーンは、要求Ｒ１を、オフロードされた仮想化マネージャコンポーネント上に送信し得る。ＯＶＭＣは、要求された動作の優先順位または緊急性を判定し得る（要素２１０４）。要素２１０７に対応する動作で判定されるように、即座のまたは緊急の応答が必要とされる場合（すなわち、要求Ｒ１が平均的な仮想化管理タスクに対して高い優先順位を有する場合）、割り込み機構が用いられてハイパーバイザをアクティブ化し得る（要素２１１０）。Ｒ１に対して必要とされる作業の詳細は、即座の実装のためにハイパーバイザに提供され得る。少なくとも一部の実施形態では、ハイパーバイザは、今度は、高い優先順位の作業を行うために、ＧＶＭを割り込みまたは一時停止し得る（要素２１１３）。先に記述したように、場合によっては、高い優先順位の要求には、ＧＶＭ−例えば、正常な通信に対応するように見えない、または、ループに閉じ込められているように見えるＧＶＭの異常なまたは期待外の状態を解決またはデバッグすることが含まれ得る。

要素２１０７に対応する動作でやはり判定されるように、Ｒ１が、即座に完了される必要がない通常の優先順位のタスクに対応する場合、キューベースのプロトコルを用いて、Ｒ１に関してハイパーバイザに非同期的に通知し得る（要素２１１６）。例えば、Ｒ１の詳細を含むタスク記述子は、キュー、または、ｐＣＰＵがＧＶＭによって放棄されハイパーバイザが受動状態からアクティブ状態に遷移するときにハイパーバイザコンポーネントによってこのタスク記述子を読み出すことができる何らかの他の場所に配置され得る。

上述したように、場合によっては、相対的に短い大部分のタスクとは対照的に、長い持続時間の仮想化管理タスクがハイパーバイザによって行われなければならない場合がある。図２２は、少なくとも一部の実施形態による、異なる期待持続時間のタスクをハイパーバイザで管理することに関連する動作の態様を示す流れ図である。要素２２０１に示すように、物理ＣＰＵはハイパーバイザに対して利用可能となり得る（例えば、ＧＶＭが自発的にｐＣＰＵを解放したとき）。ハイパーバイザは、例えば論理ｔｏ−ｄｏタスクキューのヘッドまたはパイプラインを検査することによって、まだ完了していない未処理の仮想化管理タスクＴ１を識別し得る（要素２２０４）。

仮想化管理タスクは、描かれた実施形態では、完全実行タスク（通常、持続期間が短い）と状態マシン必要タスク（持続期間が長い）として分類され得る。ハイパーバイザが、Ｔ１は完全実行タスクであると判定した場合（要素２２０７に対応する動作で判定されたように）、ハイパーバイザは、ｐＣＰＵを解放しＧＶＭの使用に戻す前に、Ｔ１を終わらせ得る（要素２２１０）。そうではなく、要素２２０７に対応する動作でやはり判定されるように、Ｔ１が状態マシンの使用を必要とするより長いタスクである場合、Ｔ１に対する状態マシン表現にアクセスし得る（または作成し得る、これがＴ１への初めての遭遇である場合）。状態マシンの次の遷移に対応する作業が実装され得る。状態マシン表現は更新されて、遷移が行われたことを示し得、ｐＣＰＵは、ハイパーバイザによって解放され得る（要素２２１３）。一部の実施形態では、タスクが状態マシンを必要とするか否かに関する決定は、オフロードされた仮想化マネージャコンポーネントで、または仮想化コンピューティングサービスの制御プレーンコンポーネントで、少なくとも部分的になされ得る−つまり、ハイパーバイザは、自身で決定をしなくてもよい場合がある。

様々な実施形態では、図５、図６、図７、図１６、図１７、図２１及び図２２の流れ図に示された動作以外の少なくともいくつかの動作が上述の様々な仮想化管理技術を実装するのに用いられ得ることに留意されたい。示される動作のうちのいくつかは、一部の実施形態では実装されなくてもよく、または、異なる順番で、もしくは逐次的ではなく並行して実装されてもよい。

図２３は、少なくとも一部の実施形態による、オポチュニスティックハイパーバイザの使用によって可能となされ得る、アプリケーションに対する応答時間のばらつきの低減の例を提供する。要素２３１０は、仮想化コンピューティングサービスのゲスト仮想マシンを用いて動作し得る時間依存のアプリケーションまたはテストの例示的な疑似コードセクションを示す。この例では、時間依存の動作の１００００回の反復がループで行われる。時間依存の動作は、場合によってはｐＣＰＵ単独で実行することができる計算を備え得、または、場合によっては要求応答モードで何らかの他のネットワークエンドポイントと通信することを含み得る。

２つのヒストグラムスタイルのグラフ２３１５及び２３１６は、それぞれ、非オポチュニスティックハイパーバイザが用いられるシナリオ及びオポチュニスティックハイパーバイザが用いられるシナリオにおける応答時間度数分布を表す。グラフのそれぞれにおいて、時間依存の動作の個々の反復に対して測定される応答時間はＸ軸に沿って増大し、応答時間の発生の度数はＹ軸に沿って増大する。従来の非オポチュニスティックハイパーバイザが用いられると、アプリケーションの時間依存の動作に関連する処理は、非常に頻繁に割り込まれ得、応答時間度数分布はグラフ２３１５に示すものと同様の結果になる。最多数の応答時間（分布のモード２３７１）は、アプリケーションタスクがあまり中断されなかった（すなわち、ハイパーバイザまたは他の仮想化管理コンポーネントによる割り込みが最小であった）シナリオに対応し得るが、それでもこのモードよりも大きい応答時間が相当数存在し、非常に多くのばらつきが示される。応答時間における広がりが大きいものは、それぞれの場合にハイパーバイザによって行われている仮想化管理タスク次第で時間量が異なる様々な割り込みである、アプリケーションの、ハイパーバイザによって生成される種々の割り込みによって生じている場合がある。

対照的に、上述の種類のオポチュニスティックハイパーバイザ（物理ＣＰＵを、ゲスト仮想マシンが自発的に放棄するまで取得しない傾向がある）が用いられるシナリオでは、応答時間の分布は全く異なり得る。応答時間の圧倒的大部分は、最小割込み値周辺に近接して集まり得、それによって、非オポチュニスティックハイパーバイザが用いられるときよりもかなり低いジッターが示される。それでも応答時間がより高い場合がいくつか存在するが、これらの場合もまた、最小割込みモード値に近接する傾向がある。オポチュニスティックかつ低フットプリントのハイパーバイザの使用によって可能となされたタイムクリティカルなアプリケーション動作に対する応答時間のばらつきの低減は、様々な実施形態において、アプリケーションの特定のクラスにとって極めて大きな価値を持ち得る。

使用事例
仮想化管理処理作業負荷の多くを、仮想化ホストのプライマリＣＰＵ及びメモリから離してオフロードする、かつ、セキュリティ機能が高められた多段階仮想化マネージャブートプロセスを実装する上述の技術は、種々の環境において有用であり得る。プロバイダネットワークで実装される多くの大規模な仮想化コンピューティングサービスでは、仮想化管理に関連するオーバーヘッドは、かなりの事業コストを意味し得る。サービス顧客の仮想マシンに割り当てることができないＣＰＵサイクル及びメモリ空間によって、プロバイダネットワーク運用者において投資へのリターンが低くなる結果となり得る。さらに、少なくとも特定のアプリケーションに対して、仮想化管理コンポーネントが顧客アプリケーションと干渉する程度は、タイムクリティカルなアプリケーションの結果に影響を与え得、したがって、顧客満足に影響を与え得る。本明細書中に記載するオフローディング技術は、仮想化管理に関連するリソース（例えばＣＰＵ及びメモリ）のフットプリントを著しく低減させ得、アプリケーションのパフォーマンスの変動を低減させ得る。サービス顧客のセキュリティ及び分離要件も、仮想化管理の多くが、オペレーティングシステムの別の管理インスタンス及び本格的なハイパーバイザを用いることによるのではなくオフロードカードから処理されるときに、より容易に満たされ得る。

本開示の実施形態は、以下の条項を鑑みて説明することができる。
１．仮想化ホストのオポチュニスティックハイパーバイザの１つまたは複数のサブコンポーネントによってアクティブ状態からデフォルトの休止状態に遷移することであって、前記仮想化ホストは、１つまたは複数の物理プロセッサを備え、前記１つまたは複数のサブコンポーネントは、前記デフォルトの休止状態では前記１つまたは複数の物理プロセッサを利用しない、前記遷移することと、
前記仮想化ホストで動作中の特定のゲスト仮想マシンが、前記仮想化ホストの特定の物理プロセッサの制御を、前記オポチュニスティックハイパーバイザによって前記特定の物理プロセッサの制御の放棄を命令されることなしに放棄したことを、前記１つまたは複数のサブコンポーネントによって判定することと、
前記特定の物理プロセッサを用いて、前記１つまたは複数のサブコンポーネントによって、未処理仮想化管理タスクのキューの特定のタスクを識別することと、
前記１つまたは複数のサブコンポーネントによって、少なくとも（ａ）前記特定の物理プロセッサの制御の放棄に先立って前記特定のゲスト仮想マシンによって要求された動作、及び（ｂ）前記特定のタスクを開始することと、
前記１つまたは複数のサブコンポーネントによって、前記デフォルトの休止状態に再遷移することであって、前記再遷移することは、前記特定の物理プロセッサを放棄して前記特定のゲスト仮想マシンの実行の再開を可能にすることを備える、前記再遷移することとを含む、方法。

２．前記識別することに先立って、前記仮想化ホストのオフロードされた仮想化マネージャコンポーネントによって、前記オポチュニスティックハイパーバイザの前記１つまたは複数のサブコンポーネントによりアクセス可能な場所に、前記特定のタスクの指示を格納することをさらに含む、条項１に記載の方法。

３．前記特定のタスクが、（ａ）前記特定のゲスト仮想マシンに関する１つまたは複数のメトリクスを収集すること、（ｂ）前記仮想化ホストの異なるゲスト仮想マシンのシャットダウンまたは再スタートを開始すること、（ｃ）前記ゲスト仮想マシンにおいて追加のゲスト仮想マシンの起動を開始すること、または、（ｄ）終了しているゲスト仮想マシンに割り当てられていたメモリの一部を上書きすることのうち１つまたは複数を含む、条項１に記載の方法。

４．前記特定のゲスト仮想マシンに代わって特定の動作が行われるであろうという判定に応じて、前記特定のゲスト仮想マシンによって前記特定の物理プロセッサの制御を解放することであって、前記特定の動作は、（ａ）タイマーを読み込むこと、または（ｂ）Ｉ／Ｏ動作を行うことのうち１つまたは複数を備える、前記解放することをさらに含む、条項１に記載の方法。

５．前記オポチュニスティックハイパーバイザの前記１つまたは複数のサブコンポーネントによって、
第２の仮想化管理タスクに関連する状態マシンの表現を永続メモリ位置に格納すること、
前記デフォルトの休止状態に再遷移した後で、前記特定の物理プロセッサが解放されているという判定に応じて、
前記第２の仮想化管理タスクの特定の状態遷移を開始する動作を行うこと、及び、
前記特定の状態遷移が完了したことを示すように前記状態マシンの前記表現を更新することを実行することをさらに含む、条項１に記載の方法。

６．１つまたは複数のハイパーバイザコンポーネント、及び、
第１のゲスト仮想マシンを含む１つまたは複数のゲスト仮想マシン
を備える仮想化ホストを備え、
前記１つまたは複数のハイパーバイザコンポーネントは、
前記第１のゲスト仮想マシンが、前記仮想化ホストの特定の物理プロセッサの制御を、前記１つまたは複数のハイパーバイザコンポーネントによって前記特定の物理プロセッサの制御の放棄を要求されることなく解放したことを判定し、
前記特定の物理プロセッサを用いて、完了していない少なくとも特定の仮想化管理タスクを識別し、
前記特定の仮想化管理タスクを開始し、
前記特定の仮想化管理タスクの少なくとも一部が行われたという判定に応じて、休止状態に入り、前記休止状態に入るのに、前記１つまたは複数のハイパーバイザコンポーネントが前記特定の物理プロセッサを放棄するように構成されている、システム。

７．前記１つまたは複数のハイパーバイザコンポーネントによってアクセス可能な場所に、前記特定の仮想化管理タスクの指示を格納するように構成されているオフロードされた仮想化マネージャコンポーネントをさらに備え、
前記特定の仮想化管理タスクを識別するために、前記１つまたは複数のハイパーバイザコンポーネントが前記場所の内容を読み出すように構成されている、条項６に記載のシステム。

８．前記オフロードされた仮想化マネージャコンポーネントが、
仮想化コンピューティングサービスの制御プレーンコンポーネントから受信したコマンドに応じて前記特定の仮想化管理タスクを生成するように構成されている、条項７に記載のシステム。

９．前記特定の仮想化管理タスクが、（ａ）前記第１のゲスト仮想マシンに関する１つまたは複数のメトリクスを収集すること、（ｂ）前記１つまたは複数のゲスト仮想マシンの異なるゲスト仮想マシンのシャットダウンまたは再スタートを開始すること、（ｃ）追加のゲスト仮想マシンの起動を開始すること、または（ｄ）終了しているゲスト仮想マシンに割り当てられていたメモリの一部を上書きすることのうち１つまたは複数を備える、条項６に記載のシステム。

１０．前記第１のゲスト仮想マシンの管理用コンポーネントが、前記第１のゲスト仮想マシンに代わって特定の動作が行われるであろうという判定に応じて、前記第１の物理プロセッサの制御を解放するように構成されており、前記特定の動作は、（ａ）タイマーを読み込むこと、または（ｂ）Ｉ／Ｏ動作を行うことのうち１つまたは複数を備える、条項６に記載のシステム。

１１．前記１つまたは複数のハイパーバイザコンポーネントが、
第２の仮想化管理タスクに関連する状態マシンの表現を永続メモリ位置に格納し、
前記休止状態に入った後で、前記特定の物理プロセッサが解放されているという判定に応じて、
前記第２の仮想化管理タスクの特定の状態遷移を開始する動作を行い、
前記休止状態への再エンターに先立って、前記特定の状態遷移が完了したことを示すように前記状態マシンの前記表現を更新するように構成された、条項６に記載のシステム。

１２．第２の仮想化管理タスクに関連する優先順位が閾値を超えているという判定に応じて、割り込みを、前記１つまたは複数のハイパーバイザコンポーネントのうちの少なくとも第１のハイパーバイザコンポーネントに発行するように構成されているオフロードされた仮想化マネージャコンポーネントをさらに備え、
前記第１のハイパーバイザコンポーネントは、
前記割り込みに応じて、前記休止状態を出て、前記第２の仮想化管理タスクを開始するように構成されている、条項６に記載のシステム。

１３．前記第２の仮想化管理タスクが、前記１つまたは複数のゲスト仮想マシンの特定のゲスト仮想マシンの不健康な状態を診断または解決する動作を行うことを備える、条項１２に記載のシステム。

１４．前記１つまたは複数のハイパーバイザコンポーネントが、（ａ）オフロードされた仮想化マネージャコンポーネントにおいて生成された通信を受信するように構成されたハイパーバイザコントローラ、（ｂ）前記１つまたは複数のゲスト仮想マシンのそれぞれに関連する各ゲスト仮想マシンマネージャ、または（ｃ）終了しているゲスト仮想マシンに割り当てられていたメモリの一部の内容を上書きするように構成されたメモリスクラバのうち１つまたは複数を備える、条項６に記載のシステム。

１５．前記１つまたは複数のハイパーバイザコンポーネントのうち少なくとも1つのハイパーバイザコンポーネントが、
前記休止状態に入るのにポーリングシステムコールを発行する、条項６に記載のシステム。

１６．１つまたは複数のプロセッサで実行されると、仮想化ホストに関連する１つまたは複数のハイパーバイザコンポーネントを実装するプログラム命令を格納する非一時的なコンピュータアクセス可能なストレージ媒体であって、前記１つまたは複数のハイパーバイザコンポーネントは、
前記仮想化ホストの第１のゲスト仮想マシンが前記仮想化ホストの特定の物理プロセッサの制御を解放したことを判定し、
前記特定の物理プロセッサを用いて、少なくとも特定の仮想化管理タスクを識別し、
前記特定の仮想化管理タスクを開始し、
前記特定のタスクの少なくとも一部が行われたとの判定に応じて、休止状態に入り、前記休止状態に入るのに、前記１つまたは複数のハイパーバイザコンポーネントが前記特定の物理プロセッサを放棄するように構成されている、前記媒体。

１７．前記特定の仮想化管理タスクを識別するのに、前記１つまたは複数のハイパーバイザコンポーネントが、
前記仮想化ホストに関連する特定のオフロードされた仮想化マネージャコンポーネントがライトアクセスを有するメモリ位置の内容を読み込むように構成されている、条項１６に記載の非一時的なコンピュータアクセス可能なストレージ媒体。

１８．前記特定の仮想化管理タスクが、（ａ）前記第１のゲスト仮想マシンに関する１つまたは複数のメトリクスを収集すること、（ｂ）前記１つまたは複数のゲスト仮想マシンの異なるゲスト仮想マシンのシャットダウンまたは再スタートを開始すること、（ｃ）追加のゲスト仮想マシンの起動を開始すること、または（ｄ）終了しているゲスト仮想マシンに割り当てられていたメモリの一部を上書きすることのうち１つまたは複数を備える、条項１６に記載の非一時的なコンピュータアクセス可能なストレージ媒体。

１９．前記１つまたは複数のハイパーバイザコンポーネントが、
第２の仮想化管理タスクに関連する状態マシンの表現を永続メモリ位置に格納し、
前記休止状態に入った後で、前記特定の物理プロセッサが解放されているという判定に応じて、
前記第２の仮想化管理タスクの特定の状態遷移を開始する動作を行い、
前記休止状態への再エンターに先立って、前記特定の状態遷移が完了したことを示すように前記状態マシンの前記表現を更新するように構成されている、条項１６に記載の非一時的なコンピュータアクセス可能なストレージ媒体。

２０．前記１つまたは複数のハイパーバイザコンポーネントが、
前記仮想化ホストに関連するオフロードされた仮想化マネージャコンポーネントから受信した割り込みに応じて、前記休止状態を出て、第２の仮想化管理タスクを開始するように構成されている、条項１６に記載の非一時的なコンピュータアクセス可能なストレージ媒体。

例示的なコンピュータシステム
少なくとも一部の実施形態では、部分的にオフロードされた仮想化マネージャなどを実装する技術を含む本明細書中に記載した技術の１つまたは複数の一部またはすべてを実装するサーバは、１つまたは複数のコンピュータアクセス可能な媒体を含むまたはそれにアクセスするように構成されている汎用コンピュータシステムを含み得る。図２４は、そのような汎用コンピューティングデバイス９０００を例示する。例示される実施形態では、コンピューティングデバイス９０００は、入力／出力（Ｉ／Ｏ）インターフェース９０３０を介して、システムメモリ９０２０（不揮発性及び揮発性メモリモジュールの両方を含み得る）に連結される、１つまたは複数のプロセッサ９０１０を含む。コンピューティングデバイス９０００は、Ｉ／Ｏインターフェース９０３０に連結されるネットワークインターフェース９０４０をさらに含む。

様々な実施形態では、コンピューティングデバイス９０００は、１つの物理プロセッサ９０１０を含むユニプロセッサシステム、または、いくつかの物理プロセッサ９０１０（例えば、２つ、４つ、８つ、または別の好適な数）を含むマルチプロセッサシステムであり得る。プロセッサ９０１０は、命令を実行することが可能な任意の好適なプロセッサであり得る。例えば、様々な実施形態では、プロセッサ９０１０は、ｘ８６、ＰｏｗｅｒＰＣ、ＳＰＡＲＣ、もしくはＭＩＰＳ ＩＳＡ、または任意の他の好適なＩＳＡなどの様々な命令セットアーキテクチャ（ＩＳＡ）のうちのいずれかを実装する、汎用または組込みプロセッサであり得る。マルチプロセッサシステムでは、プロセッサ９０１０の各々は、同じＩＳＡを一般的に実装し得るが、必ずしも実装しなくてもよい。一部の実装例では、グラフィックス処理ユニット（ＧＰＵ）は、従来のプロセッサの代わりに、またはそれらに加えて使用され得る。

システムメモリ９０２０は、プロセッサ（複数可）９０１０によってアクセス可能な命令及びデータを記憶するように構成され得る。少なくとも一部の実施形態では、システムメモリ９０２０は、揮発性及び非揮発性部分の両方を含み得、他の実施形態では、揮発性メモリのみが使用され得る。様々な実施形態では、システムメモリ９０２０の揮発性部分は、スタティックランダムアクセスメモリ（ＳＲＡＭ）、同期ダイナミックＲＡＭ、または任意の他のタイプのメモリなどの任意の適切なメモリ技術を使用して実装され得る。システムメモリの（例えば、１つまたは複数のＮＶＤＩＭＭを含み得る）非揮発性部分に関しては、一部の実施形態では、ＮＡＮＤフラッシュデバイスを含むフラッシュベースのメモリデバイスが使用され得る。少なくとも一部の実施形態では、システムメモリの不揮発性部分は、スーパーキャパシタまたは他の蓄電装置（例えば、バッテリ）などの電源を含み得る。様々な実施形態では、メモリスタベースの抵抗ランダムアクセスメモリ（ＲｅＲＡＭ）、３次元ＮＡＮＤ技術、強誘電ＲＡＭ、磁気抵抗ＲＡＭ（ＭＲＡＭ）、または様々なタイプの相変化メモリ（ＰＣＭ）のうちのいずれかが、少なくともシステムメモリの不揮発性部分に対して使用され得る。例示される実施形態では、上述のそれらの方法、技術、及びデータなどの１つまたは複数の所望の機能を実装するプログラム命令及びデータは、コード９０２５及びデータ９０２６として、システムメモリ９０２０内に記憶されることが示される。

一実施形態では、Ｉ／Ｏインターフェース９０３０は、プロセッサ９０１０と、システムメモリ９０２０と、ネットワークインターフェース９０４０、または、様々なタイプのオフロードカード、永続的及び／または揮発性記憶デバイスなどの他の周辺インターフェースを含む、デバイス内の任意の周辺デバイスとの間のＩ／Ｏトラフィックを調整するように構成され得る。一部の実施形態では、Ｉ／Ｏインターフェース９０３０は、あるコンポーネント（例えば、システムメモリ９０２０）からのデータ信号を、別のコンポーネント（例えば、プロセッサ９０１０）による使用に適した形式に変換するために、任意の必要なプロトコル、タイミング、または他のデータ変換を実行し得る。一部の実施形態では、Ｉ／Ｏインターフェース９０３０は、例えば、ペリフェラルコンポーネントインターコネクト（ＰＣＩ）またはＰＣＩ−Ｅｘｐｒｅｓｓバス規格、もしくはユニバーサルシリアルバス（ＵＳＢ）規格の変形など、様々なタイプの周辺バスを通じて取設されるデバイスに対するサポートを含み得る。一部の実施形態では、Ｉ／Ｏインターフェース９０３０の機能は、例えば、ノースブリッジ及びサウスブリッジなどの２つ以上の別々のコンポーネントに分割され得る。また、一部の実施形態では、システムメモリ９０２０へのインターフェースなどのＩ／Ｏインターフェース９０３０の機能性のうちのいくつかまたはすべては、プロセッサ９０１０に直接組み込まれ得る。

ネットワークインターフェース９０４０は、データが、コンピューティングデバイス９０００と、例えば、図１〜図２３に例示されるような他のコンピュータシステムまたはデバイスなどの、ネットワーク（１つまたは複数）９０５０に取設される他のデバイス９０６０との間で交換されることを可能にするように構成され得る。様々な実施形態では、ネットワークインターフェース９０４０は、例えば、イーサネット（登録商標）ネットワークのタイプなどの任意の適切な有線または無線の一般データネットワークを介した通信をサポートし得る。さらに、ネットワークインターフェース９０４０は、アナログ音声ネットワークまたはデジタルファイバ通信ネットワークなどの電気通信／テレフォニネットワークを介した、ファイバチャネルＳＡＮなどのストレージエリアネットワークを介した、または任意の他の適切なタイプのネットワーク及び／またはプロトコルを介した通信をサポートし得る。

一部の実施形態では、システムメモリ９０２０は、対応する方法及び装置の実施形態を実装するための図１〜図２３に関して上述のようなプログラム命令及びデータを記憶するように構成される、コンピュータアクセス可能な媒体の一実施形態であり得る。しかし、他の実施形態では、プログラム命令及び／またはデータは、異なるタイプのコンピュータアクセス可能な媒体上で、受信、送信、または記憶され得る。一般的に言えば、コンピュータアクセス可能な媒体は、Ｉ／Ｏインターフェース９０３０を介してコンピューティングデバイス９０００に連結される、磁気媒体または光媒体、例えば、ディスクまたはＤＶＤ／ＣＤなどの非一時的記憶媒体またはメモリ媒体を含み得る。非一時的コンピュータアクセス可能記憶媒体はまた、システムメモリ９０２０または別のタイプのメモリとして、コンピューティングデバイス９０００の一部の実施形態に含まれ得る、ＲＡＭ（例えば、ＳＤＲＡＭ、ＤＤＲ ＳＤＲＡＭ、ＲＤＲＡＭ、ＳＲＡＭなど）、ＲＯＭなどといった任意の揮発性または不揮発性媒体も含み得る。さらに、コンピュータアクセス可能な媒体は、ネットワークインターフェース９０４０を介して実装され得るような、ネットワーク及び／または無線リンクなどの通信媒体を介して伝送される伝送媒体または電気信号、電磁信号、もしくはデジタル信号などの信号を含み得る。図２４に示されるような複数のコンピューティングデバイスのうちの一部またはすべては、様々な実施形態では、記載される機能性を実装するために使用され得て、例えば、様々な異なるデバイス及びサーバ上で実行するソフトウェアコンポーネントが、機能性を提供するために協働し得る。一部の実施形態では、記載される機能性の一部は、汎用コンピュータシステムを使用して実装されることに加えて、またはその代わりに、記憶デバイス、ネットワークデバイス、または特殊目的コンピュータシステムを使用して実装され得る。「コンピューティングデバイス」という用語は、本明細書で使用される場合、少なくともすべてのこれらのタイプのデバイスを指し、これらのタイプのデバイスに限定されない。

結論
様々な実施形態は、命令の受信、送信、または記憶、及び／またはコンピュータアクセス可能媒体に関する前述の説明に従って実装されたデータをさらに含み得る。一般的に言えば、コンピュータアクセス可能媒体は、磁気または光学媒体、例えば、ディスクまたはＤＶＤ／ＣＤ−ＲＯＭ、ＲＡＭ（例えば、ＳＤＲＡＭ、ＤＤＲ、ＲＤＲＡＭ、ＳＲＡＭなど）、ＲＯＭなどといった揮発性または不揮発性媒体などの記憶媒体またはメモリ媒体、ならびにネットワーク及び／または無線リンクなどの通信媒体を介して伝送される伝送媒体または電気信号、電磁信号、もしくはデジタル信号などの信号を含み得る。

本明細書で図に例示され説明される様々な方法は、本方法の例となる実施形態を表す。本方法は、ソフトウェア、ハードウェア、またはこれらの組み合わせで実装され得る。方法の順序は変更され得て、様々な要素の、追加、再順位付け、組み合わせ、除外、変更などがされ得る。

本開示の利点を有する当業者に明白であるように、種々の変形及び変更を行い得る。すべてのそのような変形及び変更を含むことを意図しており、したがって、上記説明が限定的な意味ではなく、例示的であると考えるべきである。

Claims (15)

1. １つまたは複数のハイパーバイザコンポーネント、及び、
   第１のゲスト仮想マシンを含む１つまたは複数のゲスト仮想マシン
   を備える仮想化ホストを備え、
   前記１つまたは複数のハイパーバイザコンポーネントは、
   前記第１のゲスト仮想マシンが、前記仮想化ホストの特定の物理プロセッサの制御を、前記１つまたは複数のハイパーバイザコンポーネントによって前記特定の物理プロセッサの制御の放棄を要求されることなく解放したことを判定し、
   前記特定の物理プロセッサを用いて、完了していない少なくとも特定の仮想化管理タスクを識別し、
   前記特定の仮想化管理タスクを開始し、
   前記特定の仮想化管理タスクの少なくとも一部が行われたという判定に応じて、休止状態に入り、前記休止状態に入るのに、前記１つまたは複数のハイパーバイザコンポーネントが前記特定の物理プロセッサを放棄するように構成されている、システム。
2. 前記１つまたは複数のハイパーバイザコンポーネントによってアクセス可能な場所に、前記特定の仮想化管理タスクの指示を格納するように構成されているオフロードされた仮想化マネージャコンポーネントをさらに備え、
   前記特定の仮想化管理タスクを識別するのに、前記１つまたは複数のハイパーバイザコンポーネントが前記場所の内容を読み出すように構成されている、請求項１に記載のシステム。
3. 前記オフロードされた仮想化マネージャコンポーネントが、
   仮想化コンピューティングサービスの制御プレーンコンポーネントから受信したコマンドに応じて前記特定の仮想化管理タスクを生成するように構成されている、請求項２に記載のシステム。
4. 前記特定の仮想化管理タスクが、（ａ）前記第１のゲスト仮想マシンに関する１つまたは複数のメトリクスを収集すること、（ｂ）前記１つまたは複数のゲスト仮想マシンの異なるゲスト仮想マシンのシャットダウンまたは再スタートを開始すること、（ｃ）追加のゲスト仮想マシンの起動を開始すること、または（ｄ）終了しているゲスト仮想マシンに割り当てられていたメモリの一部を上書きすることのうち１つまたは複数を備える、請求項１に記載のシステム。
5. 前記第１のゲスト仮想マシンの管理用コンポーネントが、前記第１のゲスト仮想マシンに代わって特定の動作が行われるであろうという判定に応じて、第１の物理プロセッサの制御を解放するように構成されており、前記特定の動作は、（ａ）タイマーを読み込むこと、または（ｂ）Ｉ／Ｏ動作を行うことのうち１つまたは複数を備える、請求項１に記載のシステム。
6. 前記１つまたは複数のハイパーバイザコンポーネントが、
   第２の仮想化管理タスクに関連する状態マシンの表現を永続メモリ位置に格納し、
   前記休止状態に入った後で、前記特定の物理プロセッサが解放されているという判定に応じて、
   前記第２の仮想化管理タスクの特定の状態遷移を開始する動作を行い、
   前記休止状態への再エンターに先立って、前記特定の状態遷移が完了したことを示すように前記状態マシンの前記表現を更新するように構成されている、請求項１に記載のシステム。
7. 第２の仮想化管理タスクに関連する優先順位が閾値を超えているという判定に応じて、割り込みを、前記１つまたは複数のハイパーバイザコンポーネントのうちの少なくとも第１のハイパーバイザコンポーネントに発行するように構成されているオフロードされた仮想化マネージャコンポーネントをさらに備え、
   前記第１のハイパーバイザコンポーネントは、
   前記割り込みに応じて、前記休止状態を出て、前記第２の仮想化管理タスクを開始するように構成されている、請求項１に記載のシステム。
8. 前記第２の仮想化管理タスクが、前記１つまたは複数のゲスト仮想マシンの特定のゲスト仮想マシンの不健康な状態を診断または解決する動作を行うことを備える、請求項７に記載のシステム。
9. 前記１つまたは複数のハイパーバイザコンポーネントが、（ａ）オフロードされた仮想化マネージャコンポーネントにおいて生成された通信を受信するように構成されたハイパーバイザコントローラ、（ｂ）前記１つまたは複数のゲスト仮想マシンのそれぞれに関連する各ゲスト仮想マシンマネージャ、または（ｃ）終了しているゲスト仮想マシンに割り当てられていたメモリの一部の内容を上書きするように構成されたメモリスクラバのうち１つまたは複数を備える、請求項１に記載のシステム。
10. 前記１つまたは複数のハイパーバイザコンポーネントのうち少なくとも1つのハイパーバイザコンポーネントが、
    前記休止状態に入るのにポーリングシステムコールを発行する、請求項１に記載のシステム。
11. 仮想化ホストの第１のゲスト仮想マシンが前記仮想化ホストの特定の物理プロセッサの制御を解放したことを判定することと、
    前記特定の物理プロセッサを用いて、少なくとも特定の仮想化管理タスクを識別することと、
    前記特定の仮想化管理タスクを開始することと、
    前記特定のタスクの少なくとも一部が行われたという判定に応じて、休止状態に入ることであって、前記休止状態に入るのに、１つまたは複数のハイパーバイザコンポーネントが前記特定の物理プロセッサを放棄する、前記休止状態に入ることとを含む方法。
12. 前記仮想化ホストに関連する特定のオフロードされた仮想化マネージャコンポーネントがライトアクセスを有するメモリ位置の内容を読み込むことをさらに含む、請求項１１に記載の方法。
13. 前記特定の仮想化管理タスクが、（ａ）前記第１のゲスト仮想マシンに関する１つまたは複数のメトリクスを収集すること、（ｂ）前記１つまたは複数のゲスト仮想マシンの異なるゲスト仮想マシンのシャットダウンまたは再スタートを開始すること、（ｃ）追加のゲスト仮想マシンの起動を開始すること、または（ｄ）終了しているゲスト仮想マシンに割り当てられていたメモリの一部を上書きすることのうち１つまたは複数を含む、請求項１１に記載の方法。
14. 第２の仮想化管理タスクに関連する状態マシンの表現を永続メモリ位置に格納することと、
    前記休止状態に入った後で、前記特定の物理プロセッサが解放されているという判定に応じて、
    前記第２の仮想化管理タスクの特定の状態遷移を開始する動作を行うことと、
    前記休止状態に再エンターするに先立って、前記特定の状態遷移が完了したことを示すように前記状態マシンの前記表現を更新することとをさらに含む、請求項１１に記載の方法。
15. 前記仮想化ホストに関連するオフロードされた仮想化マネージャコンポーネントから受信された割り込みに応じて、前記休止状態を出て、第２の仮想化管理タスクを開始することをさらに含む、請求項１１に記載の方法。

Images