説明

Cisco HyperFlex リリース 5.5(1a) 以降、M4 サーバーはサポートされていません。M4 以前の HX 世代のサーバーを含むクラスタを HXDP リリース 5.5(1a) 以降にアップグレードしようとすると、アップグレード前のフェーズで失敗します。

アップグレード ページとアクティビティ ページに、[ブートストラップ アップグレード（Bootstrap Upgrade）] 手順でエラーが表示されます。場合によっては、ユーザーはエラー メッセージを表示できず、実際にはアップグレードが失敗したにもかかわらず、アップグレードが成功したと表示されます。

フォールバック メカニズムでは、ClusterUpgradeFailed イベントと、試行されたアップグレードが許可されないことを示すバナーが表示されます。

症状

アラートが生成され、HXDP 5.5(1a) 以降でサポートされていないクラスタで 1 つ以上の M4 プラットフォーム ノードが検出されたことを示すバナーが表示されます。グレースフルノード削除手順に従ってこれらのノードをクラスタから削除するか、TAC と協力してこれらのノードから移行し、アップグレードを再試行してください。

（注）	メッセージ センターには、同じエラー メッセージが入力されます。

アクション

アップサポートされているノードをグレースフルに削除し、アップグレードを再試行するか、TAC に連絡してサポートを受けてください。

説明

ESXi クラスタのアップグレードは、「ノードのメンテナンス モードが失敗しました」というエラーで失敗します。これは、DRS と HA が有効になっているオンラインで正常な ESXi クラスタで発生します。

アクション（Action）

次の回避策を次の順序で試してください。

1. HA アドミッション コントロール ポリシーが有効で、スロット ポリシーに設定されている場合は、クラスタ 技術情報の割合に変更して 1 つのホストの障害を許容してから、アップグレードを再試行します。

2. HA アドミッション コントロール ポリシーを無効にするか、HA を無効にしてから、アップグレードを再試行します。

3. いくつかの VMを追加して、少なくとも 1 つのノードの障害を許容できる十分なフェイルオーバー キャパシティがクラスタにあることを確認してから、アップグレードを再試行します。

説明

ESXi ホストがロックダウン モードの場合は、アップグレード前の検証が失敗し、エラーメッセージ [auth cancel] が表示されます。

アクション

ESXi ホストでロックダウン モード モードを有効化/無効化にし、アップグレードが成功したら有効にします。

HyperFlex コントローラ VM の使用

1. HX Connect にログインします。

2. 左側の [Navigation] ペインで、[System Overview] を選択します。

3. システムの概要] タブで、アクションドロップダウンリストからの有効化またはコントローラ VM へのアクセスを無効にする管理者として、SSH を使用します。

ESXi ホストの使用

1. vSphere Web クライアントにログインします。

2. VSphere Web Client のインベントリでホストを特定します。

3. [Manage] タブをクリックし、[Settings] をクリックします。

4. [System] で、[Security profile] を選択します。

5. [Lockdown Mode] パネルで、[Edit] をクリックします。

6. [ロックダウン モード（Lockdown Mode）] をクリックし、モードを [無効] に設定します。

説明

HX 4.5（1a）以上への HXDP アップグレードのエラー：「HyperFlex VIB のアップグレードに失敗しました。理由：いくつかの（システム エラー）。」

次のエラー ログが ESXi esxupdate.log ファイルに表示されます。

2020-12-01T11:59:22Z esxupdate: 333049: root: ERROR: vmware.esximage.Errors.LiveInstallationError: ([], '([], "Error in running rm /tardisks/scvmclie.v00:\\nReturn code: 1\\nOutput: rm: can\'t remove \'/tardisks/scvmclie.v00\': Device or resource busy\\n\\nIt is not safe to continue. 完了していないアップデートを破棄するには、ホストをただちに再起動してください。 」

アクション

次の手順に従って、getstctlvmlogs に対応するプロセスを強制終了し、アップグレードを再試行します。

1. root ログインで ESXi に SSH 接続します。

2. コマンド ps -c | grep -e cisco -e springpath を実行し、プロセス ID（PID）をメモします。次に例を示します。

   ps -c | grep -e cisco -e springpath

   112056 112056 sh /bin/sh /opt/springpath/support/getstctlvmlogs

3. コマンド kill-9<PID from previous command> を使用してプロセスを強制終了します。次に例を示します。

   kill -9 112056

4. HX Connect または Intersight に戻り、アップグレードを再試行します。問題がまだ続く場合は、Cisco TAC にお問い合わせください。

説明

HX Connect UI から複合アップグレードを実行しようとすると、UCS サーバ ファームウェアを選択するドロップダウンにバージョン 4.1 以降が表示されません。

アクション

UCS Manager にログインし、ファブリック インターコネクトに UCS B および C ファームウェア バンドルをアップロードしたことを確認します。そうでない場合は、それらをアップロードし、アップグレードを再試行します。UCS B および C ファームウェア バンドルがファブリック インターコネクトにすでにアップロードされている場合は、以下の回避策を適用してアップグレードを続行します。

1. [アップグレード タイプの選択（Select Upgrade Type）] ページで、[HX データ プラットフォーム（HX Data Platform）] のみを選択します。

2. アップグレードに適した HXDP アップグレード パッケージを参照して選択します。¹

3. vCenter ログイン情報を入力します。

4. [アップグレード（Upgrade）] をクリックします。これにより、管理コンポーネントがブートストラップされます。UI 画面を更新します。

5. UI が更新されたら、複合アップグレード手順を試してください。これで、UCS サーバ ファームウェア バージョン 4.1 以降がドロップダウン メニューに表示されます。

説明

クラスタ ノードをメンテナンス モードにする手順の失敗は、vSwitch とポート グループでの MTU の不一致が原因で発生します。ノード拡張方式を使用して後で追加されたノードがクラスタにある場合、新しく追加されたノードの MTU は 9000 に設定され、他のノードは MTU 1500 に設定されます。

（注）	以下の修復は、クラスタにクラスタ拡張の一部として追加された 1 つ以上のノードがあり、元のクラスタノードが 1500 の MTU に設定されている間に MTU が 9000 に設定されている場合にのみ適用されます。これがシナリオではない場合は、TAC にお問い合わせください。

アクション

• vCenter にログインします。

• すべてのノードで設定されている MTU 値を確認します。

• 最初に構築されたクラスタの一部であったノードの MTU が 1500 に設定されており、他の一部のノード（クラスタ拡張の一部として後で追加されたノード）の MTU が 9000 に設定されている場合は、そのようなすべてのノードの MTU を 1500 に変更します。

• アップグレードを再試行します。

説明

vGPU が設定された VM を含むクラスタの場合、DRS が完全に有効になっていても、メンテナンス モードは自動的には開始しません。ローリング アップグレード時には、これらの VM を手動で処理して、各 ESXi ホストがメンテナンス モードに入り、適切なタイミングでアップグレードを続行できるようにする必要があります。

アクション

次のいずれかの方法を使用して続行します。

1. vGPU が設定された VM について、クラスタ内の別の ESXi ホストに、手動で vMotion の操作を行います。

2. vGPU が設定された VM の電源を一時的にオフにします。ESXi ホストが再起動し、クラスタに再参加したら、再度電源をオンにすることができます。

（注）	これは DRS ホストの退避に関する制限で、ドキュメント化されています。VMware ドキュメント サイト上の 「DRS が vGPU 対応の VM を自動的に移行しない（66813）トピック」を参照してください。