更新日：2020 年 8 月 05 日 ESXi 7.0 | 2020 年 4 月 2 日 | ISO ビルド 15843807 vCenter Server 7.0 | 2020 年 4 月 2 日 | ISO ビルド 15952498 各リリース ノートで、追加および更新された機能をご確認ください。

リリース ノートの概要

本リリース ノートには、次のトピックが含まれています。

• 新機能
• 利用可能な言語
• 互換性
• はじめに
• 本リリースのインストールおよびアップグレード
• VMware vSphere 用オープン ソース コンポーネント
• 製品サポートに関する注意事項
• 既知の問題

新機能

VMware vSphere 7.0 の本リリースには、VMware ESXi 7.0 および VMware vCenter Server 7.0 が含まれています。このリリースの新機能および機能拡張については、「vSphere 7.0 の新機能」を参照してください。

利用可能な言語

vSphere 7.0 は、次の言語で使用可能です。

• 英語
• フランス語
• ドイツ語
• スペイン語
• 日本語
• 韓国語
• 簡体字中国語
• 繁体字中国語

vCenter Server、ESXi、vSphere Client、vSphere Host Client を含む vSphere 7.0 のコンポーネントは非 ASCII 入力を受け入れません。

互換性

ESXi と vCenter Server のバージョンの互換性

VMware 製品の相互運用性マトリックス では、ESXi、VMware vCenter Server を含む VMware vSphere コンポーネント、および任意の VMware 製品の現在および以前のバージョンの互換性について、詳細に説明しています。ESXi または vCenter Server をインストールする前に、VMware 製品の相互運用性マトリックスでサポート対象の管理エージェントおよびバックアップ エージェントを確認してください。

vSphere Lifecycle Manager と vSphere Client は、vCenter Server に含まれています。

ESXi のハードウェア互換性

vSphere 7.0 と互換性のあるプロセッサ、ストレージ デバイス、SAN アレイ、および I/O デバイスのリストを確認するには、VMware 互換性ガイドの ESXi 7.0 の情報を参照してください。

ESXi のデバイス互換性

ESXi 7.0 と互換性のあるデバイスを確認するには、VMware 互換性ガイドの ESXi 7.0 の情報を参照してください。

ESXi のゲスト OS の互換性

vSphere 7.0 と互換性のあるゲスト OS を確認するには、VMware 互換性ガイドの ESXi 7.0 の情報を参照してください。

ESXi の仮想マシンの互換性

ESX 3.x 以降（ハードウェア バージョン 4）と互換性がある仮想マシンは、ESXi 7.0 でもサポートされています。ESX 2.x 以降（ハードウェア バージョン 3）と互換性がある仮想マシンは、サポートされていません。サポート対象外の仮想マシンを ESXi 7.0 で使用するには、仮想マシンの互換性をアップグレードする必要があります。『ESXi のアップグレード』のドキュメントを参照してください。

はじめに

vSphere 7.0 では、最大 32 個の物理コアに対して 1 つの CPU ライセンスが必要です。CPU に 32 個を超えるコアがある場合は、「Update to VMware’s per-CPU Pricing Model」で発表されているように、追加の CPU ライセンスが必要になります。ESXi ホストをアップグレードする前に、「新しい VMware ライセンス ポリシーで必要となる CPU ライセンスのカウント」で説明されているライセンス カウント ツールを使用して、必要なライセンスの数を判断できます。

本リリースのインストールおよびアップグレード

本リリースのインストールに関する注意事項

ESXi と vCenter Server のインストールおよび構成の手順については、『ESXi のインストールとセットアップ』および『vCenter Server のインストールとセットアップ』のドキュメントをお読みください。

インストールを行った後、重要な構成手順を行う必要があります。次のドキュメントをお読みください。

• 『vCenter Server およびホスト管理』ドキュメントの「ライセンスの管理」
• 『vSphere ネットワーク』の「ネットワーク」
• 『vSphere のセキュリティ』ドキュメントの「セキュリティ」にある、ファイアウォール ポートの情報

VMware の Configuration Maximums ツールは、vSphere のデプロイの計画に役立ちます。このツールを使用すると、仮想マシン、ESXi、vCenter Server、vSAN、ネットワークなどに対する制限を確認できます。また、2 つまたは 3 つの製品リリースの間で制限を比較することもできます。VMware Configuration Maximums ツールは、デスクトップやラップトップなど、大きな画面のデバイスで表示するのに適しています。

ESXi 7.0 での VMware Tools のバンドルの変更

ESXi 7.0 では、VMware Tools 11.0.5 および VMware Tools 10.3.21 の ISO イメージのサブセットが ESXi 7.0 ホストにバンドルされます。

次の VMware Tools 11.0.5 の ISO イメージが ESXi にバンドルされます。

• windows.iso：Windows Vista 以降用の VMware Tools イメージ

次の VMware Tools 10.3.21 の ISO イメージが ESXi にバンドルされます。

• linux.iso：VMware Tools イメージ（Linux OS、glibc 2.5 以降のバージョン）

次の VMware Tools 11.0.5 の ISO イメージをダウンロードできます。

• darwin.iso：VMware Tools イメージ (OSX)

ESXi にバンドルされていない、特定のプラットフォーム用の VMware Tools をダウンロードする場合は、次のドキュメントに記載されている手順に従ってください。

• VMware Tools 11.0.5 リリース ノート
• VMware Tools 10.3.21 リリース ノート
• VMware Tools のドキュメント

サードパーティ製ソリューションの移行

サードパーティ関連のカスタマイズを伴うアップグレードの詳細については、『ESXi のアップグレード』を参照してください。カスタム ISO を作成するための Image Builder の使用方法の詳細については、『ESXi のインストールとセットアップ』を参照してください。

本リリースへのアップグレードおよびインストールをサポートしない CPU

vSphere 6.7 のサポート対象プロセッサのうち、次のプロセッサは vSphere 7.0 ではサポートされません。

• Intel ファミリ 6、モデル = 2C (Westmere-EP)
• Intel ファミリ 6、モデル = 2F (Westmere-EX)

インストールまたはアップグレード中に、インストーラによってホスト CPU と vSphere 7.0 の互換性がチェックされます。ホスト ハードウェアに互換性がないと非互換性情報メッセージを示すパープル スクリーンが表示され、vSphere 7.0 インストール プロセスが停止します。

次の CPU は vSphere 7.0 リリースでサポートされていますが、今後の vSphere リリースではサポートされない可能性があります。これを踏まえて、使用するハードウェアを決定してください。

• Intel ファミリ 6、モデル = 2A (Sandy Bridge DT/EN, GA 2011)
• Intel ファミリ 6、モデル = 2D (Sandy Bridge EP, GA 2012)
• Intel ファミリ 6、モデル = 3A (Ivy Bridge DT/EN, GA 2012)
• AMD ファミリ 0x15、モデル = 01 (Bulldozer, GA 2012)

本リリースのアップグレードに関する注意点

ESXi ホストおよび vCenter Server のアップグレードの詳細については、『、『ESXi のアップグレード』および『『vCenter Server のアップグレード』を参照してください。

vSphere 7.0 用オープン ソース コンポーネント

vSphere 7.0 で配布されているオープン ソース ソフトウェア コンポーネントに適用される著作権情報およびライセンスについては、http://www.vmware.com をご確認ください。My VMware アカウントにログインする必要があります。[ダウンロード] メニューから [vSphere] を選択します。[オープン ソース] タブでは、vSphere の最新リリースで利用されており、ソース コードやソース コードへの改変の公開が必要な GPL、LGPL、またはその他の類似のライセンスのソース ファイルをダウンロードできます。

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

• VMware vSphere Client

  vSphere 7.0 では、vSphere Client (HTML5) で利用可能な機能を活用できます。Flash ベースの vSphere Web Client は廃止され、使用できなくなりました。詳細については、「Goodbye, vSphere Web Client」を参照してください。

  VMware Host Client は、vCenter Server システムに接続されていない個別の ESXi ホストの管理に使用できる、Web ベースのアプリケーションです。

• VMware vSphere 7.0 および TLS プロトコル

  vSphere 7.0 では、TLS 1.2 がデフォルトで有効です。TLS 1.0 と TLS 1.1 は、デフォルトで無効になっています。vCenter Server を 7.0 にアップグレードし、その vCenter Server インスタンスが ESXi ホスト、その他の vCenter Server インスタンス、またはその他のサービスに接続すると、通信に問題が発生する可能性があります。

  この問題を解決するには、TLS Configurator ユーティリティを使用して、7.0 システムで以前のバージョンのプロトコルを一時的に有効にします。すべての接続で TLS 1.2 を使用した後、安全性の低い旧バージョンを無効にすることができます。詳細については、「TLS Configurator Utility を使用した TLS プロトコル構成の管理」を参照してください。

• 外部 Platform Services Controller の削除

  vSphere 7.0 では、vSphere 7.0 での vCenter Server のデプロイまたはアップグレードに、vCenter Server Appliance を使用する必要があります。事前構成済みの Linux 仮想マシンは、vCenter Server の実行用に最適化されています。新しい vCenter Server には、すべての Platform Services Controller (PSC) サービスが含まれており、認証、証明書管理、ライセンスなどの機能とワークフローが保持されます。外部 Platform Services Controller をデプロイして使用する必要がなくなり、使用できなくなりました。すべての PSC サービスが vCenter Server に統合され、デプロイと管理が簡素化されました。

• vCenter Server for Windows のサポートの削除

  vSphere 7.0 では、vCenter Server for Windows が削除され、サポートは利用できません。詳細については、「Farewell, vCenter Server for Windows」を参照してください。

• ESXi からの VNC サーバの削除

  vSphere 7.0 では、ESXi 組み込みの VNC サーバが削除されました。ユーザーは、RemoteDisplay.vnc.enable 構成を true に設定して、VNC クライアントを使用して仮想マシンに接続することができなくなります。代わりに、ユーザーは、仮想マシンを接続するために、vSphere Client、ESXi Host Client、または VMware Remote Console を介して仮想マシン コンソールを使用する必要があります。仮想マシンに VNC アクセスするユーザーは、WebSocket を介した VNC 接続を提供する VirtualMachine.AcquireTicket ("webmks") API を使用する必要があります。webmks チケットは、仮想マシン コンソールへの認証されたアクセスを提供します。詳細については、『VMware HTML Console SDK のドキュメント』を参照してください。

• VMKLinux の廃止

  vSphere 7.0 では、VMKLinux ドライバの互換性が廃止され、削除されました。vSphere 7.0 には、VMKLinux API および関連する VMKLinux ドライバのサポートは含まれていません。カスタム ISO は、VMKLinux 非同期ドライバを持つことができません。ISO に含まれるすべてのドライバは、ネイティブ ドライバである必要があります。ネイティブ ドライバでサポートされていない、現在サポートされているすべてのデバイスは、機能しなくなり、インストールまたはアップグレード中に認識されなくなります。VCG では、ネイティブ ドライバによってサポートされていないデバイスは、vSphere 7.0 でサポートされているデバイスとして表示されません。

• 32 ビット Userworld のサポートの廃止

  vSphere 7.0 では、32 ビット Userworld のサポートが廃止されました。Userworld は、パートナーが使用する ESXi のコンポーネントであり、ドライバ、プラグイン、およびその他のシステム拡張機能（VIB として配布）を提供します。Userworld には、お客様はアクセスできません。

  vSphere 7.0 では、パートナー開発キットを通じて 64 ビットの Userworld のサポートを提供します。また、このメジャー リリースでは、32 ビットの Userworld のサポートが保持されます。32 ビットの Userworld のサポートは、次のメジャー ESXi リリースで完全に削除されます。機能の損失を回避するには、vSphere 7.0 リリースを超えるアップグレードの前に、ベンダーによって提供されたすべての使用中の VIB を 64 ビットに移行する必要があります。

• Update Manager プラグインの廃止

  vSphere 7.0 では、vSphere Update Manager の管理に使用される Update Manager プラグインが Lifecycle Manager プラグインに置き換えられました。vSphere Update Manager に対する管理操作は、Lifecycle Manager プラグインでも、vSphere Lifecycle Manager の新機能とともに、引き続き使用できます。

• 統合 Windows 認証の廃止

  統合 Windows 認証 (IWA) は vSphere 7.0 で廃止され、今後のリリースで削除される予定です。詳細については、VMware ナレッジベースの記事 KB78506 を参照してください。

• DCUI スマート カード認証の廃止

  今後の vSphere リリースでは、DCUI でのスマート カード認証のサポートが廃止されます。Personal Identity Verification (PIV)、Common Access Card (CAC)、または SC650 スマート カードを使用して DCUI にアクセスする代わりに、vCenter Server、PowerCLI、API 呼び出し、またはユーザー名とパスワードによるログインを通じて操作を行うことをお勧めします。

• ホスト プロファイルでのコア パーティション プロファイルの廃止

  vSphere 7.0 では、ホスト プロファイルのコアダンプ パーティションのサポートが廃止されました。コアダンプ パーティションの代わりに、コアダンプ ファイルに移行する必要があります。

• MyVMware で vSphere Lifecycle Manager と共に使用するベンダー アドオン

  vSphere 7.0 では、vCenter Server インスタンスがプロキシまたは Update Manager Download Service を使用するように構成されている場合、vCenter Server の vSphere Lifecycle Manager を介してベンダー アドオンにアクセスできます。MyVMware からアドオンにアクセスするには、[カスタム ISO およびアドオン] タブに移動します。[OEM カスタマイズによるインストーラ CD およびアドオン] に、各ベンダーのカスタム アドオンがあります。vSphere Lifecycle Manager およびベンダー アドオンの詳細については、「Managing Host and Cluster Lifecycle」ドキュメントを参照してください。

既知の問題

既知の問題には、次のトピックが含まれます。

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

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

• NEW：ESXi 7.0 へのアップグレード後、vmnic および vmhba デバイス名が変更される

  特定のハードウェア プラットフォームでは、以前の ESXi バージョンから ESXi 7.0 へのアップグレード時に、vmnic および vmhba デバイス名（エイリアス）が変更されることがあります。これは、ファームウェアが、プラガブル スロットでないデバイスに対して物理スロット番号 0 を返す ACPI _SUN メソッドを提供しているシステムで発生します。 

  回避策：VMware ナレッジベースの記事 KB2091560 の手順を使用して、デバイス名を変更できます。

• 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 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 ナレッジベースの記事を参照してください。

• 外部 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) を参照してください

• 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 セキュリティ』ドキュメントを参照してください。

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

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

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

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

  vCenter Server for Windows を vCenter Server Appliance 7.0 に移行すると、「IP がネットワークにすでに存在します」というエラー メッセージが表示され、失敗します。これにより、移行プロセスで新しい 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 への移行を再試行します。

   

• 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 以外のセカンダリ ネットワークが保持されません。ソース インスタンスが、DVS ポート グループの一部である複数の 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 を確認して、やり直してください」というエラー メッセージが表示されます。このエラー メッセージが表示されても [アップデート] パネル内の機能は使用できるため、利用可能なアップデートの表示、ステージング、インストールは可能です。

  回避策：なし。

セキュリティ機能の問題

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

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

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

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

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

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

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

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

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

ネットワークの問題

• 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

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

• 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 分散スイッチ (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 アダプタの接続は、サポートされている操作ではありません。分散ポート グループを使用してください。」というエラーを報告する。
  • Distributed Virtual Switch (DVS) のステートレス ESXi では、NSX ポート グループ上の vmknic はブロックされます。代わりに、分散ポート グループを使用する必要があります。
  • DVS 上のステートフル ESXi では、NSX ポート グループ上の vmknic はサポートされていますが、NSX ポート グループ上で vmknic を使用している場合、vSAN に問題が発生する可能性があります。

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

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

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

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

  esxcfg-module

• New：Distributed Resource Scheduler (DRS) を使用しているクラスタ内のホストが、別の Virtual Distributed Switch (VDS) または NSX-T Virtual Distributed Switch (NVDS) と VDS の組み合わせによって NSX-T ネットワークに参加すると、vCenter Server に障害が発生する

  vSphere 7.0 では、vSphere VDS 上で NSX-T ネットワークを DRS クラスタと併用している際に、ホストが同一の VDS または NVDS による NSX トランスポート ゾーンに参加していない場合、vCenter Server に障害が発生することがあります。

  回避策：DRS クラスタ内のホストが、同一の VDS または NVDS を使用する NSX トランスポート ゾーンに参加するようにします。 

ストレージの問題

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

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

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

• nvme_pcie ドライバの loglevel を設定すると、エラーが発生して失敗する

  コマンド esxcli nvme driver loglevel set -l <ログ レベル> を使用して nvme_pcie ドライバの loglevel を設定すると、次のエラー メッセージが表示されてアクションが失敗します。

  ログ レベル 0x2 の設定に失敗しました。

  このコマンドは、NVMe ドライバとの互換性を考慮して保持されていましたが、nvme_pcie ドライバではサポートされていません。

  回避策：なし。この状態は、nvme_pcie 機能が有効になっている場合に発生します。

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

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

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

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

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

  エラー：デバイスの予約に失敗しました。関数が実装されていません 

  例：

  # voma -m vmfs -f check -d /vmfs/devices/disks/: <partition#>
  チェック モードでの VMFS Checker バージョン 2.1 の実行中
  LVM メタデータの初期化中、基本チェックが完了します
  
  ファイルシステムのアクティビティを確認しています
  ファイルシステムの稼動状態チェックを実行しています..|VMFS-6 ホスト アクティビティをスキャンしています（4,096 バイト/HB、1,024 HB）。
  エラー：デバイスの予約に失敗しました。関数が実装されていません
  VMFS ボリュームのチェックを中止しています
  VOMA がデバイスをチェックできませんでした：一般エラー

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

  voma -l -f dump -d /vmfs/devices/disks/:<パーティション #> 

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

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

  ディスクを復号化できません。キーまたはパスワードが正しくありません。

  回避策：仮想マシンの再構成 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 予約競合メッセージが表示されることがあります。

  2020-02-18T07:41:10.273Z cpu22:1001391219)ScsiDeviceIO: vm 1001391219: SCSIDeviceCmdCompleteCB:2972: 予約競合の再試行 544：コマンド 0x45ba814b8340 (op: 0x89)：デバイス "naa. 624a9370b97601e346f64ba900024d53"

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

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

  vmkfstools -L registerkey /vmfs/devices/disks/<デバイス名>

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

• 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 操作を実行しないようにします。

• New：削除された CNS ボリュームが、CNS ユーザー インターフェイスに既存のボリュームとして一時的に表示されることがある

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

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

• New：複数の CNS ボリュームを同じポッドに接続すると、エラーが発生して失敗することがある

  複数のボリュームを同じポッドに同時に接続しようとすると、接続操作中に同じコントローラ スロットが選択されることがあります。その結果、1 つの操作のみが成功し、それ以外のボリュームのマウントは失敗します。

  回避策：Kubernetes が失敗した操作を再試行した後、ノードの仮想マシンでコントローラ スロットが使用可能な場合、操作は成功します。

• New：状況によっては、CNS の操作が失敗しても、vSphere Client でタスクのステータスが「成功」と表示されることがある

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

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

• New：CNS のパーシステント ボリュームの削除操作に失敗すると、vSphere データストア上にボリュームが削除されずに残ることがある

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

  回避策：なし。

vCenter Server および vSphere Client の問題

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

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

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

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

  vCenter Server をまたがった vMotion を使用して、仮想マシンのストレージとホストを別の vCenter Server インスタンスに移動するときに、「現在の状態ではその操作を実行できません」というエラーが表示されることがあります。 

  このエラーは、暗号化やその他の 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`

• vCenter Cloud Gateway が Software-Defined Data Center (SDDC) にリンクされていると、リンクされた SDDC 内の vCenter Server インスタンスがオンプレミスの vSphere Client に表示される

  vCenter Cloud Gateway がオンプレミス vCenter Server と同じ環境にデプロイされ、SDDC にリンクされている場合、SDDC の vCenter Server がオンプレミスの vSphere Client に表示されます。これは予期しない動作であり、リンクされた SDDC の vCenter Server は無視する必要があります。リンクされた SDDC の vCenter Server に関連するすべての操作は、vCenter Cloud Gateway 内で実行されている vSphere Client で実行する必要があります。

  回避策：なし。

仮想マシンの管理の問題

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

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

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

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

  複数のディスクとマルチレベルのスナップショットがある仮想マシンでグループ移行操作を実行すると、操作が失敗し、次のエラーが表示されることがあります。com.vmware.vc.GenericVmConfigFault がデータの待機に失敗しました。エラー 195887167。リモート ホストにより接続が切断されました。タイムアウトの可能性があります。

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

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

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

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

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

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

  回避策：

  1. .ovf および .vmdk ファイル名から ASCII 以外の文字を削除します。
     • .ovf ファイルを編集するには、テキスト エディタで開きます。
     • ASCII 以外の .vmdk ファイル名を検索し、それを ASCII に変更します。
  2. 保存したファイルを再度インポートするかデプロイします。 
• New：仮想マシン フォルダ内のネストされたオブジェクトの 3 階層目が表示されない

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

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

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

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

vSphere HA および Fault Tolerance の問題

• Modified：クラスタ全体の 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 の問題

• すべてのホストでのイメージのセットアップとアップデートをまとめて管理するためにすでに有効になっているクラスタでは、NSX-T を有効にすることはできない

  NSX-T は、イメージ管理のための vSphere Lifecycle Manager 機能と互換性がありません。クラスタ内のすべてのホストでのイメージのセットアップとアップデートをまとめて行うためにクラスタを有効にすると、そのクラスタで NSX-T を有効にすることはできません。ただし、このクラスタに NSX Edge をデプロイすることはできます。

  回避策：ベースラインを使用して管理できる新しいクラスタにホストを移動し、その新しいクラスタで NSX-T を有効にします。

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

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

  回避策：なし。

• vSphere Auto Deploy を使用して、1 つのイメージで管理するクラスタに ESXi 7.0 ホストを追加することができない

  vSphere Auto Deploy の「インベントリへの追加」ワークフローを使用して、1 つのイメージで管理するクラスタに ESXi ホストを追加しようとすると失敗します。この失敗は、既存の Auto Deploy ルールセットでパターンが一致しないために発生します。タスクは警告なしで失敗し、ホストは [検出されたホスト] タブに残ります。

  回避策：

  1. [検出されたホスト] タブで、ルールセットと一致しなかった ESXi ホストを削除します。
  2. ルールを作成するか、既存の Auto Deploy ルールを編集します。ホストのターゲットの場所は、イメージによって管理されるクラスタです。
  3. ホストを再起動します。

   

  ホストは、vSphere Lifecycle Manager でイメージによって管理されるクラスタに追加されます。

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

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

  • クラスタでの vSphere HA の構成に失敗する。
  • ホスト上で vSphere HA エージェントの構成を完了できない：クラスタへの HA VIB の適用中に障害が発生しました。
  • vSphere HA の修正が失敗する：一般的なシステム エラーが発生しました：有効なコンポーネント マップを取得できませんでした。
  • vSphere HA を無効にできない：ソリューションの削除タスクが失敗しました。一般的なシステム エラーが発生しました：デポまたはハードウェア サポート マネージャのハードウェア サポート パッケージが見つかりません。

   

  回避策：

  • ハードウェア サポート マネージャが一時的に使用できない場合は、次の手順を実行します。
  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 対応のクラスタの修正プロセスで 1 台または複数の ESXi ホストを追加すると、次のエラー メッセージが表示されます。クラスタへの HA VIB の適用中に障害が発生しました。

  回避策：クラスタの修正操作が完了した後、次のいずれかのタスクを実行します。

  • 障害が発生した ESXi ホストを右クリックし、[vSphere HA 用に再設定] を選択します。
  • クラスタの vSphere HA を無効にしてから再度有効にします。

   

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

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

  回避策：クラスタの修正操作が終了した後、クラスタの 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

  回避策：なし。

• ベンダー アドオン、コンポーネント、ファームウェアおよびドライバ アドオンを含まないイメージを、これらの要素を含むイメージを使用しているクラスタにインポートしたとき、既存のイメージのイメージ要素が削除されない

  ESXi 基本イメージのみが、インポートされたイメージのものと置き換えられます。

  回避策：インポート プロセスが終了したら、イメージを編集し、必要に応じてベンダー アドオン、コンポーネント、ファームウェアおよびドライバ アドオンを削除します。

• ベースラインを使用するクラスタを単一のイメージを使用するクラスタに変換するとき、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 でプロキシを使用できるようにします。

その他の問題

• バージョン 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 インベントリの仮想マシンの [サマリ] タブにある [新しい表示に切り替える] ボタンをクリックすると、[ゲスト 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 以上の場合、ファイルベースのバックアップがタイムアウトして失敗します。次のエラー メッセージが表示されます。タイムアウトしました。72000 秒以内に完了できませんでした

  回避策：なし。

• ESXi 7.0 ホストのコンプライアンス状態をバージョン 6.5 または 6.7 のホスト プロファイルに対して確認すると、vmhba および vmhba デバイスのエラーが出力される

  nmlx5_core または nvme_pcie ドライバを使用する ESXi 7.0 ホストのコンプライアンス状態をバージョン 6.5 または 6.7 のホスト プロファイルに対して確認すると、次のエラーが表示されることがあります。ここで、address1 と address2 は、影響を受けるシステムに固有です。

  • バス タイプ logical、address1 の vmhba デバイスがホストに存在しません。
  • バス タイプ logical、 address2 の vmrdma デバイスがホストに存在しません。

  このエラーは、ESXi バージョン 7.0 以前の nmlx5_core または nvme_pcie ドライバによって生成されたデバイス アドレス間の不一致が原因で発生します。

  回避策：このエラーは無視してかまいません。ESXi ホストの機能に影響はありません。コンプライアンス状態のエラーを解決するには、ESXi ホスト バージョン 7.0 からホスト プロファイルを再抽出し、新しいホスト プロファイルをホストに適用します。

• 外部 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 をリストアすると、リストアが失敗し、次のエラーが表示されることがあります。アプライアンス ストレージ リストを取得できませんでした

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

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

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

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

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

  セキュリティ ホスト プロファイルを使用してロックダウン モードを構成できず、一度に複数の 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 では、ホスト プロファイルを使用してコア ダンプ パーティションを構成および管理することはできません。コア ダンプ パーティションが定義されたホスト プロファイルを適用すると、次のエラーが発生します。有効なコアダンプ パーティションが見つかりませんでした。

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

• ホスト プロファイルを ESXi ホストからコピーするか、ホスト プロファイルを編集すると、ユーザー入力値が失われる

  一部のホスト プロファイル キーは、キー生成に関する明示的なルールが指定されている場合でもハッシュ計算によって生成されます。その結果、ホストから設定をコピーしたときやホスト プロファイルを編集したときに、応答ファイル内のユーザー入力値が失われます。

  回避策：vCenter Server 7.0 では、ホスト プロファイルを ESXi ホストからコピーしたときやホスト プロファイルを変更したときにユーザー入力の設定が保持されます。

• 特定のライブラリから 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 ライブラリを使用することを検討してください。

• ホスト プロファイルの詳細オプション パラメータを編集して、値を false に設定すると、値が true に設定される

  ホスト プロファイルの詳細オプション パラメータで値を false に設定すると、ユーザー インターフェイスによって空でない文字列値が作成されます。空ではない値は true と解釈され、詳細オプション パラメータはホスト プロファイルで true 値を受け取ります。

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

  • リファレンス ESXi ホストで詳細オプション パラメータを false に設定し、ホスト プロファイルでこのホストから設定をコピーします。
    注：ホストの詳細オプション パラメータを変更する前に、ホストがホスト プロファイルに準拠している必要があります。
  • リファレンス ESXi ホストで詳細オプション パラメータを false に設定し、このホストからホスト プロファイルを作成します。次に、新しいホスト プロファイルから既存のホスト プロファイルにホスト プロファイル設定をコピーします。

   

• 修正プロセスの実行中に、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 を構成してから再起動する必要があります。