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

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

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

7.14.1.1. 仮想マシンのリソースクォータ制限の設定

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

手順

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

apiVersion: kubevirt.io/v1
kind: VirtualMachine
metadata:
  name: with-limits
spec:
  running: false
  template:
    spec:
      domain:
# ...
        resources:
          requests:
            memory: 128Mi
          limits:
            memory: 256Mi  1

1: この設定がサポートされるのは、limits.memory 値が requests.memory 値より少なくとも 100Mi 大きいためです。

VirtualMachine マニフェストを保存します。

7.14.1.2. 関連情報

7.14.2. 仮想マシンのノードの指定

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

7.14.2.1. 仮想マシンのノード配置について

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

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

注記

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

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

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

7.14.2.2. ノード配置の例

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

7.14.2.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
# ...

7.14.2.2.2. 例: Pod のアフィニティーおよび Pod の非アフィニティーによる仮想マシンノードの配置

この例では、仮想マシンはラベル 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
# ...

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

7.14.2.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
# ...

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

7.14.2.2.4. 例: 容認 (toleration) を使用した仮想マシンノードの配置

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

注記

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

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

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

7.14.2.3. 関連情報

7.14.3. kernel samepage merging (KSM) のアクティブ化

OpenShift Virtualization は、ノードが過負荷になると kernel samepage merging (KSM) をアクティブ化できます。KSM は、仮想マシンのメモリーページにある同一データの重複を排除します。非常によく似た仮想マシンがある場合に KSM を使用すると、シングルノード上で多くの仮想マシンをスケジュールできるようになります。

重要

KSM は、必ず信頼できるワークロードでのみ使用してください。

7.14.3.1. 前提条件

OpenShift Virtualization が KSM をアクティブ化するノード上で、管理者が KSM サポートを設定していることを確認する。

7.14.3.2. OpenShift Virtualization を使用して KSM をアクティブ化する

ノードでメモリーの過負荷が発生した場合に kernel samepage merging (KSM) をアクティブ化するように、OpenShift Virtualization を設定できます。

7.14.3.2.1. 設定方法

OpenShift Container Platform Web コンソールを使用するか、HyperConverged カスタムリソース (CR) を編集することで、すべてのノードの KSM アクティブ化機能を有効または無効にできます。HyperConverged CR は、より詳細な設定をサポートしています。

CR 設定

HyperConverged CR の spec.configuration.ksmConfiguration スタンザを編集することで、KSM アクティブ化機能を設定できます。

この機能を有効にして設定するには、ksmConfiguration スタンザを編集します。
この機能を無効にするには、ksmConfiguration スタンザを削除します。
ノード選択構文を ksmConfiguration.nodeLabelSelector フィールドに追加すると、OpenShift Virtualization はノードのサブセットのみで KSM を有効化できます。

注記

管理者は、OpenShift Virtualization で KSM アクティブ化機能が無効になっている場合でも、それをサポートするノードでは KSM を有効化できます。

7.14.3.2.2. KSM ノードのラベル

OpenShift Virtualization は、KSM をサポートするように設定されたノードを識別し、次のノードラベルを適用します。

kubevirt.io/ksm-handler-managed: "false": メモリーの過負荷が発生しているノード上で OpenShift Virtualization が KSM をアクティブ化すると、このラベルが "true" に設定されます。管理者が KSM をアクティブ化した場合、このラベルは "true" に設定されません。
kubevirt.io/ksm-enabled: "false": OpenShift Virtualization が KSM をアクティブ化しなかった場合でも、KSM がノード上でアクティブ化されると、このラベルは "true" に設定されます。

このラベルは、KSM をサポートしていないノードには適用されません。

7.14.3.3. Web コンソールを使用して KSM のアクティブ化を設定する

OpenShift Container Platform Web コンソールを使用して、OpenShift Virtualization がクラスター内のすべてのノードで kernel samepage merging (KSM) をアクティブ化できるように設定できます。

手順

サイドメニューから、Virtualization Overview をクリックします。
Settings タブを選択します。
Cluster タブを選択します。
Resource management を展開します。
すべてのノードの機能を有効または無効にします。
- Kernel Samepage Merging (KSM) をオンに設定します。
- Kernel Samepage Merging (KSM) をオフに設定します。

7.14.3.4. CLI を使用して KSM のアクティブ化を設定する

HyperConverged カスタムリソース (CR) を編集することで、OpenShift Virtualization の kernel samepage merging (KSM) アクティブ化機能を有効または無効にできます。OpenShift Virtualization がノードのサブセットのみで KSM をアクティブ化するように設定する場合は、この方法を使用します。

手順

以下のコマンドを実行して、デフォルトのエディターで HyperConverged CR を開きます。
```
$ oc edit hyperconverged kubevirt-hyperconverged -n openshift-cnv
```
ksmConfiguration スタンザを編集します。
- すべてのノードで KSM アクティブ化機能を有効にするには、nodeLabelSelector の値を {} に設定します。以下に例を示します。
```
apiVersion: hco.kubevirt.io/v1beta1
kind: HyperConverged
metadata:
  name: kubevirt-hyperconverged
  namespace: openshift-cnv
spec:
  configuration:
    ksmConfiguration:
      nodeLabelSelector: {}
# ...
```
- ノードのサブセットで KSM アクティブ化機能を有効にするには、nodeLabelSelector フィールドを編集します。OpenShift Virtualization が KSM を有効にするノードに一致する構文を追加します。たとえば次の設定では、OpenShift Virtualization は <first_example_key> と <second_example_key> の両方が "true" に設定されているノードで KSM を有効にできます。
```
apiVersion: hco.kubevirt.io/v1beta1
kind: HyperConverged
metadata:
  name: kubevirt-hyperconverged
  namespace: openshift-cnv
spec:
  configuration:
    ksmConfiguration:
      nodeLabelSelector:
        matchLabels:
          <first_example_key>: "true"
          <second_example_key>: "true"
# ...
```
- KSM アクティブ化機能を無効にするには、ksmConfiguration スタンザを削除します。以下に例を示します。
```
apiVersion: hco.kubevirt.io/v1beta1
kind: HyperConverged
metadata:
  name: kubevirt-hyperconverged
  namespace: openshift-cnv
spec:
  configuration:
# ...
```
ファイルを保存します。

7.14.3.5. 関連情報

仮想マシンのノードの指定
ノードセレクターの使用による特定ノードへの Pod の配置
Red Hat Enterprise Linux (RHEL) ドキュメントの kernel samepage merging の管理

7.14.4. 証明書ローテーションの設定

証明書ローテーションパラメーターを設定して、既存の証明書を置き換えます。

7.14.4.1. 証明書ローテーションの設定

これは、Web コンソールでの OpenShift Virtualization のインストール時に、または HyperConverged カスタムリソース (CR) でインストール後に実行することができます。

手順

以下のコマンドを実行して HyperConverged CR を開きます。
```
$ oc edit hyperconverged kubevirt-hyperconverged -n openshift-cnv
```
以下の例のように spec.certConfig フィールドを編集します。システムのオーバーロードを避けるには、すべての値が 10 分以上であることを確認します。golang ParseDuration 形式に準拠する文字列として、すべての値を表現します。
```
apiVersion: hco.kubevirt.io/v1beta1
kind: HyperConverged
metadata:
  name: kubevirt-hyperconverged
  namespace: openshift-cnv
spec:
  certConfig:
    ca:
      duration: 48h0m0s
      renewBefore: 24h0m0s 1
    server:
      duration: 24h0m0s  2
      renewBefore: 12h0m0s  3
```
1
ca.renewBefore の値は ca.duration の値以下である必要があります。
2
server.duration の値は ca.duration の値以下である必要があります。
3
server.renewBefore の値は server.duration の値以下である必要があります。
YAML ファイルをクラスターに適用します。

7.14.4.2. 証明書ローテーションパラメーターのトラブルシューティング

1 つ以上の certConfig 値を削除すると、デフォルト値が以下のいずれかの条件と競合する場合を除き、デフォルト値に戻ります。

ca.renewBefore の値は ca.duration の値以下である必要があります。
server.duration の値は ca.duration の値以下である必要があります。
server.renewBefore の値は server.duration の値以下である必要があります。

デフォルト値がこれらの条件と競合すると、エラーが発生します。

以下の例で server.duration 値を削除すると、デフォルト値の 24h0m0s は ca.duration の値よりも大きくなり、指定された条件と競合します。

例

certConfig:
   ca:
     duration: 4h0m0s
     renewBefore: 1h0m0s
   server:
     duration: 4h0m0s
     renewBefore: 4h0m0s

これにより、以下のエラーメッセージが表示されます。

error: hyperconvergeds.hco.kubevirt.io "kubevirt-hyperconverged" could not be patched: admission webhook "validate-hco.kubevirt.io" denied the request: spec.certConfig: ca.duration is smaller than server.duration

エラーメッセージには、最初の競合のみが記載されます。続行する前に、すべての certConfig の値を確認します。

7.14.5. デフォルトの CPU モデルの設定

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

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

仮想マシンに定義された CPU モデルがない場合:
- defaultCPUModel は、クラスター全体のレベルで定義された CPU モデルを使用して自動的に設定されます。
仮想マシンとクラスターの両方に CPU モデルが定義されている場合:
- 仮想マシンの CPU モデルが優先されます。
仮想マシンにもクラスターにも CPU モデルが定義されていない場合:
- ホストモデルは、ホストレベルで定義された CPU モデルを使用して自動的に設定されます。

7.14.5.1. デフォルトの CPU モデルの設定

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

注記

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

前提条件

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

手順

以下のコマンドを実行して HyperConverged CR を開きます。
```
$ oc edit hyperconverged kubevirt-hyperconverged -n openshift-cnv
```

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

apiVersion: hco.kubevirt.io/v1beta1
kind: HyperConverged
metadata:
 name: kubevirt-hyperconverged
 namespace: openshift-cnv
spec:
  defaultCPUModel: "EPYC"

YAML ファイルをクラスターに適用します。

7.14.6. 仮想マシンに UEFI モードを使用する

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

7.14.6.1. 仮想マシンの UEFI モードについて

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

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

7.14.6.2. UEFI モードでの仮想マシンの起動

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

前提条件

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

手順

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
# ...
```
1
OpenShift Virtualization では、UEFI モードでセキュアブートを実行するために SMM (System Management Mode) を有効にする必要があります。
2
OpenShift Virtualization は、UEFI モードを使用する場合に、セキュアブートの有無に関わらず、仮想マシンをサポートします。セキュアブートが有効な場合には、UEFI モードが必要です。ただし、セキュアブートを使用せずに UEFI モードを有効にできます。
以下のコマンドを実行して、マニフェストをクラスターに適用します。
```
$ oc create -f <file_name>.yaml
```

7.14.6.3. 永続的な EFI の有効化

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

前提条件

クラスター管理者の権限がある。
RWX アクセスモードと FS ボリュームモードをサポートするストレージクラスが必要です。

手順

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

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

7.14.6.4. 永続的な EFI を使用した仮想マシンの設定

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

前提条件

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

手順

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

apiVersion: kubevirt.io/v1
kind: VirtualMachine
metadata:
  name: vm
spec:
  template:
    spec:
      domain:
        firmware:
          bootloader:
            efi:
              persistent: true
# ...

7.14.7. 仮想マシンの PXE ブートの設定

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

7.14.7.1. 前提条件

Linux ブリッジが接続されている。
PXE サーバーがブリッジとして同じ VLAN に接続されている。

7.14.7.2. MAC アドレスを指定した PXE ブート

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

前提条件

Linux ブリッジが接続されている。
PXE サーバーがブリッジとして同じ VLAN に接続されている。

手順

クラスターに PXE ネットワークを設定します。
1. PXE ネットワーク pxe-net-conf のネットワーク接続定義ファイルを作成します。
```
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
    }
```
  1
  NetworkAttachmentDefinition オブジェクトの名前。
  2
  設定の名前。設定名をネットワーク接続定義の name 値に一致させることが推奨されます。
  3
  このネットワーク接続定義のネットワークを提供する Container Network Interface (CNI) プラグインの実際の名前。この例では、Linux ブリッジ CNI プラグインを使用します。OVN-Kubernetes localnet または SR-IOV CNI プラグインを使用することもできます。
  4
  ノードに設定される Linux ブリッジの名前。
  5
  オプション: MAC スプーフィングチェックを有効にするフラグ。true に設定すると、Pod またはゲストインターフェイスの MAC アドレスを変更できません。この属性により、Pod から出ることができる MAC アドレスは 1 つだけになり、MAC スプーフィング攻撃に対するセキュリティーが確保されます。
  6
  オプション: VLAN タグ。ノードのネットワーク設定ポリシーでは、追加の VLAN 設定は必要ありません。
  7
  オプション: 仮想マシンがデフォルト VLAN 経由でブリッジに接続するかどうかを示します。デフォルト値は true です。
直前の手順で作成したファイルを使用してネットワーク接続定義を作成します。
```
$ oc create -f pxe-net-conf.yaml
```
仮想マシンインスタンス設定ファイルを、インターフェイスおよびネットワークの詳細を含めるように編集します。
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
```
  注記
  複数のインターフェイスおよびディスクのブートの順序はグローバル順序になります。
2. オペレーティングシステムのプロビジョニング後に起動が適切に実行されるよう、ブートデバイス番号をディスクに割り当てます。
  ディスク bootOrder の値を 2 に設定します。
```
devices:
  disks:
  - disk:
      bus: virtio
    name: containerdisk
    bootOrder: 2
```
3. 直前に作成されたネットワーク接続定義に接続されるネットワークを指定します。このシナリオでは、<pxe-net> は <pxe-net-conf> というネットワーク接続定義に接続されます。
```
networks:
- name: default
  pod: {}
- name: pxe-net
  multus:
    networkName: pxe-net-conf
```

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

$ oc create -f vmi-pxe-boot.yaml

出力例

  virtualmachineinstance.kubevirt.io "vmi-pxe-boot" created

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

$ oc get vmi vmi-pxe-boot -o yaml | grep -i phase
  phase: Running

VNC を使用して仮想マシンインスタンスを表示します。
```
$ virtctl vnc vmi-pxe-boot
```
ブート画面で、PXE ブートが正常に実行されていることを確認します。
仮想マシンインスタンスにログインします。
```
$ virtctl console vmi-pxe-boot
```

検証

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

7.14.7.3. 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 リソースを使用して定義されるオブジェクト。
ネットワーク接続定義 (NAD): Multus プロジェクトによって導入された CRD。Pod、仮想マシン、および仮想マシンインスタンスを 1 つ以上のネットワークに接続できるようにします。
ノードネットワーク設定ポリシー (NNCP): nmstate プロジェクトによって導入された CRD。ノード上で要求されるネットワーク設定を表します。NodeNetworkConfigurationPolicy マニフェストをクラスターに適用して、インターフェイスの追加および削除など、ノードネットワーク設定を更新します。

7.14.8. 仮想マシンでの Huge Page の使用

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

7.14.8.1. 前提条件

ノードに事前に割り当てられた huge page が設定されている。

7.14.8.2. 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 を使用できるように仮想マシンを設定できます。

7.14.8.3. 仮想マシンの Huge Page の設定

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

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

注記

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

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

前提条件

ノードには、事前に割り当てられた Huge Page が設定されている必要がある。

手順

仮想マシン設定で、resources.requests.memory および memory.hugepages.pageSize パラメーターを spec.domain に追加します。以下の設定スニペットは、ページサイズが 1Gi の合計 4Gi メモリーを要求する仮想マシンに関するものです。
```
kind: VirtualMachine
# ...
spec:
  domain:
    resources:
      requests:
        memory: "4Gi" 1
    memory:
      hugepages:
        pageSize: "1Gi" 2
# ...
```
1
仮想マシンに要求されるメモリーの合計量。この値はページサイズで分ける必要があります。
2
各 Huge Page のサイズ。x86_64 アーキテクチャーの有効な値は 1Gi および 2Mi です。ページサイズは要求されたメモリーよりも小さくなければなりません。
仮想マシン設定を適用します。
```
$ oc apply -f <virtual_machine>.yaml
```

7.14.9. 仮想マシン用の専用リソースの有効化

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

7.14.9.1. 専用リソースについて

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

7.14.9.2. 前提条件

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

7.14.9.3. 仮想マシンの専用リソースの有効化

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

手順

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

7.14.10. 仮想マシンのスケジュール

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

7.14.10.1. ポリシー属性

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

ポリシー属性	説明
force	仮想マシンは強制的にノードでスケジュールされます。これは、ホストの CPU が仮想マシンの CPU に対応していない場合でも該当します。
require	仮想マシンが特定の CPU モデルおよび機能仕様で設定されていない場合に仮想マシンに適用されるデフォルトのポリシー。このデフォルトポリシー属性または他のポリシー属性のいずれかを持つ CPU ノードの検出をサポートするようにノードが設定されていない場合、仮想マシンはそのノードでスケジュールされません。ホストの CPU が仮想マシンの CPU をサポートしているか、ハイパーバイザーが対応している CPU モデルをエミュレートできる必要があります。
optional	仮想マシンがホストの物理マシンの CPU でサポートされている場合は、仮想マシンがノードに追加されます。
disable	仮想マシンは CPU ノードの検出機能と共にスケジュールすることはできません。
forbid	この機能がホストの CPU でサポートされ、CPU ノード検出が有効になっている場合でも、仮想マシンはスケジュールされません。

7.14.10.2. ポリシー属性および CPU 機能の設定

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

手順

仮想マシン設定ファイルの domain 仕様を編集します。以下の例では、仮想マシン (VM) の CPU 機能および require ポリシーを設定します。
```
apiVersion: kubevirt.io/v1
kind: VirtualMachine
metadata:
  name: myvm
spec:
  template:
    spec:
      domain:
        cpu:
          features:
            - name: apic 1
              policy: require 2
```
1
仮想マシンの名前。
2
仮想マシンのポリシー属性。

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

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

手順

仮想マシン設定ファイルの domain 仕様を編集します。以下の例は、VM 向けに定義された特定の CPU モデルを示しています。
```
apiVersion: kubevirt.io/v1
kind: VirtualMachine
metadata:
  name: myvm
spec:
  template:
    spec:
      domain:
        cpu:
          model: Conroe 1
```
1
VM の CPU モデル。

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

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

手順

仮想マシン設定ファイルの domain 仕様を編集します。以下の例は、仮想マシンに指定される host-model を示しています。
```
apiVersion: kubevirt/v1alpha3
kind: VirtualMachine
metadata:
  name: myvm
spec:
  template:
    spec:
      domain:
        cpu:
          model: host-model 1
```
1
スケジュールされるノードの CPU モデルを継承する仮想マシン。

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

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

前提条件

セカンダリースケジューラーがクラスター用に設定されています。

手順

VirtualMachine マニフェストを編集して、カスタムスケジューラーを仮想マシン設定に追加します。以下に例を示します。
```
apiVersion: kubevirt.io/v1
kind: VirtualMachine
metadata:
  name: vm-fedora
spec:
  running: true
  template:
    spec:
      schedulerName: my-scheduler 1
      domain:
        devices:
          disks:
            - name: containerdisk
              disk:
                bus: virtio
# ...
```
1
カスタムスケジューラーの名前。schedulerName 値が既存のスケジューラーと一致しない場合、virt-launcher Pod は、指定されたスケジューラーが見つかるまで Pending 状態のままになります。

検証

virt-launcher Pod イベントをチェックして、仮想マシンが VirtualMachine マニフェストで指定されたカスタムスケジューラーを使用していることを確認します。
1. 次のコマンドを入力して、クラスター内の Pod のリストを表示します。
```
$ oc get pods
```
  出力例
```
NAME                             READY   STATUS    RESTARTS   AGE
virt-launcher-vm-fedora-dpc87    2/2     Running   0          24m
```
2. 次のコマンドを実行して Pod イベントを表示します。
```
$ oc describe pod virt-launcher-vm-fedora-dpc87
```
  出力の From フィールドの値により、スケジューラー名が VirtualMachine マニフェストで指定されたカスタムスケジューラーと一致することが検証されます。
  出力例
```
[...]
Events:
  Type    Reason     Age   From              Message
  ----    ------     ----  ----              -------
  Normal  Scheduled  21m   my-scheduler  Successfully assigned default/virt-launcher-vm-fedora-dpc87 to node01
[...]
```

関連情報

セカンダリースケジューラーのデプロイ

7.14.11. PCI パススルーの設定

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

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

7.14.11.1. GPU パススルー用のノードの準備

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

7.14.11.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
```
1
<node_name> を、NVIDIA GPU オペランドをインストールしないノードの名前に置き換えます。

検証

次のコマンドを実行して、ラベルがノードに追加されたことを確認します。
```
$ oc describe node <node_name>
```

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

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

$ oc get pods -n nvidia-gpu-operator

出力例

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

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

$ oc get pods -n nvidia-gpu-operator

出力例

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

7.14.11.2. PCI パススルー用のホストデバイスの準備

7.14.11.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 デバイス情報を削除します。

7.14.11.2.2. IOMMU ドライバーを有効にするためのカーネル引数の追加

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

前提条件

クラスター管理者パーミッションがある。
CPU ハードウェアは Intel または AMD です。
BIOS で Directed I/O 拡張機能または AMD IOMMU 用の Intel Virtualization Technology を有効にしました。

手順

カーネル引数を識別する 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
# ...
```
1
新しいカーネル引数をワーカーノードのみに適用します。
2
name は、マシン設定とその目的におけるこのカーネル引数 (100) のランクを示します。AMD CPU がある場合は、カーネル引数を amd_iommu=on として指定します。
3
Intel CPU の intel_iommu としてカーネル引数を特定します。
新規 MachineConfig オブジェクトを作成します。
```
$ oc create -f 100-worker-kernel-arg-iommu.yaml
```

検証

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

7.14.11.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 を有効にするために追加している。

手順

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

$ lspci -nnv | grep -i nvidia

出力例

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

Butane 設定ファイル 100-worker-vfiopci.bu を作成し、PCI デバイスを VFIO ドライバーにバインドします。
注記
Butane の詳細は、「Butane を使用したマシン設定の作成」を参照してください。
例
```
variant: openshift
version: 4.16.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
```
1
新しいカーネル引数をワーカーノードのみに適用します。
2
以前に決定された vendor-ID 値 (10de) と device-ID 値 (1eb8) を指定して、単一のデバイスを VFIO ドライバーにバインドします。複数のデバイスのリストをベンダーおよびデバイス情報とともに追加できます。
3
ワーカーノードで vfio-pci カーネルモジュールを読み込むファイル。
Butane を使用して、ワーカーノードに配信される設定を含む MachineConfig オブジェクトファイル (100-worker-vfiopci.yaml) を生成します。
```
$ butane 100-worker-vfiopci.bu -o 100-worker-vfiopci.yaml
```
MachineConfig オブジェクトをワーカーノードに適用します。
```
$ oc apply -f 100-worker-vfiopci.yaml
```

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

$ oc get MachineConfig

出力例

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

検証

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

$ lspci -nnk -d 10de:

この出力では、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

7.14.11.2.4. CLI を使用したクラスターでの PCI ホストデバイスの公開

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

手順

以下のコマンドを実行して、デフォルトエディターで HyperConverged CR を編集します。
```
$ oc edit hyperconverged kubevirt-hyperconverged -n openshift-cnv
```
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
# ...
```
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 と動作することがテストおよび検証されています。
変更を保存し、エディターを終了します。

検証

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

$ oc describe node <node_name>

出力例

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

7.14.11.2.5. CLI を使用したクラスターからの PCI ホストデバイスの削除

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

手順

以下のコマンドを実行して、デフォルトエディターで HyperConverged CR を編集します。
```
$ oc edit hyperconverged kubevirt-hyperconverged -n openshift-cnv
```

適切なデバイスの 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"
# ...

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

検証

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

$ oc describe node <node_name>

出力例

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

7.14.11.3. PCI パススルー用の仮想マシンの設定

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

7.14.11.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
```
1
クラスターでホストデバイスとして許可される PCI デバイスの名前。仮想マシンがこのホストデバイスにアクセスできます。

検証

以下のコマンドを使用して、ホストデバイスが仮想マシンから利用可能であることを確認します。
```
$ lspci -nnk | grep NVIDIA
```
出力例
```
$ 02:01.0 3D controller [0302]: NVIDIA Corporation GV100GL [Tesla V100 PCIe 32GB] [10de:1eb8] (rev a1)
```

7.14.11.4. 関連情報

7.14.12. 仮想 GPU の設定

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

7.14.12.1. OpenShift Virtualization での仮想 GPU の使用について

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

注記

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

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

7.14.12.2. 仲介デバイス用のホストの準備

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

7.14.12.2.1. IOMMU ドライバーを有効にするためのカーネル引数の追加

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

前提条件

クラスター管理者パーミッションがある。
CPU ハードウェアは Intel または AMD です。
BIOS で Directed I/O 拡張機能または AMD IOMMU 用の Intel Virtualization Technology を有効にしました。

手順

カーネル引数を識別する 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
# ...
```
1
新しいカーネル引数をワーカーノードのみに適用します。
2
name は、マシン設定とその目的におけるこのカーネル引数 (100) のランクを示します。AMD CPU がある場合は、カーネル引数を amd_iommu=on として指定します。
3
Intel CPU の intel_iommu としてカーネル引数を特定します。
新規 MachineConfig オブジェクトを作成します。
```
$ oc create -f 100-worker-kernel-arg-iommu.yaml
```

検証

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

7.14.12.3. NVIDIA GPU Operator の設定

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

注記

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

7.14.12.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) ワークロードのプロビジョニングを特に容易にします。

7.14.12.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

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 パススルーを設定します。

関連情報

PCI パススルーの設定

7.14.12.4. 仮想 GPU がノードに割り当てられる方法

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

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

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

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

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

# ...
mediatedDevicesConfiguration:
  mediatedDeviceTypes:
  - nvidia-222
  - nvidia-228
  - nvidia-105
  - nvidia-108
# ...

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

nvidia-105
# ...
nvidia-108
nvidia-217
nvidia-299
# ...

各ノードで、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
# ...

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

7.14.12.5. 仲介されたデバイスの管理

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

7.14.12.5.1. 仲介デバイスの作成および公開

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

前提条件

入出力メモリー管理ユニット (IOMMU) ドライバーを有効にしました。
ハードウェアベンダーがドライバーを提供している場合は、仲介デバイスを作成するノードにドライバーをインストールしている。
- NVIDIA カードを使用する場合は、NVIDIA GRID ドライバーをインストールしている。

手順

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

$ oc edit hyperconverged kubevirt-hyperconverged -n openshift-cnv

例7.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
# ...

仲介デバイスを spec.mediatedDevicesConfiguration スタンザに追加して作成します。
YAML スニペットの例
```
# ...
spec:
  mediatedDevicesConfiguration:
    mediatedDeviceTypes: 1
    - <device_type>
    nodeMediatedDeviceTypes: 2
    - mediatedDeviceTypes: 3
      - <device_type>
      nodeSelector: 4
        <node_selector_key>: <node_selector_value>
# ...
```
1
必須: クラスターのグローバル設定を定義します。
2
オプション: 特定のノードまたはノードのグループのグローバル設定をオーバーライドします。グローバルの mediatedDeviceTypes 設定と併用する必要があります。
3
nodeMediatedDeviceTypes を使用する場合に必須です。指定されたノードのグローバル mediatedDeviceTypes 設定をオーバーライドします。
4
nodeMediatedDeviceTypes を使用する場合に必須です。key:value ペアを含める必要があります。
重要
OpenShift Virtualization 4.14 より前では、mediatedDeviceTypes フィールドの名前は mediatedDevicesTypes でした。仲介デバイスを設定するときは、必ず正しいフィールド名を使用してください。
クラスターに公開するデバイスの名前セレクターとリソース名の値を特定します。次のステップで、これらの値を HyperConverged CR に追加します。
1. 次のコマンドを実行して、resourceName 値を見つけます。
```
$ oc get $NODE -o json \
  | jq '.status.allocatable \
    | with_entries(select(.key | startswith("nvidia.com/"))) \
    | with_entries(select(.value != "0"))'
```
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 タイプを使用できます。
mdevNameSelector と resourceName の値を HyperConverged CR の spec.permittedHostDevices.mediatedDevices スタンザに追加することで、仲介されたデバイスをクラスターに公開します。
YAML スニペットの例
```
# ...
  permittedHostDevices:
    mediatedDevices:
    - mdevNameSelector: GRID T4-2Q 1
      resourceName: nvidia.com/GRID_T4-2Q 2
# ...
```
1
この値にマッピングする仲介デバイスをホスト上に公開します。
2
ノードに割り当てられているリソース名と一致します。
変更を保存し、エディターを終了します。

検証

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

7.14.12.5.2. 仲介デバイスの変更および削除について

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

HyperConverged CR を編集し、mediatedDeviceTypes スタンザの内容を変更します。
nodeMediatedDeviceTypes ノードセレクターに一致するノードラベルを変更します。
HyperConverged CR の spec.mediatedDevicesConfiguration および spec.permittedHostDevices スタンザからデバイス情報を削除します。
注記
spec.permittedHostDevices スタンザからデバイス情報を削除したが、spec.mediatedDevicesConfiguration スタンザからは削除しなかった場合、同じノードで新規の仲介デバイスタイプを作成することはできません。仲介デバイスを適切に削除するには、両方のスタンザからデバイス情報を削除します。

7.14.12.5.3. 仲介されたデバイスをクラスターから削除する

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

手順

以下のコマンドを実行して、デフォルトエディターで HyperConverged CR を編集します。
```
$ oc edit hyperconverged kubevirt-hyperconverged -n openshift-cnv
```
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
```
1
nvidia-231 デバイスタイプを削除するには、これを mediatedDeviceTypes 配列から削除します。
2
GRID T4-2Q デバイスを削除するには、mdevNameSelector フィールドおよび対応する resourceName フィールドを削除します。
変更を保存し、エディターを終了します。

7.14.12.6. 仲介デバイスの使用

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

7.14.12.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
```
1
仲介デバイスに関連付けられたリソース名。
2
仮想マシン上のデバイスを識別する名前。

検証

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

7.14.12.6.2. Web コンソールを使用した仮想マシンへの vGPU の割り当て

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

注記

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

前提条件

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

手順

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

検証

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

7.14.12.7. 関連情報

BIOS での Intel VT-X および AMD-V Virtualization ハードウェア拡張の有効化

7.14.13. 仮想マシンでの Descheduler エビクションの有効化

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

重要

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

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

7.14.13.1. Descheduler プロファイル

テクノロジープレビューの DevPreviewLongLifecycle プロファイルを使用して、仮想マシンで Descheduler を有効にします。これは、現在 OpenShift Virtualization で利用可能な唯一の Descheduler プロファイルです。適切なスケジューリングを確保するには、予想される負荷に応じた CPU およびメモリー要求で仮想マシンを作成します。

DevPreviewLongLifecycle

このプロファイルは、ノード間のリソース使用率のバランスを取り、以下のストラテジーを有効にします。

RemovePodsHavingTooManyRestarts: コンテナーが何度も再起動された Pod、およびすべてのコンテナー (Init コンテナーを含む) の再起動の合計が 100 を超える Pod を削除します。仮想マシンのゲストオペレーティングシステムを再起動しても、この数は増えません。
LowNodeUtilization: 使用率の低いノードがある場合に、使用率の高いノードから Pod をエビクトします。エビクトされた Pod の宛先ノードはスケジューラーによって決定されます。
- ノードは、使用率がすべてのしきい値 (CPU、メモリー、Pod の数) について 20% 未満の場合に使用率が低いと見なされます。
- ノードは、使用率がすべてのしきい値 (CPU、メモリー、Pod の数) について 50% を超える場合に過剰に使用されていると見なされます。

7.14.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 コンソールにアクセスできる。

手順

OpenShift Container Platform Web コンソールにログインします。
Kube Descheduler Operator に必要な namespace を作成します。
1. Administration Namespaces に移動し、Create Namespace をクリックします。
2. Name フィールドに openshift-kube-descheduler-operator を入力し、Labels フィールドに openshift.io/cluster-monitoring=true を入力して Descheduler メトリックを有効にし、Create をクリックします。
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 をクリックします。
Descheduler インスタンスを作成します。
1. Operators Installed Operators ページから、Kube Descheduler Operator をクリックします。
2. Kube Descheduler タブを選択し、Create KubeDescheduler をクリックします。
3. 必要に応じて設定を編集します。
  1. エビクションをシミュレーションせずに Pod をエビクトするには、Mode フィールドを Automatic に変更します。
  2. Profiles セクションを展開し、DevPreviewLongLifecycle を選択します。AffinityAndTaints プロファイルがデフォルトで有効になっています。
    重要
    OpenShift Virtualization で現在利用できるプロファイルは DevPreviewLongLifecycle のみです。

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

7.14.13.3. 仮想マシン (VM) での Descheduler エビクションの有効化

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

前提条件

Descheduler を OpenShift Container Platform Web コンソールまたは OpenShift CLI (oc) にインストールしている。
仮想マシンが実行されていないことを確認します。

手順

仮想マシンを起動する前に、descheduler.alpha.kubernetes.io/evict アノテーションを VirtualMachine CR に追加します。

apiVersion: kubevirt.io/v1
kind: VirtualMachine
spec:
  template:
    metadata:
      annotations:
        descheduler.alpha.kubernetes.io/evict: "true"

インストール時に Web コンソールで DevPreviewLongLifecycle プロファイルをまだ設定していない場合は、KubeDescheduler オブジェクトの spec.profile セクションに DevPreviewLongLifecycle を指定します。
```
apiVersion: operator.openshift.io/v1
kind: KubeDescheduler
metadata:
  name: cluster
  namespace: openshift-kube-descheduler-operator
spec:
  deschedulingIntervalSeconds: 3600
  profiles:
  - DevPreviewLongLifecycle
  mode: Predictive 1
```
1
デフォルトでは、Descheduler は Pod をエビクトしません。Pod をエビクトするには、mode を Automatic に設定します。

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

7.14.13.4. 関連情報

デスケジューラーの概要

7.14.14. 仮想マシンの高可用性について

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

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

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

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

修復ノードの設定

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

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

7.14.15. 仮想マシンのコントロールプレーンのチューニング

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

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

7.14.15.1. highBurst プロファイルの設定

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

手順

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

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

検証

次のコマンドを実行して、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"}}

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

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

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

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

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

7.14.16.1. CPU リソースのオーバーコミット

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

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

7.14.16.2. CPU 割り当て率の設定

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

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

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

手順

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

以下のコマンドを実行して、デフォルトのエディターで HyperConverged CR を開きます。
```
$ oc edit hyperconverged kubevirt-hyperconverged -n openshift-cnv
```
vmiCPUAllocationRatio を設定します。
```
...
spec:
  resourceRequirements:
    vmiCPUAllocationRatio: 1 1
# ...
```
1
vmiCPUAllocationRatio が 1 に設定されている場合、Pod に対して最大量の vCPU が要求されます。

7.14.16.3. 関連情報

Pod Quality of Service Classes

7.14.17. マルチキュー機能について

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

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

注記

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

7.14.17.1. 既知の制限

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

7.14.17.2. マルチキュー機能の有効化

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

手順

マルチキュー機能を有効にするには、仮想マシンの VirtualMachine マニフェストファイルで networkInterfaceMultiqueue 値を true に設定します。
```
apiVersion: kubevirt.io/v1
kind: VM
spec:
  domain:
    devices:
      networkInterfaceMultiqueue: true
```
VirtualMachine マニフェストファイルを保存して変更を適用します。