2.5. 既知の問題

  • cdrom ドライブが VMI 仕様で readonly: true に設定される場合、仮想マシンインスタンス (VMI) は移行に失敗します。以下のメッセージが表示されます: Operation not supported: Cannot migrate empty or read-only disk sdb(BZ#1927378)

  • 現時点で、一部の Containerized Data Importer (CDI) の操作は、要求時に 事前割り当て られません。これらには以下が含まれます。

    • 空のブロックディスクの作成
    • VMWare ディスクイメージのインポート

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

    • 回避策として、クローンを要求する DataVolume オブジェクトを削除します。ソースが利用可能になると、削除した DataVolume オブジェクトを再作成し、クローン操作を正常に完了できるようにします。
  • Containerized Data Importer および KubeVirt は、NFS バージョン 3 をサポートしない QEMU に依存します。したがって、NFS バージョン 4 のみがサポートされます。(BZ#1892445)

  • openshift-virtualization-os-images namespace の Fedora PVC の名前は、fedora32 ではなく fedora です。OpenShift Virtualization 2.5 以前で fedora32 PVC を設定している場合、仮想マシンは Web コンソールに表示されません。また、これを使用して別の仮想マシンのクローンを作成することはできません。(BZ#1913352)

    • 回避策として、PVC を fedora32 ではなく fedora と名付けることで、Fedora イメージをアップロードします。

  • HPP ブートソースの作成時に、ユーザーが Upload local file (creates PVC) オプション以外の方法を使用してブートソースを作成する場合、データボリュームは WaitForFirstConsumer ステータスで pending となります。(BZ#1929177)

    • 回避策として、Storage → Persistent Volume Claims Web コンソール画面で、データボリュームの基礎となる PVC の YAML を編集し、cdi.kubevirt.io/storage.bind.immediate.requested: "true" アノテーションを追加します。 

      metadata:
  annotations: cdi.kubevirt.io/storage.bind.immediate.requested: "true"

  • Fedora イメージをブートソースとして使用する場合に、ブートソースの割り当てに使用した PVC が以前にプロビジョニングされていた場合は、テンプレートに割り当てられなくなりました。(BZ#1907187) (BZ#1913352)

    • 回避策として、fedora という名前の新規 PVC をテンプレートに割り当ててから、これを使用してブートソースから仮想マシンを作成します。

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

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

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

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

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

  • ノードの CPU モデルが異なると、ライブマイグレーションに失敗します。ノードに同じ物理 CPU モデルがある場合でも、マイクロコードの更新によって導入される違いにより同じ状況が生じます。これは、デフォルト設定が、ライブマイグレーションと互換性のないホスト CPU パススルー動作をトリガーするためです。(BZ#1760028)

    • 回避策として、以下の例のように kubevirt-config 設定マップ にデフォルトの CPU モデルを設定します。

      注記

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

      1. 以下のコマンドを実行して、編集するために kubevirt-config 設定マップ を開きます。 

        $ oc edit configmap kubevirt-config -n openshift-cnv

      2. 設定マップを編集します。 

        kind: ConfigMap
metadata:
  name: kubevirt-config
data:
  default-cpu-model: "<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