特許 5960103 空間最適化ブロックデバイスのためのシステムソフトウェアインタフェース

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】5960103

(24)【登録日】2016年7月1日

(45)【発行日】2016年8月2日

(54)【発明の名称】空間最適化ブロックデバイスのためのシステムソフトウェアインタフェース

(51)【国際特許分類】

   G06F 13/10 20060101AFI20160719BHJP

   G06F 9/46 20060101ALI20160719BHJP

   G06F 3/06 20060101ALI20160719BHJP

【ＦＩ】

   G06F13/10 330C

   G06F9/46 350

   G06F3/06 301Z

【請求項の数】4

【全頁数】21

(21)【出願番号】特願2013-177455(P2013-177455)

(22)【出願日】2013年8月29日

(62)【分割の表示】特願2011-186106(P2011-186106)の分割

【原出願日】2011年8月29日

(65)【公開番号】特開2014-29700(P2014-29700A)

(43)【公開日】2014年2月13日

【審査請求日】2013年8月29日

(31)【優先権主張番号】61/378,076

(32)【優先日】2010年8月30日

(33)【優先権主張国】US

(31)【優先権主張番号】13/181,163

(32)【優先日】2011年7月12日

(33)【優先権主張国】US

(73)【特許権者】

【識別番号】510108504

【氏名又は名称】ヴイエムウェア インク

【氏名又は名称原語表記】ＶＭｗａｒｅ， Ｉｎｃ．

(74)【代理人】

【識別番号】100105957

【弁理士】

【氏名又は名称】恩田 誠

(74)【代理人】

【識別番号】100068755

【弁理士】

【氏名又は名称】恩田 博宣

(74)【代理人】

【識別番号】100142907

【弁理士】

【氏名又は名称】本田 淳

(74)【代理人】

【識別番号】100085372

【弁理士】

【氏名又は名称】須田 正義

(72)【発明者】

【氏名】ヴァガニ，サトィヤム ビー．

(72)【発明者】

【氏名】アスワタナラヤナ，テジャスヴィ

【審査官】 坂東 博司

(56)【参考文献】

【文献】 特開昭６１−１１２２５５（ＪＰ，Ａ）

【文献】 特開２００７−１９３５７３（ＪＰ，Ａ）

【文献】 特開２００６−２９３５４３（ＪＰ，Ａ）

【文献】 特開２００４−３０２７０１（ＪＰ，Ａ）

【文献】 特開２００２−０９９５０２（ＪＰ，Ａ）

【文献】 特表２０１２−５２３５９４（ＪＰ，Ａ）

【文献】 特表２０１２−５２２２９２（ＪＰ，Ａ）

【文献】 特表２０１０−５３７２９７（ＪＰ，Ａ）

【文献】 国際公開第０９／０６６６１１（ＷＯ，Ａ１）

【文献】 国際公開第１１／０２４２３９（ＷＯ，Ａ１）

【文献】 国際公開第１０／１１１６９４（ＷＯ，Ａ２）

【文献】 欧州特許出願公開第００１６９００５（ＥＰ，Ａ２）

【文献】 特開２００９−１３４６０１（ＪＰ，Ａ）

【文献】 特開２０１０−１４０２７３（ＪＰ，Ａ）

【文献】 特開２００８−１０２６６７（ＪＰ，Ａ）

【文献】 特表２０１１−５２３７５１（ＪＰ，Ａ）

【文献】 国際公開第２００９／１５０１２２（ＷＯ，Ａ１）

【文献】 特開２００９−６４３０３（ＪＰ，Ａ）

【文献】 国際公開第２００９／１３３０１５（ＷＯ，Ａ１）

【文献】 国際公開第２００９／０４７９８６（ＷＯ，Ａ１）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｇ０６Ｆ １３／１０

Ｇ０６Ｆ ３／０６

Ｇ０６Ｆ ９／４６

(57)【特許請求の範囲】

【請求項1】

コンピュータシステムであって、
ハードウェアデバイスとしてのストレージアレイであって、該ストレージアレイにおける物理ストレージ空間の論理表現としてのＬＵＮをサポートする前記ストレージアレイと、
前記ストレージアレイとネットワークを介して接続されたホストコンピュータであって、該ホストコンピュータは、仮想マシンの実行をサポートするハイパーバイザを提供する、前記ホストコンピュータと
を備え、
前記ハイパーバイザは、エミュレートされた論理ブロックデバイスを含む前記仮想マシンに対するハードウェア資源をエミュレートするように構成され、前記エミュレートされた論理ブロックデバイスは、前記仮想マシンによりアクセス可能な仮想ストレージ空間の論理表現であり、前記ハイパーバイザは、前記ＬＵＮを用いて前記仮想ストレージ空間を提供し、
前記ハイパーバイザは、前記ＬＵＮからストレージブロックの割当てを解除するために前記ストレージアレイに対してコマンドを発行するように構成され、
前記仮想マシンは、前記エミュレートされた論理ブロックデバイスからストレージブロックの割当てを解除するために前記エミュレートされた論理ブロックデバイスに対してコマンドを発行するように構成されている、コンピュータシステム。

【請求項2】

前記ハイパーバイザは、整合値及び粒度値に基づいて前記ストレージアレイに対してコマンドを発行するように構成され、該コマンドに従って前記ストレージアレイが前記ストレージアレイ内のＬＵＮの物理ストレージ空間を再利用する空間再利用動作を実行し、
前記仮想マシンは、整合値及び粒度値に基づいて前記エミュレートされた論理ブロックデバイスに対してコマンドを発行するように構成され、該コマンドに従って前記エミュレートされた論理ブロックデバイスが前記エミュレートされた論理ブロックデバイス内の仮想ストレージ空間を再利用する空間再利用動作を実行する、請求項１に記載のコンピュータシステム。

【請求項3】

前記ハイパーバイザは、前記ＬＵＮのストレージブロックが、割当てを解除されるべきであるが、前記ＬＵＮの前記整合値及び粒度値と互換性がないと識別されている第１のデータ構造を管理するように構成され、
前記仮想マシンは、前記エミュレートされた論理ブロックデバイスのストレージブロックが、割当てを解除されるべきであるが、前記エミュレートされた論理ブロックデバイスの前記整合値及び粒度値と互換性がないと識別されている第２のデータ構造を管理するように構成される、請求項２に記載のコンピュータシステム。

【請求項4】

前記ハイパーバイザは、前記ストレージブロックに対する書込みを検出する場合、ストレージブロックを前記第１のデータ構造において識別されているものとして除外するように構成され、
前記仮想マシンは、前記ストレージブロックに対する書込みを検出する場合、ストレージブロックを前記第２のデータ構造において識別されているものとして除外するように構成される、請求項３に記載のコンピュータシステム。

【発明の詳細な説明】

【関連出願の相互参照】

【0001】

[0001]本出願は、２０１０年８月３０日出願の米国特許仮出願第６１／３７８，０７６号の利益を主張し、その内容全体を本願明細書に引用したものとする。

【技術分野】

【0002】

本発明は、空間最適化ブロックデバイスのためのシステムソフトウェアインタフェースに関する。

【背景技術】

【0003】

[0002]コンピュータ仮想化は、物理的コンピュータプラットホームを、ハードウェアコンピュータプラットホーム即ち「ホスト」上で動作する仮想化ソフトウェアの制御の下で実行される仮想マシンにカプセル化することを含む技法である。仮想マシンは、仮想システムハードウェア及びゲストオペレーティングシステムソフトウェアの両方を有する。仮想システムハードウェアは典型的に、ゲストオペレーティングシステムに対する典型的ストレージドライブとして見える少なくとも１台の「仮想ディスク」、単一ファイル又は一組のファイルを含む。仮想ディスクは、ホストプラットホーム上に又はリモートストレージデバイス上に格納されてもよい。典型的に、ゲストオペレーティングシステム、アプリケーションプログラム及びアプリケーションデータを格納するために、物理ストレージドライブが用いられるのと同じ方法で、仮想マシン（ＶＭ）は仮想ディスクを用いる。
[0003]仮想化ソフトウェアは、また、ハイパーバイザと称され、仮想ディスクに対するゲストオペレーティングシステムのアクセスを管理し、かつ、仮想ディスクを、ホストプラットホーム上に、又はストレージエリアネットワーク（ＳＡＮ）若しくはネットワーク接続ストレージ（ＮＡＳ）のような、リモートストレージデバイス内に存在する下位物理ストレージ資源にマップする。複数仮想マシンが単一ホスト上にインスタンス化可能であるので、物理ストレージ空間を組織のデータセンター内のすべてのインスタンス化された仮想マシンに対応する仮想ディスクに割り当てることは、データセンターの物理ストレージ空間容量に圧迫を加える可能性がある。例えば、仮想マシンに仮想ディスクを供給するときには、仮想ディスクが最初に作り出された時点で仮想化ソフトウェアが全ての物理ディスク空間を仮想ディスクに割り当て、時にはゼロだけを含有する多数の空のデータブロック（「０ブロック」）を作り出す場合がある。しかしながら、仮想ディスクに割り当てられた物理ストレージ空間が仮想マシンによって折よく用いられない（又は決して用いられない）かもしれないので、この種の割当てはストレージ非効率性に結びつくかもしれない。「シン・プロビジョニング（ｔｈｉｎ ｐｒｏｖｉｓｉｏｎｉｎｇ）」として知られる、１つの解決策において、仮想化ソフトウェアは、この種の物理ストレージ空間が仮想マシンによって実際に必要な時だけ、仮想ディスクに物理ストレージ空間を動的に割り当て、必ずしも仮想ディスクが最初に作り出された時に割り当てない。

【0004】

[0004]これと同様の方法で、シン・プロビジョニングは下位ストレージハードウェア、例えば、物理ストレージ媒体として回転ディスク又は固体ディスクのアレイを含んでもよい、ストレージアレイのストレージ空間最適化法として実現されてもよい。そのような場合、物理ストレージ媒体を管理し、かつ、論理装置番号（ＬＵＮ）と称される、論理データストレージユニットとしてそれらをホストに公開するストレージシステムコントローラが、ＬＵＮを薄く供給する。即ち、ストレージシステムコントローラがこの種の物理ストレージ空間がＬＵＮによって実際に必要な時だけ、ＬＵＮに物理ストレージ空間を動的に割り当て、必ずしもＬＵＮが最初に作り出された時に割り当てるのではない。その結果、ＬＵＮが最初に作り出された時には、ＬＵＮの各々の論理サイズは典型的にその物理サイズより非常に大きい。

【先行技術文献】

【特許文献】

【0005】

【特許文献1】米国特許第７，８４９，０９８号、名称「ファイルシステムに対する複数並列アクセス」、２００４年２月４日出願、２０１０年１２月７日発行

【特許文献2】米国特許出願第１２／０５０８０５号、名称「ファイルデータブロックの効率的なゼロ合わせ」（弁護士内容摘要録番号Ａ１２３）、２００８年３月１８日出願

【発明の概要】

【発明が解決しようとする課題】

【0006】

[0005]しかしながら、薄く供給された仮想ディスク及び薄く供給されたＬＵＮの使用によってさえ、ストレージ非効率性が「淀んだ（ｓｔａｌｅ）」データの累積、即ち、以前に用いられて現在使っていないが、割り当てられたまま残るディスクブロック、によって生じるおそれがある。例えば、ゲストオペレーティングシステムによって仮想ディスク内の、ドキュメントの編集中にバックアップとして作り出された一時ファイルのようなファイルの削除は、一般に、一時ファイルに対応する実際のデータブロックの解放に結びつかない。ゲストオペレーティングシステムが（例えば、ゲストファイルシステムのビットマップ内のビットをクリアすることによって）それ自体のゲストファイルシステム内の削除された一時ファイルに関する解放されたデータブロックをそれ自体で追跡することができるとはいえ、ゲストオペレーティングシステムは、それが一時データファイルを削除したディスクが実際にはそれ自体でファイルである「仮想ディスク」であることを知らない。従って、仮想ディスクの一部分（即ち解放されたデータブロックのゲストファイルシステムのビットマップを格納する仮想ディスクの部分）がゲストオペレーティングシステムによって一時ファイルの削除の際に変更されてもよいとはいえ、削除された一時ファイルの実際のデータブロックに対応する仮想ディスクの部分は、仮想化ソフトウェアによって仮想ディスクからＬＵＮへ実際には解放されない。仮想ディスクのこの種の「淀んだ」部分は対応するゲストオペレーティングシステムによって利用されず、かつまた、代替用途（例えば、異なる仮想マシン、その他用の異なる仮想ディスクの一部として再割当される）のための仮想化ソフトウェアに利用可能でないので、この振る舞いはストレージ非効率性に結びつく可能性がある。

【0007】

[0006]（１台以上の仮想ディスク及び他のＶＭ構成ファイルを含む）仮想マシンディスクファイルのソースＬＵＮから宛先ＬＵＮへのライブの移行を含むＳｔｏｒａｇｅ ｖＭｏｔｉｏｎ（商標）として知られるプロセスは、薄く供給されたＬＵＮ内に累積された「淀んだ」データの別の例を提供する。Ｓｔｏｒａｇｅ ｖＭｏｔｉｏｎ（商標）中に、仮想マシンディスクファイルに対応する実際のデータブロックが、ソースＬＵＮから宛先ＬＵＮにコピーされ、及び、コピーの終わりで、このＶＭをサポートするＬＵＮがソースＬＵＮから宛先ＬＵＮに原子的に切替えられる。原子的切替えの後、ソースＬＵＮ内の仮想マシンディスクファイルに対応する実際のデータブロックは、もはや必要でない。仮想化ソフトウェアがそれ自体でこれらのデータブロックを追跡し、かつ、例えばソースＬＵＮから仮想マシンディスクファイルを実際に削除することによって、「空き（ｆｒｅｅ）」としてそれらをマークすることができるとはいえ、仮想マシンディスクファイルのこれらの空きデータブロックに対応するソースＬＵＮの部分は、ＬＵＮからストレージアレイへ実際には解放されない。仮想化ソフトウェアが（例えば、新規な仮想マシンディスクファイルを別の仮想マシン、その他に割り当てることによって）代替用途のためのソースＬＵＮ内に、解放されたデータブロックをすばやく再割当するならば、これは受け入れられるかもしれない。しかしながら、解放されたデータブロックが未割り当てのままである場合において、ＬＵＮのこの種の「淀んだ」部分は（例えば、この種の淀んだ部分が、ストレージアレイマネージャによって、ストレージ圧力を経験しているかもしれない、異なる薄く供給されたＬＵＮに再割当される可能性があるので）シン・プロビジョニングから得られるストレージ空間効率を小さくする。

【課題を解決するための手段】

【0008】

[0007]本発明の１つ以上の実施態様が、支持されるべきこの種の技術から利益が得られることを可能にするために、シン・プロビジョニングのような、ストレージ空間最適化法を使用するストレージデバイスに対する、システムソフトウェアインタフェースを提供する。この種のインタフェースは、ハイパーバイザが、ＬＵＮが薄く供給されたかどうかのような、ＬＵＮの機能を発見することを可能にするために仮想化コンピュータシステムのハイパーバイザ内に、及び、更に、ＶＭが、仮想ディスクが薄く供給されたかどうかのような、仮想ディスクの機能を発見することを可能にするために、仮想化コンピュータシステムのＶＭ内に設けられてもよい。これらの機能の発見は、論理ブロックデバイス、即ちＬＵＮ又は仮想ディスクに以前に割り当てられたブロックの割当てを解除する動作のような特定の動作を実行するように、ハイパーバイザ又はＶＭが下位ストレージデバイスに指示することを可能にし、下位ストレージデバイスがその中で実現されるストレージ空間最適化法から利益を得続けることができるようにする。

【0009】

[0008] 本発明の一実施態様に従う一コンピュータシステムは、論理データストレージユニットをサポートするストレージアレイと、プロセッサと、メモリとを含むハードウェア資源、及び仮想マシンの実行をサポートしてかつエミュレートされた論理ブロックデバイスを含む仮想マシンのためのハードウェア資源をエミュレートするハイパーバイザを含む。ハイパーバイザは、論理データストレージユニットからストレージブロックの割当てを解除するために論理データストレージユニットに第１コマンドを発行するための第１コンポーネントを含み、及び仮想マシンは、エミュレートされた論理ブロックデバイスからストレージブロックの割当てを解除するためにエミュレートされた論理ブロックデバイスに第２コマンドを発行するための第２コンポーネントを含む。

【図面の簡単な説明】

【0010】

【図1】[0012]１つ以上の実施態様に従う仮想化コンピュータアーキテクチャを示すブロック図である。

【図2A】[0013]１つ以上の実施態様に従う、図１の仮想化コンピュータアーキテクチャにおけるサーバを代表するブロック図を記載する。

【図2B】[0014]１つ以上の実施態様に従う、図１の仮想化コンピュータアーキテクチャにおけるストレージアレイを代表するブロック図を記載する。

【図3】[0015]図２Ａのサーバ内で動作するハイパーバイザの論理ブロックデバイスとして動作するＬＵＮの構成特性を集める一方法を例示する流れ図である。

【図4】[0016]図２Ａのサーバ内で動作する仮想マシンのゲストオペレーティングシステムの論理ブロックデバイスとして動作する仮想ディスクの構成特性を集める一方法を例示する流れ図である。

【図5】[0017]仮想ディスクからのストレージ空間再利用の一方法を例示する流れ図である。

【図6】[0018]ＶＭからのコマンドに応答してハイパーバイザによって開始されるＬＵＮからのストレージ空間再利用の一方法を例示する流れ図である。

【図7】[0019]管理サーバからのコマンドに応答してハイパーバイザによって開始されるＬＵＮからのストレージ空間再利用の一方法を例示する流れ図である。

【図8】[0020]ＶＭをライブで移行するプロセスを開始する前に互換性チェックを実行する一方法を例示する流れ図である。

【図9】[0021]ＬＵＮが用いられた容量内の特定の閾値に到達したと仮想化コンピュータシステムの管理サーバに通知する一方法を例示する流れ図である。

【図10】[0022]図９で通知を受け取る際に管理サーバによって善後策を実行する一方法を例示する流れ図である。

【図11】[0023]書込み動作を実行する間にＬＵＮの、空間が尽きる時に、生じるエラーを検出してかつ処理する一方法を例示する流れ図である。

【図12】[0024]ＬＵＮからストレージ空間を遡及して再利用する一方法を例示する流れ図である。

【発明を実施するための形態】

【0011】

[0025]図１は、１つ以上の実施態様に従う仮想化コンピュータアーキテクチャ１００を示すブロック図である。仮想化コンピュータアーキテクチャ１００は、１台以上のストレージアレイ１３０を含む共有ストレージシステムにネットワーク１２０経由で接続される複数のサーバ１１０を含む。サーバ１１０はいくつあってもよく、それぞれが、任意の数のストレージアレイ１３０上に格納されるデータにアクセスする１台以上の仮想マシンを有する汎用コンピュータシステムを備えていてもよい。ネットワーク１２０は、広域ネットワーク、ローカルエリアネットワーク又は、Ｆｉｂｒｅ Ｃｈａｎｎｅｌ、ｉＳＣＳＩ、その他のような、ストレージアレイ１３０に特に適しているプロトコルをホストするネットワークであってもよく、かつ１個以上のスイッチを備えていてもよい。ストレージアレイ１３０は、ネットワーク接続ストレージ（ＮＡＳ）ファイラ又はストレージエリアネットワーク（ＳＡＮ）を介したブロックベースデバイスのような任意のタイプであってもよい。ストレージアレイ１３０が典型的に複数のディスクから構成されるとはいえ、固体不揮発性ストレージデバイスの価格が下落するにつれて、それらがますます回転ディスクストレージ媒体に取って代わると認識されなければならない。従って、用語「ディスク」の使用は、本願明細書において、回転ディスクストレージ媒体だけに限定されると解釈されるべきでなく、また、固体ディスク又は「ＳＳＤ」として知られるようになっているものも含まれる。

【0012】

[0026]仮想化コンピュータアーキテクチャ１００は、管理サーバ１４８によって管理され、それは、中央サーバ内に又は代わりとしてサーバ１１０の１つの内に存在して実行するコンピュータプログラムである。管理サーバ１４８は、サーバ１１０の各々と通信し、かつ、サーバ１１０間の負荷平衡及びストレージアレイ１３０間の作業負荷平衡のような仮想化コンピュータアーキテクチャ１００の管理業務を実施する。

【0013】

[0027]図２Ａ及び２Ｂは、１つ以上の実施態様による、サーバ１１０のいずれかの代表であるサーバ２００及び、ストレージアレイ１３０のいずれかの代表であるストレージアレイ２５０のブロック図をそれぞれ記載する。サーバ２００は、従来の、典型的にサーバ−クラスの、ハードウェアプラットホーム２０２上で構成されていてもよい。図２Ａに示すように、サーバ２００はストレージアレイ２５０にサーバ２００を接続することを可能にするＨＢＡ２０４及びＮＩＣ２０１を含む。図２Ａに更に示すように、ハイパーバイザ２０８がハードウェアプラットホーム２０２上にインストールされ、及びそれが、複数の仮想マシン（ＶＭ）２１２_１−２１２_Ｎがその中で並行してインスタンス化されて実行されることができる仮想マシン実行空間２１０をサポートする。この種の各仮想マシン２１２_１−２１２_Ｎは、アプリケーション２１８を実行可能なゲストオペレーティングシステム（ＯＳ）２１６のインストールをサポートする仮想ハードウェアプラットホーム２１４を実現する。ゲストＯＳ ２１６の例はＭｉｃｒｏｓｏｆｔ Ｗｉｎｄｏｗｓ（登録商標）、Ｌｉｎｕｘ（登録商標）等のような、周知のコモディティーオペレーティングシステムのいずれをも含む。それぞれの例において、ゲストＯＳ ２１６はネイティブのファイルシステムレイヤ（図２Ａ内に図示せず）、例えばＮＴＦＳ又はｅｘｔ３ＦＳタイプファイルシステムレイヤのいずれかを含む。これらのファイルシステムレイヤは、ゲストオペレーティングシステム２１６の観点から、データストレージＨＢＡにアクセスするために仮想ハードウェアプラットホーム２１４とインタフェースするが、それは、実際はディスクストレージサポートの外観を提供する仮想ハードウェアプラットホーム２１４によって実現される仮想ＨＢＡ２２０であり（実際は、複数の仮想ディスク即ち仮想ディスク２２２_Ａ−２２２_Ｘ）、システムハードウェアの仮想化に透過的なゲストＯＳ２１６の実行を可能にする。特定の実施態様において、仮想ディスク２２２_Ａ−２２２_Ｘは薄く供給されることができ、かつ、ゲストＯＳ２１６の観点から、仮想マシンに接続するためのＳＣＳＩ規格、又はＩＤＥ、ＡＴＡ及びＡＴＡＰＩを含む、当業者に公知のその他の適切なハードウェア接続インタフェース規格をサポートするように見える。

【0014】

[0028]ゲストオペレーティングシステム２１６の観点から、ファイルシステム関連のデータ転送及び制御動作を実現するためにこの種のゲストオペレーティングシステム２１６によって開始されるファイルシステム呼出しは、最終的な実行のために仮想ディスク２２２_Ａ−２２２_Ｘに経路を定められるように見えるとはいえ、実際は、この種の呼出しはハイパーバイザ２０８による動作を調整するために必要な仮想システムサポートを実現する補助仮想マシンモニタ（ＶＭＭ）レイヤ２２４_１−２２４_Ｎに仮想ＨＢＡ２２０を通して処理されて通される。特に、ＨＢＡエミュレータ２２６は、ストレージアレイ２５０に接続する本当のＨＢＡ２０４又はＮＩＣ２０１に、その種々のレイヤを通して最終的にこの種の動作を通すハイパーバイザ２０８によって、データ転送及び制御動作が正しく処理されることを機能的に可能にする。ＳＣＳＩサポートされた仮想デバイス実現を想定して、（当業者が他のハードウェアインタフェース規格を用いるオプションを認識するとはいえ）、ハイパーバイザ２０８のＳＣＳＩ仮想化レイヤ２２８が、ＶＭＭレイヤ２２４_１−２２４_Ｎからデータ転送及び制御動作を（例えば、ＳＣＳＩ準拠仮想ディスクを意図されるＳＣＳＩコマンドの形で）受け取り、かつＳＣＳＩ準拠仮想ディスクを代表するＶＭＦＳ２３０の管理下で、ストレージアレイ２５０内のＬＵＮの１つの内に格納されているファイルにアクセスするために、仮想マシンファイルシステム（ＶＭＦＳ）２３０によって理解されるファイルシステム動作に、それらを変換する。一実施態様において、代替仮想ディスクファイルフォーマットが他の実施態様で用いられてもよいことが認識されるべきであるとはいえ、仮想ディスクを代表するファイルが仮想ディスクのためのＶＭｗａｒｅ社によって広められるＶＭｗａｒｅ仮想ディスク（ＶＭＤＫ）ファイルフォーマットに適合する。

【0015】

[0029]次に、ＳＣＳＩ仮想化レイヤ２２８は、ＶＭＦＳ２３０に、これらのファイルシステム動作を発行する。ＶＭＦＳ２３０は、一般に、ストレージアレイ２５０によって公開されるＬＵＮ上に格納される（例えば、仮想ディスクを代表する．ｖｍｄｋファイルのような）ファイルの作成、使用及び削除を管理する。一実施態様においてＶＭＦＳ２３０として機能することができるクラスタ化されたファイルシステムの一例が、特許文献１内に記載されており、その内容全体を、本願明細書に引用したものとする。ＶＭＦＳ２３０は、ＳＣＳＩ仮想化レイヤ２２８から受け取られるファイルシステム動作をボリューム（例えばＬＵＮ）ブロック動作に変換し、かつボリュームブロック動作を論理ボリュームマネージャ２３２に与える。論理ボリュームマネージャ（ＬＶＭ）２３２は、典型的にドライバとファイルシステムレイヤとの間の中間層として実現され、かつボリューム指向仮想化並びにＨＢＡ２０４及びＮＩＣ２０１を通してアクセス可能なＬＵＮの管理をサポートする。ＬＶＭ２３２は、ＬＵＮブロック動作に基づいてデバイスアクセスレイヤ２３４に生のＳＣＳＩ動作を発行する。データアクセスレイヤ２４０は、ストレージアレイ２５０を発見しかつコマンド待ち行列及びスケジューリングポリシーを生のＳＣＳＩ動作に適用するデバイスアクセスレイヤ２３４と、ストレージアレイ２５０とインタフェースするＨＢＡ２０４及びＮＩＣ２０１の入出力インタフェースを理解し、かつデバイスアクセスレイヤ２３４から、ストレージアレイ２５０に送り届けられるべきＨＢＡ２０４又はＮＩＣ２０１に生のＳＣＳＩ動作を送るデバイスドライバ２３６と、を含む。

【0016】

[0030]図２Ａ内の仮想化コンポーネントを記述するために用いられる種々の用語、レイヤ及びカテゴリ化は、本発明のそれらの機能又は趣旨若しくは有効範囲から逸脱することなく、異なって参照されてもよいと認識されるべきである。例えば、各インスタンス化されたＶＭに対して別々のＶＭＭが存在するので、ＶＭＭ２２４はＶＭ２１２とハイパーバイザ２０８との間の別々の仮想化コンポーネントと考えてもよい（この種の概念において、それはそれ自体で仮想化「カーネル」コンポーネントと考えてもよい）。代わりに、この種のＶＭＭが仮想マシンに対するハードウェアエミュレーションコンポーネントを含むので、各ＶＭＭはその対応する仮想マシンのコンポーネントと考えてもよい。この種の代替概念において、例えば、仮想ホストバスアダプタ２２０が図２Ａから除去されるように（即ち、その機能がホストバスアダプタエミュレータ２２６によって達成されるので）、仮想ハードウェアプラットホーム２１４として記述される概念上のレイヤがＶＭＭ２２４に結合されていてもよい。

【0017】

[0031]図２Ｂで図示するように、ストレージアレイ２５０のストレージアレイマネージャ２５１は、そのＬＵＮの１つに対応する生のＳＣＳＩ動作を受け取り、かつその際に動作されるストレージアレイ２５０のスピンドル内でそれらを適切なエクステントに分割する。１台以上のプログラムされたストレージプロセッサを代表するストレージアレイマネージャ２５１は、一般にストレージアレイ２５０の（外部に対する）通信エージェントとして機能し、かつ、ストレージアレイ２５０内に存在する、図２Ｂ内ではスピンドル２５２_Ａ−２５２_Ｎと称される、物理的な、典型的にはディスクドライブベースのストレージユニットの仮想化を実現する。論理的観点から、これらのスピンドルの各々は、固定したサイズのエクステント２５４のシーケンシャルなアレイと考えることができる。本願明細書において先にＬＵＮ２５６_Ａ−２５６_Ｍ（「論理装置番号」）と称された一組の仮想ＳＣＳＩブロックデバイスに分割されてもよい連続した論理ストレージ空間としてディスクドライブによって与えられる集積された物理ストレージ空間を見る能力をサーバ２００に公開することによって、ストレージアレイマネージャ２５１は、ディスクドライブの実際のスピンドル及びエクステントのアドレスに読出し及び書込み動作を向ける複雑さを取り去る。ＬＵＮ２５６_Ａ−２５６_Ｍのこの種の連続した論理ストレージ空間へのスピンドル２５２_Ａ−２５２_Ｎの仮想化は、論理ボリュームのアドレス空間によって代表される集積された物理ストレージ空間のより効率的な利用を提供することができる。ストレージアレイマネージャ２５１は、エクステントの順序リストへのＬＵＮ２５６_Ａ−２５６_Ｍの各々に対するマッピング（以下に、また、エクステント−マッピングと称する）を含むメタデータ２５５を維持し、この種の各エクステントはスピンドル−エクステント対＜ｓｐｉｎｄｌｅ＃、ｅｘｔｅｎｔ＃＞として識別可能であり、従って、種々のスピンドル２５２_Ａ−２５２_Ｎのいずれかの内に置かれていてもよい。

【0018】

[0032]特定の実施態様において、ＬＵＮを割り当てる時、ストレージアレイ２５０は「シン・プロビジョニング（ｔｈｉｎ ｐｒｏｖｉｓｉｏｎｉｎｇ）」と呼ばれるストレージ空間最適化法を使用することができる。ＬＵＮが「薄く（ｔｈｉｎｌｙ）」供給される時、ストレージアレイ２５０によって報告されるＬＵＮの論理サイズは、そのＬＵＮを最初に支持する物理空間の合計より大きくてもよい。ＬＵＮの全てのコンシューマは、ＬＵＮの論理サイズを見るだけである。書込み動作が薄く供給されたＬＵＮの以前に未割り当てのブロックに発行されるにつれて、消費された実際の物理空間の合計は増大し、ある時点で、ＬＵＮは物理空間が尽きるかもしれない。同様に、図２Ａ内に記載されるような仮想化環境において、ストレージアレイ２５０のＬＵＮ上に格納される仮想ディスク２２２は、例えばハイパーバイザ２０８によって（又は特定の実施態様では管理サーバ１４８によって）、「薄く供給される」ように構成されていてもよい。ゲストＯＳ２１６の観点から、この種の薄く供給された仮想ディスク２２２は固定論理サイズを有するとして認められるが、実際は、ＶＭＦＳ２３０がＬＵＮストレージ空間を仮想ディスク２２２（例えば、．ｖｍｄｋファイル）に動的に割り当て、そうすると、任意の所定の時間で、仮想ディスク２２２を支持するＬＵＮ内の実際のストレージ空間は論理サイズ未満かもしれない。

【0019】

[0033]図３は、ハイパーバイザ２０８の論理ブロックデバイスとして動作する、ＬＵＮの構成特性を集めるためにハイパーバイザ２０８によって実施される一方法を例示する流れ図である。ＬＵＮのこれらの構成特性は、ＬＵＮに「ＵＰＭＡＰ」コマンドを発行することによって、ＬＵＮから（ストレージアレイ２５０のようなＬＵＮをサポートするストレージシステムへ戻る）ストレージ空間を「再利用する（ｒｅｃｌａｉｍ）」ために以下に記載する技法で用いられてもよい。図３で図示するように、ステップ３０２で、ハイパーバイザ２０８はＬＵＮにＳＣＳＩ読取り容量コマンド（例えば１６ビット版のコマンド）を発行する。ステップ３０４で受け取られるＬＵＮの応答は、ビットの設定によって示されるように、ＬＵＮがシン・プロビジョニングをサポートするか否かの表示を含む（それは、一実施態様において、シン・プロビジョニング対応（ｔｈｉｎ ｐｒｏｖｉｓｉｏｎｉｎｇ ｅｎａｂｌｉｎｇ）（ＴＰＥ）ビットとして既知である）。ステップ３０６で、ハイパーバイザ２０８が、ＬＵＮがシン・プロビジョニングをサポートする（例えば、ＴＰＥビットが設定される）と判定するならば、この方法はステップ３０８に続く。ステップ３０６で、ハイパーバイザ２０８が、ＬＵＮがシン・プロビジョニングをサポートしない（例えば、ＴＰＥビットが設定されない）と判定するならば、この方法は終了する。

【0020】

[0034]ステップ３０８で、ハイパーバイザ２０８はシン・プロビジョニングに対するＬＵＮのサポートを記録し、かつＬＵＮに（例えば、一実施態様において問合せのタイプとして０ｘＢ０「Ｖｉｔａｌ Ｐｒｏｄｕｃｔ Ｄａｔａ」コードを利用して）ＳＣＳＩ Ｉｎｑｕｉｒｙコマンドを発行する。ステップ３１０で受け取られてかつステップ３１２で記録されたＬＵＮの応答は、ＬＵＮが「ＵＮＭＡＰ」コマンド（実施態様によってはＵＮＭＡＰ「ビット（ｂｉｔ）」によって示される）をサポートするか否かに関する指示を含み、及びサポートがあるならば、応答はさらにマップ解除コマンドと共に用いられるべきいくつかのパラメータのレポートを含む。その最も単純な形において、一実施態様において、ＵＮＭＡＰコマンドはＬＵＮによってマップ解除されるべき、かつＬＵＮをサポートする下位ストレージシステムに解放されるべきブロックのリストを特定する。そのような実施態様において報告されるパラメータは、Ｄ_Ｇ（ＬＵＮがデータを管理する粒度）、Ｄ_{ｏｆｆｓｅｔ}（ＬＵＮがマップ解除コマンドを受け取るのを好むオフセットで表現される整合パラメータ）、及びＮ_{ＭＡＸ＿Ｄ}（単一のＵＮＭＡＰコマンドで特定可能な＜ｏｆｆｓｅｔ，ｌｅｎｇｔｈ＞対の最大数）、を含む。例えば、Ｄ_{ｏｆｆｓｅｔ}が４ＫＢの値を有するならば、その時、ＬＵＮは、４ＫＢのアドレスの倍数（例えば、０ＫＢ、４ＫＢ、８ＫＢ、１２ＫＢ、その他のアドレス）で始まる、ＵＮＭＡＰコマンドのような、ＳＣＳＩ動作を受け入れる。Ｄ_Ｇがその時５１２ＫＢの値を有するならば、ＬＵＮは５１２ＫＢの倍数であるブロックサイズを特定するＳＣＳＩ動作を受け入れる。この種の例において、ＬＵＮはＬＵＮの始まりから１２ＫＢのオフセットに対応するアドレスから始まる１０２４ＫＢの連続ブロックをマップ解除するためにＵＮＭＡＰコマンドを受け入れるが、ＬＵＮの始まりから１ＫＢ、２ＫＢ、３ＫＢ、その他のオフセットに対応するアドレスから始まる任意の連続ブロック、又は連続したブロックサイズが５１２ＫＢ未満であるところをマップ解除するためにＵＮＭＡＰコマンドを受け入れない。値Ｄ_Ｇ、Ｄ_{ｏｆｆｓｅｔ}及びＮ_{ＭＡＸ＿Ｄ}が、ＬＵＮをサポートする下位ストレージシステムのストレージベンダーによって設定されるか又は規定されると認識されるべきである。

【0021】

[0035]図４は、仮想マシン２１２のゲストＯＳ２１６の論理ブロックデバイスとして動作する、仮想ディスク２２２の構成特性を集めるためにゲストＯＳ２１６によって実施される一方法を例示する流れ図である。認識されるはずであるように、ハイパーバイザが、図３に記載のその構成特性に対してストレージアレイ内のＬＵＮを問い合わせるよりむしろ、図４において、仮想マシン２１２内のプロセス（例えばゲストＯＳ２１６、又はゲストＯＳ２１６その他内へロードされたＳＣＳＩデバイスドライバ内の設定ルーチン内の、空きブロックを追跡するために開発されたユーザレベルプロセス）が、その構成特性に対して仮想ディスク２２２（例えばそのデータがＬＵＮ内にファイルとして実際に格納されたエミュレートされたＳＣＳＩデバイス）を問い合わせるという点を除けば、図４は図３と同じステップを繰り返す。仮想ディスクがハイパーバイザ２０８によってエミュレートされているので、ハイパーバイザ２０８は仮想マシン２１２内の問合せプロセスに応答して（仮想ディスクの代理として）仮想ディスクの構成特性を提供する。仮想ディスクのこれらの構成特性は、仮想ディスクに「ＵＮＭＡＰ」コマンドを発行することによって仮想ディスクがファイルとして格納されるＬＵＮへ、仮想ディスクからストレージ空間を「再利用する」ために以下に記載する技法で用いられてもよい。図４で図示するように、ステップ４０２で、ゲストＯＳ２１６は仮想ディスクにＳＣＳＩ読取り容量コマンド（例えば１６ビット版のコマンド）を発行する。ステップ４０４で受け取られる仮想ディスクの応答は、ビットの設定（それは、一実施態様において、「シン・プロビジョニング対応（ＴＰＥ）ビットとして既知である）によって示されるように、仮想ディスクがシン・プロビジョニングをサポートするか否か、の指示を含む。ステップ４０６で、ゲストＯＳ２１６が、仮想ディスクがシン・プロビジョニングをサポートする（例えば、ＴＰＥビットが設定される）と判定するならば、この方法はステップ４０８に続く。ステップ４０６で、ゲストＯＳ ２１６が、仮想ディスクがシン・プロビジョニングをサポートしない（例えば、ＴＰＥビットは設定されない）と判定するならば、この方法は終了する。

【0022】

[0036]ステップ４０８で、ゲストＯＳ２１６はシン・プロビジョニングに対する仮想ディスクのサポートを記録し、かつ仮想ディスクに（例えば、一実施態様において問合せのタイプとして０ｘＢ０「Ｖｉｔａｌ Ｐｒｏｄｕｃｔ Ｄａｔａ」コードを利用して）ＳＣＳＩ Ｉｎｑｕｉｒｙコマンドを発行する。ステップ４１０で受け取られてかつステップ４１２で記録された仮想ディスクの応答は、仮想ディスクが「ＵＮＭＡＰ」コマンド（実施態様によってはＵＮＭＡＰ「ビット」によって示される）をサポートするか否かに関する指示を含み、及びサポートがあるならば、応答はさらにＵＮＭＡＰコマンドと共に用いられるべきいくつかのパラメータのレポートを含む。その最も単純な形において、一実施態様において、ＵＮＭＡＰコマンドは仮想ディスクによってマップ解除され、かつ仮想ディスクが格納されているＬＵＮに解放されるべきブロックのリストを特定する。そのような実施態様において報告されるパラメータは、Ｖ_Ｇ（そこでハイパーバイザ２０８がデータを管理する粒度）、Ｖ_{ｏｆｆｓｅｔ}（ハイパーバイザ２０８がＵＮＭＡＰコマンドを受け取るのを好むオフセットとして表現される整合パラメータ）、及びＮ_{ＭＡＸ＿Ｖ}（単一マップ解除コマンドで特定可能な＜ｏｆｆｓｅｔ，ｌｅｎｇｔｈ＞対の最大数）、を含む。仮想ディスクに対するＶ_Ｇ及びＶ_{ｏｆｆｓｅｔ}は、ＬＵＮに対するＤ_Ｇ及びＤ_{ｏｆｆｓｅｔ}に類似しており、従って、前述のようにＤ_Ｇ及びＤ_{ｏｆｆｓｅｔ}に同様に用いられる。

【0023】

[0037]図５は、例えば、ＶＭがその仮想ディスク内に格納されるファイルを削除する時の、ＶＭによって開始されるストレージ空間再利用の一方法を例示する流れ図である。認識されるべきことは、ファイルが、連続していてもしていなくてもよい一連のファイルブロックとして、仮想ディスク（例えば、それはそれ自体でＬＵＮ内に格納されたファイルである）内に表されること、及び、図５の方法が、「ファイルセグメント」として本願明細書では呼ばれる、連続したファイルブロックの各組に対して実行されること、である。一実施態様において、図５のステップが、ゲストＯＳ２１６内の削除されたファイルに関する空きファイルシステムブロックを監視してかつ識別するために開発されたユーザレベルプロセスによって実行される。例えば、この種の監視プロセスは、最近削除されたファイルに関する空きブロックを認識する際に定期的な間隔で図５の方法を実行してもよく、又は仮想ディスクからファイルの削除の際にゲストＯＳ２１６によって通知されてもよい。ステップ５０８で、仮想ディスクによって公開された、図４のステップ４１０で受け取られたＵＮＭＡＰビットが調べられる。このビットが設定されないならば、この方法はこの種の判定の後で終わる。ステップ５０８で、仮想ディスクによって公開されたＵＮＭＡＰビットが設定されるならば、この方法はステップ５１０へ続き、そこで仮想ディスクによって公開されたオフセットに準拠する（例えば、その倍数である）オフセットで始まる削除されたファイルのファイルセグメントの長さ（又は、代わりとして、ゲストＯＳ２１６によって示された多数の連続した空きファイルシステムブロックの長さ）、Ｖ_{ｏｆｆｓｅｔ}（この後「Ｌ１」と称するこの種のファイルセグメントの長さ）が、決定される。従って、Ｖ_{ｏｆｆｓｅｔ}と自然に整合されないファイルセグメントは、このステップを実施することによってＶ_{ｏｆｆｓｅｔ}と整合するようにされる。Ｌ１がステップ５１０で決定された後で、ステップ５１４で、Ｌ１は仮想ディスクによって公開された粒度、Ｖ_Ｇと比較される。Ｌ１＜Ｖ_Ｇならば、次にステップ５１６で、ファイルセグメントが仮想ディスクに対するマップ解除コマンドをサポートするために十分な連続したファイルブロックを含まないと判定され、及びそのようなものとして、監視プロセスによってその後識別されることができるこの種のファイルブロックに隣接する他の空きブロックとの、可能な合体のためにファイルセグメントのファイルブロックが、記憶される（例えば、特別なデータ構造内のファイルブロックを識別する）。記憶されたファイルブロックは、そのＬ１がまたＶ_Ｇ未満である他のファイルセグメントから、ファイルブロックに隣接していてもよいので、ステップ５１６が実施される。その場合は、ファイルブロックは、仮想ディスクによって公開された粒度に固着する単一ＵＮＭＡＰコマンド内の可能な内包に対して合体される。しかしながら、記憶されたファイルブロックは、また、（例えば、監視プロセスによって）書込みに対して監視され、かつ、（この種のファイルブロックはＵＮＭＡＰコマンドに対してもはや空いてないので）書込みがそれに対して発行されるならば、もはや記憶されない（例えば、特別なデータ構造から除去される）。ステップ５１０への破線の矢印によって示されるように、合体されたファイルブロックの長さ、Ｌ１はステップ５１０で決定される。ステップ５１４で、それらが条件、Ｌ１＜Ｖ_Ｇを満たすかどうか見るために、Ｌ１がもう一度確認される。

【0024】

[0038]Ｌ１がＶ_Ｇ以上であるならば、ＵＮＭＡＰコマンドと共に用いられる＜ｏｆｆｓｅｔ，ｌｅｎｇｔｈ＞ディスクリプタがステップ５１８で生成される。次いで、ステップ５２０で、処理すべきより多くのファイルセグメントがあるかどうかが、判定される。もしあれば、流れは、ステップ５１０に戻る。これ以上ないならば、１つ以上の＜ｏｆｆｓｅｔ，ｌｅｎｇｔｈ＞ディスクリプタの列を備えたＵＮＭＡＰコマンドが生成されてステップ５２２で仮想ディスクに送られる。ステップ５１８で生成されたディスクリプタの数が仮想ディスクによって公開された最大数、Ｎ_{ＭＡＸ＿Ｖ}より大きいならば、ＵＮＭＡＰコマンドは複数のＵＮＭＡＰコマンドに分割されて別々に仮想ディスクに送られる。この方法は、ステップ５２２の後で終わる。

【0025】

[0039]例えば、Ｖ_Ｇ＝１ＭＢ及びＶ_{ｏｆｆｓｅｔ}＝４ＫＢであり、ステップ５１０で分析されたファイルセグメントが仮想ディスクの始まりから５ＫＢに対応するアドレスから始まって１．５ＭＢの長さ、Ｌ１を有したならば、その時、ディスクリプタが仮想ディスクによって公開された粒度及び整合パラメータに準拠するように、ＵＮＭＡＰコマンドのために生成されたこのファイルセグメントに対する対応するディスクリプタは＜８ＫＢ、１ＭＢ＞である。即ち、ファイルセグメントのその部分がＶ_{ｏｆｆｓｅｔ}（即ち４ＫＢ）の倍数であるアドレスから始まらないので、仮想ディスクは５ＫＢから８ＫＢまでのファイルセグメントの初めの３ＫＢの部分をマップ解除することができない。同様に、テール部分がファイルセグメントの第２の１ＭＢの部分内に納まるので、仮想ディスクはファイルセグメントのテール部分（即ちおよそ最後の０．５ＭＢ）をマップすることができず、仮想ディスクは１ＭＢの倍数でマップ解除することができるだけである。

【0026】

[0040]図６は、（例えば、図５のステップ５２２から受け取られる）ＶＭからのＵＮＭＡＰコマンドに応答してハイパーバイザ２０８によって開始されたストレージ空間再利用の一方法を例示する流れ図である。ステップ６０２で、ハイパーバイザ２０８、特にＳＣＳＩ仮想化レイヤ２２８は、仮想ディスクの代わりにＶＭからＵＮＭＡＰコマンドを受け取ってかつＵＮＭＡＰコマンドを、連続していてもしていなくてもよい、一連のＶＭＦＳブロックに概念的に対応する、ＶＭＦＳファイルオフセット及び長さに変換する。ＶＭＦＳブロックはこの後空きＶＭＦＳブロックと称され、及び、空きＶＭＦＳブロックの各連続したセグメントはＶＭＦＳブロックセグメントと称される。次いで、空きＶＭＦＳブロックが割り当てられたままにしておかれるべきであるかどうか、判定がステップ６０４でなされる。例えば、仮想ディスクが薄く供給されなくてその代わりに予め割り当てられる時、空きＶＭＦＳブロックを割り当てられたままにしておくことがステップ６０４で決定される。従って、空きＶＭＦＳブロックが割り当てられたままにしておかれるべきであるならば、仮想ディスクを代表するＶＭＦＳファイルのメタデータ（即ちアイノード）が、空きＶＭＦＳブロックが、特許文献２にて説明され、その内容全体を本願明細書に引用したものであるように、「ゼロ合わせされるべき」として示されるようにアップデートされる。この方法は、ステップ６０５の後で終わる。他方では、空きＶＭＦＳブロックが割当てを解除されるべきであることがステップ６０４で決定されるならば、空きＶＭＦＳブロックは、仮想ディスクを代表するＶＭＦＳファイルから、ステップ６０６で割当てを解除される。論理サイズが同じのままの場合であっても、この割当て解除は（仮想ディスクに対応するＶＭＦＳファイルのアイノード内に記録されたように）仮想ディスクに割り当てられたブロックの物理サイズを減少させる。この割当て解除の一部として、ＶＭＦＳ ２３０によって管理されたビットマップデータ構造が、割当てを解除されたＶＭＦＳブロックが目下空いていることを示すようにアップデートされる。この割当て解除がＬＵＮへ仮想ディスク（例えば薄く供給された仮想ディスク）から空きブロックを実質的に解放するので、ハイパーバイザ２０８によって実行されるように、それが仮想ディスク上のＶＭからのＵＮＭＡＰコマンドの満足を代表する点に留意する必要がある。しかしながら、特定の実施態様において、仮想ディスクから戻る空きブロックをちょうど受け取った、かつ薄く供給されたＬＵＮである、ＬＵＮがそれ自体で、（例えば、この種の空きブロックが別のＬＵＮによって利用されることができるように）その下位ストレージアレイへこの種の空きブロックを解放することができるかどうかを、この接合点で、判定するよう更に求められてもよい。

【0027】

[0041]実施態様によっては、ハイパーバイザ２０８は空きＶＭＦＳブロックを再利用する（例えば、この種の空きブロックを別の仮想ディスクに割り当てる）よう求めることができる。このチェックは、ステップ６０８でなされる。ハイパーバイザ２０８が空きＶＭＦＳブロックを再利用するよう求めると判定されるならば、この方法は終わる。他方では、ハイパーバイザ２０８が現在時刻で空きＶＭＦＳブロックを再利用するよう求めないとステップ６０８で判定されるならば、空きＶＭＦＳブロックを格納するＬＵＮによって公開されたＵＮＭＡＰビットは、（例えば、この種の空きブロックが別のＬＵＮによって利用可能なように）ＬＵＮがその下位ストレージアレイへ空きＶＭＦＳブロックを解放することが可能であるかどうか、判定するためにステップ６１０で調べられる。このビットが設定されないならば、この方法はこの種の判定の後で終わる。ステップ６１０で、ＬＵＮによって公開されるマップ解除ビットが設定されるならば、この方法はステップ６１２へ続き、そこで、ＬＵＮによって公開されたオフセットに準拠するオフセットから始まる１つのＶＭＦＳブロックセグメントの長さ、Ｄ_{ｏｆｆｓｅｔ}（この後「Ｌ２」と称する長さ）が、判定される。従って、Ｄ_{ｏｆｆｓｅｔ}と自然に整合されないＶＭＦＳブロックセグメントは、このステップを実施することによってＤ_{ｏｆｆｓｅｔ}と整合するようにされる。Ｌ２がステップ６１２で判定された後で、Ｌ２はＬＵＮによって公開された粒度、Ｄ_Ｇと比較される。Ｌ２＜Ｄ_Ｇならば、ＶＭＦＳブロックセグメント内のＶＭＦＳブロックは、ステップ６１６で監視されるそれへの可能な合体及び書込みに対して記憶される（例えば、特別なデータ構造内のＶＭＦＳブロックを識別する）。記憶されたＶＭＦＳブロックが、そのＬ２がＤ_Ｇ未満である他のＶＭＦＳブロックセグメントからのＶＭＦＳブロックと隣接していてもよいので、ステップ６１６が実施される。その場合は、ＶＭＦＳブロックは、ＬＵＮによって公開された粒度に固着する単一ＵＮＭＡＰコマンド内の可能な内包に対して合体される。しかしながら、記憶されるＶＭＦＳブロックは、書込みのために監視され、及び、書込みがそれに対して発行されるならば、もはや記憶されない（例えば、特別なデータ構造から除去される）。判定ブロック６１２に破線の矢印によって示されるように、それらが条件、Ｌ２＜Ｄ_Ｇを満たすかどうか見るために、合体されたＶＭＦＳブロックがチェックされる。

【0028】

[0042]Ｌ２がＤ_Ｇ以上であるならば、ＵＮＭＡＰコマンドと共に用いられる＜ｏｆｆｓｅｔ，ｌｅｎｇｔｈ＞ディスクリプタがステップ６１８で生成される。次いで、ステップ６２０で、処理されるべきより多くのＶＭＦＳブロックセグメントがあるかどうかが、判定される。もしあれば、フローは、ステップ６１２に戻る。これ以上ないならば、１つ以上の＜ｏｆｆｓｅｔ，ｌｅｎｇｔｈ＞ディスクリプタの列を備えたＵＮＭＡＰコマンドが生成されてステップ６２２でＬＵＮに送られる。ステップ６１８で生成されたディスクリプタの数が仮想ディスクによって公開された最大数、Ｎ_{ＭＡＸ＿Ｄ}より大きいならば、ＵＮＭＡＰコマンドは複数のＵＮＭＡＰコマンドに分割されて別々にＬＵＮに送られる。この方法は、ステップ６２２の後で終わる。

【0029】

[0043]例えば、１つのＶＭＦＳブロックセグメントが＜８ＫＢ、１ＭＢ＞によって記述されて、並びにＤ_Ｇ＝３２ＫＢ及びＤ_{ｏｆｆｓｅｔ}＝１６ＫＢならば、ディスクリプタがＬＵＮによって公開された粒度及び整合パラメータに準拠するように、ＵＮＭＡＰコマンドはディスクリプタ＜１６ＫＢ、（１ＭＢ−３２ＫＢ）＞と共に発行される。即ち、ファイルセグメントのその部分がＤ_{ｏｆｆｓｅｔ}（即ち１６ＫＢ）の倍数であるアドレスから始まらないので、ＬＵＮは８ＫＢから１６ＫＢまでのＶＭＦＳブロックセグメントの初めの８ＫＢの部分をマップ解除することができない。同様に、テール部分が３２ＫＢの粒度に準拠するにはあまりに小さいので、ＬＵＮはＶＭＦＳブロックセグメントのテール部分（即ち、およそ最後の２４ＫＢ）をマップすることができない。

【0030】

[0044]図７は、管理サーバ１４８からのＵＮＬＩＮＫコマンドに応答してハイパーバイザ２０８によって開始されたストレージ空間再利用の一方法を例示する流れ図である。ＵＮＬＩＮＫコマンドは、ＶＭＦＳ２３０によって維持されるファイル又はファイルの組を削除し、かつこれらのファイルに対応するＶＭＦＳブロックの割当てを解除するようにＵＮＭＡＰコマンドを発行するようにハイパーバイザ２０８に知らせるように発行される。例えば、Ｓｔｏｒａｇｅ ｖＭｏｔｉｏｎ（商標）が実施された後で、その結果、ＶＭと関連する一組のファイル（例えば、仮想ディスクを例えば備えるか又は含む）が、ソースＬＵＮから宛先ＬＵＮに移行され、ＵＮＬＩＮＫコマンドが、ファイルを削除し、かつ、ソースＬＵＮから、これらのファイルに対応するＶＭＦＳブロックの割当てを解除するために管理サーバ１４８によって発行されてもよい。この方法はステップ７０２から始まり、そこで、ハイパーバイザ２０８がファイル又は複数ファイルのアイノードを調べることによって削除されたファイル又は削除されたファイルの組に対応するＶＭＦＳブロックセグメントを識別する。図７内に例示される残りのステップは図６の同じ番号をつけられたステップと同一であり、参照がこれらのステップに対して上述のようになされる。

【0031】

[0045]図８は、ソースホストから宛先ホストにＶＭをライブ移行するプロセスを開始する前に互換性チェックを実行する一方法を例示する流れ図である。薄く供給された仮想ディスクによってサポートされたＶＭは、好ましくは、ＵＮＭＡＰサポートによって薄く供給された仮想ディスクを提供することが可能でない宛先ホスト上のハイパーバイザに移行されるべきでないので、これらの互換性チェックは管理サーバ１４８によって実施される。これらのチェックは、ハイパーバイザのバージョンナンバをチェックすることを含む種々の方法で実行されてもよい。例えば、宛先ホスト上のハイパーバイザのバージョンナンバがシン・プロビジョニングをサポートするハイパーバイザの最も低いバージョンナンバ以上であるならば、ソースホストから宛先ホストへのライブの移行が可能にされる。ライブの移行は、そうでなければ承認されない。

【0032】

[0046]図８を参照して、ステップ８０２で、ライブ移行されるべきＶＭが、識別される。このＶＭが薄く供給された仮想ディスクでサポートされることが、例証のために想定される。ステップ８０８で、宛先ホスト上のハイパーバイザも薄く供給された仮想ディスクをサポートするかどうか見るために、チェックがなされる。一実施態様において、このチェックは上記の通りにバージョンナンバに基づいてなされる。チェックが失敗するならば、準拠したハイパーバイザを備えた宛先ホストが見いだされるまで、この方法はステップ８１０及び８１２を通してループする。準拠したハイパーバイザがないならば、この方法は終了する。準拠したハイパーバイザが見いだされるならば、ＶＭのライブの移行がステップ８２０で管理サーバ１４８によって開始される。

【0033】

[0047]図９は、ＬＵＮが用いられた容量内の特定のしきい値に到達したと管理サーバ１４８に通知する一方法を例示する流れ図である。ＬＵＮにより多くの空間を供給すること、ＵＮＬＩＮＫコマンドを用いてＬＵＮに格納された、使っていないファイルを削除すること、又はＬＵＮから別のＬＵＮへ作業負荷（例えばＶＭの仮想ディスク）を移行し、移行された作業負荷上でＵＮＬＩＮＫコマンドを起動することが続くような、救済策を管理サーバ１４８が使用できるように、この通知が与えられる。ステップ９０２及び９０４は、ストレージアレイによって実施される。ステップ９０６は、ハイパーバイザによって実施される。

【0034】

[0048]ステップ９０２は、ＬＵＮのストレージ容量が特定の閾値レベルに到達したか又は超えたかどうかを、ストレージアレイが継続的に監視していることを示す。この条件が満たされると判定するならば、それはＬＵＮ ＩＤと共にステップ９０４でハイパーバイザにソフトエラーメッセージを発行する。例えば、ＬＵＮがその閾値レベルを上回ることに結びつくＬＵＮへの任意の書込み動作は、ストレージアレイにハイパーバイザに対してソフトエラーメッセージを発行させる。ステップ９０６で、このソフトエラーメッセージを受け取る際に、ハイパーバイザは管理サーバ１４８にソフトエラーメッセージを発行する。管理サーバ１４８が上記の救済策を使用することができるように、ソフトエラーメッセージはＬＵＮ ＩＤ及びＶＭＦＳ ＩＤを含む。

【0035】

[0049]図１０は、図９のステップ９０６で生成されたソフトエラーメッセージを受け取る際に管理サーバ１４８によって善後策を実行する一方法を例示する流れ図である。ステップ１００２で、管理サーバ１４８がソフトエラーメッセージを受け取る。次いで、ステップ１００４で、管理サーバ１４８が、収容能力に近づいているＬＵＮによってサポートされるＶＭの構成設定を調べる。本発明の実施態様によれば、ＶＭの配備の際に特定可能な構成設定の１つが、ＶＭをサポートするＬＵＮが収容能力に近づいている時、どんな救済策がとられるべきであるかである。選択肢の三つが、Ｓｔｏｒａｇｅ ｖＭｏｔｉｏｎ（商標）、スナップショット及びパワーオフである。１００６の判定ブロックの後、Ｓｔｏｒａｇｅ ｖＭｏｔｉｏｎ（商標）がこの種の設定で指定されるならば、ステップ１００８が実行され、スナップショットがこの種の設定で指定されるならば、ステップ１０１０が実行され、及び、パワーオフがこの種の設定で指定されるならば、ステップ１０１２が実行される。ステップ１００８で、管理サーバ１４８はソースＬＵＮ（即ち収容能力に近づいているＬＵＮ）と宛先ＬＵＮとの間のＳｔｏｒａｇｅ ｖＭｏｔｉｏｎ（商標）を開始する。Ｓｔｏｒａｇｅ ｖＭｏｔｉｏｎ（商標）の完了の後、ＵＮＬＩＮＫコマンドがソースＬＵＮから移行されたファイルを削除するために用いられる。ステップ１０１０で、ＶＭファイルのスナップショットが宛先ＬＵＮ上に作り出され、及び、ソースＬＵＮ上のＶＭファイルが読取り専用にマークされる。ステップ１０１２で、管理サーバ１４８はＶＭをパワーオフする。

【0036】

[0050]何の救済策も使用されないか、又はそれらがあまりに遅く配備されるならば、又は救済策が配備されるにもかかわらず、書込み動作を実行する時、ＬＵＮは空間が尽きるかもしれない。この条件の下で、ハードエラーメッセージがストレージアレイによって発行される。より多くの空間がＬＵＮに供給されるか、又はＬＵＮ内の追加的な空間が再利用されるまで、書込み動作を発行したＶＭが停止可能なように、このエラーメッセージはエラー条件を引き起こした書込み動作のＩＤを含む。エラーを引き起こしたＶＭだけを停止させることによって、ＶＭ分離は保たれ、及び、ストレージのために同じＬＵＮを使用している他のＶＭは動作中のままであることができる。

【0037】

[0051]図１１は、書込み動作を実行する間、ＬＵＮが、空間が尽きる時引き起こされるエラーを検出して処理する一方法を例示する流れ図である。ステップ１１０２、１１０４及び１１０６は、ストレージアレイによって実施される。ステップ１１０８は、ハイパーバイザによって実施される。ステップ１１０２で、ストレージアレイはＬＵＮ上の書込み動作を受け取って実行する。書込み動作の実行中に、判定ブロック１１０４で判定されるようにＬＵＮが、空間が尽きるならば、ハードエラーメッセージがステップ１１０６でハイパーバイザに発行される。エラーメッセージが、エラーを引き起こした書込み動作のＩＤを含む。ステップ１１０８で、ハイパーバイザが書込み動作を発行したＶＭを非活性化する。通常の環境の下で、ＶＭの非活性化はアラートメッセージが管理サーバ１４８に伝送されることに結びつき、及び、管理サーバ１４８は非活性化されたＶＭを再開させる前にそれに応答して救済策を実現することができる。救済策は、非活性化されたＶＭの仮想ディスク（又は他のＶＭの仮想ディスクさえ）を別のＬＵＮに移行することを目的として、ＬＵＮにより多くの空間を供給してかつＬＵＮ内の追加的な空間を再利用し、移行された仮想ディスク上でＵＮＬＩＮＫコマンドを起動して、特定のＶＭをパワーオフするか又は他のファイルを削除することが続く、ことを含む。

【0038】

[0052]図１２は、本発明の１つ以上の実施態様に従うシステムソフトウェアインタフェースを有しないバージョンから有するバージョンにアップグレードされたハイパーバイザに対する論理ブロックデバイスとして動作するＬＵＮから、ストレージ空間を遡及して再利用する一方法を例示する流れ図である。ハイパーバイザアップグレードが実施された後で、この方法が実施される。ステップ１２０２で、ハイパーバイザはＬＵＮ内のその空きＶＭＦＳブロックの合計サイズを決定する。ステップ１２０４で、ハイパーバイザはＬＵＮ内のその空きＶＭＦＳブロックの合計サイズのＸ％である一時ファイルを作り出す。ステップ１２０６で、一時ファイルが削除され、及び、ハイパーバイザが一時ファイルの全てのブロックに対してＵＮＭＡＰコマンドを発行する。その結果、一時ファイルに対応するＶＭＦＳブロックがビットマップ内に空いていると示唆されるように、ハイパーバイザが全てのＶＭＦＳブロックの使用を追跡するように維持するビットマップがアップデートされる。Ｘ％パラメータが設定可能であり、かつ、１００％に等しいならば、ハイパーバイザの空きＶＭＦＳブロックの全てがＬＵＮから割当てを解除され、ＬＵＮの物理サイズをその理論上の最小値に減少させる。しかしながら、図１２の方法が実施される間に、追加的な空間を必要とするＬＵＮに、書込みがあるかもしれない。従って、経験的に決定されることができる一定量の空間が、この種の書込みを処理するように空いたまま保たれる。

【0039】

[0053]本発明の１つ以上の実施態様において、ＳＣＳＩ読取り容量及びＳＣＳＩ問合せを含む、ＬＵＮにハイパーバイザによってかつ仮想ディスクにゲストオペレーティングシステムによって発行されるコマンド、及びハイパーバイザにストレージアレイによって発行されるエラー、例えば図９と関連して記載されているソフトエラー及び図１１と関連して記載されているハードエラーは、Ｔ１０ ＳＣＳＩプロトコル内のコマンド及びエラーコードの組の一部である。

【0040】

[0054]１つ以上の実施態様が理解の明快さのためにいくらか詳細に本願明細書に記載されたとはいえ、特定の変更及び修正が本発明の趣旨から逸脱することなく、なされることができると認識されるべきである。

【0041】

[0055]本願明細書に記載されている種々の実施態様は、コンピュータシステムに格納されるデータを含む種々のコンピュータ実行動作を用いてもよい。例えば、これらの動作は通常物理量の物理的操作を必要とすることができ、必ずしもではないが、これらの量は電気又は磁気信号の形をとることがあり、そこで、それら又はそれらの表現は、格納される、転送される、組み合わせられる、比較されるか又はさもなければ操作されることが可能である。更に、この種の操作は、生成する、識別する、決定するか又は比較することのような、用語でしばしば参照される。本発明の１つ以上の実施態様の一部を形成する本願明細書に記載されている任意の動作が有用なマシン動作である。加えて、本発明の１つ以上の実施態様がこれらの動作を実行するためのデバイス又は装置にもまた関する。装置は特定の必要とされた目的のために特別に構成されてもよく、又は、それがコンピュータに格納されるコンピュータプログラムによって選択的に活性化されたか又は構成された汎用コンピュータであってもよい。特に、種々の汎用マシンが本願明細書の教示に従って書かれたコンピュータプログラムと共に用いられてもよく、又は、必要とされた動作を実行するためにより専門の装置を構成することがより都合がいい場合がある。

【0042】

[0056]本願明細書に記載されている種々の実施態様は、携帯デバイス、マイクロプロセッサシステム、マイクロプロセッサベースの又はプログラム可能な民生用電子機器、ミニコンピュータ、メインフレームコンピュータ等を含む他のコンピュータシステム構成で実践されてもよい。

【0043】

[0057]本発明の１つ以上の実施態様が、１つ以上のコンピュータ可読の媒体内に具体化された１つ以上のコンピュータプログラムとして又は１つ以上のコンピュータプログラムモジュールとして実現されてもよい。用語コンピュータ可読の媒体は、その後にコンピュータシステムに入力可能なデータを格納することができる任意のデータストレージデバイスを指し、コンピュータ可読の媒体は、それらがコンピュータによって読み取られることを可能にする方法で、コンピュータプログラムを具体化するための任意の既存の又は後で開発される技術に基づいてもよい。コンピュータ可読の媒体の例は、ハードディスク、ネットワーク接続ストレージ（ＮＡＳ）、読取り専用メモリ、ランダムアクセスメモリ（例えば、フラッシュメモリデバイス）、ＣＤ（コンパクトディスク）、ＣＤ−ＲＯＭ、ＣＤ−Ｒ又はＣＤ−ＲＷ、ＤＶＤ（デジタル多用途ディスク）、磁気テープ及び他の光及び非光データストレージデバイスを含む。コンピュータ可読のコードが格納され、かつ分散された形態で実行されるように、コンピュータ可読の媒体はまた、コンピュータシステムに連結されたネットワークを介して分散可能である。

【0044】

[0058]本発明の１つ以上の実施態様が、理解の明快さのためにいくらか詳細に記載されたとはいえ、特定の変更及び修正が本請求項の有効範囲内でなされてもよいことは明らかである。従って、記載されている実施態様は、例示的であり限定的でないとみなされるべきであり、かつ、請求項の有効範囲は本願明細書に与えられる詳細に限定されるべきでなく、しかし請求項の有効範囲及び等価物の範囲内で変更されてもよい。本請求項において、要素及び／又はステップは、請求項内に明示的に述べられない限り、動作のいかなる特定の順序も意味しない。

【0045】

[0059]種々の実施態様に従う仮想化システムは、ホストされた実施態様、ホストされない実施態様として、又は二つの区別を不鮮明にする傾向がある実施態様として実現されてもよいことが、全て構想される。さらに、種々の仮想化動作はハードウェアで完全に又は部分的に実現されてもよい。例えば、ハードウェア実現は非ディスクデータを確保するためにストレージアクセス要求の修正に対してルックアップテーブルを使用してもよい。

【0046】

[0060]多くの変形、修正、追加及び改良が、仮想化の程度に拘わらず可能である。仮想化ソフトウェアは、従って、仮想化機能を実行するホスト、コンソール又はゲストオペレーティングシステムのコンポーネントを含むことができる。複数のインスタンスが、単一インスタンスとして本願明細書に記載されているコンポーネント、動作又は構造に与えられてもよい。最後に、種々のコンポーネント、動作及びデータストアの間の境界は幾分任意であり、及び、特定の動作が特定の例証となる構成の局面で例示される。機能の他の割当てが構想されてかつ本発明（複数発明）の有効範囲内に含まれてもよい。一般に、例示的な構成で別々のコンポーネントとして提示された構造及び機能は、組み合わせられた構造又はコンポーネントとして実現されてもよい。同様に、単一コンポーネントとして提示された構造及び機能は、別々のコンポーネントとして実現されてもよい。これらの、そしてまた他の、変形、修正、追加及び改良は、添付の請求項（複数請求項）の有効範囲内に含まれてもよい。

【図1】

【図2A】

【図2B】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】