VMware Integrated OpenStack 4.0 リリースノート

VMware Integrated OpenStack 4.0 | 2017 年 9 月 19 日 | ビルド 6437860
VMware Integrated OpenStack with Kubernetes | 2017 年 9 月 19 日 | ビルド 6564406

リリースノートに追加または更新された内容をご確認ください。

リリースノートの概要

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

VMware Integrated OpenStack について
利用可能な言語
新機能
VMware Integrated OpenStack with Kubernetes
互換性
VMware Integrated OpenStack 4.0 へのアップグレード
VMware Integrated OpenStack 4.0 用オープンソースコンポーネント
既知の問題

VMware Integrated OpenStack について

VMware Integrated OpenStack は、統合プロセスを効率化することで、OpenStack クラウドインフラストラクチャのデプロイを大幅に簡素化します。VMware Integrated OpenStack には事前設定なしですぐに使用できる OpenStack 機能と、vCenter Server で直接稼動するデプロイマネージャの vApp を介した簡単な構成ワークフローが備わっています。

利用可能な言語

VMware Integrated OpenStack バージョン 4.0 は英語、および簡体字中国語、繁体字中国語、日本語、韓国語、フランス語、ドイツ語、スペイン語の 7 つの追加言語でご利用になれます。OpenStack リソースのすべての入力および命名規則（プロジェクト名、ユーザー名、イメージ名など）、および基盤となるインフラストラクチャコンポーネント（ESXi ホスト名、仮想スイッチポートグループ名、データセンター名、データストア名など）には、ASCII 文字を使用する必要があります。

新機能

本リリースは、最新の OpenStack Ocata リリースに基づいており、次の新機能および拡張機能を提供します。

最新バージョンの VMware 製品のサポート。VMware Integrated OpenStack 4.0 は、VMware vSphere 6.5 Update 1、VMware NSX for vSphere 6.3.3、および VMware NSX-T 2.0 をサポートし、これらと完全な互換性があります。
SR-IOV 拡張機能。direct vNIC タイプがサポートされ、SR-IOV 仮想機能を指定するポートを作成できるようになりました。direct vNIC タイプを使用して作成した Neutron ポートは OpenStack インスタンスの起動フェーズで使用できます。この機能拡張により、direct と normal タイプの vNIC など、複数の vNIC タイプを持つインスタンスを起動する機能が追加されました。
マルチ vCenter Server のサポート。NSX-T VMware Integrated OpenStack デプロイにさらに vCenter Server コンピューティングインスタンスを追加できるようになりました。
vRealize Automation との統合。vRealize Automation ポータルに組み込まれた [VMware Integrated OpenStack] タブから OpenStack デプロイを管理し、OpenStack XaaS ブループリントを設計できるようになりました。
VMware Integrated OpenStack with Kubernetes。VMware Integrated OpenStack 4.0 以降では、Kubernetes 上に構築されたコンテナオーケストレーションプラットフォームが含まれ、完全にサポートされるようになりました。
コンソールログ。VMware Integrated OpenStack 4.0 でデプロイされたすべての仮想マシンで、nova console-log コマンドが利用可能になりました。
マルチテナントのセキュリティ強化。VMware Integrated OpenStack 4.0 では、新しいテナント仮想データセンター構造が導入されました。これは、OpenStack の配布に差をつける要因となるマルチテナントを提供します。この構造により、CPU およびメモリのリソースをテナントごとに割り当てる機能が提供され、リソースの確保とマルチテナント環境での分離が実現します。管理者は、新たに導入された viocli コマンドを使用するか、テナント固有のフレーバーを作成することによって、セキュアなマルチテナント環境を構成できます。
VLAN のトランスペアレント。VMware NSX Plug-In for vSphere Distributed Switch および NSX for vSphere では、VLAN のトランスペアレント拡張機能がサポートされるようになりました。この機能により、トランスペアレントフラグが有効な Neutron ネットワークの作成が可能になります。
ライブサイズ変更。仮想ネットワーク機能 (VNF) リソースのスケールアップを、サイズ変更操作のダウンタイムなしで実行できるようになりました。イメージメタデータ os_live_resize を使用したディスク、メモリ、vCPU のサイズ調整が可能です。
新しいライセンスモデル。VMware Integrated OpenStack 4.0 では、Data Center Edition と Carrier Edition のライセンスモデルが導入されており、ソリューションのインストール後にこれらを適用する必要があります。有効なライセンスを取得する方法の詳細については、https://www.vmware.com/products/openstack.html#pricing を参照してください。
NUMA の完全なサポート。VMware Integrated OpenStack 4.0 では、基盤となる vSphere プラットフォームにおける NUMA 対応の配置をサポートしています。この機能により、Telco 環境で実行される Virtual Network Function (VNF) で低遅延と高スループットが実現されます。

VMware Integrated OpenStack with Kubernetes

Kubernetes 上に構築されたコンテナオーケストレーションプラットフォームが VMware Integrated OpenStack に含まれるようになり、アプリケーション開発者に向けたインフラストラクチャスタック全体のプロビジョニングが可能になりました。このプラットフォームでは、次の機能が提供されます。

最新バージョンの Kubernetes のサポート。VMware Integrated OpenStack 4.0 には Kubernetes バージョン 1.7 が含まれ、これが完全にサポートされます。
VMware Integrated OpenStack とのシームレスな展開。コンテナプラットフォームを VMware Integrated OpenStack に簡単にインストールし、統合された操作性を実現できます。
ユーザーインターフェイスによる簡単な操作。管理者やユーザーは、管理用ユーザーインターフェイスを介して Kubernetes 管理操作を簡単に実行することができます。
共有または排他的クラスタタイプを使用可能。クラスタを排他的モードで展開すると、許可されたすべてのユーザーがネームスペースを管理できます。一方、共有モードで展開するとマルチテナント環境が強制されます。
エンタープライズ対応のストレージとネットワーク。VMware Integrated OpenStack との連携により、vSAN と NSX をベースとするエンタープライズクラスのストレージとネットワーク機能が Kubernetes に拡張されます。
特別な設定は不要な LDAP/Active Directory 連携。Keystone を使用すると、特別な設定を必要とすることなく、Active Directory と LDAP の連携がサポートされ、完全なマルチテナント環境が可能になります。

互換性

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

VMware Integrated OpenStack 4.0 へのアップグレード

VMware Integrated OpenStack 3.1 環境から VMware Integrated OpenStack 4.0 に直接アップグレードできます。

アップグレード手順は、VMware Integrated OpenStack Manager で直接行います。一連の手順の詳細については、『VMware Integrated OpenStack 管理者ガイド』を参照してください。

VMware Integrated OpenStack 4.0 用オープンソースコンポーネント

VMware Integrated OpenStack 4.0 で配布されるオープンソースソフトウェアコンポーネントに適用される著作権情報とライセンスは、製品ダウンロードページの [オープンソース] タブで入手できます。また、入手可能な VMware Integrated OpenStack の最新リリースについて、ソースコードやソースコードへの改変を公開することが必要な GPL、LGPL、またはその他の類似するライセンスのソースファイルをダウンロードすることもできます。

既知の問題

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

VMware Integrated OpenStack
VMware Integrated Openstack with Kubernetes

VMware Integrated OpenStack

トランスポートゾーンの UUID の入力がないと、Horizon でプロバイダネットワークの作成に失敗する
VLAN タイプネットワークを作成するときは、Horizon の [provider_network] テキストボックスにトランスポートゾーンの UUID の値を入力することが必須です。値が入力されていないと、ネットワークの作成が失敗します。

回避策：VMware NSX インターフェイスのトランスポートゾーンの UUID を参照し、その値を [provider_network] テキストボックスに入力します。
分散論理ルーター上の DHCP が無効なサブネットでメタデータにアクセスできない。
分散論理ルーターを使用する場合、DHCP が無効なサブネット上のインスタンスはルーターのインターフェイスを介してメタデータにアクセスできません。この動作は、共有ルーターおよび排他的なルーターでは発生しません。単一の論理ネットワーク（メタデータネットワークなど）は複数の分散論理ルーターに接続することができないため、これは予期される動作の場合もあります。

回避策：なし。
Ubuntu Xenial OVA を使用して作成された Glance イメージから起動すると、OS が起動に失敗する。
OS が次のエラーで起動に失敗します。
```
error: file `/boot/grub/i386-pc/efi_gop.mod' not found
error: file `/boot/grub/i386-pc/efi_uga.mod' not found
```
これは、Ubuntu クラウドイメージプロジェクトのバグによって追跡される Xenial クラウド OVA に関する問題です。詳細については、https://bugs.launchpad.net/cloud-images/+bug/1615875 を参照してください。

回避策：Ubuntu のバグが修正され、新しい OVA が公開されるまで、Xenial ISO イメージを使用します。
--loadbalancer オプションを使用して作成されたプールにメンバーを追加すると、LBaaS v2 が失敗する。
OpenStack LBaaS v2 では、ロードバランサープールを構成するための次の 2 つのオプションが提供されています。--loadbalancer および --listenerプールを作成するには、2 つのオプションのうちの少なくとも 1 つを指定する必要があります。
--loadbalancer オプションを使用して OpenStack LBaaS v2 のプールを作成すると、メンバーの追加に失敗し、ロードバランサーは ERROR 状態になります。

回避策：--listener オプションを使用してプールを作成します。
名前を変更した OpenStack インスタンスが vCenter Server に古い名前で表示される。
nova rename コマンドを使用して OpenStack インスタンスの名前を変更すると、変更は OpenStack データベースにのみ表示されます。vCenter Server インスタンスには古い名前が表示されます。

回避策：なし。
アベイラビリティゾーンの構成が正常に適用されないことがある。
アベイラビリティゾーンの構成を変更した後、バックアップエッジを削除して再作成するまで、新しい構成が適用されないことがあります。

たとえば、nsx.ini ファイルの次の構成では、バックアップエッジを含むアベイラビリティゾーンがあります。
zone3:resgroup-163:datastore-12:true:datastore-21
そのゾーンのリソースプールを変更して Neutron を再起動すると、バックアップエッジは更新されません。新しいルーターやネットワークをデプロイした場合、アベイラビリティゾーン構成の不整合の原因となる古いバックアップエッジが使用されます。

アベイラビリティゾーンの構成を変更後 Neutron を起動する前に、管理ユーティリティを呼び出します。
1. nsx.ini ファイルでアベイラビリティゾーンの構成を変更します。
2. すべてのバックアップエッジを順次削除します。
  nsxadmin -r backup-edges -o clean --property edge-id=edge-XX
3. Neutron を再起動します。
4. 新しい構成を検証します。
  availability-zone-list
新しい OpenStack インスタンスをデプロイすると、「Certificate is not in CA store」というエラーが表示される場合がある。
vRealize Automation に接続された別のインスタンスで使用されていた IP アドレスを持つ新しい VMware Integrated OpenStack インスタンスをデプロイすると、以下の証明書エラーが発生する場合があります。
Cannot execute the request: ; java.security.cert.CertificateException: Certificate is not in CA store.(Workflow:Invoke a REST operation / REST call (item0)#35)

回避策：vRealize Orchestrator でそれぞれのワークフローを実行して、古い VMware Integrated OpenStack インスタンスの証明書を削除し、新しいインスタンスの証明書をインポートします。
1. vRealize Orchestrator にログインします。
2. [ライブラリ] > [構成] > [SSL Trust Manager] の順に選択します。
3. 古い VMware Integrated OpenStack インスタンスの信頼できる証明書を削除するためのワークフローを実行します。
4. URL から新しいインスタンスの証明書をインポートするためのワークフローを実行します。
VMware Integrated OpenStack Manager インターフェイスで、デプロイ後に Syslog 設定を変更できない
VIO をデプロイした後、VIO Manager インターフェイスの設定を使用して Syslog サーバ構成を変更することはできません（[VMware Integrated OpenStack] > [管理サーバ] > [設定の編集] > [vApp オプション]）。

回避策：次のようにして、構成を変更します。[VMware Integrated OpenStack] > [OpenStack クラスタ] > [管理] > [Syslog サーバ]。

ボリュームを接続できなかったにも関わらず、ダッシュボードに「接続されている」と表示される場合がある
これは OpenStack の既知の問題であり、Icehouse リリースで最初に報告されました。

イメージのアップロードに長時間かかると、NotAuthenticated エラーが発生する
これは OpenStack の既知の問題であり (https://bugs.launchpad.net/glance/+bug/1371121)、Icehouse リリースで最初に報告されました。

Glance（イメージサービス）でデータストア名に特殊文字を使用できない
データストア名にコロン、アンパサンド、またはコンマなど、アルファベット文字以外の文字が含まれている場合、そのデータストアを Glance サービスに追加することはできません。具体的には、次の文字は他の目的に予約されており、構成に干渉を生じるため、Glance データストア名に使用することはできません。: , / $（コロン、カンマ、スラッシュ、ドル記号）。

回避策：これらの記号を使用しないでください。

いずれかのコントローラ仮想マシンをリブートすると、高可用性が損なわれる場合がある
一方のコントローラで障害が発生すると、もう一方のコントローラによってサービスの提供が続行されます。しかし、最初のコントローラをリブートすると、そのコントローラによってサービスが提供されなくなる可能性があり、もう一方のコントローラにも障害が発生した場合に使用できなくなる可能性があります。

回避策：コントローラに障害が発生し、HA が起動されたら、失敗したコントローラをリブートした後に、デプロイを確認して、両方のコントローラでサービスが提供されていることを確認してください。VMware Integrated OpenStack のデプロイの開始と停止については、VMware ナレッジベースの記事 KB2148892 を参照してください。

ゲートウェイなしのオプションを設定して作成されたサブネット上でメタデータサービスにアクセスできない
NSX 6.2.2 以前を使用するデプロイでは、no-gateway ネットワークがサポートされません。エッジでルーティングされるネットワークには Edge が使用され、VDR ネットワークには DHCP が使用されます。NSX 6.2.3 以降を使用するデプロイでは、no-gateway または no-dhcp ネットワークがサポートされません。すべての DHCP ネットワークには DHCP が使用され、DHCP 以外のネットワークには Edge が使用されます。2.x では、Edge 仮想マシンの自動構成はオフになっています。該当する場合、DHCP はゲートウェイを設定し、メタデータはこのゲートウェイ Edge を介して提供されます。このため、 no-gateway オプションを設定してサブネットが作成された場合、メタデータトラフィックをキャプチャするルータ Edge が存在しなくなります。

回避策：ゲートウェイなしのオプションが設定されたネットワークの場合、169.254.169.254/32 に対するルートを構成して、トラフィックを DHCP Edge IP アドレスに転送します。
Firefox ブラウザでパッチファイルをアップロードする場合に問題が発生する
Firefox を使用して VMware Integrated OpenStack のパッチを更新するときに、Firefox でバージョン 19 の Adobe Flash プラグインが使用されている場合は、アップロードに失敗します。

回避策：CLI を使用してパッチを取得します。代わりのブラウザを使用するか、Firefox ブラウザの Flash プラグインを以前のバージョン（15、16、17、または 18）にリストアしてこの問題を回避することもできます。

OpenStack 管理サービスが自動的に再起動しない
特定の条件では、OpenStack 管理サービスは自動的に再起動しません。たとえば、フェイルオーバーイベントの後、すべての OpenStack サービスは正常に再起動しますが、管理サービスにはアクセスできない状態になります。

回避策：vSphere Web Client で VMware Integrated OpenStack vApp を手動で再起動します。[インベントリ] ページのアイコンを右クリックして、[シャットダウン] を選択します。すべてのサービスがシャットダウンしたら vApp をパワーオンします。OpenStack Manager のログを調べ、正常に再起動したことを確認します。

注：再起動すると、サービスが中断します。

Heat テンプレートの実行時にネットワーク作成に失敗することがある
NSX 6.2.2 を使用する VMware Integrated OpenStack デプロイで発生します。複数の Heat テンプレートの実行時に、ネットワーク作成の反復がバックエンドで失敗することがあります。

NSX 6.2.3 以降で解決されました。

リカバリ操作が「ノードはすでに存在します」という内容のエラーを返す
特定の状況では、Ansible の操作が中断されると、viocli recovery - <DB name> コマンドの実行は失敗します。その結果、データベースノードが残り、エラーの原因となります。

回避策：ノードを手動で削除し、viocli recovery コマンドを再度実行します。

LBaaS v2 移行：プールに関連付けられていない健全性監視が移行しない
LBaaS v2 では、健全性監視を指定してプールに接続する必要があります。LBaaS v1 では、健全性監視をプールの関連付けなしで作成し、別の手順でプールに関連付けることができます。

その結果、LBaaS v2 に移行するときに、関連付けられていない健全性監視が除外されます。

回避策：LBaaS v1 に移行する前に、すべての健全性監視をプールに関連付けて正常に移行することを確認します。移行プロセスは VMware Integrated OpenStack 3.0 をインストールするか VMware Integrated OpenStack 3.0 にアップグレードした後で実行するオプションです。『VMware Integrated OpenStack 管理者ガイド』を参照してください。

NSX LBaaS v2.0 テナントの制限
NSX for vSphere ロードバランサはサブネットあたり 1 つのテナントのみをサポートします。テナントはそのテナント自体のロードバランサを作成するので、通常の動作ではこれは問題になりません。ユーザーがロードバランサを作成してサブネットに接続しようとすると、ロードバランサは作成されますがエラー状態になります。

回避策：テナントがそのテナント自体のロードバランサを作成するようにします。ロードバランサを作成して既存のサブネットに接続しないでください。

Heat スタックを削除すると、「Failed to publish configuration on NSX Edge」というエラーメッセージと共に失敗する
NSX v6.2.2 を使用したデプロイで見られます。負荷の高い条件下で、Heat スタックまたは OpenStack API がバックエンドで失敗する可能性があります。

回避策：失敗した操作を再試行します。

イメージは VMX バージョン 10 以降であることが必要
この問題は、streamOptimized イメージと OVA に影響があります。たとえば、イメージが VMX-10 より低いバージョンの場合、インポートは問題なく実行できる可能性がありますが、このイメージから作成された OpenStack インスタンスは機能しません。これは通常、ESXi 5.5 などの旧バージョンの ESXi に OpenStack コンピューティングノードをデプロイする場合に発生します。また、イメージのメタデータ (vmware_hw_version) またはフレーバーのメタデータ (vmware:hw_version) を変更して、このようなイメージを修正することもできません。

vSphere HA イベント後のリカバリで同期とプロセスの起動エラーが表示される
vSphere で HA イベントが発生すると、VMware Integrated OpenStack デプロイに影響が及ぶ場合があります。リカバリ後に、VMware Integrated OpenStack で viocli deployment status -v コマンドを実行します。結果として表示されるレポートで同期またはプロセスの起動に失敗したことが示される場合は、次の回避策を使用してください。

回避策： viocli services stop コマンドを使用して、すべての OpenStack サービスを停止します。viocli services stop コマンドを使用して、すべての OpenStack サービスを再開します。再開後、viocli deployment status -v コマンドを再度実行します。これで、エラーが表示されなくなります。

RabbitMQ を開始する際に、OpenStack リカバリに失敗する場合がある
まれに、RabbitMQ の開始時に VMware Integrated OpenStack リカバリに失敗することがあります。

回避策：リカバリプロセスを繰り返します。2 度目のリカバリは正常に実行されます。

Heat スタックを削除したときに、関連付けられた Cinder ボリュームの削除に失敗する
負荷の大きい環境では、Heat スタックの削除後に Cinder ボリュームの削除が失敗し、データベースのデッドロックに関する警告が表示され、Cinder のパフォーマンスが低下することがあります。

回避策：回避策はありません。

SQL が構成されたユーザーをダッシュボードで変更できない
VMware Integrated OpenStack デプロイでユーザー認証に LDAP を使用するように構成されている場合、SQL データベースに基づいて作成された OpenStack ダッシュボード (Horizon) であっても、ユーザー定義を変更することができません。

OpenStack ダッシュボードでルーターのサイズドロップダウンメニューが表示されない
OpenStack ダッシュボード (Horizon) では、排他的なルーターを作成する際にそのサイズを指定できます。しかし、共有ルーターから排他的なルーターに変更すると、ルーターのサイズドロップダウンメニューが表示されず、ルーターのサイズを指定できません。

回避策：デフォルト値をリストアし、タイプを排他的に再度変更します。これで、ドロップダウンメニューが表示されます。
ゲートウェイが設定されていないルーターにファイアウォールを適用すると、ルールが NSX ルーターに追加されない
Firewall as a Service (FWaaS) のルールは、ゲートウェイが設定されているルーターのみに追加されます。これは、ゲートウェイが設定されていないルーターでは、保護の適用対象となる関連トラフィックがないので、これらのルールによる影響がないためです。

回避策：ルールを追加するには、ルーターにゲートウェイを設定します。
VMware NSX-T デプロイで、ゲートウェイが設定されていないルーターにファイアウォールを適用すると、ルールが NSX ルーターに追加される
ルーターにゲートウェイが設定されておらず、これらのルールに一致する関連トラフィックがない場合でも、Firewall as a Service (FWaaS) のルールがルーターに追加されます。

回避策：ルールを有効にするには、ルーターにゲートウェイを設定します。
NSX for vSphere を使用するデプロイで admin_state パラメータを更新しても変化がない
Nova ポートの admin_state パラメータを False に更新しても、このパラメータは NSX for vSphere でサポートされないため、変化はありません。

回避策：回避策はありません。
VMware NSX for vSphere デプロイで MDProxy ルーターにゲートウェイを接続した後、NSX Edge (MDProxy Edge) vnic0 インデックスが仮想マシンネットワークからゲートウェイネットワークポートグループに変更される
この設定の変更は、OpenStack インスタンスからの MDProxy サーバの取得中に暗黙的に発生することがあります。管理者テナントは MDProxy ルーターをゲートウェイに接続することが可能になり、これにより OpenStack インスタンスからのメタデータサーバのアクセスを妨げることになります。

回避策：MDProxy ルーターにゲートウェイを接続しないでください。
VMware Integrated OpenStack 4.0 へのアップグレードを行うと、「ssh_exchange_identification: Connection closed by remote host」または「Can’t connect to MySQL server」というエラーメッセージが ansible.log に記録され、失敗する場合がある
ネットワーク遅延やリソースの競合など、インフラストラクチャに障害が発生したことが原因でアップグレードが完了しない場合があります。

回避策：vSphere Web Client で [アップグレードの続行] をクリックして、アップグレードを再試行します。
Object Storage ユーザー、サービス、およびエンドポイントの作成のドキュメントで誤ったコマンドが記載されている
Object Storage ユーザー、サービス、およびエンドポイントの作成の手順 3. で次のコマンドが記載されています。keystone service-create.これは誤ったコマンドであり、次のようなエラーが帰ってきます。keystone: command not found.

回避策：Keystone CLI は廃止されたため、keystone service-create は無効になりました。次のコマンドに置き換えます。openstack service create.バージョン 4.1 に対応して更新された Object Storage ユーザー、サービス、およびエンドポイントの作成を参照してください。
BGP テナントネットワークがサービスゲートウェイ Edge から消失する
BGPSpeaker とサービスゲートウェイ間の BGP ピア設定を確立した後、Neutron コマンド neutron bgp-speaker-network-remove を実行して BGPSpeaker と外部ネットワークまたはプロバイダネットワークの関連付けを解除すると、サービスゲートウェイ上のテナントルートが失われることがあります。neutron bgp-speaker-network-add を実行して BGPSpeaker に対して外部ネットワークまたはプロバイダネットワークをリストアしても、問題は解消しません。この問題は、Neutron コマンドセットによって、ECMP フラッグの切り替えと BGP の設定が同時にトリガされることが原因で発生します。

回避策：ecmp_wait_time パラメータのデフォルト値である 2 秒が十分ではないことが考えられるため、5 秒に増やす必要があります。この変更により、再度 bgp-speaker-network-remove、bgp-speaker-add の順に実行すると、消失したルートが復旧されます。nsxv.ini ファイルで、このプロパティ値を変更します。
Nova サーバとメタデータエージェントの HTTP 通信でセキュリティ上のリスクが生じる
エッジアプライアンス上に配置されたメタデータエージェントはリバースプロキシとして動作し、アップストリームの Nova サーバに接続して、OpenStack 上の NSX 環境に関するメタデータ情報を収集します。nginx リバースプロキシ構成では、プレーンテキスト通信もサポートしています。TLS 暗号化が使用されないため、秘密データが漏えいする危険性があり、サイトから転送中のデータがネットワーク上の攻撃者に改ざんされる恐れもあります。

回避策：HTTP の代わりに、認証局 (CA) サポートのある HTTPS を使用すると、MDProxy と Nova サーバ間のセキュアな通信が可能になります。次の手順を実行してください。
1. nova.conf に次のパラメータを追加することで、Nova メタデータの HTTPS サポートが有効になります。
  
  [DEFAULT] enabled_ssl_apis = metadata [wsgi] ssl_cert_file = <nova metadata https server certificate file path> ssl_key_file = <nova metadata https server private key file path>
2. NSX Manager にログインして、[システム] > [信頼] > [証明書] に移動し、必要に応じて CA 証明書または証明書のチェーンをインポートし、証明書の UUID を記録します。
3. REST コールを使用して、HTTPS MDProxy サービスを作成します。
  1. 次の形式を使用して、https_mdproxy.json ファイルを準備します。
    
    https_mdproxy.json の json 形式は次の通りです。 { "display_name" : "https_md_proxy", "resource_type" : "MetadataProxy", "metadata_server_url" : "https://10.117.5.179:8433", "metadata_server_ca_ids": ["4574853e-e312-4b02-a1c1-002b570c2aa8","940251c9-3500-4bcd-9761-b49d0c2a95d1"], "secret": "123", "edge_cluster_id" : "00aaf00d-a8ba-42b6-a3bf-9914c8567401" }
  2. REST を呼び出し、CA を使用する HTTPS MDProxy サービスを 1 つ導入し、NSX Manager によって、
    
    201 CREATE success のステータスが返されるのを待ちます。curl -i -k -u <nsx-mgr-admin:nsx-mgr-passwd> -H "content-type: application/json" -H "Accept: application/json" -X POST https://<nsx-mgr-ip>/api/v1/md-proxies -d "`cat ./https_mdproxy.json`
4. mdproxy サービスの UUID を記録して、この MDProxy サービスを VMware Integrated OpenStack メタデータプロキシサービスとして使用します。これで、証明書認証を備えた HTTPS により、MDProxy と Nova サーバ間の通信が保護されます。
NSX-T デプロイで router-gateway-set の実行中、新たに作成された Tier-0 ルーターが Tier-1 ルーターに接続されない
Tier-0 ルーターが構成されている場合、新たに作成したルーターの UUID は nsxv3.ini ファイルに自動的に入力されません。新たに作成した Tier-1 ルーターが、新しい Tier-0 ルーターに接続されません。この問題を修正するには、nsxv3.ini ファイルを手動で更新して、外部ネットワークを再作成する必要があります。
回避策：この問題を解決するには次の手順を実行します。
1. 新しい Tier-0 ルーターの UUID を取得します。
2. /etc/neutron/plugin/vmware/nsxv3.ini ファイルを開き、Tier-0 ルーターの UUID を更新します。
3. Neutron サーバを再起動します。
4. 既存の外部ネットワークを削除して、新しい外部ネットワークを作成します。
BGP 対応の共有ルーターのゲートウェイを削除すると、他の BGP 対応の共有ルーターで一時的にネットワークが停止する場合がある
共有ルーターの場合は、同一のエッジで複数のルーターをホストできます。これらのルーターのいずれかのゲートウェイ IP アドレスが、BGP で router id として使用されます。このルーターのゲートウェイが削除されると、プラグインによって他の BGP 対応ルーターのゲートウェイ IP アドレスが router id として選択され、そのフィールドが変更されます。このプロセスでは、このエッジでホストされている他のすべての BGP ルーターで、通知されたルートが失われるため、ピア設定が中断されます。ピア設定を再度確立すれば、これが復元されます。

回避策：回避策はありません。この問題を回避するには、排他的ルーターを使用してください。
Neutron で NSX ポリシーを有効にした後、テナントのトラフィックがブロックされることがある
Neutron プラグインで security-group-policy を有効にした後、NSX ファイアウォールのセクションの順序が誤っている場合があります。正しい順序は以下のとおりです。
1. NSX ポリシー
2. テナントのセキュリティグループ
3. デフォルトセクション
回避策：VMware Integrated OpenStack を構成する前に、まず NSX ポリシーを作成します。すでに構成している場合、vSphere Web Client の [NSX ファイアウォール] ページに移動して、このポリシーのセクションを上に移動します。

VMware Integrated Openstack with Kubernetes

Software-Defined Data Center (SDDC) プロバイダを使用して、VMware Integrated OpenStack with Kubernetes 仮想マシンのパワーサイクルを実行すると、OpenStack サービスコンテナが動作を停止し、自動的に再起動されない
VMware Integrated OpenStack with Kubernetes 仮想マシンに 1 つの SDDC プロバイダが展開されており、たとえば ESXi ホストの問題に対処するために、この仮想マシンをパワーオフし、再度オンにすると、仮想マシンが別のホストに移行されます。これ以降、Kubernetes クラスタの作成やスケールアウトなどの操作をプロバイダ上で実行すると失敗します。

回避策：プロバイダを更新するには、次の手順を実行します。
1. VMware Integrated OpenStack with Kubernetes 仮想マシンで、OVA の展開時に設定したパスワードを使用して、root としてログインします。
  vkube login --insecure
2. SDDC プロバイダ ID を取得します。
  vkube provider list --insecure
3. このプロバイダ ID を使用して、SDDC プロバイダを更新します。
  vkube provider refresh sddc <provider_id> --insecure
管理者パスワードを変更した後、ユーザーはユーザーとグループを一覧表示できない
キャッシュ済みの管理者パスワードが、新しい管理者パスワードと同期されません。

回避策：キャッシュ済みの管理者パスワードを更新するには、VMware サポートから update_admin_pwd スクリプトを入手します。次に、update_admin_pwd を実行し、各クラスタで vkube cluster update を実行します。
ユーザーインターフェイスに SDDC クラウドプロバイダの vSphere クラスタが表示されない
ユーザーインターフェイスで SDDC クラウドプロバイダを作成し、ルート CA ファイルをアップロードする場合、[vSphere クラスタ] ページにクラスタが表示されません。これは、証明書の検証プロセスにおけるバグが原因で発生します。この問題は、信頼されている認証局によって承認された証明書を使用して vCenter Server を保護している場合、あるいは vCenter Server 証明書の検証を無視する場合には発生しません。

回避策：次のいずれかのタスクを実行します。
- 信頼されている認証局によって承認された証明書を使用して vCenter Server を保護してから、SDDC クラウドプロバイダを作成します。
- vCenter Server 証明書の検証を無視します。これは、安全なインストール環境を維持するためには推奨されません。
- CLI を使用して、SDDC クラウドプロバイダを作成し、CLI ペイロードで vcenter_certificate プロパティとしてルート CA ファイルを渡します。
プロバイダ名を入力した後も、ユーザーインターフェイスでプロバイダ名を要求される
SDDC または OpenStack クラウドプロバイダを作成する際に、[プロバイダの追加] ウィザードでプロバイダ名を指定したにもかかわらず、「プロバイダ名が必要です」という内容のエラーメッセージがユーザーインターフェイスに表示されます。

回避策：この問題は、特定バージョンのブラウザでユーザーインターフェイスを初めて読み込む際に発生します。この問題を回避するには、このブラウザタブを閉じます。その後、新しいタブを開いて、仮想アプライアンスに再度接続します。
ユーザーインターフェイスでファイルをアップロードする際に、「{0} 個のファイルのみがサポートされます」という内容のエラーメッセージが表示される
このエラーメッセージは、誤ったファイルタイプがアップロードされると、ユーザーインターフェイスに表示されます。これは、次のいずれかの場合に発生します。
- クラウドプロバイダまたはクラスタを作成する際に、作成プロセスですでにダウンロードしたペイロードファイルをアップロードした場合。
- SDDC クラウドプロバイダまたは OpenStack プロバイダを作成する際に、CA 証明書ファイルをアップロードした場合。
回避策：それぞれの状況に応じて、次の回避策を適用します。
- ペイロードファイルをアップロードする場合、ペイロードファイルの拡張子が .json であり、有効な JSON コンテンツがファイルに記載されていることを確認します。
- CA 証明書をアップロードする場合、証明書ファイルの拡張子が .crt であることを確認します。
SDDC クラウドプロバイダを作成すると、「dpkg: unrecoverable fatal error, aborting:」というエラーメッセージと共に失敗する
SDDC クラウドプロバイダを作成すると、仮想アプライアンス上の column-api コンテナのログにエラーメッセージが記録され、失敗します。記録されるメッセージは次のようなものです。

- docker logs column-api -fTASK [bootstrap-os : Bootstrap | Install python 2.x and pip] *******************172.18.0.2 - - [06/Sep/2017 05:47:32] "GET /runs/46a74449-7123-4574-90c2-3404dfac6641 HTTP/1.1" 200 -fatal: [k8s-node-1-2393e79d-ec6a-4e63-8f63-c6308d72496e]: FAILED! => {"changed": true, "failed": true, "rc": 100, "stderr": "Shared connection to 192.168.0.3 closed.", "stdout": "........"dpkg: unrecoverable fatal error, aborting:", " files list file for package 'python-libxml2' is missing final newline", "E: Sub-process /usr/bin/dpkg returned an error code (2)"]}"

回避策：このエラーは、SDDC クラウドプロバイダの作成中にファイルが破損した結果、発生します。SDDC クラウドプロバイダを削除し、再度作成します。

リリース ノートの概要