VMware vCenter Server 7.0 Update 3o リリース ノート

VMware vCenter Server 7.0 Update 3o | 2023 年 9 月 28 日 | ISO ビルド 22357613 これらのリリース ノートへの追加や更新を確認してください。

新機能

New：このリリースでは、CVE-2023-34048 および CVE-2023-34056 が解決されています。これらの脆弱性と VMware 製品が受ける影響の詳細については、VMSA-2023-0023 を参照してください。

• vSphere クラウド ネイティブ ストレージ内のデータストア間でのパーシステント コンテナ ボリュームの移行：vSphere 7.0 Update 3o 以降では、vSphere Client を使用して、vSphere クラウド ネイティブ ストレージ内のデータストア間でパーシステント コンテナ ボリュームを移行できます。

• vSphere Client からの vSphere クラスタ サービス (vCLS) の退避モードの有効化：vSphere 7.0 Update 3o では、構成] > [vSphere クラスタ サービス] > [全般 にある vCLS モードの編集 ボタンを使用して、vCLS クラスタで退避モードを有効にすることができます。

• VMware vSphere with Tanzu のアップデートについては、「VMware vSphere with Tanzu リリースノート」を参照してください。

• Photon OS のアップデートについては、「VMware vCenter Server Appliance Photon OS Security Patches」を参照してください。

vCenter Server 7.0 の以前のリリース

vCenter Server の機能、解決された問題、および既知の問題については、各リリースのリリース ノートに記載されています。vCenter Server 7.0 の以前のリリースのリリース ノートは以下のとおりです。

• VMware vCenter Server 7.0 Update 3n リリース ノート

• VMware vCenter Server 7.0 Update 3m リリース ノート

• VMware vCenter Server 7.0 Update 3l リリース ノート

• VMware vCenter Server 7.0 Update 3k リリース ノート

• VMware vCenter Server 7.0 Update 3j リリース ノート

• VMware vCenter Server 7.0 Update 3i リリース ノート

• VMware vCenter Server 7.0 Update 3h リリース ノート

• VMware vCenter Server 7.0 Update 3g リリース ノート

• VMware vCenter Server 7.0 Update 3f リリース ノート

• VMware vCenter Server 7.0 Update 3e リリース ノート

• VMware vCenter Server 7.0 Update 3d リリース ノート

• VMware vCenter Server 7.0 Update 3c リリース ノート

• VMware vCenter Server 7.0 Update 3a リリース ノート

• VMware vCenter Server 7.0 Update 3 リリース ノート

• VMware vCenter Server 7.0 Update 2d リリース ノート

• VMware vCenter Server 7.0 Update 2c リリース ノート

• VMware vCenter Server 7.0 Update 2b リリース ノート

• VMware vCenter Server 7.0 Update 2a リリース ノート

• VMware vCenter Server 7.0 Update 2 リリース ノート

• VMware vCenter Server 7.0 Update 1c リリース ノート

• VMware vCenter Server 7.0 Update 1a リリース ノート

• VMware vCenter Server 7.0 Update 1 リリース ノート

• VMware vCenter Server 7.0.0d リリース ノート

• VMware vCenter Server 7.0.0c リリース ノート

• VMware vCenter Server 7.0.0b リリース ノート

• VMware vCenter Server 7.0.0a リリース ノート

利用可能な言語、互換性、インストール、アップグレード、オープン ソース コンポーネント、製品サポートに関する注意事項については、「VMware vSphere 7.0 リリース ノート」を参照してください。

vCenter Server のサポート対象のアップグレードおよび移行パスの詳細については、VMware ナレッジベースの記事 KB67077 を参照してください。

本リリースに含まれるパッチ

• VMware vCenter Server Appliance 7.0 Update 3o のパッチ
• ダウンロードとインストール

VMware vCenter Server Appliance 7.0 Update 3o のパッチ

vCenter Server の製品パッチ。VMware のソフトウェアの修正、セキュリティ修正、およびサードパーティ製品の修正を含みます。

このパッチは、vCenter Server に適用されます。

ダウンロード ファイル名	VMware-vCenter-Server-Appliance-7.0.3.01700-22357613-patch-FP.iso
ビルド	22357613
ダウンロード サイズ	6718.0 MB
md5sum	6591318d7c1b10c16f52eb2553c880a0
sha256checksum	cb5e135aa14f0413f7e9f4d013c6fbcba5a65e12699fa2ba40565784b3dd72fb

ダウンロードとインストール

このパッチを VMware Customer Connect からダウンロードするには、[製品とアカウント] > [製品パッチ] の順に移動する必要があります。[製品の選択] ドロップダウン メニューから [vCenter Server] を選択し、[バージョンの選択] ドロップダウン メニューから [7.0.3] を選択します。

1. VMware-vCenter-Server-Appliance-7.0.3.01700-22357613-patch-FP.iso ファイルを vCenter Server の CD または DVD ドライブに接続します。

2. スーパー管理者権限（root など）を持つユーザーとしてアプライアンス シェルにログインし、次のコマンドを実行します。

   • ISO をステージングするには：

     software-packages stage --iso

   • ステージングしたコンテンツを表示するには：

     software-packages list --staged

   • ステージングした rpms をインストールするには：

     software-packages install --staged

vCenter Server シェルの使用方法の詳細については、VMware ナレッジベースの記事 KB2100508 を参照してください。

vCenter Server へのパッチ適用については、「vCenter Server Appliance へのパッチ適用」を参照してください。

パッチのステージングについては、「Stage Patches to vCenter Server Appliance」を参照してください。

パッチのインストールについては、「Install vCenter Server Appliance Patches」を参照してください。

アプライアンス管理インターフェイスを使用したパッチ適用については、「アプライアンス管理インターフェイスを使用した vCenter Server へのパッチ適用」を参照してください。

製品サポートに関する注意事項

仮想マシンをバックアップする際に独立ディスクを使用した仮想マシンのメモリ スナップショットのリストアはサポートされていません：独立ディスクを使用する仮想マシンのメモリ スナップショットを作成できるのは、仮想マシンのゲスト OS の動作を分析する場合のみです。このタイプのスナップショットのリストアはサポートされていないため、仮想マシンをバックアップする際に、このようなスナップショットを使用することはできません。メモリ スナップショットをパワーオフされたスナップショットに変換できます。このスナップショットは正常にリストアできます。

解決した問題

• セキュリティの問題
• vSAN の問題
• 仮想マシンの管理
• vCenter Server および vSphere Client の問題
• インストールとアップグレードの問題
• その他の問題
• ネットワークの問題
• ストレージの問題
• CIM および API の問題
• Auto Deploy の問題
• vSphere vMotion の問題
• サーバ構成の問題

セキュリティの問題

• このリリースでは、CVE-2023-34048 および CVE-2023-34056 が解決されています。これらの脆弱性と VMware 製品が受ける影響の詳細については、VMSA-2023-0023 を参照してください。

• インターネット プロキシのパスワードに特定の予約文字が含まれていると、vSphere Lifecycle Management の一部の操作が失敗する

  インターネット プロキシのパスワードに含まれている特定の予約文字（英数字、ダッシュ、アンダースコア、ピリオド、チルドを除く）は、パスワード文字列の URL エンコード（パーセントエンコードとも呼ばれます）をトリガします。これにより、パスワードで保護されたプロキシを介してインターネットにアクセスする必要がある vSphere Lifecycle Management の一部の操作が失敗します。たとえば、vSphere Client の vSphere Lifecycle Manager ホーム ビューで アクションの選択] > [HCL の同期 をクリックすると、プロキシ サーバの正しいユーザー名とパスワードが構成されていても、「Update HCL data - A general system error occurred」というエラーが表示されます。

  本リリースで、この問題は修正されました。

• 複数の ESXi ホストの接続が断続的に失われるが、すぐに再接続される

  テスト インスタンスが古いなど、vCenter Server システムのキー管理サーバ (KMS) 構成が無効である場合、vpxd サービスは、その KMS に定期的に接続して状態の確認を試みますが、これが原因でファイル記述子が正しくなくなります。その結果、ESXi ホストの接続が失われます。ホストは一度に 1 つずつ切断されますが、1 秒後に自動的に再接続されます。

  本リリースで、この問題は修正されました。

• Secure Sockets Layer (SSL) 証明書で organizationalUnitName フィールドが必要になる

  vCenter Server 7.0 Update 3o 以降では、vCenter Server 証明書を管理するためのインターフェイスとして vSphere Automation API、Certificate Manager ユーティリティ、または証明書管理 CLI を使用する場合は、organizationalUnitName フィールドを空のままにすることができます。この変更は、証明書の置き換えまたは証明書署名要求 (CSR) の既存のワークフローには影響しません。vSphere Client および PowerCLI 12.4 には、organizationalUnitName フィールドのデータが従来どおり必要になります。

  本リリースで、この問題は修正されました。

• 脆弱性スキャンで vCenter Server ポート 9084 および 9087 に対する HTTP TRACE メソッドに脆弱性があると報告される場合がある

  一部のサードパーティ製ツールの脆弱性スキャンでは、vCenter Server ポート 9084 および 9087 に対する HTTP TRACE メソッドに脆弱性があると報告される場合があります。

  本リリースで、この問題は修正されました。

• vCenter Server 7.0 Update 3o では、次のセキュリティ アップデートが提供されます。

  • Apache Tomcat はバージョン 8.5.89 にアップデートされました。

  • Spring Framework はバージョン 5.3.27 にアップデートされました。

  • Jackson パッケージはバージョン 2.15.2 にアップデートされました。

  • Commons Lang3 ソフトウェア ライブラリはバージョン 3.12.0 にアップデートされました。

  • Commons-Collections4 ソフトウェア ライブラリはバージョン 4.4 にアップデートされました。

  • Commons-Fileupload ソフトウェア ライブラリはバージョン 1.5 にアップデートされました。

  • Velocity-Engine-Core はバージョン 2.3 にアップデートされました。

  • sqlite-jdbc はバージョン 3.42.0.0 にアップデートされました。

  • Protocol Buffers (Protobuf) はバージョン 3.22.3 にアップデートされました。

  • Jetty はバージョン 9.4.51.v20230217 にアップデートされました。

  • オープン ソースの変更については、PhotonOS リリース ノートを参照してください。

vSAN の問題

• vSAN クラスタのシャットダウンおよび再起動後に vCLS 仮想マシンがパワーオンされない

  vSAN クラスタのシャットダウン中に、vSAN は ESX Agent Manager (EAM) でそのクラスタを無効にします。EAM サービスが再起動しても、vCLS 仮想マシンはパワーオンされません。

  本リリースで、この問題は修正されました。

• vSAN 健全性チェックの一時的な警告：ネットワーク構成が同期していません

  ネットワーク構成が同期されていないことが、vSAN Skyline Health によってランダムに報告されることがあります。この一時的な問題が発生するのは、vSAN 健全性サービスが古い vCenter Server 構成を使用してユニキャスト チェックを実行する場合です。

  本リリースで、この問題は修正されました。

仮想マシンの管理

• Advanced Cross vCenter vMotion を使用した vCenter Server インスタンス間での仮想マシンの移行に失敗し、「VirtualEthernetCardNetworkBackingInfo required property deviceName not set」というエラーが表示される

  Advanced Cross vCenter vMotion 操作のソースとターゲットの vCenter Server インスタンス（オンプレミスまたはクラウド）で、一部のネットワーク アダプタに対して同じ名前の一致するネットワークがある場合は、操作が失敗し、「VirtualEthernetCardNetworkBackingInfo required property deviceName not set」のようなエラーが表示されることがあります。この問題は、リンクされた vCenter Server インスタンス間において、仮想マシンを vCenter Server 間で移行する標準の方法には影響しません。

  本リリースで、この問題は修正されました。

• vSphere Client で、一部の仮想マシンの仮想ハードウェア設定が暗い背景に黒で表示され、その値が明確に表示されない

  vSphere Client で、仮想マシンの 設定の編集] > [仮想ハードウェア を開いて メモリ セクションまたは ハード ディスク セクションを展開すると、暗い背景に数字が黒で表示され、値が明確に表示されません。

  本リリースで、この問題は修正されました。

• IP アドレスに基づく仮想マシンのフィルタリングが、2 つ以上の IP アドレスを持つ仮想マシンで機能しない

  vSphere Client では、仮想マシン リストを IP アドレスでフィルタリングすると、2 つ以上の IP アドレスを持つ仮想マシン（2 つの NIC が接続されている場合や仮想 IP アドレスを使用している場合など）がフィルタ結果に表示されないことがあります。

  本リリースで、この問題は修正されました。

• データセンター間で複数の仮想マシンを移行すると、[コンピューティング リソースの選択] の検証手順を完了できないことがある

  まれに、データセンター間で多数の仮想マシンを移行すると、プロパティの計算の問題が発生し、[コンピューティング リソースの選択] の検証手順が完了せず、移行を実行できないことがあります。

  本リリースで、この問題は修正されました。

• 同じクラスタ内でスケジュール設定された仮想マシンの移行を実行すると、親リソース プールまたは vApp が保持されないことがある

  仮想マシンを移行するタスクをスケジュール設定した場合、ソース ホストとターゲット ホストが同じクラスタ内にあるときは、移行の完了後に仮想マシンが親リソース プールまたは vApp から移動することがあります。

  本リリースで、この問題は修正されました。

• vSphere Client で、暗号化ストレージ ポリシーを仮想マシンに適用できない

  仮想マシンの暗号化タスクを有効にするキー管理サーバ (KMS) クラスタに接続の問題がある場合、vSphere Client の [仮想マシン ストレージ ポリシーの編集] または [仮想マシン設定の編集] を使用して仮想マシンに暗号化ストレージ ポリシーを適用することはできません。また、KMS クラスタの接続の問題が原因で、ロードに時間がかかります。

  本リリースで、この問題は部分的に修正されました。[仮想マシン設定の編集] を使用すると、暗号化ストレージ ポリシーを仮想マシンに設定できます。ただし、暗号化ポリシーと vSphere Client のウィザードを想定どおりに機能させるには、問題のある KMS サーバの接続の問題を修正するか、そのサーバをキー プロバイダから削除する必要があります。

• vSphere Client で、データ グリッドのライブ更新後に [アイテムをすべて選択] オプションが適切に機能しないことがある

  vSphere Client で、関連するオブジェクト リスト（仮想マシンのリストなど）内のエンティティを追加または変更すると、自己更新がトリガされ、リストが連続してライブ更新されます。データ グリッドが 2 回更新されると、[アイテムをすべて選択] オプションが適切に機能しないことがあります。

  本リリースで、この問題は修正されました。

• vCenter Server システムから .vmx ファイルをダウンロードできない

  ESXi ホストで暗号化モードが有効になっている場合は、個々の仮想マシンが暗号化されていないときでも、このホストから .vmx ファイルをダウンロードできません。ただし、vCenter Server システムへの Cryptographer.Access 権限がある場合は除きます。

  本リリースで、この問題は修正されました。

vCenter Server および vSphere Client の問題

• vCenter Server フォルダ名に、「%」などの特殊文字が「%25」などのエスケープ文字で表示される

  特殊文字はエスケープされるため、vCenter Server フォルダ名に「%」などの特殊文字が含まれていると、vSphere Client に正しく表示されない場合があります。たとえば、フォルダ名 My%Folder は My%25Folder と表示されます。

  本リリースで、この問題は修正されました。

• vSphere Client の仮想ハードウェア設定画面のネットワーク アダプタの名前に「/」ではなく「%2f」が表示される

  vSphere Client で、仮想マシン > 設定の編集] > [仮想ハードウェア に移動すると、ネットワーク アダプタの名前に「/」ではなく「%2f」が表示されます。たとえば、nw10.55.0.0/24 が nw10.55.0.0%2f24 と表示されます。

  本リリースで、この問題は修正されました。

• vCenter Server で削除したデフォルトのバックアップ ジョブ失敗アラームまたはバックアップ ジョブ成功アラームをリストアできない

  vCenter Server の一般的なアラームである バックアップ ジョブ失敗 または バックアップ ジョブ成功 はデフォルトのアラームです。新規アラームの追加 ドロップダウン メニューにはデフォルトのバックアップ アラームが含まれていないため、これらのアラームを削除すると、元に戻すことができません。

  本リリースで、この問題は修正されました。この修正により、バックアップ ジョブ失敗 アラームと バックアップ ジョブ成功 アラームが 新規アラームの追加 ドロップダウン メニューに追加されます。

インストールとアップグレードの問題

• vCenter Server GUI インストーラを使用して vCenter Server の構成とインベントリのみを移行することができない

  GUI インストーラを使用して vCenter Server の移行を実行するときに [構成とインベントリ] オプションのみを選択しても、[タスクとイベント] や [パフォーマンス メトリック] など、リストされているすべてのオプションのデータが取得されます。この問題が発生するのは、GUI インストーラでの選択に関係なく、バックエンドでの選択の対象がすべてのデータであるためです。

  本リリースで、この問題は修正されました。

• vCenter Server 7.x へのアップグレードが失敗すると、バックログに「VMware directory error[9127]」と表示される

  vCenter Server システムのドメイン コントローラで共通名 cn と LDAP 属性 sAMAccountName が一致しない可能性があるため、vCenter Server 7.x へのアップグレードに失敗することがあります。/var/log/firstboot ファイルには、次のようなメッセージが記録されます。「INFO wcp-firstboot WCP storage user does not exists, create the user」および「VMware directory error[9127]」。

  本リリースで、この問題は修正されました。

その他の問題

• 証明書署名リクエストにホスト名が同じ 2 つの SAN エントリが表示される

  まれに、証明書署名リクエスト (CSR) に重複する SAN エントリが含まれている場合があります。この問題による機能上の影響はなく、CSR は新しい証明書の作成に成功します。

  本リリースで、この問題は修正されました。

• vCenter Server の Syslog サービスが /var/log/vmware/esx/HOSTNAME/ ディレクトリに重複ファイルを作成する

  ESXi ホストで Syslog サービスのアップストリーム構成を変更すると、ソース システムに重複するストリーム ファイルが作成され、vCenter Server で容量が必要以上に使用されることがあります。

  本リリースで、この問題は修正されました。

• ESXi ホストで vSphere HA を再起動すると、重複する vSphere HA エントリのログが表示される

  vSphere Client を使用して vSphere HA の詳細オプションを構成する場合、エントリにスペースが含まれていると（例：<unknownStateMonitorPeriod >）、vSphere HA の再起動後に構成済みのプロパティの重複エントリが表示されることがあります。ホストの fdm.log ファイルには、次のようなエラーが記録されます。

  2022-12-05T20:55:58.592Z fdm[2104214]: Upgrade FDM configuration failed with error:Duplicate child: unknownStateMonitorPeriod.

  本リリースで、この問題は修正されました。

• ESXi 6.x 仮想マシンを 7.0 Update 2 以降に移行すると、次のエラーを表示して失敗する：「モジュール「MonitorLoop」のパワーオンに失敗しました。」

  vSphere vMotion を使用して 6.x 仮想マシンをバージョン 7.0 Update 2 以降の ESXi ホストに移行すると、失敗することがあります。これは、ターゲット ホストで必要な仮想マシン オーバーヘッド メモリがソース ホストより多いためです。バックトレースには Module 'MonitorLoop' power on failed. のようなエラーが記録されます。

  本リリースで、この問題は修正されました。この修正により、vSphere DRS の詳細オプション、NewDeltaAlloc が強化されました。

• ローテーション後に未圧縮のいくつかの vsphere-ui ログが表示される

  いくつかの vsphere-ui ログ（catalina.log、localhost.log、manager.log、host-manager.log など）がローテーション後に圧縮されず、ローテーションの頻度が高い（たとえば、毎日）場合は、ローテーションされたファイルの長いリストが表示されることがあります。

  本リリースで、この問題は修正されました。

• システム日付を変更しても、証明書の有効期限に関する誤った vSphere Client アラームが表示され、有効期限が負の値になる

  この問題は非常にまれですが、何らかの理由で vCenter Server システムの日付が、vCenter Server 証明書が期限切れと表示される日付と比較して、遠い将来の日付に設定されている場合に発生します。その結果、vCenter Server システムが将来の日付に設定されているケースを考慮するようにアラームが設計されていないため、証明書の有効期限アラームが想定どおりに表示されます。システム時刻を正しい日付に変更した後も、負の値の有効期限が指定された vCenter Server アラームが続行されます。

  本リリースで、この問題は修正されました。この修正により、システム日付を修正した後は、証明書の有効期限アラームが表示されなくなります。ベスト プラクティスは、vCenter Server システムの日付を遠い将来の日付に設定しないことです。

• VMware Service Lifecycle Manager (vmware-vmon) vMon が障害発生時のコア ダンプの生成に成功する前に vpxd サービスのスレッドを閉じる

  まれに、コア ダンプ操作に時間がかかる場合、vCenter Server サービスの健全性を監視する vmware-vmon サービスが、障害発生時のコア ダンプの生成に成功する前に vpxd サービスのスレッドを閉じることがあります。その結果、vpxd エラーの根本原因を調査できません。

  本リリースで、この問題は修正されました。

• 仮想マシンの移行操作中に vpxd サービスが頻繁に失敗し、ダンプが表示される

  まれに、移行操作中に hostd サービスが空の仮想マシン レイアウトを返すと、仮想マシン レイアウトの null チェックが行われないために vpxd サービスが失敗し、ダンプが表示されることがあります。

  本リリースで、この問題は修正されました。この修正により、仮想マシン レイアウトの null チェックが追加され、vpxd エラーが回避されます。

• vCenter Server のアップグレード後に SNMP を実行すると、vCenter Server のアップグレード後のバージョンではなく、元のバージョンの情報が返されることがある

  vCenter Server のアップグレード後に snmpwalk コマンドを実行して vCenter Server のバージョン情報を取得すると、アップグレード後のバージョンではなく、元のバージョンの情報が返されることがあります。

  本リリースで、この問題は修正されました。

• SNMP サービスのコア ファイルによって /storage/core ディレクトリに空きがなくなる

  ファイル /proc/cpuinfo 内の仮想ファイル システムの CPU 情報を保持する内部バッファが正しく計算されず、SNMP サービスのコア ファイルが多数生成され、/storage/core ディレクトリに空きがなくなることがあります。

  本リリースで、この問題は修正されました。この修正により、バッファが cpuinfo ファイル全体を適切に保持できるようになりました。

• Likewise メモリの枯渇が原因で ESXi ホストが Active Directory ドメインまたは vCenter Server からランダムに切断される

  Active Directory 操作および関連ライブラリでメモリ リークが発生します。ESXi ホストでスマート カード認証が有効になっていると、Likewise メモリが枯渇することがあります。

  本リリースで、この問題は部分的に修正されました。詳細については、VMware ナレッジベースの記事 KB78968 を参照してください。

ネットワークの問題

• [NSX ポート グループ ID] 列で分散ポート グループをフィルタリングできない

  vSphere Client の [NSX ポート グループ ID] 列で分散ポート グループをフィルタリングすると、「Cannot filter by non-filterable property: DistributedVirtualPortgroup/dvpgNsxId」のようなエラーが表示されるか、ポートのデータグリッドにロード中と表示され続ける場合があります。

  本リリースで、この問題は修正されました。この修正により、フィルタリングのブロックは解除されますが、[NSX ポート グループ ID] 列でのフィルタリングは引き続き実行できません。

ストレージの問題

• 仮想マシンでの vSphere Storage DRS 操作が次のエラーで失敗する：使用可能なストレージ IOPs キャパシティがこの操作には不十分です

  ストレージ クラスタ内の一部の仮想マシンにストレージ I/O 予約がある場合、vSphere Storage DRS がクラスタ内の I/O 予約の分散処理に失敗し、次のようなエラーが発生することがあります：The available storage IOPs capacity is not sufficient for the operation。

  本リリースで、この問題は修正されました。手動での回避策として、vSphere Storage DRS の詳細オプション EnforceIOReservations を 0 に設定します。

• DatastoreInfo オブジェクトの timestamp プロパティが継続的に変化し、古いタイムスタンプが取得される場合もある

  共有データストアの場合、DatastoreInfo オブジェクトのタイムスタンプはホストごとに異なる可能性があります。タイムスタンプは、ESXi ホストがストレージ スタックから空き容量やキャパシティなどのデータを取得する時刻を示していますが、ホストにより更新をトリガする時刻は異なります。DatastoreInfo オブジェクトを更新する際のホストの同期中、vCenter Server で取得されるタイムスタンプは、別のホストから送信されたタイムスタンプよりも古い場合があるため、タイムスタンプに変化が発生します。

  本リリースで、この問題は修正されました。

CIM および API の問題

• アプライアンス シェルの一部の API コマンドから予期しない結果が返される場合がある

  さまざまな管理タスクを実行するために vCenter Server のアプライアンス シェルで使用する一部の API コマンドから予期しない結果が返される場合があります。たとえば、com.vmware.appliance.version1.resources.cpu.stats.get コマンドからは次の結果が返される場合があります。

  Error in method: Operation Failed. (code com.vmware.applmgmt.err_operation_failed)または

  Error in executing command: 8002。

  次に示すのは、健全性に関連する一部のコマンドです。

  • com.vmware.appliance.version1.resources.load.health.get

  • com.vmware.appliance.version1.resources.mem.health.get

  • com.vmware.appliance.version1.resources.storage.health.get

  • com.vmware.appliance.version1.resources.swap.health.get

  • com.vmware.appliance.version1.resources.system.health.get

  • com.vmware.appliance.version1.resources.softwarepackages.health.get

  このようなコマンドからは、灰色の健全性ステータスのみが返される場合があります。

  本リリースで、この問題は修正されました。

• integrity_check_machine_account_executor.py ツールがタイムアウトになり、致命的ではないエラー メッセージが表示されることがある

  vc-support コマンドを実行して vCenter Server のログ サポート バンドルを収集すると、次のような致命的ではないエラーが表示されることがあります：cmd "/usr/lib/vmware-vmdir/vmdir-tool/integrity_check_machine_account_executor.py" timed out after 1200 seconds due to lack of progress in last 600 seconds (0 bytes read)。このような場合は、/usr/lib/vmware-vmdir/vmdir-tool/vmdir_tool.py ツールの [--integrityCheck] オプションを使用して、そのスクリプトを個別に実行し、完全な出力を収集します。

  本リリースで、この問題は修正されました。

Auto Deploy の問題

• 固定パスワード設定を使用してホスト プロファイルからデプロイされたステートレス ESXi ホストが再起動後に vCenter Server から切断される場合がある

  vSphere Auto Deploy を使用してデプロイしたステートレス ESXi ホストは、再起動後にメンテナンス モードを終了しないことがあるため、このホストを vCenter Server に再接続するには root パスワードを手動で設定する必要があります。この問題は、ステートレス ホストの再起動後に正しく適用されないホスト プロファイルを 固定パスワード 設定とともに使用する場合にのみ発生します。

  本リリースで、この問題は修正されました。

• VMware vSphere+ で、vSphere Auto Deploy を使用してデプロイするステートレス ESXi ホストがクラスタの起動またはクラスタへの接続に失敗することがある

  vSphere+ のライセンスがある環境で Auto Deploy を使用してステートレス ESXi ホストをデプロイすると、ホストの起動中にライセンスの検証に失敗することがあります。その結果、ホストは指定されたクラスタに参加して適切なライセンスを取得できなくなります。

  本リリースで、この問題は修正されました。

vSphere vMotion の問題

• Intel Ice Lake CPU を搭載した ESXi 6.7.x ホストからの vSphere vMotion 操作が「msg.checkpoint.cpucheck.fail」というエラーで失敗する

  ESXi 6.7.x を実行している Intel Ice Lake CPU ホストから vSphere Client または VMware Hybrid Cloud Extension (HCX) を使用して vSphere vMotion 操作を実行すると失敗し、「msg.checkpoint.cpucheck.fail」のようなエラーが表示されます。vSphere Client には、cpuid.PSFD がターゲット ホストでサポートされていないことを示すメッセージが表示されます。HCX には、「A general system error occurred: vMotion failed:」のようなレポートが表示されます。

  本リリースで、この問題は修正されました。

サーバ構成の問題

• VMware vSphere Authentication Proxy (vmcam) サービスの起動が断続的に失敗し、vCenter Server ファイルベースのバックアップを完了できない

  vCenter Server Appliance 管理インターフェイス (VAMI) を使用してファイルベースのバックアップを実行すると、次のようなエラーが表示されることがあります。

  Invalid vCenter Server Status: All required services are not up! Stopped services:'vmcam'

  この問題は、vCenter Server のアップデート後に vmcam ログ ファイルの所有権が /vmcam から /root に変更された可能性があり、vmcam の起動に失敗することがある場合に発生します。

  本リリースで、この問題は修正されました。この修正により、正しい所有権を指定して vmcam ログ ファイルが更新されます。

• PowerCLI または VMware Aria Automation Orchestrator を使用して vSphere クラスタ サービス (vCLS) データストアを構成すると、定期的に vCLS 仮想マシンの再デプロイが表示される

  VMware Aria Automation Orchestrator（旧称 VMware vRealize Orchestrator）または PowerCLI を使用して vCLS 仮想マシンのカスタム データストア構成を作成する（たとえば、これらの仮想マシンに許可されるデータストアのリストを設定する）と、定期的（たとえば、15 分ごと）にこれらの仮想マシンの再デプロイが表示されることがあります。

  本リリースで、この問題は修正されました。

既知の問題

• サーバ構成の問題
• vSphere Lifecycle Manager の問題
• vSAN の問題

サーバ構成の問題

• vSphere Client でキー管理サーバ (KMS) インスタンスのステータスを表示すると、「取得エラー」というメッセージが表示される

  vSphere Client でキー管理サーバ (KMS) インスタンスを表示する際に、「Error retrieving」というメッセージが数分間表示されることがあります。この問題は、標準のキー プロバイダで KMS インスタンスの接続が失われた場合に発生します。影響を受ける KMS に対するすべてのネットワーク要求がタイムアウト（約 4 分）になるまで、システム内の KMS インスタンスのステータスを表示することはできず、キー プロバイダに関するエラー メッセージのみが表示されます。タイムアウト後には、すべての KMS インスタンスのステータスを確認できます。

  回避策：「取得エラー」というメッセージが表示された場合は、4 分間待機します。

• デフォルトのタイムアウト設定は 2 分であるため、いずれかの vCenter Server が停止している場合、拡張リンク モードの vCenter Server インスタンスへのログインに時間がかかる

  拡張リンク モードの vCenter Server インスタンスが複数ある場合は、何らかの理由（メンテナンスなど）でいずれかのインスタンスが停止すると、他のインスタンスへのログインに最大で 2 分かかる可能性があります。これはデフォルトのタイムアウト設定です。リンクされた vCenter Server インスタンスへのログインの待機時間を指定する timeout プロパティの変更は複雑なタスクであり、vim-commons-vsphere.properties にある LinkedVcGroup.login.timeout プロパティを手動で編集する必要があります。このタスクを簡素化するために、vCenter Server 7.0 Update 3l 以降では、LinkedVcGroup.login.timeout=120000 の設定を vim-commons-vsphere.properties から webclient.properties ファイルに移動します。このオプションを編集すると待機時間を短縮できるため、いずれかの vCenter Server ログインに時間がかかっていても、他のインスタンスのログイン時間には影響を与えません。

  回避策：/etc/vmware/vsphere-ui/webclient.properties を編集し、LinkedVcGroup.login.timeout の値を 120000 からより小さい値（ミリ秒単位）に変更します。ただし、値 <= 0（ゼロ以下）は無限タイムアウトです。

vSphere Lifecycle Manager の問題

• VMware vSphere Lifecycle Manager アップデートのダウンロードのスケジュール設定されたタスクを編集できない

  vSphere Client で、vCenter Server インスタンスに移動して 構成 タブの スケジュール設定されたタスク を選択し、VMware vSphere Lifecycle Manager アップデートのダウンロード を選択し、編集 をクリックすると、既存の設定を変更できません。

  回避策：トピック「vSphere Lifecycle Manager の自動ダウンロード タスクの構成」に記載の手順に従うことで、VMware vSphere Lifecycle Manager アップデートのダウンロード タスクを編集することができます。

vSAN の問題

• vSAN ストレージ プールの空き容量の予測が実際の容量よりも多いと、予期しないストレージ不足が発生することがある

  vSAN ストレージ プールの freeSpace パラメータでは、エラーのあるディスクが除外されず、未使用の容量の予測が実際の容量よりも多く表示されることがあります。その結果、予期しないストレージ不足が発生する可能性があります。この問題は、vSAN ストレージ プールにのみ影響します。

  回避策：ストレージ プールの freeSpace パラメータによって提供される全体的なストレージ容量から、エラーのあるディスクの freeSpace 値を無視して、ストレージ容量を手動で計算します。

以前のバージョンの既知の問題

• vSphere クラスタ サービスの問題
• インストール、アップグレード、および移行の問題
• セキュリティ機能の問題
• ネットワークの問題
• ストレージの問題
• vCenter Server および vSphere Client の問題
• 仮想マシンの管理の問題
• vSphere HA および Fault Tolerance の問題
• vSphere Lifecycle Manager の問題
• その他の問題
• バックアップの問題

vSphere クラスタ サービスの問題

• クラスタ内の vSphere クラスタ サービス エージェント仮想マシンがすべて停止していると、クラスタ内の vSphere DRS が機能しない

  vSphere クラスタ サービス エージェント仮想マシンをクラスタでデプロイまたはパワーオンできない場合、vSphere DRS などのサービスが影響を受けることがあります。

  回避策：問題と回避策の詳細については、VMware ナレッジベースの記事 KB79892 を参照してください。

• vSphere クラスタ サービスをサポートするシステム仮想マシンが、クラスタおよびデータストアのメンテナンス ワークフローに影響を与える場合がある

  vCenter Server 7.0 Update 1 では、vSphere DRS が正常な動作を確実にするために、vSphere クラスタ サービスにより、すべての vSphere クラスタに一連のシステム仮想マシンが追加されています。システム仮想マシンは、暗黙的なデータストア選択ロジックを使用して自動的にデプロイされます。クラスタの構成によっては、システム仮想マシンがクラスタやデータストアのメンテナンス ワークフローの一部に影響を与える場合があります。

  回避策：影響を受けるワークフローや、回避策の詳細については、VMware ナレッジベースの記事 KB79892 および KB80483 を参照してください。

インストール、アップグレード、および移行の問題

• vSphere 7.0 Update 3c へのアップグレードで、ホストの完全同期を強制実行するための追加手順が必要になる場合がある

  vSphere システムでサポートされているアップグレード手順では、まず vCenter Server をアップグレードしてから ESXi をアップグレードします。ただし、7.0 Update 2d 以降のバージョンの ESXi ホストがある特定の環境では、まず ESXi を 7.0 Update 3c に更新してから vCenter Server を更新する必要があります。このようなアップグレード手順では、完全なホスト同期を強制実行するための追加手順が必要です。

  回避策：スーパー管理者権限（root など）を持つユーザーとしてアプライアンス シェルにログインし、次の手順を実行します。

  1. vpxd サービスを停止します。

  2. コマンド /opt/vmware/vpostgres/current/bin/psql -U postgres -d VCDB -c "update VPX_HOST_SYNC_GEN set master_gen=0 where host_id in (select id from VPX_HOST where product_version like '7.0.3%')" を実行します。

  3. vpxd サービスを開始します。

• i40en と i40enu の両方の Intel ネットワーク ドライバがインストールされているホット パッチが適用された ESXi ホストで、vCenter Server 7.0 Update 3c へのアップグレード後に vSphere High Availability の構成に失敗することがある

  Intel i40en ドライバの名前が i40enu に変更され、その後 i40en に戻ったため、vCenter Server 7.0 Update 3c では変更の影響を受ける ESXi ホストが適切にアップグレードされるように、アップグレードの事前チェックが追加されます。ただし、vCenter Server 7.0 Update 3c の後にリリースされた ESXi ホット パッチを適用してからシステムを vCenter Server 7.0 Update 3c にアップグレードすると、ホット パッチが事前チェックにリストされないことがあります。その結果、適切なアップグレード手順を実行できず、vSphere HA がそのようなホストでの構成に失敗することがあります。

  回避策：ホット パッチが適用された ESXi ホストをバージョン 7.0 Update 3c にアップグレードします。

• vCenter Server のアップグレード/移行の事前チェックが「予期しないエラー 87」で失敗する

  Security Token Service (STS) 証明書に Subject Alternative Name (SAN) フィールドが含まれていない場合、vCenter Server のアップグレード/移行の事前チェックは失敗します。この状況は、vCenter 5.5 Single Sign-On 証明書を SAN フィールドのないカスタム証明書に置き換えてから、vCenter Server 7.0 にアップグレードしようとした場合に発生します。アップグレード プロセスによって STS 証明書が無効であると判断され、事前チェックによってアップグレード プロセスが続行されなくなります。

  回避策：STS 証明書を、SAN フィールドを含む有効な証明書に置き換えてから、vCenter Server 7.0 のアップグレードまたは移行を続行します。

• 既存の CIM プロバイダを伴う vSphere 7.0 へのアップグレードに関する問題

  アップグレード後、ESXi には 64 ビットの CIM プロバイダが必要であるため、以前にインストールした 32 ビットの CIM プロバイダは動作を停止します。CIMPDK、NDDK（ネイティブ DDK）、HEXDK、VAIODK（I/O フィルタ）に関連する管理 API 関数が失われ、uwglibc 依存関係に関連するエラーが表示されることがあります。

  Syslog では、モジュールが見つからないため、「32 ビットの共有ライブラリがロードされていません」とレポートされます。

  回避策：対処法はありません。修正するには、新しい 64 ビットの CIM プロバイダをベンダーからダウンロードします。

• vCenter Server High Availability が有効な場合、vCenter Server 7.x の以前のバージョンから vCenter Server 7.0 Update 1 へのパッチ適用がブロックされることがある

  vCenter Server High Availability がアクティブな場合、vCenter Server 7.x の以前のバージョンから vCenter Server 7.0 Update 1 へのパッチ適用がブロックされることがあります。

  回避策：vCenter Server 7.x の以前のバージョンから vCenter Server 7.0 Update 1 にパッチを適用するには、vCenter Server High Availability を削除し、パッシブ ノードと監視ノードを削除する必要があります。アップグレード後、vCenter Server High Availability クラスタを再作成する必要があります。

• 6.7.x vCenter Server システムから vCenter Server サーバ 7.x への移行が UnicodeEncodeError で失敗する

  構成、インベントリ、タスク、イベント、およびパフォーマンス メトリックのすべてのデータをインポートするオプションを選択した場合、英語以外のロケールを使用する vCenter Server システムで、6.7.x vCenter Server システムから vCenter Server 7.x への移行が失敗することがあります。移行のステージ 2 の手順 1 では、vSphere Client で、次のようなエラーが表示されます。

  Error while exporting events and tasks data: …ERROR UnicodeEncodeError: Traceback (most recent call last):

  回避策：移行操作は、次のいずれかを実行して完了できます。

  • 移行のステージ 1 の最後に、デフォルトのオプションである [構成とインベントリ] を選択します。

    このオプションには、タスクとイベントのデータは含まれません。

  • イベント テーブルのデータを消去し、移行を再実行します。

• Windows vCenter Server システムに非 ASCII 文字を含む データベース パスワードがある場合、VMware 移行アシスタントの事前チェックが失敗する

  システムが Windows OS で、非 ASCII 文字を含むパスワードを指定した外部データベースを使用している場合に、VMware 移行アシスタントを使用して 6.x vCenter Server システムを vCenter Server 7.x に移行すると、操作が失敗します。たとえば、「Admin!23迁移」のようなパスワードです。この場合、移行アシスタントのコンソールに次のエラーが表示されます。

  Error:Component com.vmware.vcdb failed with internal errorResolution:File Bugzilla PR to VPX/VPX/vcdb-upgrade

  回避策：なし

• vCenter Server 7.x から vCenter Server 7.0 Update 1 へのアップデート中に、vCenter Single Sign-On パスワードを入力するように求められる

  vCenter Server 7.x から vCenter Server 7.0 Update 1 へのアップデート中に、vCenter Single Sign-On 管理者のパスワードを入力するように求められます。

  回避策：vCenter Server 管理インターフェイスを使用してアップデートを実行する場合は、vCenter Single Sign-On 管理者パスワードを入力する必要があります。

  ソフトウェア パッケージまたは CLI を使用して対話形式でアップデートを実行する場合は、vCenter Single Sign-On 管理者のパスワードをインタラクティブに入力する必要があります。

  ソフトウェア パッケージまたは CLI を使用して非対話的にアップデートを実行する場合は、vCenter Single Sign-On 管理者のパスワードを次の形式の応答ファイルで指定する必要があります。

  { "vmdir.password": "SSO Password of Administrator@<SSO-DOMAIN> user" }

• vCenter Server 7.0 にアップグレードした後、スマート カードと RSA SecurID 認証が機能しなくなることがある

  スマート カードまたは RSA SecurID 認証用に vCenter Server を構成した場合は、vSphere 7.0 アップグレード プロセスを開始する前に、https://kb.vmware.com/s/article/78057 の VMware ナレッジベースの記事を参照してください。ナレッジベースに記載されている回避策を実行しないと、次のエラー メッセージが表示される場合があり、スマート カードまたは RSA SecurID 認証が機能しません。

  「スマート カード認証が機能しなくなることがあります。スマート カードの設定が保存されず、スマート カード認証が機能しなくなることがあります。」

  または

  「RSA SecurID 認証が機能しなくなることがあります。RSA SecurID の設定が保持されず、RSA SecurID 認証が機能しなくなることがあります。」

  回避策：vSphere 7.0 にアップグレードする前に、https://kb.vmware.com/s/article/78057 の VMware ナレッジベースの記事を参照してください。

• vSphere Lifecycle Manager イメージを使用して、VMware vSphere High Availability が有効なクラスタに ESXi ホストを追加すると、NSX を適用または削除できなくなることがある

  vSphere Lifecycle Manager イメージを使用して複数の ESXi ホストを vSphere HA が有効なクラスタに追加しているときに NSX を適用または削除する操作を開始すると、NSX 関連の操作が失敗し、vSphere Client に次のようなエラー メッセージが表示されることがあります。

  vSphere HA agent on some of the hosts on cluster <cluster_name> is neither vSphere HA master agent nor connected to vSphere HA master agent. Verify that the HA configuration is correct.

  この問題は、vSphere Lifecycle Manager が、クラスタに追加される ESXi ホストの vSphere HA を一度に 1 つずつ構成するために発生します。vSphere HA による構成操作が進行中のときに NSX の適用操作または削除操作を実行すると、2 つの異なる ESXi ホストに対する vSphere HA の構成操作の間に NSX 操作がキューに登録される可能性があります。このような場合、クラスタの健全性チェック エラーで NSX 操作が失敗します。これは、その時点でのクラスタの状態が、想定される状態（すべての ESXi ホストで vSphere HA が構成され、実行されている状態）と一致しないためです。複数の ESXi ホストをクラスタに同時に追加すると、問題が発生する可能性が高くなります。

  回避策：クラスタで、vSphere HA を無効にしてから有効にします。NSX の適用操作または削除操作を続行します。

• vCenter Server 7.0 システムのアップグレード後、vSphere Client の vSphere Pod の [サマリ] タブに IP アドレスが表示されない

  vCenter Server 7.0 システムを新しいバージョンにアップグレードした場合、vSphere Client の vSphere Pod の [サマリ] タブに IP アドレスが表示されなくなりました。

  回避策：Kubernetes CLI Tools for vSphere を使用して、ポッドの詳細を確認します。

  1. 前提条件として、ポッド名と名前空間名をコピーします。

     • vSphere Client で [ワークロード管理] > [クラスタ] の順に移動します。

     • [制御プレーン ノードの IP アドレス] タブに表示されている IP アドレスをコピーします。

     • https://<control_plane_node_IP_address> にアクセスして、Kubernetes CLI Tools の kubectl と kubectl-vsphere をダウンロードできます。

       または、「Kubernetes CLI Tools for vSphere のダウンロードとインストール」の手順を実行します。

  2. vSphere の CLI プラグインを使用して、ポッドの詳細を確認します。

     1. 次のコマンドを使用して、スーパーバイザー クラスタにログインします。

        kubectl vsphere login --server=https://<server_adress> --vsphere-username <your user account name> --insecure-skip-tls-verify

     2. 手順 1 でコピーした名前を使用して、ポッドの詳細を取得するコマンドを実行します。

        kubectl config use-context <namespace_name>

        および

        kubectl describe pod <pod_name> -n <namespace_name>

  その結果、IP アドレスが次のような出力に表示されます。

  $ kubectl describe pod helloworld -n my-podvm-ns ...

  Status: Running

  IP: 10.0.0.10

  IPs:

  IP: 10.0.0.10 ...

• 外部 Platform Services Controller を持つ vCenter Server を 6.7u3 から 7.0 にアップグレードすると、VMAFD エラーで失敗する

  外部 Platform Services Controller を使用する vCenter Server デプロイをアップグレードする場合は、Platform Services Controller を vCenter Server Appliance に統合します。エラー install.vmafd.vmdir_vdcpromo_error_21 でアップグレードが失敗する場合、VMAFD の firstboot プロセスが失敗しています。VMAFD の firstboot プロセスは、ソース Platform Services Controller および複製パートナー vCenter Server Appliance から、VMware Directory Service データベース (data.mdb) をコピーします。

  回避策：外部 Platform Services Controller を持つ vCenter Server をアップグレードする前に、ソース Platform Services Controller または複製パートナー vCenter Server Appliance のイーサネット アダプタ上で TCP セグメンテーション オフロード (TSO) およびジェネリック セグメンテーション オフロード (GSO) を無効にします。ナレッジベースの記事 (https://kb.vmware.com/s/article/74678) を参照してください

• 事前チェック段階で vCenter Server システムのアップグレードが失敗する

  認可 (Authz) の接続が制限されているため、vCenter Server システムのアップグレードが事前チェック段階で失敗することがあります。/var/log/vmware/vpxd-svcs/vpxd-svcs*.log ファイルに、次のようなエントリが記録されます。

  Session count for user [after add]: <DOMAIN-NAME>\machine-xxxx is 200​Session limit reached for user: <DOMAIN-NAME>\machine-xxxx with 200 sessions.

  インベントリをロードするために vSphere Client からの応答に遅延が生じる場合もあります。

  回避策：service-control --restart vmware-vpxd-svcs コマンドを使用して、vCenter Server システムで vmware-vpxd-svcs を再起動します。このコマンドは、ワークフローの中断を回避するために vCenter Server システムで実行されている他のアクティビティがない場合のみ使用してください。詳細については、VMware ナレッジベースの記事 KB81953 を参照してください。

• CLI を使用して vCenter Server をアップグレードすると、vSphere Authentication Proxy サービスの Transport Security Layer (TLS) 構成が誤って保存される

  vSphere Authentication Proxy サービス (vmcam) が、デフォルトの TLS 1.2 プロトコル以外の特定の TLS プロトコルを使用するように構成されている場合は、この構成が CLI のアップグレード プロセスで保持されます。vSphere は、デフォルトで、TLS 1.2 暗号化プロトコルをサポートしています。TLS 1.2 をサポートしていない製品またはサービスをサポートするために TLS 1.0 および TLS 1.1 プロトコルを使用する必要がある場合は、TLS 構成ユーティリティを使用して、複数の TLS プロトコルのバージョンを有効または無効にすることができます。

  回避策：TLS 構成ユーティリティを使用して、vmcam ポートを構成します。TLS プロトコル構成を管理する方法や、TLS 構成ユーティリティを使用する方法については、『VMware セキュリティ』ドキュメントを参照してください。

• CLI を使用して vCenter Server 7.0 Update 3c にパッチを適用するときに事前チェック エラーが表示されない

  Intel i40en ドライバの名前が i40enu に変更され、その後 i40en に戻ったため、vCenter Server 7.0 Update 3c では変更の影響を受ける ESXi ホストが適切にアップグレードされるように、アップグレードの事前チェックが追加されます。このようなホストがシステムに存在する場合、7.0 Update 3 より前の vCenter Server バージョンから 7.0 Update 3 より後のバージョンに CLI を使用してパッチを適用すると、次のエラーが表示されて失敗することがあります。 Installation failed. Retry to resume from the current state. Or please collect the VC support bundle..

  ただし、このエラーの代わりに、事前チェック エラー メッセージが表示されなければなりません。

  回避策：事前チェック エラーが表示されず、vCenter Server 7.0 Update 3c へのパッチ適用に失敗する場合は、vCenter Server をアップグレードする前に、ISO または単一イメージから作成されたベースラインを使用して、すべての ESXi ホストが ESXi 7.0 Update 3c 以降にアップグレードされていることを確認します。ロールアップ パッチに基づくパッチ ベースラインは使用しないでください。追加のデバッグ ログ情報は、/var/log/vmware/applmgmt にあります。詳細については、VMware ナレッジベースの記事 KB87319 および KB86447 を参照してください。

• vCenter Server のアップグレード中に、スマート カードと RSA SecurID の設定が保持されない場合がある

  vCenter Server 7.0 へのアップグレード後は、RSA SecurID を使用した認証が機能しません。RSA SecurID ログインを使用してログインしようとすると、この問題についてのエラー メッセージが表示されます。

  回避策：スマート カードまたは RSA SecureID を再構成します。

• vSphere 7.0 Update 3c へのアップグレードで、ホストの完全同期を強制実行するための追加手順が必要になる場合がある

  vSphere システムでサポートされているアップグレード手順では、まず vCenter Server をアップグレードしてから ESXi をアップグレードします。ただし、7.0 Update 2c 以降のバージョンの ESXi ホストがある特定の環境では、まず ESXi を 7.0 Update 3c に更新してから vCenter Server を更新する必要があります。このようなアップグレード手順では、完全なホスト同期を強制実行するための追加手順が必要です。

  回避策：スーパー管理者権限（root など）を持つユーザーとしてアプライアンス シェルにログインし、次の手順を実行します。

  1. vpxd サービスを停止します。

  2. コマンド /opt/vmware/vpostgres/current/bin/psql -U postgres -d VCDB -c "update VPX_HOST_SYNC_GEN set master_gen=0 where host_id in (select id from VPX_HOST where product_version like '7.0.3%')" を実行します。

  3. vpxd サービスを開始します。

• vCenter Server for Windows から vCenter Server Appliance 7.0 に移行すると、ネットワーク エラー メッセージが表示されて失敗する

  vCenter Server for Windows を vCenter Server Appliance 7.0 に移行すると、「IP already exists in the network」というエラー メッセージが表示され、失敗します。これにより、移行プロセスで新しい vCenter Server Appliance のネットワーク パラメータを構成できなくなります。詳細については、次のログ ファイルを確認してください。 /var/log/vmware/upgrade/UpgradeRunner.log

  回避策：

  1. ソース vCenter Server for Windows インスタンスですべての Windows Update が完了していることを確認するか、移行が完了するまで Windows Update の自動更新を無効にします。

  2. vCenter Server for Windows から vCenter Server Appliance 7.0 への移行を再試行します。

• i40en と i40enu の両方の Intel ネットワーク ドライバがインストールされているホット パッチが適用された ESXi ホストで、vCenter Server 7.0 Update 3c へのアップグレード後に vSphere High Availability の構成に失敗することがある

  Intel i40en ドライバの名前が i40enu に変更され、その後 i40en に戻ったため、vCenter Server 7.0 Update 3c では変更の影響を受ける ESXi ホストが適切にアップグレードされるように、アップグレードの事前チェックが追加されます。ただし、vCenter Server 7.0 Update 3c の後にリリースされた ESXi ホット パッチを適用してからシステムを vCenter Server 7.0 Update 3c にアップグレードすると、ホット パッチが事前チェックにリストされないことがあります。その結果、適切なアップグレード手順を実行できず、vSphere HA がそのようなホストでの構成に失敗することがあります。

  回避策：ホット パッチが適用された ESXi ホストをバージョン 7.0 Update 3c にアップグレードします。

• max_vfs モジュール パラメータを使用して SR-IOV デバイスの仮想関数の数を構成すると、変更が反映されないことがある

  vSphere 7.0 では、仮想インフラストラクチャ管理 (VIM) API を使用して（たとえば vSphere Client を通じて）、SR-IOV デバイスの仮想関数の数を構成できます。このタスクでは ESXi ホストを再起動する必要はありません。VIM API 構成を使用した後に、max_vfs モジュール パラメータを使用して SR-IOV 仮想関数の数を構成しようとすると、VIM API の構成によってオーバーライドされるため、変更が反映されないことがあります。

  回避策：なし。SR-IOV デバイスの仮想関数の数を構成するには、毎回同じ方法を使用します。VIM API を使用するか、max_vfs モジュール パラメータを使用して ESXi ホストを再起動します。

• アップグレードされた vCenter Server Appliance インスタンスで、ソース インスタンスのすべてのセカンダリ ネットワーク (NIC) が保持されない

  メジャー アップグレードで、vCenter Server Appliance のソース インスタンスが VCHA NIC 以外の複数のセカンダリ ネットワークで構成されている場合、ターゲット vCenter Server インスタンスでは VCHA NIC 以外のセカンダリ ネットワークが保持されません。ソース インスタンスが、Distributed Switch ポート グループの一部である複数の NIC で構成されている場合、アップグレードで NIC 構成は保持されません。標準ポート グループの一部である vCenter Server Appliance インスタンスの構成は保持されます。

  回避策：なし。ターゲット vCenter Server Appliance インスタンスのセカンダリ ネットワークを手動で構成します。

• 外部 Platform Services Controller を持つ vCenter Server をアップグレードまたは移行した後、Active Directory を使用して認証を行うユーザーが、新しくアップグレードされた vCenter Server インスタンスにアクセスできなくなる

  外部 Platform Services Controller を持つ vCenter Server をアップグレードまたは移行した後に、新しくアップグレードされた vCenter Server が Active Directory ドメインに参加していない場合、Active Directory を使用して認証を行うユーザーは vCenter Server インスタンスにアクセスできなくなります。

  回避策：新しい vCenter Server インスタンスが Active Directory ドメインに参加していることを確認します。ナレッジベースの記事 (https://kb.vmware.com/s/article/2118543) を参照してください

• Oracle データベースを使用する外部 Platform Services Controller を持つ vCenter Server for Windows を移行すると失敗する

  Oracle のイベントおよびタスク テーブルに ASCII 以外の文字列が含まれていると、イベントおよびタスク データをエクスポートするときに移行が失敗することがあります。次のエラー メッセージが表示されます。UnicodeDecodeError

  回避策：なし。

• ESXi ホストのアップグレード後、ホストの修正タスクが失敗すると、ホスト プロファイルのコンプライアンス チェックで非準拠ステータスが表示される

  非準拠ステータスは、プロファイルとホスト間での不整合を示します。

  この不整合は、ESXi 7.0 で要求ルールの重複が許可されていないにもかかわらず、使用中のプロファイルに重複するルールが含まれていることが原因で発生することがあります。たとえば、ESXi 6.5 または ESXi 6.7 からバージョン 7.0 にアップグレードする前にホストから抽出したホスト プロファイルを使用しており、ホスト プロファイルにシステムのデフォルト ルールで重複した要求ルールが含まれている場合、問題が発生することがあります。

  回避策：

  1. ホスト プロファイル ドキュメントから、システムのデフォルト ルールで重複した要求ルールを削除します。

  2. コンプライアンスの状態を確認します。

  3. ホストを修正します。

  4. 前の手順で問題が解決しない場合は、ホストを再起動します。

• vCenter Server 管理インターフェイスにエラー メッセージが表示される

  vCenter Server 7.0 へのインストールまたはアップグレード後、vCenter Server 管理インターフェイス内の [アップデート] パネルに移動すると、「URL を確認して、やり直してください」というエラー メッセージが表示されます。このエラー メッセージが表示されても [アップデート] パネル内の機能は使用できるため、利用可能なアップデートの表示、ステージング、インストールは可能です。

  回避策：なし。

• VMware vCenter Server High Availability が有効な環境の監視ノードまたはパッシブ ノードへのパッチ適用が失敗することがある

  vCenter Server High Availability が有効になっている環境で、監視またはパッシブ ノードへのパッチ適用が失敗し、次のようなメッセージが表示されることがあります。

  ​RuntimeError: unidentifiable C++ exception。

  回避策：vCenter Server High Availability を無効にします。vCenter Server システムにパッチを適用します。vCenter Server High Availability を再度有効にします。

• vCenter Server システムに vCenter Server 7.0.0a へのパッチを適用した後、vCenter Server ストレージ クライアントの TLS バージョンがデフォルトに戻ることがある

  vCenter Server ストレージ クライアント サービスの TLS 構成がデフォルトの TLS 1.2 専用以外に設定されている場合、vCenter Server システムに vCenter Server 7.0.0a へのパッチを適用した後に TLS バージョンがデフォルトに戻されることがあります。

  回避策：TLS 構成ユーティリティを使用して、アップデート後に vCenter Server システムで TLS バージョンを有効または無効にします。

• システムを vCenter Server 7.0.0b にアップデートした後、/var/core フォルダに systemd コア ダンプが発生する

  システムを vCenter Server 7.0.0a または vCenter Server 7.0 のいずれかから vCenter Server 7.0.0b にアップデートすると、/var/core フォルダに core.systemd-journal.393 や core.systemd-udevd.405 などの systemd コア ダンプが発生します。コア ダンプは無害で、削除することができます。

  回避策：なし

• vCenter Server システムを 7.0.0b にアップデートしても、ダイレクト コンソール ユーザー インターフェイス (DCUI) で vCenter Server バージョンがアップデートされない

  システムを vCenter Server 7.0.0a または vCenter Server 7.0 から vCenter Server 7.0.0b にアップデートした後でも、DCUI には以前の vCenter Server バージョンが表示されます。

  回避策：アップデートの完了後、vCenter Server バージョンを更新するには、アプライアンス シェルでコマンド /usr/lib/applmgmt/dcui/notify を実行します。

• Update Planner が「ネットワーク接続または正しくない URL が原因で、構成済みリポジトリにアクセスできません。」というエラーと共に停止する

  vCenter Server のアップデートを簡素化するために vSphere Lifecycle Manager の一部である Update Planner を使用している場合、vSphere Client に次のエラーが表示されることがあります。

  Configured repository is not accessible due to network connectivity or incorrect URL. Verify the repository settings。

  この問題は、抽出した内容を保存するために https:///uploads/dpe/ や DBC パスなどのカスタムのローカル リポジトリを使用した場合に発生します。URL ベースのパッチ適用でカスタムのリポジトリに認証ポリシーが設定されている場合、Update Planner が使用可能なアップデートのリストを取得できないことがあります。

  回避策：カスタム リポジトリ URL へのアクセスに認証が不要になるようにカスタム リポジトリを構成します。

• vCenter Server 7.0.0b へのアップグレード後、vSphere Lifecycle Manager イメージベースのクラスタに vSphere HA エラーが表示される

  vCenter Server 7.0.0b へのアップグレード後、vSphere HA で構成されている vSphere Lifecycle Manager イメージベースのクラスタで、環境に初めてログインした際に vSphere HA 構成に関するエラー メッセージが表示されることがあります。vSphere Client には次のようなメッセージが表示されます。

  Cannot complete the configuration of the vSphere HA agent on the host. または

  Applying HA VIBs on the cluster encountered a failure。

  この問題は、イメージ デポのエクスポートに時間がかかり、タスクがタイムアウトになることがあるために発生します。/storage/log/vmware/vmware-updatemgr/vum-server/vmware-vum-server.log には、次のメッセージが記録されます： ​Export taking too long (Failure case)

  回避策：これは、vCenter Server の起動後 10 分以内に解決する一時的な問題です。この問題は、機能には影響しません。影響を受けるクラスタの vSphere HA は予期したとおりに動作します。パワーオンや移行などの仮想マシンに関連するすべての操作は、このエラーのリカバリが進行中の状態でも、vSphere HA が有効なクラスタ全体で動作します。

• CLI を使用して vCenter Server 7.0 Update 3d にパッチを適用するときに事前チェック エラーが表示されない

  Intel i40en ドライバの名前が i40enu に変更され、その後 i40en に戻ったため、vCenter Server 7.0 Update 3d 以降では変更の影響を受ける ESXi ホストが適切にアップグレードされるように、アップグレードの事前チェックが追加されます。このようなホストがシステムに存在する場合、7.0 Update 3 より前の vCenter Server バージョンから 7.0 Update 3 より後のバージョンに CLI を使用してパッチを適用すると、「Installation failed. Retry to resume from the current state. Or please collect the VC support bundle.」というエラーが表示されて失敗することがあります。ただし、このエラーの代わりに、事前チェック エラー メッセージが表示されなければなりません。

  回避策：事前チェック エラーが表示されず、vCenter Server 7.0 Update 3d へのパッチ適用に失敗する場合は、vCenter Server をアップグレードする前に、ISO または単一イメージから作成されたベースラインを使用して、すべての ESXi ホストが ESXi 7.0 Update 3d にアップグレードされていることを確認します。ロールアップ パッチに基づくパッチ ベースラインは使用しないでください。追加のデバッグ ログ情報は、/var/log/vmware/applmgmt にあります。詳細については、VMware ナレッジベースの記事 KB87319 および KB86447 を参照してください。

セキュリティ機能の問題

• HA 対応の信頼済みクラスタに証明されていないホストが含まれている場合、暗号化された仮想マシンがパワーオンに失敗する

  VMware® vSphere Trust Authority™ で、信頼済みクラスタ上で HA を有効にしていて、クラスタ内の 1 つ以上のホストで証明が失敗した場合、暗号化された仮想マシンはパワーオンできません。

  回避策：信頼済みクラスタからの証明に失敗したすべてのホストを削除するか、修正します。

• DRS 対応の信頼済みクラスタに証明されていないホストが含まれている場合、暗号化された仮想マシンがパワーオンに失敗する

  VMware® vSphere Trust Authority™ で、信頼されたクラスタで DRS を有効にしていて、クラスタ内の 1 つ以上のホストで証明が失敗した場合、DRS はクラスタ内の証明されていないホストで暗号化された仮想マシンをパワーオンしようとすることがあります。この操作により、仮想マシンがロックされた状態になります。

  回避策：信頼済みクラスタからの証明に失敗したすべてのホストを削除するか、修正します。

• <span>vCenter Server</span> インスタンス間での暗号化された仮想マシンの移行またはクローン作成が、vSphere Client を使用して実行しようとすると失敗する

  vSphere Client を使用して vCenter Server インスタンス間で暗号化された仮想マシンを移行またはクローン作成しようとすると、次のエラー メッセージが表示されて操作が失敗します。「現在の状態ではその操作を実行できません。」

  回避策：vCenter Server インスタンス間で、暗号化された仮想マシンを移行またはクローン作成するには、vSphere API を使用する必要があります。

ネットワークの問題

• VMware Remote Console を使用すると、envoy サービスが断続的に失敗することがある

  VMware Remote Console に固有の envoy サービスの問題により、サービスが断続的に失敗することがあります。その結果、vCenter Server 管理インターフェイスまたは vCenter Server API も使用できなくなることがあります。

  回避策：VMware Remote Console の代わりに、vSphere Client を使用します。

• Intel 82599/X540/X550 NIC でのネットワーク パフォーマンスのスループットの低下

  Intel 82599EB/X540/X550 シリーズの NIC のネットワーク パフォーマンスを向上させるために、新しいキュー ペア機能が ixgben ドライバに追加されたことで、vSphere 7.0 の一部のワークロードでは、vSphere 6.7 と比較してスループットが低下することがあります。

  回避策：vSphere 6.7 と同じネットワーク パフォーマンスを実現するために、モジュール パラメータを使用してキュー ペアを無効にすることができます。キュー ペアを無効にするには、次のコマンドを実行します。

  # esxcli system module parameters set -p "QPair=0,0,0,0..." -m ixgben

  コマンドを実行した後、再起動します。

• vSphere クラスタで vSphere with Tanzu を無効にすると、エラーと共に操作が停止する

  スーパーバイザー クラスタの外部にある一部の仮想マシンが、クラスタの任意の NSX セグメント ポート グループにある場合、クリーンアップ スクリプトは、そのようなポートを削除することも、クラスタにある vSphere with Tanzu を無効にすることもできません。vSphere Client では、「Cleanup requests to NSX Manager failed」というエラーが表示され、操作が「Removing 」ステータスで停止します。/var/log/vmware/wcp/wcpsvc.log ファイルに、次のようなエラー メッセージが記録されます。

  Segment path=[...] has x VMs or VIFs attached. Disconnect all VMs and VIFs before deleting a segment.

  回避策：/var/log/vmware/wcp/wcpsvc.log ファイルに示されている仮想マシンをセグメントから削除します。リストアが完了するまで待ちます。

• NSX 6.4.7 にアップグレードした後、IPv6 ネットワーク上のワークロード仮想マシンに固定 IPv6 アドレスが割り当てられている場合、仮想マシンは Edge の IPv6 ゲートウェイ インターフェイスに ping を送信できない

  この問題は、vSphere Distributed Switch を 6.x から 7.0 にアップグレードした後に発生します。

  回避策 1：

  すべてのホストが接続されている Distributed Switch を選択し、[編集] 設定に移動し、[マルチキャスト] オプションで基本に切り替えます。

  回避策 2：

  Edge ファイアウォールに次のルールを追加します。

  ping の許可ルール。

  Multicast Listener Discover (MLD) の許可ルール（icmp6 の type 130 (v1) および type 143 (v2)）。

• Network I/O Control (NetIOC) が有効になっている場合、高スループットの仮想マシンでネットワーク パフォーマンスが低下することがある

  高ネットワーク スループットを必要とする仮想マシンでは、NetIOC を有効にして vSphere 6.7 から vSphere 7.0 にアップグレードすると、スループットが低下することがあります。

  回避策：複数のワールドを有効にするように、ethernetx.ctxPerDev 設定を調整します。

• IPv6 トラフィックが、IPsec を使用する VMkernel ポートを通過できない

  あるポート グループから別のポート グループに VMkernel ポートを移行する場合、IPv6 トラフィックは IPsec を使用する VMkernel ポートを通過しません。

  回避策：影響を受けるサーバから IPsec Security Association (SA) を削除してから、SA を再適用します。IPsec SA を設定および削除する方法については、『vSphere セキュリティ』ドキュメントを参照してください。

• ESX ネットワーク パフォーマンスが向上すると CPU 使用率が部分的に増加する

  ESX ネットワーク パフォーマンスの向上に伴って、CPU 使用率が部分的に増加する場合があります。

  回避策：ネットワーク インターフェイスを削除し、1 つの rx ディスパッチ キューのみを持つようにして追加します。例：

  esxcli network ip interface remove --interface-name=vmk1

  esxcli network ip interface add --interface-name=vmk1 --num-rxqueue=1

• ホット アド、ホット リムーブ、または Storage vMotion の後で、仮想マシンのイーサネット トラフィックが失われることがある

  ホット アド、ホット リムーブ、または Storage vMotion の後で、仮想マシンがイーサネット トラフィックの受信を停止することがあります。この問題は、vNIC のアップリンクで SR-IOV が有効になっている仮想マシンに影響します。PVRDMA 仮想 NIC では、仮想ネットワークのアップリンクが Mellanox RDMA 対応の NIC であり、RDMA の名前空間が構成されている場合に、この問題が発生します。

  回避策：仮想マシンの、影響を受けるイーサネット NIC をホット リムーブしてホット アドすると、トラフィックをリストアできます。Linux ゲスト OS では、ネットワークを再起動すると問題が解決する場合もあります。これらの回避策の効果がない場合は、仮想マシンを再起動してネットワーク接続をリカバリできます。

• 固定 IP アドレスを使用してデプロイした VCSA の IP アドレスを変更する場合、事前に DNS レコードを作成する必要がある

  DDNS の導入により、DNS レコードの更新は、DHCP で構成されたネットワークを使用してデプロイされた VCSA でのみ機能します。VAMI を通じて vCenter Server の IP アドレスを変更すると、次のエラーが表示されます。

  指定された IP アドレスが、指定されたホスト名に解決されません。

  回避策：考えられる回避策は 2 つあります。

  1. 同じ FQDN と必要な IP アドレスを持つ追加の DNS エントリを作成します。VAMI にログインし、手順に従って IP アドレスを変更します。

  2. ssh を使用して VCSA にログインします。次のスクリプトを実行します。

     ./opt/vmware/share/vami/vami_config_net

     eth0 の IP アドレスを変更するには、オプション 6 を使用します。変更が完了したら、次のスクリプトを実行します。

     ./opt/likewise/bin/lw-update-dns

     VCSA 上のすべてのサービスを再起動して、DNS サーバの IP アドレス情報を更新します。

• NSX Manager で対応する論理スイッチを削除した後、NSX 分散仮想ポート グループ (NSX DVPG) が削除されるまでに、数秒かかる場合があります。

  論理スイッチの数が増えると、NSX Manager で対応する論理スイッチを削除した後、vCenter Server の NSX DVPG が削除されるまでに、より長い時間がかかる場合があります。12,000 個の論理スイッチがある環境では、NSX DVPG が vCenter Server から削除されるまでに約 10 秒かかります。

  回避策：なし。

• 多数の NSX 分散仮想ポート グループが作成されると、hostd がメモリ不足になり、失敗します。

  vSphere 7.0 では、NSX 分散仮想ポート グループは不透明ネットワークよりも非常に多くのメモリを使用します。このため、NSX 分散仮想ポート グループは、同じ量のメモリで不透明ネットワークと同じスケールをサポートできません。

  回避策：NSX 分散仮想ポート グループの使用をサポートするには、ESXi ホストのメモリ量を増やします。システムに仮想マシンをサポートするのに十分なメモリがあることを確認した場合、次のコマンドを使用して、hostd のメモリを直接増やすことができます。

  localcli --plugin-dir /usr/lib/vmware/esxcli/int/ sched group setmemconfig --group-path host/vim/vmvisor/hostd --units mb --min 2048 --max 2048

  これにより、hostd が、環境内の仮想マシン用に通常予約されているメモリを使用することに注意してください。このため、ESXi ホストがサポートできる仮想マシンの数が減少する可能性があります。

• 仮想マシンでネットワークの予約が設定されている場合、DRS が vMotion を誤って起動することがある

  仮想マシンでネットワークの予約が設定されている場合、DRS は、指定された要件を満たすホストにのみ仮想マシンを移行することを想定しています。NSX トランスポート ノードがあるクラスタでは、一部のトランスポート ノードが NSX-T 分散仮想スイッチ (N-VDS) によりトランスポート ゾーンに参加し、その他のトランスポート ノードが vSphere Distributed Switch (VDS) 7.0 によりトランスポート ゾーンに参加すると、DRS が誤って vMotion を起動することがあります。この問題は、次の場合に発生することがあります。

  • 仮想マシンがネットワーク予約で構成された NSX 論理スイッチに接続する。

  • 一部のトランスポート ノードが N-VDS を使用してトランスポート ゾーンに参加し、その他のトランスポート ノードが VDS 7.0 を使用してトランスポート ゾーンに参加するか、またはトランスポート ノードが別の VDS 7.0 インスタンスを介してトランスポート ゾーンに参加する。

  回避策：すべてのトランスポート ノードを N-VDS または同じ VDS 7.0 インスタンスによってトランスポート ゾーンに参加させます。

• NSX ポートグループに VMkernel NIC (vmknic) を追加すると、vCenter Server は「ステートレス ホスト上の NSX ポートグループへの VMKernel アダプタの接続は、サポートされている操作ではありません。分散ポート グループを使用してください。」というエラーを報告する。

  • vSphere Distributed Switch (VDS) のステートレス ESXi では、NSX ポート グループ上の vmknic はブロックされます。代わりに、分散ポート グループを使用する必要があります。

  • Distributed Switch 上のステートフル ESXi では、NSX ポート グループ上の vmknic はサポートされていますが、NSX ポート グループ上で vmknic を使用している場合、vSAN に問題が発生する可能性があります。

  回避策：同じ Distributed Switch で分散ポート グループを使用します。

• QLogic 4x10GE QL41164HFCU CNA に対して vCenter Server から SRIOV を有効にできないことがある

  QLogic 4x10GE QL41164HFCU CNA を使用している場合、物理ネットワーク アダプタの [設定の編集] ダイアログに移動して SR-IOV を有効にしようとすると、操作が失敗することがあります。SR-IOV を有効にしようとすると、ESXi ホストのネットワークが停止する可能性があります。

  回避策：SR-IOV を有効にするには、ESXi ホストで次のコマンドを使用します。

  esxcfg-module

ストレージの問題

• SmartPQI コントローラを使用する HPE Gen10 サーバでのディスクのホット リムーブとホット インサートの後、VMFS データストアが自動的にマウントされない

  エクスパンダなしの SmartPQI コントローラを使用する HPE Gen10 サーバの SATA ディスクが、ホット リムーブされてから同じマシンの別のディスク ベイにホット インサートされる場合、または複数のディスクがホット リムーブされてから別の順序でホット インサートされる場合、ディスクに新しいローカル名が割り当てられることがあります。そのディスク上の VMFS データストアはスナップショットとして表示され、デバイス名が変更されたため、自動的にマウントし直されることはありません。

  回避策：なし。SmartPQI コントローラでは、順序なしのホット リムーブおよびホット インサート操作はサポートされていません。

• すべてのアクティブなパスでのエラーのため、ESXi によって NVMeOF デバイスへの I/O が終了されることがある

  場合によっては、リンクの問題やコントローラの状態が原因で、NVMeOF デバイスへのすべてのアクティブ パスで I/O エラーが登録されることがあります。いずれかのパスのステータスが「非活動」に変わった場合、高パフォーマンス プラグイン (HPP) では、大量のエラーが表示されている別のパスは選択されないことがあります。そのため、I/O が失敗します。

  回避策：構成オプション /Misc/HppManageDegradedPaths を無効にして、I/O のブロックを解除します。

• NVMe ベースの VMFS データストアに対する VOMA チェックがエラーで失敗する

  VOMA チェックは NVMe ベースの VMFS データストアではサポートされておらず、次のエラーが表示されて失敗します。

  ERROR: Failed to reserve device. Function not implemented 

  例：

  # voma -m vmfs -f check -d /vmfs/devices/disks/: <partition#>
  Running VMFS Checker version 2.1 in check mode
  Initializing LVM metadata, Basic Checks will be done
  
  Checking for filesystem activity
  Performing filesystem liveness check..|Scanning for VMFS-6 host activity (4096 bytes/HB, 1024 HBs).
  ERROR: Failed to reserve device. Function not implemented
  Aborting VMFS volume check
  VOMA failed to check device : General Error

  回避策：なし。VMFS メタデータを分析する必要がある場合は、-l オプションを使用して収集し、VMware ユーザー サポートに渡します。ダンプを収集するためのコマンドは、次のとおりです。

  voma -l -f dump -d /vmfs/devices/disks/:<partition#> 

• 仮想マシンの再構成 API を使用して、暗号化された First Class Disk を暗号化された仮想マシンに接続すると、エラーが発生して失敗することがある

  FCD と仮想マシンが異なる暗号化キーで暗号化されている場合、VM reconfigure API を使用して、暗号化された FCD を暗号化された仮想マシンに接続しようとすると、次のエラー メッセージが表示されて失敗することがあります。

  Cannot decrypt disk because key or password is incorrect.

  回避策：VM reconfigure API ではなく、attachDisk API を使用して、暗号化された FCD を暗号化された仮想マシンに接続します。

• スパンされた VMFS データストアの非ヘッド エクステントが Permanent Device Loss (PDL) 状態になると、ESXi ホストが応答しない状態になることがある

  この問題は、スパンされた VMFS データストアの非ヘッド エクステントがヘッド エクステントとともに失敗した場合には発生しません。この場合、データストア全体にアクセスできなくなり、I/O が許可されなくなります。

  これに対して、非ヘッド エクステントは失敗しても、ヘッド エクステントがアクセス可能である場合、データストアのハートビートは正常であると表示されます。また、ホストとデータストア間の I/O も継続されます。ただし、失敗した非ヘッド エクステントに依存するすべての I/O は失敗し始めます。失敗した I/O の解決を待つ間に、他の I/O トランザクションが蓄積され、ホストが応答していない状態になります。

  回避策：この問題を解決するには、非ヘッド エクステントの PDL 条件を修正します。

• APD または PDL の状態からリカバリした後、クラスタ化された仮想ディスクのサポートが有効になっている VMFS データストアがアクセスできないままになることがある

  この問題は、クラスタ化された仮想ディスクのサポートが有効になっているデータストアでのみ発生します。データストアが All Paths Down (APD) または Permanent Device Loss (PDL) 状態からリカバリすると、そのデータストアはアクセスできないままになります。VMkernel ログには、次のような複数の SCSI3 reservation conflict メッセージが表示されることがあります。

  2020-02-18T07:41:10.273Z cpu22:1001391219)ScsiDeviceIO: vm 1001391219: SCSIDeviceCmdCompleteCB:2972: Reservation conflict retries 544 for command 0x45ba814b8340 (op: 0x89) to device "naa.624a9370b97601e346f64ba900024d53"

  この問題は、クラスタに参加している ESXi ホストがデータストアの SCSI 予約を失い、データストアのリカバリ後に常に自動的に再取得することができないために発生する可能性があります。

  回避策：次のコマンドを使用して、手動で予約を登録します。

  vmkfstools -L registerkey /vmfs/devices/disks/<device name>

  <device name> は、データストアが作成されたデバイスの名前です。

• Virtual NVMe コントローラが Windows 10 ゲスト OS のデフォルトのディスク コントローラである

  ハードウェア バージョン 15 以降を使用している場合、Virtual NVMe コントローラが以下のゲスト OS のデフォルトのディスク コントローラになります。

  Windows 10

  Windows Server 2016

  Windows Server 2019

  Virtual NVMe コントローラを使用している場合、一部の機能が使用できないことがあります。詳細については、https://kb.vmware.com/s/article/2147714 を参照してください

  注：一部のクライアントでは、以前のデフォルトの LSI Logic SAS が使用されます。これには、ESXi Host Client と PowerCLI が含まれます。

  回避策：Virtual NVMe で使用できない機能が必要な場合は、VMware 準仮想化 SCSI (PVSCSI) または LSI Logic SAS に切り替えます。VMware 準仮想化 SCSI (PVSCSI) の使用方法については、https://kb.vmware.com/s/article/1010398 を参照してください

• ESXi ホストを vSphere 7.0 にアップグレードした後、コア要求ルールの重複が存在すると、予期しない動作が発生することがある

  要求ルールは、NMP、HPP などのマルチパス プラグインが特定のストレージ デバイスへのパスを所有するかどうかを判定します。ESXi 7.0 は、要求ルールの重複をサポートしていません。ただし、レガシー リリースからのアップグレードによって継承された既存の要求ルールに重複したルールを追加しても、ESXi 7.0 ホストはアラートを表示しません。重複したルールを使用すると、ストレージ デバイスが意図しないプラグインによって要求され、予期しない結果が発生する可能性があります。

  回避策：重複したコア要求ルールは使用しないでください。新しい要求ルールを追加する前に、一致する既存の要求ルールをすべて削除してください。

• コンプライアンスの状態フィルタが設定された CNS クエリが、完了するまでに異常に長い時間がかかることがある

  CNS QueryVolume API を使用すると、ボリュームの健全性やコンプライアンスの状態など、CNS ボリュームに関する情報を取得できます。個々のボリュームのコンプライアンスの状態を確認すると、結果が迅速に取得されます。ただし、複数（数十、または数百）のボリュームのコンプライアンスの状態をチェックするために CNS QueryVolume API を呼び出すと、クエリの実行速度が低下することがあります。

  回避策：一括クエリを使わないようにします。コンプライアンスの状態を取得する必要がある場合は、一度に 1 つのボリュームに対するクエリを実行するか、クエリ API のボリュームの数を 20 以下に制限します。クエリを使用している間は、最高のパフォーマンスを得るために、他の CNS 操作を実行しないようにします。

• <span style="color:#CC0000">New：</span>削除された CNS ボリュームが、CNS ユーザー インターフェイスに既存のボリュームとして一時的に表示されることがある

  CNS ボリュームをバッキングする FCD ディスクを削除した後も、そのボリュームが CNS ユーザー インターフェイスに既存のボリュームとして表示される場合があります。ボリュームを削除しようとすると、失敗します。次のようなエラー メッセージが表示されることがあります。

  The object or item referred to could not be found。

  回避策：次回の完全同期で不整合が解決され、CNS ユーザー インターフェイスが正常に更新されます。

• <span style="color:#CC0000">New：</span>状況によっては、CNS の操作が失敗しても、vSphere Client でタスクのステータスが「成功」と表示されることがある

  この問題は、非準拠のストレージ ポリシーを使用して CNS ボリュームを作成する場合などに発生することがあります。操作は失敗しますが、vSphere Client ではタスクのステータスが「成功」と表示されます。

  回避策：vSphere Client でタスクのステータスが成功になっていても、CNS 操作が成功したとは限りません。操作が正常に完了したことを確認するには、結果を確認してください。

• <span style="color:#CC0000">New：</span>CNS のパーシステント ボリュームの削除操作に失敗すると、vSphere データストア上にボリュームが削除されずに残ることがある

  この問題は、CNS の削除 API でポッドに接続されているパーシステント ボリュームを削除する際に発生することがあります。たとえば、ポッドが実行されている Kubernetes 名前空間を削除する際に発生することがあります。その結果、ボリュームは CNS から消去され、CNS のクエリ操作でボリュームが返らなくなります。しかし、ボリュームはデータストア上に配置され続け、CNS 削除 API 操作を繰り返しても削除することはできません。

  回避策：なし。

vCenter Server および vSphere Client の問題

•  vSphere Client の VMkernel ネットワーク アダプタの [ポートのプロパティ] ページに VLAN ID が表示されない

  vSphere Client で、パス ホスト] > [ネットワークの追加 に移動して、VMkernel ネットワーク アダプタと既存の標準スイッチを選択すると、ポートのプロパティ ページに VLAND ID が表示されないことがあります。この問題は、遅延ロードされ、更新のためのトリガが必要な network-ui モジュールに VLAN ID コンポーネントが含まれているために発生します。

  回避策：ホスト] > [構成] > [ネットワーク] > [仮想スイッチ に移動して network ui モジュールのロードをトリガすると、VLAN ID が表示されます。

• PNID の変更後にベンダー プロバイダがオフラインになる

  vCenter IP アドレスを変更すると（PNID の変更）、登録されているベンダー プロバイダがオフラインになります。

  回避策：ベンダー プロバイダを再登録します。

• vCenter Server をまたがった仮想マシンの移行がエラーで失敗する

  vCenter Server をまたがった vMotion を使用して、仮想マシンのストレージとホストを別の vCenter Server インスタンスに移動するときに、次のエラーが表示されることがあります。 The operation is not allowed in the current state.

  このエラーは、暗号化やその他の I/O フィルタ ルールなどのホスト ベースのルールを含むストレージ ポリシーが仮想マシンに割り当てられている場合に、ユーザー インターフェイス ウィザードで、ホストの選択手順の後、データストアの選択手順の前に表示されます。

  回避策：ホスト ベースのルールを持たないストレージ ポリシーに、仮想マシンとそのディスクを割り当てます。ソース仮想マシンが暗号化されている場合は、仮想マシンの復号化が必要になる場合があります。次に、vCenter Server をまたがった vMotion アクションを再試行します。

• [ハードウェアの健全性] タブのストレージ センサー情報に、vCenter Server ユーザー インターフェイス、ホスト ユーザー インターフェイス、および MOB の正しくない値が表示される

  vCenter Server ユーザー インターフェイスで [ホスト] > [監視] > [ハードウェア健全性] > [ストレージ センサー] の順に移動すると、ストレージ情報として正しくない値または不明な値が表示されます。同じ問題が、ホスト ユーザー インターフェイスと MOB パス runtime.hardwareStatusInfo.storageStatusInfo でも発生します。

  回避策：なし。

• vSphere ユーザー インターフェイスのホストの高度な設定で、現在のプロダクト ロッカーの場所が空として表示される（デフォルトでは空）

  vSphere ユーザー インターフェイスのホストの高度な設定で、現在のプロダクト ロッカーの場所が空として表示されます（デフォルトでは空）。これは、実際のプロダクトの場所 symlink が作成され、有効であることと一貫していません。これにより、ユーザーに混乱が生じます。デフォルトは、ユーザー インターフェイスからは修正できません。

  回避策：ユーザーは、ホストで esxcli コマンドを使用して、現在のプロダクト ロッカーの場所のデフォルトを次のように修正できます。

  1.既存のプロダクト ロッカーの場所の設定を次のように削除します： "esxcli system settings advanced remove -o ProductLockerLocation"

  2.プロダクト ロッカーの場所の設定を適切なデフォルト値で再追加します。

  2.a.ESXi が完全インストールの場合、デフォルト値は "/locker/packages/vmtoolsRepo" export PRODUCT_LOCKER_DEFAULT="/locker/packages/vmtoolsRepo"

  2.b.ESXi が autodeploy などの PXEboot 構成である場合のデフォルト値は"/vmtoolsRepo" export PRODUCT_LOCKER_DEFAULT="/vmtoolsRepo"

  次のコマンドを実行して、場所を自動的に確認します。 export PRODUCT_LOCKER_DEFAULT=`readlink /productLocker`

  設定を追加します： esxcli system settings advanced add -d "Path to VMware Tools repository" -o ProductLockerLocation -t string -s $PRODUCT_LOCKER_DEFAULT

  上の手順 2 のすべての操作をまとめて、次のように 1 つのコマンドを発行することができます。

  esxcli system settings advanced add -d "Path to VMware Tools repository" -o ProductLockerLocation -t string -s `readlink /productLocker`

• [Skyline Health] ページに文字化けが表示される

  vSphere Client で、vCenter Server に移動して、または vSphere Client ナビゲータで ESXi ホストを選択して、[監視] > [Skyline Health] の順にクリックすると、ページに以下のロケールで文字化けが表示されます。韓国語、日本語、ドイツ語、フランス語。

  回避策：英語のロケールに切り替えます。

仮想マシンの管理の問題

• 仮想マシン上の既存のネットワーク アダプタを追加または変更することができない

  仮想マシン上の既存のネットワーク アダプタを追加または変更すると、「Cannot complete operation due to concurrent modification by another operation」などのエラーが表示され、vSphere Client で仮想マシンの再設定タスクが失敗することがあります。仮想マシンが実行されている ESXi ホストの /var/log/hostd.log ファイルには、次のようなログが記録されます。

  2020-07-28T07:47:31.621Z verbose hostd[2102259] [Originator@6876 sub=Vigor.Vmsvc.vm:/vmfs/volumes/vsan:526bc94351cf8f42-41153841cab2f9d9/bad71f5f-d85e-a276-4cf6-246e965d7154/interop_l2vpn_vmotion_VM_1.vmx] NIC: connection control message: Failed to connect virtual device 'ethernet0'.

  vpxa.log ファイルには、次のようなエントリが記録されます。 2020-07-28T07:47:31.941Z info vpxa[2101759] [Originator@6876 sub=Default opID=opId-59f15-19829-91-01-ed] [VpxLRO] -- ERROR task-138 -- vm-13 -- vim.VirtualMachine.reconfigure: vim.fault.GenericVmConfigFault:

  回避策：クラスタ内の各 ESXi ホストについて、次の手順を実行します。

  1. SSH を使用して ESXi ホストに接続し、次のコマンドを実行します。

     esxcli system module parameters set -a -p dvfiltersMaxFilters=8192 -m dvfilter

  2. ESXi ホストをメンテナンス モードに切り替えます。

  3. ESXi ホストを再起動します。

  詳細については、VMware ナレッジベースの記事 KB80399 を参照してください。

• AMD Opteron Generation 3 (Greyhound) プロセッサ搭載の ESXi 6.5 ホストが、vCenter Server 7.0 Update 1 システムで Enhanced vMotion Compatibility (EVC) AMD REV E または AMD REV F クラスタに参加できない

  vCenter Server 7.0 Update 1 では、vSphere DRS や vSphere HA などの vSphere クラスタ サービスは、vCenter Server から独立してサービスを機能させるため、ESX エージェント仮想マシン上で実行されます。ただし、ESX エージェント仮想マシンの AMD プロセッサの CPU ベースラインには POPCNT SSE4A 命令が含まれているため、AMD Opteron Generation 3 (Greyhound) プロセッサを搭載した ESXi 6.5 ホストは、vCenter Server 7.0 Update 1 システムで EVC モード AMD REV E および AMD REV F を有効にできません。

  回避策：なし

• カスタマイズ スクリプトの postcustomization セクションが、ゲストのカスタマイズの前に実行される

  Linux ゲスト OS でゲスト カスタマイズ スクリプトを実行すると、カスタマイズ仕様で定義されているカスタマイズ スクリプトの precustomization セクションがゲスト カスタマイズの前に実行され、その後に postcustomization セクションが実行されます。仮想マシンのゲスト OS で Cloud-Init を有効にすると、Cloud-Init の既知の問題のために、カスタマイズの前に postcustomization セクションが実行されます。

  回避策：Cloud-Init を無効にし、標準のゲスト カスタマイズを使用します。

• 共有ストレージを使用しない vSphere vMotion、Storage vMotion、vMotion でのグループ移行操作がエラーで失敗する

  複数のディスクとマルチレベルのスナップショットがある仮想マシンでグループ移行操作を実行すると、操作が失敗し、次のエラーが表示されることがあります。 com.vmware.vc.GenericVmConfigFault Failed waiting for data. Error 195887167. Connection closed by remote host, possibly due to timeout.

  回避策：失敗した仮想マシンに対して、一度に 1 台ずつ移行操作を再試行します。

• URL から OVF または OVA テンプレートをデプロイすると、「403 許可されていません」エラーで失敗する

  HTTP クエリ パラメータを含む URL は、サポートされていません。たとえば、http://webaddress.com?file=abc.ovf または Amazon の事前署名済み S3 URL などです。

  回避策：ファイルをダウンロードし、ローカル ファイル システムからデプロイします。

• 名前に ASCII 以外の文字が含まれているローカル OVF ファイルをインポートまたはデプロイすると、エラーが発生して失敗することがある

  名前に ASCII 以外の文字が含まれているローカル .ovf ファイルをインポートすると、「400 Bad Request Error」エラーが表示されることがあります。このような .ovf ファイルを使用して vSphere Client に仮想マシンをデプロイすると、デプロイ プロセスが 0% で停止します。その結果、「400 Bad Request Error 」または「500 Internal Server Error」が表示されることがあります。

  回避策：

  1. .ovf および .vmdk ファイル名から ASCII 以外の文字を削除します。

     • .ovf ファイルを編集するには、テキスト エディタで開きます。

     • ASCII 以外の .vmdk ファイル名を検索し、それを ASCII に変更します。

  2. 保存したファイルを再度インポートするかデプロイします。

• <span style="color:#CC0000">New：</span>仮想マシン フォルダ内のネストされたオブジェクトの 3 階層目が表示されない

  次の手順を実行してください。

  1. データセンターに移動し、仮想マシン フォルダを作成します。

  2. 仮想マシン フォルダにネストされた仮想マシン フォルダを作成します。

  3. 2 階層目のフォルダに、別のネストされた仮想マシン、仮想マシン フォルダ、vApp、または仮想マシン テンプレートを作成します。

  その結果、[仮想マシンおよびテンプレート] インベントリ ツリーで、ネストされた 3 階層目のフォルダのオブジェクトが表示されません。

  回避策：3 階層目のネストされたフォルダ内のオブジェクトを表示するには、2 階層目のネストされたフォルダに移動して [仮想マシン] タブを選択します。

• vSphere Lifecycle Manager が有効なクラスタで vSAN ファイル サービスの操作が失敗する

  ESXi ホストの状態の変更時に、vSphere ESX Agent Manager (EAM) との競合状態が原因で vSphere Lifecycle Manager が有効なクラスタで vSAN ファイル サービスの操作が失敗することがあります。この問題は、アップグレード中、パワーオン、パワーオフ、起動などの操作中、またはホストがメンテナンス モードまたはスタンバイ モードを終了したときなどに発生します。ESXi ホストの状態が変更される前にエンドポイントが利用できなくなると、競合状態が発生します。この状況で、EAM は解決できない修正プロセスを開始し、vSAN ファイル サービスなど、他のサービスからの操作が失敗します。

  回避策：vSphere ESX Agent Manager を再起動します。

vSphere HA および Fault Tolerance の問題

• クラスタ全体の APD などのストレージにアクセスできない状態からリカバリした後、クラスタ内の仮想マシンの実体がなくなることがある

  クラスタで HA と VMCP が有効になっている場合でも、クラスタ全体の APD がリカバリした後に、一部の仮想マシンが実体のない状態になることがあります。

  この問題は、以下の条件が同時に満たされた場合に発生することがあります。

  • クラスタ内のすべてのホストで APD が発生し、VMCP のタイムアウトに達するまでリカバリしない。

  • ホストでの APD が原因で、HA プライマリがフェイルオーバーを開始する。

  • HA フェイルオーバー中のパワーオン API が、次のいずれかの理由で失敗する。

    • 同じホスト全体の APD

    • クラスタ全体でのカスケード APD

    • ストレージの問題

    • リソースの利用不可

  • FDM が障害の発生した仮想マシンを登録解除しておらず、複数のホストが同じ仮想マシンをレポートしていることが VC のホスト同期によって応答されている場合に、FDM の登録解除と VC のスティール仮想マシン ロジックが開始することがある。FDM と VC の両方が、異なるホストの同じ仮想マシンを対象にした異なる登録済みコピーを登録解除するため、仮想マシンは実体がなくなります。

  回避策：APD のリカバリ後、クラスタ内で実体のない仮想マシンを手動で登録解除し、再登録する必要があります。

  実体のない仮想マシンを手動で再登録しない場合、HA は実体のない仮想マシンのフェイルオーバーを試みますが、APD がいつリカバリされるかに応じて、5 ～ 10 時間かかる場合があります。

  このような場合、クラスタの全体的な機能は影響を受けず、HA は仮想マシンの保護を継続します。これは、問題の発生中にVC に表示される内容に関するアノマリです。

vSphere Lifecycle Manager の問題

• vSphere 7.0 リリースの vSAN クラスタで、vSphere Lifecycle Manager と vSAN ファイル サービスの両方を有効にできない

  クラスタで vSphere Lifecycle Manager が有効になっている場合、同じクラスタで vSAN ファイル サービスを有効にできません。また、その逆も同様です。vSAN ファイル サービスがすでに有効になっているクラスタで vSphere Lifecycle Manager を有効にするには、最初に vSAN ファイル サービスを無効にして操作を再試行します。1 つのイメージで管理されているクラスタに移行する場合は、そのクラスタで vSphere Lifecycle Manager を無効にすることはできません。

  回避策：なし。

• ハードウェア サポート マネージャが使用できない場合、vSphere High Availability (HA) 機能に影響がある

  1 つのイメージで管理するクラスタにハードウェア サポート マネージャを使用できない場合に、ファームウェアとドライバのアドオンが選択され、vSphere HA が有効になっていると、vSphere HA 機能が影響を受けます。以下のエラーが発生することがあります。

  • クラスタでの vSphere HA の構成に失敗する。

  • ホスト上で vSphere HA エージェントの構成を完了できない： Applying HA VIBs on the cluster encountered a failure.

  • vSphere HA の修正が失敗する： A general system error occurred: Failed to get Effective Component map.

  • vSphere HA を無効にできない：ソリューションの削除タスクが失敗しました。 A general system error occurred: Cannot find hardware support package from depot or hardware support manager.

  回避策：

  • ハードウェア サポート マネージャが一時的に使用できない場合は、次の手順を実行します。

  1. ハードウェア サポート マネージャを vCenter Server に再接続します。

  2. [ホストおよびクラスタ] メニューからクラスタを選択します。

  3. [構成] タブを選択します。

  4. [サービス] で、[vSphere の可用性] をクリックします。

  5. vSphere HA を再度有効にします。

  • ハードウェア サポート マネージャが完全に使用できない場合は、次の手順を実行します。

  1. ハードウェア サポート マネージャとハードウェア サポート パッケージをイメージ仕様から削除します。

  2. vSphere HA を再度有効にします。

  3. [ホストおよびクラスタ] メニューからクラスタを選択します。

  4. [更新] タブを選択します。

  5. [編集] をクリックします。

  6. ファームウェアとドライバのアドオンを削除し、[保存] をクリックします。

  7. [構成] タブを選択します。

  8. [サービス] で、[vSphere の可用性] をクリックします。

  9. vSphere HA を再度有効にします。

• vSphere Lifecycle Manager で修正プロセスを実行した後、I/OFilter がクラスタから削除されない

  vSphere Lifecycle Manager でクラスタを修正してクラスタから I/OFilter を削除する操作が次のエラー メッセージとともに失敗します。iofilter XXX already exists。iofilter は、インストール済みとして表示されたままになります。

  回避策：

  1. vCenter Server 管理対象オブジェクト (IoFilterManager) から IOFilter API UninstallIoFilter_Task を呼び出します。

  2. vSphere Lifecycle Manager でクラスタを修正します。

  3. vCenter Server 管理対象オブジェクト (IoFilterManager) から IOFilter API ResolveInstallationErrorsOnCluster_Task を呼び出して、データベースを更新します。

• vSphere Lifecycle Manager で vSphere HA 対応のクラスタを修正しているときに vSphere HA を無効にしてから再度有効にすると vSphere HA エラー状態になる

  クラスタの修正プロセスで vSphere HA を無効にしてから再度有効にすると、vSphere HA 健全性チェックでホストに vSphere HA VIB がインストールされていないと報告され、修正プロセスが失敗することがあります。次のエラー メッセージが表示されることがあります。Setting desired image spec for cluster failed。

  回避策：クラスタの修正操作が終了した後、クラスタの vSphere HA を無効にしてから再度有効にします。

• 大規模クラスタにおいて、vSphere Lifecycle Manager での推奨イメージの確認のパフォーマンスが低下する

  ホストが 16 台を超える大規模クラスタでは、推奨の生成タスクが完了するまでに 1 時間以上かかる場合やハングしているように見える場合があります。推奨タスクの完了時間は、各ホストで構成されているデバイスの数と、推奨される有効なイメージを取得する前に vSphere Lifecycle Manager が処理する必要があるデポのイメージ候補の数によって異なります。

  回避策：なし。

• 大規模クラスタにおいて、vSphere Lifecycle Manager でのハードウェアの互換性の確認のパフォーマンスが低下する

  ホストが 16 台を超える大規模クラスタでは、検証レポートの生成タスクが完了するまでに最大で 30 分かかる場合やハングしているように見える場合があります。完了時間は、各ホストで構成されているデバイスの数と、クラスタで構成されているホストの数によって異なります。

  回避策：なし

• vSphere Lifecycle Manager でクラスタを修正するときに、英語以外の言語で不完全なエラー メッセージが表示される

  vCenter Server のユーザー インターフェイスで、ローカライズされた言語の不完全なエラー メッセージが表示されることがあります。メッセージは、vSphere Lifecycle Manager でクラスタの修正プロセスが失敗した後に表示されます。たとえば、次のようなエラー メッセージが表示されます。

  英語のエラー メッセージ： Virtual machine 'VMC on DELL EMC -FileServer' that runs on cluster 'Cluster-1' reported an issue which prevents entering maintenance mode: Unable to access the virtual machine configuration: Unable to access file[local-0] VMC on Dell EMC - FileServer/VMC on Dell EMC - FileServer.vmx

  フランス語のエラー メッセージ： La VM « VMC on DELL EMC -FileServer », située sur le cluster « {Cluster-1} », a signalé un problème empêchant le passage en mode de maintenance : Unable to access the virtual machine configuration: Unable to access file[local-0] VMC on Dell EMC - FileServer/VMC on Dell EMC - FileServer.vmx

  回避策：なし。

• ベースラインを使用するクラスタを単一のイメージを使用するクラスタに変換するとき、vSphere HA VIB が削除されることを示す警告が表示される

  ベースラインを使用する vSphere HA 対応のクラスタを単一のイメージを使用するクラスタに変換するとき、vmware-fdm コンポーネントが削除されることを示す警告メッセージが表示されることがあります。

  回避策：このメッセージは無視してかまいません。変換プロセスによって vmware-fdm コンポーネントがインストールされます。

• プロキシ サーバ経由でインターネットからパッチ アップデートをダウンロードするように vSphere Update Manager が構成されている状態で、vSphere 7.0 へのアップグレードを行って Update Manager が vSphere Lifecycle Manager に変換された後、VMware パッチ リポジトリからのパッチのダウンロードに失敗することがある

  以前のリリースの vCenter Server では、vCenter Server と vSphere Update Manager に対してプロキシ設定を個別に構成できました。vSphere 7.0 にアップグレードすると、vSphere Update Manager サービスは vSphere Lifecycle Manager サービスの一部になります。vSphere Lifecycle Manager サービスの場合、プロキシ設定は vCenter Server Appliance 設定から構成されます。プロキシ サーバ経由でインターネットからパッチ アップデートをダウンロードするように Update Manager が構成されている一方で vCenter Server Appliance にプロキシ設定の構成がない場合、vCenter Server をバージョン 7.0 にアップグレードすると、vSphere Lifecycle Manager は VMware デポに接続できず、パッチまたはアップデートをダウンロードできません。

  回避策：vCenter Server Appliance 管理インターフェイス (https://<vCenter Server Appliance の FQDN または IP アドレス>:5480) にログインして vCenter Server Appliance のプロキシ設定を構成し、vSphere Lifecycle Manager でプロキシを使用できるようにします。

• Java クライアントを使用して修正タスクを確認する際に、修正操作から結果を抽出できない

  Java クライアントを使用して修正タスクを確認する際に、結果を抽出すると、ConstraintValidationException エラーと共に失敗することがあります。この問題は、修正中に ESXi ホストがメンテナンス モードに切り替わらず、「スキップされました」というステータスになった場合に発生しますが、同時に、連続する修正操作に対して「処理中」というフラグが誤って表示されます。これにより、Java クライアントで ConstraintValidationException エラーが発生し、修正操作の結果を抽出できません。

  回避策：ESXi ホストがメンテナンス モードに切り替わらない原因となっている問題を修正し、修正操作を再試行します。

• ROBO (Remote Office and Branch Office) 環境の一般的な vSphere Lifecycle Manager デポとローカル デポが同期しない場合がある

  インターネットへのアクセスがないか制限されている、または vCenter Server への接続が制限されている ROBO クラスタは、vCenter Server の vSphere Lifecycle Manager にアクセスしなくても、ローカル デポからイメージをダウンロードできます。ただし、vSphere Lifecycle Manager は、中央レベルでのみ事前検証済みイメージの形式でソフトウェア推奨事項を生成し、デポのオーバーライドでは推奨イメージの内容を利用できない場合があります。

  回避策：推奨イメージを使用する場合は、デポのオーバーライドと中央デポの間でコンテンツが同期されていることを確認します。

• ロックダウン モードが有効になっている ESXi ホストで vSphere Lifecycle Manager を使用したクラスタの修正に失敗することがある

  ロックダウン モードが有効になっている ESXi のホストがクラスタにある場合、vSphere Lifecycle Manager を使用した修正操作によって、そのようなホストがスキップされることがあります。ログ ファイルに、「Host scan task failed」や「com.vmware.vcIntegrity.lifecycle.EsxImage.UnknownError An unknown error occurred while performing the operation.」などのエラーが表示されます。

  回避策：ロックダウン モードの例外リストに root ユーザーを追加し、クラスタの修正を再試行します。

• アップデート後に vSphere Lifecycle Manager ワークフローを使用して、OEM コンテンツを含む ESXi イメージを使用してクラスタを作成することができない

  Dell ESXi 7.0 Update 2a などの OEM コンテンツを含む ESXi イメージを Dell ESXi 7.0 Update 3d にアップデートすると、VMware の基本イメージに含まれているが OEM によってパッケージ化された非同期 VIB によってオーバーライドされている、一部の予約済み VIB が削除されることがあります。重要度の低いベースラインを使用してシステムをアップデートし、OEM コンテンツを含む ESXi イメージを使用して新しいバージョンにアップデートした後も、同じ問題が発生することがあります。たとえば、重要度の低いベースラインを使用して 7.0 Update 2 にアップデートしてから、Dell ESXi 7.0 Update 3 イメージを使用して 7.0 Update 3 にアップデートすると、予約されていた VIB が削除されることもあります。そのため、ESXi ホストでアップデート後のバージョン使用して、単一イメージで管理される vSphere Lifecycle Manager クラスタを作成することはできません。操作は失敗し、バックトレースに次のようなエラーが表示されます。

  2021-11-24T09:42:49Z lifecycle: 2101166: HostSeeding:956 ERROR Extract depot failed: ('VMW_bootbank_bnxtroce_216.0.58.0-23vmw.703.0.0.18644231', 'Failed to add reserved VIB VMW_bootbank_bnxtroce_216.0.58.0-23vmw.703.0.0.18644231: not found in the reserved VIB cache storage')2021-11-24T09:42:50Z lifecycle: 2101166: imagemanagerctl:373 ERROR Extract depot failed.021-11-24T09:42:50Z lifecycle: 2101166: imagemanagerctl:152 ERROR [ReservedVibExtractError] ('VMW_bootbank_bnxtroce_216.0.58.0-23vmw.703.0.0.18644231', 'Failed to add reserved VIB VMW_bootbank_bnxtroce_216.0.58.0-23vmw.703.0.0.18644231: not found in the reserved VIB cache storage')

  回避策：vSphere Lifecycle Manager ワークフローの代わりに、インタラクティブ アップグレードまたはスクリプトを使用したアップグレードを使用します。

• vCenter Server 7.0.0b へのアップグレード後、vSphere Client の vSphere Lifecycle Manager ホーム ビューに [ロールアップの更新のみを表示] トグル ボタンが表示されない

  vCenter Server 7.0.0b では、[ロールアップの更新のみを表示] トグル ボタンを使用することで、vSphere Lifecycle Manager の使用時にベースラインに含めるパッチをフィルタリングして選択することができます。

  このボタンは、vSphere Client の vSphere Lifecycle Manager ホーム ビューで [メニュー] > [Lifecycle Manager] の順に選択して [Lifecycle Manager] ペインの [更新] タブで利用できます。このボタンは、[新規] > [ベースライン] の順に選択して表示される [ベースラインの作成] ウィザードで [パッチの手動選択] 画面の [ベースライン] タブでも利用することができます。

  ただし、vCenter Server 7.0.0b へのアップグレード後も、[ロールアップの更新のみを表示] トグル ボタンが表示されない場合があります。

  回避策：vCenter Server 7.0.0b へのアップグレード後、vSphere Client を再起動します。詳細については、「サービスの開始、停止、再起動」を参照してください。

• vSphere Client で、vSphere Lifecycle Manager ホーム ビューのタブを開くと、[ロールアップの更新のみを表示] トグル ボタンが常に有効になる

  vCenter Server 7.0.0b では、[ロールアップの更新のみを表示] トグル ボタンを使用することで、vSphere Lifecycle Manager の使用時にベースラインに含めるパッチをフィルタリングして選択することができます。

  このボタンは、vSphere Client の vSphere Lifecycle Manager ホーム ビューで [メニュー] > [Lifecycle Manager] の順に選択して [Lifecycle Manager] ペインの [更新] タブで利用できます。このボタンは、[新規] > [ベースライン] の順に選択して表示される [ベースラインの作成] ウィザードで [パッチの手動選択] 画面の [ベースライン] タブでも利用することができます。

  ただし、[更新] タブまたは [パッチの手動選択] 画面のいずれかに移動すると、トグル ボタンが常に有効になります。タブまたは画面から移動する際にボタンを無効にしても、次回開いたときにボタンは有効になります。

  回避策：なし

• Update Planner を使用すると、vSphere Client で更新の取得中に予期しないエラーが発生することがある

  vCenter Server のアップデートを簡素化するために vSphere Lifecycle Manager の一部である Update Planner を使用している場合、vSphere Client に次のエラーが表示されることがあります。

  Unexpected error occurred while fetching the updates

  この問題は、vSphere Client を使用した相互運用性レポートの実行を妨げるカスタム HTTPS ポートを使用している場合に発生します。

  回避策：API を手動で起動します。詳細については、「vSphere Automation API」を参照してください。

その他の問題

• バージョン 6.5 のホスト プロファイルをバージョン 7.0 の ESXi ホストに適用すると、コンプライアンスの確認に失敗する

  バージョン 6.5 のホスト プロファイルをバージョン 7.0 の ESXi ホストに適用すると、コアダンプ ファイル プロファイルがホストに準拠していないと報告されます。

  回避策：考えられる回避策は 2 つあります。

  1. バージョン 6.5 のホスト プロファイルを作成する場合は、ESXi ホストの高度な設定オプション VMkernel.Boot.autoCreateDumpFile を false に設定します。

  2. バージョン 6.5 の既存のホスト プロファイルを適用する場合は、ホスト プロファイルに高度な設定オプション VMkernel.Boot.autoCreateDumpFile を追加し、そのオプションを固定ポリシーに設定して、値を false に設定します。

• 容量不足のためコンテナ ボリュームを移行できない

  vSphere Client のボリュームの移行ダイアログでは、コンテナ ボリュームの現在のサイズとターゲット データストアで使用可能な空き容量が考慮されます。データストアの空き容量がボリューム サイズよりも少ない場合は、移行するデータストアを選択できません。vSphere では、ボリュームの移行時にストレージ ポリシーを保持しますが、ボリュームのファイル サイズはターゲット データストアのタイプとサポートされている機能によって変わる可能性があります。十分な容量がある場合でも、vSphere Client には、移行を実行するための十分な容量がデータストアにないと表示されることがあります。

  回避策：なし

• ブラウザが英語以外の言語に設定されている場合、[アクション] ドロップダウン メニューに項目が含まれない

  ブラウザが英語以外の言語に設定されているときに vSphere Client インベントリの仮想マシンの [サマリ] タブにある [新しい表示に切り替える] ボタンをクリックすると、[ゲスト OS] パネルの [アクション] ドロップダウン メニューに項目が表示されません。

  回避策：仮想マシン ページの上部にある [アクション] ドロップダウン メニューを選択します。

• Dynamic Receive Side Scaling (DYN_RSS) または Generic RSS (GEN_RSS) 機能をオンにすると、Mellanox ConnectX-4 または ConnectX-5 のネイティブ ESXi ドライバのスループットがわずかに低下することがある

  DYN_RSS および GEN_RSS 機能がオンのとき、Mellanox ConnectX-4 または ConnectX-5 のネイティブ ESXi ドライバのスループットが 5% を下回る範囲で低下することがありますが、通常のワークロードへの影響はほとんどありません。

  回避策：次のコマンドを使用して、DYN_RSS および GEN_RSS 機能を無効にすることができます。

  # esxcli system module parameters set -m nmlx5_core -p "DYN_RSS=0 GEN_RSS=0"

  # reboot

• PVRDMA 環境で同じホスト上の 2 台の仮想マシン間の RDMA トラフィックに問題が発生することがある

  PVRDMA 環境の vSphere 7.0 実装では、HCA が配置されている場合、仮想マシンはローカル通信用に HCA を介してトラフィックを渡します。ただし、qedrntv ドライバでは、RDMA トラフィックのループバックは機能しません。たとえば、同一のアップリンク ポートで構成されている仮想マシンで実行されている RDMA のキュー ペアは、相互に通信できません。

  vSphere 6.7 以前では、SRQ が有効な場合にローカルの RDMA トラフィックに HCA が使用されていました。vSphere 7.0 では、RoCE v2 を使用して HW v14 以上で SRQ が有効になっている PVRDMA のバージョンにより、仮想マシンで HCA ループバックを使用します。

  現在のバージョンの Marvell FastLinQ アダプタ ファームウェアでは、同じ PF またはポートの QP 間のループバック トラフィックはサポートされていません。

  回避策：必要なサポートは、vSphere 7.0 に対して認定されている、すぐに利用できるドライバで追加されます。インボックス qedrntv ドライバを使用している場合は、3 ホスト構成を使用して、仮想マシンを 3 台目のホストに移行する必要があります。

• qedrntv ドライバでの Unreliable Datagram トラフィック QP の制限事項

  Marvell FastLinQ qedrntv RoCE ドライバと Unreliable Datagram (UD) トラフィックには制限があります。バルク トラフィックを含む UD アプリケーションは、qedrntv ドライバで動作しない可能性があります。さらに、UD QP は、DMA メモリ領域 (MR) のみを使用できます。物理 MR または FRMR はサポートされていません。UD QP とともに物理 MR または FRMR を使用するアプリケーションは、qedrntv ドライバとともに使用したときにトラフィックを渡すことができません。このようなテスト アプリケーションの既知の例には、ibv_ud_pingpong と ib_send_bw があります。

  iSER、NVMe-oF (RoCE)、PVRDMA などの VMware ESXi 環境における標準の RoCE および RoCEv2 のユースケースは、この問題の影響を受けません。UD トラフィックのユースケースは限定的で、この問題はバルク UD トラフィックを必要とする少数のアプリケーションに影響を及ぼします。

  Marvell FastLinQ ハードウェアは、RDMA UD トラフィック オフロードをサポートしていません。GSI QP をサポートするための VMware PVRDMA 要件を満たすために、UD QP サポートの制限付きソフトウェア専用の実装が qedrntv ドライバに追加されました。実装の目的は、制御パスの GSI 通信のサポートを提供することであり、バルク トラフィックと高度な機能をサポートする UD QP の完全な実装ではありません。

  UD のサポートはソフトウェアで実装されるため、大量のトラフィックに対応できず、パケットがドロップされる可能性があります。これにより、バルク UD トラフィックで障害が発生する可能性があります。

  回避策：バルク UD QP トラフィックは qedrntv ドライバでサポートされていません。現時点では回避策はありません。iSER、NVMe、RDMA、PVRDMA などの VMware ESXi RDMA (RoCE) のユースケースは、この問題の影響を受けません。

• QLogic 578xx NIC を搭載したサーバで iSCSI LUN を頻繁に接続または切断すると、障害が発生することがある

  QLogic 578xx NIC の iSCSI 接続または切断を短時間で頻繁にトリガすると、qfle3 ドライバの問題が原因でサーバに障害が発生することがあります。これは、デバイスのファームウェアの既知の問題によるものです。

  回避策：なし。

• Broadcom の NVMe over FC 環境で、ドライバのアンロードまたはコントローラの切断操作中に ESXi に障害が発生することがある

  Broadcom の NVMe over FC 環境で、ドライバのアンロードまたはコントローラの切断操作中に ESXi に障害が発生し、次のようなエラー メッセージが表示されることがあります。 @BlueScreen: #PF Exception 14 in world 2098707:vmknvmeGener IP 0x4200225021cc addr 0x19

  回避策：なし。

• 一部の Dell サーバ上で i350/X550 NIC の OEM ファームウェアのバージョン番号が ESXi に表示されない

  インボックスの ixgben ドライバは、i350/X550 NIC のファームウェア データ バージョンまたは署名のみを認識します。一部の Dell サーバでは、OEM ファームウェアのバージョン番号が OEM パッケージ バージョンのリージョンにプログラムされています。そのため、インボックスの ixgben ドライバは、この情報を読み取れません。8 桁のファームウェア署名のみが表示されます。

  回避策：OEM ファームウェアのバージョン番号を表示するには、非同期 ixgben ドライバのバージョン 1.7.15 以降をインストールします。

• X710 または XL710 NIC が ESXi で動作しないことがある

  NIC のリセットや VMkernel の内部デバイス ツリーの操作など、特定の破壊的操作を X710 または XL710 NIC に対して開始すると、NIC ハードウェアがパケット以外のメモリからデータを読み取ることがあります。

  回避策：NIC のリセットや、VMkernel の内部デバイス状態の操作を行わないでください。

• NVMe-oF では、システムの再起動後にパーシステントな VMHBA 名が使用されるとは限らない

  NVMe-oF は、vSphere 7.0 の新機能です。サーバに vmhba30+ を使用する USB ストレージ インストールがあり、さらに NVMe over RDMA 構成もある場合は、システムの再起動後に VMHBA 名が変更されることがあります。これは、NVMe over RDMA の VMHBA 名の割り当てが PCIe デバイスと異なるためです。ESXi では、パーシステンスを確保できません。

  回避策：なし。

• サイズが 300 GB 以上の vCenter Server データベースのバックアップに失敗する

  vCenter Server データベースのサイズが 300 GB 以上の場合、ファイルベースのバックアップがタイムアウトして失敗します。次のエラー メッセージが表示されます。 Timeout! Failed to complete in 72000 seconds

  回避策：なし。

• 外部 Platform Services Controller を使用する vCenter Server 6.x から vCenter Server 7.0 にアップグレードされた vCenter Server 7.0 をリストアすると失敗することがある

  外部 Platform Services Controller を使用する vCenter Server 6.x からバージョン 7.0 にアップグレードされた vCenter Server 7.0 をリストアすると、リストアが失敗し、次のエラーが表示されることがあります。 Failed to retrieve appliance storage list

  回避策：リストア プロセスの最初のステージで、vCenter Server 7.0 のストレージ レベルを増やします。たとえば、vCenter Server 6.7 外部 Platform Services Controller のセットアップ ストレージ タイプが small の場合は、リストア プロセス用に large ストレージ タイプを選択します。

• [有効な SSL プロトコル] 構成パラメータがホスト プロファイル修正プロセスで構成されない

  Enabled SSL protocols 構成パラメータがホスト プロファイルの修正中に構成されず、システムのデフォルト プロトコルの tlsv1.2 のみが有効になります。この動作は、vCenter Server 7.0 環境にバージョン 7.0 以前のホスト プロファイルがある場合に発生します。

  回避策：SFCB の TLSV 1.0 または TLSV 1.1 SSL プロトコルを有効にするには、SSH を使用して ESXi ホストにログインし、次の ESXCLI コマンドを実行します。 esxcli system wbem -P <protocol_name>

• ホスト プロファイルを使用してロックダウン モードの設定を構成できない

  セキュリティ ホスト プロファイルを使用してロックダウン モードを構成できず、一度に複数の ESXi ホストに適用できません。各ホストを手動で構成する必要があります。

  回避策：vCenter Server 7.0 では、セキュリティ ホスト プロファイルを使用して、ロックダウン モードを構成し、ロックダウン モードの例外ユーザー リストを管理できます。

• ホスト プロファイルをクラスタに適用すると、Enhanced vMotion Compatibility (EVC) の設定が ESXi ホストで失われる

  構成ファイルを変更したとき、VMware 構成ファイル /etc/vmware/config 内の一部の設定は、ホスト プロファイルによって管理されず、ブロックされます。その結果、ホスト プロファイルがクラスタに適用されると、EVC 設定が失われ、EVC 機能が失われます。たとえば、マスクされていない CPU がワークロードに公開される可能性があります。

  回避策：クラスタ上に適切な EVC ベースラインを再構成し、EVC 設定をリカバリします。

• vCenter Server 7.0 でコア ダンプ パーティションを定義するホスト プロファイルを使用すると、エラーが発生する

  vCenter Server 7.0 では、ホスト プロファイルを使用してコア ダンプ パーティションを構成および管理することはできません。コア ダンプ パーティションが定義されたホスト プロファイルを適用すると、次のエラーが発生します。 No valid coredump partition found.

  回避策：なし。vCenter Server 7.0 では、ホスト プロファイルはファイルベースのコア ダンプのみをサポートしています。

• vi エディタで右クリックして貼り付けることができない

  vCenter Server Appliance インスタンスで vi テキスト エディタを使用している場合は、以前にコピーしたコンテンツを右クリックで貼り付けることはできません。代わりに、vi エディタがビジュアル モードに変更されます。

  回避策：vCenter Server Appliance シェルで /usr/bin/sed -i.bak -E '2alet skip_defaults_vim=1' /etc/vimrc コマンドを実行します。

• 特定のライブラリから vSphere への HTTP 要求が拒否されることがある

  vSphere 7.0 の HTTP リバース プロキシでは、以前のリリースと比べて、より厳しい標準コンプライアンスが適用されます。これにより、アプリケーションが vSphere への SOAP 呼び出し用に使用する一部のサードパーティ製ライブラリで、既存の問題が明らかになる可能性があります。

  このようなライブラリを使用する vSphere アプリケーションを開発する場合や、vSphere スタック内のこのようなライブラリに依存するアプリケーションを含める場合、これらのライブラリが HTTP 要求を VMOMI に送信するときに接続の問題が発生する可能性があります。たとえば、vijava ライブラリから発行される HTTP 要求は、次の形式をとることができます。

  POST /sdk HTTP/1.1
  SOAPAction
  Content-Type: text/xml; charset=utf-8
  User-Agent: Java/1.8.0_221

  この例の構文は、SOAPAction の後にコロンを必要とする HTTP プロトコル ヘッダー フィールドの要件に違反しています。そのため、この要求はフライト中に拒否されます。

  回避策：アプリケーションで非準拠のライブラリを利用している開発者は、そのライブラリに代えて HTTP 標準に準拠するライブラリを使用することを検討してください。たとえば、vijava ライブラリを使用している開発者は、そのライブラリに代えて最新バージョンの yavijava ライブラリを使用することを検討してください。

• 修正プロセスの実行中に、SNMP 動的ファイアウォール ルールセットがホスト プロファイルによって変更される

  SNMP ファイアウォール ルールセットは動的な状態で、ランタイム時に処理されます。ホスト プロファイルが適用されると、ルールセットの構成はホスト プロファイルと SNMP によって同時に管理され、ファイアウォールの設定が予期せずに変更されることがあります。

  回避策：考えられる回避策は 2 つあります。

  • ルールセットが動的に管理されるようにするには、ホスト プロファイルの構成で SNMP ファイアウォール ルールセット オプションを除外します。

  • ルールセットの二重管理を続行するには、必要に応じて、ファイアウォールのルールセットの状態を修正します。

• Broadcom ドライバ lsi_msgpt3、lsi_msgpt35、および lsi_mr3 を使用すると、ダンプ ファイルが表示されることがある

  lsi_msgpt3、lsi_msgpt35、および lsi_mr3 コントローラを使用している場合、ダンプ ファイル lsuv2-lsi-drivers-plugin-util-zdump が表示されることがあります。このプラグイン ユーティリティで使用されている storelib を終了するときに問題が発生します。ESXi の操作に影響はなく、このダンプ ファイルは無視できます。

  回避策：このメッセージは無視してかまいません。次のコマンドを使用して lsuv2-lsi-drivers-plugin を削除できます。

  esxcli software vib remove -n lsuv2-lsiv2-drivers-plugin

• vCenter Server で PCI デバイスの SR-IOV を構成した後、再起動は不要というメッセージが表示されることがあるが、サードパーティの拡張機能によるデバイス構成が失われ、再適用が必要になる場合がある

  ESXi 7.0 では、SR-IOV 構成は再起動しなくても適用され、デバイス ドライバが再ロードされます。ESXi ホストでは、起動時にデバイス ドライバがロードされた後で実行する必要があるデバイス構成をサードパーティの拡張機能によって実行することがあります。デバイス構成を再適用するには、このようなサードパーティの拡張機能を実行するために再起動が必要です。

  回避策：サードパーティ製デバイスの構成を適用するには、SR-IOV を構成してから再起動する必要があります。

• ダイレクト コンソール ユーザー インターフェイス (DCUI) で、子ウィンドウが閉じた後に親ウィンドウの背景に黒色または灰色のゾーンが表示される

  DCUI で ESC キーまたは Enter キーを押すか、[キャンセル] または [OK] ボタンをクリックして子ウィンドウを閉じると、親ウィンドウの外観が変化することがあります。親ウィンドウの一部で、背景色が灰色または黒に変化します。ただし、DCUI からの必要な情報はすべて適切に表示され、DCUI で実行されたすべての操作は正常に完了します。

  回避策：DCUI のカレント ウィンドウを更新したり、キーを押したりせずに、1 分間待機します。

バックアップの問題

• vCenter Server でファイルベースのバックアップに NFS および SMB プロトコルを使用している場合、vCenter Server 7.x から vCenter Server 7.0 Update 1 へのアップデート後にバックアップが失敗する

  vCenter Server でファイルベースのバックアップにネットワーク ファイル システム (NFS) および Server Message Block (SMB) プロトコルを使用している場合、以前のバージョンの vCenter Server 7.x から vCenter Server 7.0 Update 1 へのアップデート後にバックアップが失敗します。applmgmt.log に、「Failed to mount the remote storage」などのエラー メッセージが記録されます。この問題は、パッチ処理中に実行される Linux カーネルの更新によって発生します。この問題は、vCenter Server 7.0 Update 1 の新規インストールでは発生しません。

  回避策：アップデートの完了後に vCenter Server Appliance を再起動します。

• vCenter Server Appliance のリストア後に、Microsoft Active Directory Federation Services (ADFS) のログインに失敗することがある

  ADFS のセットアップ時に vCenter Server の JRE トラストストアに手動で証明書を追加したり、/etc/hosts ファイルを変更したりすると、リストア後に変更が保存されず、ADFS ログインに失敗することがあります。

  回避策：vCenter Server Appliance のリストア後、vCenter Server の JRE トラストストアに ADFS 証明書を追加します。詳細については、「外部 ID プロバイダの信頼された証明書のインポート」を参照してください。vCenter Server Appliance のリストア後、必要なホスト名のマッピングを /etc/hosts ファイルに再度追加します。