サポートコンソール開発者トライアルの開始お問い合わせ

2.4. 既知の問題

  • KubeMacPool ラベルを適用し、その namespace の仮想マシンの io 属性を使用して namespace の MAC アドレスプールを有効にする場合、仮想マシンに対して io 属性設定は保持されません。回避策として、仮想マシンに io 属性を使用しないでください。または、namespace に対して KubeMacPool を無効にすることができます。(BZ#1869527)

  • Container-native Virtualization 2.3 が OpenShift Container Platform 4.4 クラスターにインストールされている場合、クラスターをバージョン 4.5 にアップグレードすると、仮想マシンインスタンス (VMI) の移行が失敗する可能性があります。これは、virt-launcher Pod が virt-handler Pod に対し、移行が失敗したことを正常に通知しないために生じます。この結果、ソース VMI migrationState は更新されません。(BZ#1859661)

    • 回避策として、VMI が実行されているソースノードで virt-handler Pod を削除します。これにより、virt-handler Pod が再起動され、VMI のステータスが更新され、VMI の移行が再開します。

      1. VMI が実行されているソースノードの名前を見つけます。 

        $ oc get vmi -o wide

      2. ソースノードで virt-handler Pod を削除します。 

        $ oc delete pod -n openshift-cnv --selector=kubevirt.io=virt-handler --field-selector=spec.nodeName=<source-node-name> 1
        1
        ここで、<source-node-name> は VMI の移行元のソースノードの名前です。

  • 以前のバージョンの OpenShift Virtualization の共通テンプレートでは、デフォルトの spec.terminationGracePeriodSeconds の値が 0 でした。これらの古い共通テンプレートから作成された仮想マシンでは、ディスクが強制的に終了されることに関連する問題が生じる可能性があります。
    OpenShift Virtualization 2.4 にアップグレードする場合には、オペレーティングシステム、ワークロード、およびフレーバーの組み合わせごとに、古いバージョンと新しいバージョンの共通テンプレートが利用できます。共通のテンプレートを使用して仮想マシンを作成する場合、新しいバージョンのテンプレートを使用する必要があります。問題を回避するために、古いバージョンを無視します。(BZ#1859235)

    • 仮想マシンがこのバグの影響を受けるかどうかを確認するには、仮想マシンの namespace で以下のコマンドを実行して spec.terminationGracePeriodSeconds の値を判別します。 

      $ oc get vm <virtual-machine-name> -o yaml | grep "terminationGracePeriodSeconds"

    • 仮想マシンの terminationGracePeriodSeconds の値が 0 の場合、Linux 仮想マシンの場合は spec.terminationGracePeriodSeconds の値が 180 で、Windows 仮想マシンの場合は 3600 の値で仮想マシン設定にパッチを適用します。 

      $ oc patch vm <virtual-machine-name> --type merge -p '{"spec":{"template":{"spec":{"terminationGracePeriodSeconds":180}}}}'

  • ライブマイグレーションを実行できない仮想マシンを実行すると、OpenShift Container Platform クラスターのアップグレードがブロックされる可能性があります。これには、hostpath-provisioner ストレージまたは SR-IOV ネットワークインターフェイスを使用する仮想マシンが含まれます。回避策として、仮想マシンを再設定し、クラスターのアップグレード時にそれらの電源をオフになるようにできます。仮想マシン設定ファイルの spec セクションで、以下を実行します。

  • 不明な理由により、containerDisk ボリュームタイプのメモリー消費量が、メモリー制限を超えるまで徐々に増加する可能性があります。この問題を解決するには、仮想マシンを再起動します。(BZ#1855067)

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

    • 回避策として、以下の oc patch コマンドを実行して、CLI から OpenShift Virtualization 2.4 へのアップグレードプロセスをトリガーします。 

      $ export TARGET_NAMESPACE=openshift-cnv CNV_CHANNEL=2.4 && 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.4 にサブスクリプションをポイントし、自動更新を有効にします。

  • 移行後、仮想マシンには新規の IP アドレスが割り当てられます。ただし、コマンドの oc get vmi および oc describe vmi は古くなった IP アドレスを含む出力を依然として出力します。(BZ#1686208)

    • 回避策として、以下のコマンドを実行して正しい IP アドレスを表示します。 

      $ oc get pod -o wide

  • ノードの 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 がデプロイされているクラスターのノードでは実行しないでください。ノードは、それらの上部で実行されている仮想マシンがある場合にドレイン (解放) を実行しない可能性があります。

  • Red Hat Virtualization (RHV) 仮想マシンを OpenShift Virtualization にインポートするには、カスタム ConfigMap を作成する必要があります。
  • ターゲットの仮想マシン名が 63 文字を超える場合は、RHV 仮想マシンをインポートできません。(BZ#1857165)
  • 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 ユーザーアカウントをロックする可能性があります。アカウントのロックを解除するには、Manager にログインし、以下のコマンドを入力します。 

    $ ovirt-aaa-jdbc-tool user unlock admin
  • RHV 仮想マシンディスクが Locked 状態にある場合は、インポートする前に ディスクのロックを解除 する必要があります。
  • cloud-init 設定は RHV 仮想マシンでインポートされません。インポートプロセス後に cloud-init を再作成する必要があります。
  • OpenShift Virtualization は UEFI をサポートしません。UEFI BIOS を使用して VMware 仮想マシンを OpenShift Virtualization にインポートすると、仮想マシンは起動しません。(BZ#1880083)
Red Hat logoGithubRedditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

Red Hat をお使いのお客様が、信頼できるコンテンツが含まれている製品やサービスを活用することで、イノベーションを行い、目標を達成できるようにします。

多様性を受け入れるオープンソースの強化

Red Hat では、コード、ドキュメント、Web プロパティーにおける配慮に欠ける用語の置き換えに取り組んでいます。このような変更は、段階的に実施される予定です。詳細情報: Red Hat ブログ.

会社概要

Red Hat は、企業がコアとなるデータセンターからネットワークエッジに至るまで、各種プラットフォームや環境全体で作業を簡素化できるように、強化されたソリューションを提供しています。

© 2024 Red Hat, Inc.