VMware Integrated OpenStack 7.1 リリースノート

VMware Integrated OpenStack 7.1 | 2021 年 5 月 13 日 | ビルド OVA 17987092、パッチ 17987093

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

リリースノートの概要

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

VMware Integrated OpenStack について
新機能
バージョン 7.1 へのアップグレード
互換性
非推奨に関する通知
解決した問題
既知の問題

VMware Integrated OpenStack について

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

新機能

最新バージョンの VMware 製品のサポート：
- VMware Integrated OpenStack 7.1 は、VMware vSphere 7.0 U2、NSX-T 3.1.1、および NSX-V 6.4.10 との間に完全な互換性があります。
新機能と機能拡張：
- 管理プレーン：
  - VIO 管理プレーンでのディザスタリカバリのサポート。管理プレーンを災害からリカバリできるようにサポートする新しい viocli コマンドが提供されます。ディザスタリカバリの全体的な手順は、SRM、vSphere Replication と、Nova インスタンス、Cinder ボリューム、Neutron ネットワークをカバーする NSX-T のマルチサイト機能で検証されます。ターゲットのディザスタリカバリサイトでデプロイがリカバリされると、ユーザーは VIO を使用して、リカバリされた Nova/Cinder/Neutron オブジェクトを管理できます。
  - Neutron NSX-T 管理プラグインからポリシープラグインへの移行のサポート。
  - 複数のライセンスキーのサポート：管理者が複数の VIO ライセンスキーを入力し、使用するキーを割り当てることができます。
- OpenStack ドライバ：
  - Octavia フレーバーのサポート。この機能により、ユーザーは、NSX-T で VIO によって作成されたロードバランサで OpenStack Octavia フレーバー機能を使用できます。この機能は、NSX-T 3.1 以降で Neutron NSX-P プラグインによってサポートされます。
- スケーラビリティ：
  - 拡張されたスケーラビリティのサポート。1 つの VIO デプロイで、最大 128 台の Nova コンピューティングノード、Neutron NSX-T Policy Plugin による最大 10,000 のテナントネットワーク、vIDM を IdP として使用する最大 8 つの VIO デプロイフェデレーションをサポートできるようになりました。

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

7.0 または 7.0.1 からアップグレードするには、viocli patch コマンドを使用します。詳細な手順については、製品のインストールガイドを参照してください。
6.0 からアップグレードする場合は、製品のインストールガイドに記載されている Blue または Green アップグレード手順を使用してください。
VIO 7.1 では、5.x からの直接アップグレードはサポートされていません。まず 7.0.1 にアップグレードしてください。

互換性

VMware Integrated OpenStack と他の VMware 製品との互換性については、VMware 製品の相互運用性マトリックスを参照してください。

非推奨に関する通知

次のネットワーク機能は廃止されています。VIO の次回のリリースで削除される予定です。
- Neutron 用の NSX Data Center for vSphere ドライバ。
- NSX-T Management Plugin for Neutron は、NSX-T Policy Plugin に置き換えられます。
- TVD プラグイン。単一の VMware Integrated OpenStack デプロイで、NSX Data Center for vSphere バックエンドと NSX-T Data Center バックエンドを使用できます。
Neutron FWaaSv2 は、以降のバージョンで廃止される予定です。

解決した問題

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

VIO 管理に関する解決した問題
OpenStack に関する解決した問題

VIO 管理に関する解決した問題

2750794 の修正：VIO 管理者が VIO バックアップのスケジュールジョブを削除すると、バックアップデータが削除される
VIO 7.0 では、管理者が VIO バックアップのスケジュールジョブを削除すると、vCenter Server コンテンツライブラリに保存されているバックアップデータも削除されました。
VIO 7.1 では、バックアップのスケジュールジョブが削除されてもバックアップデータは削除されません。
2738659 の修正：vCenter Server SSL を有効にしてあると、VIO バックアップのリストア手順が正しく動作しない
vCenter Server SSL を有効にしてあると、VIO バックアップのリストア手順が正しく動作しないvCenter Server のコンテンツライブラリへのバックアップデータのアップロードに失敗し、「x509: 認証局が不明な証明書です」エラーが報告されていました。
2680755 の修正：VIO デプロイウィザードで「vCenter Server リソースのロードタイムアウト」というエラーが発生し、先に進めない
VIO 7 は、govmomi を使用して vCenter Server インベントリ情報を取得します。ターゲットの vSphere 環境で、トラフィックのフィルタリングとマーキングのために DistributedVirtualPortgroup に「MAC」または「システムトラフィック」トラフィック修飾子がある場合、govmomi は正常な処理ができません。
2677748 の修正：VIO マネージャの Web ユーザーインターフェイスで、OpenStack のサービスステータスを一覧表示できない
VIO マネージャの Web ユーザーインターフェイスでは、ホイールによってサービスを一覧表示することができず、「リソースが見つかりません」というメッセージのみが表示されます。
2591794 の修正：NSX-V 環境でメタデータサービスにアクセスできない
VMware Integrated OpenStack の API ネットワークからメタデータプロキシエッジにルーティングできない場合、メタデータサービスにアクセスできません。この場合、VIO7.1 は管理 API 経由でメタデータプロキシに自動的にアクセスします。
2688209 の修正：VIO サポートバンドルに含まれるログ情報が約 2 日間分のみ
VIO 6.0 および 7.0 では、サポートバンドルに保持できるログ情報が約 2 日間分のみです。このログ情報は、トラブルシューティングの目的を十分に満たせません。この問題を解決するために、VIO 7.1 では自動生成されるログバックアップを有効にして、ログの保持期間を最大 7 日に増やしています。
2707205 の修正：VIO 6 および 7 では、コントローラノードで rp_filter が loose モードに設定されない
VIO 6 および 7 は PhotonOS に移行し、コントローラノードで rp_filter を明示的に設定しませんでした。そのため、デフォルトで「1」（RFC3704 の strict モード）に設定されています。strict モード設定によってパケットがドロップされ、管理ネットワーク上のアプリケーションがパブリックエンドポイントに接続できない場合があります。
2631412 の修正：VIO GUI で「Kubernetes Ingress Controller Fake Certificate」という名前の証明書が使用される
この証明書名は、Nginx Ingress Controller によって作成されるデフォルトの名前です。VIO 7.1 にアップグレードすると、適切な名前に置き換えられます。

OpenStack に関する解決した問題

2594923 の修正：glance イメージの vmware_cpu_affinity プロパティが機能しない
glance イメージの vmware_cpu_affinity プロパティが機能しないこのような glance イメージを使用して Nova インスタンスを作成すると、「エラー: vmware_cpu_affinity フィールドには、文字列でなくリストが必要です (HTTP 400)」エラーが発生します。

VIO 7.1 では、次の例のようにこのプロパティを設定できます。
```
openstack image set --property vmware_cpu_affinity="[0,1]" image_name
```
2753879 の修正：fwaas v1 拡張機能が原因で Heat スタックを更新できない
アップストリーム Heat では fwaas v1 が引き続き使用され、fwaas v2 はサポートされません。ただし、VIO7 は fwaas v2 のみをサポートします。
2713308 の修正：未使用の基本 glance イメージが Nova キャッシュフォルダに蓄積される
未使用の基本 glance イメージが Nova キャッシュフォルダに蓄積される未使用のイメージをクリーンアップするバックエンドプロセスが正しく動作しません。
2710808 の修正：VIO7 でサポートされる Designate プール内の ns_record は 1 つのみ
VIO7 でサポートされる Designate プール内の ns_record は 1 つのみです。VIO7.1 ではこれが改善され、Designate で複数の ns_record がサポートされます。
2707581 の修正：QoS ポリシーがデフォルトとして設定されている場合、その QoS ポリシーが外部ネットワークでも使用される
特定の QoS ポリシーがデフォルトとして設定されている場合、その QoS ポリシーが外部ネットワークでも使用されます。これは、外部ネットワークにとって正しくない動作です。
2705010 の修正：VIO7 では Octavia のロードバランサのサイズを変更できない
Octavia LBaaS には、ユーザーがロードバランサのサイズを変更する方法がありません。
VIO 7.1 には、このサイズを設定するオプションが用意されています。
```
default_edge_size = <purpose>:<edge size>[,...]
```
サポートされる purpose は、router、dhcp、lb です。
サポートされる size は、compact、large、xlarge、quadlarge です。
例：default_edge_size = lb:xlarge

「viocli update neutron」を使用して、[nsxv] セクションの下にパラメータを追加し、設定してください。
```
conf:
  neutron: 
  plugins: 
    nsx: 
      nsxv: 
        default_edge_size: lb:xlarge
```
2701437 の修正：glance イメージオプション「vmware_create_template=false」が正しく機能しない
次の構成では、glance イメージから Nova インスタンスを作成および起動できませんでした。
- glance 構成で vmware_create_template オプションが false の場合
- ユーザーが openstack CLI でプロパティ「vmware_create_template=false」を使用して glance イメージを作成した場合
  例：
```
openstack image create --disk-format vmdk --file vmdk --property vmware_create_template=false imageName
```
2699470 の修正：Nova コンピューティングポッドで nova-manage コマンドを実行できない
Nova コンピューティングポッドから nova-manage コマンドを実行すると、nova-compute.conf に [database] セクションが存在しないために DBNonExistentTable 例外が発生します。
2688655 の修正：VIO 7.0.1 では Openstack CLI で openid を使用した認証が機能しない
VIO 7.0.1 では、Openstack CLI で openid を使用した認証は Unauthorized (HTTP 401) エラーが発生して機能しません。
2674517 の修正：フレーバーで定義されたスワップディスクが Nova インスタンスに正しくマウントされない
フレーバーで定義されたスワップディスクが Nova インスタンスに正しくマウントされないこれは、スワップディスクを持つ仮想マシンのサイズ変更をサポートしないという制約の下で VIO 7.1 で修正されました。
2672946 の修正：ホスト集約名が特定の条件のとき、Nova コンピューティングのアベイラビリティゾーンセットアップポッドが CrashLoopBackOff 状態になる
Nova アベイラビリティゾーンに「nova」という名前のホスト集約があり、同じゾーンに「^.*nova$」に一致する「xxxxx-nova」という名前（5-nova など）の別のホスト集約がある場合、Nova コンピューティングのアベイラビリティゾーンセットアップポッドは CrashLoopBackOff 状態になります。
2656225 の修正：ユーザーが仮想マシンコンソールを開けず、「エラー: 現在、コンソールは利用できません」というエラーが Horizon ユーザーインターフェイスで表示される
一定の条件のとき、Horizon で「エラー: 現在、コンソールは利用できません」というエラーが表示されて仮想マシンを表示できませんでした。これは、vmx 構成パスが長くなり、MKS チケットの情報と vmx 構成パスを含む行を Nova コンピューティングがデータベースに挿入できない場合に発生します。たとえば、VIO インスタンスに SvMotion を使用すると、vmx 構成パスが長い文字列に変更されます。
2652286 の修正：LB 健全性モニターの削除が「サーバ側エラー: 'NoneType' オブジェクトに 'load_balancer_id' 属性がありません」というエラーと共に失敗する
これは、Octavia サービスのバグが VMware NSX プラグインに影響しているためです。健全性モニターに対応するプールを Octavia サービスが取得できないために、このエラーが発生することもあります。このバグは現在、https://storyboard.openstack.org/#!/story/2008231 でオープン状態として扱われ、追跡されています。
2678067 の修正：Horizon Console で、Windows Nova 仮想マシンに対するマウスカーソルの動作に一貫性がない
任意のブラウザで Horizon Console にアクセスしたとき、Tab キーまたは Ctrl キーを押しながらクリックしないと、Windows 仮想マシンのカーソルが反応しません。その後、再度左クリックしても反応しなくなります。
2755304 の修正：Octavia LB ステータス変更トランザクションが失敗し、ステータスが PENDING_DELETE から変化しなくなる
Octavia は、ドライバエージェント内での内部通信に UNIX ソケットを使用します。このソケットへの書き込み中に、タイムアウトが発生してステータス変更トランザクションが失敗することがあります。ステータス変更トランザクションの再試行メカニズムが追加されました。
2643797 の修正：trusted_dashboard を構成するとき、Horizon FQDN が FQDN 名ではなく IP アドレスとして kystone.conf に保存される
keystone のフェデレーション設定を構成するとき、指定された Horizon FQDN は、指定された FQDN 名ではなく IP アドレスとして keystone 構成ファイルに保存されます。
```
viocli update keystone
conf: 
  keystone: 
    federation: 
      trusted_dashboard: https://HorizonFQDN/auth/websso/
```

既知の問題

パブリック API のレート制限を使用できない
VMware Integrated OpenStack 7.1 では、パブリック API にレート制限を適用できません。

回避策：なし。この機能は、この後のバージョンで提供されます。
ルーターに接続されていないプライベートサブネットを使用してロードバランサを作成すると、エラー状態になる
MP プラグインや Policy Plugin などの Neutron NSX-T プラグインでは、ルーターに接続されていないプライベートサブネットを使用してロードバランサを作成すると、ロードバランサにエラーが発生しますが、エラーがユーザーに報告されません。

回避策：ルーターに接続されているサブネットを使用してロードバランサを作成します。
OpenStack のデプロイ時に誤った認証情報を入力すると、ウィザードは正しい認証情報を認識できないことがある
OpenStack のデプロイプロセスで、vCenter Server または NSX Manager の認証情報を正しく入力しなかった場合、ウィザードは正しい認証情報を認識できないことがあります。誤った情報を削除して、正しい認証情報を入力しても、ウィザードは検証に失敗することがあります。

回避策：デプロイウィザードを閉じて、もう一度開きます。
NSX-V Neutron Plugin の直接ポートに OpenStack ポートセキュリティを適用できない
vnic-type が direct であるポートでポートセキュリティを有効にしても、有効にならないことがあります。直接ポートでセキュリティ機能が使用できません。

回避策：なし。
vCenter Server と NSX のパスワードに $$ が含まれていると VIO にログインできない
基になる vCenter Server と NSX 用に構成された VIO アカウントが「$$」を含むパスワードを使用している場合、パスワードに含まれる「$$」のために VIO は vCenter Server と NSX の認証を完了できません。OpenStack ポッドが CrashLoopBackOff 状態になる可能性があります。

回避策：「$$」を含まない他のパスワードを使用します。
ロードバランサが PENDING_XXX 状態で停止し、操作できなくなる
この停止問題は、ロードバランサが作成、変更、または削除されたとき、octavia-api ポッド内で octavia-da がクラッシュすると発生します。

回避策：これらのロードバランサは、Octavia で使用できなくなります。これらは Octavia データベースから手動で削除する必要があります。
ユーザーが openstack CLI クライアントから glance イメージをダウンロードできない
openstack CLI からイメージをダウンロードすると、次のエラーが発生します。「[Errno 32] ダウンロードされたイメージが破損しています。」これは、VIO がデフォルトでイメージを仮想マシンテンプレートとして vSphere データストアに保存するためです。md5sum 値は VMDK と仮想マシンテンプレートの間で保存されません。

回避策：glance イメージは、次の構成の場合にダウンロードできます。
- glance 構成で vmware_create_template オプションが false
- ユーザーが openstack CLI でプロパティ「vmware_create_template=false」を使用して glance イメージを作成した
ファイアウォールグループの管理状態を DOWN に設定すると (state=DOWN)、UP に戻した後でもファイアウォールグループの動作ステータスが常に DOWN になる
neutron-fwaas サービスでは、ファイアウォールグループに対するポートの追加や削除を伴わない移行における動作ステータスの変更は無視されます。

回避策：ポートを追加または削除するか、ファイアウォールグループにバインド済みのポートを追加してから削除します。
vCenter Server および NSX 証明書が中間 CA によって署名されている場合、証明書の検証を無視しないように選択することができない
vCenter Server および NSX 証明書が中間 CA によって署名されている場合、一部の VIO サービスは、証明書検証を実行するように適切に構成できません。不具合はさまざまな形で示されます。たとえば、vCenter Server または NSX の追加または編集時に「証明書の検証を無視」の選択を解除することができません。

回避策：ユーザーインターフェイスから [証明書の検証を無視] を選択し、vCenter Server と NSX の CR を編集して spec.insecure を true に設定します。
Neutron セグメントで [編集] をクリックして保存すると、誤ってマルチキャストが有効になる
NSX-T ポリシーのユーザーインターフェイスで、マルチキャストルーティングに対して何か無関係な変更が行われた場合、セグメントでマルチキャストルーティングが有効になります。

回避策：ユーザーインターフェイスでセグメントを編集するときには、マルチキャストを明示的に無効にします。
メンバー追加の操作が「プロバイダ 'vmwareedge' からエラーが返されました: 証明書を取得できません::」(HTTP ステータス 500) メッセージで失敗する
HTTPS_TERMINATED 状態の Octavia ロードバランサに対してメンバーを追加または削除できません。

回避策：OpenStack CLI を使用してメンバーを追加または削除します。

1.影響を受けるすべてのユーザーについて tls_container_ref を取得します。

2.コンテナ、シークレット、および証明書の URI を見つけます。

3.Octavia のサービスユーザー ID を取得します。

4.手順 2 で取得した URI を、手順 3 で取得したユーザー ID の ACL に追加します。
大規模な MP2P 移行中に Tier-1 ゲートウェイを完全にロールバックできない
大規模な MP2P 移行中、一部の Tier-1 ゲートウェイは完全にロールバックできず、削除ステータスが進行中のままになっていました。移行中のエラーが原因でロールバックが失敗した可能性があります。

回避策：UA をリストアして再移行します。
Keystone フェデレーションで重複エントリエラーが発生する
Keystone フェデレーションで OIDC を削除した後、同じユーザーが OIDC を使用してログインしようとすると、409 メッセージが表示されて認証に失敗します。

回避策：Horizon または OpenStack CLI を使用してユーザーを削除します。

例：

1.Horizon で、管理者アカウントでログインします。

2.フェデレーションドメインでドメインコンテキストを設定します。

3.[ユーザー] 画面で、[ユーザー名] 列が [なし] のユーザーを削除します。

OpenStack CLI で以下を実行します。

openstack user list --domain <federated domain name>

openstack user delete <user id> --domain <federated domain name>
移行が成功した後、移行ポッドのログが VIO サポートバンドルで利用できない

移行が成功すると、VIO 制御プレーンが再構成され、移行ポッドは削除されます。これにより、そのログはサポートバンドルでキャプチャされません。

回避策：移行ポッドのログはコントローラノードから入手できます。ログは /var/log/vmware/mp2p_migration.log に記録され、保存されます。viossh を介してコントローラノードにアクセスすると、ログファイルを取得できます。ログファイルは、ジョブが実行されるコントローラからのみ入手できます。そのため、ログファイルが見つかるまで複数のコントローラを調べる必要がある場合もあります。
Neutron テナントネットワークの数が 10,000 の場合、ceilometer を有効にできない
ネットワークなどの大量のリソースが vSphere 内に作成されると、VIO はそれらのオブジェクトに対して大量の顧客リソースを生成します。顧客リソースの数が多すぎると、http 要求に対する応答データが大きくなりすぎ、バックエンド API で VIO Manager の Web ユーザーインターフェイスが正常に動作しません。

回避策：VIO マネージャで、検出された顧客リソースを手動で削除します。

次のコマンドを使用して顧客リソースを一覧表示できます。
```
kubectl -n openstack get discoveries.vio.vmware.com
```
次のコマンドを使用して顧客リソースを削除できます。例：
```
kubectl -n openstack delete discoveries.vio.vmware.com vcenter-vcenter2-networks-2
```
リストア後、証明書は CA 署名をして再適用する必要がある
VIO プライベートキーと証明書を含む証明書シークレットは、現在バックアップの対象ではありません。インプレースでないリストアの後、以前にインポートした証明書は新しいデプロイには含まれません。

回避策：

1.元のデプロイの証明書シークレットを保存します。
osctl get secret certs -oyaml > certs.yaml
2. リストア後、証明書シークレットの「private_key」と「vio_certificate」の値を手順 1 のデータに置き換えます。
3. サービスを停止し、再度開始します。
特定の Nova コンピューティングノードにインスタンスを作成できず、Nova コンピューティングログが停止する
インスタンスを作成すると、そのインスタンスは BUILD 状態になり、作成は成功しません。Nova コンピューティングログを確認すると、記録は少なく、あまり情報が得られません。

回避策：novacompute ポッドを手動で再起動します。
ファイアウォールルールの変更を Horizon ユーザーインターフェイスから保存すると応答がない
ファイアウォールルールの編集時、「*」でマークされている必須オプションに更新されていないものがあると、変更を保存するときにユーザーインターフェイスは応答しません。

回避策：ファイアウォールルールを編集するときは、すべての必須オプションを更新してください。
vCenter Server のユーザー名とパスワードを VIO Manager の Web ユーザーインターフェイスから変更した後、一部の Day2 操作が機能しない
ユーザーが VIO Manager の Web ユーザーインターフェイスで vCenter Server の認証情報を更新した場合、OpenStack サービスが機能することは可能です。しかし、Kubernetes クラウドプロバイダの vCenter Server シークレットと cluster-api が更新されないため、VIO の制御プレーンは vCenter Server と通信できません。

回避策：VIO Manager で「kubectl patch secret」コマンドを使用して、vCenter Server の認証情報を更新します。

次のようにして、現在の vc-credential シークレット情報を確認します。
```
kubectl -n kube-system get secret viocluster1-vc-credentials -o yaml 
kubectl -n openstack get secret viocluster1-vc-credentials -o yaml
```
次のようにして、vc-credentials シークレットを新しいユーザー名/パスワード（base64 形式）で更新します。
```
kubectl -n kube-system patch secret viocluster1-vc-credentials --patch \
'{"data": {"your_vcenter.password": "password_in_base64", "your_vcenter.username": "username_in_base64"}}'
kubectl -n openstack patch secret viocluster1-vc-credentials --patch \
'{"data": {"password": "password_in_base64", "username": "username_in_base64"}}'
```
SAML フェデレーション IdP を使用してログインすると、Horizon のユーザーインターフェイスに「xmltooling::IOException」と表示される
VIO が外部 SAML IdP で構成されている場合、ユーザーが SAML フェデレーションでログインしようとすると、「xmltooling::IOException」エラーが発生します。

回避策：ブラウザの [更新] ボタンをクリックすると IdP のログイン画面に進むことができます。
「viocli update」コマンドを使用して CR を更新すると、値として大きな整数を入力した場合にエラーが発生することがある（例：profile_fb_size_kb: 2097152）
大きい整数は、VIO Helm チャートによって指数表記に変換される場合があります。

回避策：大きい整数は引用符で囲みます。例：profile_fb_size_kb: "2097152"。
コントローラノードでスナップショットを作成すると、一部の VIO 操作ができない
コントローラノードのスナップショットがある場合は、コントローラノード上のパーシステントボリュームを移動できません。そのため、VIO ではコントローラのスナップショットの作成はサポートされません。

回避策：コントローラノード上のすべてのスナップショットを削除します。
イメージから作成されたボリュームは、デフォルトで常に起動可能である
イメージからボリュームを作成するときに、--non-bootable パラメータを指定した場合、パラメータは有効になりません。

回避策：ボリュームが作成されたら、起動不可能に更新します。

リリース ノートの概要