JP2011145827A - 仮想バスシステム、およびデバイス管理方法 - Google Patents
仮想バスシステム、およびデバイス管理方法 Download PDFInfo
- Publication number
- JP2011145827A JP2011145827A JP2010005047A JP2010005047A JP2011145827A JP 2011145827 A JP2011145827 A JP 2011145827A JP 2010005047 A JP2010005047 A JP 2010005047A JP 2010005047 A JP2010005047 A JP 2010005047A JP 2011145827 A JP2011145827 A JP 2011145827A
- Authority
- JP
- Japan
- Prior art keywords
- port
- virtual
- descriptor
- remote
- device management
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Abstract
【課題】従来、仮想化環境に用いられるＰＣのＯＳはＵＳＢデバイスのプラグインイベント（イベント）を受け取ってもイベントに対するエニュメレーションの妥当性を検証できずに、機械的にエニュメレーションする。そのため、ＵＳＢデバイス１機種あたり１回のインストールで済ませることはできず、ポートの数だけ冗長なインストレーションを許してしまう。
【解決手段】ローカルＰＣ８１とリモートＰＣ８２の間にデバイス管理部４４を具備し、デバイス管理部４４はイベントの通知を受信すると、デバイス管理テーブル４７に従いエニュメレーションの妥当性を検証する。妥当と判断するとデバイスの機種毎にポート番号を付与し、リモートＰＣ８２のＯＳ（ゲストＯＳ）にイベントを通知する。このイベントにより、リモートＰＣ８１のＯＳにはいつも同じポート番号にデバイスが挿された（抜かれた）と通知されるので、インストール回数は１回で済む。
【選択図】図６
【解決手段】ローカルＰＣ８１とリモートＰＣ８２の間にデバイス管理部４４を具備し、デバイス管理部４４はイベントの通知を受信すると、デバイス管理テーブル４７に従いエニュメレーションの妥当性を検証する。妥当と判断するとデバイスの機種毎にポート番号を付与し、リモートＰＣ８２のＯＳ（ゲストＯＳ）にイベントを通知する。このイベントにより、リモートＰＣ８１のＯＳにはいつも同じポート番号にデバイスが挿された（抜かれた）と通知されるので、インストール回数は１回で済む。
【選択図】図６
Description
本発明は、リモート（のＰＣ（Personal Computer））からデバイスを制御する仮想バスシステムにおけるデバイスの管理手法に関する。
従来、仮想化環境に用いられるＰＣのＯＳ（Operating System）は、ＵＳＢ（Universal Serial Bus）デバイス（単に、「デバイス」と称する場合がある）がＰＣのＵＳＢポートに挿されると、挿されたＵＳＢデバイスのエニュメレーションを開始する。「エニュメレーション」とは、デバイスの識別子（デバイスディスクリプタ）を生成し、それをＯＳのシステムコンポーネントに通知することで、プラグアンドプレイに対応したデバイスを検出する処理をいう。ＵＳＢデバイスが未インストールの場合、ＵＳＢデバイスが挿されたＵＳＢポート毎にドライバやミドル（ウェア）、アプリ（ケーション）がインストールされることで、ＰＣがデバイスを制御することが可能となる。複数のＵＳＢポートを具備するＰＣで、全てのＵＳＢポートに対しＵＳＢデバイスが挿抜されると、ＵＳＢポートの数だけインストールが実行され、所定の設定が記録、保持される。
非特許文献１のＵＳＢ／ＩＰ（Internet Protocol）技術では、デバイスを制御するクライアント（リモートＰＣ）から、デバイスが挿されるサーバ（ローカルＰＣ）のＵＳＢポートを監視している。サーバにＵＳＢデバイスが挿され、クライアントがプラグインイベント（単に、「イベント」と称する場合がある）を検知すると、クライアントはデバイスが挿されたポート番号を参照してＵＳＢデバイスをインストールしていた。
ＩＰネットワークを介したＵＳＢ拡張手法の提案、広渕崇宏、２００７年３月２３日、奈良先端科学技術大学院大学情報科学研究科博士論文 ２００７年３月
ＰＣのＯＳはプラグインイベントを受け取っても、プラグインイベントに対するエニュメレーションの妥当性を検証できずに、機械的にエニュメレーションする。そのため、他のＵＳＢポートにインストール済みのＵＳＢデバイスがあったとしても、そのＵＳＢデバイスを他のＵＳＢポートに挿すとインストールが再度発生する。つまりＵＳＢポートの数だけ冗長なインストレーションを許している。
このような事態は非特許文献１で例示したＵＳＢ／ＩＰ技術におけるリモートＰＣのＯＳでも同様であり、リモートＰＣのＯＳがローカルＰＣのＵＳＢのポート番号を参照してＵＳＢデバイスをエニュメレーションする場合、ローカルＰＣ上でＵＳＢデバイスが挿されたポート毎に１回ずつ冗長にインストールが実行される。
つまり従来の、仮想化環境に用いられるＰＣのＯＳでもリモートＰＣのＯＳでも、ＵＳＢデバイス１機種あたり１回のインストールで済ませることはできず、ポートの数だけ冗長にインストールが実行され、所定の設定が記録、保持される。その結果、例えばサービスマンが、仮想化環境を提供するシステムのメンテナンス作業、特に、デバイスの接続の確認に要する作業を行う場合、その作業自体が煩雑化したり、作業の遅延を招いたりして、負担が大きい。
つまり従来の、仮想化環境に用いられるＰＣのＯＳでもリモートＰＣのＯＳでも、ＵＳＢデバイス１機種あたり１回のインストールで済ませることはできず、ポートの数だけ冗長にインストールが実行され、所定の設定が記録、保持される。その結果、例えばサービスマンが、仮想化環境を提供するシステムのメンテナンス作業、特に、デバイスの接続の確認に要する作業を行う場合、その作業自体が煩雑化したり、作業の遅延を招いたりして、負担が大きい。
このような事情を鑑みて、本発明では、仮想化環境におけるデバイスの接続を簡易化することを目的とする。
本発明は、ローカルＰＣのポートに接続されたデバイスを管理するデバイス管理部にプラグインイベントを通知し、デバイス管理部がデバイス管理テーブルに従いエニュメレーションの妥当性を検証する。エニュメレーションが妥当と判断すると、デバイスの機種毎にポート番号を付与し、リモートＰＣのＯＳ（ゲストＯＳ）にプラグインイベントを通知する。このプラグインイベントにより、リモートＰＣのＯＳ（ゲストＯＳ）にはいつも同じポート番号にデバイスが挿された、ないしデバイスが抜かれたと通知されるので、インストール回数を１回にとどめる。
ＵＳＢデバイスがローカルＰＣに挿されるとローカルＰＣのＯＳ（ホストＯＳ）でエニュメレーションが始まり、ＵＳＢデバイス本来のデバイスドライバの代わりにポートリダイレクタドライバ（単に、「ポートリダイレクタ」と称する場合がある。デバイスドライバの一種。）がロードされる。ロード後、ポートリダイレクタドライバによるデバイスの追加処理が済むとポートリダイレクタドライバはデバイス管理部にプラグインイベントと、イベントが発生したポート番号とデバイスディスクリプタを通知する。
デバイス管理部は、デバイス管理部が保持するデバイス管理テーブルにデバイスディスクリプタが示すＵＳＢデバイスが登録されていて、既に１台以上挿されておらず、イベントが発生したポート番号に挿すことを許されていることを確認してエニュメレーションの妥当性を検証する。
デバイス管理部の検証が済み、リモートのＰＣのＯＳに対してプラグインイベントと、当該デバイスに付与したポート番号とデバイスディスクリプタを通知すると、リモートのＰＣのＯＳ上で当該デバイスのエニュメレーションが始まる。当該デバイスはリモートのＰＣのＯＳ上ではインストール済みなので、当該デバイス本来のデバイスドライバがロードされ、リモートＰＣから当該デバイスを制御することが可能となる。これにより、リモートＰＣのＯＳにおいて冗長にインストールが繰り返される事態を回避する。
詳細は、後記する。
ＵＳＢデバイスがローカルＰＣに挿されるとローカルＰＣのＯＳ（ホストＯＳ）でエニュメレーションが始まり、ＵＳＢデバイス本来のデバイスドライバの代わりにポートリダイレクタドライバ（単に、「ポートリダイレクタ」と称する場合がある。デバイスドライバの一種。）がロードされる。ロード後、ポートリダイレクタドライバによるデバイスの追加処理が済むとポートリダイレクタドライバはデバイス管理部にプラグインイベントと、イベントが発生したポート番号とデバイスディスクリプタを通知する。
デバイス管理部は、デバイス管理部が保持するデバイス管理テーブルにデバイスディスクリプタが示すＵＳＢデバイスが登録されていて、既に１台以上挿されておらず、イベントが発生したポート番号に挿すことを許されていることを確認してエニュメレーションの妥当性を検証する。
デバイス管理部の検証が済み、リモートのＰＣのＯＳに対してプラグインイベントと、当該デバイスに付与したポート番号とデバイスディスクリプタを通知すると、リモートのＰＣのＯＳ上で当該デバイスのエニュメレーションが始まる。当該デバイスはリモートのＰＣのＯＳ上ではインストール済みなので、当該デバイス本来のデバイスドライバがロードされ、リモートＰＣから当該デバイスを制御することが可能となる。これにより、リモートＰＣのＯＳにおいて冗長にインストールが繰り返される事態を回避する。
詳細は、後記する。
本発明によれば、仮想化環境におけるデバイスの接続を簡易化することができる。
次に、本発明を実施するための形態（以下、「実施形態」という。）について、適宜図面を参照しながら説明する。
≪第１の実施形態≫
まず、本発明の第１の実施形態について、図１から図５を用いて説明する。図中、２はバスのホストコントローラを制御するバスドライバ、３はポートリダイレクタ、４はデバイス管理部、５は仮想バス、６はデバドラＡ（「デバドラ」はデバイスドライバの略称）、８はＰＣ上のホストＯＳ（ローカルマシン）、９はホストＯＳが提供する仮想マシン実行環境で動作するゲストＯＳ（リモートマシン）、１１はルートハブ、１２、１４はプラグアンドプレイマネジャ（図中では、「Ｐ＆Ｐ Ｍｎｇｒ」と表記）、１３，１５はＵＳＢデバイスのインストール等に関する設定を格納するレジストリファイル、４６はデバイス管理テーブル、１０５はポート５、１０６はポート６、１４１はデバイスＡ、２０１、３０１、５０１、６０１はデバイスオブジェクト（図中では「ＤＯ」（Device Object）と表記）、４０１は仮想ポート１、７０１はデバイスＡの制御ミドルであるミドルＡ、７１１はデバイスＡを制御するアプリＡである。
まず、本発明の第１の実施形態について、図１から図５を用いて説明する。図中、２はバスのホストコントローラを制御するバスドライバ、３はポートリダイレクタ、４はデバイス管理部、５は仮想バス、６はデバドラＡ（「デバドラ」はデバイスドライバの略称）、８はＰＣ上のホストＯＳ（ローカルマシン）、９はホストＯＳが提供する仮想マシン実行環境で動作するゲストＯＳ（リモートマシン）、１１はルートハブ、１２、１４はプラグアンドプレイマネジャ（図中では、「Ｐ＆Ｐ Ｍｎｇｒ」と表記）、１３，１５はＵＳＢデバイスのインストール等に関する設定を格納するレジストリファイル、４６はデバイス管理テーブル、１０５はポート５、１０６はポート６、１４１はデバイスＡ、２０１、３０１、５０１、６０１はデバイスオブジェクト（図中では「ＤＯ」（Device Object）と表記）、４０１は仮想ポート１、７０１はデバイスＡの制御ミドルであるミドルＡ、７１１はデバイスＡを制御するアプリＡである。
図１は本発明の第１の実施形態のソフトウェアスタック構成を示す図であり、（例えば１台の）ＰＣのポートに挿されたデバイスをハイパバイザから仮想マシン（以下、「ＶＭ」（Virtual Machine）と表記する場合がある）上の仮想バスでプラグアンドプレイさせる処理手順を示している。
図１を用いて、ホストＯＳないしハイパバイザが動作するＰＣにデバイスを挿した後、同じＰＣのゲストＯＳないしＶＭ上の仮想バスでプラグアンドプレイするまでの処理を説明する。なお、本実施形態のＰＣは、入力部（デバイスと接続する入力用インターフェイスを含む）、出力部（デバイスと接続する出力用インターフェイスを含む）、制御部（例：ＣＰＵ（Central Processing Unit））、記憶部（例：メモリ、ストレージデバイス）といったハードウェア構成を備え、以下に説明する情報処理を実現する。また、このＰＣは、前記情報処理を実現するのに必要なコードが記述されたデバイス管理用のプログラムを記憶している。
図１を用いて、ホストＯＳないしハイパバイザが動作するＰＣにデバイスを挿した後、同じＰＣのゲストＯＳないしＶＭ上の仮想バスでプラグアンドプレイするまでの処理を説明する。なお、本実施形態のＰＣは、入力部（デバイスと接続する入力用インターフェイスを含む）、出力部（デバイスと接続する出力用インターフェイスを含む）、制御部（例：ＣＰＵ（Central Processing Unit））、記憶部（例：メモリ、ストレージデバイス）といったハードウェア構成を備え、以下に説明する情報処理を実現する。また、このＰＣは、前記情報処理を実現するのに必要なコードが記述されたデバイス管理用のプログラムを記憶している。
（デバイス）
図中デバイスＡ（１４１）はスキャナやプリンタ等のデバイスの機能を表す。具体的には、デバイスを挿すポートないしバスが規定するプラグアンドプレイに対応する機能、例えばデバイスディスクリプタの応答や、プリンタなら印刷と言ったデバイス本来の機能、電源状態に応じて節電運転する電源モード管理機能からなる。
図中デバイスＡ（１４１）はスキャナやプリンタ等のデバイスの機能を表す。具体的には、デバイスを挿すポートないしバスが規定するプラグアンドプレイに対応する機能、例えばデバイスディスクリプタの応答や、プリンタなら印刷と言ったデバイス本来の機能、電源状態に応じて節電運転する電源モード管理機能からなる。
（エニュメレーション）
ポート５（１０５）にデバイスＡ（１４１）が挿されると、ルートハブ１１がデバイスの挿入を検知し、プラグアンドプレイマネジャ１２にプラグインイベント（図中では「Plug-in」と表記）を通知する。プラグアンドプレイマネジャ１２はバスドライバ２に対し、ポート５（１０５）にデバイスＡ（１４１）がプラグインした旨伝達し、ポート５（１０５）に挿したデバイスＡ（１４１）からデバイスディスクリプタを読み出し、レジストリファイル１３を検索してバスドライバ２の上位にデバイスドライバをロードする。図１において、レジストリファイル１３に記載されているデバイスＡ(１４１)のデバイスドライバはポートリダイレクタ３である。レジストリファイル１３にはデバイスのインストール時に、デバイスディスクリプタの情報とデバイスドライバの名称と所在等情報が記載ないし格納されており、これら情報を参照することでロードすべきデバイスドライバを特定することができる。ポートリダイレクタ３はすでにメモリ上にロードされているのでロードは省略し、ポートリダイレクタ３を初期化してデバイスＡ（１４１）を制御するためのデバイス追加処理としてデバイスオブジェクト（２０１，３０１）がポートリダイレクタ３とバスドライバ２に作成される。
ポート５（１０５）にデバイスＡ（１４１）が挿されると、ルートハブ１１がデバイスの挿入を検知し、プラグアンドプレイマネジャ１２にプラグインイベント（図中では「Plug-in」と表記）を通知する。プラグアンドプレイマネジャ１２はバスドライバ２に対し、ポート５（１０５）にデバイスＡ（１４１）がプラグインした旨伝達し、ポート５（１０５）に挿したデバイスＡ（１４１）からデバイスディスクリプタを読み出し、レジストリファイル１３を検索してバスドライバ２の上位にデバイスドライバをロードする。図１において、レジストリファイル１３に記載されているデバイスＡ(１４１)のデバイスドライバはポートリダイレクタ３である。レジストリファイル１３にはデバイスのインストール時に、デバイスディスクリプタの情報とデバイスドライバの名称と所在等情報が記載ないし格納されており、これら情報を参照することでロードすべきデバイスドライバを特定することができる。ポートリダイレクタ３はすでにメモリ上にロードされているのでロードは省略し、ポートリダイレクタ３を初期化してデバイスＡ（１４１）を制御するためのデバイス追加処理としてデバイスオブジェクト（２０１，３０１）がポートリダイレクタ３とバスドライバ２に作成される。
（デバイスオブジェクト）
デバイスオブジェクト（２０１，３０１）はデバイスがプラグアンドプレイされる度にデバイス毎にバスドライバとデバイスドライバ（ホストＯＳ（８）においては、ポートリダイレクタ３）に作成される。デバイスオブジェクト（２０１，３０１）にはデバイスを制御する際の電文（コマンドとデータ）を格納するバッファへのポインタと、電文を処理するコードを指し示すポインタと、対応するデバイスオブジェクト（２０１，３０１）を指し示すポインタとが格納される。
デバイスドライバであってもバスドライバであっても、一般的にドライバは入出力リクエストパケット（ＩＲＰ（I/O Request Packet））をＩ／Ｏマネージャ（不図示）から受け取ると、ＩＲＰに対応するデバイスのデバイスオブジェクト（２０１，３０１）を参照し、処理した上で、上位ないし下位のドライバにＩＲＰを受け渡しデバイスの制御を実現する。
デバイスオブジェクト（２０１，３０１）はデバイスがプラグアンドプレイされる度にデバイス毎にバスドライバとデバイスドライバ（ホストＯＳ（８）においては、ポートリダイレクタ３）に作成される。デバイスオブジェクト（２０１，３０１）にはデバイスを制御する際の電文（コマンドとデータ）を格納するバッファへのポインタと、電文を処理するコードを指し示すポインタと、対応するデバイスオブジェクト（２０１，３０１）を指し示すポインタとが格納される。
デバイスドライバであってもバスドライバであっても、一般的にドライバは入出力リクエストパケット（ＩＲＰ（I/O Request Packet））をＩ／Ｏマネージャ（不図示）から受け取ると、ＩＲＰに対応するデバイスのデバイスオブジェクト（２０１，３０１）を参照し、処理した上で、上位ないし下位のドライバにＩＲＰを受け渡しデバイスの制御を実現する。
（デバイス追加処理）
ポート５（１０５）に挿したデバイスＡ（１４１）に関して、バスドライバ２でデバイス追加処理が実行されるとデバイスオブジェクト２０１が作成され、ポートリダイレクタ３でデバイス追加処理が実行されるとデバイスオブジェクト３０１が作成される。そして、デバイスオブジェクト２０１とデバイスオブジェクト３０１とが互いにポインタを格納することで関連付けが完了し、デバイス追加処理が終了する。ポートリダイレクタ３はデバイスオブジェクト３０１を作成した際、デバイスオブジェクト３０１にセッション番号を付与し、デバイスオブジェクトを識別する。デバイスオブジェクト３０１にはセッション１が付与される。
ポート５（１０５）に挿したデバイスＡ（１４１）に関して、バスドライバ２でデバイス追加処理が実行されるとデバイスオブジェクト２０１が作成され、ポートリダイレクタ３でデバイス追加処理が実行されるとデバイスオブジェクト３０１が作成される。そして、デバイスオブジェクト２０１とデバイスオブジェクト３０１とが互いにポインタを格納することで関連付けが完了し、デバイス追加処理が終了する。ポートリダイレクタ３はデバイスオブジェクト３０１を作成した際、デバイスオブジェクト３０１にセッション番号を付与し、デバイスオブジェクトを識別する。デバイスオブジェクト３０１にはセッション１が付与される。
（デバイス管理部へのプラグインイベント通知）
デバイス追加処理が成功し、完了すると、ポートリダイレクタ３はデバイス管理部４に対し、ポート５(１０５)にデバイスＡ（１４１）がプラグインされた旨を示すイベントを通知し、当該デバイスディスクリプタとセッション番号を受け渡し、処理を終了する。
デバイス追加処理が成功し、完了すると、ポートリダイレクタ３はデバイス管理部４に対し、ポート５(１０５)にデバイスＡ（１４１）がプラグインされた旨を示すイベントを通知し、当該デバイスディスクリプタとセッション番号を受け渡し、処理を終了する。
（デバイス放置）
ポートリダイレクタ３はデバイス追加処理とデバイス削除処理（デバイスのアンインストール）と電文の中継処理に機能が限定されるので、この後自発的にデバイスＡ（１４１）を制御することは無い。そのため、デバイスＡ（１４１）は初期化ないし活性化されないまま、ポート５（１０５）につながった状態で初期化ないし活性化を待ち続ける。
ポートリダイレクタ３はデバイス追加処理とデバイス削除処理（デバイスのアンインストール）と電文の中継処理に機能が限定されるので、この後自発的にデバイスＡ（１４１）を制御することは無い。そのため、デバイスＡ（１４１）は初期化ないし活性化されないまま、ポート５（１０５）につながった状態で初期化ないし活性化を待ち続ける。
（適・不適の判定と仮想ポートの特定）
プラグインイベントを受けたデバイス管理部４はデバイス管理テーブル４６を参照し、［１］受け渡されたデバイスディスクリプタが既知のデバイスのデバイスディスクリプタと一致し、［２］そのデバイスが予め許可されたポートに挿されていて、［３］仮想バス５に既にプラグアンドプレイされており、ｓｔａｒｔｅｄ状態（ゲストＯＳ（９）が制御している状態）である同一機種のデバイスが存在しない、という以上の３条件を満足するか確認する。条件が満足していると、エニュメレーションが妥当であることを意味し、デバイスディスクリプタからデバイスの機種を特定し、機種ごとに割り当てられた仮想ポートのポート番号を特定する。図１においてデバイスＡ（１４１）の仮想ポートは仮想ポート１（４０１）である。
プラグインイベントを受けたデバイス管理部４はデバイス管理テーブル４６を参照し、［１］受け渡されたデバイスディスクリプタが既知のデバイスのデバイスディスクリプタと一致し、［２］そのデバイスが予め許可されたポートに挿されていて、［３］仮想バス５に既にプラグアンドプレイされており、ｓｔａｒｔｅｄ状態（ゲストＯＳ（９）が制御している状態）である同一機種のデバイスが存在しない、という以上の３条件を満足するか確認する。条件が満足していると、エニュメレーションが妥当であることを意味し、デバイスディスクリプタからデバイスの機種を特定し、機種ごとに割り当てられた仮想ポートのポート番号を特定する。図１においてデバイスＡ（１４１）の仮想ポートは仮想ポート１（４０１）である。
（デバイス管理テーブル）
図５にデバイス管理部４が参照するデバイス管理テーブルを示す。デバイス管理テーブル（第１の実施形態では、符号４６）には既知のデバイスＡとデバイスＢとデバイスＣが登録されている。この登録は、例えば、各デバイスの初回のインストール時に行われる。デバイスの名称（デバイス名５００１）はデバイスディスクリプタに記載されたデバイス名とデバイスの機種毎に固有のＩＤ（インスタンスＩＤ）とが登録され、デバイス管理部４はいずれかで検索する。換言すれば、デバイス名５００１には、デバイスのデバイスディスクリプタが登録されており、デバイスがポートに挿されるときに読み出されるデバイスディスクリプタを検索キーとして、デバイス名５００１に対して検索が実行される。
図５にデバイス管理部４が参照するデバイス管理テーブルを示す。デバイス管理テーブル（第１の実施形態では、符号４６）には既知のデバイスＡとデバイスＢとデバイスＣが登録されている。この登録は、例えば、各デバイスの初回のインストール時に行われる。デバイスの名称（デバイス名５００１）はデバイスディスクリプタに記載されたデバイス名とデバイスの機種毎に固有のＩＤ（インスタンスＩＤ）とが登録され、デバイス管理部４はいずれかで検索する。換言すれば、デバイス名５００１には、デバイスのデバイスディスクリプタが登録されており、デバイスがポートに挿されるときに読み出されるデバイスディスクリプタを検索キーとして、デバイス名５００１に対して検索が実行される。
デバイスＡに関していえば、デバイスディスクリプタ５００２には仮想バス５が動作するＯＳのプラグアンドプレイマネジャ１４に受け渡す代替デバイスディスクリプタＡが、ゲストＯＳ（９）でエニュメレーションを行うときにゲストＯＳ（９）に割り当てられる仮想的なポートを示す仮想ポート番号５００３には仮想ポート１が、ホストＯＳ（８）が動くＰＣ上でデバイスＡ（１４１）が挿されるべきポートを表す実ポート番号５００４はポート５が、それぞれ記載されている。
デバイス管理テーブル４６においてセッション番号５００５以外は固定値であり、管理者や管理権限を持ったプログラム、例えばインストーラが追加、修正、削除する。セッション番号５００５はデバイスが挿されていないときはヌル（ＮＵＬＬ）であり、デバイスが挿されてポートリダイレクタ３がセッション番号を付与するたびに上書きされる。
デバイス管理部４はこのデバイス管理テーブル４６に従い、ポート５（１０５）に１台だけデバイスＡ（１４１）が挿されていれば好適と判断する。デバイスＢも同様である。デバイスＣは実ポート番号５００４と仮想ポート番号５００３ともにヌル（ＮＵＬＬ）である。これはホストＯＳ（８）が動くＰＣ上に挿されるべきポートが無く、仮想バス５にもつながらないことを意味するため、デバイス管理部４はデバイスＣが挿されると無条件で不適と判断する。
（いつも同じポートに同じデバイスが挿抜されたと通知）
デバイス管理部４は、デバイス管理テーブル４を参照して、ゲストＯＳ（９）のプラグアンドプレイマネジャ１４に、挿抜されたデバイスに対応する代替デバイスディスクリプタと仮想ポートとを通知する。これにより、プラグアンドプレイマネジャ１４は初回のインストール時に仮想ポート番号と代替デバイスディスクリプタの情報をレジストリファイル１５に書き込む。以後、ゲストＯＳ（９）において、同じポートに同じデバイスが挿抜されたと認識する。
デバイス管理部４は、デバイス管理テーブル４を参照して、ゲストＯＳ（９）のプラグアンドプレイマネジャ１４に、挿抜されたデバイスに対応する代替デバイスディスクリプタと仮想ポートとを通知する。これにより、プラグアンドプレイマネジャ１４は初回のインストール時に仮想ポート番号と代替デバイスディスクリプタの情報をレジストリファイル１５に書き込む。以後、ゲストＯＳ（９）において、同じポートに同じデバイスが挿抜されたと認識する。
（プラグインイベント通知）
デバイス管理部４はプラグアンドプレイマネジャ１４に対してプラグインイベント（図中では「Plug-in」と表記）を通知する。この通知は、ホストＯＳ（８）とゲストＯＳ（９）をつなぐ仮想マシンバス（ＶＭ Ｂｕｓ）を介してメッセージを送受信して実現している。通知の際、デバイスＡ（１４１）が挿されているポートは、先に特定した仮想ポート１（４０１）に置き換えて通知する。プラグアンドプレイマネジャ１４は仮想バス５に対して、仮想ポート１（４０１）へデバイスＡ（１４１）がプラグインした旨通知する。
デバイス管理部４はプラグアンドプレイマネジャ１４に対してプラグインイベント（図中では「Plug-in」と表記）を通知する。この通知は、ホストＯＳ（８）とゲストＯＳ（９）をつなぐ仮想マシンバス（ＶＭ Ｂｕｓ）を介してメッセージを送受信して実現している。通知の際、デバイスＡ（１４１）が挿されているポートは、先に特定した仮想ポート１（４０１）に置き換えて通知する。プラグアンドプレイマネジャ１４は仮想バス５に対して、仮想ポート１（４０１）へデバイスＡ（１４１）がプラグインした旨通知する。
（仮想バスへのエニュメレーション）
プラグアンドプレイマネジャ１４はデバイス管理部４から代替デバイスディスクリプタを受け取り、レジストリファイル１５を検索して仮想バス５の上位にデバイスドライバとしてデバイスＡ本来のデバイスドライバであるデバドラＡ（６）をロードする。デバドラＡ（６）はメモリ上にロードされ、初期化の後、デバイスＡ（１４１）を制御するためのデバイス追加処理としてデバイスオブジェクト（５０１，６０１）が作成される。
プラグアンドプレイマネジャ１４はデバイス管理部４から代替デバイスディスクリプタを受け取り、レジストリファイル１５を検索して仮想バス５の上位にデバイスドライバとしてデバイスＡ本来のデバイスドライバであるデバドラＡ（６）をロードする。デバドラＡ（６）はメモリ上にロードされ、初期化の後、デバイスＡ（１４１）を制御するためのデバイス追加処理としてデバイスオブジェクト（５０１，６０１）が作成される。
（デバイス追加処理）
仮想ポート１（４０１）に仮想的に挿されたデバイスＡ（１４１）に関して、仮想バス５でデバイス追加処理が実行されるとデバイスオブジェクト５０１が作成される。そして、デバドラＡ（６）でデバイス追加処理が実行されるとデバイスオブジェクト６０１が作成され、デバイスオブジェクト５０１とデバイスオブジェクト６０１とが互いにポインタを格納することで関連付けが完了し、デバイス追加処理が終了する。
仮想ポート１（４０１）に仮想的に挿されたデバイスＡ（１４１）に関して、仮想バス５でデバイス追加処理が実行されるとデバイスオブジェクト５０１が作成される。そして、デバドラＡ（６）でデバイス追加処理が実行されるとデバイスオブジェクト６０１が作成され、デバイスオブジェクト５０１とデバイスオブジェクト６０１とが互いにポインタを格納することで関連付けが完了し、デバイス追加処理が終了する。
（セッション番号）
デバイス管理部４はプラグアンドプレイマネジャ１４に通知した情報（デバイスディスクリプタと仮想ポート番号）とセッション番号とを、仮想バス５に通知する（図示せず）。この通知は、ホストＯＳ（８）とゲストＯＳ（９）をつなぐ仮想マシンバス（ＶＭ Ｂｕｓ）を介してメッセージを送受信して実現している。仮想バス５はセッション番号としてセッション１を受け取り、デバイスオブジェクト５０１にセッション１を付与する。
付与されたセッション番号により、デバイスオブジェクト２０１，３０１，５０１，６０１が関連付けられる。このセッション番号での関連付けがなされてはじめて、上位のドライバであるデバドラＡ（６）が受けたＩＲＰが最下位のバスドライバ２に受け渡される状態になり、ゲストＯＳ（９）はホストＯＳ（８）を介してデバイスＡ（１４１）を制御できる。
デバイス管理部４はプラグアンドプレイマネジャ１４に通知した情報（デバイスディスクリプタと仮想ポート番号）とセッション番号とを、仮想バス５に通知する（図示せず）。この通知は、ホストＯＳ（８）とゲストＯＳ（９）をつなぐ仮想マシンバス（ＶＭ Ｂｕｓ）を介してメッセージを送受信して実現している。仮想バス５はセッション番号としてセッション１を受け取り、デバイスオブジェクト５０１にセッション１を付与する。
付与されたセッション番号により、デバイスオブジェクト２０１，３０１，５０１，６０１が関連付けられる。このセッション番号での関連付けがなされてはじめて、上位のドライバであるデバドラＡ（６）が受けたＩＲＰが最下位のバスドライバ２に受け渡される状態になり、ゲストＯＳ（９）はホストＯＳ（８）を介してデバイスＡ（１４１）を制御できる。
（効果）
図１の構成によれば、本発明のデバイス管理部４がデバイス管理テーブル４６（図５）を参照し、挿されたデバイスの適／不適を判定することで、適と判断した場合には、ゲストＯＳ（９）のプラグアンドプレイマネジャ１４にプラグインイベントを通知し、ゲストＯＳ（９）におけるエニュメレーションを許可できる。不適と判断した場合にはゲストＯＳ（９）のプラグアンドプレイマネジャ１４にプラグインイベントを通知しないのでエニュメレーションを抑止できる。また、当該デバイスはホストＯＳ（８）のポートリダイレクタ３が占有することで、ゲストＯＳ（９）やホストＯＳ（８）の他のドライバやミドル、アプリが制御できない隔離状態を実現している。
図１の構成によれば、本発明のデバイス管理部４がデバイス管理テーブル４６（図５）を参照し、挿されたデバイスの適／不適を判定することで、適と判断した場合には、ゲストＯＳ（９）のプラグアンドプレイマネジャ１４にプラグインイベントを通知し、ゲストＯＳ（９）におけるエニュメレーションを許可できる。不適と判断した場合にはゲストＯＳ（９）のプラグアンドプレイマネジャ１４にプラグインイベントを通知しないのでエニュメレーションを抑止できる。また、当該デバイスはホストＯＳ（８）のポートリダイレクタ３が占有することで、ゲストＯＳ（９）やホストＯＳ（８）の他のドライバやミドル、アプリが制御できない隔離状態を実現している。
デバイス管理部４が適と判断し、ゲストＯＳ（９）のプラグアンドプレイマネジャ１４にプラグインイベントを通知する際、デバイス種別ないし機種毎に割り当てられた仮想ポート番号を通知することで、ゲストＯＳ（９）のプラグアンドプレイマネジャ１４やアプリやミドルにはいつも同じポートに同じ（同種の）デバイスが挿されたように見せることができる。これにより、デバイスを不意にホストＯＳ（８）の別のポートに挿しても（そのデバイスに関し、そのポートも許可されていれば）プラグアンドプレイマネジャ１４は同じポートに挿したと認識するので、デバイスのインストール回数は１機種あたり１回で済ませられる。これにより、アプリケーションやミドルはデバイスが挿されたポートを検索する手間も省ける。
デバイス管理テーブル４６にデバイス毎に挿しても良いポートが記載されていることで、不意に別の許可されていないポートに挿した場合、エニュメレーションは抑止される。これにより、利用者はデバイスを間違ったポートに挿したと認識できる。
図２は本発明の第１の実施形態でデバイスをリセット後、デバイスを再接続する際の処理手順を示す図である。
図２を用いて、デバイスＡ（１４１）にリセットがかかり、デバイスＡ（１４１）が再起動した後、同じＰＣのゲストＯＳ（９）ないしＶＭ上の仮想バス５でプラグアンドプレイするまでの処理を説明する。簡単のため、図１と重複する処理について説明を省略する（他の図面を用いた説明においても同様）。また、同一の構成には、同一の符号を付す（他の図面においても同様）。
図２を用いて、デバイスＡ（１４１）にリセットがかかり、デバイスＡ（１４１）が再起動した後、同じＰＣのゲストＯＳ（９）ないしＶＭ上の仮想バス５でプラグアンドプレイするまでの処理を説明する。簡単のため、図１と重複する処理について説明を省略する（他の図面を用いた説明においても同様）。また、同一の構成には、同一の符号を付す（他の図面においても同様）。
（リセット）
図２において、ゲストＯＳ（９）上のアプリＡ（７１１）ないしミドルＡ（７０１）がデバイスＡ（１４１）をリセットし、デバイスＡ（１４１）が再起動すると、ホストＯＳ（８）はポート５（１０５）にプラグインを検知する。
リセットはこの他、デバイスＡ（１４１）の瞬断や操作により電源が落ちた場合、ポート５（１０５）で抜き挿しされた場合等に発生する。
図２において、ゲストＯＳ（９）上のアプリＡ（７１１）ないしミドルＡ（７０１）がデバイスＡ（１４１）をリセットし、デバイスＡ（１４１）が再起動すると、ホストＯＳ（８）はポート５（１０５）にプラグインを検知する。
リセットはこの他、デバイスＡ（１４１）の瞬断や操作により電源が落ちた場合、ポート５（１０５）で抜き挿しされた場合等に発生する。
（エニュメレーションとデバイス追加処理）
ホストＯＳ（８）上でエニュメレーションが進行すると、バスドライバ２にデバイスオブジェクト２０２が、ポートリダイレクタ３にデバイスオブジェクト３０２が作成される。そして、デバイス追加処理でセッション番号としてセッション２が付与される。このときデバイス管理部４は、デバイス管理テーブル４６のデバイスＡにおけるセッション番号５００５の値を更新する。バスドライバ２はデバイス追加処理を終えると、デバイス管理部４にプラグインイベントを通知する。
ホストＯＳ（８）上でエニュメレーションが進行すると、バスドライバ２にデバイスオブジェクト２０２が、ポートリダイレクタ３にデバイスオブジェクト３０２が作成される。そして、デバイス追加処理でセッション番号としてセッション２が付与される。このときデバイス管理部４は、デバイス管理テーブル４６のデバイスＡにおけるセッション番号５００５の値を更新する。バスドライバ２はデバイス追加処理を終えると、デバイス管理部４にプラグインイベントを通知する。
（適・不適の判定と仮想ポートの特定）
プラグインイベントを受けたデバイス管理部４は、［１］受け渡されたデバイスディスクリプタが既知のデバイスのデバイスディスクリプタと一致し、［２］そのデバイスが予め許可されたポートに挿されていて、［３］仮想バス５に既にプラグアンドプレイされており、ｓｔａｒｔｅｄ状態である同一機種のデバイスが存在しない、という以上の３条件を満足するか確認する。満足されていると、エニュメレーションが妥当であることを意味し、デバイスディスクリプタからデバイスの機種を特定し、機種ごとに割り当てられた仮想ポートのポート番号から、該当する仮想ポートのポート番号を仮想ポート１（４０１）に特定する。デバイスＡ（１４１）がリセットした前後で挿されているデバイスの数やポート番号に変化が無いので、デバイス管理部４における処理は図１による説明と同じ結果にいたる。
プラグインイベントを受けたデバイス管理部４は、［１］受け渡されたデバイスディスクリプタが既知のデバイスのデバイスディスクリプタと一致し、［２］そのデバイスが予め許可されたポートに挿されていて、［３］仮想バス５に既にプラグアンドプレイされており、ｓｔａｒｔｅｄ状態である同一機種のデバイスが存在しない、という以上の３条件を満足するか確認する。満足されていると、エニュメレーションが妥当であることを意味し、デバイスディスクリプタからデバイスの機種を特定し、機種ごとに割り当てられた仮想ポートのポート番号から、該当する仮想ポートのポート番号を仮想ポート１（４０１）に特定する。デバイスＡ（１４１）がリセットした前後で挿されているデバイスの数やポート番号に変化が無いので、デバイス管理部４における処理は図１による説明と同じ結果にいたる。
（ゲストＯＳ上の仮想バスへのエニュメレーション）
プラグアンドプレイマネジャ１４はデバイス管理部４から代替デバイスディスクリプタを受け取り、レジストリファイル１５を検索して仮想バス５の上位にデバイスドライバとして、デバイスＡ本来のデバイスドライバであるデバドラＡ（６）を特定する。デバドラＡ（６）はメモリ上にロードされ初期化済みなので、デバイスＡ（１４１）を制御するためのデバイス追加処理としてデバイスオブジェクト（５０２，６０２）が作成される。
プラグアンドプレイマネジャ１４はデバイス管理部４から代替デバイスディスクリプタを受け取り、レジストリファイル１５を検索して仮想バス５の上位にデバイスドライバとして、デバイスＡ本来のデバイスドライバであるデバドラＡ（６）を特定する。デバドラＡ（６）はメモリ上にロードされ初期化済みなので、デバイスＡ（１４１）を制御するためのデバイス追加処理としてデバイスオブジェクト（５０２，６０２）が作成される。
（デバイス追加処理）
仮想ポート１（４０１）に仮想的に挿されたデバイスＡ（１４１）に関して、仮想バス５でデバイス追加処理が実行されるとデバイスオブジェクト５０２が作成され、デバドラＡ（６）でデバイス追加処理が実行されるとデバイスオブジェクト６０２が作成される。そして、デバイスオブジェクト５０２とデバイスオブジェクト６０２とが互いにポインタを格納することで関連付けが完了し、デバイス追加処理が終了する。
仮想ポート１（４０１）に仮想的に挿されたデバイスＡ（１４１）に関して、仮想バス５でデバイス追加処理が実行されるとデバイスオブジェクト５０２が作成され、デバドラＡ（６）でデバイス追加処理が実行されるとデバイスオブジェクト６０２が作成される。そして、デバイスオブジェクト５０２とデバイスオブジェクト６０２とが互いにポインタを格納することで関連付けが完了し、デバイス追加処理が終了する。
（セッション番号）
図２においてデバイスＡ（１４１）のリセット後に付与されたセッション番号はセッション２となり、デバイスオブジェクト２０２，３０２，５０２，６０２が関連付けられる。このセッション番号での関連付けがなされてはじめて、上位のドライバであるデバドラＡ（６）が受けたＩＲＰが最下位のバスドライバ２に受け渡される状態になり、ゲストＯＳ（９）はホストＯＳ（８）を介してデバイスＡ（１４１）を制御できる。これにより、ミドルＡ（７０１）とアプリＡ（７１１）はリセット後もデバイスＡ（１４１）を制御できる。
図２においてデバイスＡ（１４１）のリセット後に付与されたセッション番号はセッション２となり、デバイスオブジェクト２０２，３０２，５０２，６０２が関連付けられる。このセッション番号での関連付けがなされてはじめて、上位のドライバであるデバドラＡ（６）が受けたＩＲＰが最下位のバスドライバ２に受け渡される状態になり、ゲストＯＳ（９）はホストＯＳ（８）を介してデバイスＡ（１４１）を制御できる。これにより、ミドルＡ（７０１）とアプリＡ（７１１）はリセット後もデバイスＡ（１４１）を制御できる。
（効果）
図２の構成によれば、本発明のデバイス管理部４がデバイス管理テーブル４６（図５）を参照し、挿されたデバイスの適／不適を判定することで、電源が再投入される等してデバイスがリセットされたり、ポートに抜き挿ししたりしたためプラグインされたと認識されたデバイスについて、リセットや抜き挿しの前後であっても同一個体と認識できる。リセットや抜き挿しの前後で同一個体と認識することで、ゲストＯＳ（９）におけるエニュメレーションを許可し、ミドルやアプリはリセットや抜き挿しの前後で同一デバイスを制御できる。
また、リセットや抜き挿しの前後でポート番号は変わらないので、アプリケーションやミドルはデバイスが挿されたポートを検索する手間も省ける。
図２の構成によれば、本発明のデバイス管理部４がデバイス管理テーブル４６（図５）を参照し、挿されたデバイスの適／不適を判定することで、電源が再投入される等してデバイスがリセットされたり、ポートに抜き挿ししたりしたためプラグインされたと認識されたデバイスについて、リセットや抜き挿しの前後であっても同一個体と認識できる。リセットや抜き挿しの前後で同一個体と認識することで、ゲストＯＳ（９）におけるエニュメレーションを許可し、ミドルやアプリはリセットや抜き挿しの前後で同一デバイスを制御できる。
また、リセットや抜き挿しの前後でポート番号は変わらないので、アプリケーションやミドルはデバイスが挿されたポートを検索する手間も省ける。
図３は本発明の第１の実施形態で同一機種が２台挿された状態での処理手順を示す図である。
図３を用いて、同一機種を２台挿したときのホストＯＳ側の処理を説明する。
図３を用いて、同一機種を２台挿したときのホストＯＳ側の処理を説明する。
（２台目）
図３においてデバイスＡ（１４１）は既にプラグアンドプレイを終え、ゲストＯＳ（９）上のミドルＡ（７０１）とアプリＡ（７１１）が制御している。この状況でデバイスＡ（１４２）をポート６（１０６）に挿すとホストＯＳ（８）上でエニュメレーションが進行し、デバイス追加処理の結果、バスドライバ２にデバイスオブジェクト２０３が、ポートリダイレクタ３にデバイスオブジェクト３０３がそれぞれ作成される。また、図示していないがセッション番号は付与される。
図３においてデバイスＡ（１４１）は既にプラグアンドプレイを終え、ゲストＯＳ（９）上のミドルＡ（７０１）とアプリＡ（７１１）が制御している。この状況でデバイスＡ（１４２）をポート６（１０６）に挿すとホストＯＳ（８）上でエニュメレーションが進行し、デバイス追加処理の結果、バスドライバ２にデバイスオブジェクト２０３が、ポートリダイレクタ３にデバイスオブジェクト３０３がそれぞれ作成される。また、図示していないがセッション番号は付与される。
（デバイス管理へのプラグインイベント通知）
デバイス追加処理に成功し完了するとポートリダイレクタ３はデバイス管理部４に対し、ポート６(１０６)にデバイスＡ（１４２）がプラグインされた旨を示すイベントを通知し、当該デバイスディスクリプタとセッション番号を受け渡し、処理を終了する。
デバイス追加処理に成功し完了するとポートリダイレクタ３はデバイス管理部４に対し、ポート６(１０６)にデバイスＡ（１４２）がプラグインされた旨を示すイベントを通知し、当該デバイスディスクリプタとセッション番号を受け渡し、処理を終了する。
（適・不適の判定と仮想ポートの特定）
プラグインイベントを受けたデバイス管理部４は、既にｓｔａｒｔｅｄ状態にある同一機種のデバイスＡ（１４１）が、仮想バス５にプラグアンドプレイされているので（条件［３］を満たしていないので）、このデバイスＡ（１４２）を不適と判断する。不適と判断したデバイスＡ（１４２）に関して、プラグアンドプレイマネジャ１４にプラグインイベントの通知は行わない。引き続きデバイス管理部４は、判断材料となったデバイスディスクリプタとポート番号とデバイスＡ（１４１）のデバイスディスクリプタと判断結果と判断した時刻をログ４１に書き込み処理を終了する。
プラグインイベントを受けたデバイス管理部４は、既にｓｔａｒｔｅｄ状態にある同一機種のデバイスＡ（１４１）が、仮想バス５にプラグアンドプレイされているので（条件［３］を満たしていないので）、このデバイスＡ（１４２）を不適と判断する。不適と判断したデバイスＡ（１４２）に関して、プラグアンドプレイマネジャ１４にプラグインイベントの通知は行わない。引き続きデバイス管理部４は、判断材料となったデバイスディスクリプタとポート番号とデバイスＡ（１４１）のデバイスディスクリプタと判断結果と判断した時刻をログ４１に書き込み処理を終了する。
（デバイス放置）
ポートリダイレクタ３はデバイス追加処理とデバイス削除処理と電文の中継処理に機能が限定されるので、この後自発的にデバイスＡ（１４２）を制御することは無い。そのため、デバイスＡ（１４２）は初期化ないし活性化されないまま、ポート６（１０６）につながった状態で初期化ないし活性化を待ち続ける。
ポートリダイレクタ３はデバイス追加処理とデバイス削除処理と電文の中継処理に機能が限定されるので、この後自発的にデバイスＡ（１４２）を制御することは無い。そのため、デバイスＡ（１４２）は初期化ないし活性化されないまま、ポート６（１０６）につながった状態で初期化ないし活性化を待ち続ける。
（ログの保存場所）
本発明の第１の実施形態において、デバイス管理部４が書き込んだログ４１はデバイス管理部４が動作しているホストＯＳ（８）がマウントしているストレージデバイスにファイルとして保存される。
本発明の第１の実施形態において、デバイス管理部４が書き込んだログ４１はデバイス管理部４が動作しているホストＯＳ（８）がマウントしているストレージデバイスにファイルとして保存される。
（効果）
図３の構成によれば、本発明のデバイス管理部４がデバイス管理テーブル４６（図５）を参照し、挿されたデバイスの適／不適を判定することで、同一機種のデバイスが既にエニュメレーションされた状態で、２台目以後同一機種のデバイスが挿されると不適と判断し、ゲストＯＳ（９）のプラグアンドプレイマネジャ１４にプラグインイベントを通知しないので、２台目以後同一機種のデバイスのエニュメレーションを抑止できる。これにより、ミドルやアプリの誤作動や、デバイスのすり替えを防げる。また、当該デバイスはホストＯＳ（８）のポートリダイレクタ３が占有することで、ゲストＯＳ（９）やホストＯＳ（８）の他のドライバやミドル、アプリが制御できない隔離状態を実現している。
図３の構成によれば、本発明のデバイス管理部４がデバイス管理テーブル４６（図５）を参照し、挿されたデバイスの適／不適を判定することで、同一機種のデバイスが既にエニュメレーションされた状態で、２台目以後同一機種のデバイスが挿されると不適と判断し、ゲストＯＳ（９）のプラグアンドプレイマネジャ１４にプラグインイベントを通知しないので、２台目以後同一機種のデバイスのエニュメレーションを抑止できる。これにより、ミドルやアプリの誤作動や、デバイスのすり替えを防げる。また、当該デバイスはホストＯＳ（８）のポートリダイレクタ３が占有することで、ゲストＯＳ（９）やホストＯＳ（８）の他のドライバやミドル、アプリが制御できない隔離状態を実現している。
図４は本発明の第１の実施形態で別機種のデバイスが挿された時の処理手順を示す図である。
図４を用いて、他機種のデバイスを挿した後、ゲストＯＳないしＶＭ上の仮想バスでプラグアンドプレイするまでの処理を説明する。簡単のため、図１と重複する処理について説明を省略する。
図４を用いて、他機種のデバイスを挿した後、ゲストＯＳないしＶＭ上の仮想バスでプラグアンドプレイするまでの処理を説明する。簡単のため、図１と重複する処理について説明を省略する。
（別デバイスのプラグイン）
図４において、ゲストＯＳ（９）上のアプリＡ（７１１）ないしミドルＡ（７０１）がデバイスＡ（１４１）を制御している最中に、ホストＯＳ（８）がデバイスＢ（１４３）のプラグインを検知する。
図４において、ゲストＯＳ（９）上のアプリＡ（７１１）ないしミドルＡ（７０１）がデバイスＡ（１４１）を制御している最中に、ホストＯＳ（８）がデバイスＢ（１４３）のプラグインを検知する。
（エニュメレーションとデバイス追加処理）
ホストＯＳ（８）上でデバイスＢ（１４３）のエニュメレーションが進行すると、バスドライバ２にデバイスオブジェクト２０４が、ポートリダイレクタ３にデバイスオブジェクト３０４が作成される。また、デバイス追加処理でセッション番号としてセッション３が付与される。バスドライバ２はデバイス追加処理を終えるとデバイス管理部４にプラグインイベントを通知する。
ホストＯＳ（８）上でデバイスＢ（１４３）のエニュメレーションが進行すると、バスドライバ２にデバイスオブジェクト２０４が、ポートリダイレクタ３にデバイスオブジェクト３０４が作成される。また、デバイス追加処理でセッション番号としてセッション３が付与される。バスドライバ２はデバイス追加処理を終えるとデバイス管理部４にプラグインイベントを通知する。
（適・不適の判定と仮想ポートの特定）
プラグインイベントを受けたデバイス管理部４は、デバイスＢ（１４３）に関して、［１］受け渡されたデバイスディスクリプタが既知のデバイスのデバイスディスクリプタと一致し、［２］そのデバイスが予め許可されたポートに挿されていて、［３］仮想バス５に既にプラグアンドプレイされており、ｓｔａｒｔｅｄ状態である同一機種のデバイスが存在しない、という以上の３条件を満足するか確認する。満足されていると、エニュメレーションが妥当であることを意味し、デバイスディスクリプタからデバイスの機種を特定し、機種ごとに割り当てられた仮想ポートのポート番号を特定する。つまり、デバイス管理テーブル４６（図５参照）にその旨を登録する。図４においてデバイスＢ（１４３）の仮想ポートは仮想ポート３（４０２）である。
プラグインイベントを受けたデバイス管理部４は、デバイスＢ（１４３）に関して、［１］受け渡されたデバイスディスクリプタが既知のデバイスのデバイスディスクリプタと一致し、［２］そのデバイスが予め許可されたポートに挿されていて、［３］仮想バス５に既にプラグアンドプレイされており、ｓｔａｒｔｅｄ状態である同一機種のデバイスが存在しない、という以上の３条件を満足するか確認する。満足されていると、エニュメレーションが妥当であることを意味し、デバイスディスクリプタからデバイスの機種を特定し、機種ごとに割り当てられた仮想ポートのポート番号を特定する。つまり、デバイス管理テーブル４６（図５参照）にその旨を登録する。図４においてデバイスＢ（１４３）の仮想ポートは仮想ポート３（４０２）である。
（ゲストＯＳ上の仮想バスへのエニュメレーション）
プラグアンドプレイマネジャ１４はデバイス管理部４から代替デバイスディスクリプタを受け取り、レジストリファイル１５を検索して仮想バス５の上位にデバイスドライバとして、デバイスＢ本来のデバイスドライバであるデバドラＢ（６２）を特定する。デバドラＢ（６２）はメモリ上にロードされ、デバイスＢ（１４３）を制御するためのデバイス追加処理としてデバイスオブジェクト（５０３，６２１）が作成される。
プラグアンドプレイマネジャ１４はデバイス管理部４から代替デバイスディスクリプタを受け取り、レジストリファイル１５を検索して仮想バス５の上位にデバイスドライバとして、デバイスＢ本来のデバイスドライバであるデバドラＢ（６２）を特定する。デバドラＢ（６２）はメモリ上にロードされ、デバイスＢ（１４３）を制御するためのデバイス追加処理としてデバイスオブジェクト（５０３，６２１）が作成される。
（デバイス追加処理）
仮想ポート３（４０２）に仮想的に挿されたデバイスＢ（１４３）に関して、仮想バス５でデバイス追加処理が実行されるとデバイスオブジェクト５０３が作成される。そして、デバドラＢ（６２）でデバイス追加処理が実行されるとデバイスオブジェクト６２１が作成され、デバイスオブジェクト５０３とデバイスオブジェクト６２１とが互いにポインタを格納することで関連付けが完了し、デバイス追加処理が終了する。
仮想ポート３（４０２）に仮想的に挿されたデバイスＢ（１４３）に関して、仮想バス５でデバイス追加処理が実行されるとデバイスオブジェクト５０３が作成される。そして、デバドラＢ（６２）でデバイス追加処理が実行されるとデバイスオブジェクト６２１が作成され、デバイスオブジェクト５０３とデバイスオブジェクト６２１とが互いにポインタを格納することで関連付けが完了し、デバイス追加処理が終了する。
（セッション番号）
図４においてデバイスＢ（１４３）の接続後に付与されたセッション番号はセッション３となり、デバイスオブジェクト２０４，３０４，５０３，６２１が関連付けられる。このセッション番号での関連付けがなされてはじめて、上位のドライバであるデバドラＢ（６２）が受けたＩＲＰが最下位のバスドライバ２に受け渡される状態になり、ゲストＯＳ（９）はホストＯＳ８を介してデバイスＢ（１４３）を制御できる。これにより、ミドルＢ（７０２）とアプリＢ（７１２）はリセット後もデバイスＢ（１４２）を制御できる。
図４においてデバイスＢ（１４３）の接続後に付与されたセッション番号はセッション３となり、デバイスオブジェクト２０４，３０４，５０３，６２１が関連付けられる。このセッション番号での関連付けがなされてはじめて、上位のドライバであるデバドラＢ（６２）が受けたＩＲＰが最下位のバスドライバ２に受け渡される状態になり、ゲストＯＳ（９）はホストＯＳ８を介してデバイスＢ（１４３）を制御できる。これにより、ミドルＢ（７０２）とアプリＢ（７１２）はリセット後もデバイスＢ（１４２）を制御できる。
（効果）
図４の構成によれば、本発明のデバイス管理部４がデバイス管理テーブル４６（図５）を参照し、挿されたデバイスの適／不適を判定することで、既にエニュメレーションされたデバイスと挿されたデバイスとが別機種だと認識し、挿された別機種のデバイスについて適／不適を判定できるので、既にエニュメレーションされたデバイスに影響を及ぼさない。
図４の構成によれば、本発明のデバイス管理部４がデバイス管理テーブル４６（図５）を参照し、挿されたデバイスの適／不適を判定することで、既にエニュメレーションされたデバイスと挿されたデバイスとが別機種だと認識し、挿された別機種のデバイスについて適／不適を判定できるので、既にエニュメレーションされたデバイスに影響を及ぼさない。
（デバイス管理部の位置）
図１〜図５による説明の通り、本発明の第１の実施形態のデバイス管理部４はホストＯＳ（８）側に実装され、ＰＣのポートに挿されたＵＳＢデバイスの適・不適を判断し、不適の場合ゲストＯＳ（９）上の仮想バス５への当該デバイスのエニュメレーションを抑止し、当該デバイスを使用できなくしている。
本発明のデバイス管理部４はゲストＯＳ（９）側に実装しても、ポートリダイレクタ３からのプラグインイベントの通知は受けることはできる。よって、プラグインイベントで知らされたＰＣのポートに挿されたＵＳＢデバイスの適・不適を判断することができ、適と判断した場合ゲストＯＳ（９）上のプラグアンドプレイマネジャ１４と仮想バス５にプラグインを通知し、ゲストＯＳ（９）におけるエニュメレーションを許可できる。よって、デバイス管理部４をホストＯＳ（８），ゲストＯＳ（９）のいずれに実装してもかまわない。
また、ポートリダイレクタ３からのプラグインイベント、ゲストＯＳ（９）上のプラグアンドプレイマネジャ１４と仮想バス５へのプラグイン通知のいずれも仮想マシンバス（ＶＭ Ｂｕｓ）を通るので、本発明のデバイス管理部４を仮想マシンバスに実装してもかまわない。
図１〜図５による説明の通り、本発明の第１の実施形態のデバイス管理部４はホストＯＳ（８）側に実装され、ＰＣのポートに挿されたＵＳＢデバイスの適・不適を判断し、不適の場合ゲストＯＳ（９）上の仮想バス５への当該デバイスのエニュメレーションを抑止し、当該デバイスを使用できなくしている。
本発明のデバイス管理部４はゲストＯＳ（９）側に実装しても、ポートリダイレクタ３からのプラグインイベントの通知は受けることはできる。よって、プラグインイベントで知らされたＰＣのポートに挿されたＵＳＢデバイスの適・不適を判断することができ、適と判断した場合ゲストＯＳ（９）上のプラグアンドプレイマネジャ１４と仮想バス５にプラグインを通知し、ゲストＯＳ（９）におけるエニュメレーションを許可できる。よって、デバイス管理部４をホストＯＳ（８），ゲストＯＳ（９）のいずれに実装してもかまわない。
また、ポートリダイレクタ３からのプラグインイベント、ゲストＯＳ（９）上のプラグアンドプレイマネジャ１４と仮想バス５へのプラグイン通知のいずれも仮想マシンバス（ＶＭ Ｂｕｓ）を通るので、本発明のデバイス管理部４を仮想マシンバスに実装してもかまわない。
（ログの保存場所）
本発明の第１の実施形態において、図３の説明の通りデバイス管理部４が書き込んだログ４１はデバイス管理部４が動作しているホストＯＳ（８）がマウントしているストレージデバイスにファイルとして保存される。デバイス管理部４をゲストＯＳ（９）に実装した場合、ゲストＯＳ（９）がマウントしているストレージデバイスにファイルとして保存する。原理的にゲストＯＳ（９）は仮想マシンバス（ＶＭ Ｂｕｓ）を介してホストＯＳ（８）がマウントしているストレージデバイスにアクセス可能なので、ログ４１をゲストＯＳ（９）がマウントしているストレージデバイスに保存してもかまわない。
本発明の第１の実施形態において、図３の説明の通りデバイス管理部４が書き込んだログ４１はデバイス管理部４が動作しているホストＯＳ（８）がマウントしているストレージデバイスにファイルとして保存される。デバイス管理部４をゲストＯＳ（９）に実装した場合、ゲストＯＳ（９）がマウントしているストレージデバイスにファイルとして保存する。原理的にゲストＯＳ（９）は仮想マシンバス（ＶＭ Ｂｕｓ）を介してホストＯＳ（８）がマウントしているストレージデバイスにアクセス可能なので、ログ４１をゲストＯＳ（９）がマウントしているストレージデバイスに保存してもかまわない。
（効果）
デバイス管理部４をホストＯＳ（８）に実装するため、ログ４１をホストＯＳ（８）がマウントしているストレージデバイスに保存することで、ゲストＯＳ（９）が複数動作する環境でも、すべてのログ４１をホストＯＳ（８）が管理できる。
デバイス管理部４をホストＯＳ（８）に実装するため、ログ４１をホストＯＳ（８）がマウントしているストレージデバイスに保存することで、ゲストＯＳ（９）が複数動作する環境でも、すべてのログ４１をホストＯＳ（８）が管理できる。
≪第２の実施形態≫
次に、本発明の第２の実施形態について、図５と図６を用いて説明する。図中、２はバスのホストコントローラを制御するバスドライバ、３はポートリダイレクタ、４２はセキュア通信サービスのクライアントプログラム、４３はセキュア通信サービスのサーバプログラム、４４はデバイス管理部、４５はログ、４７はデバイス管理テーブル、５１は仮想バス、６１はデバドラＡ、８１はローカルＰＣ（ローカルマシン）、８２はリモートＰＣ（リモートマシン）、１１はルートハブ、１２，１６はプラグアンドプレイマネジャ（図中では、「Ｐ＆Ｐ Ｍｎｇｒ」と表記）、１３，１７は設定を格納するレジストリファイル、１０５はポート５、１０６はポート６、１４１はデバイスＡ、２０１、３０１、５１１、６１１はデバイスオブジェクト（図中では「ＤＯ」と表記）、４０１は仮想ポート１、７０１はデバイスＡの制御ミドルあるミドルＡ、７１１はデバイスＡを制御するアプリＡである。
次に、本発明の第２の実施形態について、図５と図６を用いて説明する。図中、２はバスのホストコントローラを制御するバスドライバ、３はポートリダイレクタ、４２はセキュア通信サービスのクライアントプログラム、４３はセキュア通信サービスのサーバプログラム、４４はデバイス管理部、４５はログ、４７はデバイス管理テーブル、５１は仮想バス、６１はデバドラＡ、８１はローカルＰＣ（ローカルマシン）、８２はリモートＰＣ（リモートマシン）、１１はルートハブ、１２，１６はプラグアンドプレイマネジャ（図中では、「Ｐ＆Ｐ Ｍｎｇｒ」と表記）、１３，１７は設定を格納するレジストリファイル、１０５はポート５、１０６はポート６、１４１はデバイスＡ、２０１、３０１、５１１、６１１はデバイスオブジェクト（図中では「ＤＯ」と表記）、４０１は仮想ポート１、７０１はデバイスＡの制御ミドルあるミドルＡ、７１１はデバイスＡを制御するアプリＡである。
図６は本発明の第２の実施形態のソフトウェアスタック構成を示す図であり、ローカルＰＣのポートに挿されたデバイスをデータセンタ内に設置されたリモートＰＣ上の仮想バスでプラグアンドプレイさせる処理手順を示す図である。
図６を用いて、ローカルＰＣにデバイスを挿した後、リモートＰＣ上の仮想バスでデバイスのプラグアンドプレイをするまでの処理を説明する。なお、本実施形態のローカルＰＣ、リモートＰＣは、第１の実施形態で説明したハードウェア構成を備え、以下に説明する情報処理を実現する。また、このローカルＰＣ、リモートＰＣは、前記情報処理を実現するのに必要なコードが記述されたデバイス管理用のプログラムを記憶している。
図６を用いて、ローカルＰＣにデバイスを挿した後、リモートＰＣ上の仮想バスでデバイスのプラグアンドプレイをするまでの処理を説明する。なお、本実施形態のローカルＰＣ、リモートＰＣは、第１の実施形態で説明したハードウェア構成を備え、以下に説明する情報処理を実現する。また、このローカルＰＣ、リモートＰＣは、前記情報処理を実現するのに必要なコードが記述されたデバイス管理用のプログラムを記憶している。
（デバイス）
図中デバイスＡ（１４１）はスキャナやプリンタ等のデバイスの機能を表す。具体的には、デバイスを挿すポートないしバスが規定するプラグアンドプレイに対応する機能、例えばデバイスディスクリプタの応答や、プリンタなら印刷と言ったデバイス本来の機能、電源状態に応じて節電運転する電源モード管理機能からなる。
図中デバイスＡ（１４１）はスキャナやプリンタ等のデバイスの機能を表す。具体的には、デバイスを挿すポートないしバスが規定するプラグアンドプレイに対応する機能、例えばデバイスディスクリプタの応答や、プリンタなら印刷と言ったデバイス本来の機能、電源状態に応じて節電運転する電源モード管理機能からなる。
（エニュメレーション）
ポート５（１０５）にデバイスＡ（１４１）が挿されると、ルートハブ１１がデバイスの挿入を検知し、プラグアンドプレイマネジャ１２にプラグインイベント（図中では「Plug-in」と表記）を通知する。ローカルＰＣ８１のプラグアンドプレイマネジャ１２はバスドライバ２にポート５（１０５）に対し、デバイスＡ（１４１）がプラグインした旨伝達し、ポート５（１０５）に挿したデバイスＡ（１４１）からデバイスディスクリプタを読み出し、レジストリファイル１３を検索してバスドライバ２の上位にデバイスドライバをロードする。図６において、レジストリファイル１３に記載されているデバイスＡ(１４１)のデバイスドライバはポートリダイレクタ３である。レジストリファイル１３にはデバイスのインストール時に、デバイスディスクリプタの情報とデバイスドライバの名称と所在等情報が記載ないし格納されており、これら情報を参照することでロードすべきデバイスドライバを特定することができる。ローカルＰＣ８１において、ポートリダイレクタ３はすでにメモリ上にロードされているのでロードは省略し、ポートリダイレクタ３を初期化してデバイスＡ（１４１）を制御するためのデバイス追加処理としてデバイスオブジェクト（２０１，３０１）がポートリダイレクタ３とバスドライバ２に作成される。
ポート５（１０５）にデバイスＡ（１４１）が挿されると、ルートハブ１１がデバイスの挿入を検知し、プラグアンドプレイマネジャ１２にプラグインイベント（図中では「Plug-in」と表記）を通知する。ローカルＰＣ８１のプラグアンドプレイマネジャ１２はバスドライバ２にポート５（１０５）に対し、デバイスＡ（１４１）がプラグインした旨伝達し、ポート５（１０５）に挿したデバイスＡ（１４１）からデバイスディスクリプタを読み出し、レジストリファイル１３を検索してバスドライバ２の上位にデバイスドライバをロードする。図６において、レジストリファイル１３に記載されているデバイスＡ(１４１)のデバイスドライバはポートリダイレクタ３である。レジストリファイル１３にはデバイスのインストール時に、デバイスディスクリプタの情報とデバイスドライバの名称と所在等情報が記載ないし格納されており、これら情報を参照することでロードすべきデバイスドライバを特定することができる。ローカルＰＣ８１において、ポートリダイレクタ３はすでにメモリ上にロードされているのでロードは省略し、ポートリダイレクタ３を初期化してデバイスＡ（１４１）を制御するためのデバイス追加処理としてデバイスオブジェクト（２０１，３０１）がポートリダイレクタ３とバスドライバ２に作成される。
（デバイスオブジェクト）
デバイスオブジェクト（２０１，３０１）はデバイスがプラグアンドプレイされる度にデバイス毎にバスドライバとデバイスドライバ（ローカルＰＣ８１においては、ポートリダイレクタ３）に作成される。デバイスオブジェクト（２０１，３０１）にはデバイスを制御する際の電文（コマンドとデータ）を格納するバッファへのポインタと、電文を処理するコードを指し示すポインタと、対応するデバイスオブジェクト（２０１，３０１）を指し示すポインタとが格納される。
デバイスドライバであってもバスドライバであっても、一般的にドライバは入出力リクエストパケット（ＩＲＰ）をＩ／Ｏマネージャ（不図示）から受け取ると、ＩＲＰに対応するデバイスのデバイスオブジェクト（２０１，３０１）を参照し、処理した上で、上位ないし下位のドライバにＩＲＰを受け渡しデバイスの制御を実現する。
デバイスオブジェクト（２０１，３０１）はデバイスがプラグアンドプレイされる度にデバイス毎にバスドライバとデバイスドライバ（ローカルＰＣ８１においては、ポートリダイレクタ３）に作成される。デバイスオブジェクト（２０１，３０１）にはデバイスを制御する際の電文（コマンドとデータ）を格納するバッファへのポインタと、電文を処理するコードを指し示すポインタと、対応するデバイスオブジェクト（２０１，３０１）を指し示すポインタとが格納される。
デバイスドライバであってもバスドライバであっても、一般的にドライバは入出力リクエストパケット（ＩＲＰ）をＩ／Ｏマネージャ（不図示）から受け取ると、ＩＲＰに対応するデバイスのデバイスオブジェクト（２０１，３０１）を参照し、処理した上で、上位ないし下位のドライバにＩＲＰを受け渡しデバイスの制御を実現する。
（デバイス追加処理）
ポート５（１０５）に挿したデバイスＡ（１４１）に関して、バスドライバ２でデバイス追加処理が実行されるとデバイスオブジェクト２０１が作成され、ポートリダイレクタ３でデバイス追加処理が実行されるとデバイスオブジェクト３０１が作成される。そして、デバイスオブジェクト２０１とデバイスオブジェクト３０１とが互いにポインタを格納することで関連付けが完了し、デバイス追加処理が終了する。ポートリダイレクタ３はデバイスオブジェクト３０１を作成した際、デバイスオブジェクト３０１にセッション番号を付与し、デバイスオブジェクトを識別する。デバイスオブジェクト３０１にはセッション１が付与される。
ポート５（１０５）に挿したデバイスＡ（１４１）に関して、バスドライバ２でデバイス追加処理が実行されるとデバイスオブジェクト２０１が作成され、ポートリダイレクタ３でデバイス追加処理が実行されるとデバイスオブジェクト３０１が作成される。そして、デバイスオブジェクト２０１とデバイスオブジェクト３０１とが互いにポインタを格納することで関連付けが完了し、デバイス追加処理が終了する。ポートリダイレクタ３はデバイスオブジェクト３０１を作成した際、デバイスオブジェクト３０１にセッション番号を付与し、デバイスオブジェクトを識別する。デバイスオブジェクト３０１にはセッション１が付与される。
（セキュア通信）
本発明の第２の実施形態においてローカルＰＣ８１はデータセンタ内に設置されたリモートＰＣ８２とセキュア通信サービスで接続される。セキュア通信サービスはサーバプログラム４３がリモートＰＣ８２に、クライアントプログラム４２がローカルＰＣ８１にそれぞれＯＳのサービスとして常駐している。ローカルＰＣ８１の起動後、クライアントプログラム４２が常駐すると、リモートＰＣ８２を探索し、リモートＰＣ８２で常駐するサーバプログラム４３に接続し通信路を確立する。
本発明の第２の実施形態においてローカルＰＣ８１はデータセンタ内に設置されたリモートＰＣ８２とセキュア通信サービスで接続される。セキュア通信サービスはサーバプログラム４３がリモートＰＣ８２に、クライアントプログラム４２がローカルＰＣ８１にそれぞれＯＳのサービスとして常駐している。ローカルＰＣ８１の起動後、クライアントプログラム４２が常駐すると、リモートＰＣ８２を探索し、リモートＰＣ８２で常駐するサーバプログラム４３に接続し通信路を確立する。
（デバイス管理部へのプラグインイベント通知）
デバイス追加処理が成功し、完了すると、ローカルＰＣ８１のポートリダイレクタ３は、リモートＰＣ８２のデバイス管理部４４に対し、セキュア通信が確立した通信を介して、ポート５(１０５)にデバイスがプラグインされた旨を示すイベントを通知し、当該デバイスディスクリプタとセッション番号を受け渡し、処理を終了する。
デバイス追加処理が成功し、完了すると、ローカルＰＣ８１のポートリダイレクタ３は、リモートＰＣ８２のデバイス管理部４４に対し、セキュア通信が確立した通信を介して、ポート５(１０５)にデバイスがプラグインされた旨を示すイベントを通知し、当該デバイスディスクリプタとセッション番号を受け渡し、処理を終了する。
（デバイス放置）
ポートリダイレクタ３はデバイス追加処理とデバイス削除処理と電文の中継処理に機能が限定されるので、この後自発的にデバイスＡ（１４１）を制御することは無い。そのため、デバイスＡ（１４１）は初期化ないし活性化されないまま、ポート５（１０５）につながった状態で初期化ないし活性化を待ち続ける。
ポートリダイレクタ３はデバイス追加処理とデバイス削除処理と電文の中継処理に機能が限定されるので、この後自発的にデバイスＡ（１４１）を制御することは無い。そのため、デバイスＡ（１４１）は初期化ないし活性化されないまま、ポート５（１０５）につながった状態で初期化ないし活性化を待ち続ける。
（適・不適の判定と仮想ポートの特定）
プラグインイベントを受けたデバイス管理部４４はデバイス管理テーブル（第２の実施形態では、符号４７。図５参照）を参照し、［１］受け渡されたデバイスディスクリプタが既知のデバイスのデバイスディスクリプタと一致し、［２］そのデバイスが予め許可されたポートに挿されていて、［３］仮想バス５に既にプラグアンドプレイされており、ｓｔａｒｔｅｄ状態である同一機種のデバイスが存在しない、という以上の３条件を満足するか確認する。条件が満足していると、エニュメレーションが妥当であることを意味し、デバイスディスクリプタからデバイスの機種を特定し、機種ごとに割り当てられた仮想ポートのポート番号を特定する。図６においてデバイスＡ（１４１）の仮想ポートは仮想ポート１（４０１）である。
プラグインイベントを受けたデバイス管理部４４はデバイス管理テーブル（第２の実施形態では、符号４７。図５参照）を参照し、［１］受け渡されたデバイスディスクリプタが既知のデバイスのデバイスディスクリプタと一致し、［２］そのデバイスが予め許可されたポートに挿されていて、［３］仮想バス５に既にプラグアンドプレイされており、ｓｔａｒｔｅｄ状態である同一機種のデバイスが存在しない、という以上の３条件を満足するか確認する。条件が満足していると、エニュメレーションが妥当であることを意味し、デバイスディスクリプタからデバイスの機種を特定し、機種ごとに割り当てられた仮想ポートのポート番号を特定する。図６においてデバイスＡ（１４１）の仮想ポートは仮想ポート１（４０１）である。
（いつも同じポートに同じデバイスが挿抜されたと通知）
デバイス管理部４４は、デバイス管理テーブル４７を参照して、リモートＰＣ８２のＯＳのプラグアンドプレイマネジャ１６に、挿抜されたデバイスに対応する代替デバイスディスクリプタと仮想ポートを通知する。これにより、プラグアンドプレイマネジャ１６は初回のインストール時に仮想ポート番号と代替デバイスディスクリプタの情報をレジストリファイル１７に書き込む。以後、リモートＰＣ８２において、同じポートに同じデバイスが挿抜されたと認識する。
デバイス管理部４４は、デバイス管理テーブル４７を参照して、リモートＰＣ８２のＯＳのプラグアンドプレイマネジャ１６に、挿抜されたデバイスに対応する代替デバイスディスクリプタと仮想ポートを通知する。これにより、プラグアンドプレイマネジャ１６は初回のインストール時に仮想ポート番号と代替デバイスディスクリプタの情報をレジストリファイル１７に書き込む。以後、リモートＰＣ８２において、同じポートに同じデバイスが挿抜されたと認識する。
（プラグインイベント通知）
リモートＰＣ上のデバイス管理部４４はプラグアンドプレイマネジャ１６に対してプラグインイベント（図中では「Plug-in」と表記）を通知する。通知の際、デバイスＡ（１４１）が挿されているポートは、先に特定した仮想ポート１（４０１）に置き換えて通知する。プラグアンドプレイマネジャ１６は仮想バス５１に、仮想ポート１（４０１）にデバイスＡ（１４１）がプラグインした旨通知する。
リモートＰＣ上のデバイス管理部４４はプラグアンドプレイマネジャ１６に対してプラグインイベント（図中では「Plug-in」と表記）を通知する。通知の際、デバイスＡ（１４１）が挿されているポートは、先に特定した仮想ポート１（４０１）に置き換えて通知する。プラグアンドプレイマネジャ１６は仮想バス５１に、仮想ポート１（４０１）にデバイスＡ（１４１）がプラグインした旨通知する。
（仮想バスへのエニュメレーション）
プラグアンドプレイマネジャ１６はデバイス管理部４４から代替デバイスディスクリプタを受け取り、レジストリファイル１７を検索して仮想バス５１の上位にデバイスドライバとしてデバイスＡ本来のデバイスドライバであるデバドラＡ（６１）をロードする。デバドラＡ（６１）はメモリ上にロードされ、初期化の後、デバイスＡ（１４１）を制御するためのデバイス追加処理としてデバイスオブジェクト（５０１，６０１）が作成される。
プラグアンドプレイマネジャ１６はデバイス管理部４４から代替デバイスディスクリプタを受け取り、レジストリファイル１７を検索して仮想バス５１の上位にデバイスドライバとしてデバイスＡ本来のデバイスドライバであるデバドラＡ（６１）をロードする。デバドラＡ（６１）はメモリ上にロードされ、初期化の後、デバイスＡ（１４１）を制御するためのデバイス追加処理としてデバイスオブジェクト（５０１，６０１）が作成される。
（デバイス追加処理）
仮想ポート１（４０１）に仮想的に挿されたデバイスＡ（１４１）に関して、仮想バス５１でデバイス追加処理が実行されるとデバイスオブジェクト５１１が作成される。そして、デバドラＡ（６１）でデバイス追加処理が実行されるとデバイスオブジェクト６１１が作成され、デバイスオブジェクト５１１とデバイスオブジェクト６１１とが互いにポインタを格納することで関連付けが完了し、デバイス追加処理が終了する。
仮想ポート１（４０１）に仮想的に挿されたデバイスＡ（１４１）に関して、仮想バス５１でデバイス追加処理が実行されるとデバイスオブジェクト５１１が作成される。そして、デバドラＡ（６１）でデバイス追加処理が実行されるとデバイスオブジェクト６１１が作成され、デバイスオブジェクト５１１とデバイスオブジェクト６１１とが互いにポインタを格納することで関連付けが完了し、デバイス追加処理が終了する。
（セッション番号）
デバイス管理部４４はプラグアンドプレイマネジャ１６に通知した情報（デバイスディスクリプタと仮想ポート番号）とセッション番号を、仮想バス５１に通知する（図示せず）。仮想バス５１はセッション番号としてセッション１を受け取り、デバイスオブジェクト５０１にセッション１を付与する。
付与されたセッション番号はサーバプログラム４３がクライアントプログラム４２との間のセキュア通信で照会し、セッション１の通信セッションを確立する。確立した通信セッションとデバイスオブジェクト２０１，３０１，５１１，６１１がセッション番号で関連付けられる。このセッション番号での関連付けがなされてはじめて、上位のドライバであるデバドラＡ（６１）が受けたＩＲＰが最下位のバスドライバ２に受け渡される状態になり、リモートＰＣ８２はローカルＰＣ８１を介してデバイスＡ（１４１）を制御できる。
デバイス管理部４４はプラグアンドプレイマネジャ１６に通知した情報（デバイスディスクリプタと仮想ポート番号）とセッション番号を、仮想バス５１に通知する（図示せず）。仮想バス５１はセッション番号としてセッション１を受け取り、デバイスオブジェクト５０１にセッション１を付与する。
付与されたセッション番号はサーバプログラム４３がクライアントプログラム４２との間のセキュア通信で照会し、セッション１の通信セッションを確立する。確立した通信セッションとデバイスオブジェクト２０１，３０１，５１１，６１１がセッション番号で関連付けられる。このセッション番号での関連付けがなされてはじめて、上位のドライバであるデバドラＡ（６１）が受けたＩＲＰが最下位のバスドライバ２に受け渡される状態になり、リモートＰＣ８２はローカルＰＣ８１を介してデバイスＡ（１４１）を制御できる。
（ログ）
デバイス管理部４４は、デバイスのエニュメレーションを不適と判断した際に、判断材料となったデバイスディスクリプタとポート番号とデバイスＡ（１４１）のデバイスディスクリプタと判断結果と判断した時刻をログ４５に書き込む。
そのほかに、サーバプログラム４３は、セキュア通信サービスの起動・停止・異常処理の際、発生した事象に関する情報をログ４５に書き込む。
デバイス管理部４４は、デバイスのエニュメレーションを不適と判断した際に、判断材料となったデバイスディスクリプタとポート番号とデバイスＡ（１４１）のデバイスディスクリプタと判断結果と判断した時刻をログ４５に書き込む。
そのほかに、サーバプログラム４３は、セキュア通信サービスの起動・停止・異常処理の際、発生した事象に関する情報をログ４５に書き込む。
（デバイス管理部の位置）
図６の説明の通り、本発明の第２の実施形態のデバイス管理部４４はリモートＰＣ８２に実装され、ローカルＰＣ８１のポートに挿されたＵＳＢデバイスの適・不適を判断し、不適の場合リモートＰＣ８２の仮想バス５１への当該デバイスのエニュメレーションを抑止し、当該デバイスを使用できなくしている。
本発明のデバイス管理部４４はローカルＰＣ８１に実装しても、ポートリダイレクタ３からのプラグインイベントの通知は受けることはできる。よって、プラグインイベントで知らされたポートに挿されたＵＳＢデバイスの適・不適を判断でき、適と判断した場合リモートＰＣ８２上のプラグアンドプレイマネジャ１６と仮想バス５１にプラグインを通知し、リモートＰＣ８２におけるエニュメレーションを許可できる。よって、デバイス管理部４４をローカルＰＣ８１，リモートＰＣ８２のいずれに実装してもかまわない。
図６の説明の通り、本発明の第２の実施形態のデバイス管理部４４はリモートＰＣ８２に実装され、ローカルＰＣ８１のポートに挿されたＵＳＢデバイスの適・不適を判断し、不適の場合リモートＰＣ８２の仮想バス５１への当該デバイスのエニュメレーションを抑止し、当該デバイスを使用できなくしている。
本発明のデバイス管理部４４はローカルＰＣ８１に実装しても、ポートリダイレクタ３からのプラグインイベントの通知は受けることはできる。よって、プラグインイベントで知らされたポートに挿されたＵＳＢデバイスの適・不適を判断でき、適と判断した場合リモートＰＣ８２上のプラグアンドプレイマネジャ１６と仮想バス５１にプラグインを通知し、リモートＰＣ８２におけるエニュメレーションを許可できる。よって、デバイス管理部４４をローカルＰＣ８１，リモートＰＣ８２のいずれに実装してもかまわない。
（ログの保存場所）
本発明の第２の実施形態において、図６の説明の通りデバイス管理部４４が書き込んだログ４５はデバイス管理部４４が動作しているリモートＰＣ８２がマウントしているストレージデバイスにファイルとして保存される。デバイス管理部４４をローカルＰＣ８１に実装した場合、ローカルＰＣ８１がマウントしているストレージデバイスにファイルとして保存する。原理的にローカルＰＣ８１はネットワーク越しにリモートＰＣ８２がマウントしているストレージデバイスにアクセス可能なので、ログ４５をリモートＰＣ８２がマウントしているストレージデバイスに保存してもかまわない。
本発明の第２の実施形態において、図６の説明の通りデバイス管理部４４が書き込んだログ４５はデバイス管理部４４が動作しているリモートＰＣ８２がマウントしているストレージデバイスにファイルとして保存される。デバイス管理部４４をローカルＰＣ８１に実装した場合、ローカルＰＣ８１がマウントしているストレージデバイスにファイルとして保存する。原理的にローカルＰＣ８１はネットワーク越しにリモートＰＣ８２がマウントしているストレージデバイスにアクセス可能なので、ログ４５をリモートＰＣ８２がマウントしているストレージデバイスに保存してもかまわない。
（効果）
図６の構成によれば、本発明のデバイス管理部４４がデバイス管理テーブル４７（図５）を参照し、挿されたデバイスの適／不適を判定することで、適と判断した場合には、リモートＰＣ８２のプラグアンドプレイマネジャ１４にプラグインイベントを通知し、リモートＰＣ８２におけるエニュメレーションを許可できる。不適と判断した場合にはリモートＰＣ８２のＯＳのプラグアンドプレイマネジャ１６にプラグインイベントを通知しないのでエニュメレーションを抑止できる。また、当該デバイスはローカルＰＣ８１のポートリダイレクタ３が占有することで、ローカルＰＣ８１やリモートＰＣ８２の他のドライバやミドル、アプリが制御できない隔離状態を実現している。
図６の構成によれば、本発明のデバイス管理部４４がデバイス管理テーブル４７（図５）を参照し、挿されたデバイスの適／不適を判定することで、適と判断した場合には、リモートＰＣ８２のプラグアンドプレイマネジャ１４にプラグインイベントを通知し、リモートＰＣ８２におけるエニュメレーションを許可できる。不適と判断した場合にはリモートＰＣ８２のＯＳのプラグアンドプレイマネジャ１６にプラグインイベントを通知しないのでエニュメレーションを抑止できる。また、当該デバイスはローカルＰＣ８１のポートリダイレクタ３が占有することで、ローカルＰＣ８１やリモートＰＣ８２の他のドライバやミドル、アプリが制御できない隔離状態を実現している。
デバイス管理部４４が適を判定しリモートＰＣ８２のプラグアンドプレイマネジャにプラグインイベントを通知する際、デバイス種別ないし機種毎に割り当てられた仮想ポート番号を通知することで、リモートＰＣ８２のプラグアンドプレイマネジャ１６やアプリやミドルにはいつも同じポートにデバイスが挿されたように見せることができる。これにより、デバイスを不意にローカルＰＣ８１の別のポートに挿してもプラグアンドプレイマネジャ１６は同じポートに挿したと認識するので、デバイスのインストール回数は１機種あたり１回で済ませられる。これにより、アプリケーションやミドルはデバイスが挿されたポートを検索する手間も省ける。
デバイス管理テーブル４７にデバイス毎に挿しても良いポートが記載されていることで、不意に別の許可されていないポートに挿した場合、エニュメレーションは抑止される。これにより、利用者はデバイスを間違ったポートに挿したと認識できる。
第２の実施形態のように本発明をリモートアクセスに適用する場合、デバイス管理部４４をリモートＰＣ８２に実装する構成で、ログ４５をリモートＰＣ８２がマウントしているストレージデバイスに保存する。これにより、ローカルＰＣ８１が遠隔地の複数の拠点で複数台動作する状況でも、すべてのログ４５をセンタ内のリモートＰＣ８２ないしセンタ内のストレージデバイスに保存するので、センタ側でログを一括管理できる。よって、センタ側でデバイスの状態（接続状況や障害発生状況）が把握できる。
≪その他≫
なお、前記した実施形態は、本発明を実施するための好適なものであるが、その実施形式はこれらに限定されるものではなく、本発明の要旨を逸脱しない範囲内において種々変形することが可能である。
例えば、ハードウェア、ソフトウェア、等の具体的な構成について、本発明の趣旨を逸脱しない範囲で適宜変更が可能である。
なお、前記した実施形態は、本発明を実施するための好適なものであるが、その実施形式はこれらに限定されるものではなく、本発明の要旨を逸脱しない範囲内において種々変形することが可能である。
例えば、ハードウェア、ソフトウェア、等の具体的な構成について、本発明の趣旨を逸脱しない範囲で適宜変更が可能である。
２…バスのホストコントローラを制御するバスドライバ
３…ポートリダイレクタ
４、４４…デバイス管理部（デバイス管理機能）
４２…セキュア通信サービスのクライアントプログラム
４３…セキュア通信サービスのサーバプログラム
４１、４５…ログ
４６、４７…デバイス管理テーブル（許可リストを含む）
５、５１…仮想バス
６、６１…デバドラＡ
８…ＰＣ上のホストＯＳ（ローカルマシン）
９…ホストＯＳが提供する仮想マシン実行環境で動作するゲストＯＳ（リモートマシン）
８１…ローカルＰＣ（ローカルマシン）
８２…リモートＰＣ（リモートマシン）
１１…ルートハブ
１２、１４、１６…プラグアンドプレイマネジャ
１３、１５、１７…設定を格納するレジストリファイル
１０５…ポート５
１０６…ポート６
１４１、１４２…デバイスＡ
２０１、３０１、５０１、５１１、６０１、６１１…デバイスオブジェクト
４０１、４０２…仮想ポート１、３
７０１…ミドルＡ
７１１…アプリＡ
３…ポートリダイレクタ
４、４４…デバイス管理部（デバイス管理機能）
４２…セキュア通信サービスのクライアントプログラム
４３…セキュア通信サービスのサーバプログラム
４１、４５…ログ
４６、４７…デバイス管理テーブル（許可リストを含む）
５、５１…仮想バス
６、６１…デバドラＡ
８…ＰＣ上のホストＯＳ（ローカルマシン）
９…ホストＯＳが提供する仮想マシン実行環境で動作するゲストＯＳ（リモートマシン）
８１…ローカルＰＣ（ローカルマシン）
８２…リモートＰＣ（リモートマシン）
１１…ルートハブ
１２、１４、１６…プラグアンドプレイマネジャ
１３、１５、１７…設定を格納するレジストリファイル
１０５…ポート５
１０６…ポート６
１４１、１４２…デバイスＡ
２０１、３０１、５０１、５１１、６０１、６１１…デバイスオブジェクト
４０１、４０２…仮想ポート１、３
７０１…ミドルＡ
７１１…アプリＡ
Claims (10)
- リモートマシン上の仮想バスとプラグアンドプレイマネジャと、ローカルマシンおよびローカルマシンに接続されるデバイスとデバイスの接続を検知する手段と、前記リモートマシンないし前記ローカルマシンのいずれかに搭載するデバイス管理機能から構成されるバスシステムであって、
前記ローカルマシンに前記デバイスを接続すると前記デバイスの接続を検知する手段が前記デバイス管理機能に接続を通知し、前記デバイス管理機能は許可リストと他のデバイスの接続状態を登録するデバイス管理テーブルを参照しエニュメレーションの可否を判断し、可と判断すると前記プラグアンドプレイマネジャが前記仮想バス上でエニュメレーションを実行することを特徴とする仮想バスシステム。 - 請求項１記載の前記デバイスの接続を検知する手段であって、
接続を検知した前記デバイスの前記ローカルマシンにおける接続位置を認識し、
前記デバイスから前記デバイスのディスクリプタ情報を読み出し、
前記デバイスのディクリプタ情報と前記接続位置を前記デバイス管理機能に通知することを特徴とした仮想バスシステム。 - 請求項２記載の前記デバイスから読み出した前記デバイスのディスクリプタ情報には前記デバイスの固体識別番号を含むことを特徴とする仮想バスシステム。
- 請求項１記載の前記許可リストであって前記許可リストには接続を許可されたデバイスのディスクリプタ情報と、接続を許可されたローカルマシンにおける接続位置と、前記デバイスの機種毎に付与される固定値のインスタンスＩＤとディスクリプタ情報が記載されていることを特徴とする仮想バスシステム。
- 請求項１記載の前記デバイス管理機能であって、前記ローカルマシンに接続されたデバイスのディスクリプタが前記許可リストに記載され、且つ、前記許可リストに記載された接続を許可されたローカルマシンにおける接続位置に接続され、且つ、前記ローカルマシンに前記デバイスが同一機種で唯一接続されている場合、接続を許可することを特徴とする仮想バスシステム。
- 請求項１記載の前記デバイス管理機能であって、前記デバイス管理機能は前記プラグアンドプレイマネジャに、前記許可リストに記載された前記デバイスの機種毎に付与される固定値のインスタンスＩＤとディスクリプタ情報を通知し、エニュメレーションを実行させることを特徴とする仮想バスシステム。
- 請求項２記載のローカルマシンにおける接続位置であって、前記ローカルマシンのポートの識別子によりローカルマシンにおける接続位置を認識することを特徴とした仮想バスシステム。
- 仮想化環境を実現する１以上のコンピュータ上で構成されるローカルマシンとリモートマシンとが仮想的に接続される仮想バスシステムにおいて、
前記コンピュータの記憶部は、
前記ローカルマシンが備える実ポートに挿入されるデバイスに関し、少なくとも、前記リモートマシンに通知する代替デバイスディスクリプタ、当該デバイスの挿入が予め許可された実ポートの実ポート番号、および前記リモートマシンが前記デバイスを制御するために仮想的に生成される仮想ポートの仮想ポート番号が登録されるデバイス管理テーブルを記憶しており、
前記コンピュータの制御部は、
前記ローカルマシンが備える実ポートにデバイスが挿入されたとき、前記挿入されたデバイスのデバイスディスクリプタを取得する制御と、
前記取得したデバイスディスクリプタにより、前記デバイス管理テーブルを参照して、前記挿入されたデバイスに関する前記デバイス管理テーブルの登録はすでになされており、前記デバイスは予め許可された実ポートに挿入されており、前記挿入されたデバイスと同種のデバイスが前記実ポートに挿入されていない、という条件を満たすか否かを判定する制御と、
前記条件を満たしていれば、前記デバイス管理テーブルに登録されている、前記挿入されたデバイスの前記代替デバイスディスクリプタおよび前記仮想ポート番号を前記リモートマシンに通知し、前記リモートマシンにおける前記挿入されたデバイスのエニュメレーションを許可する制御と、
前記条件を満たしていなければ、前記デバイス管理テーブルに登録されている、前記挿入されたデバイスの前記代替デバイスディスクリプタおよび前記仮想ポート番号を前記リモートマシンに通知せず、前記リモートマシンにおける前記挿入されたデバイスのエニュメレーションを抑止する制御と、を実行する
ことを特徴とする仮想バスシステム。 - 前記制御部は、
前記リモートマシンによる、前記挿入されたデバイスのリセットおよび再起動が実行されたとき、前記ローカルマシンが備える実ポートに挿入されたデバイスと同種のデバイスが別の実ポートに挿入されたとき、または前記ローカルマシンが備える実ポートに挿入されたデバイスと別種のデバイスが別の実ポートに挿入されたとき、前記条件を満たすか否かを判定する制御を実行する
ことを特徴とする請求項８に記載の仮想バスシステム。 - 仮想化環境を実現する１以上のコンピュータ上で構成されるローカルマシンとリモートマシンとが仮想的に接続される仮想バスシステムにおけるデバイス管理方法において、
前記コンピュータの記憶部は、
前記ローカルマシンが備える実ポートに挿入されるデバイスに関し、少なくとも、前記リモートマシンに通知する代替デバイスディスクリプタ、当該デバイスの挿入が予め許可された実ポートの実ポート番号、および前記リモートマシンが前記デバイスを制御するために仮想的に生成される仮想ポートの仮想ポート番号が登録されるデバイス管理テーブルを記憶しており、
前記コンピュータの制御部は、
前記ローカルマシンが備える実ポートにデバイスが挿入されたとき、前記挿入されたデバイスのデバイスディスクリプタを取得するステップと、
前記取得したデバイスディスクリプタにより、前記デバイス管理テーブルを参照して、前記挿入されたデバイスに関する前記デバイス管理テーブルの登録はすでになされており、前記デバイスは予め許可された実ポートに挿入されており、前記挿入されたデバイスと同種のデバイスが前記実ポートに挿入されていない、という条件を満たすか否かを判定するステップと、
前記条件を満たしていれば、前記デバイス管理テーブルに登録されている、前記挿入されたデバイスの前記代替デバイスディスクリプタおよび前記仮想ポート番号を前記リモートマシンに通知し、前記リモートマシンにおける前記挿入されたデバイスのエニュメレーションを許可するステップと、
前記条件を満たしていなければ、前記デバイス管理テーブルに登録されている、前記挿入されたデバイスの前記代替デバイスディスクリプタおよび前記仮想ポート番号を前記リモートマシンに通知せず、前記リモートマシンにおける前記挿入されたデバイスのエニュメレーションを抑止するステップと、を実行する
ことを特徴とするデバイス管理方法。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2010005047A JP2011145827A (ja) | 2010-01-13 | 2010-01-13 | 仮想バスシステム、およびデバイス管理方法 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2010005047A JP2011145827A (ja) | 2010-01-13 | 2010-01-13 | 仮想バスシステム、およびデバイス管理方法 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| JP2011145827A true JP2011145827A (ja) | 2011-07-28 |
Family
ID=44460631
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2010005047A Pending JP2011145827A (ja) | 2010-01-13 | 2010-01-13 | 仮想バスシステム、およびデバイス管理方法 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP2011145827A (ja) |
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2013200690A (ja) * | 2012-03-23 | 2013-10-03 | Fujitsu Ltd | 処理システム、機器管理装置、及びプログラム |
| JP2017107445A (ja) * | 2015-12-10 | 2017-06-15 | 日本電信電話株式会社 | 情報処理装置、接続デバイス識別方法およびプログラム |
| US10157163B2 (en) | 2014-06-12 | 2018-12-18 | Nec Corporation | Computer system, connection management method for remote device, and program recording medium |
-
2010
- 2010-01-13 JP JP2010005047A patent/JP2011145827A/ja active Pending
Cited By (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2013200690A (ja) * | 2012-03-23 | 2013-10-03 | Fujitsu Ltd | 処理システム、機器管理装置、及びプログラム |
| US9253039B2 (en) | 2012-03-23 | 2016-02-02 | Fujitsu Limited | Device management system and device management apparatus |
| US10157163B2 (en) | 2014-06-12 | 2018-12-18 | Nec Corporation | Computer system, connection management method for remote device, and program recording medium |
| JP2017107445A (ja) * | 2015-12-10 | 2017-06-15 | 日本電信電話株式会社 | 情報処理装置、接続デバイス識別方法およびプログラム |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US11151225B2 (en) | License management in pre-boot environments | |
| JP4805116B2 (ja) | 情報処理システム、情報処理システムの制御方法、サービス利用装置及びサービス提供装置 | |
| KR101453266B1 (ko) | 서비스 프로세서 컴플렉스 내의 데이터 저장을 위한 요구 기반 ｕｓｂ 프록시 | |
| US8997090B2 (en) | Installing an operating system in a host system | |
| US7930371B2 (en) | Deployment method and system | |
| JP6067771B2 (ja) | ネットワークインターフェースコントローラ情報の帯域外取得 | |
| JP5333579B2 (ja) | 管理サーバ、ブートサーバ、ネットワークブートシステムおよびネットワークブート方法 | |
| US9912535B2 (en) | System and method of performing high availability configuration and validation of virtual desktop infrastructure (VDI) | |
| JP2010152704A (ja) | 計算機システムの運用管理システム及び管理方法 | |
| US8874891B2 (en) | Systems and methods for activation of applications using client-specific data | |
| US20110296404A1 (en) | Systems and methods for host-level distributed scheduling in a distributed environment | |
| JP2009140194A (ja) | 障害回復環境の設定方法 | |
| JP2008532161A (ja) | ドライバのインストール | |
| US20110083004A1 (en) | Performing recovery of a headless computer | |
| WO2016062146A1 (zh) | 序列号信息的更新方法、装置及终端 | |
| JP2010219725A (ja) | ネットワーク装置および外部記憶装置をネットワーク上に公開する方法 | |
| US20220244942A1 (en) | Selecting and sending subset of components to computing device prior to operating system install | |
| US9058231B2 (en) | Deployment of operating systems with detection of loop conditions | |
| JP2007183837A (ja) | 環境設定プログラム、環境設定システムおよび環境設定方法 | |
| JP2011145827A (ja) | 仮想バスシステム、およびデバイス管理方法 | |
| JP4982454B2 (ja) | 情報処理方法および情報処理システム | |
| JP2016025656A (ja) | Ｉｐアドレスの帯域外設定 | |
| JP2023544001A (ja) | アクセラレータカードのセキュリティモードの静的構成 | |
| JP7084160B2 (ja) | 起動制御装置、起動制御システム、起動制御方法、及び、起動制御プログラム | |
| JP6051798B2 (ja) | ファームウェア検証システム、ファームウェア検証方法およびファームウェア検証プログラム |