JP5657121B2 - 仮想マシンのオンデマンド型イメージ・ストリーミング - Google Patents

Description

本出願は、一般に、コンピュータ・システムに関し、より具体的には、例えばクラウド環境又は他の環境のための、仮想マシンのオンデマンド型イメージ・ストリーミングに関する。

クラウド・コンピューティング環境において、仮想マシン（ＶＭ）が必要とするブロック・デバイス・ストレージを、複数のソース：即ち、ホストの直接接続型ストレージ（ＤＡＳ、即ちローカル・ディスク）、ネットワーク接続型ストレージ（ＮＡＳ、例えばＮＦＳ）、又はストレージ・エリア・ネットワーク（ＳＡＮ）から割り当てることができる。これらの選択肢は、異なるコストで異なる性能、信頼性及び可用性を提供する。

現在周知の１つのＶＭ作成方法は、ＶＭファイル全体をｒａｗ（生の）形式で、ＮＡＳに格納された読み出し専用イメージ・テンプレートから、ホストにローカルなＤＡＳにコピーする（物理ブロック・デバイスのコンテンツのバイト単位のコピー）。それによって初めて、ホストのＶＭをブートし、実行することができる。こうした方法では、イメージ・テンプレート全体をＤＡＳにコピーするのにかかる時間が原因で、新しいＶＭを開始し使用できるまでに長い遅延が生じる。

別の周知の方法は、ホストのＤＡＳに対してコピー・オン・ライトのみを実施する、即ち、変更されたデータのみをＤＡＳ上に格納し、変更されていないデータは常にバッキング・イメージ（backing image）から読み出す。新しいＶＭの作成時にイメージ・テンプレートをＮＡＳからＤＡＳにコピーする必要がないため、ＮＡＳ上に格納されたイメージ・テンプレートをバッキング・イメージとして使用することは、より高速なＶＭ作成をサポートすることができる。しかしながら、変更されていないデータをＮＡＳから繰り返し読み出すことは、共有ＮＡＳサーバ上に過度のネットワーク・トラフィック及びＩ／Ｏ負荷をもたらし得る。これは、多数のＶＭが関与するクラウド環境において特に当てはまる。このような方法では、クラウド環境が、そうしたトラフィック及びＩ／Ｏ負荷を処理するための十分な能力を有するネットワーク及びＮＡＳサーバを提供することが求められ得る。

別の考慮事項として、既存のハイパーバイザは、そのイメージ・ファイルがＮＡＳ上に格納されている場合にしか、ＶＭをマイグレートすることができない。ことによるとＤＡＳ上で実行されているＶＭのマイグレートができない場合、クラウド・プロバイダは、単に、ホスト上の次回の保守作業をユーザに通知し、ユーザに、ＶＭの損失によって生じる結果を処理するように求めるにすぎない。これは、クラウド・サービス・プロバイダにとって簡単であるが、クラウドのユーザにとっては望ましくない場合がある。

仮想マシンのオンデマンド型イメージ・ストリーミングのための方法及びシステムを提供する。

本方法は、１つの態様において、選択された仮想マシンと関連したイメージ・メタデータを、それぞれ１つ又は複数の仮想マシンに対応する１つ又は複数のイメージ・テンプレート（バッキング・イメージとも呼ばれる）を格納するストレージ・サーバから、ホスト・コンピュータのローカル・ストレージにコピーすることを含むことができ、ここで、ホスト・コンピュータのローカル・ストレージは、最初に、選択された仮想マシンのイメージ・テンプレートを含まない。本方法はまた、コピーされたイメージ・メタデータを用いて、ホスト・コンピュータにおいて選択された仮想マシンをブートすることと、選択された仮想マシンが、ホスト・コンピュータにおいて選択された仮想マシンの実行を続行するのに必要とされるデータを、該必要とされるデータがホスト・コンピュータのローカル・ストレージ上に格納されていない場合に、ストレージ・サーバ上のイメージ・テンプレートから読み出すことを可能にすることとを含むこともできる。本方法は、イメージ・テンプレートの読み出されたデータがホスト・コンピュータのローカル・ストレージ上に格納されていない場合に、イメージ・テンプレートの読み出されたデータを、ストレージ・サーバからホスト・コンピュータのローカル・ストレージにコピーすることをさらに含むことができる。同じデータに対する後の読み出しは、ホスト・コンピュータのローカル・ストレージから行われる。本方法はまた、読み出されたデータがホスト・コンピュータのローカル・ストレージ上に格納されていることを示すように、ビットマップ内のビットを設定することを含むこともできる。本方法は、リソースのアイドル時間を利用して、選択された仮想マシンと関連したイメージ・テンプレートのデータ（バッキング・イメージ）を、ストレージ・サーバからホスト・コンピュータのローカル・ストレージにプリフェッチすることを含むこともできる。

仮想マシンのオンデマンド型イメージ・ストリーミングのための方法は、別の態様において、仮想マシンと関連したイメージ・メタデータを、その仮想マシンに対応するイメージ・テンプレートを格納するソース・コンピュータから、ターゲット・コンピュータにコピーすることを含むことができ、ここで、ターゲット・コンピュータは、最初に、仮想マシンのイメージ・テンプレートを含まない。本方法はまた、コピーされたイメージ・メタデータを用いて、ターゲット・コンピュータにおける仮想マシンをブートすることと、ターゲット・コンピュータにおける仮想マシンが、ターゲット・コンピュータにおいて仮想マシンの実行を続行するのに必要とされる、ソース・コンピュータ上のイメージ・テンプレートのデータを、イメージ・テンプレートの必要とされるデータがターゲット・コンピュータ上に格納されない場合に読み出すのを可能にすることとを含むこともできる。本方法はまた、イメージ・テンプレートの読み出されたデータがターゲット・コンピュータ上に格納されていない場合に、イメージ・テンプレートの読み出されたイメージ・データを、ソース・コンピュータからターゲット・コンピュータにコピーすることを含むことができ、ここで、同じデータの後の読み出しは、ターゲット・コンピュータにおいてコピーされたデータを読み出す。本方法は、読み出されたデータがターゲット・コンピュータ上に格納されていることを示すように、ビットマップ内のビットを設定することをさらに含むことができる。

仮想マシンのオンデマンド型イメージ・ストリーミングのためのシステムが、１つの態様において、仮想マシンと関連したイメージ・メタデータを、仮想マシンに対応するイメージ・テンプレートを格納するソース・コンピュータからコピーするように動作可能であり、最初に、仮想マシンのイメージ・テンプレートを含まない、ターゲット・コンピュータと、ターゲット・コンピュータにローカルに取り付けられたストレージ・デバイスとを含むことができる。ターゲット・コンピュータは、コピーされたイメージ・メタデータを用いて、ターゲット・コンピュータにおける仮想マシンをブートし、且つ、ターゲット・コンピュータにおける仮想マシンが、ターゲット・コンピュータにおいて仮想マシンの実行を続行するのに必要とされる、ソース・コンピュータ上のイメージ・テンプレートのデータを、イメージ・テンプレートの必要とされるデータがターゲット・コンピュータ上に格納されていない場合に読み出すのを可能にするようにさらに動作可能であり得る。ターゲット・コンピュータは、イメージ・テンプレートの読み出されたデータがターゲット・コンピュータ上に格納されていない場合に、イメージ・テンプレートの読み出されたデータを、ソース・コンピュータから、ターゲット・コンピュータにローカルに取り付けられたストレージ・デバイスにコピーするようにさらに動作可能とすることができ、ここで、同じデータの後の読み出しは、ターゲット・コンピュータにローカルに取り付けられたストレージ・デバイスから行われる。ターゲット・コンピュータは、読み出されたデータがターゲット・コンピュータ上に格納されていることを示すように、ビットマップ内のビットを設定するようにさらに動作可能とすることができる。

本明細書で説明される１つ又は複数の方法を実施するための、マシンにより実行可能な命令のプログラムを格納するコンピュータ可読ストレージ媒体を提供することもできる。

種々の実施形態の更なる特徴、並びに構造及び操作が、添付図面を参照して以下に詳細に説明される。図面において、同様の参照符号は、同一の要素又は機能的に類似する要素を示す。

１つの実施形態における本開示の仮想マシン（ＶＭ）のオンデマンド型ストリーミングにより実施されるシステム・コンポーネント及び操作フローを示す図である。 本開示の１つの実施形態におけるＯＤＳイメージ形式の簡略化された図を示す。 本開示の１つの実施形態における、ＫＶＭ／ＱＥＭＵスタック内のＯＤＳドライバを示す。 本開示の１つの実施形態におけるＲＡＷイメージを用いたＶＭ作成の比較を示す。 本開示の１つの実施形態におけるＲＡＷイメージを用いたＶＭ作成の比較を示す。 本開示のＯＤＳによるローカル・ストレージを有する仮想マシンのライブ・マイグレーションのためのシステム・コンポーネント及び操作フローを示す。 新しいＶＭを作成するための１つの実施形態における方法を示すフロー図である。 ＶＭのライブ・マイグレーションのための、１つの実施形態における方法を示すフロー図である。 １つの実施形態における本開示のＯＤＳの異なる機能の可能な異なる使用例を示す。 １つの実施形態における本開示のＯＤＳの異なる機能の可能な異なる使用例を示す。 １つの実施形態における本開示のＯＤＳの異なる機能の可能な異なる使用例を示す。 １つの実施形態における本開示のＯＤＳの異なる機能の可能な異なる使用例を示す。

本開示の１つの実施形態における仮想マシン・イメージのオンデマンド型イメージ・ストリーミング（on-demand image streaming、ＯＤＳ）は、コピー・オン・ライト（copy-on-write、ＣｏＷ）、コピー・オン・リード（copy-on-read、ＣｏＲ）、及びプリフェッチを実施することができる。コピー・オン・リードは、使用のために、コンピュータのホスト・マシンのローカル・ディスク（例えば、直接接続型ストレージ（ＤＡＳ））上に戻されるセクタのコピーを保存することにより、データ・セクタを遠隔ストレージ・サーバ（例えば、ネットワーク接続型ストレージ（ＮＡＳ））から繰り返し読み出すことを回避する。プリフェッチは、アイドル時間を用いて、仮想マシンがまだアクセスしていない残りのイメージを、遠隔ストレージ・サーバ（例えば、ＮＡＳ）からローカル・ディスク（例えば、ＤＡＳ）にコピーする。コピー・オン・ライト及びコピー・オン・リードの際、１つの実施形態における本開示は、ディスク上のデータ及びメタデータの両方を更新することを規定し、ここで、メタデータは、データが現在、遠隔ストレージ・サーバ（例えば、ＮＡＳ）の代わりに、ローカル・ディスク（例えば、ＤＡＳ）内に格納されていることを示す。

１つの実施形態における本開示のＯＤＳは、ＱＥＭＵのための新しいイメージ形式と、対応するブロック・デバイス・ドライバとを含むことができる。１つの実施形態における本開示のＯＤＳは、そのイメージがホスト・コンピュータの直接接続型ストレージ上に格納されている仮想マシンのために設計することができる。ＯＤＳの主要な使用例として、（１）遠隔ストレージ・サーバからＤＡＳへのＶＭのイメージ・テンプレートのコピーの終了を待つことのない、直接接続型ストレージ（例えばＤＡＳ、即ちホストにとってのローカル・ディスク）上での仮想マシン（ＶＭ）の即時作成、及び（２）ＤＡＳを用いてＶＭをホストする、マシン間のライブＶＭマイグレーションを含むことができる。

１つの実施形態における本開示のＯＤＳは、コピー・オン・ライト及びコピー・オン・リードの両方を実施して、遠隔ストレージ・サーバ上のデータをホストのローカル・ディスクに徐々にもたらすことができる。多数のＶＭを有するクラウド環境において、コピー・オン・リードは、ストレージ・サーバ上に過度のネットワーク・トラフィック又は入力／出力（Ｉ／Ｏ）負荷をもたらし得る、遠隔ストレージ・サーバから同じデータ・セクタを繰り返し読み出すことを回避する。１つの実施形態における本開示のＯＤＳはまた、プリフェッチを実施することもできる。本開示のＯＤＳは、アイドル時間を見つけて、まだタッチされていない（not-yet-touched）イメージ・データを遠隔ストレージ・サーバからホストのローカル・ディスクにコピーする。１つの実施形態におけるＯＤＳのイメージ形式は、（１）ヘッダ、（２）データ・セクタがローカル・ディスク上にあるのか又は遠隔ストレージ・サーバ上にあるのかを示すビットマップ、及び（３）ｒａｗ形式で格納されたイメージ・コンテンツを含むことができる。

図１は、１つの実施形態における本開示の仮想マシン（ＶＭ）のオンデマンド型ストリーミングにより実施されるシステム・コンポーネント及び操作フローを示す図である。ストレージ・サーバ１０２は、対応する１つ又は複数の仮想マシンの１つ又は複数のイメージ・テンプレート１０４を格納する。ストレージ・サーバ１０２は、通常、仮想マシン１０６をホストするホスト・コンピュータ１０８から遠隔に配置され、ネットワーク１１０を介して接続される。ストレージ・サーバ１０２の一例は、ＮＡＳサーバとすることができる。ストレージ・サーバ１０２は共有することができ（例えば、共有ストレージ・サーバ（ＳＯＮＡＳ））、且つ、ネットワーク・ファイル・システム（ＮＦＳ）を通じてエクスポートされたイメージ・テンプレートを保持することができる。ローカル・ディスク１１２の一例は、ＤＡＳとすることができる。ＤＡＳは一時ストレージ（ephemeral storage）と考えることができるのに対して、ＮＡＳは永続ストレージと考えることができる。一時ストレージは、ルート・ファイル・システムを収容するＶＭのディスク・イメージを格納するために用いることができる。ＶＭが終了すると、一時ストレージ上のデータは失われる。随意的に、ユーザは、永続ストレージをＶＭに取り付けることもできる。永続ストレージは、ＶＭの寿命より長く存在し、例えば、これを用いて関係データベースの永続データを格納することができる。クラウド環境において、場合によってはハードウェアＲＡＩＤを用いずに、ホストのローカル・ディスクにより一時ストレージが提供される。

ＶＭは、ストレージ・サーバ１０２上に格納され、全てのホスト（例えば、ＶＭをホストする又は実行しているコンピュータ又はマシン）にアクセス可能である、読み出し専用イメージ・テンプレート１０４に基づいて作成することができる。ＶＭの仮想ディスク１１４は、ホストのファイル・システム内に、通常ファイル１１６として格納することができる。ホスト・コンピュータ（計算ノード）１０８は、ＫＶＭのようなハイパーバイザを含むことができる。ハイパーバイザ（又は仮想マシン・モニタ）は、所与のマシン（ハードウェア又はプロセッサ）上で複数のオペレーティング・システムが同時に実行されるのを可能にするソフトウェア・コンポーネントである。ハイパーバイザに応じて、仮想ディスク１１４のための多数の形式をサポートすることができる。例えば、ＫＶＭ／ＱＥＭＵは、仮想ディスクのための多数の形式をサポートする。ＫＶＭは、Ｌｉｎｕｘカーネルの仮想化インフラストラクチャである。ＫＶＭは、Ｉ／ＯエミュレーションのためにＱＥＭＵを使用する。ＲＡＷ形式は、通常ファイル内に格納された物理ブロック・デバイスのコンテンツのバイト単位コピー（byte-by-copy）である。ＱＣＯＷ２は、ＱＥＭＵによりサポートされる別のイメージ形式である。ＱＣＯＷ２イメージは、変更されたデータのみを格納し、変更されていないデータは、常にバッキング・イメージ（即ち、ストレージ・サーバ、例えば、ＮＡＳ）から読み出される。

最初に、ホスト・コンピュータ１０８のローカル・ディスク１１２は、選択された仮想マシン１０６を実行するためのイメージ・テンプレートを収容していない。ＶＭ１０６を起動又はブートする命令の受信に応答して、１つの実施形態における本開示のＯＤＳは、１１６に示されるように、小容量のイメージ・メタデータ１１８をストレージ・サーバ１０２からローカル・ディスク１１２にコピーする。イメージ・メタデータは、ヘッダ及びビットマップを含む。ヘッダはイメージ・テンプレートを識別し、ビットマップは、イメージ・テンプレートのどの部分（例えば、セクタ）がローカルに格納されているかを識別するために用いられる。初期状態において、１つの実施形態におけるビットマップは、完全にゼロで埋められているイメージ・テンプレートのセクタを識別する。実行時に、ストレージ・サーバ１０２からローカル・ディスク１１２に、これらのゼロで埋められたセクタをコピーする必要はない。別の実施形態における本開示のＯＤＳは、１１６に示されるように、小容量のイメージ・メタデータ１１８を、ストレージ・サーバ１０２からローカル・ディスク１１２にコピーするステップを省略することができる。この場合、メタデータは、ローカル・ディスク１１２上のスクラッチから作成され、ビットマップ内の全てのビットは、全てのデータ・セクタがローカルに格納されていないことを示すように設定される。この形式的な実施形態は、イメージ・テンプレート内のゼロで埋められたセクタをコピーしないという利点を有する。ＶＭ１０６は、イメージ・メタデータ１１８を用いてブートされ、ＶＭ１０６が、そのブート及び実行のために用いるために、付加的なデータ１０４にアクセスし、これをストレージ・サーバ１０２から読み出すと、そのデータもまた、ローカル・イメージ１１６としてローカル・ディスク１１２上にコピー及び保存される。ビットマップ内のビットもまた、イメージ・テンプレート１０４の対応するデータ部分又はセクタがローカルに格納されたことを示すように更新される。この次にＶＭ１０６が同じデータにアクセスする必要があるときには、ネットワークを辿ってストレージ・サーバ１０２上のイメージ・テンプレート１０４にアクセスするのではなく、ローカルに格納されたバージョンが用いられる。

本開示のＯＤＳの実行時操作は、バックグラウンドにおいて、ネットワークにわたるイメージ・データの非同期式コピー・オン・リード、コピー・オン・ライト、及びプリフェッチを含むことができる。非同期式コピー・オン・リードの場合、ＶＭ１０６が初めてセクタを読み出したとき、本開示のＯＤＳにより強化されたホスト・マシン１０８上のハイパーバイザが、ネットワーク１１０にわたって、遠隔ストレージ・サーバ１０２からセクタをフェッチする。バックグラウンドにおいて、１つの実施形態における本開示のＯＤＳにより強化されたホスト・コンピュータ１０８上のハイパーバイザは、セクタをそのローカルＯＤＳファイル１１６内に格納し、これに従ってビットマップを設定する。ビットマップは、ＯＤＳイメージの一部であり、且つ、ローカル・ディスク上に格納される。本開示の１つの実施形態において、セクタの後の読み出しは、常に、ローカルＯＤＳファイル１１６からデータを直接入手する。ローカル・ディスクへの直接書き込み（コピー・オン・ライト）の場合、ＶＭがセクタを書き込むとき、１つの実施形態における本開示のＯＤＳにより強化されたホスト・コンピュータ１０８上のハイパーバイザは、ストレージ・サーバ１０２から４ＫＢデータをフェッチする必要なしに、ローカルＯＤＳファイル１１６に直接書き込みを行う。１つの実施形態における本開示のＯＤＳはまた、バックグラウンドにおいて、ネットワークにわたってイメージ・データのプリフェッチを実施することもできる。バックグラウンド操作として構成可能なポリシーに導かれ、１つの実施形態における本開示のＯＤＳにより強化されたホスト・コンピュータ１０８上のハイパーバイザは、ストリーミング方式で、ネットワーク１１０にわたってｒａｗイメージ・データ１０４全体をプリフェッチし、データをローカルＯＤＳファイル１１６内に格納することができる。例えば、プリフェッチ・ポリシーは、ＶＭ１０６が１２時間実行された後、ネットワーク１１０及びストレージ・サーバ１０２上の作業負荷が軽くなる真夜中に、プリフェッチを開始できると指示することができる。その結果、この例示的なポリシーに従うと、その寿命が１２時間より短いＶＭに対して、データはプリフェッチされない。１つの実施形態においては、システム管理者又は他のユーザがポリシーを設定することができる。

図２は、本開示の１つの実施形態におけるＯＤＳイメージ形式の簡略化された図を示す。図２に示されるＯＤＳ形式の仮想ディスクを、ホスト・マシン又はコンピュータ上で実行されている各々のＶＭについて割り当てることができる。１つの態様において、ＯＤＳイメージは、読み出し専用のバッキング・イメージに基づいている。ＯＤＳヘッダ２０２は、仮想マシンのイメージ・テンプレートを識別するための、バッキング・イメージ２０６への参照を格納する。バッキング・イメージは、永続ストレージ内に格納された仮想マシンのイメージ・テンプレートを参照する。この参照は、仮想マシンのイメージ・テンプレートのファイル名、例えば、ＯＤＳイメージが基づくｒａｗイメージの名称を格納する文字列とすることができる。他の参照を用いて、仮想マシンのイメージ・テンプレートを識別することができる。ＯＤＳイメージ形式はまた、例えば、仮想ディスク・イメージ内の各々のデータ・セクタについて１ビットを有する、ビットマップ２０４も含む。このビットは、対応するセクタの現在のコンテンツがＯＤＳイメージ内に格納されているか、又はバッキング・イメージ内に格納されているかを示す。例えば、その対応するセクタが既にｒａｗイメージからＯＤＳイメージ内にコピーされている場合、又は、セクタが既にＶＭによりローカルに書き込まれている場合、ビットは１に設定される。本開示の１つの実施形態において、ビットマップのサイズは、イメージ・テンプレートのサイズに比例する。ＯＤＳブロック・デバイス・ドライバは、例えば、ＯＤＳ形式を理解し、ＶＭが発行するディスク入力／出力（Ｉ／Ｏ）要求を処理する、ＱＥＭＵにおいて実装される。イメージ・データ２０８のためのスペースは、最初に空であってもよく、最初にデータが存在せず、最初にスペースを保持する必要がない。イメージ・データ２０８のためのスペースのサイズは、イメージ・データがコピーされるテンプレート・イメージと同じになり得る。

ＯＤＳイメージ形式はまた、拡張されたディスク・データのためのスペース２１０を含むこともできる。拡張されたディスク・データのためのスペース２１０は、任意のサイズのものとすることができ、いずれの時点でもサイズを変更して、イメージのサイズ変更をサポートすることができる。このスペース２１０に対して、テンプレート・イメージ内に対応するデータは存在しない。さらに、このスペース２１０内のデータに対応するビットマップは必要とされない。従って、ビットマップのサイズは、拡張されたディスク・データのためのスペース２１０のサイズに依存せず、拡張されたディスク・データのためのスペース２１０に起因するＯＤＳイメージのサイズ変更は、ビットマップに影響を与えない。「拡張されたディスク・データ」のサイズに関係なく、「拡張されたディスク・データのためのスペース」を付加するようにＯＤＳイメージをサイズ変更することは、一定時間の操作である。これには、ＯＤＳイメージの「ヘッダ」内の「ｄｉｓｋ＿ｓｉｚｅ」フィールドの変更しか必要としない。このスペース２１０内のデータは、ローカルにのみ使用することができる。拡張されたディスク・データのためのスペースは、随意的なものである。

新しいＶＭを開始するために、ホストは、そのバッキング・イメージ２０６への参照が、ストレージ・サーバ（例えば、ＮＡＳ）内に格納されたイメージ・テンプレートを指し示す、ローカル・ディスク（例えば、ＤＡＳ）上にＯＤＳイメージを作成する。例えば、ヘッダ及びビットマップのみを含むＯＤＳイメージを、ローカル・ディスク（例えば、ＤＡＳ）にコピーすることができる。次いで、いずれのイメージ・データ（テンプレート・イメージ）もストレージ・サーバ（例えば、ＮＡＳ）からローカル・ディスク（例えば、ＤＡＳ）にコピーすることなく、ＶＭを即時にブートすることができる、即ち、ＯＤＳイメージの「ディスク・データのためのスペース」セクション２０８は、最初は空である。一例として、１０ギガバイト（ＧＢ）のオリジナルのｒａｗイメージについて、ビットマップは、わずか２．５メガバイト（ＭＢ）とすることができる。新しいＶＭを作成し、ブートするときには、ネットワークにわたって、２．５ＭＢのビットマップ＋小容量のヘッダ・フィールドをコピーするだけでよい。ＶＭからのディスク書き込み要求を処理するとき、ＱＥＭＵのＯＤＳドライバは、データをＯＤＳイメージ２０８内に格納し、それに従ってビットマップ２０４を更新することができる。この挙動は、「コピー・オン・ライト」と呼ばれる。

ＶＭからのディスク読み出し要求を処理するとき、ＯＤＳドライバはビットマップ２０４をチェックして、要求されたデータがＯＤＳイメージ内に存在するかどうかを判断する。存在する場合、データは、ＯＤＳイメージから読み出され、ＶＭに戻される。存在しない場合、データはバッキング・イメージ２０６から読み出され、ＶＭに戻される。ＶＭが戻されたデータの処理を続行する間、バックグラウンドにおいて、戻されたデータのコピーがＯＤＳイメージ２０８内に保存され、それに従ってビットマップ２０４が更新されるので、同じデータに対する将来の読み出し要求は、ストレージ・サーバ（例えば、ＮＡＳ）上のバッキング・イメージ２０８からではなく、ローカル・ディスク（例えば、ＤＡＳ）上のＯＤＳイメージからデータを取得する。この挙動は、「コピー・オン・リード」と呼ばれる。このコピー・オン・リードの挙動を用いて、データ・セクタを、ストレージ・サーバ（例えば、ＮＡＳ）から多くとも一度で読み出すことができ、そのことは、ストレージ・サーバ（例えば、ＮＡＳ）上に過度なネットワーク・トラフィック及びＩ／Ｏ負荷を生成するのを回避する助けとなる。

コピー・オン・リードは、バッキング・イメージ２０６のコンテンツを、ストレージ・サーバ（例えば、ＮＡＳ）からホスト・コンピュータのローカル・ディスク（例えば、ＤＡＳ）に徐々にマイグレートする。ＯＤＳのプリフェッチ・メカニズムは、アイドル・リソースをさらに活用して、データ・マイグレーションを加速することができる。表１は、本開示の１つの実施形態におけるディスク上のＯＤＳイメージの詳細なレイアウトの一例を示す。

ｄｉｓｋ＿ｄａｔａセクションは、ディスク・コンテンツをｒａｗ形式で格納することができる。ｄｉｓｋ＿ｄａｔａ［ｎ＊５１２］において論理ブロック・アドレスＬＢＡ＝ｎを有するセクタのコンテンツを格納することができ、ここで５１２は、セクタ・サイズである。

図３は、本開示の１つの実施形態におけるＫＶＭ／ＱＥＭＵスタック（例えばハイパーバイザ）内のＯＤＳドライバを示す。Ｌｉｎｕｘカーネルのようなオペレーティング・システム・カーネル３０２は、ハードウェア・プロセッサ３０４上で実行することができる。オペレーティング・システム・カーネル３０２は、例えばＫＶＭ、ＫＶＭの異なるベンダ・バージョンなどの複数のハイパーバイザ・プログラムを実行することができる。ハイパーバイザの別の例は、Ｘｅｎである。ハイパーバイザ・プログラム３０６（例えば、ＫＶＭ）は、ハードウェア・プロセッサ３０４上で仮想マシン３１０を実行することを可能にする。さらに、ハイパーバイザ・プログラム３０６は、例えば、ｒａｗ形式、ｑｃｏｗ２形式、及び本開示のＯＤＳ形式などの複数の仮想イメージ形式３０８をサポートすることができる。仮想マシン３１０の起動時に、仮想マシンは、対応する仮想ディスク（ローカル・ディスク上のイメージ形式３０８）上の第１のセクタ（例えば、５１２キロバイト（ＫＢ））を読み出そうと試みる。本開示のＯＤＳと共に機能するように拡張されたハイパーバイザ・プログラムは、ＯＤＳイメージがまだ仮想ディスク（ローカル・ディスク）内に存在しないことを検出し、本開示のＯＤＳ方法を開始する（実行する）。本開示のＯＤＳは、本明細書で記載されるように、必要とされるデータをストリーミングし、１つの実施形態においては、ＶＭを殆ど即時にブートする。実装のために、他のコードを変更することなく、ｏｄｓ．ｃ及びｏｄｓ．ｈを付加するように、ハイパーバイザ・ユーザ・スペース・プログラム（例えば、ｑｅｍｕ−ｋｖｍユーザ・スペース・プログラム）を変えることができる。特に、コンピュータ・ノード（例えば、Ｌｉｎｕｘ）のカーネルに対する変更を行う必要はない。

図４及び図５は、ＲＡＷイメージ及びＯＤＳイメージを用いたＶＭ作成の比較を示す。示される例は、同時に３つのＶＭを作成する。図４に示されるように、ＲＡＷイメージ形式を用いたＶＭ作成プロセスは、イメージ・テンプレート全体がストレージ・サーバ（例えば、ＮＡＳ）からローカル・ディスク（例えば、ＤＡＳ）にコピーされるまで待つ必要があり、それによって初めてＶＭがブートされる。これは、ＶＭブート・プロセス中、コピーされるイメージ・データの大部分が必要とされず、ＶＭの寿命全体を通じてアクセスされることがない場合でさえ当てはまる。１つの実施形態における本開示のＯＤＳ作成プロセスが、図５に示される。ＯＤＳは、ローカル・ディスク（例えば、ＤＡＳ）上にいかなるイメージ・データもない状態で、ＶＭを即時にブートし、ＶＭがデータにアクセスする際に、オンデマンドで、データをストレージ・サーバ（例えば、ＮＡＳ）からホストのローカル・ディスク（例えば、ＤＡＳ）にコピーする。さらに、ＯＤＳのプリフェッチ・メカニズムは、リソースのアイドル時間を見つけて、ＶＭがアクセスしていないイメージの残りの部分又はイメージの部分を、ストレージ・サーバ（例えば、ＮＡＳ）からローカル・ディスク（例えば、ＤＡＳ）にコピーする。ＯＤＳがいずれかのリソース（例えば、ストレージ・サーバ、ローカル・ディスク、又はネットワーク）上の競合を検出した場合、ＯＤＳは一時的にプリフェッチを停止し、輻輳が消滅又は緩和した後で、プリフェッチを再開できるという点で、プリフェッチは保守的であり得る。別の実施形態においては、ひとたびイメージ・テンプレートの全体がプリフェッチ操作によりローカル・ディスクにコピーされると、本開示はまた、一般的なイメージ・テンプレートをホストのローカル・ディスク（例えば、ＤＡＳ）上にキャッシュすることもできるので、キャッシュされたイメージ・テンプレートを用いて、新しいＶＭを即時に作成すること、即ち、キャッシュ・ヒット時にイメージ・コピー・ステップを省くことができる。

１つの実施形態における本開示のＯＤＳは、コピー・オン・リードを用いて、データが必要とされる際に、オンデマンドで、データ・セクタをストレージ・サーバ（例えば、ＮＡＳ）からローカル・ディスク（例えば、ＤＡＳ）にもたらすことができる。随意的に、ＯＤＳにおいて、使用されてないアイドル・リソースを用いて、まだタッチされていないデータ・セクタをストレージ・サーバ（例えば、図１の１０２）からローカル・ストレージ（例えば、図１の１１２）にコピーするように、プリフェッチをイネーブルにすることができる。１つの実施形態における本開示のＯＤＳは、全イメージのプリフェッチを実施することができる。全イメージのプリフェッチにおいて、１つの実施形態における本開示のＯＤＳは、アイドル・リソースを用いて、例えば、最初のデータ・セクタから最後のデータ・セクタまでなど、イメージ全体をストレージ・サーバ（例えば、ＮＡＳ）からローカル・ストレージ（例えば、ＤＡＳ）に連続的にコピーする。随意的に、局所性ベースのプリフェッチにおいて、１つの実施形態は、連続的な全イメージのプリフェッチを行う代わりに、既にアクセスされたデータ・セクタのものに密接に関連した、まだアクセスされていないデータ・セクタをプリフェッチすることができる。随意的に、プロファイル・ベースのプリフェッチにおいて、１つの実施形態は、オフラインで構築されるイメージ・テンプレート・プロファイルに従って、まだアクセスされていないデータ・セクタをプリフェッチすることができる。プロファイルは、データ・セクタについてのプリフェッチの順序を、その重要性に基づいて優先順位付けすることができるか、又は、通常一緒にアクセスされるデータ・セクタを識別することができる、即ち、キャッシングの用語を用いて作業用セットを形成することができる。データ・セクタの状態が既にＳ_{ｉｎ＿ｏｄｓ}である場合、そのデータ・セクタはプリフェッチ手順により省かれる。ひとたびプリフェッチが終了すると、ＯＤＳイメージ内に、例えばａｌｌ＿ｄａｔａ＿ｉｎ＿ｏｄｓ＿ｉｍａｇｅフラグなどのフラグが設定される（例えば、表１を参照されたい）。次いで、バッキング・イメージ内のそのデータは再び必要とされないことが先験的に分かっているので、ＶＭが発行する全ての読み出し及び書き込み要求は、ビットマップをチェックすること又は更新することなしに、直接、ＯＤＳイメージのｄｉｓｋ＿ｄａｔａセクションに対して動作することができる。

プリフェッチされるデータは緊急に必要とされないので、プリフェッチは、プロセッサ（例えば、ＣＰＵ）、ストレージ・ディスク（例えば、ＤＡＳ、ＮＡＳ）、及びネットワークを含むいずれかのリソース上の競合の発生を回避しようと試みる。ＯＤＳドライバは、ストレージ・サーバ（例えば、ＮＡＳ）からデータを読み出すための応答時間Ｔ_ｒ、並びに、ローカル・ディスク（例えば、ＤＡＳ）にデータを書き込むための応答時間Ｔ_ｗを監視する。Ｔ_ｒ＜Ｃ_ｒ及びＴ_ｗ＜Ｃ_ｗである場合、ＯＤＳドライバは、プリフェッチを続行し、ここでＣ_ｒ及びＣ_ｗは、例えばＣ_ｒ＝３０ミリ秒（ｍｓ）、Ｃ_ｗ＝３０ｍｓなどの２つの一定の閾値である。いずれかの応答時間が閾値を上回った場合、ＯＤＳドライバは、乱数を生成して、プリフェッチを一時停止するかどうかについての決定を行う。１つの実施形態において、ＯＤＳドライバは、５０％の確率でプリフェッチを続行し、５０％の確率で、一定の期間プリフェッチを一時停止する。プリフェッチを一時停止するように決定した場合、ＯＤＳドライバは後で起動し、少量のデータをストレージ・サーバ（例えば、ＮＡＳ）からローカル・ディスク（例えば、ＤＡＳ）に暫定的にコピーすることにより、リソースの競合が解消したかどうかを探る。ＯＤＳドライバは応答時間を監視し、プリフェッチを続行するか、又はスリープ状態に戻るかを決定する。

応答時間が閾値を上回る場合にプリフェッチを一時停止するかどうかを決定する際のランダム性のために、本開示の１つの実施形態において、複数のＯＤＳインスタンスが互いに競合するとき、全てのＯＤＳインスタンスがプリフェッチを一時停止するまで、又はボトルネック・リソースが競合から解放されるまで、各回のプリフェッチ操作の後に、アクティブにプリフェッチしているＯＤＳインスタンスの５０％が、プリフェッチを一時停止する。

ノイズを低減させるために、応答時間は、指数移動平均として計算される。

複数の同時ディスクＩ／Ｏ要求をサブミットするリソース管理システムとは異なり、１つの実施形態における本開示のＯＤＳのプリフェッチは、リソース消費に関して保守的であり得る。例えば、本開示のＯＤＳにおけるプリフェッチは、ストレージ・サーバ（例えば、ＮＡＳ）上のバッキング・イメージに対する多くとも１つの未処理の読み出し要求と、ローカル・ディスク（例えば、ＤＡＳ）上のＯＤＳイメージに対する多くとも１つの未処理の書き込み要求とを保持する。本開示のＯＤＳにおけるプリフェッチは、ストレージ・サーバ（例えば、ＮＡＳ）から幾らかのデータ・セクタをプリフェッチした後、直ちに次の読み出し要求をストレージ・サーバ（例えば、ＮＡＳ）にサブミットし、且つ、同時に以前に戻されたデータをローカル・ディスク（例えば、ＤＡＳ）に書き込む。ネットワークの待ち時間が短く（データ・センタ内にある場合のように）、システムに競合がない場合、本開示のＯＤＳにおけるプリフェッチは、ストレージ・サーバ（例えば、ＮＡＳ）又はローカル・ディスク（例えば、ＤＡＳ）を最大限の利用率まで推進することができる。

いつプリフェッチが開始するかを制御するためのポリシーを指定することができる。例えば、高速のＶＭ作成の使用事例において、寿命の短いＶＭに対してプリフェッチが実施されないように、ＶＭが作成されてから１２時間後にプリフェッチを開始するように構成することができる。ＶＭマイグレーションを使用する場合、仮想ディスク・イメージのマイグレーションがより早く終了できるように、ＶＭがマイグレートされた直後に開始するようにプリフェッチを構成することができる。

別の実施形態における本開示のＯＤＳは、ライブＶＭマイグレーションにおいて用いることができる。例えば、クラウド環境において、ライブＶＭマイグレーションの能力は、クラウドの保守及び操作を大きく強化する。例えば、時間の経過と共に、ホストが、ハードウェアの保守（例えば、信頼できないＣＰＵファンを交換する）又はソフトウェアの保守（例えば、セキュリティ・パッチをハイパーバイザに適用する。ＫＶＭの場合、ハイパーバイザはＬｉｎｕｘである）を必要とすることは避けられない。幾つかの保守操作は、ホストのリブートを必要とし、ホスト上で実行されているＶＭに対してダウンタイムを生じさせ得る。ライブＶＭマイグレーションの能力を用いて、ユーザに感知されるダウンタイムが存在しないように、保守操作が開始する前に、影響を受けるＶＭを他のホストにマイグレートすることができる。

ＶＭをソース・ホストからターゲット・ホストにマイグレートするために、全ての既存のハイパーバイザ（ＫＶＭ、Ｘｅｎ、及びＶＭｗａｒｅを含む）は、ソース・ホスト及びターゲット・ホストの両方にアクセス可能な共用ストレージ上に、ＶＭのイメージ・ファイルを格納することを必要とする。ＤＡＳを用いる場合でさえ、ＶＭマイグレーションが成功するように、ソース・ホスト上のＶＭイメージ・ファイルが、ターゲット・ホストにアクセスできるようにすることが依然として可能である（例えば、ＮＦＳを通じて）。しかしながら、この場合、ターゲット・ホスト上のＶＭにより生成される全てのディスクＩ／Ｏ要求は、ソース・ホストに向けられ、これにより処理される。ソース・ホストのリブートにより、イメージ・ファイルが利用できなくなり、ターゲット・ホスト上で実行されているＶＭが故障する。

１つの実施形態における本開示のＯＤＳは、ホストのローカル・ディスク（例えば、ＤＡＳ）上で実行されているＶＭのライブ・マイグレーションをサポートする。図６は、本開示のＯＤＳによる、ローカル・ディスクを用いる仮想マシンのライブ・マイグレーションのためのシステム・コンポーネント及び動作フローを示す。ソース・ホストは、物理コンピュータ又はマシンであり、そのローカル・ディスク５１０上のＶＭのＯＤＳイメージ５０４を用いてＶＭ５０８を実行する。ターゲット・ホスト５０６は、ＶＭ５０８がマイグレートされる、別の物理コンピュータ又はマシンである。説明のために、ソース・ホスト５０２上のＶＭ５０８をソースＶＭと呼び、ターゲット・ホスト５０６上のＶＭをターゲットＶＭ５１２と呼ぶ。マイグレーションが開始する前に、ソース・ホスト５０２は、ＮＦＳを通じて、ＶＭのイメージ・ファイル５０４をターゲット・ホスト５０６にエクスポートし、その結果、イメージ・ファイルは、ネットワークを通じてターゲット・ホストにアクセス可能になる。ターゲット・ホスト５０６は、そのローカル・ディスク５１４（例えば、ＤＡＳ）上に、バッキング・イメージとしてソース・ホストによりエクスポートされたイメージ・ファイルを参照する又は指し示す。ＯＤＳイメージのメタデータのヘッダ・フィールドを有するＯＤＳイメージ５１６を作成する。次いで、ＶＭのイメージ・ファイル５０４をソース・ホスト５０２からターゲット・ホスト５０６に実際にコピーすることなく、ＶＭ５０８を即時にマイグレートすることができる。つまり、最初はバッキング・イメージへの参照のみを含むＯＤＳイメージ５１６のみを用いて、ターゲット・ホスト５０６上でターゲットＶＭ５１２をブートすることができる。ターゲットＶＭ５１２はターゲット・ホスト５０６上で連続して実行されているので、１つの実施形態における本開示のＯＤＳは、ターゲットＶＭ５１２が、コピー・オン・リードを通じてデータをもたらすことを可能にする。さらに、１つの実施形態における本開示のＯＤＳは、プリフェッチを用いて、イメージの残りをソース・ホスト５０２からターゲット・ホスト５０６にコピーする。ひとたびプリフェッチが終了すると、ＶＭのイメージ・ファイル５０４がターゲット・ホスト５０６に完全にコピーされ、ターゲットＶＭ５１２は、もはや決してソース・ホスト５０２に依存しない。次いで、保守のためにソース・ホスト５０２をシャットダウンすることができる。

ローカル・ストレージを用いた仮想マシンのライブ・マイグレーションに関する上述のＯＤＳプロシージャにより、ローカル・ストレージ上にデータを移動させることなく、ＶＭを即時にマイグレートすることができる。マイグレートされたＶＭ（ターゲットＶＭ）は、新しい位置で実行を続行することができ、データは、ターゲットＶＭがそれを必要とするときに、オンデマンドでコピーすることができる。ターゲットＶＭが生成した書き込みは、ローカルに格納される。リソースに関するアイドル時間を用いて、オリジナルのホスト（ソース・ホスト）上に残されたデータをプリフェッチする。ひとたび全てのデータがソース・ホストからターゲット・ホストにプリフェッチされると、マイグレーションは完全に終了する。

図７は、新しいＶＭを作成するための、１つの実施形態における仮想マシンのオンデマンド型イメージ・ストリーミング方法を示すフロー図である。６０２において、本方法は、それぞれ１つ又は複数の仮想マシンに対応する１つ又は複数のイメージ・テンプレートを格納するストレージ・サーバから、選択された仮想マシンと関連したイメージ・メタデータを、ホスト・コンピュータのローカル・ストレージにコピーすることを含むことができる。ホスト・コンピュータのローカル・ストレージは、最初は、選択された仮想マシンのイメージ・テンプレートを含まない。６０４において、本方法は、コピーされたイメージ・メタデータを用いて、ホスト・コンピュータにおいて選択された仮想マシンをブートすることを含むことができる。６０６において、本方法は、選択された仮想マシンが、ホスト・コンピュータにおいて選択された仮想マシンの実行を続行するのに必要とされるデータを、該必要とされるデータがホスト・コンピュータのローカル・ストレージ上に格納されていない場合に、ストレージ・サーバ上のイメージ・テンプレートから読み出すのを可能にすることを含むことができる。６０８において、本方法は、イメージ・テンプレートの読み出されたデータがホスト・コンピュータのローカル・ストレージ上に格納されていない場合に、イメージ・テンプレートの読み出されたデータを、ストレージ・サーバからホスト・コンピュータのローカル・ストレージにコピーすることを含むことができる。同じデータに対する後の読み出しは、ホスト・コンピュータのローカル・ストレージから行われる。６１０において、本方法は、読み出されたデータがホスト・コンピュータのローカル・ストレージ上に格納されていることを示すように、ビットマップ内のビットを設定することを含むことができる。６１２において、選択された仮想マシンによるイメージ・テンプレートへのデータ書き込みは、ホスト・コンピュータのローカル・ストレージに書き込まれる。６１４において、リソースのアイドル時間を用いて、選択された仮想マシンと関連したイメージ・テンプレートのデータを、ストレージ・サーバからホスト・コンピュータのローカル・ストレージにプリフェッチすることができる。別の態様において、イメージのプリフェッチ中、応答時間を監視することができ、例えば応答時間が閾値を上回る場合など、長い応答時間が検出された場合、プリフェッチを一時的に停止することができる。

１つの態様において、ストレージ・サーバからコピーされるイメージ・メタデータは、最初は、イメージ・テンプレートへの参照を含む。ビットを、イメージ・テンプレートの対応するセクタにマッピングするビットマップにより、ホスト・コンピュータのローカル・ストレージにおいてイメージ・メタデータを増強することができる。別の態様において、ストレージ・サーバからコピーされたイメージ・メタデータはまた、イメージ・テンプレートへの参照に加えて、このビットマップを含むこともできる。仮想マシンの実行に必要とされるデータについてのビットマップ内の対応するビットをチェックして、選択された仮想マシンを実行するのに必要とされるイメージ・テンプレートのデータが、ホスト・コンピュータのローカル・ストレージ上に格納されているかどうかを判断する。ビットマップ内のビットに応じて、選択された仮想マシンは、ストレージ・サーバ上のイメージ・テンプレート、又はホスト・コンピュータのローカル・ストレージ上のコピーされたイメージ・テンプレートを読み出す。ストレージ・サーバ及びホスト・コンピュータは、例えば、クライアントのために複数の仮想マシンがクラウドにインストールされているクラウド環境内のコンピュータとすることができる。

図８は、例えばＶＭのライブ・マイグレーションのための、仮想マシンのオンデマンド型ストリーミングのための方法を示すフロー図である。７０２において、本方法は、仮想マシンと関連したイメージ・メタデータを、仮想マシンに対応するイメージ・テンプレートを格納するソース・コンピュータからターゲット・コンピュータにコピーすることを含むことができる。ターゲット・コンピュータは、最初は、仮想マシンのイメージ・テンプレートを含まない。７０４において、本方法は、コピーされたイメージ・メタデータを用いて、ターゲット・コンピュータにおいて仮想マシンをブートすることを含むことができる。７０６において、本方法は、イメージ・テンプレートの必要とされるデータがターゲット・コンピュータ上に格納されていない場合、ターゲット・コンピュータにおける仮想マシンが、ターゲット・コンピュータにおける仮想マシンの実行を続行するのに必要とされる、ソース・コンピュータ上のイメージ・テンプレートのデータを読み出すのを可能にすることを含むことができる。７０８において、本方法は、イメージ・テンプレートの読み出されたデータがターゲット・コンピュータ上に格納されていない場合、イメージ・テンプレートのデータの読み出されたデータをソース・コンピュータからターゲット・コンピュータにコピーすることを含むことができる。同じデータに対する後の読み出しは、ターゲット・コンピュータのコピーされたデータから行われる。７１０において、本方法は、読み出されたデータがターゲット・コンピュータ上に格納されていることを示すように、ビットマップ内のビットを設定することを含むことができる。７１２において、仮想マシンのデータ書き込みは、ターゲット・コンピュータに書き込まれる。７１４において、リソースのアイドル時間を用いて、仮想マシンと関連したイメージ・テンプレートのデータを、ソース・コンピュータからターゲット・コンピュータにプリフェッチすることができる。

１つの態様において、ソース・コンピュータからコピーされたイメージ・メタデータは、最初は、イメージ・テンプレートへの参照を含む。ビットを、イメージ・テンプレートの対応するセクタにマッピングするビットマップにより、ターゲット・コンピュータにおいてイメージ・メタデータを増強することができる。別の態様において、ソース・コンピュータからコピーされたイメージ・メタデータはまた、イメージ・テンプレートへの参照に加えて、このビットマップを含むこともできる。仮想マシンの実行に必要とされるデータについてのビットマップ内の対応するビットをチェックして、仮想マシンの実行に必要とされるイメージ・テンプレートのデータがターゲット・コンピュータ上に格納されているかどうかを判断する。ビットマップ内のビットに応じて、仮想マシンは、ソース・コンピュータ上のイメージ・テンプレート、又はターゲット・コンピュータ上のコピーされたイメージ・テンプレートを読み出す。図８に示される方法は、別個のストレージ・サーバを用いる必要なしに、直接、ソース・コンピュータからターゲット・コンピュータへの仮想マシンのライブ・マイグレーションを実施することができる。そのイメージ・ファイルをマイグレートすることなく、ＶＭを即時にマイグレートすることができる。ＶＭはターゲット・ホスト上で連続して実行されているので、１つの実施形態における本開示のＯＤＳは、コピー・オン・リード及びプリフェッチを用いて、イメージ・ファイルをソース・ホストからターゲット・ホストに徐々にマイグレートすることができる。ひとたびプリフェッチが終了すると、ＶＭはもはやソース・ホストに依存する必要はなく、ソース・ホストは、保守のためにシャットダウンすることができる。

１つの態様において、異なる使用事例をサポートするように、ＯＤＳの特徴（コピー・オン・ライト、コピー・オン・リード、及びプリフェッチ）を個々にイネーブルにすることができる。図９−図１２は、１つの実施形態における本開示のＯＤＳの異なる特徴の可能な異なる使用事例を示す。図９では、ＯＤＳにおいて、コピー・オン・ライトのみがイネーブルにされる。この最も基本的な構成は、以下の利点を提供しながら、ＱＥＭＵの既存のＣＯＷイメージ形式の置換として用いることができる。：即ち、１）ＯＤＳはＱＥＭＵのｃａｃｈｅ＝ｎｏｎｅオプション及びｃａｃｈｅ＝ｗｒｉｔｅｔｈｒｏｕｇｈオプションを尊重し、停電の際に、データの完全性を保証する。２）ＯＤＳのビットマップ・セクション及びディスク・データ・セクションは、ページ境界上に適切に整合され、優れた性能を提供する。クラウド環境及び非クラウド環境とすることができる図９の設定において、ＯＤＳイメージ及びイメージ・テンプレートについてのストレージ選択肢は、柔軟性がある。両方をホストのローカル・ディスク（例えば、ＤＡＳ）上に格納することができ、両方をストレージ・サーバ（例えば、ＮＡＳ）上に格納することができ、又は一方がホストのローカル・ディスク（例えば、ＤＡＳ）上に格納され、他方がストレージ・サーバ（例えば、ＮＡＳ）上に格納される。

図１０及び図１１における設定は、イメージ・テンプレートがストレージ・サーバ（例えば、ＮＡＳ）上に格納され、ＯＤＳイメージがホスト・コンピュータのローカル・ディスク（例えば、ＤＡＳ）上に格納されるクラウド環境にとって適したものとなり得る。これらは、高速のＶＭ作成をサポートし、且つ、イメージ・テンプレートのコンテンツをＯＤＳイメージ内に徐々にマイグレートし、ネットワーク及びストレージ・サーバＮＡＳ上の過剰な負荷を回避することができる。

図１２は、イメージ・テンプレートがストレージ・サーバ（例えば、ＮＡＳ）上に格納され、３つのＯＤＳイメージが全てホスト・コンピュータのローカル・ストレージ（例えば、ＤＡＳ）上に格納されている設定を示す。この設定は、複数のＶＭが、別個のコピー・オン・ライトＯＤＳイメージを使用するが、ローカル・ストレージ（例えば、ＤＡＳ）上にイメージ・テンプレートのコンテンツのミラーを提供する「ＯＤＳ（ＣｏＲ＋プリフェッチ）」イメージの、単一の読み出し専用コピーを共有することを可能にする。この設定は、イメージ・テンプレートのコンテンツを、遠隔ネットワーク・ストレージ・サーバ（例えば、ＮＡＳ）からホスト・コンピュータのローカル・ストレージ（例えば、ＤＡＳ）に、異なるＶＭごとにその都度、複数回コピーすることを回避する。

本開示はまた、データの完全性も提供する。以下のイベントが連続して発生したと仮定する。即ち、（１）ＶＭがディスク書き込み要求をサブミットする、（２）ＯＤＳドライバが（何らかの処理の後で）書き込み操作が成功裡の完了したことを確認応答する、及び（３）ホストが即時に停電する。電力の復旧後、同じセクタに対するＶＭの次の読み出しは、故障以前に書き込まれたコンテンツを入手しなければならない。

上記の表１は、本開示の１つの実施形態におけるディスク上のＯＤＳイメージの例示的なレイアウトを示す。１つの実施形態における本開示のＯＤＳイメージは、停電がいつ発生するかに関わりなく、データの完全性を保持する。例えば、コピー・オン・ライト及びコピー・オン・リードを実施するとき、１つの実施形態における本開示のＯＤＳは、ディスク・データ及びビットマップを別個に更新することができる。下記で説明されるように、１つの実施形態における本開示において、２つの更新間の停電により、依然としてデータの完全性は損なわれない。

ビットマップ内のビットは、それぞれ、対応するセクタのコンテンツがバッキング・イメージ内又はＯＤＳイメージ内にあることを意味する２つの状態、すなわちＳ_{ｉｎ＿ｂａｃｋｉｎｇ}＝０又はＳ_{ｉｎ＿ｏｄｓ}＝１の一方とすることができる。セクタの状態は、Ｓ_{ｉｎ＿ｂａｃｋｉｎｇ}からＳ_{ｉｎ＿ｏｄｓ}にしか変更することができず、決して、Ｓ_{ｉｎ＿ｏｄｓ}からＳ_{ｉｎ＿ｂａｃｋｉｎｇ}に変更することはできない。セクタの状態をＳ_{ｉｎ＿ｂａｃｋｉｎｇ}からＳ_{ｉｎ＿ｏｄｓ}に変更することができる２つのシナリオ、即ちコピー・オン・ライト及びコピー・オン・リードが存在する。

コピー・オン・ライトは、ＯＤＳがＶＭからのディスク書き込み要求を処理するときに発生する。簡潔にするために、以下の議論は、書き込み要求が２つのディスク・セクタ（ｄ１、ｄ２）にわたると仮定する。ビット（ｄ１）及びビット（ｄ２）は、それぞれ、ビットマップにおけるｄ１及びｄ２の状態を示すものとする。書き込み操作の前には、ビット（ｄ１）＝Ｓ_{ｉｎ＿ｂａｃｋｉｎｇ}且つｂｉｔ（ｄ２）＝Ｓ_{ｉｎ＿ｂａｃｋｉｎｇ}であるとさらに仮定する。より多くのデータ・セクタが関与し、異なる初期状態を有する他の場合は、以下の例と同様の方法で分析することができる。

ＯＤＳにおける書き込み要求の処理は、次の一連の操作を含むことができる。：即ち、
・ＯＤＳ−Ｗ１：ＶＭが２つのセクタ（ｄ１、ｄ２）に関する書き込み要求を発行する。
・ＯＤＳ−Ｗ２：ＯＤＳドライバは、ｄ１を、ディスク上のＯＤＳイメージのｄｉｓｋ＿ｄａｔａセクション内に格納する。
・ＯＤＳ−Ｗ３：ＯＤＳドライバは、ｄ２を、ディスク上のＯＤＳイメージのｄｉｓｋ＿ｄａｔａセクション内に格納する。
・ＯＤＳ−Ｗ４：ＯＤＳドライバは、ビット（ｄ１）をＳ_{ｉｎ＿ｂａｃｋｉｎｇ}からＳ_{ｉｎ＿ｏｄｓ}に更新する。
・ＯＤＳ−Ｗ５：ＯＤＳドライバは、ビット（ｄ２）をＳ_{ｉｎ＿ｂａｃｋｉｎｇ}からＳ_{ｉｎ＿ｏｄｓ}に更新する。
・ＯＤＳ−Ｗ６：ＯＤＳドライバは、書き込み操作の完了をＶＭに確認応答する。

ビット（ｄ１）及びビット（ｄ２）は同じセクタに属することができるので、ＯＤＳ−Ｗ４及びＯＤＳ−Ｗ５は、単一の更新で実施できることに留意されたい。最悪の場合の分析を考慮して、最悪の場合の分析のために、ＯＤＳ−Ｗ４及びＯＤＳ−Ｗ５を分離する。

上記のいずれかのステップの後で、ホストが故障し得る。本開示は、ＯＤＳが、故障に関係なくデータの完全性を保持することを示す。特に、ＯＤＳは、ＲＡＷイメージ形式に生じ得るよりも多くの複雑さをもたすものではない。つまり、ＯＤＳにおけるデータの完全性は、少なくともＲＡＷイメージ形式におけるデータの完全性と同じくらいに良好である。

ＶＭがＲＡＷイメージ形式を使用する場合、このディスク書き込みの処理は、以下の一連の操作を含む。即ち、
・ＲＡＷ−Ｗ１：ＶＭが２つのセクタ（ｄ１、ｄ２）に関する書き込み要求を発行する。
・ＲＡＷ−Ｗ２：ＲＡＷドライバは、ｄ１をディスク上に格納する。
・ＲＡＷ−Ｗ３：ＲＡＷドライバは、ｄ２をディスク上に格納する。
・ＲＡＷ−Ｗ４：ＯＤＳドライバは、書き込み操作の完了をＶＭに確認応答する。

ＶＭの書き込み操作の前に、ｄ１及びｄ２の「古い」コンテンツがバッキング・イメージ内に格納される。ＶＭの書き込み操作の後、それらの「新しい」コンテンツが、ＯＤＳイメージ内に格納される。ここで、ＯＤＳの故障例を１つずつ考慮する。：即ち、
・ＯＤＳ−Ｗ１の後の故障。この場合、ＯＤＳの挙動は、ＲＡＷ−Ｗ１の後でＲＡＷイメージ形式に停電があるのと同等である。その影響は、書き込み操作が単純に失われることであり、ドライバがまだ書き込みの完了をＶＭに確認応答していなかったので、これは許容される正しい挙動である。
・ＯＤＳ−Ｗ２の後の故障。この場合、ｄ１はＯＤＳイメージに書き込まれるが、ビット（ｄ１）は更新されず、Ｓ_{ｉｎ＿ｂａｃｋｉｎｇ}のままである。電力の復旧後、ＶＭの次のｄ１に対する読み出しは、あたかもＯＤＳイメージ内の新しいｄ１コンテンツが存在しないかのように、バッキング・イメージからそのコンテンツを取得する。この挙動は正しく、ＲＡＷ−Ｗ１の後でＲＡＷイメージ形式に停電があるのと同等である。その影響は、書き込み操作が単純に失われることであり、ドライバがまだ書き込みの完了をＶＭに確認応答していなかったので、これは許容される正しい挙動である。
・ＯＤＳ−Ｗ３の後の故障。上記の場合と同様に、電力の復旧後、ＶＭの次のｄ１又はｄ２に対する読み出しは、あたかもＯＤＳイメージ内に新しいコンテンツが存在しないかのように、バッキング・イメージから古いコンテンツを入手する。この挙動は正しく、ＲＡＷ−Ｗ１の後でＲＡＷイメージ形式に停電があるのと同等である。
・ＯＤＳ−Ｗ４の後の故障。電力の復旧後、ＶＭの次のｄ１に対する読み出しはＯＤＳイメージからその新しいコンテンツを入手するのに対して、ＶＭの次のｄ２に対する読み出しは、バッキング・イメージからその古いコンテンツを入手する（ビット（ｄ１）＝Ｓ_{ｉｎ＿ｏｄｓ}であり、且つ、ビット（ｄ２）＝Ｓ_{ｉｎ＿ｂａｃｋｉｎｇ}であるため）。この挙動は正しくＲＡＷ−Ｗ２の後でＲＡＷイメージ形式に停電があるのと同等である。
・ＯＤＳ−Ｗ５の後の故障。電力の復旧後、ＶＭの次のｄ１又はｄ２に対する読み出しは、ＯＤＳイメージから新しいコンテンツを入手する（ビット（ｄ１）＝Ｓ_{ｉｎ＿ｏｄｓ}であり、且つ、ビット（ｄ２）＝Ｓ_{ｉｎ＿ｏｄｓ}であるため）。この挙動は正しく、ＲＡＷ−Ｗ３の後でＲＡＷイメージ形式に停電があるのと同等である、即ち、書き込み操作は完了しているが、まだ確認応答されていない。
・ＯＤＳ−Ｗ６の後の故障。電力の復旧後、ＶＭの次のｄ１又はｄ２に対する読み出しは、ＯＤＳイメージから新しいコンテンツを入手する（ビット（ｄ１）＝Ｓ_{ｉｎ＿ｏｄｓ}であり、且つ、ビット（ｄ２）＝Ｓ_{ｉｎ＿ｏｄｓ}であるため）。この挙動は正しく、ＲＡＷ−Ｗ４の後でＲＡＷイメージ形式に停電があるのに相当する。

上記の分析は、１つの実施形態における本開示のＯＤＳが、コピー・オン・ライト中にデータの完全性を保持し得ることを証明する。また、同様のプロセスの後、１つの実施形態における本開示のＯＤＳが、最初にＯＤＳイメージのディスク・データ・セクションを更新し、次いでビットマップ・セクションを更新する、正しい更新シーケンスに従うことにより、コピー・オン・リード中にデータの完全性を保持し得ることも証明することができる。

１つの実施形態における本開示のＯＤＳの実装は、ディスクの入力／出力（Ｉ／Ｏ）オーバーヘッドを低減させることができる。例えば、ＲＡＷイメージ形式に比べると、ＯＤＳの単純な実装では、ビットマップの読み出し及び書き込み時にオーバーヘッドが生じ得る。最悪の場合、ＶＭからの一組の連続した書き込み要求が、ホストのファイル・システム上に、次の書き込みシーケンス、即ち、書き込みｓ１、書き込みビット（ｓ１）、書き込みｓ２、書き込みビット（ｓ２）、書き込みｓ３、書き込みビット（ｓ３）等を生成し得る。ここで、ｓ１、ｓ２、及びｓ３は、連続した論理ブロック・アドレスを有するセクタであり、ビット（ｓｉ）は、ビットマップ内のｓｉの対応するビットである。この例において、ディスク・ヘッドは、ＯＤＳイメージのディスク・データ・セクションとビットマップ・セクションとの間を前後に移動することができる。本開示の１つの実施形態においては、最も一般的な場合における、データの完全性を損なわずに、ビットマップの更新と関連したオーバーヘッドをなくすための技術が提示される。

クラウド環境において、ＶＭのイメージ・テンプレートのサイズは、典型的には、そのＶＭに対して割り当てられる一時ストレージ・スペース（ephemeral storage space）よりもずっと小さい。例えば、ＤＡＳ上で実行されている周知のＶＭに許容される最大のイメージ・テンプレート・サイズは１０ＧＢであり、一方、そのＶＭに与えられる一時ストレージ・スペース・スペースは、１７０ＧＢ又はそれ以上である。イメージ・テンプレートに基づいてＶＭのルート・ディスクを拡張すること、又は、付加的な仮想ディスクをＶＭに取り付けることのいずれかにより、ＶＭに付加的な一時ストレージ・スペースを与えることができる。別の周知のクラウドは、企業の顧客をターゲットとしており、より柔軟な構成を提供する。このクラウドにより、ＶＭが１０ＧＢよりもずっと大容量のルート・ディスクを使用することが可能になる。

以下は、クラウドにおいて、Ｌｉｎｕｘイメージ・テンプレートを準備するプロセスである。イメージ・テンプレートは、ＲＡＷイメージ形式を用いる。初期のイメージ・テンプレート・サイズは５０ＧＢであると仮定する。イメージ・テンプレートは最初に、必要なソフトウェアがインストールされ、十分に試験される。次いで、ｒｅｓｉｚｅ２ｆｓツールを用いて、イメージ・テンプレート内のｅｘｔ３ファイル・システムをその最小サイズにサイズ変更する（例えば、５０ＧＢから１２ＧＢに至るまで）。最後に、最小のファイル・システム・サイズに適合するように、イメージ・テンプレートを切り捨てる（例えば、５０ＧＢから１２ＧＢまで）。サイズ変更ステップ及び切り捨てステップは、インストール及び試験の際に生成された不要なデータ（garbage data）を取り除き、最小サイズのイメージ・テンプレートを形成する。小容量のイメージ・テンプレートは、イメージ・テンプレートに基づいて新しいＶＭを作成する際に、ＮＡＳからＤＡＳに転送されるデータの量を減らす助けとなる。

上記の例を受けて、１２ＧＢのイメージ・テンプレートを用いて、ユーザの支払額に応じて、ルート・ディスクのサイズが変わり得るＶＭを作成することができる。例えば、次のＱＥＭＵコマンドは、ＮＦＳ上に格納された１２ＧＢのイメージ・テンプレートに基づいて、ＤＡＳ上に１００ＧＢのＯＤＳイメージを作成する。即ち、
qemu-img create -f ods -b/nfs/template.raw vm.ods 100G

ｆｄｉｓｋを用いて仮想ディスクのパーティション・サイズを１２ＧＢから１００ＧＢに拡張した後、ｒｅｓｉｚｅ２ｆｓを用いて、ＯＤＳイメージ内のｅｘｔ３ファイル・システムを１２ＧＢから１００ＧＢに拡張することができ、これが、ＶＭの大容量のルート・ファイル・システムとなる。ファイル・システムの拡張のためにｒｅｓｉｚｅ２ｆｓを用いることは、ブロックの再配置を必要としないため、迅速な操作であることに留意されたい。

表１に示されるＯＤＳイメージ形式において、ディスク・データ・サイズは、ＶＭにより認識されるＯＤＳイメージのサイズであり、有効バッキング・イメージ・サイズは、バッキング・イメージのサイズである。上記の例においては、ディスク・データ・サイズ＝１００Ｇであり、有効バッキング・イメージ・サイズ＝１２Ｇである。

図２は、ＯＤＳイメージをバッキング・イメージより大容量のものにし得る概念を示す。そのバッキング論理ブロック・アドレス（ＬＢＡ）がバッキング・イメージのサイズを上回るデータ・セクタの場合、そのコンテンツはバッキング・イメージ内に存在することができず、ＯＤＳイメージ内にのみ存在することができる。セクタの状態は先験的に知られているので、ＯＤＳイメージのビットマップ・セクションにおいてセクタの状態を捕捉する必要はない。その結果、ビットマップのサイズは、ＯＤＳイメージのサイズではなく、バッキング・イメージのサイズに比例する。

１０ＧＢのバッキング・イメージを指し示す２ＴＢのＯＤＳイメージの場合、ビットマップのサイズはわずか２．５Ｍである。サイズが小さいため、ビットマップ全体をメモリ内に容易にキャッシュすることができ、それにより、ディスクからビットマップを繰り返し読み出すオーバーヘッドが回避される。周知のクラウドにおいて、１０ＧＢは、ＤＡＳ上で実行されているＶＭに許容される最大のイメージ・テンプレート・サイズである。その論理ブロック・アドレス（ＬＢＡ）がバッキング・イメージのサイズを上回るセクタＳの場合、ＶＭからの読み出し要求を処理するとき、ＯＤＳドライバは、単にＬＢＡに基づいて、このセクタがバッキング・イメージ内に存在し得ないことを知っており、従って、ＯＤＳイメージのディスク・データ・セクションからこのセクタを読み出す。セクタＳについてＶＭからの書き込み要求を処理するとき、ＯＤＳドライバは、データをディスク・データ・セクションに直接書き込み、ビットマップを更新する必要はない（実際には、ビットマップ内のセクタＳについての対応するビットさえ存在しない）。

イメージ・テンプレートはｒｅｓｉｚｅ２ｆｓにより最小サイズに低減され、イメージ・テンプレート内のデータは、テンプレートの性質上、大部分が読み出し専用であるので（例えば、プログラム実行ファイル）、ＶＭターゲット・セクタからの大部分のディスク書き込み要求は、そのアドレスがバッキング・イメージのサイズを上回るものである。これらの書き込み要求について、ＯＤＳドライバは、データをローカル・ディスク（例えば、ＤＡＳ）に直接書き込み、ビットマップの更新におけるオーバーヘッドは存在しない。

本開示の１つの実施形態において、多くのデータ・セクタがゼロで埋められている疎（sparse）イメージ・テンプレートについて１つの最適化が以下に説明される。ＲＡＷイメージ・テンプレートｉｍａｇｅ．ｒａｗについては、ｑｅｍｕ−ｉｍｇツールを用いて、そのバッキング・イメージがｉｍａｇｅ．ｒａｗであるＯＤＳイメージ・テンプレートｉｍａｇｅ．ｏｄｓを作成することができる。ｉｍａｇｅ．ｏｄｓのサイズは、ｉｍａｇｅ．ｒａｗのサイズと同一である。ｉｍａｇｅ．ｏｄｓを作成するとき、ｑｅｍｕ−ｉｍｇは、ゼロで埋められたセクタＳを検索し、ビットマップ内のその状態をＳ_{ｉｎ＿ｏｄｓ}に設定することができる。非ゼロのセクタについての状態は、Ｓ_{ｉｎ＿ｂａｃｋｉｎｇ}に設定される。実行時に、ＶＭが、その状態がＳ_{ｉｎ＿ｏｄｓ}であるセクタＳを読み出すとき、ＯＤＳドライバは、ＯＤＳイメージのディスク・データ・セクションから読み出しを行い、ゼロで埋められたセクタが戻されるが、これは望ましい挙動である。このことは、ＯＤＳイメージがホストのファイル・システム上に疎ファイルとして格納され、セクタＳは以前に書き込まれたことがなく、従って、ホストのオペレーティング・システム（ＯＳ）がゼロで埋められたセクタを戻すことに起因している。

ＯＤＳイメージ・テンプレートｉｍａｇｅ．ｏｄｓは、ｉｍａｇｅ．ｒａｗと共にＮＡＳ上に格納される。ホスト上に新しいＶＭを作成するとき、ホストは、ｉｍａｇｅ．ｏｄｓをストレージ・サーバ（例えば、ＮＡＳ）からローカル・ストレージ（例えば、ＤＡＳ）にコピーし、ｉｍａｇｅ．ｏｄｓをより大きいターゲット・サイズにサイズ変更する。ディスク・データ・セクションが空であり、従ってｉｍａｇｅ．ｏｄｓのサイズは小さいので、ｉｍａｇｅ．ｏｄｓのコピーは高速である。具体的には、１０ＧＢのｉｍａｇｅ．ｒａｗについて、ｉｍａｇｅ．ｏｄｓは、わずかに約２．５ＭＢである。ｉｍａｇｅ．ｏｄｓのより大きい仮想ディスクへのサイズ変更は、表１内のｄｉｓｋ＿ｄａｔａ＿ｓｉｚｅフィールドをより大きい値に更新することだけを含むことができる。ＶＭがブートすると、ＯＤＳドライバは、ｄｉｓｋ＿ｄａｔａ＿ｓｉｚｅフィールドにより示されるサイズまで、ディスク・データ・セクションを自動的に切り捨てる。

ＶＭがブートすると、ＯＤＳドライバは、ＯＤＳイメージのビットマップ・セクションを、ディスクから、データ・セクタの初期状態を収容するメモリ内にロードする。本開示において、これらの２つのビットマップのコピーは、それぞれ、オンディスク状態（on-disk state）及びインメモリ状態（in-memory state）と呼ばれる。実行時に、ＯＤＳドライバは、インメモリ状態を常に最新に保持するが、ディスクのＩ／Ｏオーバーヘッドを減らすために、オンディスク状態の更新をゆっくりと（lazily）行うことができる。しかしながら、停電時に、オンディスク状態内の古い情報がデータの完全性を損なうことはないことが保証される。

ＶＭが、そのインメモリ状態がＳ_{ｉｎ＿ｏｄｓ}であるセクタを読み出すとき、ＯＤＳドライバは、そのセクタをＯＤＳイメージから読み出し、それをＶＭに戻す。付加的なオーバーヘッドは関与しない。ＶＭが、そのインメモリ状態がＳ_{ｉｎ＿ｂａｃｋｉｎｇ}であるセクタを読み出すとき、ＯＤＳドライバは、そのセクタをバッキング・イメージから読み出し、それをＶＭに戻す。ＶＭが戻されたデータの処理を続行した後、バッググラウンドにおいて（即ち、非同期的に）、ＯＤＳドライバは、セクタのコンテンツをＯＤＳイメージのディスク・データ・セクション内に書き込み、セクタのインメモリ状態をＳ_{ｉｎ＿ｂａｃｋｉｎｇ}からＳ_{ｉｎ＿ｏｄｓ}に更新する。しかしながら、セクタのオンディスク状態は更新されず、Ｓ_{ｉｎ＿ｂａｃｋｉｎｇ}のままであり、それにより、ディスクのＩ／Ｏオーバーヘッドが低減される。インメモリ状態の「ダーティ（dirty）」ビットをフラッシュし、オンディスク状態を、定期的に（例えば、１時間ごとに）又はＶＭがシャットダウンしたときに、ゆっくりと更新することができる。オンディスク状態が更新される前にホストが停電した場合、電力の復旧後、ＯＤＳドライバは、古いオンディスク状態をメモリ内に再ロードし、セクタの状態はＳ_{ｉｎ＿ｂａｃｋｉｎｇ}として認められる。このセクタに対するＶＭの次の読み出しを処理するとき、ＯＤＳドライバは、再びコピー・オン・リード・プロセスを繰り返す：即ち、バッキング・イメージからセクタを読み出し、それをＶＭに戻し、非同期的にＯＤＳイメージに書き込み、インメモリ状態をＳ_{ｉｎ＿ｂａｃｋｉｎｇ}からＳ_{ｉｎ＿ｏｄｓ}に更新する。コピー・オン・ライト中にオンディスク状態を直ちに更新せずに、ＶＭは、復旧後に依然として正しいセクタ・コンテンツを入手するが、ＶＭは、既にＯＤＳイメージにコピーされたセクタのコンテンツを無視し得る。

ＶＭがセクタに書き込むとき、ＯＤＳドライバは、オンディスク状態（インメモリ状態ではなく）をチェックして、適切なアクションを判断する。セクタのオンディスク状態がＳ_{ｉｎ＿ｏｄｓ}である場合（セクタのインメモリ状態もまたＳ_{ｉｎ＿ｏｄｓ}である）、ＯＤＳドライバは、セクタをＯＤＳイメージに直接書き込み、書き込み操作が完了したことをＶＭに通知する。ビットマップの更新オーバーヘッドは関与しない。セクタのオンディスク状態がＳ_{ｉｎ＿ｂａｃｋｉｎｇ}である場合（セクタのインメモリ状態は、Ｓ_{ｉｎ＿ｂａｃｋｉｎｇ}又はＳ_{ｉｎ＿ｏｄｓ}である）、ＯＤＳドライバは、セクタをＯＤＳイメージに書き込み、オンディスク状態をＳ_{ｉｎ＿ｏｄｓ}に更新し（インメモリ状態が現在Ｓ_{ｉｎ＿ｂａｃｋｉｎｇ}である場合、同じくそのインメモリ状態をＳ_{ｉｎ＿ｏｄｓ}に更新する）、書き込み操作の完了をＶＭに通知する。この場合、ＯＤＳドライバは、オンディスク状態を更新するオーバーヘッドを受けることがある。

別の実施形態において、メモリ・オーバーヘッドを低減させる非同期的式実装を提供することができる。ＱＥＭＵ内の全てのブロック・デバイス・ドライバは、同期Ｉ／Ｏと非同期Ｉ／Ｏの両方を行うためのＡＰＩを提供する、ＢｌｏｃｋＤｒｉｖｅｒインターフェースを実装する。同期Ｉ／Ｏは、ブロック・デバイスが、一度に１つの未処理のＩ／Ｏ要求だけを処理することを可能にする。非同期Ｉ／Ｏは、ブロック・デバイス・ドライバに、コールバック関数を通じてＩ／Ｏ操作の完了をＶＭに通知させることにより、ブロック・デバイスが、複数の未処理のＩ／Ｏ要求を同時に処理することを可能にする。

１つの実施形態における本開示のＯＤＳは、非同期インターフェースを実装する。幾つかの厄介な場合では、同一のデータ・セクタに対するコピー・オン・ライト及びコピー・オン・リードの実行は、慎重に処理される。ＶＭが、そのインメモリ状態がＳ_{ｉｎ＿ｂａｃｋｉｎｇ}であるデータ・セクタｄに対する読み出し要求Ｒ_ｄをサブミットし、次いで読み出しが終了する前に、同一のデータ・セクタｄに対する書き込み要求Ｗ_ｄをサブミットすると仮定する。これを処理するとき、ＯＤＳドライバは、次の順序で操作を終了すると仮定する。：即ち、
１．Ｒ_ｄに関するコピー・オン・リード操作の一部として、セクタの古いコンテンツをバッキング・イメージから読み出す。
２．Ｗ_ｄに関するコピー・オン・ライト操作の一部として、セクタの新しいコンテンツをＯＤＳイメージに書き込む。
３．Ｒ_ｄに関するコピー・オン・リード操作の一部として、セクタの古いコンテンツをＯＤＳイメージに書き込む。

同一のデータ・セクタに関してコピー・オン・ライト及びコピー・オン・リードを行う際に、競合状態が生じ得る。ＯＤＳイメージ内に残されるのは、セクタの古いコンテンツであり、これは正しくない結果である。この及び他の類似した競合状態を適切に処理するために、データ・セクタｄに関してコピー・オン・リードを実施する前に、ＯＤＳドライバは、ｄに関して１つの未処理のコピー・オン・ライト操作が存在するかどうかをチェックする。存在する場合、コピー・オン・リード操作を断念する。同様に、データ・セクタｄに関してコピー・オン・ライトを実施する前に、ＯＤＳドライバは、ｄに関して１つの未処理のコピー・オン・リード操作が存在するかどうかをチェックする。存在する場合、コピー・オン・ライト操作は、未処理のコピー・オン・リード操作が終了するまで遅延され、これにより、新しいコンテンツがディスク上に残されることが保証される。

１つの実施形態における本開示のＯＤＳは、次の最適化を実施することができる。：即ち、
・ＯＤＳイメージのビットマップ・セクションのサイズは、ＯＤＳイメージのサイズではなくバッキング・イメージのサイズに比例する。１０ＧＢのバッキング・イメージを指し示す２ＴＢのＯＤＳイメージについては、ビットマップのサイズはわずか２．５ＭＢである。１０ＧＢは、ＤＡＳ上で実行されている周知のクラウドのＶＭに許容される最大イメージ・テンプレート・サイズであることに留意されたい。
・ビットマップのサイズが小さいため、ビットマップの完全なコピーをメモリ内に保持して、オンディスク・ビットマップを繰り返し読み出す際のオーバーヘッドを回避することができる。
・ひとたびプリフェッチが終了すると、ＯＤＳイメージは、ＲＡＷイメージとほとんど同じように働く。ＶＭにより発行されるディスク読み出し又は書き込み要求は、インメモリ・ビットマップのチェック又はオンディスク・ビットマップの更新におけるいずれのオーバーヘッドもなしに、ＯＤＳイメージのディスク・データ・セクションに対して実行される。
・その論理ブロック・アドレスがバッキング・イメージのサイズを上回るセクタに関するＶＭの読み出し又は書き込み要求を処理するとき、ＯＤＳドライバは、インメモリ・ビットマップのチェック又はオンディスク・ビットマップの更新におけるいずれのオーバーヘッドもなしに、ＯＤＳイメージのディスク・データ・セクションを直接読み出す又は書き込む。
・インメモリ状態が既にＳ_{ｉｎ＿ｏｄｓ}であるセクタに関するＶＭの読み出し要求を処理するとき、セクタは、オンディスク・ビットマップの更新におけるオーバーヘッドなしに、ＯＤＳイメージから直接読み出される。
・コピー・オン・リード操作は、インメモリ・ビットマップを更新するだけであり、オンディスク・ビットマップを直ちに更新するわけではない。
・コピー・オン・リード操作は、データをＶＭに戻すクリティカル・パス上にない。ＶＭがバッキング・イメージから読み出されたデータの処理を続行する間、データは、バックグラウンドにおいて、ＯＤＳイメージに非同期的に保存される。
・オンディスク状態が既にＳ_{ｉｎ＿ｏｄｓ}であるセクタに関するＶＭの書き込み要求を処理するとき、オンディスク・ビットマップの更新におけるオーバーヘッドは存在しない。
・バッキング・イメージ内のセクタが完全にゼロで埋められている場合、ＯＤＳイメージのオンディスク・ビットマップにおける初期状態をＳ_{ｉｎ＿ｏｄｓ}に設定できるので、セクタの読み出し又は書き込みは、あたかもそのセクタが既にＯＤＳイメージ内にあるかのように扱われ、オンディスク・ビットマップの更新におけるオーバーヘッドは存在しない。
・ＯＤＳイメージのサイズ変更は、表１に示されるレイアウト内のｄｉｓｋ＿ｄａｔａ＿ｓｉｚｅフィールドを更新することのみを必要とする、一定時間操作である。

１つの実施形態における本開示のＯＤＳの考えは、コピー・オン・ライト、コピー・オン・リード、及びプリフェッチを含む。理論的には、コピー・オン・リード及びプリフェッチを、ＱＥＭＵにより既にサポートされている既存のコピー・オン・ライト形式（例えば、ＣｏＷ及びＱＣＯＷ２）で実装することが可能であり、このことにより、新しいイメージ形式を導入する複雑性が回避される。１つの実施形態における本開示の新しいＯＤＳイメージ形式は、最も一般的な場合、高い性能を達成する。ＣＯＷ形式は、ＯＤＳ形式とほとんど同一である。ＣＯＷ形式はまた、ヘッダ、ビットマップ・セクション、及びディスク・データ・セクションを含む。ＣＯＷドライバの現在の実装は、ＱＥＭＵのｃａｃｈｅ＝ｎｏｎｅオプション及びｃａｃｈｅ＝ｗｒｉｔｅｔｈｒｏｕｇｈオプションを無視する。その結果、これは、停電の場合に、ディスク・データを破損し得る。この実装問題は、潜在的に解決することができるが、ＣＯＷ形式自体は、そのディスク・データ・セクションが４ＫＢページ境界上に整列されないという、基本的な限界を有する。ＶＭの読み出し又は書き込み要求が仮想ディスクの４ＫＢページ境界上に整合される場合でも、要求がＣＯＷイメージのディスク・データ・セクション上で動作するように変換された後、要求は、もはやホスト・ファイル・システムの４ＫＢページ境界上に整合され得ない。ホストのページ・キャッシュは４ＫＢページ上で動作するので、不整合（misaligned）要求により、ホスト上に複数のディスクＩ／Ｏがもたらされ得る。例えば、ホスト内で、ＶＭにより発行されたうまく整合された４ＫＢ書き込みが、不整合の４ＫＢ書き込みに変換されることがあり、これは、非効率的な読み出し−修正−書き込み挙動、即ち、８ＫＢを読み出し、４ＫＢを修正し、８ＫＢを書き込み戻す挙動をもたらす。１つの実施形態における本開示のＯＤＳ形式は、表１内に示されるパディング（padding）・セクションを付加して、ｂｉｔｍａｐ（ビットマップ）セクション及びｄｉｓｋ＿ｄａｔａ（ディスク・データ）セクションが、４ＫＢページ境界上に適切に整合されることを保証することにより、この問題に対処する。

ＱＣＯＷ２は、ＱＥＭＵの「ネイティブ形式」である。ＱＣＯＷ２は、疎ファイルに対してホスト・ファイル・システムのサポートを利用する代わりに、疎イメージ・ファイルをサポートするために、それぞれの２レベル索引を実装するという点で、ＣＯＷ及びＯＤＳとは著しく異なる。この索引は、論理ブロック・アドレスを、ブロックのコンテンツが実際に格納されているイメージ・ファイル内の位置にマッピングする。このアドレス・マッピングの柔軟性により、ＱＣＯＷ２が、スナップショット及び圧縮のような高度な機能を提供することが可能になる。

他方、ＱＣＯＷ２の２レベル索引は、特に付加的なディスクが索引を読み出そうとする又は更新しようとするときにも、オーバーヘッドを受ける。ＯＤＳにおける最適化に比べて、コピー・オン・リード及びプリフェッチにより強化されたＱＣＯＷ２の潜在的な実装には、次の制限がある：即ち、
・索引のサイズは、（小容量の）バッキング・イメージのサイズではなく、（大容量の）ＱＣＯＷ２イメージのサイズに比例する。その結果、索引をメモリ内に完全にキャッシュすることができない。
・プリフェッチが終了した後でも、ＶＭにより発行される読み出し要求を処理するために、依然としてオンディスク索引を読み出す必要があり、これは、追加のディスクＩ／Ｏ操作を意味する。
・プリフェッチが終了した後でも、ＶＭにより発行される書き込み要求を処理するために、オンディスク索引を読み出す（及び潜在的に書き込む）必要がある。
・その論理ブロック・アドレスがバッキング・イメージのサイズを上回るセクタに関するＶＭの読み出し又は書き込み要求を処理するとき、依然として索引の読み出し又は書き込みを行う必要がある。
・コピー・オン・リード及びプリフェッチ操作は、索引全体をメモリ内に保持することができないので、オンディスク索引をより頻繁に更新する可能性が高い。

本開示のＯＤＳにおける最適化により、最も一般的な場合、オンディスク・ビットマップの更新におけるオーバーヘッドがなくなる。これとは対照的に、ＱＣＯＷ２の２レベル索引によっては、同じレベルの最適化を達成することはできない。ＱＣＯＷ２の高度な機能（即ち、スナップショット、圧縮、及び暗号化）はクラウドにおいて使用されないので、１つの実施形態における本開示は、より良好な性能を提供するより単純なイメージ形式、即ちＯＤＳ形式を選ぶことができる。ＱＣＯＷ２のスナップショット能力は、クラウドにとって有用となる可能性が最も高い。クラウドは、典型的には、２つのスナップショット様の機能：即ち、１）信頼できるバックアップ、及び、２）イメージ様のものをバンドルし、即ち、ルート・ファイル・システムのスナップショットを取り、それをイメージ・テンプレートに変換して、将来再利用するためにそのイメージ・テンプレートをクラウドに登録すること、を提供する。しかしながら、ＱＣＯＷ２のスナップショットは、ＤＡＳ上のＱＣＯＷ２イメージ内に格納され、従って、バックアップ・メカニズムとしては信頼できるものではなく、別のホスト上に新しいＶＭを作成するためのイメージ・テンプレートとして用いることができない。

１つの実施形態における本開示は、高速の仮想マシン（ＶＭ）作成及びクラウドにおける良好な実行時性能の両方をサポートすることができる。既存の解決策には、２つの制限：即ち、１）作成前にイメージ全体をコピーすることに起因する、遅いＶＭ作成時間（例えば、ＫＶＭにおけるｒａｗイメージ形式ドライバ）、２）遠隔ストレージ・サーバからデータを繰り返し読み出すことに起因する、実行時の高ネットワーク・トラフィック及び劣った性能（例えば、ＫＶＭにおけるｑｃｏｗ２イメージ形式ドライバ）、のうちの少なくとも１つがある。

１つの実施形態において、本開示のオンデマンド型イメージ・ストリーミング（ＯＤＳ）は、高速のＶＭプロビジョニング及び良好な実行時性能の両方を提供することができる。本開示のＯＤＳは、新しい「ｏｄｓ」イメージ形式及び対応するドライバを用いて、ハイパーバイザを強化することができる。幾つかの既存のクラウドにおいて用いられるｒａｗイメージ形式に比べて、ＯＤＳは、プロビジョニング時のみならず、ＶＭの寿命全体においても、ストレージ・サーバ上に導入するネットワーク・トラフィック及び入力／出力（Ｉ／Ｏ）負荷が少ない。幾つかの既存のクラウドにおいて用いられるｒａｗイメージ形式とは異なり、ＯＤＳは、ネットワークにわたってイメージ・テンプレートの完全なコピーを作成することなく、ＶＭをブートすることができる。ＯＤＳは、ＶＭを即時にブートし、次いで、ＶＭがデータ・ブロックにアクセスすると、オンデマンドで、ストレージ・サーバからデータ・ブロックをフェッチすることができる。

コピー・オン・ライトのみを実施し、コピー・オン・リードは実施しないので、同一のデータ・ブロックをストレージ・サーバから繰り返し読み出すことができるＱＣＯＷ２イメージ形式とは異なり、１つの実施形態における本開示のＯＤＳは、多くとも一回データ・ブロックをストレージ・サーバから読み出し、次いでそのブロックを、後で再利用するためにローカル・ディスク上に格納することができる。ＯＤＳがＱＣＯＷ２に優る本開示の別の利点は、ローカル・ディスク内のＱＣＯＷ２のデータ・レイアウトはｒａｗイメージ形式のものとは異なるが、一方、本開示のＯＤＳのデータ・ブロックのレイアウトは、ｒａｗイメージ形式のものと同一であり得るという点である。その結果、ＯＤＳの実行時性能は、ＱＣＯＷ２のものより優れたものであり得る。

実験は、１）本開示のＯＤＳが、ネットワークにわたって１７メガバイト（ＭＢ）を下回るデータを転送しながら、周知のオペレーティング・システム・サーバを１４秒以内でブートできること、及び、２）ＯＤＳの実行時性能が、ｒａｗイメージ形式と同じように良好であるという結果を示す。

別の実施形態において、本開示のＯＤＳは、ディスク、ネットワーク、及びＣＰＵのようなリソースが他の点ではアイドル状態であるとき又はアイドル状態である間、バックグラウンドにおいて、ＶＭイメージ全体をストレージ・サーバからプリフェッチする高度な機能をさらに含むことができる。この機能は、ＶＭ作成時に待機し、ＶＭイメージ全体をコピーするのではなく、ネットワーク待ち時間を隠し、リソースの消費を均等に分散させる。

本開示のＯＤＳを、クラウド環境において用いることができる。ＯＤＳはまた、非クラウド環境において用いることもできる。さらに、ＯＤＳは、例えば、高性能のＣｏＷ形式として働くように、コピー・オン・ライトだけをイネーブルにした状態で用いることができる。さらに、ＯＤＳの実装は、ゲストＶＭ（ハイパーバイザ等の上で実行されている選択されたＶＭ）に対してトランスペアレントにすることができ、従って、広範囲に適用可能である。

本開示のＯＤＳを、ハイパーバイザの一部として、又は、ハイパーバイザ若しくは同様の機能への拡張機能として実装し、例えば、ゲストＶＭに対するいかなる修正もなしに、ハイパーバイザの全ての機能を提供することができる。ＯＤＳの能力、即ち、コピー・オン・ライト、コピー・オン・リード、及びプリフェッチは、いずれの既存のハイパーバイザによっても提供されない。

ＯＤＳイメージのビットマップ・セクションのサイズは、ＯＤＳイメージのサイズではなく、バッキング・イメージのサイズに比例する。さらに、ビットマップのサイズが小さいことに起因して、ビットマップの完全なコピーをメモリ内に保持することができ、このことは、オンディスク・ビットマップを繰り返し読み出す際のオーバーヘッドを回避する。１つの態様において、コピー・オン・リード操作は、インメモリ・ビットマップを更新するだけでよく、オンディスク・ビットマップを直ちに更新する必要はなく、このことは、ディスクのＩ／Ｏオーバーヘッドを減らす助けとなる。

その論理ブロック・アドレスがバッキング・イメージのサイズを上回るセクタに関するＶＭの読み出し及び／又は書き込み要求を処理するとき、ＯＤＳドライバは、インメモリ・ビットマップのチェック及び／又はオンディスク・ビットマップの更新における如何なるオーバーヘッドもなしに、ＯＤＳイメージのディスク・データ・セクションに直接読み出す及び／又は書き込む。また、ひとたびプリフェッチが終了すると、ＶＭにより発行されたディスク読み出し及び／又は書き込み要求は、インメモリ・ビットマップのチェック及び／又はオンディスク・ビットマップの更新におけるいずれのオーバーヘッドもなしに、ＯＤＳイメージのディスク・データ・セクションに対して実行される。

別の態様において、コピー・オン・リード操作が、データをＶＭに戻すクリティカル・パス上になくてもよく、ＶＭがバッキング・イメージから読み出されたデータの処理を続行している間、バックグラウンドにおいて、データをＯＤＳイメージに非同期的に保存することができる。

さらに別の態様において、バッキング・イメージ内のデータ・セクタが完全にゼロで埋められている場合、ＯＤＳイメージのオンディスク・ビットマップにおける初期状態は、あたかもセクタがＯＤＳイメージ内に既に存在するかのように設定され、このことは、オンディスク・ビットマップの更新、及びストレージ・サーバからのデータ・セクタの読み出しにおけるオーバーヘッドを回避する。

当業者には認識されるように、本発明の態様は、システム、方法又はコンピュータ・プログラム製品として具体化することができる。従って、本発明の態様は、完全にハードウェアの実施形態、完全にソフトウェアの実施形態（ファームウェア、常駐ソフトウェア、マイクロ・コード等を含む）、又はソフトウェアの態様とハードウェアの態様とを組み合わせた実施形態の形を取ることができ、本明細書においては、これらを全て、一般的に、「回路」、「モジュール」又は「システム」と呼ぶことがある。さらに、本発明の態様は、媒体内に具体化されたコンピュータ可読プログラム・コードを有する、１つ又は複数のコンピュータ可読媒体内に具体化されたコンピュータ・プログラム製品の形態をとることができる。

１つ又は複数のコンピュータ可読媒体のいずれの組み合わせを用いることもできる。コンピュータ可読媒体は、コンピュータ可読信号媒体又はコンピュータ可読ストレージ媒体とすることができる。コンピュータ可読ストレージ媒体は、例えば、これらに限定されるものではないが、電子的、磁気的、光学的、電磁気的、赤外線若しくは半導体のシステム、機器若しくは装置、又はこれらのいずれかの適切な組み合わせとすることができる。コンピュータ可読ストレージ媒体のより具体的な例（非網羅的なリスト）として、以下のもの、即ち、１つ又は複数の配線を有する電気的接続、ポータブル・コンピュータ・ディスケット、ハード・ディスク、ランダム・アクセス・メモリ（ＲＡＭ）、読み出し専用メモリ（ＲＯＭ）、消去可能なプログラム可能読み出し専用メモリ（ＥＰＲＯＭ又はフラッシュ・メモリ）、光ファイバ、ポータブル・コンパクト・ディスク型読み出し専用メモリ（ＣＤ−ＲＯＭ）、光記憶装置、磁気記憶装置、又はこれらのいずれかの適切な組み合わせが挙げられる。本明細書の文脈においては、コンピュータ可読ストレージ媒体は、命令実行システム、機器若しくは装置によって又はそれらと関連して用いるためのプログラムを収容又は格納することが可能ないずれかの有形媒体とすることができる。

コンピュータ可読信号媒体は、例えばベースバンドに、又は搬送波の一部として、コンピュータ可読プログラム・コードが組み入れられた伝搬データ信号を含むことができる。このような伝搬信号は、電磁気、光又はそれらのいずれかの適切な組み合わせを含むがこれらに限定されない、種々の形態のうちのいずれかをとることもできる。コンピュータ可読信号媒体は、コンピュータ可読ストレージ媒体ではなく、かつ、命令実行システム、装置若しくはデバイスによって又はこれらと関連して用いるためのプログラムを通信、伝搬又搬送することができる、いずれかのコンピュータ可読媒体とすることができる。

コンピュータ可読媒体上に具体化されたプログラム・コードは、これらに限定されるものではないが、無線、有線、光ファイバ・ケーブル、ＲＦ等、又はこれらのいずれかの適切な組み合わせを含む、いずれかの適切な媒体を用いて伝送することができる。

本発明の態様についての操作を実行するためのコンピュータ・プログラム・コードは、Ｊａｖａ、Ｓｍａｌｌｔａｌｋ、Ｃ＋＋等のようなオブジェクト指向型プログラミング言語、及び「Ｃ」プログラミング言語又は同様のプログラミング言語のような従来の手続き型プログラミング言語を含む、１つ又は複数のプログラミング言語のいずれかの組み合わせで書くことができる。全体がユーザのコンピュータ上で実行される場合もあり、独立型ソフトウェア・パッケージとして、一部がユーザのコンピュータ上で実行される場合もあり、一部がユーザのコンピュータ上で実行され、一部が遠隔コンピュータ上で実行される場合もあり、又は全体が遠隔コンピュータ若しくはサーバ上で実行される場合もある。後者のシナリオにおいては、遠隔コンピュータは、ローカル・エリア・ネットワーク（ＬＡＮ）若しくは広域ネットワーク（ＷＡＮ）を含むいずれかのタイプのネットワークを通じてユーザのコンピュータに接続される場合もあり、又は外部コンピュータへの接続がなされる場合もある（例えば、インターネット・サービス・プロバイダを用いたインターネットを通じて）。

本発明の態様は、本明細書において、本発明の実施形態による方法、装置（システム）及びコンピュータ・プログラム製品のフローチャート図及び／又はブロック図を参照して説明される。フローチャート図及び／又はブロック図の各ブロック、並びにフローチャート図及び／又はブロック図におけるブロックの組み合わせは、コンピュータ・プログラム命令によって実装できることが理解されるであろう。これらのコンピュータ・プログラム命令を、汎用コンピュータ、専用コンピュータ、又は他のプログラム可能データ処理装置のプロセッサに与えて、マシンを製造し、その結果、コンピュータ又は他のプログラム可能データ処理装置のプロセッサによって実行される命令が、フローチャート及び／又はブロック図の１つ又は複数のブロックにおいて指定された機能／動作を実装するための手段を生成するようになる。

これらのコンピュータ・プログラム命令を、コンピュータ、他のプログラム可能データ処理装置、又は他のデバイスを特定の方式で機能させるように指示することができるコンピュータ可読媒体内に格納し、その結果、そのコンピュータ可読媒体内に格納された命令が、フローチャート及び／又はブロック図の１つ又は複数のブロックにおいて指定された機能／動作を実装する命令を含む製品を製造するようにすることもできる。

コンピュータ・プログラム命令をコンピュータ、他のプログラム可能データ処理装置、又は他のデバイス上にロードして、そのコンピュータ、他のプログラム可能装置、又は他のデバイス上で一連の動作ステップを行わせてコンピュータ実装プロセスを生成し、それにより、そのコンピュータ又は他のプログラム可能装置上で実行される命令が、フローチャート及び／又はブロック図の１つ又は複数のブロックにおいて指定された機能／動作を実施するためのプロセスを提供するようにすることもできる。

図面内のフローチャート及びブロック図は、本発明の種々の実施形態による、システム、方法及びコンピュータ・プログラム製品の可能な実装のアーキテクチャ、機能及び動作を示す。この点に関して、フローチャート又はブロック図内の各ブロックは、指定された論理機能を実行するための１つ又は複数の実行可能な命令を含む、モジュール、セグメント又はコードの一部を表すことができる。幾つかの代替的な実施において、ブロック内に記された機能は、図面内に記された順序とは異なる順序で行われることがあることにも留意すべきである。例えば、連続して示された２つのブロックは、関与する機能に応じて、実際には実質的に同時に実行されることもあり、又はこれらのブロックは、ときには逆の順序で実行されることもある。ブロック図及び／又はフローチャート図の各ブロック、並びにブロック図及び／又はフローチャート図内のブロックの組み合わせは、指定された機能又は動作を行う専用ハードウェアベースのシステム、又は専用ハードウェアとコンピュータ命令との組み合わせによって実装することができることにも留意されたい。

本開示のシステム及び方法は、１つ又は複数のプロセッサ及び／又はコア、メモリ、及びコンピュータ処理システムを実装する他のシステム・コンポーネント（図には明示的に示されていない）、又はコンピュータ・プログラム製品を実行することができるコンピュータを収容する処理ユニットを含むコンピュータ・システムおいて実施若しくは実行することができる。コンピュータ・プログラム製品は、例えば、ハード・ディスク、コンパクト・ディスクのようなコンパクト・ストレージ媒体、又は実行のためにコンピュータ・プログラム製品を処理システムに提供するための、当業者には周知の又は周知になるであろういずれかの技術により、処理ユニットによって読み出すことができる他のストレージ・デバイスのような媒体を含むことができる。

コンピュータ・プログラム製品は、本明細書で説明される方法の実施を可能にし、且つ、コンピュータ・システム内にロードされたとき、方法を実行することができる、それぞれの機能の全てを含むことができる。コンピュータ・プログラム、ソフトウェア・プログラム、プログラム、又はソフトウェアは、本文脈においては、情報処理機能を有するシステムに、直接的に、又は（ａ）別の言語、コード、若しくは表記法への変換、及び／又は（ｂ）異なる材料形態の複製、のいずれか又はその両方の後において、特定の機能を実行させるように意図された命令のセットの、いずれかの言語、コード、又は表記法でのいずれかの表現を意味する。

本開示のシステム及び方法を実行するコンピュータ処理システムはまた、出力表示を提示し、且つ、ユーザがデータを入力し、例えば、キーボード及びマウス・デバイス又はポインティング・デバイスなどの入力デバイスと協働して処理システムと対話することができる表示を提供するための、モニタ又は表示画面のような表示装置を含むこともできる。コンピュータ処理システムはまた、プリンタ、スキャナ、スピーカ及びいずれかの他のデバイスなどの１つ又は複数の周辺機器に、直接的に又は遠隔接続を介して接続又は結合することもできる。コンピュータ処理システムは、ローカル・イーサネット、ＷＡＮ接続、インターネット等のいずれか１つ又は複数を介して、又は異なるコンピューティング・システムを接続し、それらが互いに通信するのを可能にするいずれかの他のネットワーキング方法を介して、サーバ、他の遠隔コンピュータ処理システム、ネットワーク・ストレージ・デバイスのような１つ又は複数の他の処理システムに接続又は結合することができる。本開示のシステム及び方法の種々の機能及びモジュールは、異なる処理システム上、又は、例えばネットワーク上に局所的に若しくは分散して格納されたデータにアクセスするいずれかの単一のプラットフォーム上に実装又は分散実行することができる。

本明細書で用いられる用語は、特定の実施形態を説明するためのものであり、本発明を限定することを意図するものではない。本明細書で用いられる場合、単数形の不定冠詞（「ａ」、「ａｎ」）及び定冠詞（「ｔｈｅ」）は、文脈から明らかにそうではないことが示されていない限り、複数形も含むことが意図される。「含む（ｃｏｍｐｒｉｓｅ）」及び／又は「含んでいる（ｃｏｍｐｒｉｓｉｎｇ）」という用語は、本明細書において用いられる場合、言及した特徴、整数、ステップ、動作、要素、及び／又はコンポーネントの存在を指定するが、１つ又は複数のその他の特徴、整数、ステップ、動作、要素、コンポーネント、及び／又はそれらの群の存在又は追加を排除するものではないこともさらに理解されるであろう。

以下の特許請求の範囲における全ての「手段又はステップと機能との組合せ（ミーンズ又はステップ・プラス・ファンクション）」要素の対応する構造、材料、動作及び均等のものは、明確に特許請求されている他の特許請求された要素と組み合わせてその機能を実行するための、いかなる構造、材料又は動作をも含むことが意図される。本発明の説明は、例証及び説明の目的で提示されたものであるが、網羅的であることを意図するものでもなく、開示された形態の発明に限定することを意図するものでもない。本発明の範囲及び思想から逸脱することのない多くの修正及び変形が、当業者には明らかであろう。実施形態は、本発明の原理及び実際の適用を最も良く説明するように、及び、当業者が、企図される特定の使用に適するように種々の修正を伴う種々の実施形態について本発明を理解することを可能にするように、選択され、説明された。

本開示の種々の態様が、プログラム、ソフトウェア、又は、コンピュータ、プロセッサ及び／又はマシン上で実行されたときに、コンピュータ若しくはマシンに方法のステップを実行させる、コンピュータ若しくはマシン使用可能媒体若しくは可読媒体において具体化されたコンピュータ命令として具体化することができる。本開示において説明される種々の機能及び方法を実行するために、マシンにより実行可能な命令のプログラムを実体的に具体化する、マシン可読のプログラム・ストレージ・デバイスも提供される。

本開示のシステム及び方法は、汎用コンピュータ又は専用コンピュータ・システム上で実装又は実行することができる。コンピュータ・システムは、いずれのタイプの周知の又は周知になるであろうシステムとすることができ、且つ、典型的には、プロセッサ、メモリ・デバイス、ストレージ・デバイス、入力／出力デバイス、内部バス、及び／又は通信ハードウェア及びソフトウェア等と共に他のコンピュータ・システムと通信するための通信インターフェースを含むことができる。

本出願において用いることができる「コンピュータ・システム」及び「コンピュータ・ネットワーク」という用語は、固定型及び／又は携帯型のコンピュータ、ハードウェア、ソフトウェア、周辺機器、及びストレージ・デバイスの種々の組み合わせを含むことができる。コンピュータ・システムは、協働して実行するようにネットワーク化された又は他の方法で接続された複数の個々のコンポーネントを含むことができる。本出願のコンピュータ・システムのハードウェア及びソフトウェア・コンポーネントは、デスクトップ、ラップトップなどの固定型デバイス及び携帯型デバイス、及び／又はサーバを含むことができ、且つ、これらの内部に含まれ得る。モジュールは、デバイスのコンポーネント、ソフトウェア、プログラム、又は何らかの「機能」を実装するシステムとすることができ、これらは、ソフトウェア、ハードウェア、ファームウェア、電子回路等として具体化することができる。

上述の実施形態は、説明に役立つ実例であり、本発明がこれらの特定の実施形態に制限されると解釈すべきではない。従って、添付の特許請求の範囲内に定められるような本発明の思想又は範囲から逸脱することなく、当業者により、種々の変更及び修正を行うことができる。

１０２：ストレージ・サーバ
１０４：イメージ・テンプレート、ｒａｗイメージ・データ
１０６、３１０、５０８：仮想マシン（ＶＭ）
１０８：ホスト・コンピュータ（計算ノード、ホスト・マシン）
１１０：ネットワーク
１１２：ローカル・ディスク
１１４：仮想ディスク
１１６：通常ファイル（ＯＤＳファイル）
１１８：イメージ・メタデータ
２０２：ＯＤＳヘッダ
２０４：ビットマップ
２０６：バッキング・イメージ
２０８：イメージ・データのためのスペース
２１０：拡張されたディスク・データのためのスペース
３０２：オペレーティング・システム・カーネル
３０４：ハードウェア・プロセッサ
３０６：ハイパーバイザ・プログラム
３０８：仮想イメージ形式
５０２：ソース・ホスト
５０４：ＯＤＳイメージ
５０６：ターゲット・ホスト
５１０：ローカル・ディスク
５１２：ターゲットＶＭ
５１４：ローカル・ディスク
５１６：ＯＤＳイメージ

Claims (25)

1. 仮想マシンのオンデマンド型イメージ・ストリーミングのための方法であって、
   選択された仮想マシンと関連したイメージ・メタデータを、それぞれ１つ又は複数の仮想マシンに対応する１つ又は複数のイメージ・テンプレートを格納するストレージ・サーバから、ホスト・コンピュータのローカル・ストレージにコピーするステップであって、前記ホスト・コンピュータのローカル・ストレージは、最初に、前記選択された仮想マシンのイメージ・テンプレートを含まず、前記イメージ・メタデータは、最初に、前記選択された仮想マシンに関連したイメージ・テンプレートへの参照のみを有するヘッダ部分を含む、コピーするステップと、
   前記コピーされたイメージ・メタデータを用いて、前記ホスト・コンピュータにおいて前記選択された仮想マシンをブートするステップであって、ブート時に必要に応じて前記ストレージ・サーバからの前記イメージ・テンプレートにアクセスすることによってブートするステップと、
   前記選択された仮想マシンが、前記ホスト・コンピュータにおいて前記選択された仮想マシンの実行を続行するのに必要とされるデータを、前記必要とされるデータが前記ホスト・コンピュータのローカル・ストレージ上に格納されていない場合に、前記ストレージ・サーバ上の前記イメージ・テンプレートから読み出すことを可能にするステップと、
   前記イメージ・テンプレートの前記読み出されたデータが前記ホスト・コンピュータのローカル・ストレージ上に格納されていない場合に、前記イメージ・テンプレートの前記読み出されたデータを、前記ストレージ・サーバから前記ホスト・コンピュータのローカル・ストレージにコピーするステップであって、同じデータに対する後の読み出しは前記ホスト・コンピュータのローカル・ストレージから行われる、コピーするステップと、
   前記読み出されたデータが前記ホスト・コンピュータのローカル・ストレージ上に格納されていることを示すように、ビットマップ内のビットを設定するステップであって、該ビットマップは、前記イメージ・メタデータの一部を形成する、設定するステップと、
   リソースのアイドル時間を用いて、前記選択された仮想マシンと関連した前記イメージ・テンプレートのデータを、前記ストレージ・サーバから前記ホスト・コンピュータのローカル・ストレージにプリフェッチするステップと、
   を含む方法。
2. 前記イメージ・メタデータは、最初に、前記イメージ・テンプレートへの参照、及びビットを前記イメージ・テンプレートの対応するセクタにマッピングする前記ビットマップを含む、請求項１に記載の方法。
3. イメージのプリフェッチ中に応答時間が監視され、応答時間が閾値を上回った場合、プリフェッチが一時的に停止される、請求項１に記載の方法。
4. 前記ビットマップのサイズは、前記ホスト・コンピュータのローカル・ストレージ上に格納された前記対応するイメージのサイズではなく、前記ストレージ・サーバ上の前記イメージ・テンプレートのサイズに比例する、請求項１に記載の方法。
5. 前記ビットマップの完全なコピーは、メモリ内に保持することができる、請求項１に記載の方法。
6. その論理ブロック・アドレスが前記ストレージ・サーバ上の前記イメージ・テンプレートのサイズを上回るセクタに対する、前記選択された仮想マシンの読み出し及び／又は書き込み要求は、前記ビットマップのチェック及び／又は前記ビットマップの更新を行わずに、直接、前記セクタを読み出すこと及び／又は前記ホスト・コンピュータのローカル・ストレージに書き込むことによって処理される、請求項１に記載の方法。
7. 前記プリフェッチの終了後、前記選択された仮想マシンにより発行される１つ又は複数のディスク読み出し及び／又は書き込み要求は、前記ビットマップのチェック及び／又は前記ビットマップの更新を行わずに、直接、前記ホスト・コンピュータのローカル・ストレージ上に格納されたイメージ・データを用いて実行される、請求項１に記載の方法。
8. 前記ビットマップは、前記ホスト・コンピュータにおいてメモリ内及びディスク上に保持され、コピー・オン・リード操作は、前記インメモリ・ビットマップを更新するだけであり、前記オンディスク・ビットマップを即時に更新しない、請求項１に記載の方法。
9. コピー・オン・リード操作は、前記データを前記仮想マシンに戻すクリティカル・パス上になく、前記データは、前記仮想マシンがバッキング・イメージから読み出された前記データの処理を続行する間、バックグラウンドにおいて、ＯＤＳイメージに非同期的に保存される、請求項１に記載の方法。
10. 前記ストレージ・サーバ上の前記イメージ・テンプレート内のデータ・セクタが完全にゼロで埋められている場合、前記ホスト・コンピュータのローカル・ストレージ上に格納されている前記ビットマップ内の前記データ・セクタの初期状態は、あたかも前記データ・セクタが前記ホスト・コンピュータのローカル・ストレージに既にコピーされているように設定される、請求項１に記載の方法。
11. 前記方法は、ハイパーバイザにおいて実装され、前記選択された仮想マシンに対する修正なしに、前記ハイパーバイザの機能を提供する、請求項１に記載の方法。
12. 仮想マシンのオンデマンド型イメージ・ストリーミングのための方法であって、
    選択された仮想マシンと関連したイメージ・メタデータを、前記仮想マシンに対応するイメージ・テンプレートを格納するソース・コンピュータから、ターゲット・コンピュータにコピーするステップであって、前記ターゲット・コンピュータは、最初に、前記仮想マシンの前記イメージ・テンプレートを含まず、前記イメージ・メタデータは、最初に、前記選択された仮想マシンに関連したイメージ・テンプレートへの参照のみを有するヘッダ部分を含む、コピーするステップと、
    前記コピーされたイメージ・メタデータを用いて、前記ターゲット・コンピュータにおける前記仮想マシンをブートするステップであって、ブート時に必要に応じて前記ソース・コンピュータからの前記イメージ・テンプレートにアクセスすることによってブートするステップと、
    前記ターゲット・コンピュータにおける仮想マシンが、前記ターゲット・コンピュータにおいて前記仮想マシンの実行を続行するのに必要とされる、前記ソース・コンピュータ上の前記イメージ・テンプレートのデータを、前記イメージ・テンプレートの必要とされるデータが前記ターゲット・コンピュータ上に格納されていない場合に読み出すのを可能にするステップと、
    前記イメージ・テンプレートの前記読み出されたデータが前記ターゲット・コンピュータ上に格納されていない場合に、前記イメージ・テンプレートの前記読み出されたデータを前記ソース・コンピュータから前記ターゲット・コンピュータにコピーするステップであって、同じデータの後の読み出しは、前記ターゲット・コンピュータにおいて前記コピーされたデータを読み出す、コピーするステップと、
    前記読み出されたデータが前記ターゲット・コンピュータ上に格納されていることを示すように、ビットマップ内のビットを設定するステップであって、該ビットマップは、前記イメージ・メタデータの一部を形成する、設定するステップと、
    を含む方法。
13. 前記イメージ・メタデータは、最初に、前記イメージ・テンプレートへの参照、及びビットを前記イメージ・テンプレートの対応するセクタにマッピングする前記ビットマップを含む、請求項１２に記載の方法。
14. 前記ビットマップ内の前記ビットをチェックすることにより、前記仮想マシンの実行に必要とされる前記データが前記ターゲット・コンピュータ上に格納されているかどうかを判断するステップをさらに含み、前記ビットマップ内の前記ビットに応じて、前記仮想マシンは、前記ソース・コンピュータ又は前記ターゲット・コンピュータからデータを読み出す、請求項１２に記載の方法。
15. リソースのアイドル時間を利用して、前記仮想マシンと関連した前記イメージ・テンプレートのデータを、前記ソース・コンピュータから前記ターゲット・コンピュータにプリフェッチするステップをさらに含む、請求項１２に記載の方法。
16. 前記ステップは、前記ソース・コンピュータから前記ターゲット・コンピュータへの前記仮想マシンのライブ・マイグレーションのために実施され、別個のストレージ・サーバは用いられない、請求項１２に記載の方法。
17. 選択された仮想マシンと関連したイメージ・メタデータを、それぞれ１つ又は複数の仮想マシンに対応する１つ又は複数のイメージ・テンプレートを格納するストレージ・サーバから、ホスト・コンピュータのローカル・ストレージにコピーするステップであって、前記ホスト・コンピュータのローカル・ストレージは、最初に、前記選択された仮想マシンのイメージ・テンプレートを含まず、前記イメージ・メタデータは、最初に、前記選択された仮想マシンに関連したイメージ・テンプレートへの参照のみを有するヘッダ部分を含む、コピーするステップと、
    前記コピーされたイメージ・メタデータを用いて、前記ホスト・コンピュータにおいて前記選択された仮想マシンをブートするステップであって、ブート時に必要に応じて前記ストレージ・サーバからの前記イメージ・テンプレートにアクセスすることによってブートするステップと、
    前記選択された仮想マシンが、前記ホスト・コンピュータにおいて前記選択された仮想マシンの実行を続行するのに必要とされるデータを、前記必要とされるデータが前記ホスト・コンピュータのローカル・ストレージ上に格納されていない場合に、前記ストレージ・サーバ上の前記イメージ・テンプレートから読み出すことを可能にするステップと、
    前記イメージ・テンプレートの前記読み出されたデータが前記ホスト・コンピュータのローカル・ストレージ上に格納されていない場合、前記イメージ・テンプレートの前記読み出されたデータを、前記ストレージ・サーバから前記ホスト・コンピュータのローカル・ストレージにコピーするステップであって、同じデータに対する後の読み出しは、前記ホスト・コンピュータのローカル・ストレージから行われる、コピーするステップと、
    前記読み出されたデータが前記ホスト・コンピュータのローカル・ストレージ上に格納されていることを示すように、ビットマップ内のビットを設定するステップであって、該ビットマップは、前記イメージ・メタデータの一部を形成する、設定するステップと、
    を含む、仮想マシンのオンデマンド型イメージ・ストリーミングのための方法を実施するための、マシンにより実行可能な命令のプログラムを格納するコンピュータ可読ストレージ媒体。
18. 前記イメージ・メタデータは、最初に、前記イメージ・テンプレートへの参照を含む、請求項１７に記載のコンピュータ可読ストレージ媒体。
19. 前記イメージ・メタデータは、ビットを前記イメージ・テンプレートの対応するセクタにマッピングする前記ビットマップをさらに含む、請求項１８に記載のコンピュータ可読ストレージ媒体。
20. 前記ビットマップ内の前記ビットをチェックすることにより、前記選択された仮想マシンの実行に必要とされる前記イメージ・テンプレートの前記データが前記ホスト・コンピュータのローカル・ストレージ上に格納されているかどうかを判断するステップをさらに含み、前記ビットマップ内の前記ビットに応じて、前記選択された仮想マシンは、前記ストレージ・サーバ上の前記イメージ・テンプレート又は前記ホスト・コンピュータのローカル・ストレージ上のコピーされたイメージ・テンプレートを読み出す、請求項１７に記載のコンピュータ可読ストレージ媒体。
21. リソースのアイドル時間を利用して、前記選択された仮想マシンと関連した前記イメージ・テンプレートのデータを、前記ストレージ・サーバから前記ホスト・コンピュータのローカル・ストレージにプリフェッチするステップをさらに含む、請求項１７に記載のコンピュータ可読ストレージ媒体。
22. 仮想マシンのオンデマンド型イメージ・ストリーミングのためのシステムであって、
    選択された仮想マシンと関連したイメージ・メタデータを、前記仮想マシンに対応するイメージ・テンプレートを格納するソース・コンピュータからコピーするように動作可能であり、最初に、前記仮想マシンの前記イメージ・テンプレートを含まず、前記イメージ・メタデータは、最初に、前記選択された仮想マシンに関連したイメージ・テンプレートへの参照のみを有するヘッダ部分を含む、ターゲット・コンピュータと、
    前記ターゲット・コンピュータにローカルに取り付けられたストレージ・デバイスと、を含み、
    前記ターゲット・コンピュータは、
    前記コピーされたイメージ・メタデータを用いて、ブート時に必要に応じて前記ソース・コンピュータからの前記イメージ・テンプレートにアクセスすることによって、前記ターゲット・コンピュータにおける前記仮想マシンをブートし、且つ、前記ターゲット・コンピュータにおける前記仮想マシンが、前記ターゲット・コンピュータにおいて前記仮想マシンの実行を続行するのに必要とされる、前記ソース・コンピュータ上の前記イメージ・テンプレートのデータを、前記イメージ・テンプレートの前記必要とされるデータが前記ターゲット・コンピュータ上に格納されていない場合に読み出すことを可能にし、
    前記イメージ・テンプレートの前記読み出されたデータが前記ターゲット・コンピュータ上に格納されていない場合に、前記イメージ・テンプレートの前記読み出されたデータを、前記ソース・コンピュータから、前記ターゲット・コンピュータにローカルに取り付けられた前記ストレージ・デバイスにコピーし、同じデータの後の読み出しは前記ターゲット・コンピュータにローカルに取り付けられた前記ストレージ・デバイスから行われ、
    前記読み出されたデータが前記ターゲット・コンピュータ上に格納されていることを示すように、前記イメージ・メタデータの一部を形成するビットマップ内のビットを設定する、
    ようにさらに動作可能である、システム。
23. 前記イメージ・メタデータは、最初に、前記イメージ・テンプレートへの参照を含む、請求項２２に記載のシステム。
24. 前記イメージ・メタデータは、ビットを前記イメージ・テンプレートの対応するセクタにマッピングする前記ビットマップをさらに含む、請求項２３に記載のシステム。
25. リソースのアイドル時間を利用して、前記仮想マシンと関連した前記イメージ・テンプレートのデータを、前記ソース・コンピュータから前記ターゲット・コンピュータにプリフェッチすることをさらに含む、請求項２２に記載のシステム。

Images