内容

問題の説明:

該当ハードウェア：

UCSB-MRAID12G RAIDコントローラ搭載サーバ：

該当ファームウェア：

該当するOS:

原因：

問題が発生するのを防ぐ方法

この問題でサーバにヒットした場合の回復方法

関連バグ：CSCvr11972

問題の説明:

RAIDコントローラの交換後、外部構成のインポート中にVDのNAA IDが変更され、データストアのマウントが失敗しました。

該当ハードウェア：

UCSB-MRAID12G

UCSC-MRAID12G

UCSB-MRAID12G RAIDコントローラを搭載したサーバ:

UCS B200 M4

UCS B200 M5

UCS B480 M5

UCS B420 M4

UCS C220 M4

UCS C240 M4

該当ファームウェア：

RAIDコントローラファームウェア：  24.5.x.xおよび24.6.x.x

例#

***mrsasctlr.24.5.0-0043_6.19.05.0_NA.bin

24.5.x.xコントローラのファームウェアは、3.2.*より前のすべてのUCSMリリースで表示されます。

3.1からのリリースノート#

https://www.cisco.com/c/en/us/td/docs/unified_computing/ucs/release/notes/CiscoUCSManager-RB-3-1.htmlhttps://www.cisco.com/c/en/us/td/docs/unified_computing/ucs/release/notes/CiscoUCSManager-RB-3-1.html

該当するOS:

VMware ESXi

原因：

古いファームウェアリリースでは、DDF（デバイスデータ形式）ワークスペースバージョンの不一致が見つかった場合、コントローラFWは外部インポート中にDDFからNAA IDを復元できません。

MR 6.4にはDDF_WORK_SPACEバージョン1が、MR 6.10にはDDF_WORK_SPACEバージョン3が含まれています。FW post-MR 6.4以降のリリースでは、DDFワークスペースが一致した場合でもコントローラNAA IDDをにから復元する見つかりました。 交換用コントローラのファームウェアが古い場合、NAA IDを正しく分析できません(例：24.5.xおよび24.6.x)。 ただし、バージョン24.12.xではNAA IDを正しく解析できます。

交換前：

[Server 2/2]：

製品名：Cisco UCS B200 M5 2ソケットブレードサーバ

装備PID:UCSB-B200-M5

装備VID:V06

装備シリアル(SN):FCH222973K5

スロットステータス：装備

確認済みの製品名：Cisco UCS B200 M5 2ソケットブレードサーバ

確認応答PID:UCSB-B200-M5

確認応答VID:V06

確認応答シリアル(SN):FCH222973K5

確認応答メモリ(MB):524288

確認応答された有効メモリ(MB):524288

確認応答コア：28

確認応答アダプタ：1

仮想ドライブ0:

Type:RAID 1ミラー

ブロック サイズ:512

ブロック：1560545280

ステータス:操作可能

プレゼンス：装備

SIZE:761985

ライフ サイクル:Allocated

ドライブの状態：最適

ストリップサイズ(KB):64

ACCESS POLICY:読み取り/書き込み

Read Policy：Normal

設定された書き込みキャッシュポリシー：ライトスルー

実際の書き込みキャッシュポリシー：ライトスルー

IOポリシー：Direct

ドライブキャッシュ：変更なし

ブート可能：正しい

固有識別子：bcc0dd21-2006-4189-86c1-132017ad0958

ベンダー固有識別子：618e7283-72eb-6460-240f-d02c0bbd9310 <<<<<<<<<<<

交換後：

[Server 2/2]：

製品名：Cisco UCS B200 M5 2ソケットブレードサーバ

装備PID:UCSB-B200-M5

装備VID:V06

装備シリアル(SN):FCH222973K5

スロットステータス：装備

確認済みの製品名：Cisco UCS B200 M5 2ソケットブレードサーバ

確認応答PID:UCSB-B200-M5

確認応答VID:V06

確認応答シリアル(SN):FCH222973K5

確認応答メモリ(MB):524288

確認応答された有効メモリ(MB):524288

確認応答コア：28

確認応答アダプタ：1

仮想ドライブ0:

Type:RAID 1ミラー

ブロック サイズ:512

ブロック：1560545280

ステータス:操作可能

プレゼンス：装備

SIZE:761985

ライフ サイクル:Allocated

ドライブの状態：最適

ストリップサイズ(KB):64

ACCESS POLICY:読み取り/書き込み

Read Policy：Normal

設定された書き込みキャッシュポリシー：ライトスルー

実際の書き込みキャッシュポリシー：ライトスルー

IOポリシー：Direct

ドライブキャッシュ：変更なし

ブート可能：正しい

固有識別子：7a894b44-721a-41ae-a3bf-380102b9e64e

ベンダー固有識別子：618e7283-72ea-3f20-ff00-005a0574b04b <<<<<<<<<<<<

この場合、サーバ2/2の[ベンダー固有識別子] idが[618e7283-72eb-6460-240f-d02c0bbd9310]から[618e7283-72ea-3f2に変更されました0-ff00-005a0574b04b]

問題が発生するのを防ぐ方法

この問題は、VD/ディスクを挿入する前に交換用コントローラのファームウェアをアップデートすることで回避できます。

手順の詳細：

1. サーバのシャットダウン

2. すべてのディスクを1つずつ取り外して、同じスロットを完全に挿入しないままにしておきます。その設置順序が乱れません(スロットから完全に取り外す場合は、ドライブを同じスロットに戻す必要があります)

3. ディスクを挿入せずに、交換用の新しいRAIDコントローラをインストールします。

4. サーバが新しいRAIDコントローラを認識します

5. Raidコントローラのファームウェアをアップデートします。

6. ファームウェアのアップグレードが成功したら、サーバの電源を切り、ディスクをサーバに挿入します。

7. サーバの電源をオンにします

この問題でサーバにヒットした場合の回復方法

手順の詳細：

===================

データストアの復元手順

===================

1 vSphere Clientにログインし、インベントリパネルからサーバを選択します。

2 [Configuration]タブをクリックし、[Hardware]パネルで[Storage]をクリックします。

3 [Add Storage]をクリックします。

4 [Disk/LUN]ストレージタイプを選択し、[Next]をクリックします。

5 LUNのリストから、[VMFS Label]列に表示されるデータストア名を持つLUNを選択し、[Next]をクリックします。

注:[VMFS Label]列に表示される名前は、LUNが既存のVMFSデータストアのコピーを含むコピーであることを示します。

6 [Mount Options]で、 次のオプションが表示されます。

既存の署名を保持:LUNを永続的にマウントする（たとえば、リブート後にLUNをマウントする）

新しい署名の割り当て:LUNの再シグニチャ

ディスクのフォーマット:LUNの再フォーマット

注意事項: ディスクのフォーマットオプションを選択すると、LUN上の既存のデータが削除されます。再署名を試みる前に、そのVMFSボリュームをオフにした仮想マシンが他のホスト上で実行されていないことを確認してください。これらの仮想マシンがvCenter Serverインベントリで無効になり、それぞれのホストに再登録されます。

[Assign a New Signature]を選択し、[Next]をクリックします。

7ボリュームに適したオプションを選択

8 [Ready to Complete]ページで、データストアの設定情報を確認し、[Finish]をクリックします。

===================

次の作業

=====================

再退後、次の操作が必要になる場合があります。

1 vSphere Clientにログインします。U[Inventory List] > [Click Datastore]

2データストアを右クリックし、[Browse Datastore]をクリックします

3左側のペインでVMフォルダをクリックし、右側のペインに内容を表示します

4右側のペインで.vmxファイルを右クリックし、[Add to Inventory]を選択します

5 「インベントリに追加」ウィザードの手順を説明し、VMのESXiホストへの追加を完了します

残りのすべてのVMに対して6つの手順を繰り返します。

7すべてのVMを再登録したら、インベントリからすべてのアクセスできないVMを削除します。削除するには、各VMを右クリックして[インベントリから削除]を選択します

8各VMの電源をオンにし、動作可能でアクセス可能であることを確認します。

注：VMの電源をオンにする前に、ESXiホストをリブートし、ESXiホストがオンラインに戻ってvSphereクライアント経由でアクセス可能になったら、VMが引き続き表示され、「アクセス不能」状態にならないことを確認します

関連バグ：CSCvr11972

CSCvr11972 MRAID12Gの交換後にベンダー固有識別子(VID)が変更されました

https://bst.cloudapps.cisco.com/bugsearch/bug/CSCvr11972