SCVMM の落とし穴 – 番外編


こんにちは。 システムセンター サポートの住です。

これまでにSCVMM の管理者が遭遇しやすい障害状況などを 「SCVMM の落とし穴」 としてご紹介してきました。
過去の投稿についてはこちらをご覧ください。

今回は「番外編」として、必ずしもお問い合わせの件数は多くないのですが、遭遇するとやっかいな以下の問題について紹介します。

目次:

 

問題 1. ホストの更新時に iSCSI のセッションが再接続される

  • 現象
    ホストクラスターを構築している環境で、iSCSI ストレージに接続されたホストの状態を更新すると、接続されている全ての iSCSI セッションが一旦切断され、再接続されます。
    関連する影響として、MPIO を使用していた場合、MPIO フェールオーバーが発生する場合があります。
    一部の監視ソフトウェアや ストレージ 用の監視ツールなどでは、MPIO のフェールオーバーについて大量の警告メッセージが記録される場合があります。

  • 原因
    これは、SCVMM が RFC に則って Discover セッションを通常のセッションとは別に作成する為です。

  • 回避方法
    仕様による動作となるため、iSCSI のセッションの再接続を回避する事はできません。 監視ツールの警告メッセージについては、警告レベルを下げるか、警告を出さないように構成してください。


問題 2. LUN のコピーによる影響

  • 現象
    ホスト クラスターを構成している環境で、ストレージ 管理用ツール (例: FlexClone ) 等で LUN をコピーした場合、仮想マシンの作成時に以下の様なエラーが発生し、失敗する事があります。

    指定されたパスは、XXX上の有効なフォルダー パスではありません。
    バーチャルマシンを保存する <host node FQDN> の有効なフォルダーパスを指定してください。
    ID2910

    例えば、以下の様なシナリオを考えます。

    1. LUN_1 に Sysprep 済みの VHD を展開し、 ストレージのコピー機能を使って複製します。
    2. 複製された LUN_x に対して、それぞれ diskpart を使用してディスクの GUID を変更します。
    3. クラスター ストレージとして、それぞれ追加します。
    4. 追加された、それぞれのボリューム上に展開されている VHD を使用して、仮想マシンを作成します。
    5. 最後に作成されたボリューム以外のボリュームでは上記のエラーが発生します。
  • 原因
    この原因は、ボリューム シリアル番号が重複する事が原因で発生します。 
    ボリューム シリアル番号は、ファイル システムのフォーマット時に一意に設定される 8 桁の ID 番号です。

    SCVMM では、クラスター ボリュームの一意性を このボリューム シリアル番号を利用して認識していますが、ディスク単位でのコピーでは、ボリューム シリアル番号が重複する為、複数のボリュームがクラスターに登録されていても SCVMM では最後に認識されたボリュームしか認識できません。
    このため、そのほかのボリュームでは上記のようなエラーが発生します。

  • 回避方法
    VolumeID.exe 等のツールを使って、ボリュームのシリアル 番号を変更します。
    Volume ID.exe は、 Sysinternals のツールです。使用方法等の詳細については、以下のサイトをご覧ください。
    http://technet.microsoft.com/ja-jp/sysinternals/bb897436


問題 3. SSP サイトから 仮想マシンの操作ができなくなる

  • 現象
    SCVMM のセルフサービス ポータル (SSP) サイトを使用して、仮想マシン上に ISO をマウントすると、仮想マシンへのアクセスができなくなる場合があります。
    以下の様なシナリオで発生します。

    1. SSP サイト上から仮想マシンのプロパティを開き、ISO ファイルをマウントします。
    2. 再度同じ仮想マシンのプロパティを開き、同じ ISO ファイルをマウントしようとすると、以下のエラーで失敗します。
      DeployFileExists (1240)
      ファイル <iso File> は、サーバー <Hyper-V Host> に既に存在します。
      ファイル <iso File> を別の場所に移動し、操作を再試行します。
    3. 以降、仮想マシンへのアクセスは全てグレーアウトされ、実行できなくなります。
  • 原因
    SCVMM が ISO をマウントする際に、ISO ファイルをホスト マシンにコピーする為に発生します。 ISO ファイルをアンマウントしても、ファイルはローカル環境に残り続ける為、同じISO ファイルをコピーしようとして失敗します。

  • 回避方法

    以下のいずれかの方法で回避できます。

    • ライブラリ上の ISO ファイルを共有する方法

      コピーせずにイメージ ファイルを共有する” オプションにチェックを入れて、ライブラリ上の ISO ファイルを共有する。

      実際の手順は以下の技術情報、またはブログを参照してください。

      TechNet: VMM で Hyper-V バーチャル マシン用に共有 ISO イメージを有効にする方法
      http://technet.microsoft.com/ja-jp/library/ee340124.aspx



      Blog: SCVMM で共有 ISO を利用する方法
      http://blogs.technet.com/b/systemcenterjp/archive/2011/02/25/scvmm-iso.aspx

    • 一旦 ISO ファイルをアンマウントする方法

      ISO ファイルをマウントする前に、「なし」を選択して設定を保存します。 これにより、ISO ファイルがアンマウントされます。 その後、マウントした ISO ファイルを選択してマウントします。

      ※ 一度別の ISO ファイルをマウントして、再度目的の ISO ファイルをマウントすることでも、同様に回避可能です。

    実際に現象が発生した後では、これらの回避方法は有効ではありません。その場合は管理者に連絡し、管理コンソール上から仮想マシンの状態を「修復」- 「無視」するよう依頼してください。
    VMの操作ができなくなる現象は、今回の ISO マウントの問題以外にも、仮想マシンの状態が「正常」以外の状態(例:「サポートされないクラスター構成」や「不足」)になると発生します。 このような場合にも管理者に連絡し、仮想マシンの状態を修復してもらうように依頼してください。


問題 4. ISO をマウントした仮想マシンの複製に失敗する

  • 現象
    ホスト クラスターを構成している SCVMM 環境において、ノード間で 仮想マシンを複製しようとすると以下のエラーが出て失敗する事があります。(バーチャル マシンの作成ジョブは、 32% 前後で失敗)

    エラー  (2940)
    VMM は、要求されたファイルの転送を完了できません。HTTP サーバー <Host FQDN> に接続できませんでした。
    詳細  (Unknown error (0x80072ee2))

    推奨する操作
    HTTP またはコンピュータ <Host FQDN> 上のエージェントがインストールされ、実行されていること、およびファイアー ウォールが HTTPS トラフィックをブロックしていないことを確認します。

  • 原因
    ホスト間の複製であっても、VM にマウントされている ISO ファイルについては、ライブラリ サーバーから複製先のホストへ改めてコピーされます。
    この問題は、ライブラリ サーバーと展開先ホスト間のファイアー ウォールによりライブラリ サーバーから複製先のホストへの
    ISO ファイルのコピーに失敗する事で発生します。

  • 回避方法
    以下のいずれかの方法で現象を回避します。


問題 5. 境界ネットワーク上のホストへのアクセス

  •  現象
    境界ネットワーク、または信頼関係の無いドメインのホストを追加した場合に、このホスト上の仮想マシンへアクセスしようとすると、「リモート コンピューターを認証できない為リモート デスクトップ接続に失敗しました」というエラーが発生し、接続できません。

    以下のシナリオを考えます。
    1. 境界ネットワーク上の Hyper-V ホストを以下の情報を基に SCVMM に追加します。
    2. 境界ネットワーク上に追加された仮想マシンをクリックし「VMへ接続」を選択します。

    この場合、以下のエラーがでて失敗します。

  • 原因
    Hyper-V ホストの自己署名証明書が、接続元の信頼された認証機関(ローカル コンピューター)に無い事が原因で、接続できません。
  • 回避方法
    以下の手順にて、追加された境界ネットワーク上の Hyper-V ホストの自己署名証明書を 接続したい接続元(クライアント)のローカル コンピューターにインポートします。
    1. 一旦、「この証明書をインストール」をクリックして、証明書を「信頼されたルート認証機関」にインポートします。
    2. 「管理者として実行」したコマンド プロンプトから、”mmc.exe” を起動します。
    3. 「ファイル」メニューから「スナップ インの追加と削除」を選択し、一覧から「証明書」を追加します。
    4. 「このスナップインで管理する証明書」では、「ユーザー アカウント」を選択し、「次へ」をクリックします。
    5. 再度同じ手順で「コンピューター アカウント」を追加し、「ローカル コンピューター」を選択します。
    6. [OK] を押して、コンソールに戻ります。

    7. 「証明書 – 現在のユーザー」を展開し、「信頼されたルート証明機関」の下の「証明書」を開きます。
    8. 「発行先」、「発行者」共に境界ネットワーク上のホストになっているコンピューター名があれば、それを右クリックし、「全てのタスク」、「エクスポート」を選択します。
    9. DER encoded binary X509 を選択して「次へ」をクリックし、証明書をエクスポートします。
    10. 「証明書(ローカル コンピューター)」を展開し、「信頼されたルート証明機関」の下の「証明書」を右クリックします。
    11. 「すべてのタスク」から「インポート」を選択し、手順 8 でエクスポートされた証明書を「信頼されたルート証明機関」にインポートします。
  • 参考情報

まとめ

これまでに System Center Virtual Machine Manager 2008 R2 を中心に管理者が遭遇しやすい問題や、解決が難しい問題を中心に、その解決方法を紹介してまいりました。
しかし、「落とし穴」シリーズでは紹介しきれない問題も少なからず存在します。 それらの未知の問題に遭遇した時には、まずサービス(VMMService, VMMAgent) の再起動や、サーバーの再起動などを行ってみてください。
また、サービスやサーバーの再起動で直らない場合には、SCVMM の再インストールも検討すべきです。 この際、データベースを削除しない再インストールと、データベースを削除する再インストールが選択できますが、まずデータベースを削除しない方法を試した後、現象が回避出来ない場合にはデータベースを削除して、再インストールを試みます。
こうした切り分けでほとんどの現象は回避可能ですが、このような状態に陥った場合の復旧の為にも、定期的なデータベースのバックアップを計画する事が重要です。

VMM データベースのバックアップと復元
http://technet.microsoft.com/ja-jp/library/cc956045.aspx

では、また。

 

Comments (0)

Skip to main content