JP2009538469A - パッチなどによるバーチャルマシンの更新 - Google Patents

Abstract

複数のバーチャルマシン（ＶＭ）の各々は、ライブラリからの取り出しとホストでのリスタートのために、停止した形態でライブラリに格納されている。リスタートされる各ＶＭは複数のソフトウェア構造体を含み、その各々は少なくとも最新状態にない可能性があるためソフトウェア更新を必要としている。最新状態にないＶＭを更新するために、そのＶＭは取り出され、メンテナンスホスト上でリスタートされ、各々の最新状態にないソフトウェア構造体は、必要とするソフトウェア更新を対応する更新ソースからパッチとして取得することによって更新されることが可能になっている。別の方法として、ＶＭはコンピューティングデバイスにマウントされており、マウントされたＶＭの構成コンポーネントは、その各々のソフトウェア構造体が最新状態にあるかどうかを判断するために検査され、各々の最新状態にないソフトウェア構造体は、必要とするソフトウェア更新を対応する更新ソースからパッチとして取得し、そのパッチをマウントされたＶＭに適用することによって更新される。

Description

本発明は、バーチャルマシンまたはそのコンポーネントをメンテナンスするためにバーチャルマシンまたはそのコンポーネントをパッチ（patch）によって更新することに関する。具体的には、本発明は、ライブラリ内などに置かれていて、オフラインでそのバーチャルマシンを更新するシステムおよび方法に関する。さらに具体的には、本発明は、バーチャルマシンをライブラリから配置（deploy）し、オンライン状態にしてパッチを適用するためのシステムおよび方法、またはファイルを収めたドライブのようにバーチャルマシンをマウントしてパッチを適用するためのシステムおよび方法に関する。

当然に理解されるように、バーチャルマシン（virtual machine VM）は、ハードウェアシステムをエミュレートする目的でコンピューティングデバイスなど（すなわち、ホスト）上で動作するソフトウェア構造体（software construct）などである。代表例として、必ずしもそうとは限らないが、ＶＭはアプリケーションなどであって、使用アプリケーション（use application）などをインスタンス化（instantiate）する一方で、それと同時に使用アプリケーションをホストデバイスから、またはホスト上の他のアプリケーションから隔離するためにホスト上で使用されることがある。１つの代表的な状況では、ホストは複数の配置されたＶＭを収容することができ、各ＶＭは、ホストから利用可能なリソースを介してなんらかの事前定義された機能（predetermined function）を実行している。特に、各ＶＭは、たとえバーチャル形態にあっても、どの点から見てもコンピューティングデバイスであることは事実であり、その使用アプリケーションから見ても、外部世界から見ても、バーチャルマシンはコンピューティングマシンとバーチャル形態の両方を表わしている。

代表例として、必ずしもそうとは限らないが、ホストはその各ＶＭを別々のパーティション（partition）に配置している。そのようなホストは、監視（overseer）アプリケーションまたは「ハイパバイザ（hypervisor）」の働きをするＶＭモニタと共に仮想化層（virtualization layer）を含んでいることがあり、そこでは仮想化層はホストの各ＶＭの監視側面を監視し、および／または管理しており、ＶＭと外部世界とを結ぶリンクとなり得る働きをしている。

ＶＭの顕著な特徴は、バーチャル構造体としてのＶＭを自由に停止し、リスタートできることであり、停止された場合にＶＭをファイルなどのように格納し、取り出せる（retrieve）ことである。具体的には、特定のコンピューティングデバイス上でインスタント化された場合のＶＭは、そのＶＭに関するすべてのデータ（その中にはＶＭに関する操作上のデータおよび状態情報が含まれている）を含んでいる限り適切にパッケージ化できる特異なソフトウェア構造体である。その結果、第１のホスト側のＶＭは、第１のホスト側でそのＶＭを停止し、停止したＶＭを第２のホスト側に移動し、移動したＶＭを第２のホスト側でリスタートなどをすることにより、第２のホスト側に移動し、または「マイグレーションする（migrate）」することができる。より一般的には、ＶＭは第１のプラットフォームから第２のプラットフォームに同じようにマイグレーションすることができ、これらのプラットフォームは、異なるホストや同じホストの異なる構成などを表わしている。後者のケースでは、当然に理解されるように、コンピューティングデバイスは、例えば、メモリが追加されたり、プロセッサが変更されたり、追加の入力デバイスが設けられたり、選択デバイスが除去されたりした場合には、異なる構成になっていることがある。

同じように、ＶＭのライブラリはメンテナンスされることがあり、その場合ライブラリ内の各ＶＭは停止され、適切なコマンドを受けて取り出され（retrieve）、リスタートされることが可能な格納されたＶＭになっている。従って、一例として、特定の処理シナリオ（processing scenario）を必要としているユーザなどは、ライブラリに置かれていて、その処理シナリオに対処する適切なＶＭを探すためにライブラリを調べることができ、そのＶＭが見つかった場合には、そのＶＭを取り出し、リスタートすることができる。同じように、ＶＭを配置したユーザなどは、任意の適切なポイントでＶＭを停止し、停止したＶＭを後の取り出しに備えて格納しておくことができ、ライブラリから取り出され格納されたＶＭは、リスタートさせて、処理を続けることができる。

当然に理解されるように、ＶＭはオペレーティングシステム、１つまたは複数の使用アプリケーション、およびその他の種々のソフトウェア構造体（「ソフトウェア構造体」と総称する）を含み、ＶＭの各ソフトウェア構造体は、パッチ（patch）などの形態で更新を随時必要とすることがある。以上から理解されるように、このような更新が行なわれるにはいくつかの理由があり、その中には、構造体を最新状態に保つこと、構造体に付加的機能を持たせること、構造体に関するセキュリティ問題を解決することなどがある。一般的に、構造体は、新規のパッチがあるかどうかを定期的に更新ソース（update source）に問い合わせる更新機能（update functionality）を含むことができ、そのようなパッチがあれば、更新機能はその新規パッチを取得し、ユーザなどの援助を受けて、および/または承認を得て、そのパッチをインストールする。

特に、停止され、ライブラリなどに格納されたＶＭはどのような処理も実行できないため、停止され、格納されたＶＭの構造体の更新機能は、必要に応じてパッチを取得し、インストールすることができない。以上から理解されるように、ＶＭが停止され、格納されている間に構造体を更新できないことは、更新の内容が比較的重要でない場合はその不都合は軽微で済むことがあるが、更新の内容が相対的に重要な場合は大きな問題となることがある。前者のケースでは、相対的に重要でない更新は、例えば、付加的な表示機能を提供する更新である可能性がある。後者のケースでは、相対的に重要な更新は、例えば、セキュリティ問題を取り扱う更新である可能性がある。

特に、相対的に重要である更新に関しては、ＶＭに更新を適用するのを不確定な時点まで待ち、その時点でＶＭを通常のようにライブラリから取り出し、リスタートすることが好ましくないことがある。従って、どのような更新でも、特にどのような重要な更新でも、ライブラリ内のＶＭに適用することを可能にするシステムおよび方法が望まれている。

上記の要求は、本発明による、コンピューティングデバイス上のバーチャルマシン（ＶＭ）のライブラリに関するシステムおよび方法を提供することによって満たされる。各ＶＭは、ライブラリからの取り出し（retrieval）とホストコンピューティングデバイス上でのリスタートに備えて、停止した形態でライブラリに格納されている。ライブラリ内の各ＶＭは、ホストコンピューティングデバイス上でリスタートされる場合にハードウェアシステムをエミュレートするソフトウェア構造体である。リスタートした各ＶＭは複数のソフトウェア構造体を含んでいる。ライブラリ内の各ＶＭの各ソフトウェア構造体は、少なくとも潜在的に最新状態にないため、ソフトウェア更新を必要としている。

本発明による方法では、ライブラリ内の各ＶＭについて、そのＶＭの各ソフトウェア構造体が最新状態にあるかどうかが定期的に判断される。ＶＭのいずれかのソフトウェア構造体が最新状態になければ、ライブラリ内において最新状態にないとのマークがそのＶＭに付けられる。ある時点で、取り出されてホストコンピューティングデバイス上でリスタートされるＶＭがライブラリから選択されたことが受け取られる。選択したＶＭにライブラリ内で最新状態にないとのマークが付けられていると、そのＶＭは、どのホストコンピューティングデバイスにもアクセスできないメンテナンスホストコンピューティングデバイスで更新され、そのあと更新したＶＭはホストコンピューティングデバイスでリスタートされる。

ＶＭを更新するために、そのＶＭはライブラリから取り出され、メンテナンスホストコンピューティングデバイス上でリスタートされ、リスタートしたＶＭの各最新状態にないソフトウェア構造体は、必要とするソフトウェア更新を対応する更新ソースから少なくとも１つのパッチとして取得することにより、メンテナンスホストコンピューティングデバイスで更新されることが可能になる。別の方法として、ＶＭはコンピューティングデバイスにマウントされ、マウントしたＶＭの構成コンポーネントは、そのＶＭの各ソフトウェア構造体が最新状態にあるどうかを判断するために検査され、各最新状態にないソフトウェア構造体は、必要とするソフトウェア更新を対応する更新ソースから少なくとも１つのパッチとして取得し、各パッチをマウントしたＶＭに適用することによって更新される。

上述した簡単な説明および以下の本発明の実施形態を記載した詳細な説明では、共に、その理解をより容易にするために添付図面が参照される。本発明を分かりやすく説明するために、図面には現在好ましいとされる実施形態が示されている。なお、当然に理解されるように、本発明は図示の正確な構成および手段に限定されるものではない。

（コンピュータ環境）
図１および以下の説明は、本発明および／またはその一部を実現することができる適当なコンピューティング環境の概要を簡単に説明することを目的としている。必ずしもその必要はないが、本発明は、プログラムモジュールのようにクライアントワークステーションやサーバなどのコンピュータによって実行されるコンピュータ実行可能命令の一般的なコンテキストにおいて説明される。一般的に、プログラムモジュールの中には、特定のタスクを実行する、または特定の抽象データ型を実現するルーチン、プログラム、オブジェクト、コンポーネント、データ構造などが含まれる。さらに、当然に理解されるように、本発明および／またはその一部は、その他のコンピュータシステム構成と共に実施されることもあり、その中には、ハンドヘルドデバイス、マルチプロセッサシステム、マイクロプロセッサベースまたはプログラマブルコンシューマエレクトロニクス、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータなどが含まれる。本発明は、通信ネットワークを介してリンクされたリモート処理デバイスによってタスクが実行されるような分散コンピューティング環境において実施されることもある。分散コンピューティング環境では、プログラムモジュールはローカルとリモートの両方のメモリストレージデバイスに置かれることがある。

図１に示すように、例示の汎用コンピューティングシステムは従来のパーソナルコンピュータ１２０などを含んでおり、その中には、処理ユニット１２１、システムメモリ１２２、およびシステムメモリを含む種々のシステムコンポーネントを処理ユニット１２１に結合するシステムバス１２３が含まれている。システムバス１２３は、いくつかのタイプのバス構造のうちのいずれにすることも可能であり、その中には、種々のバスアーキテクチャのいずれかを使用したメモリバスまたはメモリコントローラ、周辺バスおよびローカルバスが含まれる。システムメモリにはＲＯＭ（リードオンリメモリ）１２４およびＲＡＭ（ランダムアクセスメモリ）１２５が含まれる。起動時などに、パーソナルコンピュータ１２０内のエレメント間で情報を転送するのを支援する基本ルーチンで構成されたＢＩＯＳ（基本入出力システム）１２６は、ＲＯＭ１２４に格納されている。

パーソナルコンピュータ１２０は、ハードディスク（図示せず）との間で読み書きを行なうハードディスクドライブ１２７、取り外し可能磁気ディスク１２９との間で読み書きを行なう磁気ディスクドライブ１２８、およびＣＤ−ＲＯＭや他の光媒体などの取り外し可能光ディスク１３１との間で読み書きを行なう光ディスクドライブ１３０を装備していることもある。ハードディスクドライブ１２７、磁気ディスクドライブ１２８、および光ディスクドライブ１３０は、それぞれハードディスクドライブインタフェース１３２、磁気ディスクドライブインタフェース１３３および光ドライブインタフェース１３４によってシステムバス１２３に接続されている。これらのドライブおよびその関連コンピュータ可読媒体は、コンピュータ可読命令、データ構造、プログラムモジュールおよびその他のデータをパーソナルコンピュータ１２０のために格納する不揮発性ストレージとなっている。

本明細書に記載されている例示環境はハードディスク、取り外し可能磁気ディスク１２９および取り外し可能光ディスク１３１を採用しているが、当然に理解されるように、コンピュータによってアクセス可能であるデータを格納することができる他のタイプのコンピュータ可読媒体が例示動作環境で使用されることもある。このような他のタイプの媒体としては、磁気カセット、フラッシュメモリカード、デジタルビデオディスク、ベルヌーイ（Bernoulli）カートリッジ、ＲＡＭ（ランダムアクセスメモリ）、ＲＯＭ（リードオンリメモリ）などがある。

複数のプログラムモジュールをハードディスク、磁気ディスク１２９、光ディスク１３１、ＲＯＭ１２４またはＲＡＭ１２５に格納することができ、その中にはオペレーティングシステム１３５、１つまたは複数のアプリケーションプログラム１３６、その他のプログラムモジュール１４０およびプログラムデータ１３８が含まれている。ユーザは、キーボード１４０やポインティングデバイス１４２などの入力デバイスを介してコマンドおよび情報をパーソナルコンピュータに入力することができる。その他の入力デバイス（図示せず）としては、マイクロホン、ジョイスティック、ゲームパッド、サテライトディッシュ、スキャナなどがある。これらの入力デバイスおよびその他の入力デバイスは、システムバスに結合されたシリアルポートインタフェース１４６を介して処理ユニット１２１に接続されることが多いが、パラレルポート、ゲームポートまたはＵＳＢ（ユニバーサルシリアルバス）などの他のインタフェースによって接続されることもある。モニタ１４７または他のタイプのディスプレイデバイスも、ビデオアダプタ１４８などのインタフェースを介してシステムバス１２３に接続されている。モニタ１４７のほかに、パーソナルコンピュータは、スピーカやプリンタのような、他の周辺出力デバイス（図示せず）を装備しているのが一般的である。図１の例示システムは、ホストアダプタ１５５、ＳＣＳＩ（Small Computer System Interface）バス１５６、およびＳＣＳＩバス１５６に接続された外部ストレージデバイス１６２も装備している。

パーソナルコンピュータ１２０は、リモートコンピュータ１４９のような１つまたは複数のリモートコンピュータとの論理接続を使用したネットワーク構築環境で動作することができる。リモートコンピュータ１４９として可能なものに、別のパーソナルコンピュータ、サーバ、ルータ、ネットワークＰＣ、ピアデバイスまたはその他の共通ネットワークノードがあり、図１には、メモリストレージデバイス１５０だけが示されているが、パーソナルコンピュータ１２０に関連して上述したエレメントの多くまたはすべてを備えているのが一般的である。図１に示した論理接続としては、ＬＡＮ（ローカルエリアネットワーク）１５１とＷＡＮ（ワイドエリアネットワーク）１５２がある。このようなネットワーキング環境はオフィス、企業内コンピュータネットワーク（enterprise-wide computer network）、イントラネット、およびインターネットにおいて普及している。

ＬＡＮネットワーキング環境で使用される場合、パーソナルコンピュータ１２０はネットワークインタフェースまたはアダプタ１５３を介してＬＡＮ１５１に接続される。ＷＡＮネットワーキング環境で使用される場合、パーソナルコンピュータ１２０は、インターネットのようなワイドエリアネットワーク１５２上の通信を確立するためのモデム１５４や他の手段を備えるのが一般的である。モデム１５４は内蔵型と外付け型があり、どちらもシリアルポートインタフェース１４６を介してシステムバス１２３に接続されている。ネットワーク構築環境では、パーソナルコンピュータ１２０に関連して図示したプログラムモジュールまたはその一部は、リモートメモリストレージデバイスに格納されていることがある。以上から理解されるように、図示のネットワーク接続は例示であり、コンピュータ間の通信リンクを確立する他の手段が使用されることもある。

（ホストおよびバーチャルマシンライブラリ）
次に図２を参照して説明すると、図２に示すように、本発明はバーチャルマシン（ＶＭ）１２のライブラリ１０のコンテキストにおいて特定の適用性を有しており、各々のＶＭは、停止した形態で、さらには最も起り得るシャットダウンした形態でライブラリ１０に格納され、ライブラリ１０から取り出されて、ホスト１４上で適当な方法でリスタートされることが可能になっている。ここで当然に理解されるように、ライブラリ１０、ＶＭ１２、およびホストは、それが適切なものであれば、本発明の趣旨と範囲から逸脱しない限り、どのようなライブラリ、ＶＭおよびホストであってもよい。そのようなライブラリ、ＶＭおよびホストは公知であるか、あるいはこの分野では一般に明らかであるので、本明細書では、すでに知られている内容以上に詳しく説明することは省略する。

上述したように、ライブラリ１０内の各ＶＭ１２は、ホスト１４上でリスタートされた場合にハードウェアシステムをエミュレートするソフトウェア構造体などである。従って、ＶＭ１２は、使用アプリケーションなどをインスタンス化するためにホスト１４のリソースを使用する一方で、それと同時にその使用アプリケーションをホスト１４およびホスト１４上の他のアプリケーションから隔離することを可能にする。図示のように、ホスト１４は複数の配置されたＶＭ１２を収容することができ、そこでは各ＶＭ１２はなんらかの事前定義された機能を独立に実行する。例えば、ホスト１４上に配置されたＶＭ１２の少なくとも一部はデータサーバとして働くことがあり、そのＶＭ１２の少なくとも一部はホスト１４に結合されたネットワーク１６に対してネットワークサーバとして働くことがあり、そのＶＭ１２の少なくとも一部はメールサーバとして働くことがあり、そのＶＭ１２の少なくとも一部は低レベルの機能を実行することがあり、その中にはメンテナンス機能、データコレクション、ハードウェアモニタリング、エラー訂正、ファイル管理などが含まれる。特に、各ＶＭ１２は、たとえバーチャル形態にあっても、どの点から見てもコンピューティングマシンである。

ホスト１４自体は、デスクトップコンピュータ、ラップトップコンピュータ、ハンドヘルドコンピュータ、データアシスタント、メンテナンスコンピュータ、または１つまたは複数のＶＭ１２のホストとなるために必要な機能と能力を備えた他のタイプのコンピューティングデバイスなどのように、適当なコンピューティングデバイスとすることができる。なお、各ＶＭは、重要なメモリ、Ｉ／Ｏオペレーション、ストレージスペースおよびプロセッサ能力をホスト１４に要求することがあることを留意すると、また、ホスト１４は、任意のどの時点においても２、５、１０、２０またはそれ以上のＶＭ１２を収容するものと期待されることがあることを留意すると、ホスト１４は、そのようなＶＭ１２を実際に収容できる重要なパワーとリソースを有しているはずである。

ライブラリ１０は、本発明の趣旨と範囲を逸脱しない限り、どのような種類のコンピューティングデバイスにも置かれた、どのような種類のライブラリであっても構わない。例えば、ライブラリ１０は、ライブラリ１０のＶＭ１２のすべてを収容する十分な容量のサーバに置かれていることもあれば、そのような十分な容量の適当なディスクドライブに置かれているだけのこともある。後者のケースでは、ディスクドライバは、ホスト１４の一部であることさえある。なお、ここで注意すべきことは、複数のホスト１４が利用可能である場合には、かかるライブラリ１０は、かかるホスト１４から物理的に切り離されている可能性があるが、ホストに通信可能に結合されていることである。あるいは、ライブラリ１０自体はバーチャルマシン上に置かれていることもある。

上述したように、バーチャル構造体としての各ＶＭ１２は、自由に停止し、リスタートすることができ、停止時には、ファイルなどのようにライブラリ１０に格納し、そこから取り出すことができる。具体的には、各ＶＭ１２は、ソフトウェア構造体がそのＶＭ１２に関するすべてのデータ（その中にはＶＭ１２に関する操作上のデータと状態情報が含まれる）を含んでいる限り、適切にパッケージ化することができる特別なソフトウェア構造体である。従って、第１のホスト１４側のＶＭ１４は、第１のホスト１４側のＶＭ１２を停止し、停止したＶＭ１２を第２のホスト１４に移動し、移動したＶＭ１２を第２のホスト１４側でリスタートするだけで、ホスト１４間で移動し、または「マイグレーション」することをできる。

典型的な例として、必ずしもその必要はないが、図２のシステムは、適当なコンピューティングデバイスなどで動作するＶＭコントローラ１８を含んでいる。主として、当然に理解されるように、このＶＭコントローラ１８は格納されたＶＭ１２をライブラリ１０から取り出し、取り出したＶＭ１２を特定のホスト１４上でリスタートすることによってそのＶＭ１２を配置するように動作すると共に、配置したＶＭ１２を停止し、停止したＶＭ１２をライブラリ１０に格納するように動作し、これらはすべてユーザなどの然るべき指示に従って行なわれる。従って、特定の処理シナリオを必要とするユーザなどは、そのシナリオに対処する適切なＶＭ１２を探すためにＶＭコントローラ１８を介してライブラリ１０を調べることができ、そのＶＭ１２が見つかると、ユーザはＶＭコントローラ１８を使用してそのＶＭ１２を取り出し、リスタートすることができる。同様に、ＶＭを配置したユーザなどは、いずれかの適当な時点でそのＶＭを停止し、停止したＶＭをその後の取り出しに備えて格納しておくことができ、格納されたＶＭがライブラリから取り出されたとき、処理を続行するためにリスタートすることができる。ここで注意すべきことは、ＶＭコントローラ１８は、本発明の趣旨と範囲から逸脱しない限り、適切であればどのようなＶＭコントローラでも構わないことである。このようなＶＭコントローラ１８は公知であるか、あるいはこの分野では一般に明らかであるので、本明細書では、すでに知られている内容以上に詳しく説明することは省略する。

（パッチによる更新）
上述したように、ライブラリ１０内の各ＶＭ１２は、物理的な意味ではそれ自体がソフトウェア構造体であるが、バーチャルの意味ではＶＭ１２自体は複数のソフトウェア構造体を含み、その中にはレジストリなどを備えたオペレーティングシステム、１つまたは複数の使用アプリケーション、種々のデバイスドライバとデバイスライブラリなどが含まれている（すなわち、「ソフトウェア構造体」と総称する）。特に、どのＶＭ１２の場合も、その各ソフトウェア構造体はパッチなどの形態をしたソフトウェア更新を随時必要とすることがある。パッチ２０などの形態をしたソフトウェア更新は公知であるか、あるいはこの分野では一般に明らかであるので、本明細書では、すでに知られている内容以上に詳しく説明することは省略する。当然に理解されるように、このような更新が行なわれる理由にはいくつかあり、その中には、ソフトウェア構造体を最新状態に保つこと、構造体に付加的機能をもたせること、構造体に対するセキュリティ問題に対処すること、などが含まれる。従って、本発明は、どのような特定のソフトウェア更新やパッチ２０（以下「パッチ２０」という）またはそれらのタイプとも関係なく動作することが可能である。

一般的に、パッチ２０は、ＶＭ１２のソフトウェア構造体のように、少なくとも部分的に自動化された方法でソフトウェア構造体に適用することができる。そのために、構造体には、新規パッチ２０を探すために１つまたは複数の更新ソース２２を定期的に調べる更新機能が含まれていることがあり、新規パッチがあれば、更新機能は各新規パッチ２０を更新ソース２２から取得し、おそらくはユーザなどの援助を受けておよび／または承諾を得てその更新をインストールしている。構造体と関連のある更新機能は公知であるか、あるいはこの分野では一般に明らかであるので、本明細書ではこれ以上詳しく説明することは省略する。従って、本発明は、どのような特定の更新機能とも関係なく動作することが可能である。

なお、以上から理解されるように、ＶＭ１２のどの特定の構造体の場合も、その更新機能が動作するためには、ＶＭ１２自体が配置されて、動作していることが必要である。言い換えると、停止され、ライブラリなどに格納されたＶＭはどのような処理も実行することができないので、停止され、格納されたＶＭの構造体の更新機能はパッチ２０を更新ソース２２から取得し、それをインストールすることができない。そこで、以上を要約すると、ライブラリ１０に置かれているＶＭ１２のソフトウェア構造体は更新することができない。その結果、ソフトウェア構造体は、ＶＭ１２がライブラリ１０から取り出されて、ホスト１４上でリスタートされるまで更新を待たされることになる。

なお、以上から理解されるように、ライブラリ１０に格納されたＶＭ１２の特定の構造体に対してセキュリティ更新のような重要な更新が出される場合も十分に起り得る。そのようなことが起ると、ＶＭ１２は、セキュリティ更新が防止しようとしているセキュリティ脅威から保護されないので、そのような未保護状態にある構造体はどのホスト１４にも配置されるべきではない。具体的には、特にネットワーク１６のような、どのネットワークにもホスト１４がアクセスできる場合には、未保護のＶＭ１２を配置すると、ネットワーク１６、ホスト１４、ネットワーク１６上の他のホスト１４などのセキュリティ違反を含む、多数の重大なセキュリティ事態のいずれかが発生するのを許容する可能性がある。

従って、引き続き図２を参照して説明すると、本発明の一実施形態において、ＶＭコントローラ１８はＶＭ１２をメンテナンスホスト１４ｍに配置し、そこではメンテナンスホスト１４ｍは適当な通信カップリングを介して更新ソース２２にアクセスできるが、ネットワーク１６や他の方法を介してどのホスト１４にもアクセスできないようになっている。具体的には、図３を参照して説明すると、ＶＭコントローラ１８は、１つまたは複数のＶＭ１２の各々を更新のために定期的にメンテナンスホスト１４ｍに配置するようにスケジューラ２４（図２）に基づいて動作することができる（ステップ３０１）。以上から理解されるように、メンテナンスホスト１４ｍでは、配置された各ＶＭ１２のソフトウェア構造体の１つまたは複数は、適当な方法で取得されたパッチ２０で更新され（ステップ３０５）、更新されたＶＭ１２は停止され、更新した形態でライブラリ１０に格納され、ホスト１４での次の配置を待つことになる（ステップ３０７）。配置されたＶＭ１２のソフトウェア構造体は、ソフトウェア構造体によってトリガされたプロセスに基づいて更新されることもあれば（ステップ３０３ａ）、ＶＭコントローラ１８によってトリガされたプロセスに基づいて更新されることもある（３０３ｂ）。後者のケースでは、ＶＭコントローラ１８は適当な公知インタフェースを使用して、上記トリガリングを行なうことがある。

理解されるように、スケジューラ２４は本発明の趣旨と範囲から逸脱しない限り、それが適切であれば、どのようなスケジューラでもよく、そのようなものとして、例えば、ＶＭコントローラ１８の一部であって、適切な基準に基づいて更新するように各ＶＭ１２をスケジュールできるタスクスケジューラがある。例えば、スケジューラ２４は、毎週１回、２週ごとに１回といったように、ＶＭコントローラ１８が各ＶＭ１２をメンテナンスホスト１４ｍに配置するように動作することができる。そのようなスケジューラおよびそのようなスケジューリングは公知であるか、あるいはこの分野では一般に明らかであるので、本明細書ではこれ以上詳しく説明することは省略する。また、以上から明らかであるように、メンテナンスホスト１４ｍは、メンテナンスホストが、配置された各ＶＭ１２を他のホスト１４から隔離するか、さもなければ隔絶し、更新ソース２２へのアクセスだけを供することを条件に、本発明の趣旨と範囲から逸脱しない限り、それが適切であれば、どのようなホストでも構わない。

以上から理解されるように、図２のスケジューラ２４に基づいて図３に図示したように動作するＶＭコントローラ１８は、ＶＭ１２に更新が必要であるかどうかに関係なく各ＶＭ１２がメンテナンスホスト１４ｍに配置されている点で若干非効率である。従って、本発明の一実施形態では、図４に示すように、スケジュールした各ＶＭ１２を最初にメンテナンスホスト１４ｍに配置するのではなく、ＶＭコントローラ１８はメンテナンスホスト１４ｍ、ライブラリ１０などのコンピューティングデバイスにＶＭ１２をマウントして、ＶＭ１２の構成コンポーネントが検査されることを可能にしている（ステップ４０１）。ＶＭ１２を検査するためにＶＭ１２をマウントすることは公知であるか、あるいはこの分野では一般に明らかであるので、本明細書ではこれ以上詳しく説明することは省略する。従って、本発明の趣旨と範囲から逸脱しない限り、どのような形態のマウンティングでも行なうことが可能である。例えば、ＶＭ１２は、複数のファイルなどを収めたディスクドライブのようにその構成コンポーネントが検査されるようにマウントすることができる。

マウントされたあと、ＶＭコントローラ１８は、ＶＭ１２の種々の構造体が最新状態にあるかどうかを判断するために、ＶＭ１２のさまざまな部分を検査することができる（ステップ４０３）。具体的には、以上の説明から理解されるように、この判断は、マウントしたＶＭ１２からの情報、すなわち、ファイルのバージョン、レジストリ情報、および１つまたは複数のパッチ２０による更新が必要かどうかの判断のために一般に使用されるその他のデータを調べることによって、ＶＭコントローラ１８によって行うことができる。１つまたは複数のパッチ２０が実際に必要であると判断された場合、ＶＭコントローラ１８は、各パッチ２０を適切な更新ソース２２から取得し（ステップ４０５）、そのパッチをＶＭ１２に適用することを実行する。特に、このパッチ２０はマウントされたＶＭ１２に適用されることも（ステップ４０７ａ）、必要ならば、メンテナンスホスト１４ｍに配置されたＶＭ１２に適用されることもある（ステップ４０７ｂ）。

前者のケースでは、ステップ４０７ａにおけるように、ＶＭコントローラ１８は、マウントされたＶＭ１２上のファイル置換（file substitution）、ファイル修正（file modifications）などによって各パッチ２０を適用することになる。レジストリ修正が必要ならば、その修正は、マウントされたＶＭ１２上のレジストリハイブ（registry hive）ファイルを見つけ、見つけたレジストリハイブをメンテナンスホスト１４ｍ、ライブラリ１０などにロードし、ロードしたハイブを修正し、修正したハイブを、見つかった対応するハイブの置換として保存することにより行なわれる。後者のケースでは、ステップ４０７ｂにおけるように、ＶＭコントローラ１８は最初にＶＭ１２をメンテナンスホスト１４ｍなどからディスマウント（dismount）し、次にそのＶＭ１２をそのメンテナンスホスト１４ｍ上に配置することになる。最後に、ＶＭ１２が必要とするすべてのパッチ２０で更新されたあと、ＶＭコントローラ１８は、ＶＭ１２をメンテナンスホスト１４ｍなどからディスマウントし、ディスマウントしたＶＭ１２をライブラリ１０に格納するか（ステップ４０９ａ）、あるいは配置したＶＭ１２を停止し、停止したＶＭ１２をライブラリ１０に格納する（ステップ４０９ｂ）ことによって、更新したＶＭ１２をライブラリ１０に戻すことができる。

以上から理解されるように、図４に示すように動作するＶＭコントローラ１８は、各ＶＭ１２がユーザなどによって使用されるかどうかに関係なく各ＶＭ１２が更新されている点で、時に非効率になることがある。すなわち、各ＶＭ１２は、ＶＭ１２が配置されていなくても極めてまれに更新される。従って、本発明の一実施形態では、図５に示すように、最新状態にない各ＶＭ１２を実際に更新するのではなく、ＶＭコントローラは最新状態にないとのマークをＶＭ１２に付け、ＶＭ１２が実際に更新されるのはＶＭ１２が実際に配置される前のみである。具体的には、前述したように、ＶＭコントローラ１８は、例えば、ステップ４０１におけるように、ＶＭ１２をマウントし、ＶＭ１２の構成コンポーネントが検査されるのを可能にすることによって、スケジュールされた各ＶＭ１２が最新状態にあるかどうかを判断する（ステップ５０１）。なお、ここでは、最新状態にない各ＶＭ１２は、例えば、ライブラリ１０内のＶＭ１２に適当な注記（notation）を付けることによって、適当な方法で最新状態にないとのマークが付けられている。従って、配置される各ＶＭ１２をライブラリ１２から選択したとき（ステップ５０５）、ＶＭコントローラ１８は、選択したＶＭ１２に最新状態にないとのマークが付けられているかどうかを最初にチェックする（ステップ５０７）。最新状態になければ、ＶＭ１２は、ステップ３０１とそれ以降またはステップ４０１とそれ以降のように最初にメンテナンスホスト１４ｍに配置またはマウントされて更新され（ステップ５０９）、最新状態にないＶＭ１２は選択したユーザによる使用に備えてホスト１４に配置される（ステップ５１１）。

（結論）
本発明に関連して実行されるプロセスを実施するために必要なプログラミングは比較的理解しやすいので、プログラミング関係の分野では一般に明らかであるはずである。従って、本明細書にはプログラミングは添付されていない。本発明の趣旨と範囲から逸脱しない限り、どのようなプログラミングを使用しても本発明を実施することが可能である。

上述してきた説明から明らかであるように、本発明は、ライブラリ１０に格納されたＶＭ１２に更新を適用するための新規かつ有用なシステムおよび方法から構成されている。当然に理解されるように、上述してきた実施形態はその新規概念から逸脱しない限り、種々の変更が可能である。従って、当然に理解されるように、本発明は本明細書に開示した特定の実施形態に限定されるものではなく、請求項に記載された本発明の趣旨と範囲に属する種々の変更を包含するものである。

本発明の側面および／またはその一部を取り入れることが可能な汎用コンピュータシステムを示すブロック図である。 バーチャルマシン（ＶＭ）のライブラリを備え、バーチャルマシンの各々をメンテナンスホストでリスタートするか、あるいはコンピューティングデバイスにマウントして、本発明の実施形態に従って更新することを可能にするシステムを示すブロック図である。 本発明の一実施形態に従って図２のシステムに関連して実行される主要ステップを示すフロー図である。 本発明の一実施形態に従って図２のシステムに関連して実行される主要ステップを示すフロー図である。 本発明の一実施形態に従って図２のシステムに関連して実行される主要ステップを示すフロー図である。

Claims (20)

1. コンピューティングデバイス上のバーチャルマシン（ＶＭ）のライブラリに関する方法であって、各ＶＭは、前記ライブラリからの取り出しとホストコンピューティングデバイス上でのリスタートに備えて前記ライブラリ内に停止した形態で格納されており、前記ライブラリ内の各ＶＭは、前記ホストコンピューティングデバイス上でリスタートされたときハードウェアシステムをエミュレートするソフトウェア構造体であり、各リスタートされたＶＭは複数の前記ソフトウェア構造体を含んでおり、前記ライブラリ内の各ＶＭの少なくとも１つの前記ソフトウェア構造体は最新状態にないためソフトウェア更新を必要としている該方法は、前記ライブラリ内の各ＶＭについて、
   前記ＶＭを定期的に前記ライブラリから取り出し、取り出したＶＭを、少なくとも１つの更新ソースにアクセスできるが、どのホストコンピューティングデバイスにもアクセスできないメンテナンスホストコンピューティングデバイス上でリスタートするステップと、
   リスタートした前記ＶＭの各最新状態にないソフトウェア構造体が、必要とするソフトウェア更新を対応する前記更新ソースから少なくとも１つのパッチとして取得することによって前記メンテナンスホストで更新されるのを可能にするステップと、
   更新した前記ＶＭを停止し、前記ホストコンピューティングデバイス上で取り出され、リスタートされるのを待つために、停止した前記ＶＭを前記ライブラリに格納しておくステップとを含むことを特徴とする方法。
2. リスタートした前記ＶＭの前記各最新状態にないソフトウェア構造体が更新されるように、外部からトリガするステップを含むことを特徴とする請求項１に記載の方法。
3. リスタートした前記ＶＭの前記各最新状態にないソフトウェア構造体が更新されるように、内部で自身をトリガするステップを含むことを特徴とする請求項１に記載の方法。
4. ＶＭコントローラは、格納されたＶＭを前記ライブラリから取り出し、取り出した前記ＶＭを前記メンテナンスホストコンピューティングデバイス上でリスタートすると共に、リスタートした前記ＶＭを停止し、停止した前記ＶＭを前記ライブラリに格納するように動作し、該方法は、前記ＶＭコントローラによって実行されることを特徴とする請求項１に記載の方法。
5. 前記ＶＭコントローラは、スケジューラに基づいて前記ライブラリの各ＶＭを更新のために定期的に前記メンテナンスホストコンピューティングデバイスに配置するように動作することを含むことを特徴とする請求項４に記載の方法。
6. 前記ライブラリの各ＶＭを更新のために前記メンテナンスホストコンピューティングデバイスに定期的に配置するようにスケジューラに基づいて動作することを含むことを特徴とする請求項１に記載の方法。
7. コンピューティングデバイス上のバーチャルマシン（ＶＭ）のライブラリに関する方法であって、各ＶＭは、前記ライブラリからの取り出しとホストコンピューティングデバイス上でのリスタートに備えて前記ライブラリに停止した形態で格納されており、前記ライブラリ内の各ＶＭは、前記ホストコンピューティングデバイス上でリスタートされたときハードウェアシステムをエミュレートするソフトウェア構造体であり、各リスタートされた前記ＶＭは複数の前記ソフトウェア構造体を含んでおり、前記ライブラリ内の各ＶＭの少なくとも１つの前記ソフトウェア構造体は最新状態にないためソフトウェア更新を必要としている該方法は、前記ライブラリ内の各ＶＭについて、
   前記ＶＭを前記ライブラリから定期的に取り出し、取り出したＶＭを、どの前記ホストコンピューティングデバイスにもアクセスできないコンピューティングデバイスにマウントするステップと、
   前記ＶＭの各ソフトウェア構造体が最新状態にあるかどうかを判断するためにマウントした前記ＶＭの構成コンポーネントを検査し、各最新状態にないソフトウェア構造体について、必要とするソフトウェア更新を対応する更新ソースから少なくとも１つのパッチとして取得し、各パッチをマウントしたＶＭに適用することによって前記各最新状態にないソフトウェア構造体をメンテナンスホストコンピューティングデバイス上で更新するステップと、
   前記ホストコンピューティングデバイス上で更新した前記ＶＭが取り出され、リスタートされるのを待つために、更新した前記ＶＭを前記ライブラリに格納しておくステップとを含むことを特徴とする方法。
8. 前記コンピューティングデバイスにマウントされたままで、前記最新状態にないソフトウェア構造体に各パッチを適用するステップを含み、該方法は、更新した前記ＶＭを前記メンテナンスホストコンピューティングデバイスからディスマウントしたあと、更新した前記ＶＭを前記ライブラリに格納するステップをさらに含むことを特徴とする請求項７に記載の方法。
9. 前記メンテナンスホストコンピューティングデバイス上でリスタートされたときの前記最新状態にないソフトウェア構造体に各パッチを適用すること、および、前記メンテナンスホストコンピューティングデバイスから前記ＶＭをディスマウントしたあと、前記メンテナンスホストコンピューティングデバイス上で前記ＶＭをリスタートすることを含み、該方法は、更新した前記ＶＭをメンテナンスホストコンピューティングデバイスで停止したあと、更新した前記ＶＭを前記ライブラリに格納することをさらに含むことを特徴とする請求項７に記載の方法。
10. 取り出した前記ＶＭを前記コンピューティングデバイスにマウントして、マウントした前記ＶＭの構成コンポーネントが、複数のファイルを収めたディスクドライブのように検査されることを可能にすることを含むことを特徴とする請求項７に記載の方法。
11. マウントした前記ＶＭの前記各ソフトウェア構造体が最新状態にあるかどうかを判断するために前記ＶＭの構成コンポーネントを検査することは、ファイルバージョンとレジストリ情報を含む、マウントした前記ＶＭからの情報をレビューすることを含むことを特徴とする請求項７に記載の方法。
12. ＶＭコントローラは、格納した前記ＶＭを前記ライブラリから取り出し、取り出したＶＭを前記コンピューティングデバイスにマウントするように動作すると共に、更新した前記ＶＭを前記ライブラリに格納するように動作し、該方法は、前記ＶＭコントローラによって実行されることを特徴とする請求項７に記載の方法。
13. 前記ＶＭコントローラは、スケジューラに基づいて前記ライブラリの各ＶＭを更新のために定期的に前記メンテナンスホストコンピューティングデバイスに配置するように動作することを含むことを特徴とする請求項１２に記載の方法。
14. 前記ライブラリの各ＶＭを、更新のために前記メンテナンスホストコンピューティングデバイスに定期的に配置するようにスケジューラに基づいて動作することを含むことを特徴とする請求項１に記載の方法。
15. コンピューティングデバイス上のバーチャルマシン（ＶＭ）のライブラリに関する方法であって、各ＶＭは、前記ライブラリからの取り出しとホストコンピューティングデバイス上でのリスタートに備えて前記ライブラリに停止した形態で格納されており、前記ライブラリ内の各ＶＭは、前記ホストコンピューティングデバイス上でリスタートされたときハードウェアシステムをエミュレートするソフトウェア構造体であり、各リスタートされたＶＭは複数の前記ソフトウェア構造体を含んでおり、前記ライブラリ内の各ＶＭの前記各ソフトウェア構造体は少なくとも潜在的に最新状態にないためにソフトウェア更新を必要としている該方法は、前記ライブラリ内の各ＶＭについて、
    前記ＶＭの前記各ソフトウェア構造体が最新状態にあるかどうかを検査し、前記ＶＭのいずれかの前記ソフトウェア構造体が最新状態になければ、前記ライブラリ内の前記ＶＭに最新状態にないとのマークを付けるステップと、
    前記ホストコンピューティングデバイス上で取り出され、リスタートされる前記ＶＭの前記ライブラリからの選択を受け取るステップと、
    選択した前記ＶＭに前記ライブラリ内で最新状態にないとの前記マークが付けられているかどうかを判断し、最新状態になければ、どの前記ホストコンピューティングデバイスにもアクセスできないメンテナンスホストコンピューティングデバイス上でそのＶＭを更新するステップと、
    更新した前記ＶＭを前記ホストコンピューティングデバイス上でリスタートするステップとを含むことを特徴とする方法。
16. ＶＭコントローラは、格納した前記ＶＭを前記ライブラリから取り出し、取り出した前記ＶＭを前記メンテナンスホストコンピューティングデバイス上でリスタートするように動作すると共に、リスタートした前記ＶＭを停止し、停止した前記ＶＭを前記ライブラリに格納するように動作し、該方法は、前記ＶＭコントローラによって実行されることを特徴とする請求項１５に記載の方法。
17. 前記ＶＭコントローラは、前記ＶＭの前記各ソフトウェア構造体が最新状態にあるかどうかを定期的に判断するためにスケジューラに基づいて動作することを含むことを特徴とする請求項１６に記載の方法。
18. 前記ＶＭの前記各ソフトウェア構造体が最新状態にあるかどうかを定期的に判断するためにスケジューラに基づいて動作することを含むことを特徴とする請求項１５に記載の方法。
19. 前記ＶＭを更新するステップは、
    前記ＶＭを前記ライブラリから取り出し、取り出したＶＭを前記メンテナンスホストコンピューティングデバイス上でリスタートし、
    リスタートした前記ＶＭの前記各最新状態にないソフトウェア構造体が、必要とするソフトウェア更新を対応する更新ソースから少なくとも１つのパッチとして取得することによって前記メンテナンスホストコンピューティングデバイス上で更新されるのを可能にすること含むことを特徴とする請求項１５に記載の方法。
20. 前記ＶＭを更新するステップは、
    前記ＶＭを前記ライブラリから取り出し、取り出したＶＭを前記コンピューティングデバイスにマウントし、
    マウントした前記ＶＭの前記各ソフトウェア構造体が最新状態にあるかどうかを判断するためにそのマウントした前記ＶＭの構成コンポーネントを検査し、前記各最新状態にないソフトウェア構造体について、必要とするソフトウェア更新を対応する更新ソースから少なくとも１つのパッチとして取得し、各パッチをマウントした前記ＶＭに適用することによって、マウントした前記ＶＭを前記メンテナンスホストコンピューティングデバイス上で更新することを含むことを特徴とする請求項１５に記載の方法。

Images