3.7. 既知の問題

  • Border Gateway Protocol デーモンが実行している OpenShift Container Platform 4.9.4 以前で OpenShift Virtualization を使用し、BPG ルートエントリーでネットワークインターフェイスを変更すると、BPG ルートは静的ルートに変換されます。OpenShift Container Platform 4.9.4 に同梱される nmstate-1.0.2-14.el8_4.noarch は、Bird Internet Routing Daemon プロトコルを正しく処理しません。

    クラスターを OpenShift Container Platform 4.9.5 以降にアップグレードすることで、この問題を回避できます。BGP ルートがすでに静的ルートに変換されている場合は、スタティックルートをネットワークインターフェイスから削除し、ルートを手動で追加する必要があります。

  • OpenShift Virtualization 4.9.6 に更新すると、一部の仮想マシン (VM) がライブマイグレーションループでスタックします。これは、仮想マシンマニフェストの spec.volumes.containerDisk.path フィールドが相対パスに設定されている場合に発生します。

    • 回避策として、仮想マシンマニフェストを削除して再作成し、spec.volumes.containerDisk.path フィールドの値を絶対パスに設定します。その後、OpenShift Virtualization を更新できます。
  • 仮想ディスクをホットプラグしてから、virt-launcher Pod を強制的に削除する場合には、データが失われる可能性があります。これは競合状態が原因で、これにより、仮想マシンのディスクの内容が永続ボリュームから消去される可能性があります。(BZ#2007397)
  • バージョン 4.8 より前の Open Shift Virtualization によって提供された削除済みテンプレートを仮想マシンが参照している場合、仮想マシンの編集は失敗します。Open Shift Virtualization 4.8 以降では、削除された Open Shift Virtualization が提供するテンプレートは、Open Shift Virtualization Operator によって自動的に再作成されます。

  • クローン操作がクローン作成するソースが利用可能になる前に開始されると、操作は無期限に停止します。これは、クローン操作の開始前にクローンの承認の期限が切れるためです。(BZ#1855182)

    • 回避策として、クローンを要求する DataVolume オブジェクトを削除します。ソースが利用可能になると、削除した DataVolume オブジェクトを再作成し、クローン操作を正常に完了できるようにします。

  • OpenShift Container Platform クラスターが OVN-Kubernetes をデフォルトの Container Network Interface (CNI) プロバイダーとして使用する場合、OVN-Kubernetes のホストネットワークトポロジーの変更により、Linux ブリッジまたはボンディングをホストのデフォルトインターフェイスに割り当てることはできません。(BZ#1885605)

    • 回避策として、ホストに接続されたセカンダリーネットワークインターフェイスを使用するか、OpenShift SDN デフォルト CNI プロバイダーに切り替えることができます。

  • ライブマイグレーションを実行できない仮想マシンを実行すると、OpenShift Container Platform クラスターのアップグレードがブロックされる可能性があります。これには、hostpath-provisioner ストレージまたは SR-IOV ネットワークインターフェイスを使用する仮想マシンが含まれます。

    • 回避策として、仮想マシンを再設定し、クラスターのアップグレード時にそれらの電源をオフにするようにできます。仮想マシン設定ファイルの spec セクションで、以下を実行します。

      1. evictionStrategy: LiveMigrate フィールドを削除します。エビクションストラテジーの設定方法についての詳細は、仮想マシンのエビクションストラテジーの設定 を参照してください。
      2. runStrategy フィールドを Always に設定します。

    • 回避策として、以下のコマンドを実行してデフォルトの CPU モデルを設定します。

      注記

      ライブマイグレーションをサポートする仮想マシンを起動する前に、この変更を行う必要があります。 

      $ oc annotate --overwrite -n openshift-cnv hyperconverged kubevirt-hyperconverged kubevirt.kubevirt.io/jsonpatch='[
  {
      "op": "add",
      "path": "/spec/configuration/cpuModel",
      "value": "<cpu_model>" 1
  }
]'
      1
      <cpu-model> を実際の CPU モデルの値に置き換えます。すべてのノードに oc describe node <node> を実行し、cpu-model-<name> ラベルを確認してこの値を判別できます。すべてのノードに存在する CPU モデルを選択します。

  • RHV 仮想マシンのインポート時に RHV Manager の誤った認証情報を入力すると、vm-import-operator が RHV API への接続を繰り返し試行するため、Manager は admin ユーザーアカウントをロックする可能性があります。(BZ#1887140)

    • アカウントのロックを解除するには、Manager にログインし、以下のコマンドを入力します。 

      $ ovirt-aaa-jdbc-tool user unlock admin

  • OpenShift Container Platform 4.8 以降で OpenShift Virtualization 2.6.5 を実行する場合、各種の問題が発生します。OpenShift Virtualization をバージョン 4.8 以降にアップグレードすると、これらの問題を回避できます。

    • Web コンソールで Virtualization ページに移動し、Create → With YAML を選択すると、以下のエラーメッセージが表示されます。 

      The server doesn't have a resource type "kind: VirtualMachine, apiVersion: kubevirt.io/v1"

      • 回避策として、apiVersion が kubevirt.io/v1alpha3 になるように VirtualMachine マニフェストを編集します。以下に例を示します。 

        apiVersion: kubevirt.io/v1alpha3
kind: VirtualMachine
metadata:
  annotations:
...

        (BZ#1979114)

    • OpenShift Virtualization Web コンソールを使用して VNC コンソールに接続すると、VNC コンソールは常に応答に失敗します。

      • 回避策として、CLI から仮想マシンを作成するか、OpenShift Virtualization 4.8 にアップグレードします。

        (BZ#1977037)