VMware Integrated OpenStack 3.1.0.2 | 2017 年 10 月 24 日 | ビルド 6902555

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

リリース ノートの概要

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

VMware Integrated OpenStack について

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

利用可能な言語

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

新機能

このパッチ セットでは、3.x シリーズで以前利用できなかった 2 つのマイナーな拡張機能が導入されています。

同じノード上でリサイズを強制するフラグの追加 

一部の特殊なケースでは、リサイズを強制的に同じホスト上で実行し、ワークロードが移動しないようにすることが必要な場合があります。これに対応するため、オプションのフラグである「always_resize_on_same_host」が追加されました。 

ホスト グループのエッジ管理 

複雑性を軽減してエッジ管理の負荷を軽くするため、エッジごとに 1 つのグループではなく、アクティブおよびスタンバイのエッジに対して、2 つのグローバル グループが作成されました。また、グループ作成がアトミックになり、エッジが削除されると自動的にバッキング仮想マシンが削除されるようになりました。 

互換性

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

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

バージョン 3.1 からバージョン 3.1.0.2 にアップデートするには、既存のデプロイに 3.1.0.2 パッチ(3.1.0.2 ビルド 6902555)をインストールして適用します。

次の手順では、バージョン 3.1 がインストールされていることが前提となります。CLI コマンドを使用してパッチをインストールします。

注:バージョン 3.0.x から 3.1.0.2 にアップデートすることはできません。現在のデプロイがバージョン 3.0.x の場合は、まずバージョン 3.1 にアップデートする必要があります。「VMware Integrated OpenStack 3.1 リリース ノート」を参照してください。

パッチをインストールするには次の手順を実行します。

  1. パッチ(3.1.0.2 ビルド 6902555)を入手します。

    1. VMware Integrated OpenStack 管理サーバにログインします。

    2. パッチの Debian ファイルをダウンロードします。

    3. 次のコマンドを実行してパッチを追加します。​
      viopatch add -l [path to the debian file]

      注意:Adobe に関する既存のバグにより、Firefox を使用してファイルをアップロードできない場合があります。詳細については、「既知の問題」の「Firefox Web ブラウザでパッチ ファイルをアップロードする場合に問題が発生する」を参照してください。
    4. パッチが正常に追加されたことを確認します。
      viopatch list
      このコマンドでは、使用可能なパッチのリストがバージョン番号、タイプ、および現在のステータスも含めて返されます。
  2. パッチをインストールします。

    1. VMware Integrated OpenStack サービスが実行中であるか、まだデプロイされていないことを確認します。VMware Integrated OpenStack サービスが他の状態になっている場合、アップグレードに失敗します。

    2. VMware Integrated OpenStack 管理サーバにログインし、次のコマンドを実行します。
      viopatch install -p vio-patch-3102 -v 3.1.0.6902555
      パッチのインストールを完了するには最大で 15 分かかります。
      注意:パッチのインストール中に、API エンドポイントは自動的にオフになります。したがって、インストール中に API 呼び出しが発生した場合は、503 エラーが返されます。
  3. アップデートを完了するには、vSphere Web Client からログアウトして再度ログインします。再度ログインするときに表示されるエラー メッセージは無視してください。

  4. (オプション)必要に応じてパッチをアンインストールし、以前のパッチ バージョンに戻すことができます。

    1. VMware Integrated OpenStack 管理サーバにログインし、次のコマンドを実行します。
      viopatch uninstall -p vio-patch-3102 -v 3.1.0.6902555
      復帰プロセスを完了するのに 15 分かかります。

    2. パッチをアンインストールした後、vCenter Server で vSphere Web Client サービスを再起動して VMware Integrated OpenStack プラグインをダウングレードする必要があります。vCenter Server アプライアンス サービスの再起動に関する詳細は、KB2054085 を参照してください。

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

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

解決した問題

  • インスタンスをリサイズすると、インスタンスが別のコンピューティング ホスト(vCenter クラスタ)に移動する

    Nova スケジューラが、リサイズ中にインスタンスを別のホストに移動する決定を行う可能性があります。

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

  • 30 分間ボリューム操作がない場合、ボリューム作成が失敗する

    30 分間ボリューム操作がない場合、OpenStack Cinder によって作成される vCenter セッションの有効期限が切れます。セッションは再作成されず、結果としてボリューム作成操作が失敗します。

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

  • ボリュームのリタイプによって、ボリューム シャドウ仮想マシン内の仮想ディスクのポリシーが変更されない

    ボリュームのリタイプ中、変更先のボリューム タイプに異なるストレージ ポリシーがある場合、新しいストレージ ポリシーは、ボリューム シャドウ仮想マシンの構成にのみ適用されます。vmdk のストレージ ポリシーは変更されません。

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

  • VMware Integrated OpenStack 3.1 から 3.1.0.2 へのアップグレード後、エッジが重複する

    Neutron データベースに冗長なバックアップ エッジが作成されます。

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

  • LDAP 構成が失敗する

    LDAP 構成中、LDAP ポート値がユーザー インターフェイスからバックエンドに渡されます。デフォルトのポート値は 636 です。ユーザーが別のポート値を定義しても、ユーザー インターフェイスは常に 636 を渡します。

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

  • コマンド「viocli inventory-admin sync-availability-zones」を実行すると失敗が報告される

    node_group['roles'] に「Compute」が存在すると、viocli inventory-admin sync-availability-zones が結果を 1 つしか返しません。

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

  • 独立した Distributed Switch ネットワークにバッキングされるコンピューティング クラスタ間での移行時に、ライブ移行が失敗する

    各クラスタに 2 つの異なる Distributed Switch を使用していると、ライブ移行後に VMware Integrated OpenStack インスタンスがネットワークと通信できません。

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

  • router_type を「shared」から「exclusive」に変更すると、フローティング IP アドレスを経由するネットワーク接続が失われる

    移行後に、フローティング IP アドレスが排他的なルーターの外部インターフェイスから失われます。

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

  • デフォルト ドメインを削除すると、ユーザーが削除され、Keystone v2 API へのアクセスが破損する

    VMware Integrated OpenStack は、Active Directory/LDAP および SQL ベースのユーザーをデフォルト ドメインに入力します。サービスと API は情報をデフォルト ドメインに依存しているため、デフォルト ドメインは削除しないでください。

    本リリースで、この問題は対応されました。

  • OpenStack が報告するストレージの空き容量が実際に使用可能な量よりも少ない

    Nova は、空き容量の報告時に誤ったデータストアを選択します。

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

既知の問題

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

    Neutron プラグインで security-group-policy を有効にした後、NSX ファイアウォールのセクションの順序が誤っている場合があります。正しい順序は以下のとおりです。

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

    回避策:VMware Integrated OpenStack を構成する前に、まず NSX ポリシーを作成します。すでに構成している場合、vSphere Web Client の [NSX ファイアウォール] ページに移動して、このポリシーのセクションを上に移動します。

  • トランスポート ゾーンの 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 から新しいインスタンスの証明書をインポートするためのワークフローを実行します。
  • VIO 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 が起動されたら、失敗したコントローラをリブートした後に、デプロイを確認して、両方のコントローラでサービスが提供されていることを確認してください。

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

    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 のログを調べ、正常に再起動したことを確認します。

    注:再起動すると、サービスが中断します。この問題は今後の VMware Integrated OpenStack リリースで速やかに解決されます。

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

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

  • リカバリ操作が「ノードはすでに存在します」という内容のエラーを返す。

    特定の状況では、Ansible の操作が中断されると、viocli recovery - <DB name> コマンドの実行は失敗します。その結果、データベース ノードが残り、エラーの原因となります。

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

  • LLBaaS 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 ロード バランサはサブネットあたり 1 つのテナントのみをサポートします。テナントはそのテナント自体のロード バランサを作成するので、通常の動作ではこれは問題になりません。ユーザーがロード バランサを作成してサブネットに接続しようとすると、ロード バランサは作成されますがエラー状態になります。

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

  • 操作がタイムアウトし、「Connection reset by peer」というエラーが発生する。
    NSX 6.2.1 を使用する VMware Integrated OpenStack 2.0.1 デプロイで発生します。ロード バランサとコントローラ ノードの設定で十分な長さのタイムアウトが構成されなかったために、HA プロキシがタイムアウトすることがあります。

    回避策:custom.yml を編集して、タイムアウト値を変更します。次のパラメータを以下のように追加するか、変更します。

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

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

    注:この問題は今後の NSX リリースで速やかに解決されます。

  • オンライン ドキュメント: 一部のグラフィックスが表示されないことがある。

    Firefox または Internet Explorer ブラウザを使用して VMware Integrated OpenStack のオンライン ドキュメントを表示すると、一部のグラフィックスが表示されないことがあります。PDF ドキュメントには影響がありません。

    回避策:Google Chrome ブラウザを使用します。すべてのグラフィックスが問題なく表示されます。

  • イメージが 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 コマンドを再度実行します。これで、エラーが表示されなくなります。

  • TLS v1.0 が無効になっている他の VMware 製品との相互運用性。
    VMware Integrated OpenStack と、TLS v1.0 と SSL v3 が無効になっている他の VMware 製品の間には相互運用性の問題があります。TLS v1.0 と SSL v3 は、PCI データ セキュリティ標準の最新のリビジョンで安全でないと考えられるようになったため、多くのクライアントはこれらを段階的に廃止しています。以前のバージョンの VMware Integrated OpenStack は、パブリック API の受信接続で TLS v1.0 と SSL v3 を無効にしていました。VMware Integrated OpenStack v2.5.1 および v3.0 では、vSphere 6.0 update 2、NSX 6.2.4、LDAP サーバなどの、TLS v1.0 と SSL v3 が無効になっているコンポーネントと完全な相互運用性があります。

    回避策:VMware Integrated OpenStack が実行されている vCenter Server で TLS を無効にします。

    1. /etc/vmware-rhttpproxy/config.xml ファイルを変更します。
      <vmacore>
         <ssl>
            <doVersionCheck> false </doVersionCheck>
            <useCompression>true</useCompression>
            <libraryPath></libraryPath>
            <sslOptions> 117587968</sslOptions>
         </ssl>
      ...
    2. /etc/vmware-vpx/vpxd.cfg ファイルを変更します。
      <vmacore>
         <cacheProperties>true</cacheProperties>
         <ssl>
            <useCompression>true</useCompression>
            <sslOptions> 117587968</sslOptions>
         </ssl>
      ...
    3. vCenter Server の vpxd および rhttpproxy サービスを再起動します。
  • RabbitMQ を開始する際に、OpenStack リカバリに失敗する場合がある。

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

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

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

    この問題は今後のリリースで速やかに解決されます。

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

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

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

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

  • custom.yml を使用して Cinder ボリュームのデフォルトのアダプタ タイプを設定できない

    custom.yml を使用する Cinder ボリュームのデフォルトのアダプタ タイプの設定が動作しません。

    回避策:ボリュームのアダプタ タイプを設定するには、ボリューム タイプの vmware:adapter_type を使用して、デフォルトのボリューム タイプを含めます。

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