VMware Cloud Foundation 3.5 リリースノート

VMware Cloud Foundation 3.5 |2018 年 12 月 13 日 |ビルド 11215871

VMware Cloud Foundation は、VMware vSphere、vSAN、NSX、および vRealize Suite コンポーネント (オプション）を集約し、スタックにネイティブに組み込んだ統合 SDDC プラットフォームです。プライベートクラウドおよびパブリッククラウドに、エンタープライズ対応のクラウドインフラストラクチャを提供します。Cloud Foundation 3.5 リリースは、SDDC の自動化、VMware SDDC スタック、およびパートナーネットワークに拡張していきます。

注： VMware Cloud Foundation 3.5 は、新規にインストールするか、Cloud Foundation 3.0.1.1 からアップグレードする必要があります。詳細については、下記のインストールとアップグレードに関する情報を参照してください。

リリースノートの概要

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

新機能
更新された Cloud Foundation のコンポーネント情報 (BOM)
VMware のソフトウェアエディションのライセンス情報
サポート対象のハードウェア
ドキュメント
Cloud Foundation ユーザーインターフェイスの Web ブラウザとの互換性と画面解像度
インストールとアップグレードに関する情報
解決した問題
更新された既知の問題

新機能

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

NSX-T 自動化のサポート
NSX-T を使用したワークロードドメインの展開が可能になります。
注： NSX-T は、統合アーキテクチャでサポートされていません。
NFS ストレージ自動化のサポート
ユーザーが NFS ベースのワークロードドメインを利用して、所有している NFS ストレージを活用できるようにします。
コンポーザブルインフラストラクチャとのより緊密な統合
SDDC Manager は現在、最初の認定パートナーとして HPE Synergy を使用して、Redfish Composability API と統合されています。
一括でのホストのコミッショニングおよびデコミッショニング
複数のホストを同時にコミッショニングおよびデコミッショニングできるようになりました。
パスワード管理のためのインターフェイスの向上
パスワードローテーションおよび手動でのパスワード更新を管理するための新しい制御方法を提供します。
更新された証明書の置換ワークフロー
この向上により、エラーメッセージがより明確になり、エラーの発生も減少しました。

更新された Cloud Foundation のコンポーネント情報 (BOM)

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

重要： VMware Cloud Foundation は、適用対象外のアップグレードバンドルについてもアップグレードマニフェストをダウンロードします。たとえば、VMware Cloud Foundation 3.x では、関連する VMware Cloud Foundation 3.x のマニフェストに加えて、VMware Cloud Foundation 2.x の更新マニフェストも表示される場合があります。詳細については、ナレッジベースの記事 KB65045 「VMware Cloud Foundation downloads upgrade manifests for non-applicable upgrade bundles」を参照してください。

VMware Cloud Foundation 3.5 は、vSphere 6.7 ベースの BOM を使用した Cloud Foundation の最初のリリースです。

ソフトウェアコンポーネント	バージョン	日付	ビルド番号
Cloud Foundation Builder 仮想マシン	3.5	2018 年 12 月 13 日	11215871
SDDC Manager	3.5	2018 年 12 月 13 日	11215871
VMware vCenter Server （vCenter Server Appliance）	6.7 U1	2018 年 10 月 12 日	10244745
VMware Platform Services Controller	6.7 U1	2018 年 10 月 16 日	10244745
VMware vSphere (ESXi)	6.7 EP5	2018 年 11 月 9 日	10764712
VMware vSAN	6.7 EP5	2018 年 11 月 9 日	10764712
VMware NSX Data Center for vSphere	6.4.4	2018 年 12 月 8 日	11197766
VMware NSX-T Data Center	2.3	2018 年 9 月 25 日	10085361
VMware vRealize Suite Lifecycle Manager	2.0	2018 年 9 月 20 日	10150522
VMware vRealize Automation	7.5	2018 年 9 月 20 日	10053539
VMware vRealize Log Insight	4.7	2018 年 10 月 4 日	9983377
vRealize Log Insight Content Pack for NSX for vSphere	3.8	該当なし	該当なし
New: vRealize Log Insight Content Pack for Linux	1.0	該当なし	該当なし
VMware vRealize Operations	7.0	2018 年 9 月 24 日	10098133

VMware Software Edition のライセンス情報

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

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

VMware ESXi
VMware vSAN
VMware NSX Data Center for vSphere

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

VMware vCenter Server
注： Cloud Foundation システムに展開されているすべての vCenter Server に必要なライセンスは 1 つのみです。
VMware vRealize Automation
VMware vRealize Operations
VMware vRealize Log Insight およびコンテンツパック
注： Cloud Foundation では、完全な vRealize Log Insight ライセンスを購入しなくても、vRealize Log Insight を管理ドメイン用に限定的に使用することが許可されます。

購入したライセンスで使用可能な VMware ソフトウェアのエディションについては、上記の Cloud Foundation のコンポーネント情報 (BOM) セクションを参照してください。

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

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

Cloud Foundation の vSan ReadyNodes の詳細については、VMware 互換性ガイド (VCG) の vSAN 情報か、『VMware Cloud Foundation のプランニングおよび準備ガイド』の「ハードウェア要件」セクションを参照してください。

ドキュメント

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

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

VMware vSphere 6.5 製品ドキュメントには、ESXi および vCenter Server に関するドキュメントも含まれています。
VMware vSAN 製品ドキュメント
VMware NSX Data Center for vSphere 製品ドキュメント
VMware NSX-T Data Center 製品ドキュメント
VMware vRealize Log Insight 製品ドキュメント
VMware vRealize Automation 製品ドキュメント

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

Cloud Foundation の Web ベースのインターフェイスは、次のブラウザをサポートしています。

Google Chrome：バージョン 70. x または 69. x
Internet Explorer：バージョン 11
Mozilla Firefox：バージョン 63. x または 62. x

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

1024 × 768 ピクセル（標準）
1366 × 768 ピクセル
1280 × 1024 ピクセル
1680 × 1050 ピクセル

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

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

Cloud Foundation 3.5 を新しいリリースとしてインストールすることや、Cloud Foundation 3.0.1.1 からアップグレードすることができます。

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

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

フェーズ 1：環境の準備

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

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

すべてのサーバを ESXi 6.7 U1 でイメージ化し、ESXi 6.7 EP5（ビルド10764712）にアップデートします。詳細についてはナレッジベースの記事 KB58715「Virtual Machines running on VMware vSAN 6.6 and later report guest data consistency concerns following a disk extend operation」をご覧ください。

フェーズ 3：Cloud Foundation 3.5 のインストール

次のユーザーマニュアルを参照してください。

VMware Cloud Foundation アーキテクチャおよび導入ガイドでは、VMware Cloud Foundation 製品とアーキテクチャの概要について説明しています。このドキュメントでは、Cloud Foundation の導入プロセスについても説明します。
VMware Cloud Foundation 運用および管理ガイドでは、システムの仮想インフラストラクチャの管理、ユーザーの管理、サービスの設定と展開、およびシステムのアップグレードと監視を含む、VMware Cloud Foundation のシステム管理に関する情報を提供します。

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

Cloud Foundation 3.5 は新規にインストールするか、Cloud Foundation 3.0.1.1 からアップグレードすることができます。

注：

Cloud Foundation 3.5 のアップグレードパスは、3.0 > 3.0.1 > 3.0.1.1 > 3.5 になります。
Cloud Foundation 3.5 にアップグレードするには、SDDC Manager バージョン 3.0.1 と ESXi 6.5 EP 11 が必要です。
ESXi 6.5 EP 8 から EP 11 へ直接アップグレードする場合は、ナレッジベースの記事 KB60887「How to perform a skip-level ESXi upgrade from VMware Cloud Foundation version 3.0.1.0 to version 3.5.0 directly」を参照してください。
VMware のパートナー企業から提供された、カスタムの ESXi 6.5 ISO を使用する Cloud Foundation 3.0 または 3.0.1 をインストールしている場合は、ナレッジベースの記事 KB65047「How to upgrade ESXi hosts in VMware Cloud Foundation 3.5 with a vendor-specific ISO image」を参照してください。

アップグレードの準備

アップグレードの前に、次のタスクを実行します。

SDDC Manager ダッシュボードまたはバンドル転送ユーティリティを使用して、LCM のアップグレードバンドルをダウンロードします。『VMware Cloud Foundation 運用および管理ガイド』の「Cloud Foundation のパッチ適用とアップグレード」を参照してください。
アップグレードスケジュールを設定する前に、次のコマンドを使用して SDDC Manager のダッシュボードからアップグレード前チェックユーティリティを実行します。
[Inventory（インベントリ）] > [Workload Domains（ワークロードドメイン）] > [<Workload Domain Name（ワークロードドメイン名）>] > [Update/Patches（アップグレード/パッチ適用）] タブに移動して、アップグレード前チェック画面にアクセスします。

アップグレード後

アップグレード後、次のタスクを実行します。

vRealize Log Insight をバージョン 4.7 にアップグレードします。ナレッジベースの記事 KB60278「How to upgrade vRealize Log Insight in VMware Cloud Foundation 3.5」を参照してください。
vRealize Automation を以前のバージョンの 3.0.x を使用して展開している場合は、アップグレードの一部として vRealize Suite Lifecycle Manager 2.0 がインストールされていることを確認してから、VMware のサポートに連絡して vRealize Automation をバージョン 7.5 にアップグレードしてください。
vRealize Operations を以前のバージョンの 3.0.x を使用して展開している場合は、アップグレードの一部として vRealize Suite Lifecycle Manager 2.0 がインストールされていることを確認してから、VMware のサポートに連絡して vRealize Operations をバージョン 7.0 にアップグレードしてください。
vRealize Automation と vRealize Operations の両方を以前のバージョン 3.0.x を使用して展開している場合は、アップグレードの一部として vRealize Suite Lifecycle Manager 2.0 がインストールされていることを確認してから、VMware のサポートに連絡して両方ともアップグレードしてください。

解決した問題

アップデート中、ユーザーによる証明書の置き換えを防ぐための警告が表示されない
SDDC Manager ダッシュボードでは、製品のアップデート中にユーザーによる証明書の置き換えを防止するメッセージが表示されません。これはサポートされている動作ではありません。

今回のリリース (3.5) で、この問題は修正されました。
管理者ユーザーがブリングアップサービスログにアクセスできない
管理者ユーザーには Cloud Foundation Builder 仮想マシンへのアクセス権限がありますが、ブリングアップログにアクセスできるのは root ユーザーのみです。

今回のリリース (3.5) で、この問題は修正されました。
SoS ログ収集によって AssertionError 「execute_api_and_save_output」が返される
VI ワークロードドメインの作成または vRealize Suite LCM ののアップデート前に、ユーザーが SoS ユーティリティスイートを起動すると、システムは AssertionError メッセージを返します。ただし、このエラーは、ログ収集を伴う SoS 機能や健全性チェックなどの他の SoS の処理に影響しません。

今回のリリース (3.5) で、この問題は修正されました。
ワークロードドメインに接続した後、ユーザーは vRealize Automation で vCenter Server 証明書を手動で受け入れる必要がある
vRealize Automation を展開して Cloud Foundation のワークロードドメインに接続した後、ユーザーは vRealize Automation インターフェイスに切り替えて、セキュリティ証明書を手動で受け入れる必要があります。

今回のリリース (3.5) で、この問題は修正されました。
vSAN ディスクの検証でキャッシュ層が返される
vSAN ディスクの検証中に、システムから"Host 'X' does not contain the minimum VSAN SDD cache disk required.VSAN cache their not within 200GB +-13.0 percent specification - FAIL" というエラーが返されます。これは、検証プロセスによって vSAN キャパシティ層のサイズに対する適切なキャッシュ層のキャパシティ要件が正しく識別されないことが原因である可能性があります。

今回のリリース (3.5) で、この問題は修正されました。
SDDC Manager の VMCA 証明書のインストール中、ブリングアップが失敗する
SDDC Manager の VMCA 証明書のインストールタスクで、ブリングアップが失敗することがあります。

今回のリリース (3.5) で、この問題は修正されました。
事前チェックで Java リソースアクセス例外が返される
事前チェックの操作で、次の Java エラーが返されます。org.springframework.web.client.ResourceAccessException: I/O error on POST request for "https://nsxManager.qr13.vcf.local/api/1.0/appliance-management/backuprestore/backup".この問題は、PSC、vCenter Server、NSX、および vRealize Automation コンポーネントの証明書を置き換えた後に確認されており、SDDC Manager 仮想アプライアンスと NSX Manager ノード間の接続が失われたことが原因である可能性があります。

今回のリリース (3.5) で、この問題は修正されました。
アップデート後の設定：ユーザーが管理ポートグループのアダプタのチーミングポリシーを再設定する必要がある
VMware Cloud Foundation 3.0 から 3.0.1 へのアップデートでは、チーミングポリシーがデフォルトで「送信元の仮想ポートに基づいたルート」設定になります。管理、vMotion、および vSAN ポートグループのポリシーは「物理 NIC ロードに基づいたルート」に設定する必要があります。

今回のリリース (3.5) で、この問題は修正されました。
アップデート後の設定：ユーザーは管理クラスタの高可用性を再度設定する必要がある
VMware Cloud Foundation 3.0 から 3.0.1 へのアップデートでは、管理クラスタの高可用性設定は「仮想マシンおよびアプリケーションの監視（VM and Application Monitoring）」がデフォルトで有効になっています。管理クラスタの高可用性設定を [VM Monitoring Only（仮想マシンの監視のみ）] に戻しておく必要があります。

今回のリリース (3.5) で、この問題は修正されました。
サードパーティのファイル転送ユーティリティを使用して SDDC Manager 仮想マシンからログをダウンロードできない
サードパーティのファイル転送ユーティリティ（WinSCP など）は、安全にファイルをダウンロードするために使用される一般的なツールで、その多くが Cloud Foundation でサポートされます。この権限エラーに対しては、簡単な回避策があります。

今回のリリース (3.5) で、この問題は修正されました。

既知の問題

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

ブリングアップに関する既知の問題
アップグレードに関する既知の問題
vRealize の統合に関する既知の問題
ネットワークに関する既知の問題
SDDC Manager に関する既知の問題
ワークロードドメインに関する既知の問題
セキュリティ運用に関する既知の問題
Lifecycle Manager に関する既知の問題
サービスプロバイダに影響する既知の問題
サポートおよび保守性 (SoS) ユーティリティに関する既知の問題

ブリングアップに関する既知の問題

New：導入ウィザードのヘルプアイコンをクリックすると、古いリリースのヘルプが表示される
導入ウィザードのヘルプアイコンは、古いバージョンの製品ヘルプにリンクしています。

回避策：Cloud Foundation の展開に関するヘルプトピックを開くには、次の手順を実行します。

1.ブラウザで、docs.vmware.com に移動します。

2.[すべての製品] をクリックし、[VMware Cloud Foundation] をクリックします。

3.[VMware Cloud Foundation アーキテクチャおよび展開ガイド] をクリックします。

4.左側のナビゲーションペインで、[Cloud Foundation の展開] をクリックします。
「[Admin/Root] password does not meet standards（[Admin/Root] パスワードが基準に適合しません）」というメッセージが表示されて Cloud Foundation Builder が起動に失敗する
Cloud Foundation Builder の管理者/root パスワードを設定するときに、フォーマットの制限の検証が行われません。このため、ユーザーは制限に準拠していないパスワードを作成する可能性があります。その結果、Cloud Foundation Builder の起動に失敗します。

回避策：Cloud Foundation Builder の設定時に、パスワードが次の制限事項を満たしていることを確認します。
- 最小 8 文字。
- 大文字と小文字の両方が含まれている
- 数字と特殊文字が含まれている
- 通常の辞書に載っている一般的な単語を含めない
vRealize Log Insight ノードの TLS 1.0 を無効にするタスクでブリングアッププロセスが失敗する
vRealize Log Insight ノードの TLS 1.0 を無効にするタスクで、Connect to 10.0.0.17:9543 [/10.0.0.17] failed: Connection refused (Connection refused) のエラーと共にブリングアップに失敗します。この問題は、vRealize Log Insight ノードを再起動した後に、低速の環境で確認されています。ノードが正常に起動せず、API にアクセスできない
回避策：この問題を回避するには、次の手順を実行します。 Cloud Foundation Builder 仮想マシンで失敗したブリングアップを再実行して、ブリングアップログを開きます。これにより、失敗したブリングアップタスクが再試行されますが、これは最初の試行で失敗する可能性があります。ログには、Log Insight ノードへの接続に失敗したことが表示されます。ブリングアップの実行中は、SSH を使用して、ブリングアップログに失敗として示されている Log Insight ノードにログインします。次のコマンドを実行して、接続の問題を特定します。 loginsight-node-2:~ # service loginsight status デーモンが実行されていないことを確認します。次のコマンドを実行します。 loginsight-node-2:~ # mv /storage/core/loginsight/cidata/cassandra/data/system ~/cassandra_keyspace_files Log Insight ノードを再起動します。実行されていることを確認します。 loginsight-node-2:~ # uptime 18:25pm up 0:02, 1 user, load average: 3.16, 1.07, 0.39 loginsight-node-2:~ # service loginsight status Log Insight が実行されています。わずか数分で、ブリングアッププロセスが Log Insight ノードへの接続を確立し、処理が続行されます。
vSAN SSD キャパシティディスクが使用不可としてマーキングされるブリングアップ前の監査検証で、ディスクサイズが推奨されるの最小容量の 1 TB より小さいと、エラーが表示されます。回避策：ユーザーには、次の 2 つのオプションが提供されます。エラーを無視する。このオプションを選択しても、ユーザーはワークフローを完了することができます。ユーザーは [Acknowledge（了承）] をクリックして検証が失敗したことを了承てから、ブリングアップに進むことができます。導入環境の各 ESXi ノードで次のコマンドを実行する。 esxcli storage core device list | grep -B 3 -e "Size: 3662830" | grep ^naa > /tmp/capacitydisks; for i in `cat /tmp/capacitydisks`; do esxcli vsan storage tag add -d $i -t capacityFlash; vdq -q -d $i; done 注：上記のコマンドのサイズパラメータは、ユーザーごとに異なります。
ホストがメンテナンスモードになっている場合、仮想マシンの展開時にブリングアップおよび VI ワークロードドメインのワークフローの処理に失敗するどちらのワークフローも、ホストのメンテナンスモードの状態を確認しません。その結果、NSX Controller の展開に失敗します。この問題の原因は、vSAN のデフォルトポリシーでは、環境に少なくとも 3 台の ESXi ノードを使用する必要があるためです。回避策：このエラーが発生した場合は、次の手順を実行します。 vCenter Server または esxcli ユーティリティで、影響を受けるホストのメンテナンスモードを終了します。 esxcli system maintenanceMode set -e 0 失敗したワークフローを再起動します。
Cloud Foundation Builder 仮想マシンが、15 分以上経過した後もロックされた状態のままになる VMware Imaging Appliance (VIA) は、ログインを 3 回失敗するとユーザーをロックアウトします。通常、15 分後にロックアウトがリセットされますが、基盤となる Cloud Foundation Builder 仮想マシンは自動的にリセットされません。回避策：SSH を使用して、Cloud Foundation Builder 仮想マシンに root としてログインします。次のコマンドを使用して、管理者ユーザーのパスワードをリセットし、アカウントのロックを解除します。 pam_tally2--user =<user>--reset
JSON 仕様の検証をキャンセルできないこれは、JSON ファイルにエラーがあるときに、ブリングアッププロセスで発生します。ユーザーは JSON 検証をキャンセルできませんが、ESXi ホストに接続されていない場合、検証に最大で 5 分かかる場合があります。回避策：キャンセルするための回避策はありません。ただし、検証に失敗した場合は、構文またはその他のエラーがないか JSON を確認してください。エラーを修正して、もう一度やり直してください。
ブリングアップの実行中、プラットフォーム監査が vSAN 接続検証エラーを返す6 つの 1 TB HDD と約 370 GB の SSD キャッシュ 2 つを含む環境を構成する際に確認される現象です。これは、vSAN プラットフォームで大量のデバイスを監査する場合、堅牢性が十分でない可能性を示唆するものです。ただし、エラーメッセージの値が正しくない状態でも、ブリングアップを続行して正常に完了することができます。回避策：必要なアクションはありません。ブリングアップには影響はありません。

アップグレードに関する既知の問題 
     
      
     RPM のアップグレード後に Operationsmanager コンポーネントが起動しないOperationsmanager RPM を手動で最新バージョンにアップグレードした後、Operationsmanager の起動に失敗します。システムは次の情報レベルのメッセージを返します。Waiting for changelog lock...（changelog ロックを待機しています）これは、サービスの再起動が重複しているため、後続のサービスが実行されないことが原因と考えられます。これは、commonsvcs など、liquibase を実行しているサービスなどで発生する可能性があります。
 回避策：データベースから databasechangeloglock テーブルをクリーンアップします。 
       
       管理者ユーザー「vcf」として SDDC Manager 仮想マシンにログインします。 
       su と入力して root ユーザーに切り替えます。 
       次のコマンドを実行します。 
         
         postgres コマンド プロンプトを開きます。
# psql -h /home/postgresql/ -U postgres 
         パスワード マネージャを開きます。
\c password_manager opsmgr 
         databasechangeloglock を削除します。
delete from databasechangeloglock
注： 上記の手順を次の 1 つのコマンドにまとめることができます。
psql -h /home/postgresql/ -U postgres -d password_manager -c "delete from databasechangeloglock" 
         パスワード マネージャをそのままにして、postgres プロンプトを終了します。
\q 
         operationsmanager コンポーネントを再起動します。
# systemctl restart operationsmanager 
         operationsmanager が実行中であることを確認します。
# curl http://localhost/operationsmanager/about
次のような値が返されます。
{"id":"2cac9b7c-545f-4e6d-a66-6f81eef27601","name":"OPERATIONS_MANAGER",
 "version":"3.1.0-SNAPSHOT-9580592","status":"ACTIVE","serviceUrl":
"http://127.0.0.1/operationsmanager","description":"Operations Manager"} 
        
   
      
  
      
     アップグレード プロセスによって無効なデータのエラーが返されるCloud Foundation 3.0 から 3.0.1 へのアップデート、および 3.0.1 から 3.5 へのアップデート時に発生します。Lifecycle Manager を介してアップグレードすると、システムによって次のエラーが返されます。Scheduling immediate update of bundle failed.UPGRADE_SPEC_INVALID_DATA; User Input cannot be null/empty, User Input is required for this upgrade.
 回避策：ブラウザ画面を更新します。
  
      
     Cloud Foundation 3.5 へのアップグレード プロセスで、一部のホストが以前の ESXi バージョンを使用し続ける場合があるデフォルトで Lifecycle Manager には、コンポーネント情報 (BOM) に基づいた、最新の ESXi バージョンのみが表示されます。ただし、ESXi の 2 つのバージョンで実行されているワークロード ドメインでは、エラーが発生する可能性があります。
 回避策：すべてのホストで ESXi のバージョンを手動でアップデートします。
  
      
     Cloud Foundation 3.0.1 から 3.5 へのアップグレード中、ユーザーに対して必要な vRealize Suite Lifecycle Manager のアップグレードが通知されない。Cloud Foundation 3.0.1 から 3.5 にアップグレードした後、vRealize Suite コンポーネントを展開する前に、vRealize Suite Lifecycle Manager を 1.2 から 2.0 にアップグレードする必要があります。vRealize Suite Lifecycle Manager のアップグレードを行わないと、vRealize Suite コンポーネントの展開に失敗する
 回避策：ユーザーが以前の Cloud Foundation 環境で vRealize Suite Lifecycle Manager をすでに展開している場合は、vRealize コンポーネントをアップデートしてから Cloud Foundation 3.5 に展開してください。そうしないと、展開に失敗することがあります。
  
    
vRealize 製品の統合に関する既知の問題 
     
      
     vRealize Operations アプライアンスが異なるサブドメインにある場合、vRealize Log Insight 構成内の vRealize Operations の起動に失敗するCloud Foundation で vRealize Suite を展開する際、ユーザーは vRealize ロード バランサの FQDN （完全修飾ドメイン名） 値を入力します。この FQDN が、最初のブリングアップに使用されたドメインとは異なるドメインにある場合、展開に失敗することがあります。
 回避策：この問題を解決するには、vRealize Log Insight 仮想マシンに vRealize Operations ドメインを追加する必要があります。 
       
       vRealize Log Insight 仮想マシンにログインして、/etc/resolv.conf ファイルを変更します。nameserver 10.0.0.250 nameserver 10.0.0.250 domain vrack.vsphere.local search vrack.vsphere.local vsphere.local
  
       vRealize Operations に使用されるドメインを上記の最後の行に追加します。 
       この操作をそれぞれの vRealize Log Insight 仮想マシンで繰り返します。 
      
  
      
     アンインストール時に vRealize Suite Lifecycle Manager が正しくクリーンアップされない展開に失敗した vRealize Automation または vRealize Operations Manager をアンインストールしても、vRealize Suite Lifecycle Manager がクリーンアップされません。この問題は、vRealize Automation または vRealize Operations の展開ワークフローが手順「ChangeVrslcmPasswords」の特定の条件下で失敗した場合に発生することがあります。たとえば、このに SDDC Manager サービスが再起動された場合などです。その結果、展開に失敗した vRealize Automation または vRealize Operations Manager のアンインストール中に、vRealize Suite Lifecycle Manager 仮想マシンがシステムから完全にクリーンアップされません。
 その後、vRealize Automation または vRealize Operations Manager を展開しても、vRealize Suite Lifecycle Manager が不正な状態にあるために失敗します。
 回避策：ナレッジベースの記事 KB57917 に記載されている手順に従って、問題を解決してください。
  
      
     vRealize Suite：証明書の置き換え後、IaaS Manager Service ノードで IaaS Manager Service が停止するvRealize Automation リソースの証明書を置き換えた後、IaaS Manager サービス ノードで Manager Service が停止します。これは、vRealize Automation アプライアンスにアクセスし、vRealize Automation 設定タブを開くことで確認できます。IaaS Manager サービス エントリ（たとえば、iaasms1.<serviceusername>.local または iaasms2.<serviceusername>.local）を開くと ManagerService が停止状していることが示されます。
 回避策：証明書の置き換えが完了したら、プリンシパル IaaS Manager サービス ノード（たとえば「iaasms1.<serviceusername>.local」など）で ManagerService を手動で再起動する必要があります。（システム上のノード名は異なる場合があります）。上記の手順に従ってノードにアクセスし、再起動します。ノードが再起動するまで 5 ～ 10 分かかる場合があります。再起動の検証に戻ることを推奨します。また、VMware vCloud Automation Center サービスも再起動する必要があります。
 注： 再起動の必要があるのは 1 台のノードのみです。もう一方のノードは、ピアとして再起動します。
  
      
     401 エラーで vRealize Automation コンポーネントの証明書の置き換えに失敗する401 不正なエラーにより、vRealize Automation コンポーネントの証明書の置き換えが失敗し、「Importing certificate failed for VRA Cafe nodes（VRA Cafe ノードにより証明書のインポートに失敗しました）」というメッセージが表示されます。この問題は、vRealize Automation 製品インターフェイスのパスワードのロックアウトが原因で発生します。たとえば、Cloud Foundation に関係なく、ユーザーが誤った認証情報を使用して vRealize Automation に何度もログインしようとすると、ロックアウトしてしまいます。
 回避策：ロックアウトは 30 分間継続し、その後であれば証明書の置き換えが正常に完了する可能性があります。
  
      
     ロード バランサ仮想マシンの IP アドレスが SDDC Manager のインターフェイスで N/A と表示される管理ドメイン画面の[サービス]タブで、vRealize Log Insight ロード バランサ仮想マシンの IP アドレスとして N/A と表示されます。
 回避策：ユーザーは、次のようにして IP アドレスを検出できます。 
       
       SDDC Manager 仮想マシンにログインし、root ユーザーに変更します。 
       次のコマンドを実行して、ロード バランサの IP アドレスを返します。nslookup <vrli-hostname>。 
      
  
      
     vRealize Suite Lifecycle Manager 2.0 にアップグレードすると、環境セクションと要求履歴が削除されるvRealize Suite Lifecycle Manager 1.2 から 2.0 へのアップグレード プロセスにより、デプロイされたアプライアンスが置き換えられ、ベースライン構成がリストアされます。これが原因で、ユーザー インターフェイスから以前の環境セクションが削除され、要求履歴も削除されます。これにより監査の問題が発生する可能性があります。ただし、vRealize Suite 製品アクションの送信元の要求（デプロイ、ワークロード ドメイン接続など）は、SDDC Manager のログに保持されます。
 回避策：ログの保持とアーカイブのために vRealize Log Insight が手動で構成されていることを確認します。これにより、SDDC Manager のログと送信元の vRealize Suite 製品のアクション要求が保持されるようになります。例として、VMware Validated Design 4.3 ドキュメントの「Configure Log Retention and Archiving for vRealize Log Insight in Region A」を参照してください。
  
      
     vRealize Log Insight ノードが Syslog サーバの IP アドレスで設定されているCloud Foundation をデプロイし、NSX-T ワークロード ドメインを作成した後に確認される現象です。NSX-T ワークロード ドメインで Log Insight を有効にすると、アクティブな Log Insight が、ロード バランサ仮想アプライアンスの IP アドレスではなく、Syslog サーバ ノードの IP アドレスの 1 つとして誤って設定されます。
 回避策：SSH を使用して、NSX-T Manager および NSX-T Controller ノードに管理者ユーザーとしてログインし、ロード バランサ仮想アプライアンスを Syslog サーバとしてポイントするように設定を手動で変更します。各ノードで次の手順を実行します。 
       
       現在の Syslog サーバの IP アドレスとポート設定を一覧表示します。
get logging-server 
       目的の IP アドレスに変更します。
set logging-server <ロード バランサの IP アドレス:ポート> proto udp level info 
       構成情報の一覧を再度確認します。
get logging-server 
      
  
    
ネットワークに関する既知の問題 
     
      
     ネットワーク接続検証のプラットフォーム監査に失敗するvSwitch MTU は VXLAN VTEP MTU と同じ MTU に設定されます。ただし、vSAN と vMotion の MTU が 9000 に設定されている場合、vmkping が失敗します。
 回避策：vSwitch が VXLAN MTU 値で設定されているので、VXLANMtu をジャンボ MTU として設定することで、導入 JSON の nsxSpecs 設定を変更します。これにより、プラットフォーム監査でエラーが発生しなくなります。
  
      
     NSX Manager が vSphere Web Client で表示されないNSX Manager が vSphere Web Client に表示されないことに加え、NSX のトップ画面に次のエラーメッセージが表示されます。「使用できる NSX Manager がありません。現在のユーザーが NSX Manager に割り当てられたロールを所有していることを確認してください。」この問題は vCenter Server と、ログインしているアカウントに権限が正しく設定されていない場合に発生します。
 回避策：この問題を解決するには、ナレッジベースの記事 KB2080740「vSphere Web Client にエラー「利用可能な NSX Manager がありません（No NSX Managers available）」と表示される」に記述されている手順に従ってください。
  
      
     NSX-T ワークロード ドメインのパスワード ローテーション後、ホストの追加に失敗するNSX-T ワークロード ドメインの vCenter Server と ESXi のパスワード ローテーション後、ホストの追加に失敗します。具体的には、ファブリックを構成するサブタスクの実行に失敗します。これは、パスワード ローテーションに関連していますが、NSX-T ホストの準備が不十分であるため、失敗してしまいます。
 回避策：NSX-T Manager にログインし、失敗したホストを削除して、SDDC Manager でホストの追加を再試行します。
  
  
      
     複数の NSX-T ワークロード ドメインがあることにより、オーバーレイ トランスポート ゾーンの競合が発生する複数の NSX-T ワークロード ドメインを作成すると、後続の各ドメインは個別にオーバーレイ ネットワーク セットを持つことになります。異なる NSX-T Edge は、単一のオーバーレイ トランスポートゾーンを必要とするため、通信できません。
 回避策：1 つの NSX-T ワークロード ドメインのみにデプロイを制限します。
  
    
SDDC Manager に関する既知の問題 
     
      
     ライセンス ページでいくつかのデータの列が表示されないInternet Explorer ブラウザで確認される現象です。ライセンス ページに製品名のみが表示されます。他のすべてのデータ列は表示されません。
 回避策：影響が生じるのは Internet Explorer のみです。サポートされている別のブラウザを使用します。（このリリースノートの上記を参照してください。）
  
      
     ネットワーク検証をキャンセルすると、次回の検証の実行時にホストの検証に失敗するネットワーク接続検証タスクの実行中に検証をキャンセルしようとすると、次の検証時に、Physical NIC vmnic1 is connected to adt_vSwitch_01 on esxi host esxi-1 (10.0.0.100): should be disconnected. など、物理 NIC の問題でホストの検証が失敗します。
 回避策：この問題は、次のように解決できます。 
       
       失敗したホスト検証を使用して検証を完了します。 
       検証を再試行します。 
      
 ホストの検証はエラーなしで完了する必要があります。
  
      
     パスワードの一括ローテーションを実行すると、誤ったエラー メッセージが表示されます。パスワード ローテーションのために多数のドメインを選択した場合、処理は成功します（[タスク] パネルに表示されます）が、[パスワード管理] 画面に「Failed to rotate...（ローテーションに失敗しました）Failed to rotate... 504 Gateway Time-out message（504 ゲートウェイ タイムアウト メッセージ）」と表示されます。
 回避策：画面を更新して、誤ったメッセージをクリアします。
  
      
     現在の検証レポートがダウンロードまたは印刷できない検証をキャンセルした後は、現在の検証レポートではなく、最新の正常な検証レポートのみをダウンロードまたは印刷できます。
 回避策：なし。
  
    
ワークロード ドメインに関する既知の問題 
     
      
     vSAN HCL データベースがワークロード ドメイン作成時に更新されないワークロード ドメインを作成する場合、そのプロセスの一環として vSAN HCL データベースを更新する必要があります。その結果、vCenter Server でデータベースの状態がクリティカルと表示されます。
 回避策：ナレッジベースの記事 KB2145116 の説明に従って、vSAN HCL データベースを手動で更新します。
  
      
     ホストが別の VLAN にある場合にホストの追加に失敗するワークロード ドメイン クラスタへのホストの追加は、新しいホストが同じクラスタ内の他のホストとは異なる VLAN 上にある場合でも成功するべきです。
 回避策： 
       
       ホストを追加する前に、クラスタの VDS に新しいポートグループを追加します。 
       追加するホストの VLAN ID を使用して、新しいポートグループにタグを付けます。 
       SDDC Manager ダッシュボードでホストの追加ワークフローを実行します。
これが、「ホストの vmknic を dvs に移行」する処理で失敗します。 
       vCenter Server で失敗したホストを見つけ、ホストの vmk0 を手順 1 で作成した新しいポート グループに移行します。
詳細については、vSphere の製品ドキュメントのvSphere Distributed Switch への VMkernel アダプタの移行を参照してください。 
       ホストの追加を再試行します。
ホストの追加に成功します。 
      
 注： ホストを削除する場合は、ポートグループを他のホストで使用していなければ手動で削除してください。
  
      
     ドメインへのクラスタの追加が、エラー 「FAILED_TO_GET_COMPLIANT_ESXI_VERSIONS」 で失敗するこの問題は、ユーザーが新しく作成したワークロード ドメインにクラスタを追加すると確認できます。ドメイン作成ワークフローには、そのドメインのクラスタの作成が含まれます。ただし、ドメイン作成ワークフローが完了しても、新しいクラスタでは認識されるまで最長で 5 分かかる場合があります。このエラーは、この 5 分間にユーザーがさらにクラスタを追加しようとした場合に発生します。
 このエラーは、LCM の更新後すぐにクラスタの追加ワークフローを試行したときに発生する可能性が最も高くなります。個別の問題により LCM キャッシュのリフレッシュに予想よりも時間がかかるため、誤ったコンポーネント バージョン情報が返され、エラーが発生します。
 回避策：LCM の更新が完了したら、少なくとも 5 分待ってから、クラスタを追加します。
  
      
     ワークロード ドメインの作成で、NFS データストアの作成に失敗することがあるNFS ベースのワークロード ドメインまたはクラスタを作成する場合、システムは NFS サーバおよびマウントの入力情報を検証しません。誤った情報が入力された場合、ワークロード ドメイン作成ワークフローは入力を受け入れます。その結果、ワークロード ドメインの作成に失敗します。
 回避策：不具合が判明したら、ワークロード ドメインを削除して、ホストの再イメージ化を実行します。正しいサーバとマウントの設定情報を使用して、もう一度やり直してください。
  
      
     NSX Controller クラスタの展開タスクで、ワークロード ドメインの作成に失敗することがある展開した NSX Controller 仮想マシンが、vSphere 分散ポートグループに接続できないことがあります。その結果、制御クラスタの展開タスクでドメイン マネージャのワークフローが失敗します。
 回避策：vCenter Server にログインし、障害が発生したワークロード ドメイン内のすべての ESXi ホストを再起動します。SDDC Manager ダッシュボードに戻り、失敗したワークロード ドメイン作成ワークフローを再起動します。
重要： 再起動する前に、ホストをメンテナンス モードにする必要があります。再起動後、メンテナンス モードを解除します。
  
      
     場合によっては、VI ワークロード ドメイン NSX Manager が vCenter Server に表示されないことがあるNFS ベースのワークロード ドメインで発生する現象です。VI ワークロード ドメインの作成に成功しましたが、NSX Manager 仮想マシンは vCenter Server に登録されていないため、vCenter Server には表示されません。
 回避策：この問題を解決するには、次の手順を実行します。 
       
       NSX Manager にログインします (http://<nsxmanager IP>)。 
       [管理] > [NSX 管理サービス] の順に移動します。 
       ルックアップ サービスと vCenter Server を登録解除してから再登録します。 
       ブラウザを閉じて、vCenter Server にログインします。 
      
  
      
     NSX-T ワークロード ドメインをすべて削除した後、新しい NSX-T ワークロード ドメイン作成ワークフローが失敗するNSX-T Manager と NSX Controller ノードのインベントリを削除した際、対応するアプライアンスを管理クラスタに残したことが原因です。
 回避策：最後の NSX-T ワークロード ドメインを削除した後、次の追加手順が必要になります。 
       
       NSX-T Manager 仮想マシンと、管理 (MGMT) ワークロードドメインで実行されているすべての NSX-T コントローラの電源をオフにします。 
       
       
       管理クラスタから NSX-T Manager およびすべての NSX-T Controller 仮想アプライアンスを削除します。 
      
  
      
     インストール バンドルが不足していても、ワークロード ドメインの作成がブロックされないこの問題は、アップグレード直後の 3.5 環境で確認されています。すべてのインストール バンドルのダウンロードが完了しないうちに、ユーザーがワークロード ドメインを作成すると発生します。バンドルが見つからないと、処理を続行できません。警告メッセージは、ユーザーが新しいワークロード ドメインに新しいホストを追加しようとした場合にのみ表示されます。
 回避策：これには 2 つの問題があり、次の 2 つの回避策で対応します。 
       
       安全性を回復するには、SDDC Manager の [ワークロード ドメインの作成] 画面の強制更新を実行します。今後は、インストール バンドルがない場合、ワークロード ドメインを作成できなくなります。 
       ワークロード ドメインを作成した後にこの問題を修正するには、新しいワークロード ドメインを削除し、ハード更新を実行して、目的のワークロード ドメインを再作成する必要があります。 
      
  
      
     SDDC Manager から vRealize Operations Manager の有効な VI ワークロード ドメインを削除できないvCenter Server アダプタを削除しようとしても失敗し、SSL エラーが返されます。
 回避策：この問題を解決するには、次の手順を実行します。 
       
       vRealize Operations Manager での vCenter アダプタ インスタンスの構成の説明に従って、vRealize Operations Manager で vCenter Server アダプタ インスタンスを作成します。
この手順が必要となるのは、失敗したワークロード ドメインの削除処理によって既存のアダプタが削除されているためです。 
       ナレッジベースの記事 KB56946 に記載されている手順を実行します。 
       失敗した VI ワークロード ドメイン削除ワークフローを SDDC Manager インターフェイスから再起動します。 
      
  
    
セキュリティ運用に関する既知の問題 
     
      
     パスワード ポリシーの更新に失敗すると、アップデート メッセージが表示されるパスワード ポリシーの更新に失敗すると、システムは「アップデート」の状態となり、トランザクション履歴には「Operation failed in 'appliance update', for  credential update（資格情報更新のための「アプライアンスのアップデート」で処理に失敗しました）」のメッセージが表示されます。実際には、新しいパスワードが要件を満たしていないため、処理は失敗しています。「Password update has failed due to unmet policy requirements（パスワードの更新はポリシー要件に合致していないために失敗しました）」というメッセージの方が適切なため、ポリシーを確認することを推奨します。
 回避策：対象となるコンポーネントのパスワード ポリシーを確認し、必要に応じてパスワードの設定を変更してから、再度更新してください。
  
      
     vCenter Server の SSL 証明書の置き換えにより vRealize Operations データ収集が中断するvCenter Server コンポーネントの証明書を置き換えた後、vRealize Operations Manager の vCenter Server コンポーネントと vSAN コンポーネントの両方で「Collection failed（収集に失敗しました）」というエラーメッセージが報告されます。接続をテストし、新しい証明書を受け入れようとすると、次のエラーメッセージが返されます。Unable to establish a valid connection to the target system（ターゲット システムへの有効な接続を確立できません）アダプタ インスタンスは、証明書を 1 つのみ許可する場合に、複数の証明書を信頼するように設定されています。不要な古い証明書を削除して、もう一度やり直してください。
 回避策：この問題が発生した場合は、次の手順を使用して解決してください。 
       
       現在の vCenter Server および vSAN アダプタを削除します。 
       vRealize Operations による最初の設定と認証情報を使用して、それらを再作成します。 
       接続をテストし、新しい証明書を受け入れて構成を保存します。 
      
  
      
     Microsoft CA パスワードに特定の特殊文字が含まれている場合、CA の構成ワークフローが失敗するMicrosoft CA パスワードに次の特殊文字が含まれている場合に、CA の構成ワークフローが失敗します。  < > (左または右の山括弧)、' (一重引用符またはアポストロフィ)、"(二重引用符)、または & (アンパサンド)。永続的なクロスサイト スクリプティングのリスクを低減するために、SDDC Manager はこれらの文字をエスケープ文字に変換して、パスワードを無効にします。
 回避策：Microsoft CA パスワードに、問題のある特殊文字が含まれていないことを確認します。その場合は、この制限に準拠するようにパスワードを変更します。
  
    
Lifecycle Manager に関する既知の問題 
     
      
     ダウンロード バンドルをステータスでフィルタリングできないInternet Explorer ブラウザでのみ確認される現象です。SDDC Manager でダウンロード バンドルを表示している場合、ステータスによるフィルタリングは機能しません。
 回避策：無視するか、Chrome や Firefox など、別のサポート対象ブラウザを使用します。
  
    
サービス プロバイダに影響する既知の問題 
     
      
     ADD HOST SPEC 処理で vmnicToVdsNameMap データを受け入れることができない2 つの分散スイッチが必要な環境のサービス プロバイダで確認される現象です。たとえば、1 つのネットワーク ファブリックに管理と VXLAN を配置し、別のネットワーク ファブリックに vSAN と vMotion を配置するとします。このとき、クラスタ内の最初のホストが、追加のホストとは異なる vmnic を使用する場合があります。そのため、ユーザーは新しく追加されたサーバの vmnic を正しい Distributed Switch にマッピングする必要があります。
 回避策：ナレッジベースの記事 KB60348「Adding a host to VMware Cloud Foundation for Service Providers cluster fails if there is more than one portgroup on the public vNetwork Distributed Switch.」を参照してください。
  
    
サポートおよび保守性 (SoS) ユーティリティに関する既知の問題 
     
      
     New：ホストのクリーンアップ機能は、管理 VLAN で管理されているホストでのみサポートされる新しいサポートおよび保守性 (SoS) ユーティリティ オプション (--cleanup-host) は、管理 VLAN で設定されたホストでのみ機能し、他の VLAN のホストでは機能しません。
 回避策：回避策はありません。

リリース ノートの概要

新機能

更新された Cloud Foundation のコンポーネント 情報 (BOM)