VMware Integrated OpenStack 4.1.2.3 リリース ノート

VMware Integrated OpenStack 4.1.2.3 | 2019 年 8 月 29 日 | ビルド 14459238 リリース ノートに追加または更新された内容をご確認ください。

リリース ノートの概要

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

• VMware Integrated OpenStack について
• 互換性
• バージョン 4.1.2.3 へのアップグレード
• 利用可能な言語
• VMware Integrated OpenStack 用オープン ソース コンポーネント
• 解決した問題
• 既知の問題

VMware Integrated OpenStack について

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

互換性

VMware Integrated OpenStack と vSphere コンポーネントなどの他の VMware 製品との互換性の詳細については、VMware 製品の相互運用性マトリックスを参照してください。

バージョン 4.1.2.3 へのアップグレード

VMware Integrated OpenStack 4.1.2.3 へのアップグレードはパッチ プロセスになります。このプロセスは、現在インストールされている VMware Integrated OpenStack のバージョンにより異なります。

パッチ プロセス

VMware Integrated OpenStack 4.1、4.1.1、4.1.2、4.1.2.1、または 4.1.2.2 を実行している場合は、既存のデプロイに対してパッチを直接適用することができます。これを行うには、次の手順を実行します。

1. OpenStack デプロイが実行中であるか、まだデプロイされていないことを確認します。VMware Integrated OpenStack のデプロイがこれらのいずれの状態でもない場合、アップグレードは失敗します。
   注：バージョン 4.1.0 にパッチを適用する場合で、かつ OpenStack をまだデプロイしていない場合は、viopatch install コマンドを 2 回実行する必要があります。1 回目にこのコマンドを実行した際にエラーが表示されても、これを無視してもう一度コマンドを実行してください。

2. vSphere Web Client で OpenStack 管理サーバ仮想マシンのスナップショットを作成します。

3. OpenStack 管理サーバ仮想マシンで次のコマンドを実行してスナップショットを作成します。
   sudo viopatch snapshot take
   このコマンドを実行すると、OpenStack サービスは停止します。パッチをインストール後にサービスが再開します。
   注：このコマンドが失敗する場合は、「既知の問題」のセクションにある「リモートの vCenter Server を使用するデプロイで、スナップショットを取得するための viopatch コマンドが失敗する」を参照してください。

4. OpenStack 管理サーバ仮想マシンにパッチ ファイルをダウンロードします。

5. 次のコマンドを実行して、パッチ ファイルを追加します。
   sudo viopatch add -l path/vio-patch-4.1.2.3_4.1.2.14459238_all.deb

6. 次のコマンドを実行して、パッチ ファイルをインストールします。
   sudo viopatch install -p vio-patch-4.1.2.3 -v 4.1.2.14459238
   注：パッチ プロセスの実行中に、インフラストラクチャ サービスが再起動します。
   パッチのインストール中に、API エンドポイントは自動的にオフになります。したがって、インストール中に API 呼び出しが発生した場合は、503 エラーが返されます。

7. vSphere Web Client からログアウトしてから再度ログインします。ログイン中に発生したエラー メッセージは無視して構いません。

注：viopatch uninstall アクションはサポートが終了しています。これを使用して以前のバージョンに戻すことはできません。したがって、バージョンを元に戻すにはこのパッチ プロセスで作成されたスナップショットが必要になります。すべての確認タスクが完了し、以前のバージョンに戻す必要がないことを確認するまでは作成したスナップショットを削除しないでください。

パッチを適用したバージョンが正しく動作していることを確認したら、sudo viopatch snapshot remove を実行してスナップショットを削除できます。このアクションは元に戻すことはできません。

パッチをインストールした後で以前のバージョンに戻す必要が生じた場合は、次の手順を実行します。

1. OpenStack 管理サーバ仮想マシンで次のコマンドを実行して以前のスナップショットに戻します。
   sudo viopatch snapshot revert

2. vSphere Web Client で OpenStack 管理サーバ仮想マシンを以前のスナップショットに戻します。

3. OpenStack 管理サーバ仮想マシンで次のコマンドを実行して、OpenStack サービスを再起動します。
   sudo service oms restart

4. vCenter Server 仮想マシンで vSphere Client サービスを停止し、保存されているファイルを削除してサービスを再起動します。

   • vSphere 6.5 以降の場合は、次のコマンドを実行します。
     service-control --stop vsphere-client
cd /etc/vmware/vsphere-client/vc-packages/vsphere-client-serenity/
rm -rf *
cd /usr/lib/vmware-vsphere-client/server/work
rm -rf *
service-control --start vsphere-client

   • vSphere 6.0 の場合は、次のコマンドを実行します。
     service vsphere-client stop
cd /etc/vmware/vsphere-client/vc-packages/vsphere-client-serenity/
rm -rf *
service vsphere-client start

   • vSphere 5.5 の場合は、次のコマンドを実行します。
     service vsphere-client stop
cd /var/lib/vmware/vsphere-client/vc-packages/vsphere-client-serenity/
rm -rf *
service vsphere-client start

5. vSphere Web Client からログアウトし、再度ログインします。

以前のバージョン

VMware Integrated OpenStack 4.0 から VMware Integrated OpenStack 4.1.2.3 にアップグレードするには、次の手順を実行します。

1. 「VMware Integrated OpenStack のパッチ適用」の手順に沿って、VMware Integrated OpenStack 4.1 へのアップグレードを実行します。
2. 上記の手順に沿って VMware Integrated OpenStack 4.1.2.3 パッチを適用します。

注：VMware Integrated OpenStack 3.1 から 4.1.2.1 以降への直接のアップグレードはサポートされていません。最初にバージョン 4.1.2 に移行してから、目的のバージョンにパッチを適用する必要があります。

VMware Integrated OpenStack 3.1 から VMware Integrated OpenStack 4.1.2.3 にアップグレードするには、次の手順を実行します。

1. 「新しいバージョンのインストール」の手順に沿って、VMware Integrated OpenStack 4.1 OVA をデプロイします。
2. 新しい 4.1 デプロイでは、VMware Integrated OpenStack 4.1.2 リリース ノートに記載されているように、VMware Integrated OpenStack 4.1.2 のパッチを適用します。
3. 「新しい VMware Integrated OpenStack デプロイへの移行」の手順に沿って、パッチを適用したデプロイ環境に移行します。
4. 上記の手順に沿って VMware Integrated OpenStack 4.1.2.3 パッチを適用します。

注：送信元 NAT が無効なルーター上でフローティング IP アドレスを設定した場合は、バージョン 4.1.2.3 にアップグレードする前に、送信元 NAT を有効にするか、フローティング IP アドレスを削除してください。フローティング IP アドレスは、送信元 NAT が無効なルーターではサポートされなくなりました。

利用可能な言語

VMware Integrated OpenStack 4.1.2.3 は英語、および簡体字中国語、繁体字中国語、日本語、韓国語、フランス語、ドイツ語、スペイン語の 7 つの追加言語でご利用になれます。

次の項目には ASCII 文字のみを含める必要があります。

• OpenStack リソース（プロジェクト、ユーザー、イメージなど）の名前
• インフラストラクチャ コンポーネント（ESXi ホスト、ポート グループ、データセンター、データストアなど）の名前
• LDAP および Active Directory の属性

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

VMware Integrated OpenStack 4.1.2.2 で配布されるオープン ソース ソフトウェア コンポーネントに適用される著作権情報とライセンスは、製品ダウンロード ページの [オープン ソース] タブで入手できます。VMware Integrated OpenStack のコンポーネントの公開パッケージをダウンロードすることもできます。これらのコンポーネントは GPL、LGPL、または他の同様なライセンスで管理されており、ライセンスに沿ってソース コードまたはソース コードの変更内容を公開する必要があります。

解決した問題

• custom.yml ファイルへの追加パラメータ。

  次の項目を custom.yml で構成できるようになりました。

  • cinder_vmware_image_transfer_timeout_secs - Cinder と Glance 間の VMDK ボリューム転送に、タイムアウトを秒単位で設定します。
• vSphere の仮想マシンからインターフェイスを削除すると、OpenStack でその論理ポートを削除することができない

  vSphere を使用して OpenStack インスタンスに対応する仮想マシンからインターフェイスを削除すると、OpenStack はそのインターフェイスの Neutron ポートを接続解除できなくなります。

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

• インスタンスのディスク サイズの変更に失敗すると、そのインスタンスでの以降のディスク サイズ変更操作が失敗することがある

  ディスク サイズ変更操作が失敗した後、古いディスクがインスタンスに残ることがあります。これにより、この後のサイズ変更操作が失敗します。

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

• 仮想マシン上の同時操作が失敗することがある

  OpenStack 操作と vSphere 操作を同じ仮想マシンで同時に実行すると、OpenStack の操作が失敗することがあります。

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

• DRS の競合により、OpenStack インスタンスを起動できないことがある

  インスタンスの起動中に DRS の競合が発生した場合、ポートがクリーンアップされず、起動プロセスがタイムアウトになることがあります。

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

• シリアル コンソールのログ ローテーションが行われず、ディスク容量が過剰に占有されることがある。

  コンピュート ノードの /var/log/vspc ディレクトリにある、仮想シリアル ポート コンセントレータ (vSPC) によって生成されたログ ファイルのローテーションが行われず、その結果、大量のディスク容量を使用することがあります。

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

既知の問題

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

• VMware Integrated OpenStack
• VMware Integrated Openstack with Kubernetes

VMware Integrated OpenStack

• インスタンスとシャドウ仮想マシンを別のアベイラビリティ ゾーンに移行すると、このボリュームのアベイラビリティ ゾーンが適切に更新されない。

  シャドウ仮想マシンが帯域外に移行されるため、移行中にボリュームのアベイラビリティ ゾーンが自動的に変更されません。

  回避策：アベイラビリティ ゾーンを手動で更新します。

  1. コントローラ ノードに viouser としてログインします。
  2. 次のコマンドを実行します。
     sudo -u cinder cinder-manage volume update_volume_host --volume_id volume-uuid --newhost cinder-volume-host --zone az-name
• NSX-T パスワードを変更した後に、VMware Integrated OpenStack が NSX-T に接続できない。

  Neutron サーバの実行中に NSX-T パスワードを変更すると、VMware Integrated OpenStack が NSX-T に接続できなくなることがあります。

  回避策：NSX-T パスワードを変更する前に、アクティブ コントローラ ノードにログインし、systemctl stop neutron-server コマンドを実行して Neutron サーバのサービスを停止します。VMware Integrated OpenStack で NSX-T パスワードを更新すると、サービスが再起動されるようになります。

• リモートの vCenter Server を使用するデプロイで、スナップショットを取得するための viopatch コマンドが失敗する

  すべてのコントロール仮想マシンが管理 vCenter Server インスタンス内にデプロイされ、リモート vCenter Server インスタンス内にデプロイされた Nova コンピューティング ノードを使用する環境では、viopatch snapshot take コマンドを実行しても、管理 vCenter Server インスタンスに関する情報を取得できません。このコマンドは、「属性エラー: 'NoneType' オブジェクトに 'snapshot' 属性がありません」というエラーと共に失敗します。

  回避策：OpenStack 管理サーバ仮想マシンで次のコマンドを実行し、管理 vCenter Server の IP アドレス、ユーザー名、パスワードを手動で設定します。

  export VCENTER_HOSTNAME = mgmt-vc-ip-address export VCENTER_USERNAME = mgmt-vc-username export VCENTER_PASSWORD = mgmt-vc-password

• OpenStack GUI が、パブリック仮想 IP アドレスの元の値のみをエクスポートする。

  パブリック仮想 IP アドレスを変更し、VMware Integrated OpenStack または OpenStack の構成をエクスポートしてセットアップに再ロードすると、エクスポートした構成には更新されたパブリック仮想 IP アドレスではなく、元の構成のパブリック仮想 IP アドレスが含まれています。

  回避策：エクスポートおよび保存された構成ファイル中のパブリック仮想 IP アドレスを更新してから、OpenStack 設定を再ロードします。あるいは、再デプロイを確定する際に GUI でパブリック仮想 IP アドレスを更新します。

• パブリック ロード バランサの IP アドレスが OpenStack API アクセス ネットワークと競合する。

  パブリック ロード バランサの IP アドレスを GUI を使用して設定しなかった場合、OpenStack API アクセス ネットワークと重複することがあります。設定をエクスポートして OpenStack または VMware Integrated OpenStack のセットアップに再適用すると、IP アドレスの重複が許容されなくなります。

  回避策：IP アドレスを指定または設定するときに、パブリック ロード バランサの IP アドレスが OpenStack API アクセス ネットワークと重複していないことを確認します。

• ロード バランサが ERROR 状態になる。

  tier-1 ネットワーク ルーターに接続されていないサブネットを使用してロード バランサを作成すると、ロード バランサが正しく作成されず、ERROR 状態になります。

  回避策：tier-1 ネットワーク ルーターをサブネットに接続してからロード バランサを作成します。

• OpenStack 管理サーバで証明書の検証に失敗することがある。

  viocli コマンドライン ユーティリティを使用すると、次のエラーが発生することがあります。

  ssl.SSLError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:590)

  回避策：OpenStack 管理サーバで、次のコマンドを実行して vCenter Server の証明書の検証を無効にします。

  sudo su - export VCENTER_INSECURE=True

• BGP が有効な共有ルーターのゲートウェイを削除すると、BGP が有効な他の共有ルーターで一時的にネットワークが停止する場合がある。

  共有ルーターを使用する環境では、複数のルーターを同じエッジでホストできます。BGP が有効な場合、それらのルーターのいずれかのゲートウェイ IP アドレスが router id として使用されます。そのルーターのゲートウェイが削除されると、プラグインは BGP が有効な別のルーターのゲートウェイを router id の新しい値として選択します。このプロセスでは、そのエッジでホストされ BGP が有効な他のルーターの通知ルートが失われるため、ピアリングが一時的に中断されます。

  回避策：排他的なルーターを使用します。

• Nova または Neutron サービスの更新中にサービスの中断が発生する。

  VMware Integrated OpenStack は、OpenStack の設定にライセンス要件に準拠しない設定を検出すると、Nova または Neutron サービスを再起動して設定を修正します。

  回避策：なし。OpenStack のデプロイを行う前にライセンスを割り当て、OpenStack の設定がライセンス要件を満たしていることを確認してください。

• 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. 既存の外部ネットワークを削除して、新しい外部ネットワークを作成します。
• ルーター インターフェイスの削除がタイムアウトになる。

  共有 NSX ルーターを使用して同時実行 Heat スタックがデプロイされている場合、ルーター インターフェイスの削除がタイムアウトになることがあります。次のメッセージが表示される可能性があります。neutron_client_socket_timeout、haproxy_neutron_client_timeout、または haproxy_neutron_server_timeout。

  回避策：ネットワーク リソースが頻繁に変更される環境では、共有ルーターを使用しないでください。NAT/FIP が必要な場合は、排他的ルーターを使用します。それ以外の場合は、分散ルーターを使用します。

• NSX-V デプロイで、ゲートウェイをメタデータ プロキシ ルーターに接続すると、OpenStack デプロイがメタデータ サーバにアクセスできなくなる。

  ゲートウェイをメタデータ プロキシ ルーターに接続すると、NSX Edge vnic0 インデックスが仮想マシン ネットワークからゲートウェイ ネットワーク ポート グループに変わります。これにより、OpenStack デプロイからのメタデータ サーバへのアクセスが妨げられる可能性があります。

  回避策：メタデータ プロキシ ルーターにゲートウェイを接続しないでください。

• NSX-T デプロイで、ゲートウェイが設定されていないルーターにファイアウォールを適用すると、ファイアウォール ルールが NSX ルーターに追加される。

  ルーターにゲートウェイが設定されておらず、これらのルールに一致する関連トラフィックがない場合でも、Firewall as a Service (FWaaS) のルールがルーターに追加されます。

  回避策：ルールを有効にするには、ルーターにゲートウェイを構成します。

• 「有効なホストが見つかりません」というエラーと共に Nova インスタンスが起動に失敗する。

  システムの負荷が高い状況では tenant_vdc プロパティを使用してインスタンスを起動すると、失敗することがあります。

  回避策：システムの負荷が低い状態でインスタンスを起動してください。

• BGP テナント ネットワークがサービス ゲートウェイ Edge から消失する。

  BGP スピーカとサービス ゲートウェイ間の BGP ピアリングを確立した後、neutron bgp-speaker-network-remove コマンドを実行して BGP スピーカと外部ネットワークまたはプロバイダ ネットワークの関連付けを解除すると、サービス ゲートウェイ上のテナント ルートが失われることがあります。neutron bgp-speaker-network-add を実行して BGP スピーカに対して外部ネットワークまたはプロバイダ ネットワークをリストアしても、ルートは再作成されません。

  回避策：nsxv.ini ファイルで、ecmp_wait_time の値を 5 秒に変更します。

• DLR テナント エッジ (PLR) とプロバイダ ゲートウェイ エッジ間で iBGP ピアリングを行うと、テナント ネットワークが適切に通知されず、外部との通信が切断される。

  iBGP ピアリングを使用すると、ネクスト ホップは変更されず、ピアに通知ルートがインストールされます。結果的に、プロバイダ ゲートウェイ エッジは、テナントの PLR エッジのアップリンクではなく、「トランジット ネットワーク」の範囲にネクスト ホップの IP アドレスを持つテナント ネットワーク間のルートをインストールします。ゲートウェイ エッジがトランジット ネットワークへのルートを解決できないため、通信は遮断されます。

  回避策：分散ルーターの操作時には、eBGP ピアリングを使用します。

• NSX-V デプロイに対して、admin_state パラメータが反映されない。

  Nova ポートの admin_state パラメータを False に変更しても反映されません。このパラメータは、NSX-V ではサポートされていません。

  回避策：なし。

• クラウド サービス ルーターに IP アドレスのみが含まれ、FQDN がない。

  VMware Integrated OpenStack のデプロイ時に、ロード バランサ設定でパブリック ホスト名が指定されていないか、パブリック アクセスの要件に準拠していませんでした。パブリック ホスト名は VMware Integrated OpenStack ダッシュボードまたは API への外部アクセスに使用されます。

  回避策：デプロイ後にパブリック ホスト名を変更または編集するには、KB 2147624 を参照してください。

• ゲートウェイが設定されていないルーターにファイアウォールを適用しても、ファイアウォールのルールが NSX ルーターに追加されない。

  Firewall as a Service (FWaaS) のルールは、ルーターにゲートウェイが設定されている場合にのみ追加できます。これらのルールには関連トラフィックが存在しないため、ゲートウェイが設定されていないルーターでは有効になりません。

  回避策：ファイアウォールを適用する前に、ルーターのゲートウェイを設定します。

• Nova サーバとメタデータ エージェントの HTTP 通信でセキュリティ上のリスクが生じる。

  エッジ アプライアンス上のメタデータ エージェントはリバース プロキシとして動作し、アップストリームの Nova サーバと通信して、OpenStack 上の NSX 環境に関するメタデータ情報を収集します。nginx リバース プロキシ構成では、プレーンテキスト通信もサポートしています。TLS 暗号化が使用されないため、秘密データが漏えいする危険性があり、サイトから転送中のデータがネットワーク上の攻撃者に改ざんされる恐れもあります。

  回避策：HTTP の代わりに、認証局 (CA) サポートのある HTTPS を使用すると、メタデータ プロキシ サーバと Nova サーバ間のセキュアな通信が可能になります。

  1. nova.conf に次のパラメータを追加することで、Nova メタデータの HTTPS サポートが有効になります。

     [DEFAULT] enabled_ssl_apis = metadata [wsgi] ssl_cert_file = nova-md-https-server-cert-file ssl_key_file = nova-md-https-server-private-key-file

  2. NSX Manager で、[システム] > [信頼] > [証明書] の順に選択し、CA 証明書または証明書のチェーンをインポートします。インポートした証明書の UUID を記録します。
  3. 次の形式を使用して、https_mdproxy.json ファイルを準備します。 

     { "display_name" : "https_md_proxy", "resource_type" : "MetadataProxy", "metadata_server_url" : "https://md-server-url", "metadata_server_ca_ids": ["ca-id"], "secret": "secret", "edge_cluster_id" : "edge-cluster-id" }

  4. REST API を使用して、HTTPS メタデータ プロキシ サーバをデプロイします。

     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`"

  5. 作成されたメタデータ プロキシ サーバの UUID を使用して、VMware Integrated OpenStack を構成します。これで、証明書認証を備えた HTTPS により、メタデータ プロキシ サーバと Nova サーバ間の通信が保護されます。
• ポリシー ファイルのカスタマイズが VMware Integrated OpenStack ダッシュボードに同期されない。

  GUI では、カスタムのプレイブックで指定されたポリシーの変更が反映されません。

  回避策：ポリシー ファイルを編集する際にカスタムのプレイブックを使用した場合は、整合性の確保のため、VMware Integrated OpenStack ダッシュボードのポリシー ファイルにも同様の変更を加えます。

• Neutron で NSX ポリシーを有効にした後で、テナント トラフィックがブロックされることがある。

  Neutron プラグインで security-group-policy を有効にした後、NSX ファイアウォール セクションが誤った順序でリストされることがあります。正しい順序は次の通りです。

  1. NSX ポリシー
  2. テナント セキュリティ グループ
  3. デフォルト セクション

  回避策：vSphere Web Client で、NSX ファイアウォール ページを開いてからセクションを正しい位置に移動します。この問題の発生を防止するには、VMware Integrated OpenStack の構成を行う前に、最初の NSX ポリシーを作成します。

• VMware Integrated OpenStack ダッシュボードにルーターのサイズ ドロップダウン メニューが表示されない。

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

  回避策：ルーターをデフォルト値に戻し、もう一度タイプを排他的に変更します。これで、ドロップダウン メニューが表示されます。

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

  回避策：なし。

• vSphere HA イベント後のリカバリで同期とプロセスの起動エラーが表示される。

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

  回避策：viocli services stop コマンドを実行し、その後に viocli services start コマンドを実行して、すべての OpenStack サービスを手動で再起動します。OpenStack サービスが再開したら、viocli deployment status コマンドをもう一度実行してエラーがないことを確認します。

• イメージが VMX バージョン 10 以降である必要がある。

  この問題は、ストリーム最適化イメージと OVA に影響があります。イメージのハードウェア バージョンが VMX 10 より前の場合、このイメージから作成された OpenStack インスタンスは機能しません。これは通常、ESXi 5.5 などの旧バージョンの ESXi に OpenStack コンピューティング ノードをデプロイする場合に発生します。イメージのメタデータ (vmware_hw_version) またはフレーバーのメタデータ (vmware:hw_version) を変更して、このようなイメージを修正することはできません。

  回避策：新しいイメージを使用します。

• no-gateway オプションを設定して作成されたサブネット上でメタデータ サービスにアクセスできない。

  no-gateway オプションを設定してサブネットが作成された場合、メタデータ トラフィックをキャプチャするルーター Edge が存在しません。

  回避策：no-gateway オプションが設定されたネットワークの場合、169.254.169.254/32 に対するルートを構成して、トラフィックを DHCP Edge IP アドレスに転送します。

• コントローラ仮想マシンが再起動すると、高可用性が損なわれることがある。

  コントローラが高可用性のセットアップに失敗すると、2 番目のコントローラが引き続きサービスを提供します。ただし、最初のコントローラが再起動すると、2 番目のコントローラでサービスの提供が開始されないことがあります。2 番目のコントローラが失敗すると、環境は最初のコントローラに切り替えられなくなります。

  回避策：高可用性のセットアップで失敗したコントローラを再起動した後、環境で両方のコントローラがサービスを提供していることを確認します。VMware Integrated OpenStack のデプロイの開始と停止については、VMware ナレッジベースの記事 KB2148892 を参照してください。

• Glance でデータストア名に特殊文字がサポートされていない。
  データストア名に英数字以外の特定の文字が使用されている場合、そのデータストアを Glance サービスに追加することができません。コロン (:)、カンマ (,)、スラッシュ (/)、ドル記号 ($) は別の目的のために予約されているため、Glance データストア名には許可されていません。
  
  回避策：これらの記号はデータストア名に使用しないでください。

• 画像のアップロードに長時間かかると、NotAuthenticated で失敗する。
  これは OpenStack の既知の問題であり、Icehouse リリースで最初に報告されました。https://bugs.launchpad.net/glance/+bug/1371121 を参照してください。

• 接続に失敗したボリュームがダッシュボードで接続されているものとして表示されることがある。
  これは OpenStack の既知の問題であり、Icehouse リリースで最初に報告されました。

• VMware Integrated OpenStack vApp を使用してデプロイした後で、Syslog 設定を変更できない。

  デプロイが完了した後で、[VMware Integrated OpenStack] > [管理サーバ] > [設定の編集] > [vApp オプション] の順に移動して Syslog サーバの構成を変更することができません。

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

VMware Integrated Openstack with Kubernetes

• SDDC プロバイダを使用した Distributed Switch デプロイの場合、クラスタは ACTIVE として表示されるが、リカバリ後に外部ルーティングがなくなる。

  Nginx Ingress Controller ポッドがリカバリ後にエラー状態になると、外部ルーティングがなくなります。

  回避策：以下の手順を実行し、エラー状態を解消します。

  1. デフォルトのサービス アカウントと影響を受ける Nginx Ingress Controller ポッドを削除します。

     kubectl delete serviceaccount default -n kube-system kubectl delete pod nginx-ingress-controller-id -n kube-system

  2. VMware Integrated OpenStack with Kubernetes 仮想マシンで、vkube cluster update コマンドを実行します。
• 削除されたクラスタをリストアできない。

  クラスタの削除およびプロバイダの削除コマンドを実行すると、削除されたネットワーク、ルーター、ロード バランサをリカバリすることはできません。

  回避策：なし。

• Kubernetes クラスタ ノードのゲスト OS を再起動すると、flannel のポッドが適切に起動されない。

  Kubernetes クラスタ ノードのゲスト OS を再起動すると、すべての IP アドレス テーブル ルールがクリーンアップされます。結果的に、flannel のポッドが適切に起動されません。

  回避策：Kubernetes ネットワーク プロキシを再起動します。kube-proxy プロセスを強制終了すると、hyperkube が新しい kube-proxy プロセスを自動的に開始します。

• クラスタ操作を実行すると、「ポリシーが割り当てられていません」というエラーが表示される。

  専用または共有クラスタのいずれかに割り当てられたグループのメンバーであるユーザーには、kubectl ユーティリティの実行などのクラスタへの操作を実行すると、「ポリシーが割り当てられていません」と表示される場合があります。この問題は、認証されたユーザーのグループ情報が、ユーザー セッション中に適切に保存されないために発生します。

  回避策：クラスタにグループではなく個人ユーザーを割り当てます。

• 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 クラウド プロバイダを削除し、再度作成します。

• Software-Defined Data Center (SDDC) プロバイダを使用して、VMware Integrated OpenStack with Kubernetes 仮想マシンのパワー サイクルを実行すると、OpenStack サービス コンテナが動作を停止し、自動的に再起動されない。

  SDDC プロバイダが 1 つの VMware Integrated OpenStack with Kubernetes 仮想マシンをパワーオフしてから再度パワーオンすると、仮想マシンが別のホストに移行します。これ以降、Kubernetes クラスタの作成やスケールアウトなどの操作をプロバイダ上で実行すると失敗します。

  回避策：プロバイダを更新するには、次の手順を実行します。

  1. VMware Integrated OpenStack with Kubernetes 仮想マシンで、root ユーザーとしてログインします。
     vkube login --insecure
  2. SDDC プロバイダを更新します。
     vkube provider refresh sddc provider-id --insecure 

     vkube provider list --insecure コマンドを実行すると、SDDC プロバイダ ID を取得できます。