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

9.12. 高度な仮想マシン管理

9.12.1. 仮想マシンのリソースクォータの使用
リンクのコピー

仮想マシンのリソースクォータの作成および管理

9.12.1.1. 仮想マシンの自動リソースクォータ制限を有効にする
リンクのコピー

AutoResourceLimits フィーチャーゲートを有効にすると、OpenShift Virtualization は仮想マシンの CPU とメモリーの制限を自動的に管理します。

デフォルトでは、OpenShift Virtualization は仮想マシンのリソース要求を計算します。AutoResourceLimits フィーチャーゲートを有効にすると、OpenShift Virtualization は namespace のクォータ要件を満たすためにリソース制限も計算します。

namespace で CPU とメモリーの両方のクォータが適用され、制限を設定する必要がある場合は、AutoResourceLimits フィーチャーゲートを有効にすることが推奨されます。この機能を有効にすると、メモリー制限は自動的に基本のメモリー割り当ての 2 倍に設定され、CPU 制限は仮想 CPU ごとに 1 つに設定されます。

注記

alpha.kubevirt.io/auto-memory-limits-ratio ラベルを追加することで、特定の namespace のメモリー制限比率をカスタマイズできます。

たとえば、次のコマンドは、my-virtualization-project namespace の比率を 1.2 に設定します。 

$ oc label ns/my-virtualization-project  alpha.kubevirt.io/auto-memory-limits-ratio=1.2
Copy to Clipboard Toggle word wrap

手順

仮想マシンの自動リソースクォータ制限を有効にするには、次の手順を実行します。

  1. 次のコマンドを実行して、HyperConverged カスタムリソース (CR) を編集します。 

    $ oc edit hyperconverged kubevirt-hyperconverged -n openshift-cnv
    Copy to Clipboard Toggle word wrap

  2. spec.featureGates セクションで、autoResourceLimits パラメーターを追加するか、true に設定します。 

    spec:
  featureGates:
    autoResourceLimits: true
    Copy to Clipboard Toggle word wrap
  3. 変更を保存し、エディターを終了します。
9.12.1.1.1. 仮想マシンのリソースクォータ制限を手動で設定する
リンクのコピー

リクエストのみを使用するリソースクォータは、仮想マシン (VM) で自動的に機能します。リソースクォータで制限を使用する場合は、VM に手動でリソース制限を設定する必要があります。リソース limits は、リソース requests より少なくとも 100 MiB 大きくする必要があります。

警告

リソースクォータ制限を手動で管理することは推奨されません。代わりに、前のセクションで説明したように、自動リソースクォータ制限の計算を有効にすることが推奨されます。制限を手動で設定すると、クォータの誤設定やスケジュールの問題が発生する可能性があります。

手順

  1. VirtualMachine マニフェストを編集して、VM の制限を設定します。以下に例を示します。 

    apiVersion: kubevirt.io/v1
kind: VirtualMachine
metadata:
  name: with-limits
spec:
  runStrategy: Halted
  template:
    spec:
      domain:
# ...
        resources:
          requests:
            memory: 128Mi
          limits:
            memory: 256Mi
    1
    Copy to Clipboard Toggle word wrap
    1
    この設定がサポートされるのは、limits.memory 値が requests.memory 値より少なくとも 100Mi 大きいためです。
  2. VirtualMachine マニフェストを保存します。

9.12.2. Application-Aware Quota (AAQ) Operator の設定
リンクのコピー

Application-Aware Quota (AAQ) Operator を使用して、OpenShift Container Platform クラスター内の各コンポーネントのリソースクォータをカスタマイズおよび管理できます。

9.12.2.1. AAQ Operator について
リンクのコピー

Application-Aware Quota (AAQ) Operator は、OpenShift Container Platform プラットフォームのネイティブ ResourceQuota オブジェクトよりも、さらに柔軟で拡張可能なクォータ管理を提供します。

複数のワークロードが共有のインフラストラクチャーおよびリソース上で動作するマルチテナントクラスター環境では、Kubernetes ネイティブの ResourceQuota オブジェクトを使用して CPU とメモリーの総消費量を制限すると、OpenShift Virtualization ワークロードのインフラストラクチャーオーバーヘッドとライブマイグレーションの課題が発生します。

OpenShift Virtualization では、仮想マシンのライブマイグレーションを処理し、仮想マシンのインフラストラクチャーオーバーヘッドを管理するために、大量のコンピューティングリソースを割り当てる必要があります。OpenShift Virtualization をアップグレードする場合は、仮想マシンを移行して virt-launcher Pod をアップグレードする必要があります。ただし、リソースクォータが存在する状態で仮想マシンを移行すると、移行と、その後のアップグレードが失敗する可能性があります。

AAQ を使用すると、アップグレードやノードのメンテナンスをはじめとするクラスターレベルのアクティビティーを妨げることなく、仮想マシンにリソースを割り当てることができます。AAQ Operator はコンピュートリソース以外のリソースもサポートするため、ネイティブリソースクォータと AAQ API オブジェクトを個別に管理する必要がなくなります。

9.12.2.1.1. AAQ Operator Controller とカスタムリソース
リンクのコピー

AAQ Operator は、複数の namespace をまたぐ代替クォータ実装を管理するためのカスタムリソース定義 (CRD) として定義された 2 つの新しい API オブジェクトを導入します。

  • ApplicationAwareResourceQuota: namespace ごとに適用される総クォータ制限を設定します。ApplicationAwareResourceQuota API はネイティブの ResourceQuota オブジェクトと互換性があり、同じ仕様とステータス定義を共有します。

    マニフェストの例

    apiVersion: aaq.kubevirt.io/v1alpha1
kind: ApplicationAwareResourceQuota
metadata:
  name: example-resource-quota
spec:
  hard:
    requests.memory: 1Gi
    limits.memory: 1Gi
    requests.cpu/vmi: "1"
    1 
    
    requests.memory/vmi: 1Gi
    2 
    
# ...
    Copy to Clipboard Toggle word wrap

    1
    デフォルトの namespace で仮想マシンワークロードに許可される CPU の最大量。
    2
    デフォルトの namespace で仮想マシンワークロードに許可される RAM の最大量。

  • ApplicationAwareClusterResourceQuota: ApplicationAwareResourceQuota オブジェクトをクラスタースコープでミラーリングします。これはネイティブの ClusterResourceQuota API オブジェクトと互換性があり、同じ仕様とステータス定義を共有します。AAQ クラスタークォータの作成時に、spec.selector.labels または spec.selector.annotations フィールドを編集して、選択したアノテーションかラベル、もしくはその両方に基づいて複数の namespace を選択できます。

    マニフェストの例

    apiVersion: aaq.kubevirt.io/v1alpha1
kind: ApplicationAwareClusterResourceQuota
    1 
    
metadata:
  name: example-resource-quota
spec:
  quota:
    hard:
      requests.memory: 1Gi
      limits.memory: 1Gi
      requests.cpu/vmi: "1"
      requests.memory/vmi: 1Gi
  selector:
    annotations: null
    labels:
      matchLabels:
        kubernetes.io/metadata.name: default
# ...
    Copy to Clipboard Toggle word wrap

    1
    ApplicationAwareClusterResourceQuota オブジェクトは、HyperConverged カスタムリソース (CR) の spec.allowApplicationAwareClusterResourceQuota フィールドが true に設定されている場合に限り作成できます。
    注記

    spec.selector.labels フィールドと spec.selector.annotations フィールドの両方が設定されている場合は、両方に一致する namespace のみが選択されます。

AAQ コントローラーは、スケジューリングゲートメカニズムを使用して、ワークロードを実行するために使用できるリソースが十分にあるか評価します。そうである場合、スケジューリングゲートは Pod から削除され、スケジューリングの準備が整ったと見なされます。クォータ使用状況ステータスが更新され、使用されているクォータの量が表示されます。

ワークロードの CPU およびメモリー requests と limits が強制されたクォータ使用量制限を超える場合、十分なクォータが利用可能になるまで Pod は SchedulingGated ステータスのままになります。AAQ コントローラーは、詳しいクォータ超過理由を含む Warning タイプのイベントを作成します。oc get events コマンドを使用してイベントの詳細を表示できます。

重要

spec.nodeName フィールドが特定のノードに設定されている Pod は、HyperConverged CR で定義されている spec.namespaceSelector ラベルと一致する namespace を使用できません。

9.12.2.2. AAQ Operator の有効化
リンクのコピー

AAQ Operator をデプロイするには、HyperConverged カスタムリソース (CR) で enableApplicationAwareQuota フィーチャーゲートを true に設定します。

前提条件

  • cluster-admin 権限を持つユーザーとしてクラスターにアクセスできる。
  • OpenShift CLI (oc) がインストールされている。

手順

  • 次のコマンドを実行して、HyperConverged CR で enableApplicationAwareQuota フィーチャーゲートを true に設定します。 

    $ oc patch hco kubevirt-hyperconverged -n openshift-cnv \
 --type json -p '[{"op": "add", "path": "/spec/featureGates/enableApplicationAwareQuota", "value": true}]'
    Copy to Clipboard Toggle word wrap

9.12.2.3. CLI を使用して AAQ Operator を設定する
リンクのコピー

HyperConverged カスタムリソース (CR) の spec.applicationAwareConfig オブジェクトのフィールドを指定して、AAQ Operator を設定できます。

前提条件

  • cluster-admin 権限を持つユーザーとしてクラスターにアクセスできる。
  • OpenShift CLI (oc) がインストールされている。

手順

  • 以下のコマンドを実行して、HyperConverged CR を更新します。 

    $ oc patch hco kubevirt-hyperconverged -n openshift-cnv --type merge -p '{
  "spec": {
    "applicationAwareConfig": {
      "vmiCalcConfigName": "DedicatedVirtualResources",
      "namespaceSelector": {
        "matchLabels": {
          "app": "my-app"
        }
      },
      "allowApplicationAwareClusterResourceQuota": true
    }
  }
}'
    Copy to Clipboard Toggle word wrap

    ここでは、以下のようになります。

    vmiCalcConfigName

    仮想マシンワークロードを実行する Pod のリソースカウント管理方法を指定します。可能な値は次のとおりです。

    • VmiPodUsage: ネイティブリソースクォータと同じ方法で、仮想マシンに関連付けられた Pod のコンピュートリソースをカウントします。移行関連のリソースは除外します。
    • VirtualResources: メモリーには仮想マシンの RAM サイズ、処理には仮想 CPU を使用して、仮想マシン仕様に基づきコンピュートリソースをカウントします。
    • DedicatedVirtualResources (デフォルト): VirtualResources と似ていますが、CPU およびメモリーリソース名に接尾辞として /vmi を追加することで、仮想マシンに関連付けられた Pod のリソース追跡を分離します。たとえば、requests.cpu/vmi と requests.memory/vmi です。
    namespaceSelector
    Pod の作成時に AAQ スケジューリングゲートを追加する namespace を決定します。namespace セレクターが定義されていない場合、AAQ Operator はデフォルトで application-aware-quota/enable-gating ラベルを持つ namespace をターゲットにします。
    allowApplicationAwareClusterResourceQuota
    true に設定すると、ApplicationAwareClusterResourceQuota オブジェクトを作成および管理できます。この属性を true に設定すると、スケジュール時間が長くなる可能性があります。

9.12.3. 仮想マシンのノードの指定
リンクのコピー

ノードの配置ルールを使用して、仮想マシン (VM) を特定のノードに配置することができます。

9.12.3.1. 仮想マシンのノード配置について
リンクのコピー

仮想マシン (VM) が適切なノードで実行されるようにするには、ノードの配置ルールを設定できます。以下の場合にこれを行うことができます。

  • 仮想マシンが複数ある。フォールトトレランスを確保するために、これらを異なるノードで実行する必要がある。
  • 2 つの相互間のネットワークトラフィックの多い chatty VM がある。冗長なノード間のルーティングを回避するには、仮想マシンを同じノードで実行します。
  • 仮想マシンには、利用可能なすべてのノードにない特定のハードウェア機能が必要です。
  • 機能をノードに追加する Pod があり、それらの機能を使用できるように仮想マシンをそのノードに配置する必要があります。
注記

仮想マシンの配置は、ワークロードの既存のノードの配置ルールに基づきます。ワークロードがコンポーネントレベルの特定のノードから除外される場合、仮想マシンはそれらのノードに配置できません。

以下のルールタイプは、VirtualMachine マニフェストの spec フィールドで使用できます。

nodeSelector
このフィールドで指定したキーと値のペアでラベル付けされたノード上で仮想マシンをスケジュールできるようにします。ノードには、リスト表示されたすべてのペアに一致するラベルがなければなりません。
affinity
より表現的な構文を使用して、ノードと仮想マシンに一致するルールを設定できます。たとえば、ルールがハード要件ではなく基本設定になるように指定し、ルールの条件が満たされない場合も仮想マシンがスケジュールされるようにすることができます。Pod のアフィニティー、Pod の非アフィニティー、およびノードのアフィニティーは仮想マシンの配置でサポートされます。Pod のアフィニティーは仮想マシンに対して動作します。VirtualMachine ワークロードタイプは Pod オブジェクトに基づくためです。
tolerations

一致する taint を持つノードに仮想マシンをスケジュールすることを許容します。ノードに taint が適用されると、そのノードはその taint を許容する仮想マシンのみを受け入れます。

注記

アフィニティールールは、スケジューリング時にのみ適用されます。OpenShift Container Platform は、制約を満たさなくなった場合に実行中のワークロードを再スケジューリングしません。

9.12.3.2. ノード配置の例
リンクのコピー

以下の YAML スニペットの例では、nodePlacement、affinity、および tolerations フィールドを使用して仮想マシンのノード配置をカスタマイズします。

9.12.3.2.1. 例: nodeSelector を使用した仮想マシンノードの配置
リンクのコピー

この例では、仮想マシンに example-key-1 = example-value-1 および example-key-2 = example-value-2 ラベルの両方が含まれるメタデータのあるノードが必要です。

警告

この説明に該当するノードがない場合、仮想マシンはスケジュールされません。

仮想マシンマニフェストの例

metadata:
  name: example-vm-node-selector
apiVersion: kubevirt.io/v1
kind: VirtualMachine
spec:
  template:
    spec:
      nodeSelector:
        example-key-1: example-value-1
        example-key-2: example-value-2
# ...
Copy to Clipboard Toggle word wrap

この例では、仮想マシンはラベル example-key-1 = example-value-1 を持つ実行中の Pod のあるノードでスケジュールされる必要があります。このようなノードで実行中の Pod がない場合、仮想マシンはスケジュールされません。

可能な場合に限り、仮想マシンはラベル example-key-2 = example-value-2 を持つ Pod のあるノードではスケジュールされません。ただし、すべての候補となるノードにこのラベルを持つ Pod がある場合、スケジューラーはこの制約を無視します。

仮想マシンマニフェストの例

metadata:
  name: example-vm-pod-affinity
apiVersion: kubevirt.io/v1
kind: VirtualMachine
spec:
  template:
    spec:
      affinity:
        podAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
1 

          - labelSelector:
              matchExpressions:
              - key: example-key-1
                operator: In
                values:
                - example-value-1
            topologyKey: kubernetes.io/hostname
        podAntiAffinity:
          preferredDuringSchedulingIgnoredDuringExecution:
2 

          - weight: 100
            podAffinityTerm:
              labelSelector:
                matchExpressions:
                - key: example-key-2
                  operator: In
                  values:
                  - example-value-2
              topologyKey: kubernetes.io/hostname
# ...
Copy to Clipboard Toggle word wrap

1
requiredDuringSchedulingIgnoredDuringExecution ルールタイプを使用する場合、制約を満たさない場合には仮想マシンはスケジュールされません。
2
preferredDuringSchedulingIgnoredDuringExecution ルールタイプを使用する場合、この制約を満たさない場合でも、必要なすべての制約を満たす場合に仮想マシンは依然としてスケジュールされます。
9.12.3.2.3. 例: ノードのアフィニティーによる仮想マシンノードの配置
リンクのコピー

この例では、仮想マシンはラベル example.io/example-key = example-value-1 またはラベル example.io/example-key = example-value-2 を持つノードでスケジュールされる必要があります。この制約は、ラベルのいずれかがノードに存在する場合に満たされます。いずれのラベルも存在しない場合、仮想マシンはスケジュールされません。

可能な場合、スケジューラーはラベル example-node-label-key = example-node-label-value を持つノードを回避します。ただし、すべての候補となるノードにこのラベルがある場合、スケジューラーはこの制約を無視します。

仮想マシンマニフェストの例

metadata:
  name: example-vm-node-affinity
apiVersion: kubevirt.io/v1
kind: VirtualMachine
spec:
  template:
    spec:
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
1 

            nodeSelectorTerms:
            - matchExpressions:
              - key: example.io/example-key
                operator: In
                values:
                - example-value-1
                - example-value-2
          preferredDuringSchedulingIgnoredDuringExecution:
2 

          - weight: 1
            preference:
              matchExpressions:
              - key: example-node-label-key
                operator: In
                values:
                - example-node-label-value
# ...
Copy to Clipboard Toggle word wrap

1
requiredDuringSchedulingIgnoredDuringExecution ルールタイプを使用する場合、制約を満たさない場合には仮想マシンはスケジュールされません。
2
preferredDuringSchedulingIgnoredDuringExecution ルールタイプを使用する場合、この制約を満たさない場合でも、必要なすべての制約を満たす場合に仮想マシンは依然としてスケジュールされます。
9.12.3.2.4. 例: toleration を使用した仮想マシンノードの配置
リンクのコピー

この例では、仮想マシン用に予約されているノードに、すでに key=virtualization:NoSchedule taint のラベルが付けられています。この仮想マシンには一致する tolerations があるため、この仮想マシンを taint を持つノードにスケジュールできます。

注記

taint を許容する仮想マシンを、その taint を持つノードにスケジュールする必要はありません。

仮想マシンマニフェストの例

metadata:
  name: example-vm-tolerations
apiVersion: kubevirt.io/v1
kind: VirtualMachine
spec:
  tolerations:
  - key: "key"
    operator: "Equal"
    value: "virtualization"
    effect: "NoSchedule"
# ...
Copy to Clipboard Toggle word wrap

9.12.4. デフォルトの CPU モデルの設定
リンクのコピー

HyperConverged カスタムリソース (CR) の defaultCPUModel 設定を使用して、クラスター全体のデフォルト CPU モデルを定義します。

仮想マシン (VM) の CPU モデルは、仮想マシンおよびクラスター内の CPU モデルの可用性によって異なります。

  • 仮想マシンに定義された CPU モデルがない場合:

    • defaultCPUModel は、クラスター全体のレベルで定義された CPU モデルを使用して自動的に設定されます。

  • 仮想マシンとクラスターの両方に CPU モデルが定義されている場合:

    • 仮想マシンの CPU モデルが優先されます。

  • 仮想マシンにもクラスターにも CPU モデルが定義されていない場合:

    • ホストモデルは、ホストレベルで定義された CPU モデルを使用して自動的に設定されます。

9.12.4.1. デフォルトの CPU モデルの設定
リンクのコピー

HyperConverged カスタムリソース (CR) を更新して、defaultCPUModel を設定します。OpenShift Virtualization の実行中に、defaultCPUModel を変更できます。

注記

defaultCPUModel では、大文字と小文字が区別されます。

前提条件

  • OpenShift CLI (oc) のインストール。

手順

  1. 以下のコマンドを実行して HyperConverged CR を開きます。 

    $ oc edit hyperconverged kubevirt-hyperconverged -n openshift-cnv
    Copy to Clipboard Toggle word wrap

  2. CR に defaultCPUModel フィールドを追加し、値をクラスター内に存在する CPU モデルの名前に設定します。 

    apiVersion: hco.kubevirt.io/v1beta1
kind: HyperConverged
metadata:
 name: kubevirt-hyperconverged
 namespace: openshift-cnv
spec:
  defaultCPUModel: "EPYC"
    Copy to Clipboard Toggle word wrap
  3. YAML ファイルをクラスターに適用します。

9.12.5. 仮想マシンに UEFI モードを使用する
リンクのコピー

Unified Extensible Firmware Interface (UEFI) モードで仮想マシン (VM) を起動できます。

9.12.5.1. 仮想マシンの UEFI モードについて
リンクのコピー

レガシー BIOS などの Unified Extensible Firmware Interface (UEFI) は、コンピューターの起動時にハードウェアコンポーネントやオペレーティングシステムのイメージファイルを初期化します。UEFI は BIOS よりも最新の機能とカスタマイズオプションをサポートするため、起動時間を短縮できます。

これは、.efi 拡張子を持つファイルに初期化と起動に関する情報をすべて保存します。このファイルは、EFI System Partition (ESP) と呼ばれる特別なパーティションに保管されます。ESP には、コンピューターにインストールされるオペレーティングシステムのブートローダープログラムも含まれます。

9.12.5.2. UEFI モードでの仮想マシンの起動
リンクのコピー

VirtualMachine マニフェストを編集して、UEFI モードで起動するように仮想マシンを設定できます。

前提条件

  • OpenShift CLI (oc) がインストールされている。

手順

  1. VirtualMachine マニフェストファイルを編集または作成します。spec.firmware.bootloader スタンザを使用して、UEFI モードを設定します。

    セキュアブートがアクティブな状態の UEFI モードでのブート

    apiversion: kubevirt.io/v1
kind: VirtualMachine
metadata:
  labels:
    special: vm-secureboot
  name: vm-secureboot
spec:
  template:
    metadata:
      labels:
        special: vm-secureboot
    spec:
      domain:
        devices:
          disks:
          - disk:
              bus: virtio
            name: containerdisk
        features:
          acpi: {}
          smm:
            enabled: true
    1 
    
        firmware:
          bootloader:
            efi:
              secureBoot: true
    2 
    
# ...
    Copy to Clipboard Toggle word wrap

    1
    OpenShift Virtualization では、UEFI モードでセキュアブートを実行するために SMM (System Management Mode) を有効にする必要があります。
    2
    OpenShift Virtualization は、UEFI モードを使用する場合に、セキュアブートの有無に関わらず、仮想マシンをサポートします。セキュアブートが有効な場合には、UEFI モードが必要です。ただし、セキュアブートを使用せずに UEFI モードを有効にできます。

  2. 以下のコマンドを実行して、マニフェストをクラスターに適用します。 

    $ oc create -f <file_name>.yaml
    Copy to Clipboard Toggle word wrap

9.12.5.3. 永続的な EFI の有効化
リンクのコピー

クラスターレベルで RWX ストレージクラスを設定し、仮想マシンの EFI セクションで設定を調整することで、仮想マシンで EFI 永続性を有効にできます。

前提条件

  • クラスター管理者の権限がある。
  • RWX アクセスモードと FS ボリュームモードをサポートするストレージクラスが必要です。
  • OpenShift CLI (oc) がインストールされている。

手順

  • 次のコマンドを実行して、VMPersistentState フィーチャーゲートを有効にします。 

    $ oc patch hyperconverged kubevirt-hyperconverged -n openshift-cnv \
  --type json -p '[{"op":"replace","path":"/spec/featureGates/VMPersistentState", "value": true}]'
    Copy to Clipboard Toggle word wrap

9.12.5.4. 永続的な EFI を使用した仮想マシンの設定
リンクのコピー

マニフェストファイルを編集して、EFI の永続性を有効にするように仮想マシンを設定できます。

前提条件

  • VMPersistentState フィーチャーゲートが有効になっている。

手順

  • 仮想マシンマニフェストファイルを編集して保存し、設定を適用します。 

    apiVersion: kubevirt.io/v1
kind: VirtualMachine
metadata:
  name: vm
spec:
  template:
    spec:
      domain:
        firmware:
          bootloader:
            efi:
              persistent: true
# ...
    Copy to Clipboard Toggle word wrap

9.12.6. 仮想マシンの PXE ブートの設定
リンクのコピー

PXE ブートまたはネットワークブートは OpenShift Virtualization で利用できます。ネットワークブートにより、ローカルに割り当てられたストレージデバイスなしにコンピューターを起動し、オペレーティングシステムまたは他のプログラムを起動し、ロードすることができます。たとえば、これにより、新規ホストのデプロイ時に PXE サーバーから必要な OS イメージを選択できます。

9.12.6.1. MAC アドレスを指定した PXE ブート
リンクのコピー

まず、管理者は PXE ネットワークの NetworkAttachmentDefinition オブジェクトを作成し、ネットワーク経由でクライアントを起動できます。次に、仮想マシンインスタンスの設定ファイルで Network Attachment Definition を参照して仮想マシンインスタンスを起動します。また PXE サーバーで必要な場合には、仮想マシンインスタンスの設定ファイルで MAC アドレスを指定することもできます。

前提条件

  • Linux ブリッジが接続されている。
  • PXE サーバーがブリッジとして同じ VLAN に接続されている。
  • OpenShift CLI (oc) がインストールされている。

手順

  1. クラスターに PXE ネットワークを設定します。

    1. PXE ネットワーク pxe-net-conf の Network Attachment Definition ファイルを作成します。 

      apiVersion: "k8s.cni.cncf.io/v1"
kind: NetworkAttachmentDefinition
metadata:
  name: pxe-net-conf
      1 
      
spec:
  config: |
    {
      "cniVersion": "0.3.1",
      "name": "pxe-net-conf",
      2 
      
      "type": "bridge",
      3 
      
      "bridge": "bridge-interface",
      4 
      
      "macspoofchk": false,
      5 
      
      "vlan": 100,
      6 
      
      "disableContainerInterface": true,
      "preserveDefaultVlan": false
      7 
      
    }
      Copy to Clipboard Toggle word wrap
      1
      NetworkAttachmentDefinition オブジェクトの名前。
      2
      設定の名前。設定名を Network Attachment Definition の name 値に一致させることが推奨されます。
      3
      この Network Attachment Definition のネットワークを提供する Container Network Interface (CNI) プラグインの実際の名前。この例では、Linux bridge CNI プラグインを使用します。OVN-Kubernetes localnet または SR-IOV CNI プラグインを使用することもできます。
      4
      ノードに設定される Linux ブリッジの名前。
      5
      オプション: MAC スプーフィングチェックを有効にするフラグ。true に設定すると、Pod またはゲストインターフェイスの MAC アドレスを変更できません。この属性により、Pod から出ることができる MAC アドレスは 1 つだけになり、MAC スプーフィング攻撃に対するセキュリティーが確保されます。
      6
      オプション: VLAN タグ。Node Network Configuration Policy では、追加の VLAN 設定は必要ありません。
      7
      オプション: 仮想マシンがデフォルト VLAN 経由でブリッジに接続するかどうかを示します。デフォルト値は true です。

  2. 直前の手順で作成したファイルを使用して Network Attachment Definition を作成します。 

    $ oc create -f pxe-net-conf.yaml
    Copy to Clipboard Toggle word wrap

  3. 仮想マシンインスタンス設定ファイルを、インターフェイスおよびネットワークの詳細を含めるように編集します。

    1. PXE サーバーで必要な場合には、ネットワークおよび MAC アドレスを指定します。MAC アドレスが指定されていない場合、値は自動的に割り当てられます。

      bootOrder が 1 に設定されており、インターフェイスが最初に起動することを確認します。この例では、インターフェイスは <pxe-net> というネットワークに接続されています。 

      interfaces:
- masquerade: {}
  name: default
- bridge: {}
  name: pxe-net
  macAddress: de:00:00:00:00:de
  bootOrder: 1
      Copy to Clipboard Toggle word wrap
      注記

      複数のインターフェイスおよびディスクのブートの順序はグローバル順序になります。

    2. オペレーティングシステムのプロビジョニング後に起動が適切に実行されるよう、ブートデバイス番号をディスクに割り当てます。

      ディスク bootOrder の値を 2 に設定します。 

      devices:
  disks:
  - disk:
      bus: virtio
    name: containerdisk
    bootOrder: 2
      Copy to Clipboard Toggle word wrap

    3. 直前に作成された Network Attachment Definition に接続されるネットワークを指定します。このシナリオでは、<pxe-net> は <pxe-net-conf> という Network Attachment Definition に接続されます。 

      networks:
- name: default
  pod: {}
- name: pxe-net
  multus:
    networkName: pxe-net-conf
      Copy to Clipboard Toggle word wrap

  4. 仮想マシンインスタンスを作成します。 

    $ oc create -f vmi-pxe-boot.yaml
    Copy to Clipboard Toggle word wrap

    出力例

      virtualmachineinstance.kubevirt.io "vmi-pxe-boot" created
    Copy to Clipboard Toggle word wrap

  5. 仮想マシンインスタンスの実行を待機します。 

    $ oc get vmi vmi-pxe-boot -o yaml | grep -i phase
  phase: Running
    Copy to Clipboard Toggle word wrap

  6. VNC を使用して仮想マシンインスタンスを表示します。 

    $ virtctl vnc vmi-pxe-boot
    Copy to Clipboard Toggle word wrap
  7. ブート画面で、PXE ブートが正常に実行されていることを確認します。

  8. 仮想マシンインスタンスにログインします。 

    $ virtctl console vmi-pxe-boot
    Copy to Clipboard Toggle word wrap

検証

  1. 仮想マシンのインターフェイスおよび MAC アドレスを確認し、ブリッジに接続されたインターフェイスに MAC アドレスが指定されていることを確認します。この場合、PXE ブートには IP アドレスなしに eth1 を使用しています。他のインターフェイス eth0 は OpenShift Container Platform から IP アドレスを取得しています。 

    $ ip addr
    Copy to Clipboard Toggle word wrap

    出力例

    ...
3. eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
   link/ether de:00:00:00:00:de brd ff:ff:ff:ff:ff:ff
    Copy to Clipboard Toggle word wrap

9.12.6.2. OpenShift Virtualization ネットワークの用語集
リンクのコピー

以下の用語は、OpenShift Virtualization ドキュメント全体で使用されています。

Container Network Interface (CNI)
コンテナーのネットワーク接続に重点を置く Cloud Native Computing Foundation プロジェクト。OpenShift Virtualization は CNI プラグインを使用して基本的な Kubernetes ネットワーク機能を強化します。
Multus
複数の CNI の存在を可能にし、Pod または仮想マシンが必要なインターフェイスを使用できるようにする "メタ" CNI プラグイン。
カスタムリソース定義 (CRD)
カスタムリソースの定義を可能にする Kubernetes API リソース、または CRD API リソースを使用して定義されるオブジェクト。
Network Attachment Definition (NAD)
Multus プロジェクトによって導入された CRD。Pod、仮想マシン、および仮想マシンインスタンスを 1 つ以上のネットワークに接続できるようにします。
UserDefinedNetwork (UDN)
ユーザー定義ネットワーク API によって導入された namespace スコープの CRD。これを使用して、テナント namespace を他の namespace から分離するテナントネットワークを作成できます。
ClusterUserDefinedNetwork (CUDN)
ユーザー定義ネットワーク API によって導入されたクラスタースコープの CRD。これは、クラスター管理者が複数の namespace 全体で共有ネットワークを作成するために使用できます。
Node Network Configuration Policy (NNCP)
nmstate プロジェクトによって導入された CRD。ノード上で要求されるネットワーク設定を表します。NodeNetworkConfigurationPolicy マニフェストをクラスターに適用して、インターフェイスの追加および削除など、ノードネットワーク設定を更新します。

9.12.7. 仮想マシンでの Huge Page の使用
リンクのコピー

Huge Page は、クラスター内の仮想マシンのバッキングメモリーとして使用できます。

9.12.7.1. Huge Page の機能
リンクのコピー

メモリーは Page と呼ばれるブロックで管理されます。多くのシステムでは、1 ページは 4Ki です。メモリー 1Mi は 256 ページに、メモリー 1Gi は 256,000 ページに相当します。CPU には、内蔵のメモリー管理ユニットがあり、ハードウェアでこのようなページリストを管理します。トランスレーションルックアサイドバッファー (TLB: Translation Lookaside Buffer) は、仮想から物理へのページマッピングの小規模なハードウェアキャッシュのことです。ハードウェアの指示で渡された仮想アドレスが TLB にあれば、マッピングをすばやく決定できます。そうでない場合には、TLB ミスが発生し、システムは速度が遅く、ソフトウェアベースのアドレス変換にフォールバックされ、パフォーマンスの問題が発生します。TLB のサイズは固定されているので、TLB ミスの発生率を減らすには Page サイズを大きくする必要があります。

Huge Page とは、4Ki より大きいメモリーページのことです。x86_64 アーキテクチャーでは、2Mi と 1Gi の 2 つが一般的な Huge Page サイズです。別のアーキテクチャーではサイズは異なります。Huge Page を使用するには、アプリケーションが認識できるようにコードを書き込む必要があります。Transparent Huge Page (THP) は、アプリケーションによる認識なしに、Huge Page の管理を自動化しようとしますが、制約があります。特に、ページサイズは 2Mi に制限されます。THP では、THP のデフラグが原因で、メモリー使用率が高くなり、断片化が起こり、パフォーマンスの低下につながり、メモリーページがロックされてしまう可能性があります。このような理由から、アプリケーションは THP ではなく、事前割り当て済みの Huge Page を使用するように設計 (また推奨) される場合があります。

OpenShift Virtualization では、事前に割り当てられた Huge Page を使用できるように仮想マシンを設定できます。

9.12.7.2. 仮想マシンの Huge Page の設定
リンクのコピー

memory.hugepages.pageSize および resources.requests.memory パラメーターを仮想マシン設定に組み込み、仮想マシンを事前に割り当てられた Huge Page を使用するように設定できます。

メモリー要求はページサイズ別に分ける必要があります。たとえば、ページサイズ 1Gi の場合に 500Mi メモリーを要求することはできません。

注記

ホストおよびゲスト OS のメモリーレイアウトには関連性がありません。仮想マシンマニフェストで要求される Huge Page が QEMU に適用されます。ゲスト内の Huge Page は、仮想マシンインスタンスの利用可能なメモリー量に基づいてのみ設定できます。

実行中の仮想マシンを編集する場合は、変更を有効にするために仮想マシンを再起動する必要があります。

前提条件

  • ノードには、事前に割り当てられた Huge Page が設定されている必要がある。
  • OpenShift CLI (oc) がインストールされている。

手順

  1. 仮想マシン設定で、resources.requests.memory および memory.hugepages.pageSize パラメーターを spec.domain に追加します。以下の設定スニペットは、ページサイズが 1Gi の合計 4Gi メモリーを要求する仮想マシンに関するものです。 

    kind: VirtualMachine
# ...
spec:
  domain:
    resources:
      requests:
        memory: "4Gi"
    1 
    
    memory:
      hugepages:
        pageSize: "1Gi"
    2 
    
# ...
    Copy to Clipboard Toggle word wrap
    1
    仮想マシンに要求されるメモリーの合計量。この値はページサイズで分ける必要があります。
    2
    各 Huge Page のサイズ。x86_64 アーキテクチャーの有効な値は 1Gi および 2Mi です。ページサイズは要求されたメモリーよりも小さくなければなりません。

  2. 仮想マシン設定を適用します。 

    $ oc apply -f <virtual_machine>.yaml
    Copy to Clipboard Toggle word wrap

9.12.8. 仮想マシン用の専用リソースの有効化
リンクのコピー

パフォーマンスを向上させるために、CPU などのノードリソースを仮想マシン専用に確保できます。

9.12.8.1. 専用リソースについて
リンクのコピー

仮想マシンの専用リソースを有効にする場合、仮想マシンのワークロードは他のプロセスで使用されない CPU でスケジュールされます。専用リソースを使用することで、仮想マシンのパフォーマンスとレイテンシーの予測の精度を向上させることができます。

9.12.8.2. 仮想マシンの専用リソースの有効化
リンクのコピー

Details タブで、仮想マシンの専用リソースを有効にすることができます。Red Hat テンプレートから作成された仮想マシンは、専用のリソースで設定できます。

前提条件

  • CPU Manager がノードに設定されている。仮想マシンのワークロードをスケジュールする前に、ノードに cpumanager = true ラベルが設定されていることを確認する。
  • 仮想マシンの電源がオフになっている。

手順

  1. OpenShift Container Platform コンソールで、サイドメニューから Virtualization VirtualMachines をクリックします。
  2. 仮想マシンを選択して、VirtualMachine details ページを開きます。
  3. Configuration Scheduling タブで、Dedicated Resources の横にある編集アイコンをクリックします。
  4. Schedule this workload with dedicated resources (guaranteed policy) を選択します。
  5. Save をクリックします。

9.12.9. 仮想マシンのスケジュール
リンクのコピー

仮想マシンの CPU モデルとポリシー属性が、ノードがサポートする CPU モデルおよびポリシー属性との互換性に対して一致することを確認して、ノードで仮想マシン (VM) をスケジュールできます。

9.12.9.1. ポリシー属性
リンクのコピー

仮想マシン (VM) をスケジュールするには、ポリシー属性と、仮想マシンがノードでスケジュールされる際の互換性について一致する CPU 機能を指定します。仮想マシンに指定されるポリシー属性は、その仮想マシンをノードにスケジュールする方法を決定します。

Expand
ポリシー属性説明

force

仮想マシンは強制的にノードでスケジュールされます。これは、ホストの CPU が仮想マシンの CPU に対応していない場合でも該当します。

require

仮想マシンが特定の CPU モデルおよび機能仕様で設定されていない場合に仮想マシンに適用されるデフォルトのポリシー。このデフォルトポリシー属性または他のポリシー属性のいずれかを持つ CPU ノードの検出をサポートするようにノードが設定されていない場合、仮想マシンはそのノードでスケジュールされません。ホストの CPU が仮想マシンの CPU をサポートしているか、ハイパーバイザーが対応している CPU モデルをエミュレートできる必要があります。

optional

仮想マシンがホストの物理マシンの CPU でサポートされている場合は、仮想マシンがノードに追加されます。

disable

仮想マシンは CPU ノードの検出機能と共にスケジュールすることはできません。

forbid

この機能がホストの CPU でサポートされ、CPU ノード検出が有効になっている場合でも、仮想マシンはスケジュールされません。

9.12.9.2. ポリシー属性および CPU 機能の設定
リンクのコピー

それぞれの仮想マシン (VM) にポリシー属性および CPU 機能を設定して、これがポリシーおよび機能に従ってノードでスケジュールされるようにすることができます。設定する CPU 機能は、ホストの CPU によってサポートされ、またはハイパーバイザーがエミュレートされることを確認するために検証されます。

手順

  • 仮想マシン設定ファイルの domain spec を編集します。以下の例では、仮想マシン (VM) の CPU 機能および require ポリシーを設定します。 

    apiVersion: kubevirt.io/v1
kind: VirtualMachine
metadata:
  name: myvm
spec:
  template:
    spec:
      domain:
        cpu:
          features:
            - name: apic
    1 
    
              policy: require
    2
    Copy to Clipboard Toggle word wrap
    1
    仮想マシンの名前。
    2
    仮想マシンのポリシー属性。

9.12.9.3. サポートされている CPU モデルでの仮想マシンのスケジューリング
リンクのコピー

仮想マシン (VM) の CPU モデルを設定して、CPU モデルがサポートされるノードにこれをスケジュールできます。

手順

  • 仮想マシン設定ファイルの domain spec を編集します。以下の例は、VM 向けに定義された特定の CPU モデルを示しています。 

    apiVersion: kubevirt.io/v1
kind: VirtualMachine
metadata:
  name: myvm
spec:
  template:
    spec:
      domain:
        cpu:
          model: Conroe
    1
    Copy to Clipboard Toggle word wrap
    1
    VM の CPU モデル。

9.12.9.4. ホストモデルでの仮想マシンのスケジューリング
リンクのコピー

仮想マシン (VM) の CPU モデルが host-model に設定されている場合、仮想マシンはスケジュールされているノードの CPU モデルを継承します。

手順

  • 仮想マシン設定ファイルの domain spec を編集します。以下の例は、仮想マシンに指定される host-model を示しています。 

    apiVersion: kubevirt/v1alpha3
kind: VirtualMachine
metadata:
  name: myvm
spec:
  template:
    spec:
      domain:
        cpu:
          model: host-model
    1
    Copy to Clipboard Toggle word wrap
    1
    スケジュールされるノードの CPU モデルを継承する仮想マシン。

9.12.9.5. カスタムスケジューラーを使用した仮想マシンのスケジュール設定
リンクのコピー

カスタムスケジューラーを使用して、ノード上の仮想マシンをスケジュールできます。

前提条件

  • セカンダリースケジューラーがクラスター用に設定されています。
  • OpenShift CLI (oc) がインストールされている。

手順

  • VirtualMachine マニフェストを編集して、カスタムスケジューラーを仮想マシン設定に追加します。以下に例を示します。 

    apiVersion: kubevirt.io/v1
kind: VirtualMachine
metadata:
  name: vm-fedora
spec:
  runStrategy: Always
  template:
    spec:
      schedulerName: my-scheduler
    1 
    
      domain:
        devices:
          disks:
            - name: containerdisk
              disk:
                bus: virtio
# ...
    Copy to Clipboard Toggle word wrap
    1
    カスタムスケジューラーの名前。schedulerName 値が既存のスケジューラーと一致しない場合、virt-launcher Pod は、指定されたスケジューラーが見つかるまで Pending 状態のままになります。

検証

  • virt-launcher Pod イベントをチェックして、仮想マシンが VirtualMachine マニフェストで指定されたカスタムスケジューラーを使用していることを確認します。

    1. 次のコマンドを入力して、クラスター内の Pod のリストを表示します。 

      $ oc get pods
      Copy to Clipboard Toggle word wrap

      出力例

      NAME                             READY   STATUS    RESTARTS   AGE
virt-launcher-vm-fedora-dpc87    2/2     Running   0          24m
      Copy to Clipboard Toggle word wrap

    2. 次のコマンドを実行して Pod イベントを表示します。 

      $ oc describe pod virt-launcher-vm-fedora-dpc87
      Copy to Clipboard Toggle word wrap

      出力の From フィールドの値により、スケジューラー名が VirtualMachine マニフェストで指定されたカスタムスケジューラーと一致することが検証されます。

      出力例

      [...]
Events:
  Type    Reason     Age   From              Message
  ----    ------     ----  ----              -------
  Normal  Scheduled  21m   my-scheduler  Successfully assigned default/virt-launcher-vm-fedora-dpc87 to node01
[...]
      Copy to Clipboard Toggle word wrap

9.12.10. PCI パススルーの設定
リンクのコピー

PCI (Peripheral Component Interconnect) パススルー機能を使用すると、仮想マシンからハードウェアデバイスにアクセスし、管理できます。PCI パススルーが設定されると、PCI デバイスはゲストオペレーティングシステムに物理的に接続されているかのように機能します。

クラスター管理者は、oc コマンドラインインターフェイス (CLI) を使用して、クラスターでの使用が許可されているホストデバイスを公開および管理できます。

9.12.10.1. GPU パススルー用のノードの準備
リンクのコピー

GPU パススルー用に指定したワーカーノードに GPU オペランドがデプロイされないようにすることができます。

9.12.10.1.1. NVIDIA GPU オペランドがノードにデプロイメントされないようにする
リンクのコピー

クラスター内で NVIDIA GPU Operator を使用する場合は、GPU または vGPU オペランド用に設定したくないノードに nvidia.com/gpu.deploy.operands=false ラベルを適用できます。このラベルは、GPU または vGPU オペランドを設定する Pod の作成を防止し、Pod がすでに存在する場合は終了します。

前提条件

  • OpenShift CLI (oc) がインストールされている。

手順

  • 次のコマンドを実行して、ノードのラベルを付けます。 

    $ oc label node <node_name> nvidia.com/gpu.deploy.operands=false
    1
    Copy to Clipboard Toggle word wrap
    1
    <node_name> を、NVIDIA GPU オペランドをインストールしないノードの名前に置き換えます。

検証

  1. 次のコマンドを実行して、ラベルがノードに追加されたことを確認します。 

    $ oc describe node <node_name>
    Copy to Clipboard Toggle word wrap

  2. オプション: GPU オペランドが以前にノードにデプロイされていた場合は、それらの削除を確認します。

    1. 次のコマンドを実行して、nvidia-gpu-operator namespace 内の Pod のステータスを確認します。 

      $ oc get pods -n nvidia-gpu-operator
      Copy to Clipboard Toggle word wrap

      出力例

      NAME                             READY   STATUS        RESTARTS   AGE
gpu-operator-59469b8c5c-hw9wj    1/1     Running       0          8d
nvidia-sandbox-validator-7hx98   1/1     Running       0          8d
nvidia-sandbox-validator-hdb7p   1/1     Running       0          8d
nvidia-sandbox-validator-kxwj7   1/1     Terminating   0          9d
nvidia-vfio-manager-7w9fs        1/1     Running       0          8d
nvidia-vfio-manager-866pz        1/1     Running       0          8d
nvidia-vfio-manager-zqtck        1/1     Terminating   0          9d
      Copy to Clipboard Toggle word wrap

    2. Terminating ステータスの Pod が削除されるまで、Pod のステータスを監視します。 

      $ oc get pods -n nvidia-gpu-operator
      Copy to Clipboard Toggle word wrap

      出力例

      NAME                             READY   STATUS    RESTARTS   AGE
gpu-operator-59469b8c5c-hw9wj    1/1     Running   0          8d
nvidia-sandbox-validator-7hx98   1/1     Running   0          8d
nvidia-sandbox-validator-hdb7p   1/1     Running   0          8d
nvidia-vfio-manager-7w9fs        1/1     Running   0          8d
nvidia-vfio-manager-866pz        1/1     Running   0          8d
      Copy to Clipboard Toggle word wrap

9.12.10.2. PCI パススルー用のホストデバイスの準備
リンクのコピー

9.12.10.2.1. PCI パススルー用ホストデバイスの準備について
リンクのコピー

CLI を使用して PCI パススルー用にホストデバイスを準備するには、MachineConfig オブジェクトを作成し、カーネル引数を追加して、Input-Output Memory Management Unit (IOMMU) を有効にします。PCI デバイスを Virtual Function I/O (VFIO) ドライバーにバインドしてから、HyperConverged カスタムリソース (CR) の permittedHostDevices フィールドを編集してクラスター内で公開します。OpenShift Virtualization Operator を最初にインストールする場合、permittedHostDevices のリストは空になります。

CLI を使用してクラスターから PCI ホストデバイスを削除するには、HyperConverged CR から PCI デバイス情報を削除します。

9.12.10.2.2. IOMMU ドライバーを有効にするためのカーネル引数の追加
リンクのコピー

カーネルで IOMMU ドライバーを有効にするには、MachineConfig オブジェクトを作成し、カーネル引数を追加します。

前提条件

  • クラスター管理者パーミッションがある。
  • CPU ハードウェアは Intel または AMD です。
  • BIOS で Directed I/O 拡張機能または AMD IOMMU 用の Intel Virtualization Technology を有効にしました。
  • OpenShift CLI (oc) がインストールされている。

手順

  1. カーネル引数を識別する MachineConfig オブジェクトを作成します。以下の例は、Intel CPU のカーネル引数を示しています。 

    apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
  labels:
    machineconfiguration.openshift.io/role: worker
    1 
    
  name: 100-worker-iommu
    2 
    
spec:
  config:
    ignition:
      version: 3.2.0
  kernelArguments:
      - intel_iommu=on
    3 
    
# ...
    Copy to Clipboard Toggle word wrap
    1
    新しいカーネル引数をワーカーノードのみに適用します。
    2
    name は、マシン設定とその目的におけるこのカーネル引数 (100) のランクを示します。AMD CPU がある場合は、カーネル引数を amd_iommu=on として指定します。
    3
    Intel CPU の intel_iommu としてカーネル引数を特定します。

  2. 新規 MachineConfig オブジェクトを作成します。 

    $ oc create -f 100-worker-kernel-arg-iommu.yaml
    Copy to Clipboard Toggle word wrap

検証

  • 新規 MachineConfig オブジェクトが追加されていることを確認します。 

    $ oc get MachineConfig
    Copy to Clipboard Toggle word wrap
9.12.10.2.3. PCI デバイスの VFIO ドライバーへのバインディング
リンクのコピー

PCI デバイスを VFIO (Virtual Function I/O) ドライバーにバインドするには、各デバイスから vendor-ID および device-ID の値を取得し、これらの値でリストを作成します。リストを MachineConfig オブジェクトに追加します。MachineConfig Operator は、PCI デバイスを持つノードで /etc/modprobe.d/vfio.conf を生成し、PCI デバイスを VFIO ドライバーにバインドします。

前提条件

  • カーネル引数を CPU の IOMMU を有効にするために追加している。
  • OpenShift CLI (oc) がインストールされている。

手順

  1. lspci コマンドを実行して、PCI デバイスの vendor-ID および device-ID を取得します。 

    $ lspci -nnv | grep -i nvidia
    Copy to Clipboard Toggle word wrap

    出力例

    02:01.0 3D controller [0302]: NVIDIA Corporation GV100GL [Tesla V100 PCIe 32GB] [10de:1eb8] (rev a1)
    Copy to Clipboard Toggle word wrap

  2. Butane 設定ファイル 100-worker-vfiopci.bu を作成し、PCI デバイスを VFIO ドライバーにバインドします。

    注記

    設定ファイルで指定する Butane のバージョン は、OpenShift Container Platform のバージョンと同じである必要があり、末尾は常に 0 です。たとえば、4.18.0 です。Butane の詳細は、「Butane を使用したマシン設定の作成」を参照してください。

    例

    variant: openshift
version: 4.18.0
metadata:
  name: 100-worker-vfiopci
  labels:
    machineconfiguration.openshift.io/role: worker
    1 
    
storage:
  files:
  - path: /etc/modprobe.d/vfio.conf
    mode: 0644
    overwrite: true
    contents:
      inline: |
        options vfio-pci ids=10de:1eb8
    2 
    
  - path: /etc/modules-load.d/vfio-pci.conf
    3 
    
    mode: 0644
    overwrite: true
    contents:
      inline: vfio-pci
    Copy to Clipboard Toggle word wrap

    1
    新しいカーネル引数をワーカーノードのみに適用します。
    2
    以前に決定された vendor-ID 値 (10de) と device-ID 値 (1eb8) を指定して、単一のデバイスを VFIO ドライバーにバインドします。複数のデバイスのリストをベンダーおよびデバイス情報とともに追加できます。
    3
    ワーカーノードで vfio-pci カーネルモジュールを読み込むファイル。

  3. Butane を使用して、ワーカーノードに配信される設定を含む MachineConfig オブジェクトファイル (100-worker-vfiopci.yaml) を生成します。 

    $ butane 100-worker-vfiopci.bu -o 100-worker-vfiopci.yaml
    Copy to Clipboard Toggle word wrap

  4. MachineConfig オブジェクトをワーカーノードに適用します。 

    $ oc apply -f 100-worker-vfiopci.yaml
    Copy to Clipboard Toggle word wrap

  5. MachineConfig オブジェクトが追加されていることを確認します。 

    $ oc get MachineConfig
    Copy to Clipboard Toggle word wrap

    出力例

    NAME                             GENERATEDBYCONTROLLER                      IGNITIONVERSION  AGE
00-master                        d3da910bfa9f4b599af4ed7f5ac270d55950a3a1   3.2.0            25h
00-worker                        d3da910bfa9f4b599af4ed7f5ac270d55950a3a1   3.2.0            25h
01-master-container-runtime      d3da910bfa9f4b599af4ed7f5ac270d55950a3a1   3.2.0            25h
01-master-kubelet                d3da910bfa9f4b599af4ed7f5ac270d55950a3a1   3.2.0            25h
01-worker-container-runtime      d3da910bfa9f4b599af4ed7f5ac270d55950a3a1   3.2.0            25h
01-worker-kubelet                d3da910bfa9f4b599af4ed7f5ac270d55950a3a1   3.2.0            25h
100-worker-iommu                                                            3.2.0            30s
100-worker-vfiopci-configuration                                            3.2.0            30s
    Copy to Clipboard Toggle word wrap

検証

  • VFIO ドライバーがロードされていることを確認します。 

    $ lspci -nnk -d 10de:
    Copy to Clipboard Toggle word wrap

    この出力では、VFIO ドライバーが使用されていることを確認します。

    出力例

    04:00.0 3D controller [0302]: NVIDIA Corporation GP102GL [Tesla P40] [10de:1eb8] (rev a1)
        Subsystem: NVIDIA Corporation Device [10de:1eb8]
        Kernel driver in use: vfio-pci
        Kernel modules: nouveau
    Copy to Clipboard Toggle word wrap

9.12.10.2.4. CLI を使用したクラスターでの PCI ホストデバイスの公開
リンクのコピー

クラスターで PCI ホストデバイスを公開するには、PCI デバイスの詳細を HyperConverged カスタムリソース (CR) の spec.permittedHostDevices.pciHostDevices 配列に追加します。

前提条件

  • OpenShift CLI (oc) がインストールされている。

手順

  1. 以下のコマンドを実行して、デフォルトエディターで HyperConverged CR を編集します。 

    $ oc edit hyperconverged kubevirt-hyperconverged -n openshift-cnv
    Copy to Clipboard Toggle word wrap

  2. PCI デバイス情報を spec.permittedHostDevices.pciHostDevices 配列に追加します。以下に例を示します。

    設定ファイルのサンプル

    apiVersion: hco.kubevirt.io/v1
kind: HyperConverged
metadata:
  name: kubevirt-hyperconverged
  namespace: openshift-cnv
spec:
  permittedHostDevices:
    1 
    
    pciHostDevices:
    2 
    
    - pciDeviceSelector: "10DE:1DB6"
    3 
    
      resourceName: "nvidia.com/GV100GL_Tesla_V100"
    4 
    
    - pciDeviceSelector: "10DE:1EB8"
      resourceName: "nvidia.com/TU104GL_Tesla_T4"
    - pciDeviceSelector: "8086:6F54"
      resourceName: "intel.com/qat"
      externalResourceProvider: true
    5 
    
# ...
    Copy to Clipboard Toggle word wrap

    1
    クラスターでの使用が許可されているホストデバイス。
    2
    ノードで利用可能な PCI デバイスのリスト。
    3
    PCI デバイスを識別するために必要な vendor-ID および device-ID。
    4
    PCI ホストデバイスの名前。
    5
    オプション: このフィールドを true に設定すると、リソースが外部デバイスプラグインにより提供されることを示します。OpenShift Virtualization はクラスターでこのデバイスの使用を許可しますが、割り当ておよびモニタリングを外部デバイスプラグインに残します。
    注記

    上記のスニペットの例は、nvidia.com/GV100GL_Tesla_V100 および nvidia.com/TU104GL_Tesla_T4 という名前の 2 つの PCI ホストデバイスが、HyperConverged CR の許可されたホストデバイスの一覧に追加されたことを示しています。これらのデバイスは、OpenShift Virtualization と動作することがテストおよび検証されています。

  3. 変更を保存し、エディターを終了します。

検証

  • 以下のコマンドを実行して、PCI ホストデバイスがノードに追加されたことを確認します。この出力例は、各デバイスが nvidia.com/GV100GL_Tesla_V100、nvidia.com/TU104GL_Tesla_T4、および intel.com/qat のリソース名にそれぞれ関連付けられたデバイスが 1 つあることを示しています。 

    $ oc describe node <node_name>
    Copy to Clipboard Toggle word wrap

    出力例

    Capacity:
  cpu:                            64
  devices.kubevirt.io/kvm:        110
  devices.kubevirt.io/tun:        110
  devices.kubevirt.io/vhost-net:  110
  ephemeral-storage:              915128Mi
  hugepages-1Gi:                  0
  hugepages-2Mi:                  0
  memory:                         131395264Ki
  nvidia.com/GV100GL_Tesla_V100   1
  nvidia.com/TU104GL_Tesla_T4     1
  intel.com/qat:                  1
  pods:                           250
Allocatable:
  cpu:                            63500m
  devices.kubevirt.io/kvm:        110
  devices.kubevirt.io/tun:        110
  devices.kubevirt.io/vhost-net:  110
  ephemeral-storage:              863623130526
  hugepages-1Gi:                  0
  hugepages-2Mi:                  0
  memory:                         130244288Ki
  nvidia.com/GV100GL_Tesla_V100   1
  nvidia.com/TU104GL_Tesla_T4     1
  intel.com/qat:                  1
  pods:                           250
    Copy to Clipboard Toggle word wrap

9.12.10.2.5. CLI を使用したクラスターからの PCI ホストデバイスの削除
リンクのコピー

クラスターから PCI ホストデバイスを削除するには、HyperConverged カスタムリソース (CR) からそのデバイスの情報を削除します。

前提条件

  • OpenShift CLI (oc) がインストールされている。

手順

  1. 以下のコマンドを実行して、デフォルトエディターで HyperConverged CR を編集します。 

    $ oc edit hyperconverged kubevirt-hyperconverged -n openshift-cnv
    Copy to Clipboard Toggle word wrap

  2. 適切なデバイスの pciDeviceSelector、resourceName、および externalResourceProvider (該当する場合) のフィールドを削除して、spec.permittedHostDevices.pciHostDevices 配列から PCI デバイス情報を削除します。この例では、intel.com/qat リソースが削除されました。

    設定ファイルのサンプル

    apiVersion: hco.kubevirt.io/v1
kind: HyperConverged
metadata:
  name: kubevirt-hyperconverged
  namespace: openshift-cnv
spec:
  permittedHostDevices:
    pciHostDevices:
    - pciDeviceSelector: "10DE:1DB6"
      resourceName: "nvidia.com/GV100GL_Tesla_V100"
    - pciDeviceSelector: "10DE:1EB8"
      resourceName: "nvidia.com/TU104GL_Tesla_T4"
# ...
    Copy to Clipboard Toggle word wrap

  3. 変更を保存し、エディターを終了します。

検証

  • 以下のコマンドを実行して、PCI ホストデバイスがノードから削除されたことを確認します。この出力例は、intel.com/qat リソース名に関連付けられているデバイスがゼロであることを示しています。 

    $ oc describe node <node_name>
    Copy to Clipboard Toggle word wrap

    出力例

    Capacity:
  cpu:                            64
  devices.kubevirt.io/kvm:        110
  devices.kubevirt.io/tun:        110
  devices.kubevirt.io/vhost-net:  110
  ephemeral-storage:              915128Mi
  hugepages-1Gi:                  0
  hugepages-2Mi:                  0
  memory:                         131395264Ki
  nvidia.com/GV100GL_Tesla_V100   1
  nvidia.com/TU104GL_Tesla_T4     1
  intel.com/qat:                  0
  pods:                           250
Allocatable:
  cpu:                            63500m
  devices.kubevirt.io/kvm:        110
  devices.kubevirt.io/tun:        110
  devices.kubevirt.io/vhost-net:  110
  ephemeral-storage:              863623130526
  hugepages-1Gi:                  0
  hugepages-2Mi:                  0
  memory:                         130244288Ki
  nvidia.com/GV100GL_Tesla_V100   1
  nvidia.com/TU104GL_Tesla_T4     1
  intel.com/qat:                  0
  pods:                           250
    Copy to Clipboard Toggle word wrap

9.12.10.3. PCI パススルー用の仮想マシンの設定
リンクのコピー

PCI デバイスがクラスターに追加された後に、それらを仮想マシンに割り当てることができます。PCI デバイスが仮想マシンに物理的に接続されているかのような状態で利用できるようになりました。

9.12.10.3.1. PCI デバイスの仮想マシンへの割り当て
リンクのコピー

PCI デバイスがクラスターで利用可能な場合、これを仮想マシンに割り当て、PCI パススルーを有効にすることができます。

手順

  • PCI デバイスをホストデバイスとして仮想マシンに割り当てます。

    例

    apiVersion: kubevirt.io/v1
kind: VirtualMachine
spec:
  domain:
    devices:
      hostDevices:
      - deviceName: nvidia.com/TU104GL_Tesla_T4
    1 
    
        name: hostdevices1
    Copy to Clipboard Toggle word wrap

    1
    クラスターでホストデバイスとして許可される PCI デバイスの名前。仮想マシンがこのホストデバイスにアクセスできます。

検証

  • 以下のコマンドを使用して、ホストデバイスが仮想マシンから利用可能であることを確認します。 

    $ lspci -nnk | grep NVIDIA
    Copy to Clipboard Toggle word wrap

    出力例

    $ 02:01.0 3D controller [0302]: NVIDIA Corporation GV100GL [Tesla V100 PCIe 32GB] [10de:1eb8] (rev a1)
    Copy to Clipboard Toggle word wrap

9.12.11. 仮想 GPU の設定
リンクのコピー

グラフィックスプロセッシングユニット (GPU) カードがある場合、OpenShift Virtualization は仮想マシンに割り当てることができる仮想 GPU (vGPU) を自動的に作成できます。

9.12.11.1. OpenShift Virtualization での仮想 GPU の使用について
リンクのコピー

一部のグラフィックス処理ユニット (GPU) カードは、仮想 GPU (vGPU) の作成をサポートしています。管理者が HyperConverged カスタムリソース (CR) で設定の詳細を提供すると、OpenShift Virtualization は仮想 GPU およびその他の仲介デバイスを自動的に作成できます。この自動化は、大規模なクラスターで特に役立ちます。

注記

機能とサポートの詳細は、ハードウェアベンダーのドキュメントを参照してください。

仲介デバイス
1 つまたは複数の仮想デバイスに分割された物理デバイス。仮想 GPU は、仲介デバイス (mdev) の一種です。物理 GPU のパフォーマンスが、仮想デバイス間で分割されます。仲介デバイスを 1 つまたは複数の仮想マシン (VM) に割り当てることができますが、ゲストの数は GPU と互換性がある必要があります。一部の GPU は複数のゲストをサポートしていません。

9.12.11.2. 仲介デバイス用のホストの準備
リンクのコピー

仲介デバイスを設定する前に、入出力メモリー管理ユニット (IOMMU) ドライバーを有効にする必要があります。

9.12.11.2.1. IOMMU ドライバーを有効にするためのカーネル引数の追加
リンクのコピー

カーネルで IOMMU ドライバーを有効にするには、MachineConfig オブジェクトを作成し、カーネル引数を追加します。

前提条件

  • クラスター管理者パーミッションがある。
  • CPU ハードウェアは Intel または AMD です。
  • BIOS で Directed I/O 拡張機能または AMD IOMMU 用の Intel Virtualization Technology を有効にしました。
  • OpenShift CLI (oc) がインストールされている。

手順

  1. カーネル引数を識別する MachineConfig オブジェクトを作成します。以下の例は、Intel CPU のカーネル引数を示しています。 

    apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
  labels:
    machineconfiguration.openshift.io/role: worker
    1 
    
  name: 100-worker-iommu
    2 
    
spec:
  config:
    ignition:
      version: 3.2.0
  kernelArguments:
      - intel_iommu=on
    3 
    
# ...
    Copy to Clipboard Toggle word wrap
    1
    新しいカーネル引数をワーカーノードのみに適用します。
    2
    name は、マシン設定とその目的におけるこのカーネル引数 (100) のランクを示します。AMD CPU がある場合は、カーネル引数を amd_iommu=on として指定します。
    3
    Intel CPU の intel_iommu としてカーネル引数を特定します。

  2. 新規 MachineConfig オブジェクトを作成します。 

    $ oc create -f 100-worker-kernel-arg-iommu.yaml
    Copy to Clipboard Toggle word wrap

検証

  • 新規 MachineConfig オブジェクトが追加されていることを確認します。 

    $ oc get MachineConfig
    Copy to Clipboard Toggle word wrap

9.12.11.3. NVIDIA GPU Operator の設定
リンクのコピー

NVIDIA GPU Operator を使用して、OpenShift Virtualization で GPU 高速化仮想マシンを実行するためのワーカーノードをプロビジョニングできます。

注記

NVIDIA GPU Operator は、NVIDIA によってのみサポートされています。詳細は、Red Hat ナレッジベースの Obtaining Support from NVIDIA を参照してください。

9.12.11.3.1. NVIDIA GPU Operator の使用について
リンクのコピー

NVIDIA GPU Operator と OpenShift Virtualization を使用すると、GPU 対応の仮想マシンを実行するためのワーカーノードを迅速にプロビジョニングできます。NVIDIA GPU Operator は、OpenShift Container Platform クラスター内の NVIDIA GPU リソースを管理し、GPU ワークロード用にノードを準備するときに必要なタスクを自動化します。

アプリケーションワークロードを GPU リソースにデプロイする前に、コンピューティングユニファイドデバイスアーキテクチャー (CUDA)、Kubernetes デバイスプラグイン、コンテナーランタイム、および自動ノードラベル付けや監視などのその他の機能を有効にする NVIDIA ドライバーなどのコンポーネントをインストールする必要があります。これらのタスクを自動化することで、インフラストラクチャーの GPU 容量を迅速に拡張できます。NVIDIA GPU Operator は、複雑な人工知能および機械学習 (AI/ML) ワークロードのプロビジョニングを特に容易にします。

9.12.11.3.2. 仲介デバイスを設定するためのオプション
リンクのコピー

NVIDIA GPU Operator を使用すると、仲介デバイスを設定するには 2 つの方法があります。Red Hat がテストする方法では、OpenShift Virtualization 機能を使用して仲介デバイスをスケジュールしますが、NVIDIA の方法では GPU Operator のみを使用します。

NVIDIA GPU Operator を使用した仲介デバイスの設定
この方法では、NVIDIA GPU Operator のみを使用して仲介デバイスを設定します。この方法を使用するには、NVIDIA ドキュメントの NVIDIA GPU Operator with OpenShift Virtualization を参照してください。
OpenShift Virtualization を使用した仲介デバイスの設定

この方法は Red Hat によってテストされており、OpenShift Virtualization の機能を使用して仲介デバイスを設定します。この場合、NVIDIA GPU Operator は、NVIDIA vGPU Manager でドライバーをインストールするためにのみ使用されます。GPU Operator は仲介デバイスを設定しません。

OpenShift 仮想化方式を使用する場合でも、NVIDIA ドキュメント に従って GPU Operator を設定します。ただし、この方法は次の点で NVIDIA ドキュメントとは異なります。

  • HyperConverged カスタムリソース (CR) のデフォルトの disableMDEVConfiguration: false 設定を上書きしないでください。

    重要

    NVIDIA ドキュメント の説明に従ってこの機能ゲートを設定すると、OpenShift Virtualization が仲介デバイスを設定できなくなります。

  • 次の例と一致するように ClusterPolicy マニフェストを設定する必要があります。

    マニフェストの例

    kind: ClusterPolicy
apiVersion: nvidia.com/v1
metadata:
  name: gpu-cluster-policy
spec:
  operator:
    defaultRuntime: crio
    use_ocp_driver_toolkit: true
    initContainer: {}
  sandboxWorkloads:
    enabled: true
    defaultWorkload: vm-vgpu
  driver:
    enabled: false
    1 
    
  dcgmExporter: {}
  dcgm:
    enabled: true
  daemonsets: {}
  devicePlugin: {}
  gfd: {}
  migManager:
    enabled: true
  nodeStatusExporter:
    enabled: true
  mig:
    strategy: single
  toolkit:
    enabled: true
  validator:
    plugin:
      env:
        - name: WITH_WORKLOAD
          value: "true"
  vgpuManager:
    enabled: true
    2 
    
    repository: <vgpu_container_registry>
    3 
    
    image: <vgpu_image_name>
    version: nvidia-vgpu-manager
  vgpuDeviceManager:
    enabled: false
    4 
    
    config:
      name: vgpu-devices-config
      default: default
  sandboxDevicePlugin:
    enabled: false
    5 
    
  vfioManager:
    enabled: false
    6
    Copy to Clipboard Toggle word wrap

    1
    この値を false に設定します。仮想マシンには必要ありません。
    2
    この値を true に設定します。仮想マシンで vGPU を使用する場合に必要です。
    3
    <vgpu_container_registry> をレジストリー値に置き換えます。
    4
    この値を false に設定すると、OpenShift Virtualization が NVIDIA GPU Operator の代わりに仲介デバイスを設定できるようになります。
    5
    vGPU デバイスの検出と kubelet へのアドバタイズを防止するには、この値を false に設定します。
    6
    vfio-pci ドライバーがロードされないようにするには、この値を false に設定します。代わりに、OpenShift Virtualization のドキュメントに従って PCI パススルーを設定します。

9.12.11.4. 仮想 GPU がノードに割り当てられる方法
リンクのコピー

物理デバイスごとに、OpenShift Virtualization は以下の値を設定します。

  • 1 つの mdev タイプ。
  • 選択した mdev タイプのインスタンスの最大数。

クラスターのアーキテクチャーは、デバイスの作成およびノードへの割り当て方法に影響します。

ノードごとに複数のカードを持つ大規模なクラスター

同様の仮想 GPU タイプに対応する複数のカードを持つノードでは、関連するデバイス種別がラウンドロビン方式で作成されます。以下に例を示します。 

# ...
mediatedDevicesConfiguration:
  mediatedDeviceTypes:
  - nvidia-222
  - nvidia-228
  - nvidia-105
  - nvidia-108
# ...
Copy to Clipboard Toggle word wrap

このシナリオでは、各ノードに以下の仮想 GPU 種別に対応するカードが 2 つあります。 

nvidia-105
# ...
nvidia-108
nvidia-217
nvidia-299
# ...
Copy to Clipboard Toggle word wrap

各ノードで、OpenShift Virtualization は以下の vGPU を作成します。

  • 最初のカード上に nvidia-105 タイプの 16 の仮想 GPU
  • 2 番目のカード上に nvidia-108 タイプの 2 つの仮想 GPU
1 つのノードに、要求された複数の仮想 GPU タイプをサポートするカードが 1 つある

OpenShift Virtualization は、mediatedDeviceTypes 一覧の最初のサポートされるタイプを使用します。

たとえば、ノードカードのカードは nvidia-223 と nvidia-224 をサポートします。次の mediatedDeviceTypes リストが設定されています。 

# ...
mediatedDevicesConfiguration:
  mediatedDeviceTypes:
  - nvidia-22
  - nvidia-223
  - nvidia-224
# ...
Copy to Clipboard Toggle word wrap

この例では、OpenShift Virtualization は nvidia-223 タイプを使用します。

9.12.11.5. 仲介されたデバイスの管理
リンクのコピー

仲介されたデバイスを仮想マシンに割り当てる前に、デバイスを作成してクラスターに公開する必要があります。仲介されたデバイスを再設定および削除することもできます。

9.12.11.5.1. 仲介デバイスの作成および公開
リンクのコピー

管理者は、HyperConverged カスタムリソース (CR) を編集することで、仲介デバイスを作成し、クラスターに公開できます。

前提条件

  • OpenShift CLI (oc) がインストールされている。
  • 入出力メモリー管理ユニット (IOMMU) ドライバーを有効にしました。

  • ハードウェアベンダーがドライバーを提供している場合は、仲介デバイスを作成するノードにドライバーをインストールしている。

手順

  1. 以下のコマンドを実行して、デフォルトのエディターで HyperConverged CR を開きます。 

    $ oc edit hyperconverged kubevirt-hyperconverged -n openshift-cnv
    Copy to Clipboard Toggle word wrap

    例9.1 仲介デバイスが設定された設定ファイルの例

    apiVersion: hco.kubevirt.io/v1
kind: HyperConverged
metadata:
  name: kubevirt-hyperconverged
  namespace: openshift-cnv
spec:
  mediatedDevicesConfiguration:
    mediatedDeviceTypes:
    - nvidia-231
    nodeMediatedDeviceTypes:
    - mediatedDeviceTypes:
      - nvidia-233
      nodeSelector:
        kubernetes.io/hostname: node-11.redhat.com
  permittedHostDevices:
    mediatedDevices:
    - mdevNameSelector: GRID T4-2Q
      resourceName: nvidia.com/GRID_T4-2Q
    - mdevNameSelector: GRID T4-8Q
      resourceName: nvidia.com/GRID_T4-8Q
# ...
    Copy to Clipboard Toggle word wrap

  2. 仲介デバイスを spec.mediatedDevicesConfiguration スタンザに追加して作成します。

    YAML スニペットの例

    # ...
spec:
  mediatedDevicesConfiguration:
    mediatedDeviceTypes:
    1 
    
    - <device_type>
    nodeMediatedDeviceTypes:
    2 
    
    - mediatedDeviceTypes:
    3 
    
      - <device_type>
      nodeSelector:
    4 
    
        <node_selector_key>: <node_selector_value>
# ...
    Copy to Clipboard Toggle word wrap

    1
    必須: クラスターのグローバル設定を定義します。
    2
    オプション: 特定のノードまたはノードのグループのグローバル設定をオーバーライドします。グローバルの mediatedDeviceTypes 設定と併用する必要があります。
    3
    nodeMediatedDeviceTypes を使用する場合に必須です。指定されたノードのグローバル mediatedDeviceTypes 設定をオーバーライドします。
    4
    nodeMediatedDeviceTypes を使用する場合に必須です。key:value ペアを含める必要があります。
    重要

    OpenShift Virtualization 4.14 より前では、mediatedDeviceTypes フィールドの名前は mediatedDevicesTypes でした。仲介デバイスを設定するときは、必ず正しいフィールド名を使用してください。

  3. クラスターに公開するデバイスの名前セレクターとリソース名の値を特定します。次のステップで、これらの値を HyperConverged CR に追加します。

    1. 次のコマンドを実行して、resourceName 値を見つけます。 

      $ oc get $NODE -o json \
  | jq '.status.allocatable \
    | with_entries(select(.key | startswith("nvidia.com/"))) \
    | with_entries(select(.value != "0"))'
      Copy to Clipboard Toggle word wrap

    2. /sys/bus/pci/devices/<slot>:<bus>:<domain>.<function>/mdev_supported_types/<type>/name の内容を表示して mdevNameSelector 値を見つけ、システムの正しい値に置き換えます。

      たとえば、nvidia-231 タイプの name ファイルには、セレクター文字列 GRID T4-2Q が含まれます。GRID T4-2Q を mdevNameSelector 値として使用することで、ノードは nvidia-231 タイプを使用できます。

  4. mdevNameSelector と resourceName の値を HyperConverged CR の spec.permittedHostDevices.mediatedDevices スタンザに追加することで、仲介されたデバイスをクラスターに公開します。

    YAML スニペットの例

    # ...
  permittedHostDevices:
    mediatedDevices:
    - mdevNameSelector: GRID T4-2Q
    1 
    
      resourceName: nvidia.com/GRID_T4-2Q
    2 
    
# ...
    Copy to Clipboard Toggle word wrap

    1
    この値にマッピングする仲介デバイスをホスト上に公開します。
    2
    ノードに割り当てられているリソース名と一致します。
  5. 変更を保存し、エディターを終了します。

検証

  • オプション: 次のコマンドを実行して、デバイスが特定のノードに追加されたことを確認します。 

    $ oc describe node <node_name>
    Copy to Clipboard Toggle word wrap
9.12.11.5.2. 仲介デバイスの変更および削除について
リンクのコピー

仲介されたデバイスは、いくつかの方法で再設定または削除できます。

  • HyperConverged CR を編集し、mediatedDeviceTypes スタンザの内容を変更します。
  • nodeMediatedDeviceTypes ノードセレクターに一致するノードラベルを変更します。

  • HyperConverged CR の spec.mediatedDevicesConfiguration および spec.permittedHostDevices スタンザからデバイス情報を削除します。

    注記

    spec.permittedHostDevices スタンザからデバイス情報を削除したが、spec.mediatedDevicesConfiguration スタンザからは削除しなかった場合、同じノードで新規の仲介デバイスタイプを作成することはできません。仲介デバイスを適切に削除するには、両方のスタンザからデバイス情報を削除します。

9.12.11.5.3. 仲介されたデバイスをクラスターから削除する
リンクのコピー

クラスターから仲介デバイスを削除するには、HyperConverged カスタムリソース (CR) からそのデバイスの情報を削除します。

前提条件

  • OpenShift CLI (oc) がインストールされている。

手順

  1. 以下のコマンドを実行して、デフォルトエディターで HyperConverged CR を編集します。 

    $ oc edit hyperconverged kubevirt-hyperconverged -n openshift-cnv
    Copy to Clipboard Toggle word wrap

  2. HyperConverged CR の spec.mediatedDevicesConfiguration および spec.permittedHostDevices スタンザからデバイス情報を削除します。両方のエントリーを削除すると、後で同じノードで新しい仲介デバイスタイプを作成できます。以下に例を示します。

    設定ファイルのサンプル

    apiVersion: hco.kubevirt.io/v1
kind: HyperConverged
metadata:
  name: kubevirt-hyperconverged
  namespace: openshift-cnv
spec:
  mediatedDevicesConfiguration:
    mediatedDeviceTypes:
    1 
    
      - nvidia-231
  permittedHostDevices:
    mediatedDevices:
    2 
    
    - mdevNameSelector: GRID T4-2Q
      resourceName: nvidia.com/GRID_T4-2Q
    Copy to Clipboard Toggle word wrap

    1
    nvidia-231 デバイスタイプを削除するには、これを mediatedDeviceTypes 配列から削除します。
    2
    GRID T4-2Q デバイスを削除するには、mdevNameSelector フィールドおよび対応する resourceName フィールドを削除します。
  3. 変更を保存し、エディターを終了します。

9.12.11.6. 仲介デバイスの使用
リンクのコピー

仲介デバイスを 1 つ以上の仮想マシンに割り当てることができます。

9.12.11.6.1. CLI を使用した仮想マシンへの vGPU の割り当て
リンクのコピー

仮想 GPU (vGPU) などの仲介デバイスを仮想マシンに割り当てます。

前提条件

  • 仲介デバイスが HyperConverged カスタムリソースで設定されている。
  • 仮想マシンが停止しています。

手順

  • VirtualMachine マニフェストの spec.domain.devices.gpus スタンザを編集して、仲介デバイスを仮想マシン (VM) に割り当てます。

    仮想マシンマニフェストの例

    apiVersion: kubevirt.io/v1
kind: VirtualMachine
spec:
  domain:
    devices:
      gpus:
      - deviceName: nvidia.com/TU104GL_Tesla_T4
    1 
    
        name: gpu1
    2 
    
      - deviceName: nvidia.com/GRID_T4-2Q
        name: gpu2
    Copy to Clipboard Toggle word wrap

    1
    仲介デバイスに関連付けられたリソース名。
    2
    仮想マシン上のデバイスを識別する名前。

検証

  • デバイスが仮想マシンで利用できることを確認するには、<device_name> を VirtualMachine マニフェストの deviceName の値に置き換えて以下のコマンドを実行します。 

    $ lspci -nnk | grep <device_name>
    Copy to Clipboard Toggle word wrap
9.12.11.6.2. Web コンソールを使用した仮想マシンへの vGPU の割り当て
リンクのコピー

OpenShift Container Platform Web コンソールを使用して、仮想 GPU を仮想マシンに割り当てることができます。

注記

カスタマイズされたテンプレートまたは YAML ファイルから作成された仮想マシンに、ハードウェアデバイスを追加できます。特定のオペレーティングシステム用に事前に提供されているブートソーステンプレートにデバイスを追加することはできません。

前提条件

  • vGPU は、クラスター内の仲介デバイスとして設定されます。

    • クラスターに接続されているデバイスを表示するには、サイドメニューから Compute Hardware Devices をクリックします。
  • 仮想マシンが停止しています。

手順

  1. OpenShift Container Platform Web コンソールで、サイドメニューから Virtualization VirtualMachines をクリックします。
  2. デバイスを割り当てる仮想マシンを選択します。
  3. Details タブで、GPU devices をクリックします。
  4. Add GPU device をクリックします。
  5. Name フィールドに識別値を入力します。
  6. Device name リストから、仮想マシンに追加するデバイスを選択します。
  7. Save をクリックします。

検証

  • デバイスが仮想マシンに追加されたことを確認するには、YAML タブをクリックし、VirtualMachine 設定を確認します。仲介されたデバイスは spec.domain.devices スタンザに追加されます。

9.12.12. USB ホストパススルーの設定
リンクのコピー

クラスター管理者は、クラスター内の USB デバイスを公開し、仮想マシン所有者による仮想マシンへの割り当てを可能にできます。USB デバイスのこのパススルーを有効にすると、ゲストは、ハードウェアと仮想マシンが物理的に接続されているかのように、OpenShift Container Platform ノードに接続された実際の USB ハードウェアに接続できるようになります。

USB デバイスを公開するには、まずホストパススルーを有効にし、次に USB デバイスを使用するように仮想マシンを設定します。

9.12.12.1. USB ホストパススルーの有効化
リンクのコピー

クラスターレベルで USB ホストパススルーを有効にできます。

最初に追加し、次に仮想マシンに割り当てる各デバイスのリソース名と USB デバイス名を指定します。1 つのリソース名に複数のデバイスを割り当てることができ、各デバイスは HyperConverged (HCO) カスタムリソース (CR) の selector と呼ばれます。クラスター上に同一の USB デバイスが複数ある場合は、特定のデバイスに仮想マシンを割り当てることができます。

前提条件

  • cluster-admin ロールを持つユーザーとして OpenShift Container Platform クラスターにアクセスできる。
  • OpenShift CLI (oc) がインストールされている。

手順

  1. 次のコマンドを実行して、USB デバイスのベンダーと製品を特定します。 

    $ lsusb
    Copy to Clipboard Toggle word wrap

  2. 次のコマンドを実行して HCO CR を開きます。 

    $ oc edit hyperconverged kubevirt-hyperconverged -n openshift-cnv
    Copy to Clipboard Toggle word wrap

  3. 次の例に示すように、permittedHostDevices スタンザに USB デバイスを追加します。

    YAML スニペットの例

    apiVersion: hco.kubevirt.io/v1beta1
kind: HyperConverged
metadata:
   name: kubevirt-hyperconverged
   namespace: openshift-cnv
spec:
  configuration:
    permittedHostDevices:
    1 
    
      usbHostDevices:
    2 
    
        - resourceName: kubevirt.io/peripherals
    3 
    
          selectors:
            - vendor: "045e"
              product: "07a5"
            - vendor: "062a"
              product: "4102"
            - vendor: "072f"
              product: "b100"
    Copy to Clipboard Toggle word wrap

    1
    クラスターでの使用が許可されているホストデバイスをリスト表示します。
    2
    使用可能な USB デバイスをリスト表示します。
    3
    追加して仮想マシンに割り当てるデバイスごとに、resourceName: deviceName を使用します。この例では、リソースは 3 つのデバイスにバインドされており、各デバイスは vendor と product で識別され、selector と呼ばれます。

9.12.12.2. USB デバイスへの仮想マシン接続の設定
リンクのコピー

USB デバイスへの仮想マシンアクセスを設定できます。この設定により、ゲストは、ハードウェアと仮想マシンが物理的に接続されているかのように、OpenShift Container Platform ノードに接続された実際の USB ハードウェアに接続できるようになります。

前提条件

  • OpenShift CLI (oc) がインストールされている。

手順

  1. 次のコマンドを実行して USB デバイスを見つけます。 

    $ oc /dev/serial/by-id/usb-VENDOR_device_name
    Copy to Clipboard Toggle word wrap

  2. 次のコマンドを実行して、仮想マシンインスタンスのカスタムリソース (CR) を開きます。 

    $ oc edit vmi vmi-usb
    Copy to Clipboard Toggle word wrap

  3. 次の例に示すように、USB デバイスを追加して CR を編集します。

    設定例

    apiVersion: kubevirt.io/v1
kind: VirtualMachineInstance
metadata:
  labels:
    special: vmi-usb
  name: vmi-usb
    1 
    
spec:
  domain:
    devices:
      hostDevices:
      - deviceName: kubevirt.io/peripherals
        name: local-peripherals
# ...
    Copy to Clipboard Toggle word wrap

    1
    USB デバイスの名前。

9.12.13. 仮想マシンでの descheduler エビクションの有効化
リンクのコピー

descheduler を使用して Pod を削除し、Pod をより適切なノードに再スケジュールできます。Pod が仮想マシンの場合、Pod の削除により、仮想マシンが別のノードにライブマイグレーションされます。

9.12.13.1. descheduler プロファイル
リンクのコピー

仮想マシンで descheduler を有効にするには、DevKubeVirtRelieveAndMigrate または LongLifecycle プロファイルを使用します。

重要

DevKubeVirtRelieveAndMigrate と LongLifeCycle の両方を同時に有効にすることはできません。

DevKubeVirtRelieveAndMigrate

このプロファイルは、LongLifeCycle プロファイルの拡張バージョンです。

重要

DevKubeVirtRelieveAndMigrate プロファイルは、テクノロジープレビュー機能です。テクノロジープレビュー機能は、Red Hat 製品のサービスレベルアグリーメント (SLA) の対象外であり、機能的に完全ではないことがあります。Red Hat は、実稼働環境でこれらを使用することを推奨していません。テクノロジープレビュー機能は、最新の製品機能をいち早く提供して、開発段階で機能のテストを行い、フィードバックを提供していただくことを目的としています。

Red Hat のテクノロジープレビュー機能のサポート範囲に関する詳細は、テクノロジープレビュー機能のサポート範囲 を参照してください。

DevKubeVirtRelieveAndMigrate プロファイルは、高コストのノードから Pod を削除して、全体的なリソースのコストを削減し、ワークロードの移行を可能にします。また、定期的にワークロードのバランスを再調整して、ノード全体で同様の予備容量を維持し、ワークロードの急増をより適切に処理できるようにします。ノードには次のようなコストが発生する可能性があります。

  • リソース使用量: リソースが逼迫すると、アプリケーション実行のオーバーヘッドが増加します。
  • ノードのメンテナンス: ノード上のコンテナーの数が増えると、リソースの消費量とメンテナンスコストが増加します。

このプロファイルは、アルファ機能である EvictionsInBackground を使用して LowNodeUtilization ストラテジーを有効にします。また、このプロファイルは次のカスタマイズフィールドを公開します。

  • devActualUtilizationProfile: 負荷を考慮した descheduler による再スケジュールを有効にします。
  • devLowNodeUtilizationThresholds: LowNodeUtilization ストラテジーの実験的なしきい値を設定します。このフィールドを devDeviationThresholds と一緒に使用しないでください。
  • devDeviationThresholds: リソース使用率が平均以下のノードを、使用率が低いノードとして扱い、過剰に使用されているノードからワークロードを再分配します。このフィールドを devLowNodeUtilizationThresholds と一緒に使用しないでください。サポートされている値は、Low (10%:10%)、Medium (20%:20%)、High (30%:30%)、AsymmetricLow (0%:10%)、AsymmetricMedium (0%:20%)、AsymmetricHigh (0%:30%) です。
  • devEnableSoftTainter: ソフト taint 適用コンポーネントがソフト taint をスケジュールヒントとして動的に適用または削除できるようにします。

設定例

apiVersion: operator.openshift.io/v1
kind: KubeDescheduler
metadata:
  name: cluster
  namespace: openshift-kube-descheduler-operator
spec:
  managementState: Managed
  deschedulingIntervalSeconds: 30
  mode: "Automatic"
  profiles:
    - DevKubeVirtRelieveAndMigrate
  profileCustomizations:
    devEnableSoftTainter: true
    devDeviationThresholds: AsymmetricLow
    devActualUtilizationProfile: PrometheusCPUCombined
Copy to Clipboard Toggle word wrap

DevKubeVirtRelieveAndMigrate プロファイルでは、すべてのワーカーノードで PSI メトリクスを有効にする必要があります。これを有効にするには、次の MachineConfig カスタムリソース (CR) を適用します。

MachineConfig CR の例

apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfig
metadata:
  labels:
    machineconfiguration.openshift.io/role: worker
  name: 99-openshift-machineconfig-worker-psi-karg
spec:
  kernelArguments:
    - psi=1
Copy to Clipboard Toggle word wrap

このプロファイルを SoftTopologyAndDuplicates プロファイルとともに使用して、ソフトトポロジー制約に基づいて Pod のバランスを再調整することもできます。これは、Hosted Control Plane 環境で役立ちます。

LongLifecycle
このプロファイルは、ノード間のリソース使用率のバランスを取り、以下のストラテジーを有効にします。
  • RemovePodsHavingTooManyRestarts: コンテナーが何度も再起動された Pod、およびすべてのコンテナー (Init コンテナーを含む) の再起動の合計が 100 を超える Pod を削除します。仮想マシンのゲストオペレーティングシステムを再起動しても、この数は増えません。

  • LowNodeUtilization: 使用率の低いノードがある場合に、使用率の高いノードから Pod をエビクトします。エビクトされた Pod の宛先ノードはスケジューラーによって決定されます。

    • ノードは、使用率がすべてのしきい値 (CPU、メモリー、Pod の数) で 20% 未満の場合に使用率が低いと見なされます。
    • ノードは、使用率がすべてのしきい値 (CPU、メモリー、Pod の数) について 50% を超える場合に過剰に使用されていると見なされます。

9.12.13.2. descheduler のインストール
リンクのコピー

descheduler はデフォルトで利用できません。descheduler を有効にするには、Kube Descheduler Operator を OperatorHub からインストールし、1 つ以上の descheduler プロファイルを有効にする必要があります。

デフォルトで、descheduler は予測モードで実行されます。つまり、これは Pod エビクションのみをシミュレートします。Pod エビクションを実行するには、descheduler のモードを automatic に変更する必要があります。

重要

クラスターでホストされたコントロールプレーンを有効にしている場合は、カスタム優先度のしきい値を設定して、ホストされたコントロールプレーンの namespace の Pod が削除される可能性を下げます。ホストされたコントロールプレーンの優先度クラスの中で優先度値が最も低い (100000000) ため、優先度しきい値クラス名を hypershift-control-plane に設定します。

前提条件

  • cluster-admin ロールを持つユーザーとして OpenShift Container Platform にログインしている。
  • OpenShift Container Platform Web コンソールにアクセスできる。

手順

  1. OpenShift Container Platform Web コンソールにログインします。

  2. Kube Descheduler Operator に必要な namespace を作成します。

    1. Administration Namespaces に移動し、Create Namespace をクリックします。
    2. Name フィールドに openshift-kube-descheduler-operator を入力し、Labels フィールドに openshift.io/cluster-monitoring=true を入力して descheduler メトリクスを有効にし、Create をクリックします。

  3. Kube Descheduler Operator をインストールします。

    1. Operators OperatorHub に移動します。
    2. Kube Descheduler Operator をフィルターボックスに入力します。
    3. Kube Descheduler Operator を選択し、Install をクリックします。
    4. Install Operator ページで、A specific namespace on the cluster を選択します。ドロップダウンメニューから openshift-kube-descheduler-operator を選択します。
    5. Update Channel および Approval Strategy の値を必要な値に調整します。
    6. Install をクリックします。

  4. descheduler インスタンスを作成します。

    1. Operators Installed Operators ページから、Kube Descheduler Operator をクリックします。
    2. Kube Descheduler タブを選択し、Create KubeDescheduler をクリックします。

    3. 必要に応じて設定を編集します。

      1. エビクションをシミュレーションせずに Pod をエビクトするには、Mode フィールドを Automatic に変更します。

      2. Profiles セクションを展開し、LongLifecycle を選択します。AffinityAndTaints プロファイルがデフォルトで有効になっています。

        重要

        現在 OpenShift Virtualization で使用できる唯一のプロファイルは LongLifecycle です。

また、後で OpenShift CLI (oc) を使用して、descheduler のプロファイルおよび設定を設定することもできます。

9.12.13.3. 仮想マシン (VM) での descheduler エビクションの有効化
リンクのコピー

descheduler のインストール後に、アノテーションを VirtualMachine カスタムリソース (CR) に追加して descheduler エビクションを仮想マシンで有効にできます。

前提条件

  • descheduler を OpenShift Container Platform Web コンソールまたは OpenShift CLI (oc) にインストールしている。

手順

  1. 仮想マシンを停止します。

  2. descheduler.alpha.kubernetes.io/evict アノテーションを VirtualMachine CR に追加します。OpenShift Virtualization 4.18 では、アノテーションの存在のみがチェックされます。値は評価されないため、"true" と "false" は同じ効果を持ちます。

    注記

    仮想マシンの実行中にアノテーションを追加すると、仮想マシンを再起動するまで、virt-launcher Pod には適用されません。 

    apiVersion: kubevirt.io/v1
kind: VirtualMachine
spec:
  template:
    metadata:
      annotations:
        descheduler.alpha.kubernetes.io/evict: "true"
    Copy to Clipboard Toggle word wrap

  3. LongLifecycle プロファイルを使用して KubeDescheduler オブジェクトを設定し、バックグラウンドエビクションを有効にして、ライブマイグレーション中の仮想マシンエビクションの安定性を向上させます。

    注記

    エビクションアノテーションが VM に設定されている場合、VM エビクションには LongLifecycle プロファイルで十分です。EvictPodsWithLocalStorage または EvictPodsWithPVC プロファイルを有効にしないでください。 

    apiVersion: operator.openshift.io/v1
kind: KubeDescheduler
metadata:
  name: cluster
  namespace: openshift-kube-descheduler-operator
spec:
  deschedulingIntervalSeconds: 3600
  profiles:
  - LongLifecycle
    1 
    
  mode: Predictive
    2 
    
  profileCustomizations:
    devEnableEvictionsInBackground: true
    3
    Copy to Clipboard Toggle word wrap
    1
    LongLifecycle プロファイルのみを設定できます。このプロファイルは、ノード間のリソース使用量のバランスを保ちます。
    2
    デフォルトでは、descheduler は Pod をエビクトしません。Pod をエビクトするには、mode を Automatic に設定します。
    3
    devEnableEvictionsInBackground 有効にすると、バックグラウンドでエビクションが実行され、安定性が向上し、ライブマイグレーション中の振動動作が軽減されます。
  4. 仮想マシンを起動します。

descheduler が仮想マシンで有効になりました。

9.12.14. 仮想マシンの高可用性について
リンクのコピー

障害が発生したノードを手動で削除して仮想マシンフェイルオーバーをトリガーするか、修復ノードを設定することによって、仮想マシンの高可用性を有効にすることができます。

障害が発生したノードを手動で削除する

ノードに障害が発生し、マシンヘルスチェックがクラスターにデプロイされていない場合、runStrategy: Always が設定された仮想マシンは正常なノードに自動的に移動しません。仮想マシンのフェイルオーバーをトリガーするには、Node オブジェクトを手動で削除する必要があります。

障害が発生したノードを削除して仮想マシンのフェイルオーバーをトリガーする を参照してください。

修復ノードの設定

OperatorHub から Self Node Remediation Operator または Fence Agents Remediation Operator をインストールし、マシンのヘルスチェックまたはノードの修復チェックを有効にすることで、修復ノードを設定できます。

ノードの修復、フェンシング、メンテナンスの詳細は、Red Hat OpenShift のワークロードの可用性 を参照してください。

9.12.15. 仮想マシンのコントロールプレーンのチューニング
リンクのコピー

OpenShift Virtualization は、コントロールプレーンレベルで次のチューニングオプションを提供します。

  • highBurst プロファイルは、固定 QPS と burst レートを使用して、1 つのバッチで数百の仮想マシンを作成します。
  • ワークロードの種類に基づいた移行設定の調整

9.12.15.1. highBurst プロファイルの設定
リンクのコピー

highBurst プロファイルを使用して、1 つのクラスター内に多数の仮想マシンを作成および維持します。

前提条件

  • OpenShift CLI (oc) がインストールされている。

手順

  • 次のパッチを適用して、highBurst チューニングポリシープロファイルを有効にします。 

    $ oc patch hyperconverged kubevirt-hyperconverged -n openshift-cnv \
  --type=json -p='[{"op": "add", "path": "/spec/tuningPolicy", \
  "value": "highBurst"}]'
    Copy to Clipboard Toggle word wrap

検証

  • 次のコマンドを実行して、highBurst チューニングポリシープロファイルが有効になっていることを確認します。 

    $ oc get kubevirt.kubevirt.io/kubevirt-kubevirt-hyperconverged \
  -n openshift-cnv -o go-template --template='{{range $config, \
  $value := .spec.configuration}} {{if eq $config "apiConfiguration" \
  "webhookConfiguration" "controllerConfiguration" "handlerConfiguration"}} \
  {{"\n"}} {{$config}} = {{$value}} {{end}} {{end}} {{"\n"}}
    Copy to Clipboard Toggle word wrap

9.12.16. コンピュートリソースの割り当て
リンクのコピー

OpenShift Virtualization では、仮想マシン (VM) に割り当てられたコンピュートリソースは、Guaranteed CPU またはタイムスライスされた CPU シェアのいずれかによってサポートされます。

Guaranteed CPU (CPU 予約とも呼ばれる) は、CPU コアまたはスレッドを特定のワークロード専用にし、他のワークロードでは使用できなくなります。Guaranteed CPU を仮想マシンに割り当てると、仮想マシンは予約された物理 CPU に単独でアクセスできるようになります。仮想マシンの専用リソースを有効化 し、Guaranteed CPU を使用します。

タイムスライス CPU は、共有物理 CPU 上の時間のスライスを各ワークロード専用にします。スライスのサイズは、仮想マシンの作成中、または仮想マシンがオフラインのときに指定できます。デフォルトでは、各仮想 CPU は 100 ミリ秒、つまり 1/10 秒の物理 CPU 時間を受け取ります。

CPU 予約のタイプは、インスタンスのタイプまたは仮想マシン設定によって異なります。

9.12.16.1. CPU リソースのオーバーコミット
リンクのコピー

タイムスライシングにより、複数の仮想 CPU (vCPU) が 1 つの物理 CPU を共有できます。これは CPU オーバーコミットメント として知られています。Guaranteed 仮想マシンをオーバーコミットすることはできません。

CPU を仮想マシンに割り当てるときに、パフォーマンスよりも仮想マシン密度を優先するように CPU オーバーコミットメントを設定します。仮想 CPU の CPU オーバーコミットメントが高くなると、より多くの仮想マシンが特定のノードに適合します。

9.12.16.2. CPU 割り当て率の設定
リンクのコピー

CPU 割り当て率は、仮想 CPU を物理 CPU のタイムスライスにマッピングすることにより、オーバーコミットメントの程度を指定します。

たとえば、10:1 のマッピングまたは比率は、タイムスライスを使用して、10 個の仮想 CPU を 1 個の物理 CPU にマッピングします。

各物理 CPU にマップされる仮想 CPU のデフォルトの数を変更するには、HyperConverged CR で vmiCPUAllocationRatio 値を設定します。Pod CPU リクエストは、仮想 CPU の数に CPU 割り当て率の逆数を乗算して計算されます。たとえば、vmiCPUAllocationRatio が 10 に設定されている場合、OpenShift Virtualization はその仮想マシンの Pod 上で 10 分の 1 少ない CPU を要求します。

前提条件

  • OpenShift CLI (oc) がインストールされている。

手順

HyperConverged CR で vmiCPUAllocationRatio 値を設定して、ノードの CPU 割り当て率を定義します。

  1. 以下のコマンドを実行して、デフォルトのエディターで HyperConverged CR を開きます。 

    $ oc edit hyperconverged kubevirt-hyperconverged -n openshift-cnv
    Copy to Clipboard Toggle word wrap

  2. vmiCPUAllocationRatio を設定します。 

    ...
spec:
  resourceRequirements:
    vmiCPUAllocationRatio: 1
    1 
    
# ...
    Copy to Clipboard Toggle word wrap
    1
    vmiCPUAllocationRatio が 1 に設定されている場合、Pod に対して最大量の仮想 CPU が要求されます。

9.12.17. マルチキュー機能について
リンクのコピー

マルチキュー機能を使用して、複数の仮想 CPU を備えた仮想マシン (VM) のネットワークスループットとパフォーマンスを拡張します。

デフォルトでは、ドメイン XML から派生した queueCount 値は、仮想マシンに割り当てられた仮想 CPU の数によって決まります。仮想 CPU の数が増えても、ネットワークパフォーマンスは向上しません。さらに、virtio-net には Tx キューと Rx キューが 1 つしかないため、ゲストはパケットを並行して送信または取得できません。

注記

ゲストインスタンス内の vNIC の数が仮想 CPU の数に比例する場合、virtio-net マルチキューを有効にしても大きな改善は得られません。

9.12.17.1. 既知の制限
リンクのコピー

  • virtio-net マルチキューがホストで有効になっているが、管理者によってゲストオペレーティングシステムで有効になっていない場合でも、MSI ベクトルは消費されます。
  • 各 virtio-net キューは、vhost ドライバー用に 64 KiB のカーネルメモリーを消費します。
  • networkInterfaceMultiqueue が 'true' に設定されている場合、CPU が 16 個を超えて搭載されている仮想マシンを起動すると接続できなくなります (CNV-16107)。

9.12.17.2. マルチキュー機能の有効化
リンクのコピー

VirtIO モデルで設定されたインターフェイスのマルチキュー機能を有効にします。

手順

  1. マルチキュー機能を有効にするには、仮想マシンの VirtualMachine マニフェストファイルで networkInterfaceMultiqueue 値を true に設定します。 

    apiVersion: kubevirt.io/v1
kind: VM
spec:
  domain:
    devices:
      networkInterfaceMultiqueue: true
    Copy to Clipboard Toggle word wrap
  2. VirtualMachine マニフェストファイルを保存して変更を適用します。

9.12.18. OpenShift GitOps を使用した仮想マシンの管理
リンクのコピー

OpenShift Virtualization で仮想マシン (VM) 管理を自動化および最適化するには、OpenShift GitOps を使用できます。

GitOps を使用すると、Git リポジトリーに保存されている設定ファイルに基づいて仮想マシンのデプロイメントをセットアップできます。これにより、これらの設定の自動化、更新、レプリケートが容易になり、バージョン管理を使用して変更を追跡することも容易になります。

前提条件

  • GitHub アカウントがある。アカウントをセットアップする手順については、Creating an account on GitHub を参照してください。
  • OpenShift Virtualuzation が OpenShift クラスターにインストールされている。手順については、OpenShift Virtualization のインストール を参照してください。
  • OpenShift GitOps Operator が OpenShift クラスターにインストールされている。手順については、GitOps のインストール を参照してください。

手順

これらの手順を実行する際は、Manage OpenShift virtual machines with GitOps のラーニングパス に従います。

  1. 外部 Git リポジトリーを Argo CD インスタンスに接続します。
  2. Git リポジトリーに必要な仮想マシン設定を作成します。
  3. 仮想マシン設定を使用して、クラスター上に仮想マシンを作成します。
トップに戻る
Red Hat logoGithubredditYoutubeTwitter

詳細情報

試用、購入および販売

コミュニティー

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

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

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

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

会社概要

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

Theme

© 2025 Red Hat