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

手順

1. 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 大きいためです。

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

手順

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

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

2. 以下の例のように 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 の値以下である必要があります。

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

手順

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

   1

   OpenShift Virtualization では、UEFI モードでセキュアブートを実行するために SMM (System Management Mode) を有効にする必要があります。

   2

   OpenShift Virtualization は、UEFI モードを使用する場合に、セキュアブートの有無に関わらず、仮想マシンをサポートします。セキュアブートが有効な場合には、UEFI モードが必要です。ただし、セキュアブートを使用せずに UEFI モードを有効にできます。

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

   $ oc create -f <file_name>.yaml

手順

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

   1. PXE ネットワーク pxe-net-conf のネットワーク接続定義ファイルを作成します。

      apiVersion: "k8s.cni.cncf.io/v1"
      kind: NetworkAttachmentDefinition
      metadata:
        name: pxe-net-conf
      spec:
        config: '{
          "cniVersion": "0.3.1",
          "name": "pxe-net-conf",
          "plugins": [
            {
              "type": "cnv-bridge",
              "bridge": "br1",
              "vlan": 1 1
            },
            {
              "type": "cnv-tuning" 2
            }
          ]
        }'

      1

      オプション: VLAN タグ。

      2

      cnv-tuning プラグインは、カスタム MAC アドレスのサポートを提供します。

      注記

      仮想マシンインスタンスは、必要な VLAN のアクセスポートでブリッジ br1 に割り当てられます。

2. 直前の手順で作成したファイルを使用してネットワーク接続定義を作成します。

   $ oc create -f pxe-net-conf.yaml

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

      注記

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

   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

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

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

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

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

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

   $ virtctl vnc vmi-pxe-boot

3. ブート画面で、PXE ブートが正常に実行されていることを確認します。

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

   $ virtctl console vmi-pxe-boot

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

   $ ip addr

手順

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

   1

   仮想マシンに要求されるメモリーの合計量。この値はページサイズで分ける必要があります。

   2

   各 Huge Page のサイズ。x86_64 アーキテクチャーの有効な値は 1Gi および 2Mi です。ページサイズは要求されたメモリーよりも小さくなければなりません。

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

   $ oc apply -f <virtual_machine>.yaml

手順

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

手順

1. Open Shift Container Platform Web コンソールで、サイドメニューから Virtualization → VirtualMachines をクリックします。
2. デバイスを割り当てる仮想マシンを選択します。

3. Details タブで、GPU devices をクリックします。

   vGPU デバイスをホストデバイスとして追加すると、VNC コンソールでデバイスにアクセスすることはできません。

4. Add GPU device をクリックし、Name を入力して、Device name リストからデバイスを選択します。
5. Save をクリックします。
6. YAMLタブをクリックして、クラスター設定の hostDevicesセクションに新しいデバイスが追加されていることを確認します。

手順

1. 以下の内容を含む YAML ファイルを作成します。

   apiVersion: kubevirt.io/v1
   kind: VirtualMachine
   metadata:
     labels:
       kubevirt.io/vm: vm2-rhel84-watchdog
     name: <vm-name>
   spec:
     running: false
     template:
       metadata:
        labels:
           kubevirt.io/vm: vm2-rhel84-watchdog
       spec:
         domain:
           devices:
             watchdog:
               name: <watchdog>
               i6300esb:
                 action: "poweroff" 1
   ...

   1

   watchdog アクション (poweroff、reset、または shutdown) を指定します。

   上記の例では、電源オフアクションを使用して、RHEL8 VM で i6300esb ウォッチドッグデバイスを設定し、デバイスを /dev/watchdog として公開します。

   このデバイスは、ウォッチドッグバイナリーで使用できるようになりました。

2. 以下のコマンドを実行して、YAML ファイルをクラスターに適用します。

   $ oc apply -f <file_name>.yaml

1. 以下のコマンドを実行して、VM がウォッチドッグデバイスに接続されていることを確認します。

   $ lspci | grep watchdog -i

2. 以下のコマンドのいずれかを実行して、ウォッチドッグがアクティブであることを確認します。

   • カーネルパニックをトリガーします。

     # echo c > /proc/sysrq-trigger

   • ウォッチドッグサービスを終了します。

     # pkill -9 watchdog

手順

1. root ユーザーとして、watchdog パッケージおよび依存関係をインストールします。

   # yum install watchdog

2. /etc/watchdog.conf ファイルの以下の行のコメントを解除して、変更を保存します。

   #watchdog-device = /dev/watchdog

3. ウォッチドッグサービスが起動時に開始できるように有効化します。

   # systemctl enable --now watchdog.service

手順

1. HyperConverged カスタムリソース (CR) を編集して、新しい storageClassName を定義します。

   apiVersion: hco.kubevirt.io/v1beta1
   kind: HyperConverged
   metadata:
     name: kubevirt-hyperconverged
   spec:
     dataImportCronTemplates:
     - metadata:
         name: rhel8-image-cron
       spec:
         template:
           spec:
             storageClassName: <appropriate_class_name>
   ...

2. 次のコマンドを実行して、新しいデフォルトのストレージクラスを設定します。

   $ oc patch storageclass <current_default_storage_class> -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"false"}}}'

   $ oc patch storageclass <appropriate_storage_class> -p '{"metadata": {"annotations":{"storageclass.kubernetes.io/is-default-class":"true"}}}'

手順

1. 以下のコマンドを使用して、編集するために HyperConverged CR を開きます。

   $ oc edit -n openshift-cnv HyperConverged

2. 適切なテンプレートおよびブートソースを dataImportCronTemplates セクションで追加して、HyperConverged CR を編集します。以下に例を示します。

   CentOS 7 の例

   apiVersion: hco.kubevirt.io/v1beta1
   kind: HyperConverged
   metadata:
     name: kubevirt-hyperconverged
   spec:
     dataImportCronTemplates:
     - metadata:
         name: centos7-image-cron
         annotations:
           cdi.kubevirt.io/storage.bind.immediate.requested: "true" 1
       spec:
         schedule: "0 */12 * * *" 2
         template:
           spec:
             source:
               registry: 3
                 url: docker://quay.io/containerdisks/centos:7-2009
             storage:
               resources:
                 requests:
                   storage: 10Gi
         managedDataSource: centos7 4
         retentionPolicy: "None" 5

   1

   このアノテーションは、volumeBindingMode が WaitForFirstConsumer に設定されたストレージクラスに必要です。

   2

   cron 形式で指定されるジョブのスケジュール。

   3

   レジストリーソースからデータボリュームを作成するのに使用します。node docker キャッシュに基づくデフォルトの node pullMethod ではなく、デフォルトの pod pullMethod を使用します。node docker キャッシュはレジストリーイメージがContainer.Image で利用可能な場合に便利ですが、CDI インポーターはこれにアクセスすることは許可されていません。

   4

   利用可能なブートソースとして検出するカスタムイメージの場合、イメージの managedDataSource の名前が、仮想マシンテンプレート YAML ファイルの spec.dataVolumeTemplates.spec.sourceRef.name にあるテンプレートの DataSource の名前に一致する必要があります。

   5

   cron ジョブが削除されたときにデータボリュームおよびデータソースを保持するには、All を使用します。cron ジョブが削除されたときにデータボリュームおよびデータソースを削除するには、None を使用します。

手順

1. oc get コマンドを使用して、HyperConverged CR 内の dataImportChronTemplates を一覧表示します。

2. ブートソースのステータスを確認します。

   出力例

   ...
   apiVersion: hco.kubevirt.io/v1beta1
   kind: HyperConverged
   ...
   spec:
     ...
   status: 1
     ...
     dataImportCronTemplates: 2
     - metadata:
         annotations:
           cdi.kubevirt.io/storage.bind.immediate.requested: "true"
         name: centos-7-image-cron
       spec:
         garbageCollect: Outdated
         managedDataSource: centos7
         schedule: 55 8/12 * * *
         template:
           metadata: {}
           spec:
             source:
               registry:
                 url: docker://quay.io/containerdisks/centos:7-2009
             storage:
               resources:
                 requests:
                   storage: 30Gi
           status: {}
       status:
         commonTemplate: true 3
       ...
     - metadata:
         annotations:
           cdi.kubevirt.io/storage.bind.immediate.requested: "true"
         name: user-defined-dic
       spec:
         garbageCollect: Outdated
         managedDataSource: user-defined-centos-stream8
         schedule: 55 8/12 * * *
         template:
           metadata: {}
           spec:
             source:
               registry:
                 pullMethod: node
                 url: docker://quay.io/containerdisks/centos-stream:8
             storage:
               resources:
                 requests:
                   storage: 30Gi
           status: {}
       status: {} 4
   ...

   1

   HyperConverged CR の status フィールド。

   2

   定義されたすべてのブートソースを一覧表示する dataImportCronTemplates フィールド。

   3

   システム定義のブートソースを示します。

   4

   ユーザー定義のブートソースを示します。

手順

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 セクションを展開し、DevPreviewLongLifecycle を選択します。AffinityAndTaints プロファイルがデフォルトで有効になっています。

         重要

         OpenShift Virtualization で現在利用できるプロファイルは DevPreviewLongLifecycle のみです。

手順

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

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

2. インストール時に 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 に設定します。