1.3. MTV の既知の問題点

Red Hat Enterprise Linux (RHEL) 9 および 10 システムでは、予測可能なネットワークインターフェイス命名オーバーライド udev rename ルールが適用されます。その結果、NetworkManager は接続をアクティブ化できず、仮想マシン (VM) は静的 IP アドレスを失います。

この問題を回避するには、systemd .link ファイルを /etc/systemd/network/ ディレクトリーに手動で追加して、インターフェイスの名前を変更します。その結果、NetworkManager は接続をアクティブ化し、静的 IP アドレスを保持します。

MTV-5530

XFS v4 ファイルシステムを持つ仮想マシン (VM) を移行するには、Red Hat Enterprise Linux 9 の virt-v2v イメージを使用します。このイメージは、virt_v2v_memsize および virt_v2v_smp パラメーターをサポートしていません。その結果、これらのパラメーターを xfsCompatibility: true に設定すると、変換フェーズ中に移行が失敗します。

この問題を回避するには、Red Hat Knowledgebase ソリューション virt-v2v アプライアンスのメモリー不足により MTV Migrations が失敗するの 手順を適用してください。その結果、予期せぬ変換エラーを回避できます。

MTV-5595

VMware から OpenShift Virtualization への移行、またはユーザー定義ネットワーク (UDN) の導入は、深刻なリソース競合を引き起こす可能性があります。この競合は、72 個を超える UDN とその関連リソースを同時に作成した場合に発生します。Open vSwitch (OVS) は CPU 時間不足に陥る。さらに、リソースをアタッチする前に UDN が完全に作成されているかどうかを判断する方法はありません。その結果、Pod の準備完了までの遅延が大きくなり、ノードが NotReady 状態になる可能性があります。

この問題を回避するには、同時 UDN 作成数を 72 以下に制限してください。大規模なデプロイメントの場合は、UDN を事前に作成してください。接続されているリソースをデプロイする前に、Open Virtual Network Kubernetes (OVNK) の利用状況が安定するまでお待ちください。その結果、安定した Pod 準備完了レイテンシーを維持し、ノード障害を防ぐことができます。

MTV-5695

仮想マシン (VM) の移行中にスクリプトの実行に問題が発生し、重複したデフォルトの永続ルートが保持されます。その結果、重複した経路が移行後にネットワークの問題を引き起こす。

この問題を回避するには、重複している永続ルートを手動で削除してください。その結果、システムは正しいネットワーク設定を使用します。

MTV-5880