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

手順

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. kubevirt_vm タスクを含むように Ansible Playbook YAML ファイルを編集します。

     kubevirt_vm:
       namespace:
       name:
       cpu_cores:
       memory:
       disks:
         - name:
           volume:
             containerDisk:
               image:
           disk:
             bus:

   注記

   このスニペットには Playbook の kubevirt_vm 部分のみが含まれます。

2. namespace、cpu_cores の数、memory、および disks を含む、作成する必要のある仮想マシンを反映させるように値を編集します。以下に例を示します。

     kubevirt_vm:
       namespace: default
       name: vm1
       cpu_cores: 1
       memory: 64Mi
       disks:
         - name: containerdisk
           volume:
             containerDisk:
               image: kubevirt/cirros-container-disk-demo:latest
           disk:
             bus: virtio

3. 仮想マシンを作成後すぐに起動する必要がある場合には、state: running を YAML ファイルに追加します。以下に例を示します。

     kubevirt_vm:
       namespace: default
       name: vm1
       state: running 1
       cpu_cores: 1

   1

   この値を state: absent に変更すると、すでに存在する場合に仮想マシンは削除されます。

4. Playbook のファイル名を引数としてのみ使用して、 ansible-playbook コマンドを実行します。

   $ ansible-playbook create-vm.yaml

5. 出力を確認し、プレイが正常に実行されたかどうかを確認します。

   出力例

   (...)
   TASK [Create my first VM] ************************************************************************
   changed: [localhost]
   
   PLAY RECAP ********************************************************************************************************
   localhost                  : ok=2    changed=1    unreachable=0    failed=0    skipped=0    rescued=0    ignored=0

6. Playbook ファイルに state: running を含めず、すぐに仮想マシンを起動する必要がある場合には、 state: running を含めるようにファイルを編集し、Playbook を再度実行します。

   $ ansible-playbook create-vm.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 を開きます。

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