VMware Cloud Foundation 4.2 | 2021 年 2 月 9 日 | ビルド 17559673

VMware Cloud Foundation 4.2 の新機能の説明、このバージョンで解決された問題、および既知の問題の回避策を確認します。

 

リリース ノートの概要

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

新機能

VMware Cloud Foundation 4.2 リリースには次のものが含まれます。

  • vSAN HCI Mesh のサポート:VMware Cloud Foundation は、vSAN クラスタで HCI Mesh をサポートします。この機能により、ローカル vSAN クラスタ内のリモート vSAN クラスタからストレージを利用できます。 
  • NSX-T フェデレーションのサポート:NSX-T フェデレーション機能を活用すると、グローバル マネージャを使用して、単一の管理画面ビューで複数の NSX-T ワークロード ドメインをフェデレーションおよび管理できます。グローバル マネージャを使用すると、複数の場所と拡張ネットワーク オブジェクト(Tier-0 および Tier-1 ゲートウェイ)にわたって一貫したセキュリティ ポリシーを構成できます。フェデレーションのガイダンスについては、『VMware Validated Design 6.2 Release Notes』を参照してください。 
  • NSX-T TEP 用の固定 IP アドレス プール:VMware Cloud Foundation 4.2 では、DHCP の代わりに NSX-T ホスト オーバーレイ (TEP) ネットワーク用の固定 IP アドレス プールを活用するための追加の柔軟性が導入されています。これは、均一の L2 クラスタを持つ管理ドメインと VI ワークロード ドメインに適用されます。DHCP は、引き続き、L3 対応またはストレッチ クラスタを備えたワークロード ドメインの NSX-T TEP IP アドレス割り当ての要件です。
  • ESXi ホストでのロックダウン モードのサポート:vCenter Server を介してワークロード ドメインに割り当てられた ESXi ホストでロックダウン モードを有効にすることができます。
  • アップグレードの回復性の向上:VMware Cloud Foundation 4.2 には、パスワードの検証、API パフォーマンスの最適化、ESXi エラー レポートの改善のための事前チェックが含まれています。 
  • リリース バージョンの UI:SDDC Manager の UI には、[リリース バージョン] ページがあり、利用可能な各 VMware Cloud Foundation リリースのコンポーネント情報、新機能、一般的なサポート終了日の情報が含まれています。このページは、アップグレード計画に役立ちます。
  • 拡張されたスキップ アップグレード環境:使用可能なアップグレード バンドルは、SDDC Manager UI またはパブリック API を使用してスキップするターゲット リリースによってフィルタリングできます。
  • vRealize Automation による VMware Cloud Foundation クラウド アカウントのサポートSDDC Manager とワークロード ドメインを VMware Cloud Foundation クラウド アカウントとして、VMware Cloud Assembly と統合できます。VMware Cloud Foundation クラウド アカウントは、包括的なハイブリッド クラウド管理ソリューションを促進するのに役立ちます。詳細については、『vRealize Automation 8.2 リリース ノート』を参照してください。 
  • vSphere Lifecycle Manager (vLCM) イメージでサポートされるサービス仮想マシン:VMware Cloud Foundation は、vLCM イメージを使用したワークロード ドメイン上のサービス仮想マシン (SVM) をサポートします。  この機能により、vLCM イメージを使用して NSX-T ゲスト イントロスペクション (GI) と NSX-T サービス挿入 (SI) をワークロード ドメインに展開できます。SVM は、すでに vLCM ベースライン(以前の VUM)を使用してワークロード ドメインでサポートされていました。
  • コンポーネント情報 (BOM) の更新:製品の新バージョンを使用してコンポーネント情報を更新しました。

Cloud Foundation のコンポーネント情報 (BOM)

Cloud Foundation ソフトウェア製品は、以下に示すソフトウェア コンポーネント情報 (BOM) で構成されています。BOM に記載のコンポーネントは相互運用可能で、互換性があります。

ソフトウェア コンポーネント バージョン 日付 ビルド番号
Cloud Builder 仮想マシン 4.2 2021 年 2 月 9 日

17559673

SDDC Manager 4.2 2021 年 2 月 9 日

17559673

VMware vCenter Server Appliance 7.0 Update 1c 2020 年 12 月 17 日

17327517

VMware ESXi 7.0 Update 1d 2021 年 2 月 04 日 17551050
VMware NSX-T Data Center 3.1.0 2020 年 10 月 30 日 

17107167

VMware vRealize Suite Lifecycle Manager 8.2 パッチ 2 2021 年 2 月 04 日

17513665

Workspace ONE Access 3.3.4 2021 年 2 月 04 日 17498518
vRealize Automation 8.2 2020 年 10 月 6 日 16980951
vRealize Log Insight 8.2 2020 年 10 月 6 日 16957702
vRealize Log Insight Content Pack for NSX-T 3.9.2 該当なし 該当なし
vRealize Log Insight Content Pack for Linux 2.1 該当なし 該当なし
vRealize Log Insight Content Pack for Linux  -Systemd 1.0 該当なし 該当なし
vRealize Log Insight Content Pack for vRealize Suite Lifecycle Manager 8.0.1+ 1.0.2 該当なし 該当なし
vRealize Log Insight Content Pack for VMware Identity Manager 2.0 該当なし 該当なし
vRealize Operations Manager 8.2 2020 年 10 月 6 日 16949153
vRealize Operations Management Pack for VMware Identity Manager 1.1 該当なし 該当なし
  • VMware vSAN は、VMware ESXi バンドルに含まれています。
  • vRealize Suite Lifecycle Manager を使用し、VMware Validated Design 6.2 のドキュメントを使用して、vRealize Automation、vRealize Operations Manager、vRealize Log Insight、および Workspace ONE Access を展開できます。
  • vRealize Log Insight を展開するときに、vRealize Log Insight コンテンツ パックがインストールされます。
  • vRealize Operations Manager を展開するときに、vRealize Operations Manager 管理パックがインストールされます。
  • VMware Solution Exchange および vRealize Log Insight 製品内マーケットプレイスには、vRealize Log Insight 用のコンテンツ パックの最新バージョンのみが格納されています。コンポーネント情報の表には、VMware Cloud Foundation がリリースされた時点で利用可能であったパックの最新バージョンが含まれています。Cloud Foundation のコンポーネントを展開する場合は、製品内マーケットプレイスのコンテンツ パックのバージョンが、このリリースで使用されている vRealize Log Insight よりも新しいものである可能性があります。

VMware のソフトウェア エディションのライセンス情報

SDDC Manager ソフトウェアは、Cloud Foundation の下でライセンスが供与されます。Cloud Foundation の一部として、SDDC Manager ソフトウェアは特定の VMware ソフトウェア製品を展開します。

SDDC Manager によって展開される次の VMware ソフトウェア コンポーネントは、Cloud Foundation の下でライセンスが供与されます。

  • VMware ESXi
  • VMware vSAN
  • VMware NSX-T Data Center

SDDC Manager によって展開される次の VMware ソフトウェア コンポーネントは、別途ライセンスが必要です。

  • VMware vCenter Server
    Cloud Foundation システムに展開されているすべての vCenter Server に必要なライセンスは 1 つのみです。

購入したライセンスでライセンス供与される特定の VMware ソフトウェア エディションの詳細については、上記のCloud Foundation のコンポーネント情報 (BOM)セクションを参照してください。

製品の全般的な情報については、 VMware Cloud Foundationを参照してください。

サポート対象のハードウェア

サポートされる構成の詳細については『VMware 互換性ガイド (VCG)』および『プランニングおよび準備ガイド』の「前提条件チェックリスト」タブの「ハードウェア要件」セクションを参照してください。

ドキュメント

Cloud Foundation のドキュメントにアクセスするには、VMware Cloud Foundation 製品ドキュメントを参照してください。

SDDC Manager が展開可能な VMware ソフトウェア製品のドキュメントにアクセスするには、該当の製品ドキュメントを表示して、画面のドロップダウン メニューから適切なバージョンを選択します。

ブラウザの互換性と画面解像度

Cloud Foundation Web ベースのインターフェイスは、Internet Explorer を除く、次の 2 つの Web ブラウザの最新バージョンをサポートしています。

  • Google Chrome
  • Mozilla Firefox
  • Microsoft Edge
  • Internet Explorer:バージョン 11

Web ベースのユーザー インターフェイスの場合、サポートされる標準の解像度は 1024 × 768 ピクセルです。最良の結果を得るには、次のテスト済みの画面解像度を使用してください。

  • 1024 × 768 ピクセル(標準)
  • 1366 × 768 ピクセル
  • 1280 × 1024 ピクセル
  • 1680 × 1050 ピクセル

1024 × 768 よりも低い解像度(960 × 640、800 × 480 など)はサポートされていません。

インストールとアップグレードに関する情報

VMware Cloud Foundation 4.2 を新しいリリースとしてインストールするか、VMware Cloud Foundation 4.1.0.1 または VMware Cloud Foundation 4.1 から VMware Cloud Foundation 4.2 にアップグレードできます

新規製品リリースのインストール

新規インストール プロセスには、次の 3 つのフェーズがあります。

フェーズ 1:環境の準備

プランニングおよびプランニングおよび準備ガイドには、標準アーキテクチャ モデルを使用して、VMware Cloud Foundation で Software-Defined Data Center (SDDC) を実装するために必要なソフトウェア、ツール、および外部サービスの情報が提供されています。

フェーズ 2:すべてのサーバを ESXi でイメージ化

Cloud Foundation のコンポーネント情報 (BOM) セクションに記載されている ESXi バージョンを使用して、すべてのサーバをイメージ化します。ESXi のインストールについては、『VMware Cloud Foundation 導入ガイド』を参照してください。

フェーズ 3:Cloud Foundation 4.2 のインストール

Cloud Foundation の展開については、『VMware Cloud Foundation 導入ガイド』を参照してください。

Cloud Foundation 4.2 へのアップグレード

VMware Cloud Foundation 4.1.0.1 または VMware Cloud Foundation 4.1 から VMware Cloud Foundation 4.2 にアップグレードできます。 詳細については、VMware Cloud Foundation ライフサイクル管理』を参照してください。

プライベート API へのアクセス

基本認証を使用するプライベート API へのアクセスは、今後のリリースで廃止される予定です。パブリック API の使用に切り替える必要があります。

解決した問題

今回のリリースでは、次の問題が解決されています。

  • vRealize Suite Lifecycle Manager で失敗した環境を削除した結果、vRealize Automation/vRealize Operations Manager ロード バランサの構成が失われる。

  • VMware Cloud Foundation が、vLCM が有効なワークロード ドメインでのサービス仮想マシン (SVM) をサポートしていない。

  • Cloud Foundation が、Tier-1 ゲートウェイでのスタンバイ再配置を有効にしない。

  • VMware Cloud Foundation 4.1 は VMware vSAN HCI メッシュをサポートしていない。

  • NSX Manager の証明書のインストールに失敗する。

  • オーバーレイ トラフィック用に別個の vSphere Distributed Switch (vDS) を持つワークロード ドメインにクラスタを追加すると、アップリンクと物理 NIC の間で適切なマッピングが行われないことがある。

  • ワークロード管理 (vSphere with Tanzu) が展開されているクラスタは拡張できない。

  • VMware Cloud Foundation 4.1 では、vRealize Automation および Workspace ONE Access のマルチ テナントはサポートされない。

  • vCenter Server 証明書を SDDC Manager から置き換えた後、vSphere と vRealize Log Insight の統合が機能しなくなる。

  • SDDC Manager で NSX Manager の証明書を置き換えると、NSX Container Plug-in (NCP) がクラッシュする。

  • SDDC Manager の [パスワード管理] ページで、PSC SSO 管理者のアカウント タイプが正しく表示されない。

  • データセンター内でトップオブラック スイッチが停止すると、NSX-T Data Center によって提供されるセグメントやサービスの可用性が失われる場合がある。

  • Distributed Switch にホストを追加するプロセスで、vmnic と管理 vmk が VSS から Distributed Switch に移行される場合、Distributed Switch に追加するために選択された最初の vmnic が管理ポート グループに関連付けられたアップリンクにマッピングされるようにする必要がある。これにより、管理 vmk が VSS から Distributed Switch に移行されるときに管理接続が失われることがなくなります。

  • [ワークロード管理] ウィザードが vSphere Client で誤った vCenter Server にリダイレクトする

既知の問題

既知の問題には次のものがあります。

VMware Cloud Foundation の既知の問題
  • ワークロード管理で NSX-T Data Center フェデレーションがサポートされていない

    ワークロード ドメインの NSX-T Data Center インスタンスが NSX-T Data Center フェデレーションに参加している場合、ワークロード管理 (vSphere with Tanzu) をワークロード ドメインに展開することはできません。

    回避策:なし。

  • ストレッチ クラスタで、NSX-T ゲスト イントロスペクション (GI) と NSX-T サービス挿入 (SI) がサポートされていない

    NSX-T ゲスト イントロスペクション (GI) または NSX-T サービス挿入 (SI) が有効になっているストレッチ クラスタはサポートされていません。VMware Cloud Foundation は、AZ 固有のネットワーク構成を許可するために、トランスポート ノード プロファイルを AZ2 ホストから切り離します。NSX-T GI と NSX-T SI では、クラスタ内のすべてのホストに同じトランスポート ノード プロファイルを接続する必要があります。

    回避策:なし

  • コンポーネント情報 (BOM) に NSX-T 用 vRealize Log Insight Content Pack の最新バージョンが含まれていない

    BOM に NSX-T 用の最新の vRealize Log Insight Content Pack が含まれていません。

    回避策:NSX-T 用の最新の vRealize Log Insight Content Pack をインストールします。

    1. Web ブラウザで、vRealize Log Insight のユーザー インターフェイスにログインします。
    2. 構成ドロップダウン メニュー アイコンをクリックし、[コンテンツ パック] を選択します。
    3. ナビゲータの [コンテンツ パック マーケットプレイス] で、[更新] をクリックします。
    4. [Log Insight コンテンツ パック マーケットプレイス] ページで、[NSX-T 用 vRealize Log Insight Content Pack] を選択し、[更新] をクリックします。
    5. [すべてのコンテンツ パックの更新] ダイアログで、[更新] をクリックします。
    6. [インストール済みコンテンツ パック] で「NSX-T – VMware」をクリックし、バージョン番号が更新されていることを確認します。

    注: コンテンツ パック マーケットプレイスには常に最新バージョンのコンテンツ パックが含まれます。 

  • SDDC Manager 仮想マシンの一部として含まれるバンドル転送ユーティリティが想定したとおりに動作しない

    VMware Cloud Foundation システムでインターネットに接続できない場合は、バンドル転送ユーティリティを使用して手動でバンドルをダウンロードできます。SDDC Manager 仮想マシンには、バージョン 1696170 のユーティリティが含まれています。このバージョンのユーティリティでは、製品バージョン(-p または --productVersion)を指定すると、バンドルのダウンロード/リスト表示に失敗します。

    回避策:MyVMware から、バージョン 17209083 のバンドル転送ユーティリティとスキップレベル アップグレード ツールをダウンロードします。

  • [Microsoft CA の構成] ページの [ユーザー名]、[パスワード]、および [テンプレート名] フィールドに特殊文字を使用できない

    [Microsoft CA の構成] ページの [ユーザー名]、[パスワード]、または[テンプレート名] フィールドに次の特殊文字が使用されている場合、構成を保存できません。

    • アンパサンド (&)
    • 一重引用符 (')
    • 二重引用符 (")
    • より小さい (<)
    • より大きい (>)
    • タブ 

    回避策:特殊文字を削除し、構成を保存します。

  • SDDC Manager で CEIP を無効にしても、vRealize Operations および vRealize Suite Lifecycle Manager で CEIP は無効にならない  

    SDDC Manager ダッシュボードで CEIP を無効にしても、vRealize Operations および vRealize Suite Lifecycle Manager でデータ収集が無効になりません。これは、vRealize Suite 8.x での API の廃止によるものです。

    回避策:vRealize Operations および vRealize Suite Lifecycle Manager で CEIP を手動で無効にします。詳細については、VMware vRealize Automation のドキュメントおよび VMware vRealize Suite Lifecycle Manager のドキュメントを参照してください。

アップグレードに関する既知の問題
  • クラスタ レベルの ESXi アップグレードが失敗する

    アップグレード中のクラスタ レベルの選択では、クラスタの健全性ステータスが考慮されず、クラスタのステータスが [使用可能] と表示されることがあります。障害のあるクラスタを選択すると、アップグレードは失敗します。

    回避策:常に更新の事前チェックを実行し、クラスタの健全性ステータスを確認します。アップグレード前に問題を解決してください。

  • vLCM が有効なワークロード ドメインの ESXi アップグレード中にホストをスキップすると、アップグレードに失敗することがある

    既知の vSphere の問題により、ホストがスキップされたときに ESXi アップグレードが「ConstraintValidationException」エラーで失敗することがあります。

    回避策:エラーの原因についての詳細は、vSphere Client とそのログを確認してください。問題を解決して、アップグレードを再試行してください。

  • 構成エラーのアップグレード バンドルの適用に失敗する

    アップグレード中の VMware Cloud Foundation 環境に、失敗したワークロード ドメインまたは部分的に展開されたワークロード ドメインが含まれている場合、構成エラー バンドルの適用に失敗します。

    回避策:

    • アップグレードの事前チェックを実行して、問題を解決します。
    • 部分的に展開されたワークロード ドメインを削除します。
    • 構成エラー バンドルを再度適用します。
  • VMware Cloud Foundation 4.1 にアップグレードすると、vSphere Cluster Services (vCLS) エージェント仮想マシンのいずれかがローカル ストレージに配置される

    vSphere Cluster Services (vCLS) は vSphere 7.0 Update 1 の新機能であり、vCenter Server が利用できなくなった場合でも、クラスタ サービスを引き続き利用できます。vCLS は 3 台の vCLS エージェント仮想マシンを展開して、クラスタ サービスの健全性を維持します。VMware Cloud Foundation 4.1 にアップグレードすると、vCLS 仮想マシンの 1 つが共有ストレージではなくローカル ストレージに配置されることがあります。これにより、仮想マシンが格納されている ESXi ホストを削除した場合に問題が生じる可能性があります。

    回避策:クラスタの vCLS を無効にしてから再度有効にして、すべての vCLS エージェント仮想マシンを共有ストレージに展開します。

    1. 環境内の各クラスタの vCLS エージェント仮想マシンの配置を確認します。
      1. vSphere Client で、[メニュー] > [仮想マシンおよびテンプレート] を選択します。
      2. [vCLS] フォルダを展開します。
      3. 最初の vCLS エージェント仮想マシンを選択し、[サマリ] タブをクリックします。
      4. [関連オブジェクト] セクションで、ストレージについてリストされているデータストアを確認します。これは vSAN データストアである必要があります。vCLS エージェント仮想マシンがローカル ストレージにある場合は、クラスタの vCLS を無効にしてから再度有効にする必要があります。
      5. すべての vCLS エージェント仮想マシンに対して、これらの手順を繰り返します。
    2. ローカル ストレージ上に vCLS エージェント仮想マシンがあるクラスタについては、vCLS を無効にします。
      1. vSphere Client で、[メニュー] > [ホストおよびクラスタ] をクリックします。
      2. ローカル ストレージに vCLS エージェント仮想マシンがあるクラスタを選択します。
      3. Web ブラウザのアドレス バーで、クラスタの moref id を確認します。
        たとえば、URL が https://vcenter-1.vrack.vsphere.local/ui/app/cluster;nav=h/urn:vmomi:ClusterComputeResource:domain-c8:503a0d38-442a-446f-b283-d3611bf035fb/summary と表示されている場合、moref id は domain-c8 です。
      4. クラスタを含んでいる vCenter Server を選択します。
      5. [構成] > [詳細設定] をクリックします。
      6. [設定の編集] をクリックします。
      7. config.vcls.clusters.<moref id>.enabled の値を false に変更して、[保存] をクリックします。
        config.vcls.clusters.<moref id>.enabled 設定が moref id に表示されない場合は、その名前を入力して、値に「false」と入力し、[追加] をクリックします。
      8. vCLS エージェント仮想マシンの電源がオフになり、削除されるまで数分待ちます。進行状況は、[最近のタスク] ペインで監視できます。
    3. クラスタで vCLS エージェント仮想マシンを共有ストレージに配置するには、vCLS を有効にします。
      1. クラスタを含む vCenter Server を選択し、[構成] > [詳細設定] をクリックします。
      2. [設定の編集] をクリックします。
      3. config.vcls.clusters.<moref id>.enabled の値を true に変更して、[保存] をクリックします。
      4. vCLS エージェント仮想マシンが展開され、電源がオンになるまで数分待ちます。進行状況は、[最近のタスク] ペインで監視できます。
    4. vCLS エージェント仮想マシンの配置を確認して、それらがすべて共有ストレージ上にあることを確認してます。
  • スキップレベル アップグレードと LCM サービスの再起動が失敗する

    VMware Engineering が提供するホット パッチを Cloud Foundation 4.0、4.0.0.1、または 4.0.1 に適用した場合、バージョンのエイリアスの問題が原因で次のタスクが失敗することがあります。

    • VMware Cloud Foundation 4.1 へのスキップレベル アップグレード
    • LCM サービスの再起動 (systemctl restart lcm)

    回避策:バージョンのエイリアスの問題を解決するには、VMware のサポートにお問い合わせください。

  • NSX-T トランスポート ノードの事前チェック ステージでエラーが発生するため、管理ドメインまたはワークロード ドメインの NSX-T Data Center を vSAN プリンシパル ストレージで更新できない

    SDDC Manager で、NSX-T Data Center を更新する前にアップグレードの事前チェックを実行すると、NSX-T トランスポート ノードの検証結果に次のエラーが表示されます。

    「No coredump target has been configured.Host core dumps cannot be saved.:System logs on host sfo01-m01-esx04.sfo.rainpole.io are stored on non-persistent storage.Consult product documentation to configure a syslog server or a scratch partition.」

    アップグレードの事前チェックの結果にエラーが発生するため、ドメイン内の NSX-T Data Center インスタンスの更新を続行できません。VMware Validated Design は、管理ドメインのプリンシパル ストレージとして vSAN をサポートしています。ただし、vSAN データストアはスクラッチ パーティションをサポートしていません。VMware のナレッジベースの記事 KB2074026 を参照してください。

    回避策:後続の NSX-T Data Center の更新の事前チェック検証を無効にします。

    1. Secure Shell (SSH) クライアントを使用して、SDDC Manager に vcf としてログインします。
    2. Application-prod.properties ファイルを編集用に開きます。

      vi /opt/vmware/vcf/lcm/lcm-app/conf/application-prod.properties

    3. 次のプロパティを追加し、ファイルを保存します。

      lcm.nsxt.suppress.prechecks=true

    4. ライフサイクル管理サービスを再起動します。

      systemctl restart lcm

    5. SDDC Manager ユーザー インターフェイスにログインし、NSX-T Data Center の更新を続けます。
  • NSX-T のアップグレードが、NSX T TRANSPORT NODE POSTCHECK STAGE のステップで失敗する場合がある

    NSX-T のアップグレードが NSX T TRANSPORT NODE POSTCHECK STAGE より先に進まない場合があります。

    回避策:VMware のサポートにお問い合わせください。

  • vRSLCM での vRealize Log Insight クラスタのアップグレード タスクでアップグレードにかかる時間が正しく表示されない

    vRealize Log Insight クラスタのアップグレードには通常 30 分ほどかかりますが、タスク情報にアップグレード時間が誤って 1 秒と表示されます。

    回避策:なし。

  • バンドル転送ユーティリティ コマンドが誤ったバンドル タイプを取得する

    バンドル転送ユーティリティ コマンドを実行してインストール バンドルを取得すると、インストールおよび構成エラー バンドルが結果に含まれます。

    回避策:バンドル コンポーネントを確認して、バンドル タイプを検証します。

  • 管理プレーン API を使用して L3 転送モードを設定した場合、NSX-T を 3.1 にアップグレードした後、ポリシーによって管理プレーンの変更がデフォルト モード IPV4_ONLY で上書きされ、IPv6 接続が中断される

    L3 転送モードの設定は、NSX-T 3.0.0 リリースのポリシーで導入されました。この問題は、NSX-T 3.0.1 および 3.0.2 から NSX-T 3.1.0 へのアップグレードに影響します。NSX-T 2.5.x から NSX-T 3.1.0 および NSX-T 3.0.0 から NSX-T 3.1.0 へのアップグレードは影響を受けません。データ パスで IPv6 転送が無効になり、IPv6 接続が失われます。

    回避策:NSX-T 3.0.1 または 3.0.2 から NSX-T 3.1.0 にアップグレードする前に、ポリシーと管理プレーンの L3 転送モードの値が同じであることを確認します。異なる場合は、ポリシー API を使用してモードを変更します。 

  • ワークロード ドメインの [アップグレード/パッチ] タブでのバンドルの可用性表示に時間がかかる

    ワークロード ドメインの [アップグレード/パッチ] タブに移動するときに、バンドルが表示されるのに時間がかかります。

    回避策:LCM サービスを再起動します (systemctl restart lcm)。

  • ワークロード管理のアップグレードに失敗する

    ワークロード管理は、NSX-T、vCenter Server、ESXi がアップグレードされた後にのみアップグレードできます。これらのコンポーネントをアップグレードする前に、ワークロード管理をアップグレードすると、アップグレードは失敗します。 

    回避策:VMware のサポートにお問い合わせください。

  • vRealize のアップグレード ステージで vRealize Automation のアップグレードが失敗する 

    VREALIZE UPGRADE ステージで vRealize Automation のアップグレードが失敗し、次のエラーが表示されます。「Verify you can log and perform REST API calls to the vRealize Suite Lifecycle Manager appliance at 192.168.11.20.Check for errors in the lcm log files located on SDDC Manager under /var/log/vmware/vcf/lcm/.Manually revert the vRealize Automation virtual machines to the snapshot with prefix vRa_LCM_Upgrade_Backup.Please retry the upgrade once the upgrade is available again.」

    回避策:

    1. vRealize Automation UI に移動し、アップグレードのステータスを確認します。
    2. アップグレード ステータスが失敗している場合は、アップグレードを再試行し、正常に完了するまで待機します。
    3. SDDC Manager の管理ドメインの [更新/パッチ] タブで再度アップグレードを実行します。
ブリングアップに関する既知の問題
  • Cloud Foundation Builder 仮想マシンが、15 分以上経過した後もロックされた状態のままになる

    VMware Imaging Appliance (VIA) は、ログインを 3 回失敗すると管理者ユーザーをロックアウトします。通常、15 分後にロックアウトがリセットされますが、基盤となる Cloud Foundation Builder 仮想マシンは自動的にリセットされません。

    回避策:Cloud Foundation Builder 仮想マシンの仮想マシン コンソールに root ユーザーとしてログインします。次のコマンドを使用して、管理者ユーザーのパスワードをリセットし、アカウントのロックを解除します。
    pam_tally2--user =<user>--reset

SDDC Manager に関する既知の問題
  • コンポーネントでの CSR 生成タスクがハングする

    CSR を生成すると、コンポーネントのリソースに問題があるため、タスクを完了できない場合があります。たとえば、NSX Manager の CSR を生成すると、NSX Manager ノードの問題によってタスクを完了できないことがあります。リソースが起動して実行中の状態になると、タスクを再試行することはできません。

    回避策:

    1. コンポーネントのユーザー インターフェイスにログインして、問題をトラブルシューティングして解決します。
    2. SSH を使用し、ユーザー名 vcf で SDDC Manager 仮想マシンにログインします。
    3. su」 と入力して root アカウントに切り替えます。
    4. 次のコマンドを実行します。
      systemctl restart operationsmanager
    5. CSR の生成を再試行します。
  • 健全性チェック用の SoS ユーティリティ オプションに情報がない

    ESXi サービス アカウントの制限により、次の健全性チェック オプションで一部の情報を使用できません。

    • --hardware-compatibility-report: ESXi ホストについての Devices and Driver の情報がありません。
    • --storage-health: ESXi ホストについての vSAN Health Status または Total no. of disks の情報がありません。

    回避策:なし。

  • [インベントリ] -> [ホスト] ページのホスト情報のロードに時間がかかるか、ロードされない

    多数のホストが未割り当ての場合、[インベントリ] -> [ホスト] ページにホスト情報が反映されるのに最長で 3 分ほどかかるか、次のメッセージが表示されることがあります。「Failed to load host details, Please retry or contact the service provider and provide the reference token」

    回避策:ホスト関連のすべてのタスクに VMware Cloud Foundation API を使用します。

  • ホスト検証 API /v1/hosts/validationsDescription の直後に API /v1/hosts/validations/commissions が使用されている場合、ホストのコミッショニングが失敗する場合がある

    ホスト検証 API /v1/hosts/validations/commissions をホスト検証 API /v1/hosts/validations の直後に実行すると、検証ワークフローがホストのコミッショニング ワークフローによって作成された一時的なトラストストアを削除する場合があります。これにより、ホストのコミッショニングが失敗する場合があります。

    回避策:ホストの検証後、少なくとも 1 分間待機してからホストのコミッショニング API を実行します。

ワークロード ドメインに関する既知の問題
  • ホストが別の VLAN にある場合にホストの追加に失敗する

    ホストが別の VLAN にある場合、ホストの追加操作が失敗することがあります。

    回避策:

    1. ホストを追加する前に、そのクラスタの VDS に新しいポート グループを追加します。
    2. 追加するホストの VLAN ID を使用して、新しいポートグループにタグを付けます。
    3. ホストを追加します。このワークフローが、「ホストの vmknic を dvs に移行」する処理で失敗します。
    4. vCenter Server で失敗したホストを見つけ、ホストの vmk0 を手順 1 で作成した新しいポート グループに移行します。
      詳細については、vSphere の製品ドキュメントのvSphere Distributed Switch への VMkernel アダプタの移行を参照してください。
    5. ホストの追加を再試行します。
       

    : 将来的にホストを削除するときは、他のホストで使用していないポートグループについても、手動で削除してください。

  • NSX-T ワークロード ドメインにパートナー サービスを展開するとエラーが表示される

    vSphere Update Manager (VUM) が有効になっているワークロード ドメインで、McAfee や Trend などのパートナー サービスを展開すると、「Configure NSX at cluster level to deploy Service VM」というエラーが表示されます。

    回避策:トランスポート ノード プロファイルをクラスタに添付し、パートナー サービスを展開します。サービスが展開されたら、トランスポート ノード プロファイルをクラスタから分離します。

  • 監視 ESXi バージョンがクラスタ内のホスト ESXi バージョンと一致しない場合、vSAN クラスタ パーティションが発生する可能性がある

    vSAN ストレッチ クラスタのワークフローでは、Witness(監視)ホストの ESXi バージョンはチェックされません。監視 ESXi バージョンがクラスタ内のホスト バージョンと一致しない場合、vSAN クラスタ パーティションが発生する可能性があります。

    回避策:

    1.vCenter Server の VUM 機能を使用して、一致する ESXi バージョンで Witness(監視)ホストを手動でアップグレードします。
    2.ESXi バージョンと一致する監視アプライアンスを交換またはデプロイします。

  • 監視 MTU が 9000 に設定されていない場合、vSAN パーティションと重大なアラートが生成される

    監視アプライアンスの監視スイッチの MTU が 9000 に設定されていない場合、vSAN ストレッチ クラスタ パーティションが発生する可能性があります。

    回避策:監視アプライアンスの監視スイッチの MTU を 9000 MTU に設定します。

  • VI ワークロード ドメインの作成または拡張操作が失敗する

    ESXi ホストの FQDN と、ホストのコミッショニング時に使用された FQDN の大文字と小文字に不一致がある場合、ワークロード ドメインの作成と拡張が失敗します。

    回避策:ESXi ホストには小文字の FQDN を設定する必要があり、小文字の FQDN を使用してコミッショニングする必要があります。

  • Dell Hardware Support Manager (OMIVV) で構成された vLCM が有効なワークロード ドメインにホストを追加すると失敗する

    vSphere Lifecycle Manager (vLCM) で有効になっているワークロード ドメインの vSphere クラスタにホストを追加しようとすると、タスクが失敗し、ドメイン マネージャ ログに「The host (host-name) is currently not managed by OMIVV.」というエラーが報告されます。ドメイン マネージャ ログは、SDDC Manager 仮想マシンの /var/log/vmware/vcf/domainmanager にあります。

    回避策:OMIVV のホスト インベントリを更新し、SDDC Manager のユーザー インターフェイスで [ホストの追加] タスクを再試行します。OMIVV のホスト インベントリの更新については、Dell のドキュメントを参照してください。

  • vSphere クラスタの追加またはワークロード ドメインへのホストの追加が失敗する

    特定の状況で、ワークロード ドメインにホストまたは vSphere クラスタを追加すると、[NSX-T トランスポート ノードの構成] または [トランスポート ノード コレクションの作成] サブタスクの作成に失敗します。

    回避策:

    1. NSX Manager 仮想マシンの SSH を有効にします。
    2. admin として NSX Manager 仮想マシンに SSH 接続し、root としてログインします。
    3. 各 NSX Manager 仮想マシンで次のコマンドを実行します。
      sysctl -w net.ipv4.tcp_en=0
    4. ワークロード ドメインの NSX Manager UI にログインします。
    5. [システム] > [ファブリック] > [ノード] > [ホスト トランスポート ノード] の順に移動します。
    6. [管理元] ドロップダウン メニューからワークロード ドメインの vCenter Server を選択します。
    7. vSphere クラスタを展開し、partial success 状態のトランスポート ノードに移動します。
    8. partial success ノードの横にあるチェックボックスを選択し [NSX の構成] をクリックします。
    9. [次へ] をクリックして、[適用] をクリックします。
    10. partial success ノードについて、手順 7~9 を繰り返します。

    すべてのホストの問題が解決されると、障害が発生したノードのトランスポート ノードの作成が開始されます。すべてのホストがトランスポート ノードとして正常に作成されたら、SDDC Manager のユーザー インターフェイスから、失敗した vSphere クラスタの追加またはホストの追加タスクを再試行します。

  • CEIP が有効になっていない場合、vSAN クラスタの vSAN パフォーマンス サービスが有効にならない

    VMware カスタマー エクスペリエンス向上プログラム (CEIP) を SDDC Manager で有効にしない場合、ワークロード ドメインを作成するとき、または vSphere クラスタをワークロード ドメインに追加するときに、vSAN クラスタに対して vSAN パフォーマンス サービスが有効になりません。CEIP が有効になっている場合は、vSAN Performance Service のデータが VMware に提供されます。また、このデータは、VMware のサポートによるトラブルシューティングや、事前対応型のクラウド監視サービスである VMware Skyline などの製品のために使用されます。CEIP によって収集されるデータの詳細については、カスタマー エクスペリエンス向上プログラム を参照してください。

    回避策:SDDC Manager で CEIP を有効にします。VMware Cloud Foundation のドキュメントを参照してください。CEIP を有効にすると、ワークロード ドメイン内の既存のクラスタで vSAN パフォーマンス サービスを有効にするスケジュール設定タスクが、3 時間ごとに実行されます。このサービスは、新しいワークロード ドメインおよびクラスタに対しても有効になります。vSAN パフォーマンス サービスを直ちに有効にするには、VMware vSphere のドキュメントを参照してください。

  • 32 台を超えるホストを含む vSAN クラスタの作成または拡張が失敗する

    デフォルトでは、vSAN クラスタは最大 32 台のホストに拡張できます。大規模クラスタのサポートが有効になっている場合、vSAN クラスタは最大 64 台のホストまで拡張できます。ただし、大規模クラスタのサポートが有効になっていても、作成または拡張タスクが [vSphere クラスタでの vSAN の有効化] サブタスクで失敗する場合があります。

    回避策:

    1. vSphere Client で、vSAN クラスタの大規模クラスタのサポートを有効にします。すでに有効になっている場合は、手順 2 に進みます。
      1. vSphere Client で vSAN クラスタを選択します。
      2. [構成] > [vSAN] > [詳細オプション] を選択します。
      3. 大規模クラスタのサポートを有効にします。
      4. [適用] をクリックします。
      5. [はい] をクリックします。
    2. vSAN 健全性チェックを実行して、再起動が必要なホストを確認します。
    3. ホストをメンテナンス モードにして、ホストを再起動します。

    大規模クラスタのサポートの詳細については、https://kb.vmware.com/kb/2110081 を参照してください。

  • サービス仮想マシン (SVM) が存在する場合、クラスタからのホストの削除、ワークロード ドメインからのクラスタの削除、またはワークロード ドメインの削除に失敗する

    NSX-T Data Center を介してクラスタにエンドポイント保護サービス(ゲスト イントロスペクションなど)を展開した場合、クラスタからホストを削除したり、クラスタを削除したり、クラスタを含むワークロード ドメインを削除したりすると、ESXi ホストでのメンテナンス モードへの切り替えサブタスクに失敗します。

    回避策:

    • ホスト削除の場合:ホストからサービス仮想マシンを削除して、操作をやり直してください。
    • クラスタ削除の場合:クラスタのサービス デプロイを削除してから、操作をやり直してください。
    • ワークロード ドメイン削除の場合:ワークロード ドメイン内のすべてのクラスタのサービス デプロイを削除して、操作を再試行してください。
  • VI ワークロード ドメインにクラスタを追加すると、vCenter Server によって NFS データストア名が上書きされる

    NFS サーバの IP アドレスが同じで、別の NFS データストア名を持つ NFS データストアを、ワークロード ドメイン内にすでに存在する NFS データストアとして追加した場合、vCenter Server は既存のデータストア名を新しいデータストアに適用します。

    回避策:別のデータストア名を持つ NFS データストアを追加する場合は、別の NFS サーバの IP アドレスを使用する必要があります。

  • vSphere Client で名前が変更されたクラスタを削除しても、クラスタのトランスポート ノード プロファイルまたはアップリンク プロファイルが削除されない

    vSphere Client を使用してクラスタの名前を変更し、そのクラスタを SDDC Manager から削除しても、クラスタに関連付けられたトランスポート ノード プロファイルとアップリンク プロファイルは削除されません。

    回避策:NSX Manager からトランスポート ノード プロファイルとアップリンク プロファイルを手動で削除し、クラスタの削除を再試行します。

    1. NSX Manager UI にログインします。
    2. クラスタの古い名前に関連付けられているアップリンク プロファイルを特定して削除します。
      1. [システム] > [ファブリック] > [プロファイル] > [アップリンク プロファイル] の順に移動して、削除されたクラスタのアップリンク プロファイルを特定します。
        アップリンク プロファイル名は、次のパターンに従います。<vcenter host name>-<old-cluster-name>.
        たとえば、vCenter Server の FQDN が vcenter server でクラスタの古い名前が nsxt-datacenter の場合、アップリンク プロファイル名は vcenter-vsan-nsxt-cluster になります。
      2. アップリンク プロファイルを選択し、[削除] をクリックします。
    3. クラスタの古い名前に関連付けられているトランスポート ノード プロファイルを特定して削除します。
      1. [システム] > [ファブリック] > [プロファイル] > [トランスポート ノード プロファイル] の順に移動して、削除されたクラスタのトランスポート ノード プロファイルを特定します。トランスポート ノード プロファイル名は、アップリンク プロファイル名と同じパターンに従います。
      2. トランスポート ノード プロファイルを選択し、[削除] をクリックします。
    4. SDDC Manager で、クラスタの削除を再試行してください。
  • vLCM イメージを使用するクラスタでホストの追加に失敗する場合がある

    vLCM イメージを使用してクラスタにホストを追加すると、次のエラーで失敗することがあります。
    「Unable to create transport node collection.Transport Node Collection is failed with state FAILED_TO_REALIZEWorkflow」

    回避策:ホストの追加ワークフローを再試行します。

マルチインスタンス管理に関する既知の問題
  • [複数インスタンスの管理] ダッシュボードから離れると、フェデレーションの作成情報が表示されない

    フェデレーションの作成の進行状況は、[複数インスタンスの管理] ダッシュボードに表示されます。別の画面に移動して、[複数インスタンスの管理] ダッシュボードに戻ると、進行中のメッセージは表示されません。代わりに、フェデレーションが作成されるまで、Cloud Foundation インスタンスのない空のマップが表示されます。

    回避策:タスクが完了するまで、[複数インスタンスの管理] ダッシュボードを表示したままにします。移動した場合は、約 20 分待ってから、操作が完了するまでの時間を指定してダッシュボードに戻ります。

  • [複数インスタンスの管理] ダッシュボードの操作が失敗する

    コントローラがフェデレーションに参加するか、フェデレーションから離れると、フェデレーション内のすべてのコントローラで Kafka が再起動されます。フェデレーションが安定するまでに最大 20 分かかる場合があります。この間にダッシュボードで実行された操作は失敗する可能性があります。

    回避策:操作を再試行します。

  • 参加操作が失敗する

    コントローラの SDDC Manager に深さが 1 より大きいパブリック証明書がある(つまり、中間証明書がある)場合、参加操作が失敗することがあります。

    回避策:コントローラの SDDC Manager の中間証明書を信頼してください。KB 80986を参照してください。

API に関する既知の問題
  • ストレッチ クラスタの操作が失敗する

    ストレッチしているクラスタに、オペレーティング システムがインストールされた電源オン状態の仮想マシンが含まれていない場合、「ゼロ仮想マシンのクラスタを検証」タスクで操作が失敗します。

    回避策:クラスタをストレッチする前に、クラスタにオペレーティング システムがインストールされた電源オン状態の仮想マシンがあることを確認します。

ネットワークに関する既知の問題
    vRealize Suite に関する既知の問題
    • vRealize Suite Lifecycle Manager に vRealize Suite 製品を展開すると、一部のインフラストラクチャの詳細がロードされないことがある

      vRealize Suite Lifecycle Manager に vRealize Suite 製品を展開すると、インフラストラクチャの詳細がロードされないことがあります。これは、vRealize Suite Lifecycle Manager で vCenter Server のデータ収集要求が失敗したことを示しています。これにより、vRealize Suite Lifecycle Manager が vCenter Server インベントリの現在の状態を検証することができなくなります。

      回避策:失敗した vCenter Server データ収集要求を正常に成功するまで再試行してから、vRealize Suite 製品の展開を再度実行します。

      1. vRealize Suite Lifecycle Manager で、[ライフサイクル操作] > [データセンター] をクリックします。
      2. 管理 vCenter Server の更新アイコンをクリックして、データ収集を更新します。
      3. [要求] をクリックし、要求が成功するまで待ちます。
      4. 製品の展開を再試行します。
    • DNS または NTP サーバの構成を更新しても vRealize Automation に更新が適用されない

      Cloud Foundation API を使用して DNS サーバまたは NTP サーバを更新しても、vRealize Suite Lifecycle Manager のバグが原因で、vRealize Automation に更新が適用されません。

      回避策:vRealize Automation の DNS または NTP サーバを手動で更新します。

      vRealize Automation の DNS サーバの更新

      1. root 認証情報を使用して、最初の vRealize Automation ノードに SSH 接続します。
      2. 次のコマンドを使用して、現在の DNS サーバを削除します。
        sed '/nameserver.*/d' -i /etc/resolv.conf
      3. 次のコマンドを使用して、新しい DNS サーバの IP アドレスを追加します。
        echo nameserver [DNS server IP] >> /etc/resolv.conf
      4. 複数の DNS サーバがある場合は、このコマンドを繰り返します。
      5. 次のコマンドを使用して、更新を確認します。
        cat /etc/resolv.conf
      6. 各 vRealize Automation ノードについて、これらの手順を繰り返します。


      vRealize Automation の NTP サーバの更新

      1. root 認証情報を使用して、最初の vRealize Automation ノードに SSH 接続します。
      2. 次のコマンドを実行して、新しい NTP サーバを指定します。
        vracli ntp systemd --set [NTP server IP]
        複数の NTP サーバを追加する場合は、次のコマンドを実行します。
        vracli ntp systemd --set [NTP server 1 IP,NTP server 2 IP]
      3. 次のコマンドを使用して、更新を確認します。
        vracli ntp show-config
      4. 次のコマンドを使用して、すべての vRealize Automation ノードに更新を適用します。
        vracli ntp apply
      5. 各 vRealize Automation ノード上で次のコマンドを実行して、更新を確認します。
        vracli ntp show-config
    • vRealize Log Insight のワークロード ドメインへの接続が、「vSphere のログ収集の有効化」ステップで失敗する

      vRealize Log Insight をワークロード ドメインに接続するときに、vSphere のログ収集の有効化ステップで失敗します。SDDC Manager の [最近のタスク] ウィジェットで接続ワークフロー タスクを展開すると、次のエラーが表示されます。
      「Cannot configure vCenter in vRealize Log Insight
      Failed post request in vRLI」

      回避策:vRLI 仮想マシンを再起動します。

      1. 管理 vCenter Server にログインします。
      2. VMware Host Client インベントリで [仮想マシン] をクリックします。
      3. vRealize Log Insight 仮想マシンを選択します。
      4. 仮想マシンを右クリックし、[ゲスト OS] -> [再起動] を選択します。
      5. 仮想マシンがパワーオンされた後、それぞれの vRealize Log Insight 仮想マシンに対して手順 3 と 4 を繰り返します。
      6. vRealize Log Insight UI にアクセスできることを検証します。
      7. SDDC Manager の [最近のタスク] パネルで、失敗したタスクを選択し、[タスクの再起動] をクリックします。
    • vRealize Suite 製品の展開を実行すると、「Failed to get Environment ID by given Host Name」というエラーと共に失敗する

      vRealize Suite Lifecycle Manager で複数の vRealize Suite 製品を同時に展開すると、SDDC Manager による製品の登録に失敗する場合があります。

      回避策:vRealize Suite 製品を一度に 1 製品ずつ展開します。 

    check-circle-line exclamation-circle-line close-line
    Scroll to top icon