RSS
 

VMware Integrated OpenStack 7.2 | 2021 年 12 月 16 日 | ビルド OVA 19066814、パッチ 19066815

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

リリース ノートの概要

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

VMware Integrated OpenStack について

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

新機能

  • 最新バージョンの VMware 製品のサポート： 

    • VMware Integrated OpenStack 7.2 は、VMware vSphere 7.0 U2、NSX-T 3.2、および NSX-V 6.4.11 との間に完全な互換性があります。 

  • 新機能と機能拡張：

    • 管理プレーン：
      • VIO デプロイの Neutron での NSX-V から NSX-T への移行のサポート：VMware NSX Data Center for vSphere 6.4.x のジェネラル サポートは、2022 年 1 月 16 日に終了します。このリリースでは、既存の VIO デプロイの Neutron を NSX-V から NSX-T に移行する機能が追加されています。NSX-T は、3.2 以降である必要があります。 
      • 仮想マシン インポート機能のサポート（機能拡張）：NSX-T Data Center のネットワークを使用する環境では、VIO は複数の vNIC を持つ仮想マシンのインポート、非ルート ディスクのボリューム タイプの指定、カスタマイズされたフレーバーとの関連付けを実行できます。
      • ディザスタ リカバリのサポート（機能拡張）：管理プレーンのリカバリをユーザー インターフェイスでサポートし、リカバリ後に一部の NSX リソースを自動的に更新します。また、複数の vCenter Server を使用する VIO のデプロイもサポートします。
      • VIOCLI のサポート（機能拡張）：複数の vCenter Server 環境で、ボリューム移行コマンドやインスタンス/仮想マシン操作コマンドなどの操作を支援します。 
      • 新しい健全性チェック ツールのサポート：VIO 管理者は、viocli コマンドを使用して VIO システムの健全性ステータスを確認できます。詳細については、VIO 7.2 の管理ガイドを参照してください。
      • VIO Web ユーザー インターフェイスのサポート（強化）：VIO 管理者は、VIO Web ユーザー インターフェイスからデプロイを直接バックアップまたはリストアできます。  以前のリリースでは、管理者はこの操作を実行するには viocli コマンドを使用する必要がありました。
      • ワンオフ パッチの管理のサポート：このリリースでは、ワンオフ パッチ用に viocli コマンドによる統合管理ツールが提供されます。すべての ワンオフ パッチで、viocli コマンドを使用して、基本的なインストール/アンインストール手順が実行され、ステータスが一覧表示されます。  
      • VIO パッチのサポート（機能拡張）：パッチの適用開始前に、事前条件の自動チェックが行われます。また、パッチのインストール中に進行状況を追跡することもできます。 
    • OpenStack ドライバ：
      • 複数の SR-IOV を使用する仮想マシン vNIC 接続の構成：仮想マシンが NUMA ノード アライメントの下に配置されているときに、指定された SR-IOV 物理 NIC で VNF が接続するための一般的な方法が提供されます。
      • テナント VDC のサポート（機能拡張）：管理者は、テナント VDC 内で仮想マシンを移行できます。テナント VDC の名前変更もサポートされます。
      • Nova インスタンスでの複数の vGPU プロファイルのサポート：nova-manage コマンドを使用して、vCenter Server に含まれる vGPU の情報を表示および更新できます。  

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

  • 以前の VIO 7.x バージョンからアップグレードするには、viocli patch コマンドを使用します。詳細については、製品のインストール ガイドを参照してください。 
  • 6.0 からアップグレードする場合は、製品のインストール ガイドに記載されている Blue または Green アップグレード手順を使用してください。 

互換性

非推奨に関する通知 

  • 次のネットワーク機能は廃止されています。VIO の次回のリリースで削除される予定です。
    • Neutron 用の NSX Data Center for vSphere ドライバ。
  • Neutron FWaaSv2 は、以降のバージョンで廃止される予定です。

解決した問題

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

VIO 管理に関する解決した問題
  • 2836971 の修正：ユーザーがバックアップ名をパラメータとして指定すると、viocli get backup が失敗する。

    バックアップ ファイル名が viocli のパラメータになっているバックアップは、取得および削除できません。

  • 2700928 の修正：VMware Integrated OpenStack Manager の Web ユーザー インターフェイスで使用される Kubernetes 入力方向コントローラでは、古いバージョンである nginx 1.15.10 が使用されている。

    ngnix が 1.20.1 にアップデートされました。

  • 2824166 の修正：Octavia サービスでは、カスタム リソースでポリシーがサポートされない。

    管理者は、viocli update コマンドを使用して Octavia ポリシーをカスタマイズすることができません。

  • 2882017 の修正：openvswitch-vswitchd ポッドの再起動後に、OVS 構成がリカバリされません。

    openvswitch-vswitchd ポッドの再起動後に、OVS 構成がリカバリされません。

OpenStack に関する解決した問題
  • 2759804 の修正：vCenter Server および NSX 証明書が中間 CA によって署名されている場合、証明書の検証を無視しないように選択することができない。

    vCenter Server および NSX 証明書が中間 CA によって署名されている場合、一部の VIO サービスは、証明書検証を実行するように適切に構成できません。不具合はさまざまな形で示されます。たとえば、vCenter Server または NSX を追加または編集するときに、[証明書の検証を無視する] を選択解除することができません。

  • 2863416 の修正：datastore_cluster バックエンドでインスタンスのビルドと実行に失敗する。

    datastore_cluster バックエンドに基づく Nova インスタンスを起動することができません。

  • 2767303 の修正：vCenter Server のユーザー名とパスワードを VIO Manager の Web ユーザー インターフェイスから変更した後、一部の Day2 操作が機能しない。

    ユーザーが VIO Manager の Web ユーザー インターフェイスで vCenter Server の認証情報を更新した場合、OpenStack サービスが停止します。しかし、k8s クラウド プロバイダの vCenter Server シークレットが更新されないので、VIO の制御プレーンは vCenter Server と通信できません。

  • 2852405 の修正：古い configdrive.iso ファイルのために vSAN データストアの使用率が高くなる。

    vSAN データストア内の Nova インスタンスを削除しても、古い configdrive.iso ファイルは削除されません。

  • 2857728 の修正：VIO ダッシュボードの動作が数時間ごとに遅くなり、入力方向ポッドを削除するまでダッシュボードにアクセスできなくなる。

    DVS バックエンドを含む VIO では、大量のメタデータ要求によって入力方向の速度が低下し、VIO ダッシュボードにアクセスできなくなる可能性があります。

  • 2851020 の修正：テンプレート以外のイメージからのインスタンスの起動に失敗する。

    「vmware_create_template=false」および「img_linked_clone=false」プロパティが設定されている場合、イメージの 2 番目の Nova インスタンスは起動できません。

  • 2746353 の修正：多くの場合に必要とされる nova-compute パラメータをすべての Nova コンピューティング ノードにグローバルに追加する。

    VIO 7.2 では、「viocli update nova」を実行することで、多くの場合に必要とされる nova-compute パラメータをすべての Nova コンピューティング ノードにグローバルに追加できます。

  • 2814396 の修正：ロード バランサが PENDING_UPDATE 状態でハングアップする。

    VIO 7.0.1/7.1 では、同じオブジェクトに対する 2 つの DELETE 更新を受信すると、2 つ目の更新でロード バランサが PENDING_UPDATE 状態になります。ただし、VIO 7.2 では同じ状況でもロード バランサへの更新がスキップされるため、PENDING_UPDATE に変更されることはありません。

  • 2795219 の修正：マルチ vCenter Server 環境で、「viocli prepare datastore」を使用して古いストレージ ボリュームを退避できない。

    VIO 7.2 では、「viocli prepare datastore」コマンドに「--vcenter-name」フラグが追加されており、vCenter Server を指定できます。指定しない場合は、管理 vCenter Server と見なされます。 

  • 2759873 の修正：VIO が NSX ロード バランサのデプロイに部分的に失敗する。

    Barbican を使用して証明書のチェーン全体を NSX にアップロードすると、ロード バランサが作成されないことがあります。

  • 2761460 の修正：複数の固定 IP アドレスを 1 つのポートに追加すると、設定が失敗する。BadRequestException: 400: URL に対するクライアント エラーが発生する。

    VIO 7.0.1/7.1 で、複数の固定 IP アドレスを 1 つのポートに追加すると、BadRequestException: 400: URL: https://frn-pr-vn-01.corp.fortinet.com:9696/v2.0/ports/a840e560-6614-4b44-a275-2898a39b14cb に対するクライアント エラーで失敗します。VIO 7.2 では、ユーザーは各ポートに複数の固定 IP アドレスを追加できます。

     

  • 2764317 の修正：移行が成功した後、移行ポッドのログが VIO サポート バンドルで利用できない。

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

  • 2768005 の修正：SAML フェデレーション IdP を使用してログインすると、Horizon のユーザー インターフェイスに「xmltooling::IOException」と表示される

    VIO を外部 SAML IdP で構成している場合、ユーザーが SAML フェデレーションでログインしようとすると、「xmltooling::IOException」エラーが発生します。

  • 2760150 の修正：ファイアウォール ルールの変更を Horizon ユーザー インターフェイスから保存すると応答がない

    ファイアウォール ルールの編集時、「*」でマークされている必須オプションに更新されていないものがあると、変更を保存した後、ユーザー インターフェイスは応答しません。

既知の問題

  • パブリック API のレート制限を使用できない

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

    回避策：なし。この機能は、この後のバージョンで提供されます。

  • ルーターに接続されていないプライベート サブネットを使用してロード バランサを作成すると、エラー状態になる。

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

    回避策：ルーターに接続されているサブネットを使用してロード バランサを作成します。

  • NSX-V Neutron プラグインの直接ポートに OpenStack ポート セキュリティを適用できない。

    vnic-type が direct であるポートでポート セキュリティを有効にしても、有効にならないことがあります。直接ポートでセキュリティ機能が使用できません。

    回避策：なし。

  • vCenter Server と NSX のパスワードに $$ が含まれていると VIO にログインできない。

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

    回避策：「$$」を含まない他のパスワードを使用します。

  • ユーザーが 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 サービスでは、ファイアウォール グループに対するポートの追加や削除を伴わない移行における動作ステータスの変更は無視されます。

    回避策：ポートを追加または削除するか、ファイアウォール グループにバインド済みのポートを追加してから削除します。

  • 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>

  • 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 コンピューティング ログを確認すると、記録は少なく、あまり情報が得られません。

    回避策：Nova コンピューティング ポッドを手動で再起動します。

  • FWaaS バインドに関係なく、Neutron ルーターのすべてのダウンリンク ポートに FWaaS v2 ルールが適用される。

    この動作は、NSX-V 分散ルーターに固有です。この種のルーターでは、NSX-V の実装はプロバイダ論理ルーター (PLR) と分散論理ルーター (DLR) の中間に位置します。FWaaS ルールは PLR で実行されますが、ダウンリンク インターフェイスは PLR 上にあります。したがって、ファイアウォール ルールはダウンリンクで送受信されるすべてのトラフィックに適用されます。

    回避策：分散ルーターの場合は、ソース サブネットとターゲット サブネットを明示的に含めてダウンリンク サブネットの CIDR に一致させます。ファイアウォール グループがルーターの各ポートに適用されるようにするか、分散ルーターの代わりに一元化されたルーターを使用します。

  • Edge クラスタで DRS を無効にすると、VIO で使用されるリソース プールの削除がトリガされる可能性がある。

    Edge クラスタで DRS を無効にすると、VIO リソース プールの削除がトリガされる可能性があります。これにより、Edge アプライアンスは管理されなくなります。

    回避策：Edge クラスタに対しては、次の手順を実行しないでください。

    1.Edge クラスタを右クリックします。

    2.Edge クラスタで DRS を無効にします。

  • NSX-V から NSX-T に移行した後、仮想マシンが Nova メタデータ サービスにアクセスできなくなる。移行後に作成された新しい仮想マシンは、Nova メタデータ サービスにアクセスできる。

    NSX-V から移行された仮想マシンには、DHCP サーバ経由でメタデータ トラフィックをリダイレクトするためのスタティック ルートがあります。NSX-T ではメタデータ アクセス用のオンリンク ルートが挿入されるため、この構成は NSX-T では機能しません。

    回避策：仮想マシンを再起動します。または、仮想マシンにアクセスできる場合は、DHCP サーバ経由のスタティック ルートを削除し、DHCP リースを更新して、Nova メタデータ サービスにアクセスするための適切なルートを持つ NSX-T DHCP サーバから新しいリースが提供されるようにします。

  • 「viocli update」コマンドを使用して CR を更新すると、値として大きな整数を入力した場合にエラーが発生することがある（例：profile_fb_size_kb: 2097152）

    大きい整数は、VIO Helm チャートによって指数表記に変換される場合があります。

    回避策：大きい整数は引用符で囲みます。例：profile_fb_size_kb: "2097152"。

  • NSX-T でロード バランサを作成すると、V2T 移行ポッドが常に失敗する。

    バックエンド メンバーが外部ネットワークにあるロード バランサでは、V2T 移行は失敗します。これは、NSX-T でこの構成がサポートされていないためです。「API 再生」ステージに入ってから、N/S カットオーバーまたはホストの移行を開始できるまでに障害が発生します。したがって、ロールバックは必要ありません。

    回避策：V2T 移行をトリガする前に、ロード バランサ プールから外部ネットワーク上のメンバーを削除します。

  • コントローラ ノードでスナップショットを作成すると、一部の VIO 操作ができない

    コントローラ ノードのスナップショットがある場合は、コントローラ ノード上のパーシステント ボリュームを移動できません。そのため、VIO ではコントローラのスナップショットの作成はサポートされません。

    回避策：コントローラ ノード上のすべてのスナップショットを削除します。

  • イメージから作成されたボリュームは、デフォルトで常に起動可能である

    イメージからボリュームを作成するときに、--non-bootable パラメータを指定した場合、パラメータは有効になりません。

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

  • V2T 移行時に、NSX ホストの移行が「構成の解決」で失敗し、次のフィードバック要求が表示されることがある。「メンテナンス モード移行で許可されない DRS 構成です」

    一部の構成では、V2T 移行時に vSphere DRS はサポートされません。サポートされている DRS モードの詳細については、NSX-T V2T のガイドを参照してください。 

    回避策：以下のいずれかが該当する場合は、vSphere DRS を無効にします。

    • インプレース移行：このモードでは、移行時にホストがメンテナンス モードになりません。このモードは、環境が vSphere 6.x の場合にのみ使用できます（vDS は N-VDS に移行されます）。
    • 自動メンテナンス移行：このモードでは、vCenter Server のバージョンは 6.5 または 6.7 です。
  • VIO NSX-V 統合を行っている場合、複数のコンピューティング クラスタが定義されていると、OpenStack インスタンスはトラフィックを送受信できない。

    Neutron サーバの初回起動時に、DHCP トラフィックが許可される Neutron のデフォルト セキュリティ グループが作成されます。コンピューティング クラスタは、VIO 環境に追加されても、デフォルト セキュリティ グループには自動的に追加されません。
     

    回避策：NSX 管理ユーティリティを使用して、デフォルトのファイアウォール セクションを次のように再構築します。

    nsxadmin -r firewall-sections -o nsx-update

  • API で Neutron ネットワークから NSX-T に移行する際に、V2T 移行ジョブが失敗し、次のようなエラーが報告される。2021-05-18 17:16:00,612 ERROR ネットワークを作成できませんでした:: 操作に対する入力が無効です。透過的 VLAN では、セグメント ID を設定することはできません。

    NSX-V Neutron プラグインを使用すると、プロバイダ VLAN ネットワークに対して VLAN 透過的ネットワーク設定を行うことができます。プロバイダ ネットワークでは特定の VLAN のみが使用されるため、この設定にはあまり意味がありません。NSX-T Neutron プラグインでは、この構成は許可されません。

    回避策：ネットワークの VLAN 透過性の設定を解除し、再試行します。

  • 場合によっては、ルーターの外部ゲートウェイの構成中に内部エラーが発生し、API 再生が失敗することがある。Neutron 移行ジョブのログに、次のようなエラーが表示される。ERROR 次のポートを持つルーター ゲートウェイを追加できませんでした: リクエストは失敗しました: リクエストの処理中に内部サーバ エラーが発生しました。

    これが発生する原因は、移行ジョブのポッド内で実行されている一時的な Neutron サーバが、NSX-T に Tier-1 が生成されたかどうかを確認するためです。まれに、この生成が非常に時間がかかりタイムアウトになることがあります。この問題が発生すると、一時的な Neutron サーバ ログ (/var/log/migration/neutron-server-tmp.log) に次のようなエラーが記録されます。2021-05-07 10:36:31.909 472 ERROR neutron.api.v2.resource vmware_nsxlib.v3.exceptions.RealizationTimeoutError: LogicalRouter ID /infra/tier-1s/ は、1 秒のスリープで 50 回試行しても生成されませんでした

    回避策：この問題の回避策はありません。ほとんどの場合は、再試行によって解決します。問題が永続的に発生する場合は、NSX-T のトラブルシューティングを実行して生成が遅い根本原因を見つける必要があります。

  • メンバーをいずれかのプールに追加した後、OpenStack ロード バランサがエラー状態になることがある。

    この問題が発生する原因は、選択されたメンバーが、すでに NSX ロード バランサに接続されているルーターのダウンリンクに構成されていることです。この場合、OpenStack ドライバは既存の LBS を再利用できません。

    回避策：ダウンリンク ネットワーク上の仮想 IP アドレスを使用して、OpenStack ロード バランサを再作成します。その後、フローティング IP アドレスを仮想 IP アドレス ポートに関連付けます。

  • V2T 移行が次のようなエラーで失敗する。INFO vmware_nsx.shell.admin.plugins.nsxv.resources.migration NSX : は Neutron に属していません。削除してください。ただし、参照されている Edge は VIO Neutron サービスによって作成される。

    これは、NSX-V プラグインの問題で、プールの一部として作成された Edge の一部が Neutron DB マッピングに追加されず、そのために Neutron に属していないと誤って識別されることによるものです。

    回避策：警告を無視してください。対処の必要がある失敗した検証チェックが他にないことを確認したら、migrator.conf.json で strict_validation を False に設定してから、移行ジョブを再実行します。

  • DOWN ステータスのクラスタの処理。

    NSX-V 上のいずれかのコンピューティング クラスタが DOWN になっていると、ホストの移行を開始できません。移行を開始する前に、すべてのクラスタが健全なステータスであることを確認する必要があります。一部のホストで継続的に障害が発生する場合は、そのホストをコンピューティング クラスタから削除する必要があります。このホスト上の仮想マシンは、クラスタ内の他のホストに移行されます。

    回避策：V2T 移行が完了したら、影響を受けたホストを NSX-T 向けに再構成し、元のクラスタに追加し直すことができます。

  • 移行後に、Neutron 論理ポートに対応するロード バランサが存在していないことがある。

    V2T の移行後、エラー状態のロード バランサに対応する Neutron ポートは、そのロード バランサが移行されなくても移行されています。V2T 移行プロセスでは、エラー状態の Octavia ロード バランサはスキップされます。これは、このような状態のロード バランサは NSX-T に正しく実装されない可能性があるためです。また、エラー状態は変更できないため、これらのロード バランサは削除する必要があります。ただし、対応する論理ポートは移行されます。

    回避策：これらのポートは、移行が完了すると安全に削除できます。この問題は、移行を開始する前にエラー状態のロード バランサを削除することで完全に回避できます。

  • Neutron ルーター ゲートウェイの削除時にエラーが発生する。

    「ロード バランサ サービスとの接続が解除されていないため、router_gateway を削除できません。」というエラーが報告されます。ただし、Octavia ロード バランサはルーターのサブネットに接続されていません。また、外部ネットワークにも接続されておらず、ルーター ダウンリンクの中にメンバーがあります。

    回避策：VIO 7.2 よりも前のバージョンでは、バックエンドの Tier-1 ルーターからロード バランサを接続解除することが唯一の回避策です。VIO 7.2 では、管理者が古いロード バランサを NSX-T から削除するためのユーティリティが提供されています。
    実体なしを一覧表示：nsxadmin -r lb-services -o list-orphaned
    実体なしを削除：nsxadmin -r lb-services -o clean-orphaned

  • リカバリされた Nova インスタンスのコンソールとログが Horizon に表示されない。

    ディザスタ リカバリ手順の後、ターゲット サイトの Horizon にログインし、[プロジェクト] > [コンピューティング] > [インスタンス] の順に移動して、リカバリされたすべてのインスタンスのログとコンソールを確認すると、何も表示されません。

    回避策：ターゲット サイトに新しい Nova インスタンスを作成し、リカバリされた各 Nova インスタンスを再度確認します。これで機能するはずです。

  • 「Edge」ステージでの N/S カットオーバー中に V2T 移行が失敗する。ユーザー インターフェイスから返されるメッセージは、「移行調整サービスが実行されている NSX-T Manager インスタンスに、トランスポート ゾーンが見つかりません」。/var/log/migration-coordinator/v2t/cm.log には、Neutron バックアップ プール内の分散 Edge（Edge 名の先頭は「backup-」）の「移行中継 LS」の作成時に障害が発生したことが示される。

    V2T 移行では、NSX-V 分散ルーターごとに N/S カットオーバー用の中継スイッチの作成が試みられます。そのため、すべての分散 Edge がスキャンされ、各 Edge に対してこの操作が実行されます。操作が成功するためには、移行の際に関連するトランスポート ゾーンを見つけることができるように、Edge にはダウンリンク インターフェイスが不可欠です。ただし、Neutron では一部の分散 Edge が「バックアップ プール」に保持されることがあります。これらは使用の準備が整っている未構成の Edge アプライアンスですが、それでも V2T 移行は失敗します。

    回避策：NSX-V で、Neutron バックアップ プール内の分散 Edge を削除します。これは、Neutron および NSX-T の操作には影響しません。

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