9.20. CPU モデル


9.20.1. CPU モデルの選択

クラスター設定に基づいて、仮想マシンに適した CPU モデルを選択できます。同種の CPU クラスターにおいて最大のパフォーマンスと機能アクセスを提供する host-model CPU、または異なる CPU タイプの異種クラスターにおいて互換性と移行の柔軟性を確保する named CPU models のいずれかを選択します。

9.20.1.1. host-model CPU

host-model は、OpenShift Virtualization におけるデフォルトの CPU 設定です。仮想マシンインスタンス (VMI) が host-model を指定して作成されると、libvirt は VMI が最初に実行されるノードの物理 CPU に最も近い CPU モデルを自動的に選択します。ホストモデルに必要な CPU 機能は、この初期ノードに存在し、VMI のドメイン定義に含まれています。

host-model によって選択される CPU モデルは、libvirt でサポートされている標準的な名前付きモデルではないことが多く、追加の CPU 機能が含まれている場合があります。Libvirt は、初期ノードで使用可能な機能のみを含む CPU 定義を作成します。このアプローチにより、以下が確保されます。

  • VMI が初期ノードで正常に起動できます。
  • 将来のライブマイグレーション時に、ターゲットノードに異なる機能や追加の機能がある場合でも、host-model で使用されているサブセットの CPU 機能のみで対応できます。
9.20.1.1.1. 同種クラスター

同種クラスターでは、すべてのノードが同様の CPU 機能を備えています。host-model CPU モデルは、同種クラスターに推奨され、以下の利点があります。

  • 物理 CPU に最も近い仮想マシンを提供します。
  • 仮想マシンは、ノード上で利用可能なすべての CPU 機能を利用できます。
  • ライブマイグレーションは、すべてのノードが同じ CPU 機能を共有しているため、スムーズに動作します。
9.20.1.1.2. host-model を使用したライブマイグレーション

CPU モデルと機能は初期ノードによって決定されるため、VMI に公開されるホストモデルに必要なすべての CPU 機能は、将来のライブマイグレーション対象ノードにも存在する必要があります。

OpenShift Virtualization は、以下の方法で互換性を確保します。

  1. 初期ノード上のすべての host-model-required-features.node.kubevirt.io/<cpuFeature> ラベルを検出します。
  2. これらのラベルを VMI ごとに保管します。
  3. これらの同じ CPU 機能を使用して、今後のすべてのライブマイグレーションのノードセレクターを設定します。

このアプローチにより、仮想マシン移行は、VMI で実際に必要とされる CPU 機能を提供するノードのみを対象とすることが保証されます。

重要

ターゲットノードは、要求されている以上の CPU 機能をサポートしていても問題ありませんが、最低限、VMI によって使用されているすべての機能をサポートしている必要があります。

9.20.1.2. named CPU models

named CPU models を使用すると、仮想マシン (VM) の CPU タイプを明示的に選択できます。仮想マシンレベルで named CPU models を設定することも、HyperConverged カスタムリソース (CR) を使用してクラスター全体のデフォルトを設定することもできます。

ノードが named CPU models をサポートするのは、そのモデルに対して libvirt によって定義されている必要な CPU 機能をすべて備えている場合に限ります。特定の CPU モデルをサポートするノードには、cpu-model.node.kubevirt.io/<cpuModel> というラベルが付けられます。OpenShift Virtualization は、これらのラベルを使用して、互換性のあるノードにのみ仮想マシンをスケジュールします。named CPU models を設定すると、仮想マシンはノードセレクターを受け取り、その特定の CPU モデルがラベル付けされたノードでのみ実行されるようになります。

9.20.1.2.1. 異種クラスター

異種クラスターでは、ノードは異なる世代の CPU や機能セットを備えています。

仮想マシンインスタンス (VMI) は、最初にスケジュールされたノードの host model CPU 機能を継承します。初期ノードが他のノードでサポートされていない CPU 機能を備えている場合、仮想マシンを他のノードに移行することが妨げられる可能性があります。

異種クラスターの CPU モデルには、共通の named CPU model (例: EPYC-IBPB または Haswell) を使用することが推奨され、以下の利点があります。

  • 移行対象として選択されたすべてのノードが、要求される CPU 機能を確実にサポートするようにします。
  • 異なる CPU タイプのノード間での仮想マシン移行の可能性を最大限に高めます。
  • ライブマイグレーションのターゲットをサポートできないノードに仮想マシンをスケジューリングすることを防止します。
重要

異種クラスターでは、最初にスケジュールされたノードに、クラスター内の他のすべてのノードが備えていない host-model 固有の CPU 機能が含まれている場合、host-model を使用するとライブマイグレーションの選択肢が制限される可能性があります。

Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

会社概要

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

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

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

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

Legal Notice

Theme

© 2026 Red Hat
トップに戻る