2.4. 既知の問題
- OpenShift Container Platform クラスターが OVN-Kubernetes をデフォルトの Container Network Interface (CNI) プロバイダーとして使用する場合、OVN-Kubernetes のホストネットワークトポロジーの変更により、Linux ブリッジまたはボンディングをホストのデフォルトインターフェイスに割り当てることはできません。回避策として、ホストに接続されたセカンダリーネットワークインターフェイスを使用するか、OpenShift SDN デフォルト CNI プロバイダーに切り替えることができます。(BZ#1887456)
-
Web コンソールを使用して VMware Virtual Disk Development Kit (VDDK) イメージを
openshift-cnv/v2v-vmware設定マップに追加すると、Managed リソース のエラーメッセージが表示されます。このエラーは無視しても問題ありません。Save をクリックして設定マップを保存します。(BZ#1884538) - たとえば、ノードが OpenShift Container Platform クラスターのアップグレード時にメンテナーンスモードにされている場合にそれらのノードがエビクトされると、仮想マシンは 1 回ではなく 2 回移行されます。(BZ#1888790)
- アップグレード後は、オペレーティングシステムのワークロードごとに複数のテンプレートが存在する可能性があります。デフォルトのオペレーティングシステム (OS) イメージ機能を使用してクローン作成された PVC から Microsoft Windows 仮想マシンを作成する場合、OS には正しいワークロード値が定義される必要があります。Web コンソールに (Source available) ラベルが表示されていても、誤った ワークロード 値を選択すると、デフォルトの OS イメージを使用できません。デフォルトの OS イメージは新しいテンプレートに割り当てられますが、ウィザードは、デフォルトの OS イメージをサポートするように設定されていない古いテンプレートを使用する場合があります。Windows 2010 システムは Desktop のワークロード値のみをサポートしますが、Windows 2012、Windows 2016、および Windows 2019 は Server のワークロード値のみをサポートします。(BZ#1907183)
-
KubeMacPool ラベルを適用し、その namespace の仮想マシンの
io属性を使用して namespace の MAC アドレスプールを有効にする場合、仮想マシンに対してio属性設定は保持されません。回避策として、仮想マシンにio属性を使用しないでください。または、namespace に対して KubeMacPool を無効にすることができます。(BZ#1869527)
- OpenShift Virtualization 2.5 にアップグレードする場合には、オペレーティングシステム、ワークロード、およびフレーバーの組み合わせごとに、古いバージョンと新しいバージョンの共通テンプレートが利用できます。共通のテンプレートを使用して仮想マシンを作成する場合、新しいバージョンのテンプレートを使用する必要があります。問題を回避するために、古いバージョンを無視します。(BZ#1859235)
ライブマイグレーションを実行できない仮想マシンを実行すると、OpenShift Container Platform クラスターのアップグレードがブロックされる可能性があります。これには、hostpath-provisioner ストレージまたは SR-IOV ネットワークインターフェイスを使用する仮想マシンが含まれます。(BZ#1858777)
回避策として、仮想マシンを再設定し、クラスターのアップグレード時にそれらの電源をオフにするようにできます。仮想マシン設定ファイルの
specセクションで、以下を実行します。-
evictionStrategy: LiveMigrateフィールドを削除します。エビクションストラテジーの設定方法についての詳細は、仮想マシンのエビクションストラテジーの設定 を参照してください。 -
runStrategyフィールドをAlwaysに設定します。
-
-
不明な理由により、
containerDiskボリュームタイプのメモリー消費量が、メモリー制限を超えるまで徐々に増加する可能性があります。この問題を解決するには、仮想マシンを再起動します。(BZ#1855067)
Web コンソールで OpenShift Virtualization Operator のサブスクリプションチャネルを編集しようとする際に、Subscription Overview の Channel ボタンをクリックすると JavaScript エラーが発生することがあります。(BZ#1796410)
回避策として、以下の
ocpatch コマンドを実行して、CLI から OpenShift Virtualization 2.5 へのアップグレードプロセスをトリガーします。$ export TARGET_NAMESPACE=openshift-cnv CNV_CHANNEL=2.5 && oc patch -n "${TARGET_NAMESPACE}" $(oc get subscription -n ${TARGET_NAMESPACE} --no-headers -o name) --type='json' -p='[{"op": "replace", "path": "/spec/channel", "value":"'${CNV_CHANNEL}'"}, {"op": "replace", "path": "/spec/installPlanApproval", "value":"Automatic"}]'このコマンドは、アップグレードチャネル
2.5にサブスクリプションをポイントし、自動更新を有効にします。
ノードの CPU モデルが異なると、ライブマイグレーションに失敗します。ノードに同じ物理 CPU モデルがある場合でも、マイクロコードの更新によって導入される違いにより同じ状況が生じます。これは、デフォルト設定が、ライブマイグレーションと互換性のないホスト CPU パススルー動作をトリガーするためです。(BZ#1760028)
回避策として、以下の例のように
kubevirt-configConfigMap にデフォルトの CPU モデルを設定します。注記ライブマイグレーションをサポートする仮想マシンを起動する前に、この変更を行う必要があります。
以下のコマンドを実行して、編集するために
kubevirt-configConfigMap を開きます。$ oc edit configmap kubevirt-config -n openshift-cnv
ConfigMap を編集します。
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 モデルを選択します。
OpenShift Virtualization は、
oc adm drainまたはkubectl drainのいずれかを実行してトリガーされるノードのドレイン (解放) を確実に特定することができません。これらのコマンドは、OpenShift Virtualization がデプロイされているクラスターのノードでは実行しないでください。ノードは、それらの上部で実行されている仮想マシンがある場合にドレイン (解放) を実行しない可能性があります。- 現時点の解決策として、ノードをメンテナーンス状態にする 方法があります。
-
OpenShift Virtualization ストレージ PV が RHV 仮想マシンのインポートに適切でない場合、進捗バーは 10% のままとなり、インポートは完了しません。VM Import Controller Pod ログには、以下のエラーメッセージが表示されます。
Failed to bind volumes: provisioning failed for PVC(BZ#1857784)
RHV 仮想マシンのインポート時に RHV Manager の誤った認証情報を入力すると、
vm-import-operatorが RHV API への接続を繰り返し試行するため、Manager は admin ユーザーアカウントをロックする可能性があります。(BZ#1887140)アカウントのロックを解除するには、Manager にログインし、以下のコマンドを入力します。
$ ovirt-aaa-jdbc-tool user unlock admin
-
basic-user権限を持つユーザーとして OpenShift Container Platform クラスターにログインしている場合は、virtctl guestosinfo <vmi_name>を実行してゲストエージェント情報を取得することは失敗します。回避策として、oc describe vmiコマンドを実行して、ゲストエージェントデータのサブセットをフェッチできます。(BZ#2000464)
