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

7.14.1. 管理タスクの自動化

Red Hat Ansible Automation Platform を使用すると、OpenShift Virtualization 管理タスクを自動化できます。Ansible Playbook を使用して新規の仮想マシンを作成する際の基本事項を確認します。

7.14.1.1. Red Hat Ansible Automation について

Ansible は、システムの設定、ソフトウェアのデプロイ、およびローリング更新の実行に使用する自動化ツールです。Ansible には OpenShift Virtualization のサポートが含まれ、Ansible モジュールを使用すると、テンプレート、永続ボリューム要求 (PVC) および仮想マシンの操作などのクラスター管理タスクを自動化できます。

Ansible は、oc CLI ツールや API を使用しても実行できる OpenShift Virtualization の管理を自動化する方法を提供します。Ansible は、KubeVirt モジュール を他の Ansible モジュールと統合できる点でユニークであると言えます。

7.14.1.2. 仮想マシン作成の自動化

kubevirt_vm Ansible Playbook を使用し、Red Hat Ansible Automation Platform を使用して OpenShift Container Platform クラスターに仮想マシンを作成できます。

前提条件

手順

  1. kubevirt_vm タスクを含むように Ansible Playbook YAML ファイルを編集します。

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

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

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

仮想マシンが作成されたことを確認するには、仮想マシンコンソールへのアクセス を試行します。

7.14.1.3. 例: 仮想マシンを作成するための Ansible Playbook

kubevirt_vm Ansible Playbook を使用して仮想マシン作成を自動化できます。

以下の YAML ファイルは kubevirt_vm Playbook の例です。これには、Playbook を実行する際に独自の情報を置き換える必要のあるサンプルの値が含まれます。

---
- name: Ansible Playbook 1
  hosts: localhost
  connection: local
  tasks:
    - name: Create my first VM
      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

7.14.2. 仮想マシンの EFI モードの使用

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

7.14.2.1. 仮想マシンの EFI モードについて

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

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

注記

OpenShift Virtualization は、EFI モードを使用する場合、セキュアブートを使用した仮想マシン (VM) のみをサポートします。セキュアブートが有効にされていない場合は、仮想マシンが繰り返しクラッシュします。ただし、仮想マシンはセキュアブートに対応していない可能性があります。仮想マシンを起動する前に、仮想マシン設定を確認して、これがセキュアブートに対応していることを確認します。

7.14.2.2. EFI モードでの仮想マシンのブート

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

前提条件

  • OpenShift CLI (oc) をインストールしている。

手順

  1. 仮想マシンオブジェクトまたは Virtual Machine Instance (VMI) オブジェクトを定義する YAML ファイルを作成します。サンプル YAML ファイルのファームウェアの スタンザを使用します。

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

      apiversion: kubevirt.io/v1
      kind: VirtualMachineInstance
      metadata:
        labels:
          special: vmi-secureboot
        name: vmi-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 では、EFI モードでセキュアブートを実行するために SMM (System Management Mode) を有効にする必要があります。
    2
    OpenShift Virtualization は、EFI モードを使用する場合、セキュアブートを使用した仮想マシン (VM) のみをサポートします。セキュアブートが有効にされていない場合は、仮想マシンが繰り返しクラッシュします。ただし、仮想マシンはセキュアブートに対応していない可能性があります。仮想マシンを起動する前に、仮想マシン設定を確認して、これがセキュアブートに対応していることを確認します。
  2. 以下のコマンドを実行して、マニフェストをクラスターに適用します。

    $ oc create -f <file_name>.yaml

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

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

7.14.3.1. 前提条件

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

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

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

前提条件

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

手順

  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 アドレスが指定されていない場合、値は自動的に割り当てられます。ただし、この時点で自動的に割り当てられる MAC アドレスは永続しないことに注意してください。

      bootOrder1 に設定されており、インターフェイスが最初に起動することを確認します。この例では、インターフェイスは <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

出力例

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

  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

出力例

...
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.3.3. テンプレート: PXE ブートの仮想マシンインスタンス設定ファイル

apiVersion: kubevirt.io/v1alpha3
kind: VirtualMachineInstance
metadata:
  creationTimestamp: null
  labels:
    special: vmi-pxe-boot
  name: vmi-pxe-boot
spec:
  domain:
    devices:
      disks:
      - disk:
          bus: virtio
        name: containerdisk
        bootOrder: 2
      - disk:
          bus: virtio
        name: cloudinitdisk
      interfaces:
      - masquerade: {}
        name: default
      - bridge: {}
        name: pxe-net
        macAddress: de:00:00:00:00:de
        bootOrder: 1
    machine:
      type: ""
    resources:
      requests:
        memory: 1024M
  networks:
  - name: default
    pod: {}
  - multus:
      networkName: pxe-net-conf
    name: pxe-net
  terminationGracePeriodSeconds: 0
  volumes:
  - name: containerdisk
    containerDisk:
      image: kubevirt/fedora-cloud-container-disk-demo
  - cloudInitNoCloud:
      userData: |
        #!/bin/bash
        echo "fedora" | passwd fedora --stdin
    name: cloudinitdisk
status: {}

7.14.3.4. OpenShift Virtualization ネットワークの用語集

OpenShift Virtualization は、カスタムリソースおよびプラグインを使用して高度なネットワーク機能を提供します。

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

Container Network Interface (CNI)
コンテナーのネットワーク接続に重点を置く Cloud Native Computing Foundation プロジェクト。OpenShift Virtualization は CNI プラグインを使用して基本的な Kubernetes ネットワーク機能を強化します。
Multus
複数の CNI の存在を可能にし、Pod または仮想マシンが必要なインターフェイスを使用できるようにするメタ CNI プラグイン。
カスタムリソース定義 (CRD、Custom Resource Definition)
カスタムリソースの定義を可能にする Kubernetes API リソース、または CRD API リソースを使用して定義されるオブジェクト。
ネットワーク接続定義
Pod、仮想マシン、および仮想マシンインスタンスを 1 つ以上のネットワークに割り当てることを可能にする Multus プロジェクトによって導入される CRD。
PXE (Preboot eXecution Environment)
管理者がネットワーク経由でサーバーからクライアントマシンを起動できるようにするインターフェイス。ネットワークのブートにより、オペレーティングシステムおよび他のソフトウェアをクライアントにリモートでロードできます。

7.14.4. ゲストメモリーの管理

ゲストメモリー設定を特定のユースケースに合わせて調整する必要がある場合、ゲストの YAML 設定ファイルを編集してこれを実行できます。OpenShift Virtualization は、ゲストメモリーのオーバーコミットの設定と、ゲストメモリーのオーバーコミットアカウンティングの無効化を許可します。

警告

以下の手順では、メモリー不足により仮想マシンのプロセスが強制終了される可能性を高めます。リスクを理解している場合にのみ続行してください。

7.14.4.1. ゲストメモリーのオーバーコミットの設定

仮想ワークロードに利用可能な量を上回るメモリーが必要な場合、メモリーのオーバーコミットを使用してホストのメモリーのすべてまたはそのほとんどを仮想マシンインスタンス (VMI) に割り当てることができます。メモリーのオーバーコミットを有効にすることは、通常ホストに予約されるリソースを最大化できることを意味します。

たとえば、ホストに 32 GB RAM がある場合、メモリーのオーバーコミットを使用してそれぞれ 4 GB RAM を持つ 8 つの仮想マシン (VM) に対応できます。これは、仮想マシンがそれらのメモリーのすべてを同時に使用しないという前提で機能します。

重要

メモリーのオーバーコミットにより、メモリー不足 (OOM による強制終了) が原因で仮想マシンプロセスが強制終了される可能性が高くなります。

仮想マシンが OOM で強制終了される可能性は、特定の設定、ノードメモリー、利用可能な swap 領域、仮想マシンのメモリー消費、カーネルの same-page merging (KSM) の使用その他の要因によって変わります。

手順

  1. 仮想マシンインスタンスに対し、クラスターから要求された以上のメモリーが利用可能であることを明示的に示すために、仮想マシン設定ファイルを編集し、spec.domain.memory.guestspec.domain.resources.requests.memory よりも高い値に設定します。このプロセスはメモリーのオーバーコミットと呼ばれています。

    以下の例では、1024M がクラスターから要求されますが、仮想マシンインスタンスには 2048M が利用可能であると通知されます。ノードに利用可能な空のメモリーが十分にある限り、仮想マシンインスタンスは最大 2048M を消費します。

    kind: VirtualMachine
    spec:
      template:
        domain:
        resources:
            requests:
              memory: 1024M
        memory:
            guest: 2048M
    注記

    ノードがメモリー不足の状態になると、Pod のエビクションルールと同じルールが仮想マシンインスタンスに適用されます。

  2. 仮想マシンを作成します。

    $ oc create -f <file_name>.yaml

7.14.4.2. ゲストメモリーオーバーヘッドアカウンティングの無効化

要求する量に加えて、少量のメモリーが各仮想マシンインスタンスによって要求されます。追加のメモリーは、それぞれの VirtualMachineInstance プロセスをラップするインフラストラクチャーに使用されます。

通常は推奨される方法ではありませんが、ゲストメモリーオーバーヘッドアカウンティングを無効にすることでノード上の仮想マシンインスタンスの密度を増やすことは可能です。

重要

ゲストメモリーのオーバーヘッドアカウンティングを無効にすると、メモリー不足 (OOM による強制終了) による仮想マシンプロセスが強制終了の可能性が高くなります。

仮想マシンが OOM で強制終了される可能性は、特定の設定、ノードメモリー、利用可能な swap 領域、仮想マシンのメモリー消費、カーネルの same-page merging (KSM) の使用その他の要因によって変わります。

手順

  1. ゲストメモリーオーバーヘッドアカウンティングを無効にするには、YAML 設定ファイルを編集し、overcommitGuestOverhead の値を true に設定します。このパラメーターはデフォルトで無効にされています。

    kind: VirtualMachine
    spec:
      template:
        domain:
        resources:
            overcommitGuestOverhead: true
            requests:
              memory: 1024M
    注記

    overcommitGuestOverhead が有効にされている場合、これはゲストのオーバーヘッドをメモリー制限 (ある場合) に追加します。

  2. 仮想マシンを作成します。

    $ oc create -f <file_name>.yaml

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

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

7.14.5.1. 前提条件

7.14.5.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 Pages (THP) は、アプリケーションによる認識なしに、Huge Page の管理を自動化しようとしますが、制約があります。特に、ページサイズは 2Mi に制限されます。THP では、THP のデフラグが原因で、メモリー使用率が高くなり、断片化が起こり、パフォーマンスの低下につながり、メモリーページがロックされてしまう可能性があります。このような理由から、アプリケーションは THP ではなく、事前割り当て済みの Huge Page を使用するように設計 (また推奨) される場合があります。

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

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

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

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

注記

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

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

前提条件

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

手順

  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

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

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

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

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

7.14.6.2. 前提条件

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

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

Details タブで仮想マシンの専用リソースを有効にすることができます。Red Hat テンプレートまたはウィザードを使用して作成された仮想マシンは、専用のリソースで有効にできます。

手順

  1. サイドメニューから WorkloadsVirtual Machines をクリックします。
  2. 仮想マシンを選択して、Virtual Machine タブを開きます。
  3. Details タブをクリックします。
  4. Dedicated Resources フィールドの右側にある鉛筆アイコンをクリックして、Dedicated Resources ウィンドウを開きます。
  5. Schedule this workload with dedicated resources (guaranteed policy) を選択します。
  6. Save をクリックします。

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

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

7.14.7.1. ポリシー属性について

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

ポリシー属性説明

force

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

require

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

optional

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

disable

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

forbid

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

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

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

手順

  • 仮想マシン設定ファイルの domain 仕様を編集します。以下の例では、仮想マシンインスタンス (VMI) について CPU 機能および require ポリシーを設定します。

    apiVersion: kubevirt.io/v1alpha3
    kind: VirtualMachine
    metadata:
      name: myvmi
    spec:
      domain:
        cpu:
          features:
          - name: apic 1
            policy: require 2
    1
    仮想マシンまたは仮想マシンインスタンス (VMI) の名前。
    2
    仮想マシンまたは仮想マシンインスタンス (VMI) のポリシー属性。

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

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

手順

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

    apiVersion: kubevirt.io/v1alpha3
    kind: VirtualMachineInstance
    metadata:
      name: myvmi
    spec:
      domain:
        cpu:
          model: Conroe 1
    1
    VMI の CPU モデル。

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

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

手順

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

    apiVersion: kubevirt/v1alpha3
    kind: VirtualMachineInstance
    metadata:
      name: myvmi
    spec:
      domain:
        cpu:
          model: host-model 1
    1
    スケジュールされるノードの CPU モデルを継承する仮想マシンまたは仮想マシンインスタンス (VMI)。