(57)【特許請求の範囲】
【請求項１】
第１のオペレーティングシステムに基づいて第１のマシンとして動作するクライアント端末と、
前記クライアント端末とネットワークを介して接続される配信サーバであって、前記クライアント端末に仮想ディスクとして認識させるための第１の仮想ディスクファイルを構成するマスタディスクファイル及び少なくとも１つの差分ディスクファイルに含まれているデータを、前記クライアント端末に配信する配信サーバとを具備し、
前記第１の仮想ディスクファイルは、前記クライアント端末が第２のマシンとして動作するための第２のオペレーティングシステムを含む第１の仮想ディスクイメージを格納し、
前記マスタディスクファイルは、第１のサイズを有するＮ個のブロックから構成される第１世代の仮想ディスクイメージを第２の仮想ディスクイメージとして格納し、
前記少なくとも１つの差分ディスクファイルは、前記マスタディスクファイルの生成後に生じる、前記第１のサイズを有するＮ個のブロックから構成される差分ディスクイメージを、前記第１世代より新しい世代の第３の仮想ディスクイメージとして格納し、
前記マスタディスクファイル及び前記少なくとも１つの差分ディスクファイルの各々は管理情報を有し、
前記管理情報は、対応するディスクファイルに含まれるＮ個のブロックの各々が有効であるかを少なくとも示し、
前記配信サーバは、
前記マスタディスクファイルから抽出される前記管理情報を含む第１世代の第１のメタファイルと、前記少なくとも１つの差分ディスクファイルから抽出される前記管理情報を含む前記第１世代より新しい世代の少なくとも１つの第２のメタファイルとを生成するメタファイル生成部と、
前記第１のメタファイル及び前記少なくとも１つの第２のメタファイルを前記クライアント端末に配信し、前記クライアント端末によって要求された複数のブロックのデータを前記クライアント端末に配信する配信部とを具備し、
前記クライアント端末の前記第１のマシンは、
前記第１のメタファイルに含まれている前記管理情報及び前記少なくとも１つの第２のメタファイルに含まれている前記管理情報を参照することにより、複数の有効なブロックを検出する解析部と、
前記検出された複数の有効なブロックの配信を前記配信サーバに要求する要求部と、
前記配信サーバの前記配信部によって配信された複数の有効なブロックのデータを前記第１の仮想ディスクイメージに組み合わせるマージ部と、
第１のブロック、及び前記第１のブロックよりも古い世代の第２のブロックであって、前記第１のブロックとディスクファイル内の相対位置が同一の第２のブロックが、いずれも有効なブロックとして検出された場合、前記第２のブロックを無効化する無効化部とを具備する
コンピュータシステム。
【請求項２】
前記Ｎ個のブロックの各々は、前記第１のサイズよりも小さい第２のサイズを有するｍ個のセクタから構成され、
前記管理情報は、対応するディスクファイルに含まれる前記Ｎ個のブロックの各々に対応付けられたマップ情報を含み、
前記マップ情報は、対応するブロックの前記ｍ個のセクタの各々が有効であるかを示し、
前記解析部は、前記第１のメタファイルに含まれている前記管理情報及び前記少なくとも１つの第２のメタファイルに含まれている前記管理情報を世代の逆順に取り出して、前記取り出された管理情報に含まれる前記Ｎ個のブロックの各々に対応付けられたマップ情報を参照することにより、対応するブロックに含まれるｍ個のセクタの各々が有効であるかを判定し、
前記無効化部は、前記第１のブロックに含まれる第１のセクタが有効であると前記第１のブロックに対応付けられた第１のマップ情報に基づいて判定された場合、前記第２のブロックに対応付けられていて且つ当該判定に用いられたメタファイルよりも古い世代のメタファイルに含まれている管理情報内の第２のマップ情報を、前記第２のブロックに含まれていて且つブロック内の相対位置が前記第１のセクタと同一である第２のセクタが無効であることを示すように変更し、
前記要求部は、前記第２のマップ情報により前記第２のブロック内のｍ個のセクタが全て無効であると示されている場合、当該第２のブロックの配信を要求するのを抑止する
請求項１記載のコンピュータシステム。
【請求項３】
前記要求部は、前記検出された複数の有効なブロックの配信を、ブロックを単位に世代の逆順に要求し
前記クライアント端末の前記第１のマシンは、前記配信部によって第３のブロックのデータが配信され、且つ当該第３のブロックとディスクファイル内の相対位置が同一のブロックがディスク領域に保存されていない場合、当該第３のブロックを前記ディスク領域に保存する保存部を更に具備し、
前記第３のブロックは第３のマップ情報を含み、
前記解析部は、前記保存部に保存されている前記第３のブロックとディスクファイル内の相対位置が同一の第４のブロックが前記配信部によって配信され、且つ、前記第４のブロックの世代に対応するメタファイルに含まれている前記第４のブロックに対応付けられた第４のマップ情報が前記無効化のために変更されている場合、当該第４のマップ情報に基づいて、前記第４のブロック内の有効なセクタを検出し、
前記マージ部は、前記有効なセクタとして第４のセクタが検出された場合、前記保存部に保存されている前記第３のブロックに含まれていて、且つブロック内の相対位置が前記第４のセクタと同一の第３のセクタを、前記第４のセクタのデータで置き換え、且つ前記第３のセクタが有効であることを示すように、前記第３のブロックに含まれている前記第３のマップ情報を変更する置換部を具備する
請求項２記載のコンピュータシステム。
【請求項４】
配信サーバとネットワークを介して接続され、且つ第１のオペレーティングシステムに基づいて第１のマシンとして動作するクライアント端末において、
前記配信サーバは、前記クライアント端末に仮想ディスクとして認識させるための第１の仮想ディスクファイルを構成するマスタディスクファイル及び少なくとも１つの差分ディスクファイルに含まれているデータを、前記クライアント端末に配信し、
前記第１の仮想ディスクファイルは、前記クライアント端末が第２のマシンとして動作するための第２のオペレーティングシステムを含む第１の仮想ディスクイメージを格納し、
前記マスタディスクファイルは、第１のサイズを有するＮ個のブロックから構成される第１世代の仮想ディスクイメージを第２の仮想ディスクイメージとして格納し、
前記少なくとも１つの差分ディスクファイルは、前記マスタディスクファイルの生成後に生じる、前記第１のサイズを有するＮ個のブロックから構成される差分ディスクイメージを、前記第１世代より新しい世代の第３の仮想ディスクイメージとして格納し、
前記マスタディスクファイル及び前記少なくとも１つの差分ディスクファイルの各々は管理情報を有し、
前記管理情報は、対応するディスクファイルに含まれるＮ個のブロックの各々が有効であるかを少なくとも示し、
前記配信サーバは、
前記マスタディスクファイルから抽出される前記管理情報を含む第１世代の第１のメタファイルと、前記少なくとも１つの差分ディスクファイルから抽出される前記管理情報を含む前記第１世代より新しい世代の少なくとも１つの第２のメタファイルとを生成するメタファイル生成部と、
前記第１のメタファイル及び前記少なくとも１つの第２のメタファイルを前記クライアント端末に配信し、前記クライアント端末によって要求された複数のブロックのデータを前記クライアント端末に配信する配信部とを具備し、
前記クライアント端末の前記第１のマシンは、
前記第１のメタファイルに含まれている前記管理情報及び前記少なくとも１つの第２のメタファイルに含まれている前記管理情報を参照することにより、複数の有効なブロックを検出する解析部と、
前記検出された複数の有効なブロックの配信を前記配信サーバに要求する要求部と、
前記配信サーバの前記配信部によって配信された複数の有効なブロックのデータを前記第１の仮想ディスクイメージに組み合わせるマージ部と、
第１のブロック、及び前記第１のブロックよりも古い世代の第２のブロックであって、前記第１のブロックとディスクファイル内の相対位置が同一の第２のブロックが、いずれも有効なブロックとして検出された場合、前記第２のブロックを無効化する無効化部とを具備する
クライアント端末。
【請求項５】
クライアント端末と配信サーバとを具備するコンピュータシステムに適用される、仮想ディスクイメージを処理する方法において、
前記クライアント端末は、前記配信サーバとネットワークを介して接続され、且つ第１のオペレーティングシステムに基づいて第１のマシンとして動作するように構成され、
前記配信サーバは、前記クライアント端末に仮想ディスクとして認識させるための第１の仮想ディスクファイルを構成するマスタディスクファイル及び少なくとも１つの差分ディスクファイルに含まれているデータを、前記クライアント端末に配信するように構成され、
前記第１の仮想ディスクファイルは、前記クライアント端末が第２のマシンとして動作するための第２のオペレーティングシステムを含む第１の仮想ディスクイメージを格納し、
前記マスタディスクファイルは、第１のサイズを有するＮ個のブロックから構成される第１世代の仮想ディスクイメージを第２の仮想ディスクイメージとして格納し、
前記少なくとも１つの差分ディスクファイルは、前記マスタディスクファイルの生成後に生じる、前記第１のサイズを有するＮ個のブロックから構成される差分ディスクイメージを、前記第１世代より新しい世代の第３の仮想ディスクイメージとして格納し、
前記マスタディスクファイル及び前記少なくとも１つの差分ディスクファイルの各々は管理情報を有し、
前記管理情報は、対応するディスクファイルに含まれるＮ個のブロックの各々が有効であるかを少なくとも示し、
前記方法は、
前記マスタディスクファイルから抽出される前記管理情報を含む第１世代の第１のメタファイルと、前記少なくとも１つの差分ディスクファイルから抽出される前記管理情報を含む前記第１世代より新しい世代の少なくとも１つの第２のメタファイルとを生成し、
前記配信サーバから前記クライアント端末に、前記第１のメタファイル及び前記少なくとも１つの第２のメタファイルを配信し、
前記第１のメタファイルに含まれている前記管理情報及び前記少なくとも１つの第２のメタファイルに含まれている前記管理情報を参照することにより、複数の有効なブロックを検出し、
前記検出された複数の有効なブロックの配信を前記クライアント端末の前記第１のマシンから前記配信サーバに要求し、
前記配信サーバによって前記クライアント端末に配信された複数の有効なブロックのデータを前記第１の仮想ディスクイメージに組み合わせ、
第１のブロック、及び前記第１のブロックよりも古い世代の第２のブロックであって、前記第１のブロックとディスクファイル内の相対位置が同一の第２のブロックが、いずれも有効なブロックとして検出された場合、前記第２のブロックを無効化する
方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明の実施形態は、コンピュータシステム、同システムにおけるクライアント端末、及び同システムにおいて仮想ディスクイメージを処理する方法に関する。
【背景技術】
【０００２】
従来から、サーバとクライアント端末とを備えたコンピュータシステムが知られている。このサーバとして、ディスクイメージを例えば複数のクライアント端末にネットワークを介して配信する配信サーバが知られている。ディスクイメージは、仮想マシンが参照できる仮想ディスクに配置されるのが一般的である。そこで以下の説明では、ディスクイメージを仮想ディスクイメージと称する。【０００３】
仮想ディスクイメージは、オペレーティングシステム及び各種アプリケーションプログラムを含む。このような仮想ディスクイメージが配信サーバにより複数のクライアント端末に配信されることにより、当該複数のクライアント端末で実行されるオペレーティングシステム及び各種アプリケーションプログラムを統一することができる。【０００４】
仮想ディスクイメージを格納したファイルは、仮想ディスクファイルと呼ばれる。クライアント端末において、この仮想ディスクファイルが配信サーバにより配信された場合、当該仮想ディスクファイルをハイパーバイザが仮想ディスクとして認識できる。以下の説明では、仮想ディスクに格納される仮想ディスクイメージ（仮想ディスクファイル）を、第１の仮想ディスクイメージ（第１の仮想ディスクファイル）と呼ぶ。【０００５】
しかし、第１の仮想ディスクイメージ（第１の仮想ディスクファイル）は更新される。このため、第１の仮想ディスクイメージ（第１の仮想ディスクファイル）は、以下に述べるように、マスタディスクイメージ（マスタディスクファイル）と、少なくとも１つの差分ディスクイメージ（差分ディスクファイル）とを用いて構成されるのが一般的である。マスタディスクイメージは、最初に生成された第１世代の仮想ディスクイメージ（第２の仮想ディスクイメージ）であり、仮想ディスクのベースとして用いられる。差分ディスクイメージは、第１世代より新しい世代の仮想ディスクイメージ（第３の仮想ディスクイメージ）であり、オペレーティングシステムの更新やアプリケーションプログラムの変更（追加を含む）などにより生ずる差分（つまり変更部分）を表す。【０００６】
仮想ディスクは、マスタディスクイメージ（第２の仮想ディスクイメージ）と少なくとも１つの差分ディスクイメージ（第３の仮想ディスクイメージ）とを１つに組み合わせる（マージする）ことにより構成される。そこで配信サーバは、これらのディスクイメージを全てネットワーク経由でクライアント端末に配信する。この配信方法を第１の配信方法と称する。クライアント端末は、配信された全てのディスクイメージを第１の仮想ディスクイメージに組み合わせることにより、仮想ディスクを構築する。クライアント端末は、この仮想ディスクに基づいて仮想マシンまたはオペレーティングシステム及びアプリケーションプログラムを起動する。【０００７】
また、クライアント端末の負荷を軽減するための第２の配信方法も知られている。この第２の配信方法では、配信サーバが仮想ディスクを構成して、当該仮想ディスク全体のイメージ（第１の仮想ディスクイメージ）をクライアント端末に配信する。つまり、配信サーバはディスクイメージを個別に配信する代わりに、仮想ディスク全体のイメージをクライアント端末に配信する。
【先行技術文献】
【特許文献】
【０００８】
【特許文献１】特許第５１８０３９９号公報
【発明の概要】
【発明が解決しようとする課題】
【０００９】
第１の配信方法を適用する従来技術において、クライアント端末が初めて配信サーバから配信を受ける場合を想定する。この場合、配信サーバは、マスタディスクイメージ及び全ての差分ディスクイメージをネットワーク経由で当該クライアント端末に転送する必要がある。このイメージ転送に要する時間は、差分ディスクイメージの数（世代数）が多いほど増加し、ネットワークの負荷も増大する。【００１０】
また、クライアント端末は、全ての差分ディスクイメージを格納しなければならない。このためクライアント端末では、仮想ディスクイメージのために必要なディスク容量が増大する。また、このディスク容量を減らすため、配信サーバまたはクライアント端末が差分ディスクイメージ間でデータを結合することも考えられる。しかし、ディスクイメージの結合には時間がかかり、配信サーバまたはクライアント端末において負荷の増大を招く。【００１１】
またクライアント端末は、例えばデータ参照のために仮想ディスクにアクセスする際、最新世代の差分ディスクイメージの管理情報にアクセスすることにより、参照されるべきデータが存在するかを判定する。もし、参照されるべきデータが存在しないならば、クライアント端末は、先行する世代の差分ディスクイメージの管理情報にアクセスする。このため、差分ディスクイメージの数（世代数）が増えるほど、仮想ディスクアクセス性能が低下する。【００１２】
一方、第２の配信方法を適用する従来技術では、配信サーバは、仮想ディスク全体のイメージ、つまり、仮想ディスク全体のサイズ（論理サイズ）に相当する大きさの仮想ディスクイメージを送付する。この場合、配信サーバは、仮想ディスクにおける空き領域や削除（無効化）領域、更にはパーティションで構成されていない領域も含めて、イメージを転送しなければならない。このため第２の配信方法では、イメージの転送時間が一層増加する。ここで、仮想ディスクの論理サイズが１２７ギガバイト（ＧＢ）であり、実際には数ＧＢ程度しか当該仮想ディスクを使用していない場合を想定する。このような場合でも、配信サーバは、仮想ディスクの論理サイズである１２７ＧＢの大きさの仮想ディスクイメージを転送しなければならない。このため、クライアント端末のディスク容量が不足するケースも発生し得る。【００１３】
本発明が解決しようとする課題は、仮想ディスクを構成するマスタディスクイメージ、及び少なくとも１つの差分ディスクイメージを全て配信サーバからクライアント端末に配信することなく、当該クライアント端末において仮想ディスクを利用することができる、コンピュータシステム、クライアント端末及び仮想ディスクイメージを処理する方法を提供することにある。
【課題を解決するための手段】
【００１４】
実施形態によれば、コンピュータシステムは、クライアント端末と配信サーバとを具備する。前記クライアント端末は、第１のオペレーティングシステムに基づいて第１のマシンとして動作する。前記配信サーバは、前記クライアント端末とネットワークを介して接続される。前記配信サーバは、前記クライアント端末に仮想ディスクとして認識させるための第１の仮想ディスクファイルを構成するマスタディスクファイル及び少なくとも１つの差分ディスクファイルに含まれているデータを、前記クライアント端末に配信する。前記第１の仮想ディスクファイルは、第１の仮想ディスクイメージを格納する。前記第１の仮想ディスクイメージは、前記クライアント端末が第２のマシンとして動作するための第２のオペレーティングシステムを含む。前記マスタディスクファイルは、第１世代の仮想ディスクイメージを第２の仮想ディスクイメージとして格納する。前記第１世代の仮想ディスクイメージは、第１のサイズを有するＮ個のブロックから構成される。前記少なくとも１つの差分ディスクファイルは、前記マスタディスクファイルの生成後に生じる差分ディスクイメージを、前記第１世代より新しい世代の第３の仮想ディスクイメージとして格納する。前記差分ディスクイメージは、前記第１のサイズを有するＮ個のブロックから構成される。前記マスタディスクファイル及び前記少なくとも１つの差分ディスクファイルの各々は管理情報を有する。前記管理情報は、対応するディスクファイルに含まれるＮ個のブロックの各々が有効であるかを少なくとも示す。前記配信サーバは、メタファイル生成部と配信部とを具備する。前記メタファイル生成部は、第１世代の第１のメタファイルと、前記第１世代より新しい世代の少なくとも１つの第２のメタファイルとを生成する。前記第１のメタファイルは、前記マスタディスクファイルから抽出される前記管理情報を含む。前記少なくとも１つの第２のメタファイルは、前記少なくとも１つの差分ディスクファイルから抽出される前記管理情報を含む。前記配信部は、前記第１のメタファイル及び前記少なくとも１つの第２のメタファイルを前記クライアント端末に配信し、前記クライアント端末によって要求された複数のブロックのデータを前記クライアント端末に配信する。前記クライアント端末の前記第１のマシンは、解析部と要求部とマージ部とを具備する。前記解析部は、前記第１のメタファイルに含まれている前記管理情報及び前記少なくとも１つの第２のメタファイルに含まれている前記管理情報を参照することにより、複数の有効なブロックを検出する。前記要求部は、前記検出された複数の有効なブロックの配信を前記配信サーバに要求する。前記マージ部は、前記配信サーバの前記配信部によって配信された複数の有効なブロックのデータを前記第１の仮想ディスクイメージに組み合わせる。
【図面の簡単な説明】
【００１５】
【図１】図１は、実施形態に係るコンピュータシステムの典型的な構成を示すブロック図である。
【図２】図２は、図１に示される配信サーバ及びクライアント端末の典型的な機能構成を主として示すブロック図である。
【図３】図３は、図１に示される仮想ディスクの構成の例を示す図である。
【図４】図４は、同実施形態における典型的なメタファイル生成を説明するための図である。
【図５】図５は、クライアント端末の起動時の典型的な動作手順を説明するためのフローチャートの一部を示す図である。
【図６】図６は、同フローチャートの他の一部を示す図である。
【図７】図７は、同フローチャートの更に他の一部を示す図である。
【図８】図８は、同フローチャートの残りを示す図である。
【図９】図９は、同実施形態における受信不要なセクタの無効化を説明するための図である。
【図１０】図１０は、同実施形態におけるセクタデータの置き換えを説明するための図である。
【発明を実施するための形態】
【００１６】
以下、種々の実施の形態につき図面を参照して説明する。  
図１は、実施形態に係るコンピュータシステムの典型的な構成を示すブロック図である。このコンピュータシステムは、配信サーバ１と、クライアント端末２及び３とを備えている。配信サーバ１とクライアント端末２及び３とはネットワーク４によって接続されている。なお、ネットワーク４に３台以上のクライアント端末が接続されていても構わない。
【００１７】
配信サーバ１は、システムプール５を備えている。システムプール５は、例えば、複数の物理ディスクの記憶領域をまとめて構築される１つの大容量の仮想的（論理的）なディスクである。システムプール５の仮想ディスク５０には、複数、例えば３つの仮想ディスクファイル５１，５２及び５３が格納されている。
【００１８】
仮想ディスクファイル５１，５２及び５３は、クライアント端末２及び３を含む複数のクライアント端末で用いられる仮想ディスク５０を構成するのに必要な仮想ディスクイメージを格納したファイルである。配信サーバ１は、これらの仮想ディスクイメージを設定し、且つ管理する管理サーバとしての機能と、これらの仮想ディスクイメージを各クライアント端末にネットワーク４を介して配信する配信サーバとしての機能とを有する。
【００１９】
仮想ディスクファイル５１は、最初に生成された第１世代の仮想ディスクイメージを格納したファイルであり、仮想ディスクのベースとして用いられる。そこで以下の説明では、仮想ディスクファイル５１をマスタディスクファイル５１と称する。仮想ディスクイメージは、第２のオペレーティングシステム及び各種アプリケーションプログラム（より詳細には、仮想ディスク５０にインストールされた第２のオペレーティングシステム及び各種アプリケーションプログラムのイメージ）を含む。本実施形態において、第２のオペレーティングシステムは、ゲストオペレーティングシステム（以下、ゲストＯＳと称する）である。また本実施形態では、仮想ディスクイメージはセキュリティポリシーを含む。
【００２０】
仮想ディスクファイル５２は、第２世代の仮想ディスクイメージを格納したファイルである。第２世代の仮想ディスクイメージは、マスタディスクファイル５１の生成後（より詳細には、サーバ管理者からの最初の差分生成指示後）において実行された、ゲストＯＳの更新やアプリケーションプログラム（以下、ＡＰＰと称する）の変更（追加を含む）などにより生ずる差分（つまり変更部分）を表す。そこで以下の説明では、仮想ディスクファイル５２を差分ディスクファイル５２（または差分＃１）と称する。
【００２１】
仮想ディスクファイル５３は、第３世代の仮想ディスクイメージを格納したファイルである。第３世代の仮想ディスクイメージは、差分ディスクファイル５２の生成後（より詳細には、サーバ管理者からの２回目の差分生成指示後）において実行された、ゲストＯＳの更新やＡＰＰの変更などにより生ずる差分を表す。そこで以下の説明では、仮想ディスクファイル５３を差分ディスクファイル５３（または差分＃２）と称する。
【００２２】
マスタディスクファイル５１、差分ディスクファイル５２及び差分ディスクファイル５２の各々は、当該ファイルに格納されている仮想ディスクイメージの構成を示す管理情報（ディスク管理情報）を含む。これらのディスクファイル５１乃至５３のデータ形式については後述する。
【００２３】
クライアント端末２は、例えばパーソナルコンピュータ（ＰＣ）である。クライアント端末２は、ＰＣを実現するためのハードウェア（ＨＷ）２１を備えている。ＨＷ２１は、ＣＰＵ２１１、メモリ２１２、ハードディスクドライブ（ＨＤＤ）２１３及びネットワークコントローラ（ＮＣ）２１４を含む。図２では省略されているが、ＨＤＤ２１３には、後述する仮想化ソフトウェアプログラム及び第１のオペレーティングシステム（以下、制御ＯＳと称する）２６が格納されている。図２では、ＨＷ２１が一般的に有する表示装置のような入出力装置も省略されている。なお、ＨＤＤ２１３に代えて、ソリッドステートドライブ（ＳＳＤ）のような外部記憶装置を用いても構わない。またＨＷ２１が、ＨＤＤ２１３に加えてＳＳＤを含んでいても構わない。
【００２４】
クライアント端末２は、当該クライアント端末２内で唯一完全な権限を有するハイパーバイザ２２を備えている。ハイパーバイザ２２は、クライアント端末２が起動されることにより、ＨＷ２１上で動作する。ハイパーバイザ２２は、ＣＰＵ２１１が仮想化ソフトウェアプログラムをＨＤＤ２１３からメモリ２１２に読み込んで実行することにより実現される。
【００２５】
ハイパーバイザ２２は、例えばクライアント端末２の起動時に、ＨＷ２１を用いて制御用の仮想マシン２３が動作する環境を提供することができる。つまりハイパーバイザ２２は、当該ハイパーバイザ２２上で動作する制御用の仮想マシン２３を構築することができる。ハイパーバイザ２２は、ＣＰＵ２１１及びメモリ２１２のような物理リソースの使用量、及び当該物理リソースの仮想マシン２３及び２４への割り当てを管理する。
【００２６】
仮想マシン２３は、制御ドメインと呼ばれる制御用の仮想マシン（第１のマシン）である。そこで以下の説明では、仮想マシン２３を制御仮想マシン２３と称する。制御仮想マシン２３は、ＨＤＤ２１３に格納されている制御ＯＳ２６に基づいて動作して、他の仮想マシン、例えば仮想マシン２４を構築し、且つ制御する。
【００２７】
仮想マシン２４は、制御仮想マシン２３の制御の下で、ゲストＯＳ２７に基づいて動作して、各種ＡＰＰ（アプリケーションプログラム）２８を実行する仮想マシン（第２のマシン）である。そこで以下の説明では、仮想マシン２４をゲスト仮想マシン２４と称する。ゲストＯＳ２７及びＡＰＰ２８は、ディスク領域２５に格納される仮想ディスクイメージに含まれている。ディスク領域２５は、ハイパーバイザ２２による物理リソースの割り当てに基づいて、ＨＤＤ２１３の一部の領域を用いて実現される。ゲスト仮想マシン２４は、ディスク領域２５に仮想ディスクイメージが格納された後に、制御仮想マシン２３によって構築される。
【００２８】
本実施形態では、ハイパーバイザ２２の負荷を軽減するために、制御仮想マシン２３がゲスト仮想マシン２４を構築する機能を有している。しかし、ハイパーバイザ２２がゲスト仮想マシン２４を構築しても構わない。逆に、ハイパーバイザ２２の負荷を一層軽減するために、制御仮想マシン２３が物理リソースの割り当てを管理しても良い。
【００２９】
図２は、図１に示される配信サーバ１及びクライアント端末２の典型的な機能構成を主として示すブロック図である。配信サーバ１は、仮想ディスクイメージ（ＶＤＩ）生成・更新部１１と、メタファイル生成部１２と、配信部１３とを備えている。
【００３０】
ＶＤＩ生成・更新部１１は、配信サーバ１が有する管理機能の１つである。ＶＤＩ生成・更新部１１は、マスタディスクファイル（ＭＤＦ）生成部１１１と、差分ディスクファイル（ＤＤＦ）生成部１１２とを備えている。ＭＤＦ生成部１１１は、サーバ管理者の操作に基づいて、マスタディスクファイル５１、つまり第１世代の仮想ディスクイメージが格納されたマスタディスクファイル５１を生成する。
【００３１】
ＤＤＦ生成部１１２は、マスタディスクファイル５１の生成後におけるサーバ管理者からの最初の差分生成指示に応じて、差分ディスクファイル５２（差分＃１）の生成を開始する。これによりＤＤＦ生成部１１２は、差分ディスクファイル５２、つまり第２世代の仮想ディスクイメージが格納された差分ディスクファイル５２を生成する。
【００３２】
ＤＤＦ生成部１１２はまた、マスタディスクファイル５１の生成後におけるサーバ管理者からの２回目の差分生成指示に応じて、差分ディスクファイル５２（差分＃１）の生成から差分ディスクファイル５３（差分＃２）の生成に切り替える。これによりＤＤＦ生成部１１２は、差分ディスクファイル５３、つまり第３世代の仮想ディスクイメージが格納された差分ディスクファイル５３を生成する。
【００３３】
メタファイル生成部１２は、配信サーバ１が有する配信機能の１つである。メタファイル生成部１２は、マスタディスクファイル５１、差分ディスクファイル５２及び差分ディスクファイル５３に含まれている管理情報を抽出する。これによりメタファイル生成部１２は、ディスクファイル５１，５２及び５３から抽出された管理情報を含むメタファイル１２１，１２２及び１２３を生成する。メタファイル１２１，１２２及び１２３は、それぞれディスクファイル５１，５２及び５３（より詳細には、ディスクファイル５１，５２及び５３に格納されている仮想ディスクイメージ）に対応する。つまりメタファイル１２１，１２２及び１２３の世代は、それぞれ第１世代、第２世代及び第３世代である。
【００３４】
配信部１３は、配信サーバ１が有する配信機能の他の１つである。配信部１３は、クライアント端末２から配信開始が要求された場合、メタファイル１２１乃至１２３をネットワーク４経由でクライアント端末２に配信（転送）する。配信部１３はまた、クライアント端末２から要求された仮想ディスクイメージのブロックのデータを、ネットワーク４経由でクライアント端末２に配信する。本実施形態において、仮想ディスクイメージの各ブロック（データブロック）は複数のセクタ（データセクタ）を含む。各セクタのサイズは、例えば５１２バイトである。
【００３５】
なお、配信サーバ１が有する管理機能を独立の管理サーバによって実現しても良い。この場合、配信サーバ１が、管理サーバとしての管理機能を必ずしも有している必要はない。つまり、配信サーバ１に代えて、ＶＤＩ生成・更新部１１を有する管理サーバと、メタファイル生成部１２及び配信部１３を有する配信サーバとを用いても良い。
【００３６】
一方、クライアント端末２（より詳細には、クライアント端末２の制御仮想マシン２３）は、受信部２３１と、解析部２３２と、要求部２３３と、保存部２３４と、マージ部２３５とを備えている。本実施形態において、これらの機能要素２３１乃至２３５は、制御仮想マシン２３（より詳細には、制御仮想マシン２３に割り当てられたＣＰＵ２１１）が制御ＯＳ２６の下で動作することにより実現されるソフトウェアモジュールである。
【００３７】
受信部２３１は、配信サーバ１の配信部１３によって配信されるデータ（つまりメタファイル１２１乃至１２３、及びブロックデータ）を受信する。解析部２３２は、受信された全てのメタファイルを、最新の世代のメタファイルから順（つまり、世代の逆順）に解析することにより、仮想ディスクイメージ内の受信不要なセクタを検出する。受信不要なセクタについては後述する。解析部２３２は、無効化部２３２ａを含む。無効化部２３２ａは、受信不要なセクタを無効化する。なお、無効化部２３２ａが解析部２３２から独立して備えられていても構わない。
【００３８】
要求部２３３は、受信不要なセクタが無効化部２３２ａによって無効化された後、世代の逆順（つまり、世代番号の降順）に、且つ有効なセクタを少なくとも１つ含むブロックを単位に、当該ブロックのデータの配信を配信サーバ１に要求する。保存部２３４は、受信ブロックのデータをディスク領域２５に保存する。
【００３９】
マージ部２３５は、受信ブロックのデータをマージすることにより、ディスク領域２５内に仮想ディスク５０を構築（復元）する。マージ部２３５は、置換部２３５ａを含む。置換部２３５ａは、無効セクタを含むブロック（第４のブロック）内の有効なセクタ（第４のセクタ）のデータで、ディスク領域２５に保存されているブロック（第３のブロック）内のセクタ（第３のセクタ）を置き換える（書き換える）。この置き換えにより、第３のブロックのデータと第４のブロックのデータとがマージされる。ここで、第３のブロック及び第４のブロックの仮想アドレスは同一であり、第３のセクタの第３のブロック内の相対位置は、第４のブロック内の第４のセクタの相対位置に一致する。第３のセクタ及び第４のセクタの仮想アドレスは同一である。
【００４０】
図３は、仮想ディスク５０の構成の例を示す。図３の例では、仮想ディスク５０は、マスタディスクファイル５１、差分ディスクファイル５２（差分＃１）、及び差分ディスクファイル５３（差分＃２）の３つの仮想ディスクファイルを格納する。この仮想ディスク５０は、マージ部２３５がマスタディスクファイル５１、差分ディスクファイル５２（差分＃１）、及び差分ディスクファイル５３（差分＃２）をマージすることにより実現される１つの仮想ディスクファイルを格納した仮想ディスクと等価である。
【００４１】
図３において、マスタディスクファイル５１、差分ディスクファイル５２及び差分ディスクファイル５３の配置位置は、双方向の矢印３００で示されるように世代を表す。マスタディスクファイル５１は最も古い世代（第１の世代）の仮想ディスクファイルであり、差分ディスクファイル５３は最も新しい世代（第３の世代）の仮想ディスクファイルである。
【００４２】
図３の例では、差分ディスクファイル５３は更新中の状態にある。マスタディスクファイル５１が生成された時点では、仮想ディスク５０は当該マスタディスクファイル５１のみを格納する。また、差分ディスクファイル５２が生成された時点では、仮想ディスク５０はマスタディスクファイル５１及び差分ディスクファイル５２を格納する。つまり仮想ディスク５０は、１つ以上の仮想ディスクファイルを格納する。
【００４３】
各仮想ディスクファイルは、ヘッダ（Ｈ）と、ブロックアロケーションテーブル（ＴＢＬ）と、Ｎ個のブロックＢＬＫ＿０乃至ＢＬＫ＿Ｎ−１と、フッタ（Ｆ）とから構成される。但し、Ｎ個のブロックＢＬＫ＿０乃至ＢＬＫ＿Ｎ−１の全てが有効であるとは限らない。つまり各仮想ディスクファイルは、有効なブロックを最大Ｎ個格納することができる。Ｎの値は、ブロック（ＢＬＫ）の長さと、仮想ディスク５０の論理サイズとに基づいて決定される。有効なブロックは、有効なデータ（セクタデータ）を含む。図３には、有効なブロックのみが示されている。図３において矢印３００に直交する方向は、仮想ディスク５０の仮想アドレス空間（オフセット）を示す。仮想アドレスは、ヘッダ（Ｈ）に近づくほど小さくなり、フッタ（Ｆ）に近づくほど大きくなるものとする。
【００４４】
本実施形態において、ヘッダ（Ｈ）及びフッタ（Ｆ）は同一の情報を有する。ヘッダ（Ｈ）及びフッタ（Ｆ）は、当該ヘッダ（Ｈ）及びフッタ（Ｆ）を有する仮想ディスクファイル（以下、対応仮想ディスクファイルと称する）の識別子（ＩＤ）、対応する仮想ディスク（ここでは仮想ディスク５０）の名称、及び親ディスクのパスを示す。親ディスクのパスは、対応仮想ディスクファイルよりも１世代前の仮想ディスクファイルの物理位置を示す。ヘッダ（Ｈ）及びフッタ（Ｆ）はまた、対応仮想ディスクファイルのファイル名、仮想ディスク５０のサイズ（つまり論理サイズ）及び各ブロック（ＢＬＫ）の長さを示す。ヘッダ（Ｈ）及びフッタ（Ｆ）は更に、対応仮想ディスクファイル内のブロック（ＢＬＫ）の数を示す。なお、ヘッダ（Ｈ）及びフッタ（Ｆ）のいずれか一方が、上述の情報を有していても構わない。
【００４５】
ブロックアロケーションテーブル（ＴＢＬ）は、対応仮想ディスクファイルに格納されるＮ個のブロックＢＬＫ＿０乃至ＢＬＫ＿Ｎ−１の識別子（ＢＬＫＩＤ）０乃至Ｎ−１に対応付けられたＮ個のエントリＴＢＬＥ＿０乃至ＴＢＬＥ＿Ｎ−１を有している。エントリＴＢＬＥ＿ｉ（ｉ＝０，１，…，Ｎ−１）の情報は、フラグ情報と位置情報とを含む。フラグ情報は、エントリＴＢＬＥ＿ｉと対応付けられたブロック識別子（ＢＬＫＩＤ）を持つ有効なブロックＢＬＫ＿ｉが対応仮想ディスクファイルに存在するか否かを示す。位置情報は、有効なブロックＢＬＫ＿ｉが対応仮想ディスクファイルに存在する場合に、当該ブロックＢＬＫ＿ｉの仮想ディスク５０内の位置（つまり仮想アドレス）を示す。
【００４６】
図３の例では、マスタディスクファイル５１は、有効なブロックＢＬＫ＿０，ＢＬＫ＿１，ＢＬＫ＿２，ＢＬＫ＿３及びＢＬＫ＿Ｎ−１を含む。各ブロック（ＢＬＫ）は、マップテーブル（ＭＡＰ）と、データ部（ＤＡＴＡ）とから構成される。データ部（ＤＡＴＡ）は、複数のセクタから構成される。この複数のセクタは、有効セクタと無効セクタとに分類される。有効セクタは有効なデータを有するセクタを指し、無効セクタは有効なデータを有さないセクタ（例えば、無効データを有するセクタ）を指す。また、データを有さないセクタ（つまり、空のセクタ）も無効セクタである。本実施形態において、ブロックの長さ（第１のサイズ）は２メガバイト（ＭＢ）であり、セクタの長さ（第２のサイズ）は５１２バイト（Ｂ）である。
【００４７】
マップテーブル（ＭＡＰ）は、ブロック内の複数のセクタがそれぞれ有効であるか（つまり、有効なデータを有しているか）を示す。ここで、ブロック内のセクタの数がｍであるものとする。本実施形態において、マップテーブル（ＭＡＰ）は、ブロック（ＢＬＫ）内のｍ個のセクタと対応付けられたｍ個のビットの列から構成されるビットマップ（ビットマップテーブル）である。このｍは、マップテーブル（ＭＡＰ）のビット列の長さ（つまりマップビット長）をも表す。マップテーブル（ＭＡＰ）の各ビットは、例えば１の場合、対応するセクタのデータが存在する（有効である）ことを表し、０の場合、対応するセクタのデータが存在しないこと、または無効であることを表す。
【００４８】
差分ディスクファイル５２及び５３も、上述のマスタディスクファイル５１と同様のデータ形式を有する。以下の説明では、ブロックＢＬＫ＿ｉ内のマップテーブル及びデータ部を、それぞれＭＡＰ＿ｉ及びＤＡＴＡ＿ｉと表記する。
【００４９】
差分ディスクファイル５２は、有効なブロックＢＬＫ＿１，ＢＬＫ＿２及びＢＬＫ＿３を含む。つまり、マスタディスクファイル５１及び差分ディスクファイル５２は、仮想ディスク５０内の位置が同一のブロックＢＬＫ＿１，ＢＬＫ＿２及びＢＬＫ＿３を含む。このことは、サーバ管理者からの最初の差分生成指示後（マスタディスクファイル５１の生成後）において、新たなブロックＢＬＫ＿１，ＢＬＫ＿２及びＢＬＫ＿３をライトする操作（ライト操作）が発生したこと、つまり、マスタディスクファイル５１のブロックＢＬＫ＿１，ＢＬＫ＿２及びＢＬＫ＿３が更新（変更）されたことを表す。但し、本実施形態では、マスタディスクファイル５１のブロックＢＬＫ＿１，ＢＬＫ＿２及びＢＬＫ＿３は直接更新されない。
【００５０】
このようにＤＤＦ生成部１１２は、マスタディスクファイル５１のブロックＢＬＫ＿１，ＢＬＫ＿２及びＢＬＫ＿３を今回の更新が発生する前の状態に維持しながら、更新されたブロックのみを差分（差分データブロック）として含む差分ディスクファイル５２（つまり、別のディスクファイル）を生成する。より詳細に述べるならば、ＤＤＦ生成部１１２は、更新されたブロックＢＬＫ＿１，ＢＬＫ＿２及びＢＬＫ＿３のみを差分ブロックとして差分ディスクファイル５２に追加する。したがって、マスタディスクファイル５１のブロックＢＬＫ＿１，ＢＬＫ＿２及びＢＬＫ＿３（前者）と差分ディスクファイル５２のブロックＢＬＫ＿１，ＢＬＫ＿２及びＢＬＫ＿３（後者）とは一般に異なる。つまり、後者は、最初の差分生成指示後において実行されたライト操作により生ずる差分（差分ブロック）である。なお、本実施形態では、後者は、形式的には前者が更新されたブロックであるが、前者とは無関係に新たに生成される。
【００５１】
ここで、サーバ管理者から２回目の差分生成が指示されたものとする。この場合、ＤＤＦ生成部１１２は、ヘッダ（Ｈ）、ブロックアロケーションテーブル（ＴＢＬ）及びフッタ（Ｆ）から構成される差分ディスクファイル５３を生成する。その後、ブロックＢＬＫ＿２にデータをライトするためのライト操作が実行されたものとする。このとき、最新のブロックＢＬＫ＿２は、差分ディスクファイル５２に存在する。この場合、ＤＤＦ生成部１１２は、差分ディスクファイル５２のブロックＢＬＫ＿２を今回のライト操作（更新）が発生する前の状態に維持しながら、データがライトされた新たな（更新された）ブロックＢＬＫ＿２を差分として差分ディスクファイル５３に追加する。
【００５２】
続いて、ブロックＢＬＫ＿０及びＢＬＫ＿１からデータをリードするためのリード操作が順次実行されたものとする。図３の例では、ブロックＢＬＫ＿０は、マスタディスクファイル５１のみに存在する。この場合、矢印ａ１で示されるように、マスタディスクファイル５１のブロックＢＬＫ＿０からデータがリードされる。一方、ブロックＢＬＫ＿１は、マスタディスクファイル５１及び差分ディスクファイル５２にそれぞれ存在する。この場合、矢印ａ２で示されるように、差分ディスクファイル５２のブロックＢＬＫ＿１（つまり、最新のブロックＢＬＫ＿１）からデータがリードされる。
【００５３】
次に、ブロックＢＬＫ＿２にデータをライトするためのライト操作が再び実行されたものとする。このとき、最新のブロックＢＬＫ＿２は、差分ディスクファイル５３に存在する。この場合、ＤＤＦ生成部１１２は、図３において矢印ａ３で示されるように、差分ディスクファイル５２のブロックＢＬＫ＿２に更新データをライトする。図３は、このときの状態を示している。
【００５４】
その後、ブロックＢＬＫ＿３にデータをライトするためのライト操作が実行されるものとする。このとき、最新のブロックＢＬＫ＿３は、差分ディスクファイル５２に存在する。この場合、ＤＤＦ生成部１１２は、差分ディスクファイル５２のブロックＢＬＫ＿３を今回のライト操作が発生する前の状態に維持しながら、データがライトされた新たな（更新された）ブロックＢＬＫ＿３を、図３において矢印ａ４で示すように、差分として差分ディスクファイル５３に追加する。
【００５５】
次に、本実施形態におけるメタファイル生成部１２による典型的なメタファイル生成について、図４を参照して説明する。今、図３において矢印ａ４で示されるライト操作が実行されたことにより、仮想ディスクファイルの生成・更新が終了したものとする。するとメタファイル生成部１２は、マスタディスクファイル５１、差分ディスクファイル５２及び差分ディスクファイル５３に格納されている管理情報に基づいて、当該マスタディスクファイル５１、差分ディスクファイル５２及び差分ディスクファイル５３にそれぞれ格納されている仮想ディスクイメージのメタファイル１２１，１２２及び１２３を生成する。これにより配信部１３は、配信レディ状態となる。
【００５６】
以下、差分ディスクファイル５３に基づくメタファイル１２３の生成について説明する。差分ディスクファイル５３は、ヘッダ（Ｈ）と、ブロックアロケーションテーブル（ＴＢＬ）と、有効なブロックＢＬＫ＿２及びＢＬＫ＿３とを含む。ブロックＢＬＫ＿２はマップテーブルＭＡＰ＿２及びデータ部ＤＡＴＡ＿２を含み、ブロックＢＬＫ＿３はマップテーブルＭＡＰ＿３及びデータ部ＤＡＴＡ＿３を含む。
【００５７】
メタファイル生成部１２は、差分ディスクファイル５３から、ヘッダ（Ｈ）と、ブロックアロケーションテーブル（ＴＢＬ）と、ブロックＢＬＫ＿２及びＢＬＫ＿３内のマップテーブルＭＡＰ＿２及びＭＡＰ＿３とを取り出す。メタファイル生成部１２は、取り出されたヘッダ（Ｈ）と、ブロックアロケーションテーブル（ＴＢＬ）と、マップテーブルＭＡＰ＿２及びＭＡＰ＿３とを、差分ディスクファイル５３（仮想ディスクファイル）の構成を表す管理情報として、図４に示されるように、１つのメタファイル１２３にまとめる。つまり差分ディスクファイル５３は、ヘッダ（Ｈ）、ブロックアロケーションテーブル（ＴＢＬ）、マップテーブルＭＡＰ＿２及びＭＡＰ＿３を、管理情報（第２の管理情報）として有する。メタファイル１２３の末尾には、ヘッダ（Ｈ）と同一内容のフッタ（Ｆ）が付加される。なお、差分ディスクファイル５３内のフッタ（Ｆ）が用いられても構わない。
【００５８】
本実施形態において、差分ディスクファイル５３は第３世代の仮想ディスクファイルである。そこでメタファイル生成部１２は、メタファイル１２３に、当該メタファイル１２３の世代（より詳細には、当該メタファイル１２３の世代に対応する差分ディスクファイル５３の世代）を表すファイル名、例えば０００３．ＭＴＡを付与する。ファイル名０００３．ＭＴＡにおける数値０００３が、世代（世代番号）を表す。
【００５９】
同様にしてメタファイル生成部１２は、マスタディスクファイル５１が有する管理情報（第１の管理情報）を抽出することにより、当該管理情報（第１の管理情報）を含む、ファイル名が０００１．ＭＴＡのメタファイル１２１を生成する。またメタファイル生成部１２は、差分ディスクファイル５２が有する管理情報（第２の管理情報）を抽出することにより、当該管理情報（第２の管理情報）を含む、ファイル名が０００２．ＭＴＡのメタファイル１２２を生成する。以下の説明では、メタファイル１２１，１２２及び１２３を、それぞれメタファイル０００１．ＭＴＡ，０００２．ＭＴＡ及び０００３．ＭＴＡと称することもある。
【００６０】
次に、クライアント端末２の起動時の動作について、図５乃至図８を参照して説明する。図５はクライアント端末２の起動時の典型的な動作手順を説明するためのフローチャートの一部を示す図であり、図６は同フローチャートの他の一部を示す図である。図７は同フローチャートの更に他の一部を示す図であり、図８は同フローチャートの残りを示す図である。
【００６１】
クライアント端末２が起動されると、ハイパーバイザ２２が動作する。するとハイパーバイザ２２は制御仮想マシン２３を起動する。これにより制御仮想マシン２３は、制御ＯＳ２６に基づいて動作を開始する。
【００６２】
すると制御仮想マシン２３の要求部２３３は、配信サーバ１に仮想ディスクイメージの配信開始をネットワーク４経由で要求する（ステップＳ１）。この要求を受けて、配信サーバ１の配信部１３は、メタファイル生成部１２によって生成されたメタファイル１２１（０００１．ＭＴＡ）乃至１２３（０００３．ＭＴＡ）を、ネットワーク４経由でクライアント端末２に配信（転送）する。
【００６３】
制御仮想マシン２３の受信部２３１は、配信部１３から配信されたメタファイル１２１（０００１．ＭＴＡ）乃至１２３（０００３．ＭＴＡ）を受信する（ステップＳ２）。受信されたメタファイル１２１（０００１．ＭＴＡ）乃至１２３（０００３．ＭＴＡ）は、制御仮想マシン２３に割り当てられたメタファイル保存用の記憶領域に格納される。この記憶領域には、ＨＤＤ２１３の一部の領域が用いられる。
【００６４】
制御仮想マシン２３の解析部２３２は、受信されたメタファイル１２１（０００１．ＭＴＡ）乃至１２３（０００３．ＭＴＡ）を世代の逆順（世代番号の降順）にソートする（ステップＳ３）。これによりメタファイル１２１（０００１．ＭＴＡ）乃至１２３（０００３．ＭＴＡ）は、メタファイル１２３（０００３．ＭＴＡ）、メタファイル１２２（０００２．ＭＴＡ）、及びメタファイル１２１（０００１．ＭＴＡ）の順にソートされる（図９参照）。
【００６５】
次に解析部２３２は、処理（解析）されるべきメタファイルの世代（世代番号）を表す変数Ｍに、ソート（受信）されたメタファイルの総数（ここでは３）を代入する（ステップＳ４）。この時点における変数Ｍ＝３は、最新のメタファイル０００３．ＭＴＡの世代Ｍ（第Ｍ世代）に一致する。
【００６６】
次に解析部２３２は、メタファイルＭ．ＭＴＡ（ここではメタファイル０００３．ＭＴＡ）をオープンする（ステップＳ５）。すると解析部２３２は、メタファイルＭ．ＭＴＡからブロックアロケーションテーブルＴＢＬを取り出す（ステップＳ６）。次に解析部２３２は、ブロック識別子ＢＬＫＩＤとして０を設定する（ステップＳ７）。
【００６７】
次に解析部２３２は、ブロックアロケーションテーブルＴＢＬのエントリＴＢＬＥ＿ＢＬＫＩＤ（ここではエントリＴＢＬＥ＿０）を参照する（ステップＳ８）。エントリＴＢＬＥ＿ＢＬＫＩＤは、ブロック識別子ＢＬＫＩＤに対応付けられている。解析部２３２は、参照されたエントリＴＢＬＥ＿ＢＬＫＩＤに含まれているフラグ情報に基づいて、ブロック識別子ＢＬＫＩＤを持つブロックＢＬＫ＿ＢＬＫＩＤ（ここではブロックＢＬＫ＿０）が有効であるかを判定する（ステップＳ９）。
【００６８】
もし、ブロックＢＬＫ＿ＢＬＫＩＤが有効であるならば（ステップＳ９のＹｅｓ）、解析部２３２は、メタファイルＭ．ＭＴＡからブロックＢＬＫ＿ＢＬＫＩＤのマップテーブルＭＡＰ＿ＢＬＫＩＤ（ここではマップテーブルＭＡＰ＿０）を取り出す（ステップＳ１０）。次に解析部２３２は、マップテーブル（ビットマップテーブル）ＭＡＰ＿ＢＬＫＩＤを構成するビット列の長さ（つまりマップビット長）ｍを、パラメータＭＢＬとして設定する（ステップＳ１１）。
【００６９】
本実施形態では、マップテーブルＭＡＰ＿ＢＬＫＩＤのビット列のｉ番目（ｉ＝１，２，…）の位置をｉ−１と表記し、且つ、当該ｉ番目のビット（つまりビット位置がｉ−１のビット）をビットＢＴ（ｉ−１）と表記する。そこで解析部２３２は、マップテーブルＭＡＰ＿ＢＬＫＩＤのビットの位置を表す変数ＣｕｒＢｉｔに先頭ビット位置を表す０を代入する（ステップＳ１２）。
【００７０】
次に解析部２３２は、マップテーブルＭＡＰ＿ＢＬＫＩＤ（つまり、ブロックＢＬＫ＿ＢＬＫＩＤのマップテーブルＭＡＰ＿ＢＬＫＩＤ）のビットＢＴ（ＣｕｒＢｉｔ）を参照する（ステップＳ１３）。ビットＢＴ（ＣｕｒＢｉｔ）は、マップテーブルＭＡＰ＿ＢＬＫＩＤのビット列に含まれていて、且つ変数ＣｕｒＢｉｔ（ここではＣｕｒＢｉｔ＝０）によって指定される位置に存在するビットである。
【００７１】
次に解析部２３２は、参照されたビットＢＴ（ＣｕｒＢｉｔ）が１であるかを判定する（ステップＳ１４）。もし、ビットＢＴ（ＣｕｒＢｉｔ）が１であるならば（ステップＳ１４のＹｅｓ）、解析部２３２は、ビットＢＴ（ＣｕｒＢｉｔ）に対応付けられているブロックＢＬＫ＿ＢＬＫＩＤ（第１のブロック）内のセクタ（第１のセクタ）が有効であると判定する。
【００７２】
すると、無効化部２３２ａが起動される。無効化部２３２ａは、変数Ｍの示す世代（つまり第Ｍ世代）よりも古い世代のメタファイルが存在するならば、当該古い世代のメタファイルからブロックＢＬＫ＿ＢＬＫＩＤのマップテーブルＭＡＰ＿ＢＬＫＩＤを取り出す（ステップＳ１５）。ここで、変数Ｍは３であり、したがって第Ｍ世代（第３世代）よりも古い世代のメタファイルは、メタファイルＭ−１．ＭＴＡ（つまり、メタファイル０００２．ＭＴＡ）及びメタファイルＭ−２．ＭＴＡ（つまり、メタファイル０００１．ＭＴＡ）である。この場合、メタファイル０００２．ＭＴＡ及び０００１．ＭＴＡから、それぞれブロックＢＬＫ＿ＢＬＫＩＤのマップテーブルＭＡＰ＿ＢＬＫＩＤ（ここではブロックＢＬＫ＿０のマップテーブルＭＡＰ＿０）が取り出される。
【００７３】
次に無効化部２３２ａは、第Ｍ世代よりも古い世代のメタファイルから取り出されたマップテーブルＭＡＰ＿ＢＬＫＩＤのビットＢＴ（ＣｕｒＢｉｔ）を０にセットする（ステップＳ１６）。ここで、第Ｍ世代よりも古い世代のメタファイルにマップテーブルＭＡＰ＿ＢＬＫＩＤが含まれていない場合、無効化部２３２ａは、当該マップテーブルＭＡＰ＿ＢＬＫＩＤの全ビットが０であると見なしてステップＳ１６を実行する。なお、第Ｍ世代よりも古い世代の全てのメタファイルにマップテーブルＭＡＰ＿ＢＬＫＩＤが含まれていない場合、無効化部２３２ａがステップＳ１６をスキップしても良い。
【００７４】
上述したように本実施形態では、第Ｍ世代のメタファイルＭ．ＭＴＡから取り出されたブロックＢＬＫ＿ＢＬＫＩＤ（第１のブロック）のマップテーブルＭＡＰ＿ＢＬＫＩＤ（第１のマップ情報）のビットＢＴ（ＣｕｒＢｉｔ）が１の場合（ステップＳ１４のＹｅｓ）、無効化部２３２ａは、第Ｍ世代よりも古い世代のマップテーブルＭＡＰ＿ＢＬＫＩＤの相対位置が同一のビットＢＴ（ＣｕｒＢｉｔ）を０にセットする（ステップＳ１６）。即ち無効化部２３２ａは、第Ｍ世代よりも古い世代のマップテーブルＭＡＰ＿ＢＬＫＩＤ（第２のマップ情報）のビットＢＴ（ＣｕｒＢｉｔ）に対応付けられた、ブロックＢＬＫ＿ＢＬＫＩＤ（第２のブロック）内のセクタ（第２のセクタ）を、受信不要なセクタとして無効化する。そこで、受信不要なセクタを無効化するためのステップＳ１６の処理を、無効化処理と呼ぶ。
【００７５】
無効化部２３２ａがステップＳ１６（つまり無効化処理）を実行すると、解析部２３２は変数ＣｕｒＢｉｔを１インクリメントする（ステップＳ１７）。また解析部２３２は、ステップＳ１３で参照されたビットＢＴ（ＣｕｒＢｉｔ）が１でない場合にも（ステップＳ１４のＮｏ）、変数ＣｕｒＢｉｔを１インクリメントする（ステップＳ１７）。
【００７６】
解析部２３２は、インクリメントされた変数ＣｕｒＢｉｔが、パラメータＭＢＬ（つまり、マップテーブルＭＡＰ＿ＢＬＫＩＤのマップビット長）に等しいかを判定する（ステップＳ１８）。もし、等しくないならば（ステップＳ１８のＮｏ）、解析部２３２はステップＳ１３に戻る。ステップＳ１３において解析部２３２は、インクリメントされた変数ＣｕｒＢｉｔに基づいて、マップテーブルＭＡＰ＿ＢＬＫＩＤのビットＢＴ（ＣｕｒＢｉｔ）を参照する。このようにして、ステップＳ１３乃至Ｓ１８を含む処理が、インクリメントされた変数ＣｕｒＢｉｔがパラメータＭＢＬに等しくなるまで繰り返される。
【００７７】
やがて、インクリメントされた変数ＣｕｒＢｉｔがパラメータＭＢＬに等しくなったものとする（ステップＳ１８のＹｅｓ）。この場合、解析部２３２は、ブロックＢＬＫ＿ＢＬＫＩＤのマップテーブルＭＡＰ＿ＢＬＫＩＤの全ビットについて処理を完了したと判定する。すると解析部２３２は、ブロック識別子ＢＬＫＩＤを１インクリメントする（ステップＳ１９）。また、ブロックＢＬＫ＿ＢＬＫＩＤが有効でない場合にも（ステップＳ９のＮｏ）、解析部２３２はブロック識別子ＢＬＫＩＤを１インクリメントする（ステップＳ１９）。そして解析部２３２は、インクリメントされたブロック識別子ＢＬＫＩＤ（ここでは１）が最大（ここではブロック数の最大値Ｎ）であるかを判定する（ステップＳ２０）。
【００７８】
もし、インクリメントされたブロック識別子ＢＬＫＩＤが最大（Ｎ）でないならば（ステップＳ２０のＮｏ）、解析部２３２はステップＳ８に戻る。ステップＳ８において解析部２３２は、インクリメントされたブロック識別子ＢＬＫＩＤに基づいて、ブロックアロケーションテーブルＴＢＬ（メタファイルＭ．ＭＴＡから取り出されたブロックアロケーションテーブルＴＢＬ）のエントリＴＢＬＥ＿ＢＬＫＩＤ（ここではエントリＴＢＬＥ＿１）を参照する。このようにして、ステップＳ８乃至Ｓ２０を含む処理が、インクリメントされたブロック識別子ＢＬＫＩＤが最大（Ｎ）となるまで繰り返される。
【００７９】
やがて、インクリメントされたブロック識別子ＢＬＫＩＤが最大（Ｎ）となったものとする（ステップＳ２０のＹｅｓ）。この場合、解析部２３２は、メタファイルＭ．ＭＴＡから取り出されたブロックアロケーションテーブルＴＢＬで管理される全てのブロック識別子ＢＬＫＩＤ（ブロックＢＬＫ＿ＢＬＫＩＤ）について処理を完了したと判定する。すると解析部２３２は、変数Ｍを１ディクリメントする（ステップＳ２１）。そして解析部２３２は、ディクリメントされた変数Ｍ（ここでは２）が０であるかを判定する（ステップＳ２２）。
【００８０】
もし、ディクリメントされた変数Ｍが０でないならば（ステップＳ２２のＮｏ）、解析部２３２はステップＳ５に戻る。ステップＳ５において解析部２３２は、ディクリメントされた変数Ｍで示される世代（つまり、１つ前の世代）のメタファイルＭ．ＭＴＡ（ここではメタファイル００２．ＭＴＡ）をオープンする。このようにして、ステップＳ５乃至Ｓ２２を含む処理が、ディクリメントされた変数Ｍが０となるまで繰り返される。
【００８１】
やがて、ディクリメントされた変数Ｍが０となったものとする（ステップＳ２２のＹｅｓ）。この場合、解析部２３２は、配信サーバ１によりクライアント端末２に配信させるべき有効なブロックＢＬＫ＿ＢＬＫＩＤを検出（特定）するために、以下の処理を行う。
【００８２】
まず解析部２３２は、前述のステップＳ３乃至Ｓ１２に相当するステップＳ２３乃至Ｓ３２を次のように実行する。解析部２３２は、無効化部２３２ａによる無効化処理が行われたメタファイル１２１（０００１．ＭＴＡ）乃至１２３（０００３．ＭＴＡ）を世代の逆順にソートする（ステップＳ２３）。次に解析部２３２は、変数Ｍに、ソートされたメタファイルの総数（ここでは３）を代入する（ステップＳ２４）。
【００８３】
次に解析部２３２は、メタファイルＭ．ＭＴＡをオープンし（ステップＳ２５）、当該メタファイルＭ．ＭＴＡからブロックアロケーションテーブルＴＢＬを取り出す（ステップＳ２６）。次に解析部２３２は、ブロック識別子ＢＬＫＩＤとして０を設定する（ステップＳ２７）。
【００８４】
次に解析部２３２は、ブロック識別子ＢＬＫＩＤに基づいて、ブロックアロケーションテーブルＴＢＬのエントリＴＢＬＥ＿ＢＬＫＩＤ（ここではエントリＴＢＬＥ＿０）を参照する（ステップＳ２８）。解析部２３２は、参照されたエントリＴＢＬＥ＿ＢＬＫＩＤに含まれているフラグ情報に基づいて、ブロックＢＬＫ＿ＢＬＫＩＤが有効であるかを判定する（ステップＳ２９）。
【００８５】
もし、ブロックＢＬＫ＿ＢＬＫＩＤが有効であるならば（ステップＳ２９のＹｅｓ）、解析部２３２は、メタファイルＭ．ＭＴＡからブロックＢＬＫ＿ＢＬＫＩＤのマップテーブルＭＡＰ＿ＢＬＫＩＤを取り出す（ステップＳ３０）。次に解析部２３２は、マップテーブルＭＡＰ＿ＢＬＫＩＤを構成するビット列の長さ（マップビット長）を、パラメータＭＢＬとして設定する（ステップＳ３１）。また解析部２３２は、変数ＣｕｒＢｉｔに０を代入する（ステップＳ３２）。
【００８６】
次に解析部２３２は、メタファイルＭ．ＭＴＡから取り出されたブロックＢＬＫ＿ＢＬＫＩＤのマップテーブルＭＡＰ＿ＢＬＫＩＤを参照して、当該マップテーブルＭＡＰ＿ＢＬＫＩＤの全てのビットが０であるかを判定する（ステップＳ３３）。もし、ブロックＢＬＫ＿ＢＬＫＩＤのマップテーブルＭＡＰ＿ＢＬＫＩＤの少なくとも１ビットが０でないならば（ステップＳ３３のＮｏ）、解析部２３２は、ブロックＢＬＫ＿ＢＬＫＩＤは有効であると判定する。この場合、解析部２３２は要求部２３３を起動する。
【００８７】
すると要求部２３３は、配信サーバ１に、メタファイルＭ．ＭＴＡに対応する第Ｍ世代の仮想ディスクファイル（ここでは差分ディスクファイル５３）に格納されているブロックＢＬＫ＿ＢＬＫＩＤの配信を要求する（ステップＳ３４）。この要求を受けて、配信サーバ１の配信部１３は、第Ｍ世代の仮想ディスクファイル（差分ディスクファイル５３）内のブロックＢＬＫ＿ＢＬＫＩＤのデータを、ネットワーク４経由で制御仮想マシン２３の受信部２３１に配信（転送）する。
【００８８】
このように本実施形態では、ブロックＢＬＫ＿ＢＬＫＩＤのマップテーブルＭＡＰ＿ＢＬＫＩＤの少なくとも１ビットが０でない場合（ステップＳ３３のＮｏ）、要求部２３３は、当該ブロックＢＬＫ＿ＢＬＫＩＤ全体の配信を配信サーバ１に要求する。これにより、配信サーバ１の配信部１３からクライアント端末２に、有効なブロックＢＬＫ＿ＢＬＫＩＤのデータがブロック単位に配信される。このため本実施形態によれば、配信サーバ１の配信効率及びクライアント端末２の受信効率を向上できる。なお、要求部２３３が、マップテーブルＭＡＰ＿ＢＬＫＩＤのビット列に基づいて、値が１のビットに対応付けられたセクタ（つまり有効なセクタ）のデータのみの配信を要求しても良い。この場合、配信サーバ１の配信部１３からクライアント端末２に、有効なセクタのデータのみが配信（転送）されるため、ブロック全体の配信と比較して、データ転送量を削減できる。
【００８９】
制御仮想マシン２３の受信部２３１は、配信部１３から配信された第Ｍ世代の仮想ディスクファイル（差分ディスクファイル５３）内のブロックＢＬＫ＿ＢＬＫＩＤのデータを受信する（ステップＳ３５）。すると制御仮想マシン２３の保存部２３４は、第Ｍ世代よりも新しい世代のブロックＢＬＫ＿ＢＬＫＩＤのデータが既にディスク領域２５に保存されているかを判定する（ステップＳ３６）。ここでは、変数Ｍは３であるため、第Ｍ世代よりも新しい世代は存在しない。したがって、ブロックＢＬＫ＿ＢＬＫＩＤのデータはディスク領域２５に保存されていない（ステップＳ３６のＮｏ）。この場合、保存部２３４は、受信されたブロックＢＬＫ＿ＢＬＫＩＤのデータをディスク領域２５に保存する（ステップＳ３７）。
【００９０】
保存部２３４は、ディスクドライバを含んでおり、ステップＳ３７を実行する際には、受信されたブロックＢＬＫ＿ＢＬＫＩＤの仮想アドレスと物理アドレスとのマッピングを行う。保存部２３４は、マッピングされたディスク領域２５の物理アドレスに、受信されたブロックＢＬＫ＿ＢＬＫＩＤを保存する。ここで、マスタディスクファイル５１、差分ディスクファイル５２及び差分ディスクファイル５３が、後述するようにディスク領域２５内で１つの仮想ディスクファイルに組み合わされた（マージされた）ものとする。このような状態では、例えばゲスト仮想マシン２４のディスクドライバは、マッピングの情報に基づき、ディスク領域２５を仮想ディスクイメージが格納された仮想ディスクとして利用することができる。
【００９１】
さて、受信されたブロックＢＬＫ＿ＢＬＫＩＤのデータがディスク領域２５に保存されると（ステップＳ３７）、解析部２３２は、ブロック識別子ＢＬＫＩＤを１インクリメントする（ステップＳ４５）。また、ブロックＢＬＫ＿ＢＬＫＩＤが有効でない場合にも（ステップＳ２９のＮｏ）、解析部２３２はブロック識別子ＢＬＫＩＤを１インクリメントする（ステップＳ４５）。また、ブロックＢＬＫ＿ＢＬＫＩＤのマップテーブルＭＡＰ＿ＢＬＫＩＤの全てのビットが０である場合にも（ステップＳ３３のＹｅｓ）、解析部２３２はブロック識別子ＢＬＫＩＤを１インクリメントする（ステップＳ４５）。
【００９２】
このように本実施形態では、ブロックＢＬＫ＿ＢＬＫＩＤが有効でない場合（ステップＳ２９のＮｏ）、或いはブロックＢＬＫ＿ＢＬＫＩＤ（第２のブロック）のマップテーブルＭＡＰ＿ＢＬＫＩＤ（第２のマップ情報）の全てのビットが０である場合（ステップＳ３３のＹｅｓ）、当該ブロックＢＬＫ＿ＢＬＫＩＤの配信が要求されない。つまり、ステップＳ３４が実行されない。したがって本実施形態によれば、無効なブロックＢＬＫ＿ＢＬＫＩＤが配信サーバ１からクライアント端末２に配信（転送）される無駄を防止できる。無効なブロックＢＬＫ＿ＢＬＫＩＤは、無効セクタのみを有するブロックＢＬＫ＿ＢＬＫＩＤを含み、無効セクタは、ステップＳ１６で無効化されたセクタを含む。
【００９３】
解析部２３２は、ブロック識別子ＢＬＫＩＤを１インクリメントすると、当該インクリメントされたブロック識別子ＢＬＫＩＤが最大（Ｎ）であるかを判定する（ステップＳ４６）。もし、インクリメントされたブロック識別子ＢＬＫＩＤが最大（Ｎ）でないならば（ステップＳ４６のＮｏ）、解析部２３２はステップＳ２８に戻る。ステップＳ２８において解析部２３２は、メタファイルＭ．ＭＴＡから取り出されたブロックアロケーションテーブルＴＢＬのエントリＴＢＬＥ＿ＢＬＫＩＤ（ここではエントリＴＢＬＥ＿１）を参照する。このようにして、ステップＳ２８乃至Ｓ３７，Ｓ４５及びＳ４６を含む処理が、インクリメントされたブロック識別子ＢＬＫＩＤが最大（Ｎ）となるまで繰り返される。
【００９４】
やがて、インクリメントされたブロック識別子ＢＬＫＩＤが最大（Ｎ）となったものとする（ステップＳ４６のＹｅｓ）。この場合、解析部２３２は、メタファイルＭ．ＭＴＡから取り出されたブロックアロケーションテーブルＴＢＬで管理される全てのブロックＢＬＫ＿ＢＬＫＩＤについて処理を完了したと判定する。すると解析部２３２は、変数Ｍを１ディクリメントする（ステップＳ４７）。そして解析部２３２は、ディクリメントされた変数Ｍ（ここでは２）が０であるかを判定する（ステップＳ４８）。
【００９５】
もし、ディクリメントされた変数Ｍが０でないならば（ステップＳ４８のＮｏ）、解析部２３２はステップＳ２５に戻る。ステップＳ２５において解析部２３２は、ディクリメントされた変数Ｍで示される世代のメタファイルＭ．ＭＴＡ（ここではメタファイル００２．ＭＴＡ）をオープンする。
【００９６】
そして、後続のステップＳ２６乃至Ｓ３５が実行された結果、受信部２３１が、第Ｍ世代（ここでは第２世代）の仮想ディスクファイル（つまり差分ディスクファイル５２）のブロックＢＬＫ＿ＢＬＫＩＤを受信したものとする。このとき、第Ｍ世代（第２世代）よりも新しい世代（第３世代）のブロックＢＬＫ＿ＢＬＫＩＤのデータが既にディスク領域２５に保存されているものとする（ステップＳ３６のＹｅｓ）。このような場合、現在オープンされている第Ｍ世代のメタファイルＭ．ＭＴＡのマップテーブルＭＡＰ＿ＢＬＫＩＤ（つまり、受信ブロックＢＬＫ＿ＢＬＫＩＤのマップテーブルＭＡＰ＿ＢＬＫＩＤ）は、無効化処理済みの状態にある。
【００９７】
解析部２３２は、第Ｍ世代（第２世代）のメタファイルＭ．ＭＴＡに含まれている無効化処理済みのマップテーブルＭＡＰ＿ＢＬＫＩＤ（第４のマップ情報）のビットＢＴ（ＣｕｒＢｉｔ）を参照する（ステップＳ３８）。次に解析部２３２は、参照されたビットＢＴ（ＣｕｒＢｉｔ）が１であるかを判定する（ステップＳ３９）。もし、ビットＢＴ（ＣｕｒＢｉｔ）が１であるならば（ステップＳ３９のＹｅｓ）、解析部２３２は、ビットＢＴ（ＣｕｒＢｉｔ）に対応付けられている受信ブロックＢＬＫ＿ＢＬＫＩＤ内のセクタが有効であると判定する。
【００９８】
すると制御仮想マシン２３のマージ部２３５は、受信ブロックＢＬＫ＿ＢＬＫＩＤ（第４のブロック）から、ビットＢＴ（ＣｕｒＢｉｔ）に対応付けられているセクタ（第４のセクタ）のデータを取り出す（ステップＳ４０）。マージ部２３５の置換部２３５ａは、ディスク領域２５に保存されているブロックＢＬＫ＿ＢＬＫＩＤ（第３のブロック）に含まれ、且つビットＢＴ（ＣｕｒＢｉｔ）に対応付けられているセクタ（第３のセクタ）のデータを、取り出されたデータで書き換える（つまり置き換える）（ステップＳ４１）。また置換部２３５ａは、ディスク領域２５に保存されているブロックＢＬＫ＿ＢＬＫＩＤ（第３のブロック）に含まれているマップテーブルＭＡＰ＿ＢＬＫＩＤ（第３のマップ情報）のビットＢＴ（ＣｕｒＢｉｔ）を１にセットする（ステップＳ４２）。上述の置換部２３５ａの処理を置換処理と称する。
【００９９】
置換部２３５ａが置換処理（ステップＳ４１及びＳ４２）を実行すると、解析部２３２は変数ＣｕｒＢｉｔを１インクリメントする（ステップＳ４３）。また解析部２３２は、ステップＳ３８で参照されたビットＢＴ（ＣｕｒＢｉｔ）が１でない場合にも（ステップＳ３９のＮｏ）、変数ＣｕｒＢｉｔを１インクリメントする（ステップＳ４３）。
【０１００】
解析部２３２は、インクリメントされた変数ＣｕｒＢｉｔが、パラメータＭＢＬ（つまり、マップテーブルＭＡＰ＿ＢＬＫＩＤマップビット長）に等しいかを判定する（ステップＳ４４）。もし、等しくないならば（ステップＳ４４のＮｏ）、解析部２３２はステップＳ３８に戻る。ステップＳ３８において解析部２３２は、インクリメントされた変数ＣｕｒＢｉｔに基づいて、第Ｍ世代のメタファイルＭ．ＭＴＡに含まれている無効化処理済みのマップテーブルＭＡＰ＿ＢＬＫＩＤのビットＢＴ（ＣｕｒＢｉｔ）を参照する。このようにして、ステップＳ３８乃至Ｓ４４を含む処理が、インクリメントされた変数ＣｕｒＢｉｔがパラメータＭＢＬに等しくなるまで繰り返される。
【０１０１】
やがて、インクリメントされた変数ＣｕｒＢｉｔがパラメータＭＢＬに等しくなったものとする（ステップＳ４４のＹｅｓ）。この場合、解析部２３２は、ブロックＢＬＫ＿ＢＬＫＩＤのマップテーブルＭＡＰ＿ＢＬＫＩＤの全ビットについて処理を完了したと判定する。すると解析部２３２は、ステップＳ２９の判定がＮｏの場合、またはステップＳ３３の判定がＹｅｓの場合、またはステップＳ３７が実行された場合と同様に、ブロック識別子ＢＬＫＩＤを１インクリメントする（ステップＳ４５）。
【０１０２】
さて、ステップＳ２５乃至Ｓ４８を含む処理が、ステップＳ４７でディクリメントされた変数Ｍが０となるまで繰り返され、やがて、当該ディクリメントされた変数Ｍが０となったものとする（ステップＳ４８のＹｅｓ）。この場合、図５乃至図８のフローチャートに従う、クライアント端末２の起動時の処理は終了する。以上の処理により、マスタディスクファイル５１、差分ディスクファイル５２及び差分ディスクファイル５３が、ディスク領域２５内で１つの仮想ディスクファイルにマージされる。
【０１０３】
さて、マスタディスクファイル５１、差分ディスクファイル５２及び差分ディスクファイル５３が、ディスク領域２５内で１つの仮想ディスクファイルにマージされると、制御仮想マシン２３はゲスト仮想マシン２４を構築（生成）する。ゲスト仮想マシン２４はディスクドライバを有している。制御仮想マシン２３は、このディスクドライバを介して、ディスク領域２５を仮想ディスクイメージが格納された仮想ディスクとして認識する。これによりゲスト仮想マシン２４は、仮想ディスクに格納されている仮想ディスクイメージに含まれているゲストＯＳをゲストＯＳ２７として実行する。つまりゲスト仮想マシン２４は、ゲストＯＳ２７に基づいて動作する。またゲスト仮想マシン２４は、仮想ディスクに格納されている仮想ディスクイメージに含まれている各種ＡＰＰを、ゲストＯＳ２７に基づいて、ＡＰＰ２８として実行する。このとき制御仮想マシン２３は、制御ＯＳ２６に基づいて動作している。つまり制御仮想マシン２３及びゲスト仮想マシン２４は並行して動作する。
【０１０４】
なお上述の動作の後に、配信サーバ１のＤＤＦ生成部１１２が、差分ディスクファイル５３（＃差分２）の次の世代の差分ディスクファイル（＃差分２）を生成したものとする。この場合、配信サーバ１のメタファイル生成部１２は、当該差分ディスクファイル（＃差分２）に基づいて第４世代のメタファイル０００４．ＭＴＡを生成する。この状態で、クライアント端末２が再度起動されて、クライアント端末２の要求部２３３から配信サーバ１に仮想ディスクイメージの配信開始が要求されたものとする。この場合、配信サーバ１の配信部１３は、第４世代のメタファイル０００４．ＭＴＡのみを配信すれば良い。
【０１０５】
次に、上述した配信サーバ１の起動時の処理の具体例について図９及び図１０を参照して説明する。図９は、受信不要なセクタの無効化を説明するための図であり、図１０はセクタデータの置き換えを説明するための図である。
【０１０６】
まず、受信不要なセクタの無効化（つまり無効化処理）について、図９を参照して説明する。図９は、クライアント端末２の受信部２３１で受信されたメタファイル０００１．ＭＴＡ（１２１），０００２．ＭＴＡ（１２２）及び０００３．ＭＴＡ（１２３）の一部を示す。より詳細に述べるならば、図９は、メタファイル０００１．ＭＴＡ，０００２．ＭＴＡ及び０００３．ＭＴＡがいずれも有するマップテーブルＭＡＰ＿２及びＭＡＰ＿３を示す。ここでは、メタファイル０００１．ＭＴＡ，０００２．ＭＴＡ及び０００３．ＭＴＡが、世代順（世代番号の降順）に配置されている。図９の例では、最新世代（第３世代）のメタファイル０００３．ＭＴＡが最上段に、最も古い世代（第１世代）のメタファイル０００１．ＭＴＡが最下段に配置されている。
【０１０７】
メタファイル０００１．ＭＴＡ，０００２．ＭＴＡ及び０００３．ＭＴＡのマップテーブルＭＡＰ＿２及びＭＡＰ＿３は、マスタディスクファイル５１、差分ディスクファイル５２及び差分ディスクファイル５３のブロックＢＬＫ＿２及びＢＬＫ＿３に含まれている。ブロックの長さが４ＭＢ、セクタの長さが５１２Ｂである本実施形態では、ブロック内のセクタの数ｍは８，０００を超える。このため、マップテーブルのビットの数ｍも８，０００を超える。しかし図９の例は、説明の簡略化のために、マップテーブルＭＡＰ＿２及びＭＡＰ＿３のビットの数ｍが８である場合、つまりブロックＢＬＫ＿２及びＢＬＫ＿３内のセクタの数が８である場合を想定している。
【０１０８】
解析部２３２は、メタファイル０００１．ＭＴＡ，０００２．ＭＴＡ及び０００３．ＭＴＡのマップテーブルを、ブロック識別子ＢＬＫＩＤ毎に照合する。即ち解析部２３２は、メタファイル０００１．ＭＴＡ，０００２．ＭＴＡ及び０００３．ＭＴＡのマップテーブルＭＡＰ＿ＢＬＫＩＤ（ＢＬＫＩＤ＝０，１，…）を照合する。この照合は、ビット単位で行われる。そのため解析部２３２は、メタファイル０００１．ＭＴＡ，０００２．ＭＴＡ及び０００３．ＭＴＡのマップテーブルＭＡＰ＿ＢＬＫＩＤをビット単位で走査する。
【０１０９】
今、解析部２３２が、メタファイル０００１．ＭＴＡ，０００２．ＭＴＡ及び０００３．ＭＴＡのマップテーブルＭＡＰ＿２（つまり、ブロック識別子ＢＬＫＩＤが０００２のブロックＢＬＫ＿２のマップテーブルＭＡＰ＿２）の相対位置が同一のビット、例えば図９に示される矩形枠９１内のビットを照合するものとする。矩形枠９１に含まれている、最新（第３世代）のメタファイル０００３．ＭＴＡのマップテーブルＭＡＰ＿２のビットは、当該マップテーブルＭＡＰ＿２の先頭ビットＢＩＴ（０）であり、１である（ステップＳ１４のＹｅｓ）。この場合、無効化部２３２ａは、メタファイル０００３．ＭＴＡの世代（第３世代）よりも古い世代のメタファイル０００２．ＭＴＡ及び０００１．ＭＴＡの矩形枠９１内のビットＢＩＴ（０）を０にセットする（ステップＳ１６）。なお、メタファイル０００２．ＭＴＡ及び０００１．ＭＴＡの矩形枠９１内のビットＢＩＴ（０）は、ステップＳ１６の実行前に０にセットされている。この場合、必ずしもステップＳ１６が実行される必要はない。
【０１１０】
解析部２３２は、照合されるべきビットＢＴ（ＣｕｒＢｉｔ）の位置を、図９において矢印９２で示される各マップテーブルのビット列の方向に１ビットずつずらしながら（ステップＳ１７）、上述のビット単位の照合を実行する。図９の例では、メタファイル０００３．ＭＴＡ及び０００１．ＭＴＡのマップテーブルＭＡＰ＿２内の２番目のビットＢＴ（１）はいずれも１である。この場合、無効化部２３２ａは、メタファイル０００１．ＭＴＡのマップテーブルＭＡＰ＿２内の２番目のビットＢＩＴ（１）を、図９において矢印９３で示されるように０にセット（変更）する。
【０１１１】
同様に、図９の例では、メタファイル０００３．ＭＴＡ及び０００２．ＭＴＡのマップテーブルＭＡＰ＿２内の３番目のビットＢＩＴ（２）はいずれも１である。この場合、無効化部２３２ａは、メタファイル０００２．ＭＴＡのマップテーブルＭＡＰ＿２内の３番目のビットＢＩＴ（２）を、図９において矢印９４で示されるように０に変更する（ステップＳ１６）。また図９の例では、メタファイル０００３．ＭＴＡ，０００２．ＭＴＡ及び０００１．ＭＴＡのマップテーブルＭＡＰ＿２内の４番目のビットＢＩＴ（３）はいずれも１である。この場合、無効化部２３２ａは、メタファイル０００２．ＭＴＡ及び０００１．ＭＡＰのマップテーブルＭＡＰ＿２内の４番目のビットＢＩＴ（３）を、図９において矢印９５ａ及び９５ｂで示されるように０に変更する（ステップＳ１６）。
【０１１２】
また、図９の例では、メタファイル０００３．ＭＴＡ，０００２．ＭＴＡ及び０００１．ＭＴＡのマップテーブルＭＡＰ＿２の矩形枠９６内のビットＢＩＴ（７）（マップテーブルＭＡＰ＿２の最後のビット）は、それぞれ０，１及び１である。つまり、最新のメタファイル０００３．ＭＴＡのマップテーブルＭＡＰ＿２の矩形枠９６内のビットＢＩＴ（７）は０であるが、それよりも古い世代のメタファイル０００２．ＭＴＡ及び０００１．ＭＴＡの両マップテーブルＭＡＰ＿１のビットＢＩＴ（７）はいずれも１である。この場合、無効化部２３２ａは、最も古い世代のメタファイル０００１．ＭＴＡのマップテーブルＭＡＰ＿２の矩形枠９６内のビットＢＩＴ（７）を、図９において矢印９７で示されるように０に変更する（ステップＳ１６）。
【０１１３】
メタファイル０００３．ＭＴＡ，０００２．ＭＴＡ及び０００１．ＭＴＡのマップテーブルＭＡＰ＿３についても同様である。図９の例では、無効化部２３２ａは、楕円枠９８で囲まれたメタファイル０００２．ＭＴＡのマップテーブルＭＡＰ＿３の３番目のビットＢ（２）及び８番目のビットＢ（７）の各々を０に変更する。また無効化部２３２ａは、メタファイル０００１．ＭＴＡのマップテーブルＭＡＰ＿３の１番目、４番目、７番目及び８番目のビットの各々を０に変更する。
【０１１４】
次に、セクタデータの置き換えについて、図１０を参照して説明する。図１０の例は、メタファイル０００２．ＭＴＡのマップテーブルＭＡＰ＿２（１００）に、図９に示されたような無効化処理が施された場合を前提としている。
【０１１５】
まず、最新世代（第３世代）のメタファイル０００３．ＭＴＡのマップテーブルＭＡＰ＿２の少なくとも１ビット（ここでは４ビット）は、図９に示されるように０でない（ステップＳ３３のＮｏ）。そこで、クライアント端末２の要求部２３３から配信サーバ１に、図１０に示されるような最新世代（第３世代）のブロックＢＬＫ＿２（１０１）の配信が要求されたものとする（ステップＳ３４）。この場合、配信サーバ１の配信部１３からクライアント端末２に第３世代のブロックＢＬＫ＿２（１０１）のデータが配信され、当該第３世代のブロックＢＬＫ＿２（１０１）のデータがクライアント端末２の受信部２３１によって受信される（ステップＳ３５）。受信された第３世代のブロックＢＬＫ＿２（１０１）のデータは、ディスク領域２５に保存される（ステップＳ３７）。
【０１１６】
受信され且つ保存された第３世代のブロックＢＬＫ＿２（１０１）は、図１０に示されるように、マップテーブルＭＡＰ＿２と、データ部ＤＡＴＡ＿２とを含む。第３世代のブロックＢＬＫ＿２（１０１）のマップテーブルＭＡＰ＿２は、図９に示される、メタファイル０００３．ＭＴＡ（１２３）のマップテーブルＭＡＰ＿２と同一内容であり、“１１１１００００”である。この場合、第３世代のブロックＢＬＫ＿２（１０１）のデータ部ＤＡＴＡ＿２に含まれる有効セクタは、図１０において実線の矩形枠で囲まれたセクタ０乃至３である。
【０１１７】
その後、第２世代のメタファイル０００２．ＭＴＡに含まれていて、且つ無効化処理が施されたマップテーブルＭＡＰ＿２（１００）に基づいて、クライアント端末２の要求部２３３から配信サーバ１に、図１０に示されるような第２世代のブロックＢＬＫ＿２（１０２）の配信が要求されたものとする（ステップＳ３４）。すると、配信サーバ１の配信部１３からクライアント端末２に第２世代のブロックＢＬＫ＿２（１０２）のデータが配信される。クライアント端末２に配信された第２世代のブロックＢＬＫ＿２（１０２）のデータは、クライアント端末２の受信部２３１によって受信される（ステップＳ３５）。
【０１１８】
受信された第２世代のブロックＢＬＫ＿２（１０２）は、図１０に示されるように、マップテーブルＭＡＰ＿２と、データ部ＤＡＴＡ＿２とを含む。受信された第２世代のブロックＢＬＫ＿２（１０２）のマップテーブルＭＡＰ＿２の内容は、第２世代のメタファイル０００２．ＭＴＡ（１２２）に含まれていて、且つ無効化処理が施される前のマップテーブルＭＡＰ＿２（図９参照）のそれと同一である。つまり、受信された第２世代のブロックＢＬＫ＿２（１０２）のマップテーブルＭＡＰ＿２の内容は、“００１１００１１”である。この場合、受信された第２世代のブロックＢＬＫ＿２（１０２）のデータ部ＤＡＴＡ＿２に含まれる有効セクタは、図１０において実線の矩形枠で囲まれたセクタ２，３，６及び７である。
【０１１９】
一方、第２世代のメタファイル０００２．ＭＴＡ（１２２）に含まれていて、且つ無効化処理が施されたマップテーブルＭＡＰ＿２（１００）の内容は、“００００００１１”である。明らかなように、マップテーブルＭＡＰ＿２（１００）の３番目のビットＢＴ（２）及び４番目のビットＢＴ（３）は、無効化処理により、１から０に変更されている。しかし、マップテーブルＭＡＰ＿２（１００）の７番目のビットＢＴ（６）及び８番目のビットＢＴ（７）は、無効化処理の後も１に保持されている。このことは、第２世代よりも新しい第３世代のブロックＢＬＫ−２（１０１）に含まれていて、且つビットＢＴ（６）及びＢＴ（７）に対応するセクタ６及び７が、無効セクタであることを示す。このとき、第３世代のブロックＢＬＫ−２（１０１）は、既に受信部２３１によって受信されて、ディスク領域２５に保存されている。
【０１２０】
そこで置換部２３５ａは、第２世代のメタファイル０００２．ＭＴＡ（１２２）に含まれていて、且つ無効化処理が施されたマップテーブルＭＡＰ＿２（１００）に基づき、次のような置換処理を行う。ここで、今回受信された第２世代のブロックＢＬＫ＿２（１０２）に含まれているセクタ６及び７は、無効化処理が施されたマップテーブルＭＡＰ＿２（１００）のビットＢＴ（６）及びＢＴ（７）に図１０において矢印１０３及び１０４で示されるように対応付けられている。
【０１２１】
まず置換部２３５ａは、この第２世代のブロックＢＬＫ＿２（１０２）のセクタ６及び７のデータを、ディスク領域２５に保存されている第３世代のブロックＢＬＫ−２（１０１）のセクタ６及び７に、図１０において矢印１０５及び１０６で示されるように上書きする（ステップＳ４１）。つまり置換部２３５ａは、第２世代のブロックＢＬＫ＿２（１０２）のセクタ６及び７のデータで、第３世代のブロックＢＬＫ−２（１０１）のセクタ６及び７を置き換える（書き換える）。次に置換部２３５ａは、このセクタデータの置き換えが行われた第３世代のブロックＢＬＫ−２（１０１）のマップテーブルＭＡＰ＿２のビットＢＴ（６）及びＢＴ（７）を、図１０において矢印１０７及び１０８で示されるように、０から１に変更する（ステップＳ４２）。
【０１２２】
上述の説明から明らかなように、本実施形態は以下に列挙される効果を有する。
【０１２３】
（１）クライアント端末２はディスクイメージの一部のみを受信すれば良く、当該クライアント端末２の負荷が低減される。また配信サーバ１は、実データのみを転送すれば良いことから、転送時間が従来技術と比較して短縮される。また、それにより、配信サーバ１及びネットワーク４の負荷を低減することができる。
【０１２４】
（２）クライアント端末２においてディスクイメージを保存するのに用いられるディスク領域２５に必要な容量を、差分間のデータ結合を実行しなくても削減できる。また、結合操作に要するコストが削減される。
【０１２５】
（３）差分ディスクファイルの数が増えても、クライアント端末２は、重複したデータブロック、古いデータブロック、更には使用されないデータブロックを受信する必要がなく、したがって当該クライアント端末２の負荷が低減される。また、それにより、配信サーバ１及びネットワーク４の負荷を低減し、且つディスク領域２５に必要な容量を削減できる。
【０１２６】
（４）差分ディスクファイルの数が増えても、ディスクイメージを保存するのに、クライアント端末２は１つの仮想ディスク（ディスク領域２５）を用意するだけで良い。これにより、仮想ディスクのアクセス性能が劣化するのを防止できる。
【０１２７】
前記実施形態では、クライアント端末２の起動時に、制御仮想マシン２３が第１のマシンとして、マスタディスクファイル５１、差分ディスクファイル５２及び差分ディスクファイル５３を１つの仮想ディスクファイルにマージする処理を実行する。しかし、クライアント端末２の実マシン（つまり、非仮想マシン）が、制御ＯＳ２６（第１のＯＳ）に基づいて第１のマシンとして動作して、上述のマージ処理を実行しても良い。また、実マシンが、マージ処理の終了後に、制御ＯＳ２６から、ディスク領域２５に保存されている仮想ディスクファイル内のゲストＯＳ（第２のＯＳ）に切り替えて、クライアント端末２を再起動すれば良い。この場合、実マシンは、ゲストＯＳ（第２のＯＳ）に基づいて第２のマシンとして動作する。つまりクライアント端末２は、第１のマシンの動作から第２のマシンの動作に切り替えられる。
【０１２８】
なお、図１に示されるコンピュータシステム以外のシステムが、前記実施形態で適用されたような仕組み（つまり、マスタディスクファイル及び少なくとも１つの差分ディスクファイルに含まれている仮想ディスクイメージを処理するための仕組み）を利用することも可能である。例えば、この仕組みは、第１の論理ディスク（論理ユニット）に格納されているマスタディスクファイル及び少なくとも１つの差分ディスクファイルのデータを、バックアップのために第２の論理ディスクにコピーするシステムに応用可能である。
【０１２９】
以上説明した少なくとも１つの実施形態によれば、仮想ディスクを構成するマスタディスクイメージ、及び少なくとも１つの差分ディスクイメージを全て配信サーバからクライアント端末に配信することなく、当該クライアント端末において仮想ディスクを利用することができる、コンピュータシステム、クライアント端末及び仮想ディスクイメージを処理する方法を提供できる。
【０１３０】
本発明のいくつかの実施形態を説明したが、これらの実施形態は、例として提示したものであり、発明の範囲を限定することは意図していない。これら新規な実施形態は、その他の様々な形態で実施されることが可能であり、発明の要旨を逸脱しない範囲で、種々の省略、置き換え、変更を行うことができる。これら実施形態やその変形は、発明の範囲や要旨に含まれるとともに、請求の範囲に記載された発明とその均等の範囲に含まれる。
【要約】
実施形態によれば、コンピュータシステムは、配信サーバとクライアント端末とを具備する。配信サーバは、管理情報を含む少なくとも２つのメタファイルを生成して、これらのメタファイルをクライアント端末に配信する。管理情報は、仮想ディスクイメージを格納した仮想ディスクファイルを構成するマスタディスクファイル及び少なくとも１つの差分ディスクファイルから抽出される。クライアント端末は、配信されたメタファイルに基づいて有効なブロックを検出し、検出された有効なブロックの配信を配信サーバに要求する。クライアント端末は、配信された有効なブロックのデータを仮想ディスクイメージに組み合わせる。【図１】
0005692829.tif 000002
【図２】
0005692829.tif 000003
【図３】
0005692829.tif 000004
【図４】
0005692829.tif 000005
【図５】
0005692829.tif 000006
【図６】
0005692829.tif 000007
【図７】
0005692829.tif 000008
【図８】
0005692829.tif 000009
【図９】
0005692829.tif 000010
【図１０】
0005692829.tif 000011