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 セクションで、以下を実行します。

    1. evictionStrategy: LiveMigrate フィールドを削除します。エビクションストラテジーの設定方法についての詳細は、仮想マシンのエビクションストラテジーの設定 を参照してください。
    2. runStrategy フィールドを Always に設定します。
  • 不明な理由により、containerDisk ボリュームタイプのメモリー消費量が、メモリー制限を超えるまで徐々に増加する可能性があります。この問題を解決するには、仮想マシンを再起動します。(BZ#1855067)

  • Web コンソールで OpenShift Virtualization Operator のサブスクリプションチャネルを編集しようとする際に、Subscription Overview の Channel ボタンをクリックすると JavaScript エラーが発生することがあります。(BZ#1796410)

    • 回避策として、以下の oc patch コマンドを実行して、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-config ConfigMap にデフォルトの CPU モデルを設定します。

      注記

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

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

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

      2. 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)