Cisco UCS Manager B シリーズ トラブルシューティング ガイド
Cisco UCS Manager でのトラブルシューティングの問題
Cisco UCS Manager でのトラブルシューティングの問題
発行日;2012/11/22   |   ドキュメントご利用ガイド   |   ダウンロード ;   この章 pdf   ,   ドキュメント全体 pdf    |   フィードバック

目次

Cisco UCS Manager でのトラブルシューティングの問題

この章の内容は、次のとおりです。

ブートの問題のトラブルシューティング

リブート警告が表示されない

問題:依存関係をリストするリブート警告の生成に失敗します。

考えられる原因:この問題は、vNIC テンプレートまたは vHBA テンプレートへの変更が原因で発生する可能性があります。 リブート警告は、バックエンドが依存関係のリストを返すときに発生します。 vNIC または vHBA テンプレートのテンプレート タイプをアップデートし、ステップ間の変更を適用せずにブート関連プロパティを変更すると、依存関係のリストを返すバックエンド システムが起動されません。

手順
    ステップ 1   Cisco UCS Manager GUI を起動します。
    ステップ 2   サービス プロファイルに含まれる vNIC テンプレートまたは vHBA テンプレートで、次の手順を実行します。
    1. テンプレート タイプを [Initial Template] から [Updating Template] に変更します。
    2. [Save Changes] をクリックします。
    ステップ 3   リブート関連値に追加の変更を加えて、[Save Changes] をクリックします。

    リブート警告および依存関係のリストが表示されます。


    eUSB にインストールされている OS からサーバがブートしない

    問題:Cisco UCS サーバ内に組み込みの eUSB にはオペレーティング システムが含まれています。 けれども、サーバがそのオペレーティング システムからブートしません。

    考えられる原因:この問題は、サーバをサービス プロファイルに関連付けた後、eUSB がサーバの実際のブート順序の 1 番目になっていない場合に発生する可能性があります。

    手順
      ステップ 1   Cisco UCS Manager GUI を起動します。
      ステップ 2   [Servers] タブで次の手順を実行して、ブート ポリシー設定を確認します。
      1. サーバに関連付けられているサービス プロファイルに移動します。
      2. [Work] ペインで [Boot Order] タブをクリックします。
      3. [Local Disk] がブート ポリシーの 1 番目のデバイスとして設定されていることを確認します。
      ステップ 3   [Equipment] タブで次の手順を実行して、サーバの実際のブート順序を確認します。
      1. サーバに移動します。
      2. [General] タブで [Boot Order Details] 領域を展開し、[Actual Boot Order] タブで eUSB が 1 番目のデバイスとしてリストされていることを確認します。

        たとえば、1 番目のデバイスが [VM eUSB DISK] になっている必要があります。

      ステップ 4   eUSB が実際のブート順序の 1 番目のデバイスでない場合は、次の手順を実行します。
      1. サーバの [General] タブで、[Actions] 領域の次のリンクをクリックします。
        • [KVM Console] をクリックし、KVM コンソールを起動します。
        • [Boot Server] をクリックし、サーバをブートします。
      2. KVM コンソールで、サーバがブートしている間に F2 を押して、BIOS 設定を開始します。
      3. BIOS ユーティリティで、[Boot Options] タブをクリックします。
      4. [Hard Disk Order] をクリックします。
      5. [Boot Option #1] を eUSB に設定します。

        たとえば、このオプションを [VM eUSB DISK] に設定します。

      6. F10 を押して、設定を保存し、終了します。

      RAID1 クラスタの移行後にサーバがブートしない

      問題:RAID1 クラスタの移行後に、サーバがオペレーティング システムからブートしません。 RAID LUN は、サービス プロファイルのアソシエーション中もアソシエーション後も、「非アクティブ」状態のままになります。 その結果、サーバは起動できなくなります。

      考えられる問題:この問題は、サーバ上のサービス プロファイルのローカル ディスク設定ポリシーが、RAID1 ではなく [Any Configuration] モードで設定されていることが原因で発生する可能性があります。

      手順
        ステップ 1   Cisco UCS Manager GUI で、[Servers] タブをクリックします。
        ステップ 2   サーバに関連付けられているサービス プロファイルに移動し、[Storage] タブをクリックします。
        ステップ 3   次のいずれかを実行します。
        • 次のように、移行する前に、サービス プロファイルに含まれているローカル ディスク設定ポリシーを、サーバに関連付けられているサービス プロファイルのローカル ディスク設定ポリシーと同じポリシーに変更します。

          • [Actions] 領域で、[Change Local Disk Configuration Policy] をクリックします。
          • [Select the Local Disk Configuration Policy] ドロップダウン リストから、適切なポリシーを選択します。
          • [OK] をクリックします。
        • サービス プロファイルに含まれているローカル ディスク設定ポリシーのモード プロパティを、次のように変更します。

          • [Storage] タブの [Local Disk Configuration Policy] 領域で、[Local Disk Policy Instance] フィールド内のリンクをクリックします。
          • [Mode] フィールドで、[Raid 1 Mirrored] オプションが選択されていることを確認します。
          • [Save Changes] をクリックします。

        KVM の問題のトラブルシューティング

        KVM ビューアの起動時の BadFieldException

        問題:KVM ビューアを起動するとき、BadFieldException エラーが発生します。

        考えられる原因:ネイティブ ライブラリを使用するアプリケーションと共に Java Web Start を使用すると、デフォルトでキャッシュがディセーブルになることによって、この問題が発生することがあります。

        手順
          ステップ 1   [Start] > [Control Panel] > [Java] を選択します。
          ステップ 2   [General] タブをクリックします。
          ステップ 3   [Temporary Internet Files] 領域で、[Settings] をクリックします。
          ステップ 4   [Keep temporary files on my computer] チェックボックスをクリックします。
          ステップ 5   [OK] をクリックします。

          KVM コンソールの障害

          問題:KVM コンソールが起動に失敗し、JRE によって次のメッセージが表示されます。

          Unable to launch the application.
          

          考えられる原因:この問題は、複数の KVM コンソールが同時に起動された場合に発生する可能性があります。

          手順
            ステップ 1   可能な場合には、開いているすべての KVM コンソールを閉じます。
            ステップ 2   KVM コンソールを一度に 1 つずつ再起動します。

            KVM を開けない

            問題:初めてサーバで KVM を開こうとすると、KVM が起動に失敗します。

            考えられる原因:この問題は、JRE バージョンの非互換性が原因で発生する可能性があります。

            手順
              ステップ 1   JRE 1.6_11 にアップグレードします。
              ステップ 2   サーバをリブートします。
              ステップ 3   KVM コンソールを起動します。

              VM の問題のトラブルシューティング

              分散仮想スイッチでポートを使用できない

              問題:次のエラーが表示されます。

              Currently connected network interface x uses Distributed Virtual Switch (uusid:y) which is 
              accessed on the host via a switch that has no free ports.
              

              考えられる原因:この問題は、次のいずれかが原因で発生する可能性があります。

              • VM の電源をオフにした後、またはあるホストから別のホストに VM を移行した後、vSphere サーバが hostProxySwitch オブジェクトの numPortsAvailable プロパティの再計算に失敗しています。
              • ESX ホスト上で電源がオンになっている VM の vNIC の累積数が、サーバのサービス プロファイルに設定されている動的 nVINC の数と一致しているかまたは上回っています。
              • あるデータストアから同じサーバ上の別のデータストアに VM を移行した後、ホスト上で電源がオンになっているすべての VM で使用されている DVS ポート数の増加が、サーバによって誤って検出されています。
              手順
                 コマンドまたはアクション目的
                ステップ 1エラーが表示されていたときに実行していた操作を特定します。   
                ステップ 2エラーが、VM の電源をオフにしたことで発生したか、またはあるホストから別のホストに VM を移行したことで発生した場合は、次の手順を実行します。    
                ステップ 3エラーが、あるデータストアから同じサーバ上の別のデータストアに VM インスタンスを移行したことで発生した場合は、次の手順を実行します。    

                Cisco UCS Manager の問題のトラブルシューティング

                イベントのシーケンス処理で致命的なエラー

                問題:スリープ モードから復帰した後、Cisco UCS Manager GUI によって次のメッセージが表示されます。

                Fatal error: event sequencing is skewed.
                

                考えられる原因:この問題は、コンピュータがスリープ状態に入るときに Cisco UCS Manager GUI が実行中だった場合に発生する可能性があります。 JRE にはスリープ検出メカニズムがないため、システムでは、スリープ モードに入る前に受信したすべてのメッセージを再追跡することはできません。 複数回再試行した後、このイベント シーケンス エラーがログに記録されます。


                (注)  


                コンピュータをスリープにするときは、必ず Cisco UCS Manager GUI をシャットダウンします。


                手順
                Cisco UCS Manager GUI で、[Connection Error] ダイアログボックスが表示された場合は、次のいずれかをクリックします。
                • [Re-login] をクリックし、Cisco UCS Manager GUI に再度ログインします。
                • [Exit] をクリックし、Cisco UCS Manager GUI を終了します。

                ファブリック インターコネクトの問題のトラブルシューティング

                起動ローダー プロンプトからのファブリック インターコネクトの回復

                ファブリック インターコネクトの起動に失敗した場合は、次のいずれかの問題が発生している可能性があります。

                • キックスタート イメージが破損しているか、その他の理由で機能していない
                • ブートフラッシュ メモリのファイル システムが破損している

                これらの問題のいずれかが存在する場合、ブートローダ プロンプトを使用して、ファブリック インターコネクトを回復することが必要になる場合があります。

                手順
                Cisco TAC に問い合わせして、ファームウェア リカバリ イメージと、ブートローダ プロンプトからファブリック インターコネクトを回復する方法の情報を取得します。

                ファブリック インターコネクトのクラスタ ID 不一致の解決

                問題:ハイアベイラビリティ クラスタをサポートするように 2 つのファブリック インターコネクトを設定して L1 ポートと L2 ポートを接続した場合に、ファブリック インターコネクトのクラスタ ID で不一致が発生する可能性があります。 このタイプの不一致は、クラスタで障害が発生したために、Cisco UCS Manager を初期化できないことを意味します。

                手順
                  ステップ 1   Cisco UCS Manager CLI で、ファブリック インターコネクト B に接続して erase configuration を実行します。

                  ファブリック インターコネクト上のすべての設定が消去されます。

                  ステップ 2   ファブリック インターコネクト B をリブートします。

                  リブート後、ファブリック インターコネクト B はファブリック インターコネクト A が存在していることを検出し、ファブリック インターコネクト A からクラスタ ID をダウンロードします。 クラスタ設定に従属ファブリック インターコネクトを設定する必要があります。

                  ステップ 3   設定されていないシステムがブートすると、使用する設定方法の入力を要求するプロンプトが表示されます。 console と入力して、コンソール CLI を使用した初期設定を続行します。
                  (注)      ファブリック インターコネクトによって、クラスタ内のピア ファブリック インターコネクトが検出されます。 検出されなかった場合は、L1 ポートと L2 ポート間の物理接続を調べ、ピア ファブリック インターコネクトがクラスタ設定でイネーブルになっていることを確認します。
                  ステップ 4   y と入力して、従属ファブリック インターコネクトをクラスタに追加します。
                  ステップ 5   ピア ファブリック インターコネクトの管理パスワードを入力します。
                  ステップ 6   従属ファブリック インターコネクト上の管理ポートの IP アドレスを入力します。
                  ステップ 7   設定の要約を確認し、yes と入力して設定を保存および適用するか、no と入力して設定ウィザードを再びやり直し、設定を一部変更します。

                  設定ウィザードのやり直しを選択した場合は、以前に入力した値が角カッコで囲まれて表示されます。 以前に入力した値をそのまま使用する場合は、Enter を押します。


                  ファブリック インターコネクト フェールオーバーの強制

                  この操作は、Cisco UCS Manager CLI でのみ実行できます。

                  プライマリ ファブリック インターコネクトからフェールオーバーを強制する必要があります。

                  手順
                     コマンドまたはアクション目的
                    ステップ 1 UCS-A# show cluster state 

                    クラスタ内のファブリック インターコネクトの状態と、クラスタが HA レディであるかどうかを表示します。

                     
                    ステップ 2 UCS-A# connect local-mgmt 

                    クラスタのローカル管理モードを開始します。

                     
                    ステップ 3 UCS-A (local-mgmt) # cluster {force primary | lead {a | b}} 

                    次のいずれかのコマンドを使用して、従属ファブリック インターコネクトをプライマリに変更します。

                    force

                    ローカル ファブリック インターコネクトがプライマリになるように強制します。

                    lead

                    指定した従属ファブリック インターコネクトをプライマリにします。

                     

                    次に、ファブリック インターコネクト b を従属からプライマリに変更する例を示します。

                    UCS-A# show cluster state
                    Cluster Id: 0xfc436fa8b88511e0-0xa370000573cb6c04
                    
                    A: UP, PRIMARY
                    B: UP, SUBORDINATE
                    
                    HA READY
                    UCS-A# connect local-mgmt
                    Cisco Nexus Operating System (NX-OS) Software
                    TAC support: http://www.cisco.com/tac
                    Copyright (c) 2002-2011, Cisco Systems, Inc. All rights reserved.
                    The copyrights to certain works contained in this software are
                    owned by other third parties and used and distributed under
                    license. Certain components of this software are licensed under
                    the GNU General Public License (GPL) version 2.0 or the GNU
                    Lesser General Public License (LGPL) Version 2.1. A copy of each
                    such license is available at
                    http://www.opensource.org/licenses/gpl-2.0.php and
                    http://www.opensource.org/licenses/lgpl-2.1.php
                    
                    UCS-A(local-mgmt)# cluster lead b
                    UCS-A(local-mgmt)#
                    

                    Post-Upgrade IQN の問題のトラブルシューティング

                    重複した IQN の障害のクリアと IQN 発信側名の再設定

                    問題:Cisco UCS Release 2.0(1) から Release 2.0(2) にアップグレードした後、サービス プロファイルでホスト ファームウェア パッケージの変更などのアクションを実行しようとすると、Cisco UCS Manager によって 1 つ以上のサービス プロファイルで IQN 関連の障害が発生します。

                    考えられる原因:単一のサービス プロファイルまたは複数のサービス プロファイルで使用されている 1 つ以上の iSCSI vNICS に、一意の IQN 発信側名が指定されていません。

                    手順
                      ステップ 1   Cisco UCS Manager CLI にログインします。
                      ステップ 2   次のコマンドを実行して、Cisco UCS ドメイン内の IQN のリストを表示します。

                      UCS-A# show identity iqn | include iqn name

                      ステップ 3   Cisco UCS PowerTool でスクリプトを実行して、Cisco UCS PowerTool の取得と重複した IQN スクリプトの実行で説明した重複する IQN を含む iSCSI vNIC を特定します。
                      ステップ 4   IQN 発信側名が登録されていないサービス プロファイルで、発信側 ID をデフォルトの IQN プールに変更するか、または手動で一意の IQN を割り当てます。
                      ステップ 5   発信側 ID を変更したサービス プロファイルで、次のように発信側割り当てを割り当てた名前またはプールに変更します。
                      1. UCS-A # scope org org-name

                        指定した組織の組織モードを開始します。 ルート組織モードを開始するには、org-name/ と入力します。

                      2. UCS-A /org # scope service-profile profile-name

                        サービス プロファイルのサービス プロファイル組織モードを開始します。

                      3. UCS-A/org# scope vnic-iscsi iscsi_vnic_name

                        指定した iSCSI vNIC のモードを開始します。

                        (注)     

                        この vNIC は未登録であり、show identity iqn で表示されません。

                      4. UCS-A /org/service-profile/vnic-iscsi* # set iscsi-identity {initiator-name initiator-name | initiator-pool-name iqn-pool-name}

                        iSCSI 発信側の名前または iSCSI 発信側名の提供元の IQN プール名を指定します。 iSCSI 発信側名には最大 223 文字を使用できます。

                      5. UCS-A /org/service-profile/vnic-iscsi # commit-buffer

                        トランザクションをシステムの設定にコミットします。

                      (注)     

                      発信側名の変更にはストレージ側の設定も関係しますが、これについてはこのマニュアルでは説明していません。

                      ステップ 6   サービス プロファイルに対するアクションを実行して、Cisco UCS データベースに発信側名を登録します。

                      たとえば、関連付けされたサーバ上のファームウェアをアップグレードしたり、サービス プロファイルの説明またはラベルを変更できます。

                      ステップ 7   次のコマンドを実行して、IQN 変更が登録されたことを確認します。

                      UCS-Ashow identity iqn | include iqn name


                      更新中のサービス プロファイル テンプレートにバインドされているサービス プロファイルの IQN 発信側名の再設定

                      問題:Cisco UCS Release 2.0(1) から Release 2.0(2) にアップグレードした後、Cisco UCS Manager によって 1 つ以上のサービス プロファイルで IQN 関連の障害が発生し、サービス プロファイル上の重複した IQN 発信側名を再設定できません。

                      考えられる原因:一意の IQN 発信側名を持っていないサービス プロファイルが、更新中のサービス プロファイル テンプレートに基づいています。

                      手順
                        ステップ 1   Cisco UCS Manager CLI にログインします。
                        ステップ 2   UCS-A # scope org org-name

                        指定した組織の組織モードを開始します。 ルート組織モードを開始するには、org-name/ と入力します。

                        ステップ 3   UCS-A /org # scope service-profile profile-name

                        サービス プロファイルのサービス プロファイル組織モードを開始します。

                        ステップ 4   UCS-A/org# scope vnic-iscsi iscsi_vnic1_name

                        サービス プロファイルに割り当てられている最初の iSCSI vNIC のモードを開始します。

                        ステップ 5   UCS-A /org/service-profile/vnic-iscsi* # set iscsi-identity {initiator-name initiator-name | initiator-pool-name iqn-pool-name}

                        iSCSI 発信側の名前または iSCSI 発信側名の提供元の IQN プール名を指定します。 iSCSI 発信側名には最大 223 文字を使用できます。

                        ステップ 6   UCS-A /org/service-profile/vnic-iscsi* # exit

                        指定した iSCSI vNIC のモードを終了します。

                        ステップ 7   UCS-A/org# scope vnic-iscsi iscsi_vnic2_name

                        サービス プロファイルに割り当てられている 2 番目の iSCSI vNIC のモードを開始します。

                        ステップ 8   UCS-A /org/service-profile/vnic-iscsi* # set iscsi-identity {initiator-name initiator-name | initiator-pool-name iqn-pool-name}

                        iSCSI 発信側の名前または iSCSI 発信側名の提供元の IQN プール名を指定します。 iSCSI 発信側名には最大 223 文字を使用できます。

                        ステップ 9   UCS-A /org/service-profile/vnic-iscsi # commit-buffer

                        トランザクションをシステムの設定にコミットします。

                        ステップ 10   Cisco UCS Manager GUI で、更新中のサービス プロファイル テンプレートからサービス プロファイルをアンバインドします。