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-imagesnamespace の Fedora PVC の名前は、fedora32ではなくfedoraです。OpenShift Virtualization 2.5 以前でfedora32PVC を設定している場合、仮想マシンは Web コンソールに表示されません。また、これを使用して別の仮想マシンのクローンを作成することはできません。(BZ#1913352)-
回避策として、PVC を
fedora32ではなくfedoraと名付けることで、Fedora イメージをアップロードします。
-
回避策として、PVC を
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セクションで、以下を実行します。-
evictionStrategy: LiveMigrateフィールドを削除します。エビクションストラテジーの設定方法についての詳細は、仮想マシンのエビクションストラテジーの設定 を参照してください。 -
runStrategyフィールドをAlwaysに設定します。
-
ノードの CPU モデルが異なると、ライブマイグレーションに失敗します。ノードに同じ物理 CPU モデルがある場合でも、マイクロコードの更新によって導入される違いにより同じ状況が生じます。これは、デフォルト設定が、ライブマイグレーションと互換性のないホスト CPU パススルー動作をトリガーするためです。(BZ#1760028)
回避策として、以下の例のように
kubevirt-config設定マップ にデフォルトの CPU モデルを設定します。注記ライブマイグレーションをサポートする仮想マシンを起動する前に、この変更を行う必要があります。
以下のコマンドを実行して、編集するために
kubevirt-config設定マップ を開きます。$ oc edit configmap kubevirt-config -n openshift-cnv
設定マップを編集します。
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
