更新日:2018 年 11 月 13 日

VMware Integrated OpenStack 4.1 | 2018 年 1 月 18 日 | ビルド 7538136
VMware Integrated OpenStack with Kubernetes 4.1 | 2018 年 1 月 18 日 | ビルド 7549988

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

リリース ノートの概要

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

VMware Integrated OpenStack について

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

新機能

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

VMware Integrated OpenStack

  • 最新バージョンの VMware 製品のサポート:VMware Integrated OpenStack 4.1 は、VMware vSphere 6.5 Update 1、VMware NSX for vSphere 6.3.5、VMware NSX-T 2.1、および vSAN 6.6.1 をサポートし、これらと完全な互換性があります。
  • HTML5 vSphere Client のサポート:VMware Integrated OpenStack は、HTML5 vSphere Client バージョン 6.5.0U1、6.5.0U1b、6.5.0U1c、および 6.5.0f をサポートします。
  • 複数ドメインの LDAP バックエンド:Keystone を複数の LDAP ドメインによってバッキングできるようになり、より複雑なストラクチャと環境のサポートが可能になりました。 
  • ネイティブ NSX-T LBaaS:VMware Integrated OpenStack は、仮想マシンベースとコンテナベースの両方のワークロードに対する NSX-T ネイティブの新しいロード バランサを完全にサポートします。 
  • HAProxy の制限:HAProxy は、悪意または不注意による API オーバーロードを防止するための設定を追加して更新されました。
  • 小規模デプロイ モード:新しいデプロイ オプションの導入により、アプライアンス モデルの単一サーバへのデプロイが可能になりました。 
  • パブリック管理 API:VMware Integrated OpenStack のデプロイの自動化とライフサイクル管理に直接使用可能な OpenStack 管理サーバ API がドキュメント化され、一般的に使用できるようになりました。 

VMware Integrated OpenStack with Kubernetes

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

  • 最新バージョンの Kubernetes のサポート:VMware Integrated OpenStack 4.1 には Kubernetes バージョン 1.8.1 が含まれ、これが完全にサポートされます。
  • ログ記録の強化:ログを Syslog に準拠している任意の宛先に転送できるようになり、既存のログ管理ツールとの統合が可能になりました。
  • コンポーネントの追加:コンテナ プラットフォームに、デプロイ済みのアプリケーションの管理と監視に役立つ Helm と Heapster のサポートが追加されました。 
  • 制御プレーンのバックアップとリカバリ:このリリースには、コンテナ プラットフォームの制御プレーンのバックアップを支援するためのツールとベスト プラクティスも含まれています。 

互換性

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

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

VMware Integrated OpenStack のアップグレード

VMware Integrated OpenStack 3.1 以降から VMware Integrated OpenStack 4.1 に直接アップグレードできます。 

  • VMware Integrated OpenStack 3.1.x から VMware Integrated OpenStack 4.1 へのアップグレードについては、インストール ガイドの「Upgrade VMware Integrated OpenStack」を参照してください。
    注:送信元 NAT が無効なルーター上でフローティング IP アドレスを設定した場合は、バージョン 4.1 にアップグレードする前に、送信元 NAT を有効にするか、フローティング IP アドレスを削除してください。フローティング IP アドレスは、送信元 NAT が無効なルーターではサポートされなくなりました。
  • VMware Integrated OpenStack 4.0 から VMware Integrated OpenStack 4.1 へのアップデートについては、インストール ガイドの「Patch VMware Integrated OpenStack」を参照してください。

VMware Integrated OpenStack 3.0 以前のバージョンを実行している場合は、まずバージョン 3.1 にアップデートしてから、バージョン 4.1 にアップグレードする必要があります。 

VMware Integrated OpenStack with Kubernetes のアップグレード

VMware Integrated OpenStack with Kubernetes 4.0 から VMware Integrated OpenStack with Kubernetes 4.1 へのアップデートについては、『Getting Started with VMware Integrated OpenStack with Kubernetes』の「Upgrade VMware Integrated OpenStack with Kubernetes」を参照してください。

利用可能な言語

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

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

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

VMware Integrated OpenStack with Kubernetes は英語版のみでご利用になれます。

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

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

解決した問題

解決された問題には、次のトピックが含まれます。

VMware Integrated OpenStack
    VMware Integrated OpenStack with Kubernetes
    • GUI に SDDC クラウド プロバイダの vSphere クラスタが表示されない。

      GUI で SDDC クラウド プロバイダを作成し、ルート CA ファイルをアップロードする場合、[vSphere クラスタ] ページにクラスタが表示されません。この問題は、信頼されている認証局によって承認された証明書を使用して vCenter Server を保護している場合、あるいは vCenter Server 証明書の検証を無視する場合には発生しません。

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

    • 管理者パスワードを変更した後、ユーザーとグループを一覧表示できない。

      キャッシュ済みの管理者パスワードが、新しい管理者パスワードと同期されません。

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

    • GUI でファイルをアップロードする際に、「{0} 個のファイルのみがサポートされます」という内容のエラー メッセージが表示される。

      このエラー メッセージは、誤ったファイル タイプがアップロードされると表示されます。これは、次のいずれかの場合に発生します。

      • クラウド プロバイダまたはクラスタを作成する際に、作成プロセスですでにダウンロードしたペイロード ファイルをアップロードした場合。
      • SDDC クラウド プロバイダまたは OpenStack プロバイダを作成する際に、CA 証明書ファイルをアップロードした場合。

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

    • プロバイダ名を入力した後も、GUI でプロバイダ名を要求される。

      SDDC または OpenStack クラウド プロバイダを作成する際に、[プロバイダの追加] ウィザードでプロバイダ名を指定したにもかかわらず、「プロバイダ名が必要です」という内容のエラー メッセージが GUI に表示されます。

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

    既知の問題

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

    VMware Integrated OpenStack
    • 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 パスワードを更新すると、サービスが再起動されるようになります。

    • テナント仮想データセンターによって削除されたコンピューティング ノードを再び追加できない。

      テナント仮想データセンターでコンピューティング ノードを削除した後で、コンピューティング ノードを追加し直すと、/var/log/nova/nova-compute.log に「Failed to create resource provider」というエラー メッセージが記録されて失敗します。

      回避策:次の手順を実行して、データベースから Nova コンピューティング ノードを削除します。

      1. 削除したコンピュート ノードの MOID を検索します。
      2. アクティブ データベース ノードにログインして、nova_api データベースを開きます。

        mysql
        use nova_api

      3. 「resource_providers」テーブルで、削除したコンピューティング ノードの MOID を持つ resource_provider レコードを削除してから、そのレコードのすべての子を削除します。
    • 順序を無視してコンピューティング ノードを削除し、さらにコンピューティング ノードを追加するとエラーが発生する。

      降順でコンピューティング ノードを削除しなかった場合、後でノードを追加するとエラーが発生します。

      回避策:ノード番号の降順でノードを削除します。たとえば、VIO-Compute-0、VIO-Compute-1、VIO-Compute-2 という 3 つのコンピューティング ノードがある場合、まず VIO-Compute-2 を削除し、次に VIO-Compute-1、そして VIO-Compute-0 という順序で削除する必要があります。

    • 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 アクセス ネットワークと重複していないことを確認します。

    • HTML5 vSphere Client を使用した VMware Integrated OpenStack のデプロイが失敗する。

      HTML5 vSphere Client では、デプロイ タイプを選択せずに古いテンプレートを使用して VMware Integrated OpenStack をデプロイすると、デプロイ ウィザードの最後の手順で内部 REST API エラーが発生します。

      回避策:古いテンプレートを使用する場合は、デプロイ タイプを手動で選択します。あるいは、Flex ベースの vSphere Web Client を使用して、OpenStack をデプロイすることもできます。

    • VMware Integrated OpenStack vApp が HTML5 vSphere Client に表示されない。

      VMware Integrated OpenStack のインストール後、HTML5 vSphere Client が VMware Integrated OpenStack プラグインのロードに失敗することがあります。

      回避策:vSphere Client からログアウトし、再度ログインします。vApp が引き続き表示されない場合は、次の手順を実行して HTML5 vSphere Client を再起動します。

      1. Flex ベースの vSphere Web Client にログインします。
      2. [ホーム] > [管理] の順に選択します。
      3. ナビゲータ ツリーで、[システム設定] を選択し、[サービス] をクリックします。
      4. VMware vSphere Client を選択します。
      5. [アクション] アイコンをクリックして [再起動] を選択します。
    • ロード バランサが ERROR 状態になる。

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

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

    • 負荷が高い状態でインスタンスを起動すると失敗する。

      システムの負荷が高い状態で VMware Integrated OpenStack インスタンスをデプロイすると、Keystone で API 要求が大量に発生し、「サービスが利用できません」というエラーと共に失敗します。

      回避策:システムの負荷が低い状態でインスタンスをデプロイします。

    • 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_timeouthaproxy_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 を再起動します。

      1. すべてのバックアップ エッジを削除します。
        nsxadmin -r backup-edges -o clean --property edge-id=edge-node-id
      2. Neutron を再起動します。
    • 名前を変更した OpenStack インスタンスが vCenter Server に元の名前で表示される。

      nova rename コマンドを使用して OpenStack インスタンスの名前を変更すると、変更は OpenStack データベースにのみ表示されます。vCenter Server インスタンスには引き続き元の名前が表示されます。

      回避策:なし。

    • 分散論理ルーター上の DHCP を使用しないサブネットでメタデータにアクセスできない。

      DHCP を使用しないサブネット上のインスタンスは、分散論理ルーターのインターフェイスを介してメタデータにアクセスできません。この動作は、共有ルーターおよび排他的なルーターでは発生しません。

      回避策:なし。

    • OpenStack インスタンスをデプロイすると、「Certificate is not in CA store(証明書が CA ストアにありません)」というエラーが表示される場合がある。

      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 から新しいインスタンスの証明書をインポートするためのワークフローを実行します。
    • 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) を変更して、このようなイメージを修正することはできません。

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

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

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

    • 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
    • 仮想 IP アドレスを使用して Kubernetes API サーバにアクセスできない。

      NSX-T ネットワーク環境にある OpenStack プロバイダを使用して複数の Kubernetes クラスタをデプロイしていると、仮想 IP アドレスを使用して Kubernetes API サーバにアクセスできないことがあります。

      回避策:NSX-T バックエンド サーバにログインし、フローティング IP アドレスを使用してロード バランサの仮想サーバを更新します。

    • 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 を取得できます。

      1.  

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