OpenShift Virtualization

OpenShift Container Platform 4.6

OpenShift Virtualization のインストール、使用方法、およびリリースノート

概要

本書では、OpenShift Container Platform で OpenShift Virtualization を使用する方法についての情報を提供します。

第1章 OpenShift Virtualization について

OpenShift Virtualization の機能およびサポート範囲について確認します。

1.1. OpenShift Virtualization の機能

OpenShift virtualization は OpenShift Container Platform のアドオンであり、仮想マシンのワークロードを実行し、このワークロードをコンテナーのワークロードと共に管理することを可能にします。

OpenShift Virtualization は、Kubernetes カスタムリソースにより新規オブジェクトを OpenShift Container Platform クラスターに追加し、仮想化タスクを有効にします。これらのタスクには、以下が含まれます。

  • Linux および Windows 仮想マシンの作成と管理
  • 各種コンソールおよび CLI ツールの使用による仮想マシンへの接続
  • 既存の仮想マシンのインポートおよびクローン作成
  • ネットワークインターフェースコントローラーおよび仮想マシンに割り当てられたストレージディスクの管理
  • 仮想マシンのノード間でのライブマイグレーション

機能強化された Web コンソールは、これらの仮想化されたリソースを OpenShift Container Platform クラスターコンテナーおよびインフラストラクチャーと共に管理するためのグラフィカルポータルを提供します。

OpenShift Virtualization は OpenShift Container Storage (OCS) でテストされ、最適なエクスペリエンスを得るために OCS 機能と共に使用するように設計されています。

OVN-Kubernetes または OpenShiftSDN のデフォルトの Container Network Interface (CNI) ネットワークプロバイダーのいずれかで OpenShift Virtualization を使用できます。

1.1.1. OpenShift Virtualization サポートのクラスターバージョン

OpenShift Virtualization 2.5 は OpenShift Container Platform 4.6 クラスターで使用するためにサポートされます。

第2章 OpenShift Virtualization リリースノート

2.1. Red Hat OpenShift Virtualization について

Red Hat OpenShift Virtualization は、従来の仮想マシン (VM) をコンテナーと共に実行される OpenShift Container Platform に組み込み、それらをネイティブ Kubernetes オブジェクトとして管理することを可能にします。

OpenShift Virtualization は、 OpenShift Virtualization ロゴで表されます。

OVN-Kubernetes または OpenShiftSDN のデフォルトの Container Network Interface (CNI) ネットワークプロバイダーのいずれかで OpenShift Virtualization を使用できます。

OpenShift Virtualization の機能について参照してください。

2.1.1. OpenShift Virtualization サポートのクラスターバージョン

OpenShift Virtualization 2.5 は OpenShift Container Platform 4.6 クラスターで使用するためにサポートされます。

2.1.2. サポート対象のゲストオペレーティングシステム

OpenShift Virtualization ゲストは以下のオペレーティングシステムを使用できます。

  • Red Hat Enterprise Linux 6, 7, and 8。
  • Microsoft Windows Server 2012 R2、2016、および 2019。
  • Microsoft Windows 10。

OpenShift Virtualization に同梱される他のオペレーティングシステムテンプレートはサポートされていません。

2.2. 新機能および変更された機能

  • OpenShift Virtualization は、Windows Server のワークロードを実行する Microsoft の Windows Server Virtualization Validation Program (SVVP) で認定されています。

    SVVP の認定は以下に適用されます。

    • Red Hat Enterprise Linux CoreOS 8 ワーカー。Microsoft SVVP Catalog では、Red Hat OpenShift Container Platform 4 on RHEL CoreOS 8 という名前が付けられます。
    • Intel および AMD CPU。
  • OpenShift Virtualization 2.5 は、QEMU ゲストエージェントデータを管理するために、3 つの新たな virtctl コマンドを追加します。

    • virtctl fslist <vmi_name> は、ゲストマシンで利用可能なファイルシステムの詳細の一覧を返します。
    • virtctl guestosinfo <vmi_name> は、オペレーティングシステムに関するゲストエージェント情報を返します。
    • virtctl userlist <vmi_name> は、ゲストマシンでログインしているユーザーの詳細の一覧を返します。
  • Red Hat Virtualization から Single Root I/O Virtualization (SR-IOV) ネットワークインターフェースを持つ仮想マシンをインポートできるようになりました。

2.2.1. ネットワーク

2.2.2. ストレージ

  • Containerized Data Importer (CDI) は、コンテナーイメージレジストリーからコンテナーディスクストレージボリュームのインポートを迅速に行い、ストレージ容量をより効率的に割り当てられるようになりました。CDI は、HTTP エンドポイントからインポートするのにかかるのとほぼ時間でコンテナーディスクイメージをレジストリーからプルできます。基礎となるストレージをより効率的に使用できるように、サイズがディスクイメージと同等のディスクを Persistent Volume Claim (永続ボリューム要求、PVC) にインポートできます。
  • DataVolume が管理する仮想マシン (VM) ディスクを準備する際に、問題の診断およびトラブルシューティングが容易になりました。

    • 非同期イメージのアップロードの場合、ディスクイメージの仮想サイズがターゲット DataVolume のサイズよりも大きい場合、接続を閉じる前にエラーメッセージが返されます。
    • oc describe dv コマンドを使用して、PersistentVolumeClaim (PVC) Bound 状態の変更または転送の失敗をモニターできます。Status:Phase フィールドの値が Succeeded の場合、DataVolume を使用することができます。
  • 電源がオフ (オフライン) の仮想マシン (VM) のスナップショットを CLI で作成し、復元し、削除することができます。OpenShift Virtualization は、以下でオフライン仮想マシンのスナップショットをサポートします。

    • Red Hat OpenShift Container Storage
    • Kubernetes Volume Snapshot API をサポートする Container Storage Interface (CSI) ドライバーを使用するその他のストレージプロバイダー

2.2.3. Web コンソール

  • 仮想マシンが実行されている場合、Web コンソールの以下のフィールドおよびタブに加えた変更は仮想マシンを再起動するまで反映されません。

    • Details タブのBoot OrderFlavor
    • Network Interfaces タブ
    • Disks タブ
    • Environment タブ

      ページ上部の Pending Changes バナーには、仮想マシンの再起動時に適用されるすべての変更の一覧が表示されます。

  • デフォルトの OS イメージを作成し、OpenShift Container Platform Web コンソールを使用してそれらを自動的にアップロードできるようになりました。デフォルトの OS イメージ は、オペレーティングシステムと、ドライバーなどのオペレーティングシステムのすべての設定を含む起動可能なディスクです。デフォルトの OS イメージを使用して、特定の設定で起動可能な仮想マシンを作成します。

2.3. 主な技術上の変更点

  • OpenShift Virtualization をインストール、またはアップグレードする場合、Update Channel を選択します。stable という名前の新しい Update Channel オプションがあります。stable チャネルを使用することで、OpenShift Container Platform バージョンと互換性のある OpenShift Virtualization のバージョンをインストールするか、またはこれにアップグレードすることができます。
  • ブロックベースのストレージを持つ仮想マシンを OpenShift Virtualization にインポートできるようになりました。
  • HyperConverged Operator (HCO)、Containerized Data Importer (CDI)、Hostpath Provisioner (HPP)、および仮想マシンインポートのカスタムリソースは API バージョン v1beta1 に移行しました。これらのコンポーネントのそれぞれの API バージョンは以下のようになります。

    hCO.kubevirt.io/v1beta1
    cdi.kubevirt.io/v1beta1
    hostpathprovisioner.kubevirt.io/v1beta1
    v2v.kubevirt.io/v1beta1

  • デフォルトの cloud-init ユーザーパスワードは、テンプレートで作成される仮想マシンについて自動生成されるようになりました。
  • ホスト支援型クローン作成を使用する場合には、より効率的な圧縮アルゴリズムにより、より高速に仮想マシンディスクのクローンを作成できるようになりました。
  • ベアメタルデプロイメントでの OpenShift Container Platform のユーザーによってプロビジョニングされたインストールでノードが失敗すると、仮想マシンは別のノードで自動的に再起動されません。自動再起動は、マシンヘルスチェックが有効にされているインストーラーでプロビジョニングされるインストールでのみサポートされます。OpenShift Virtualization のクラスターの設定 の詳細を参照してください。

2.4. 既知の問題

  • OpenShift Container Platform クラスターが OVN-Kubernetes をデフォルトの Container Network Interface (CNI) プロバイダーとして使用する場合、OVN-Kubernetes のホストネットワークトポロジーの変更により、Linux ブリッジまたはボンディングをホストのデフォルトインターフェースに割り当てることはできません。回避策として、ホストに接続されたセカンダリーネットワークインターフェースを使用するか、OpenShift SDN デフォルト CNI プロバイダーに切り替えることができます。(BZ#1887456)
  • Web コンソールを使用して VMware Virtual Disk Development Kit (VDDK) イメージopenshift-cnv/v2v-vmware 設定マップに追加すると、Managed リソース のエラーメッセージが表示されます。このエラーは無視しても問題ありません。Save をクリックして設定マップを保存します。(BZ#1884538)
  • たとえば、ノードが OpenShift Container Platform クラスターのアップグレード時にメンテナンスモードにされている場合にそれらのノードがエビクトされると、仮想マシンは 1 回ではなく 2 回移行されます。(BZ#1888790)
  • アップグレード後は、オペレーティングシステムのワークロードごとに複数のテンプレートが存在する可能性があります。デフォルトのオペレーティングシステム (OS) イメージ機能を使用してクローン作成された PVC から Microsoft Windows 仮想マシンを作成する場合、OS には正しいワークロード値が定義される必要があります。Web コンソールに (Source available) ラベルが表示されていても、誤った ワークロード 値を選択すると、デフォルトの OS イメージを使用できません。デフォルトの OS イメージは新しいテンプレートに割り当てられますが、ウィザードは、デフォルトの OS イメージをサポートするように設定されていない古いテンプレートを使用する場合があります。Windows 2010 システムは Desktop のワークロード値のみをサポートしますが、Windows 2012、Windows 2016、および Windows 2019 は Server のワークロード値のみをサポートします。(BZ#1907183)
  • KubeMacPool ラベルを適用し、その namespace の仮想マシンの io 属性を使用して namespace の MAC アドレスプールを有効にする場合、仮想マシンに対して io 属性設定は保持されません。回避策として、仮想マシンに io 属性を使用しないでください。または、namespace に対して KubeMacPool を無効にすることができます。(BZ#1869527)
  • OpenShift Virtualization 2.5 にアップグレードする場合には、オペレーティングシステム、ワークロード、およびフレーバーの組み合わせごとに、古いバージョンと新しいバージョンの共通テンプレートが利用できます。共通のテンプレートを使用して仮想マシンを作成する場合、新しいバージョンのテンプレートを使用する必要があります。問題を回避するために、古いバージョンを無視します。(BZ#1859235)
  • ライブマイグレーションを実行できない仮想マシンを実行すると、OpenShift Container Platform クラスターのアップグレードがブロックされる可能性があります。これには、hostpath-provisioner ストレージまたは SR-IOV ネットワークインターフェースを使用する仮想マシンが含まれます。(BZ#1858777)

    回避策として、仮想マシンを再設定し、クラスターのアップグレード時にそれらの電源をオフにするようにできます。仮想マシン設定ファイルの spec セクションで、以下を実行します。

    1. evictionStrategy: LiveMigrate フィールドを削除します。エビクションストラテジーの設定方法についての詳細は、「仮想マシンのエビクションストラテジーの設定」を参照してください。
    2. runStrategy フィールドを Always に設定します。
  • 不明な理由により、containerDisk ボリュームタイプのメモリー消費量が、メモリー制限を超えるまで徐々に増加する可能性があります。この問題を解決するには、仮想マシンを再起動します。(BZ#1855067)
  • Web コンソールで OpenShift Virtualization Operator のサブスクリプションチャネルを編集しようとする際に、Subscription OverviewChannel ボタンをクリックすると JavaScript エラーが発生することがあります。(BZ#1796410)

    • 回避策として、以下の oc patch コマンドを実行して、CLI から OpenShift Virtualization 2.5 へのアップグレードプロセスをトリガーします。

      $ export TARGET_NAMESPACE=openshift-cnv CNV_CHANNEL=2.5 && oc patch -n "${TARGET_NAMESPACE}" $(oc get subscription -n ${TARGET_NAMESPACE} --no-headers -o name) --type='json' -p='[{"op": "replace", "path": "/spec/channel", "value":"'${CNV_CHANNEL}'"}, {"op": "replace", "path": "/spec/installPlanApproval", "value":"Automatic"}]'

      このコマンドは、アップグレードチャネル 2.5 にサブスクリプションをポイントし、自動更新を有効にします。

  • ノードの CPU モデルが異なると、ライブマイグレーションに失敗します。ノードに同じ物理 CPU モデルがある場合でも、マイクロコードの更新によって導入される違いにより同じ状況が生じます。これは、デフォルト設定が、ライブマイグレーションと互換性のないホスト CPU パススルー動作をトリガーするためです。(BZ#1760028)

    • 回避策として、以下の例のように kubevirt-config ConfigMap にデフォルトの CPU モデルを設定します。

      注記

      ライブマイグレーションをサポートする仮想マシンを起動する前に、この変更を行う必要があります。

      1. 以下のコマンドを実行して、編集するために kubevirt-config ConfigMap を開きます。

        $ oc edit configmap kubevirt-config -n openshift-cnv
      2. ConfigMap を編集します。

        kind: ConfigMap
        metadata:
          name: kubevirt-config
        data:
          default-cpu-model: "<cpu-model>" 1
        1
        <cpu-model> を実際の CPU モデルの値に置き換えます。すべてのノードに oc describe node <node> を実行し、cpu-model-<name> ラベルを確認してこの値を判別できます。すべてのノードに存在する CPU モデルを選択します。
  • OpenShift Virtualization は、oc adm drain または kubectl drain のいずれかを実行してトリガーされるノードのドレイン (解放) を確実に特定することができません。これらのコマンドは、OpenShift Virtualization がデプロイされているクラスターのノードでは実行しないでください。ノードは、それらの上部で実行されている仮想マシンがある場合にドレイン (解放) を実行しない可能性があります。

  • OpenShift Virtualization ストレージ PV が RHV 仮想マシンのインポートに適切でない場合、進捗バーは 10% のままとなり、インポートは完了しません。VM Import Controller Pod ログには、以下のエラーメッセージが表示されます。Failed to bind volumes: provisioning failed for PVC(BZ#1857784)
  • RHV 仮想マシンのインポート時に RHV Manager の誤った認証情報を入力すると、vm-import-operator が RHV API への接続を繰り返し試行するため、Manager は admin ユーザーアカウントをロックする可能性があります。(BZ#1887140)

    アカウントのロックを解除するには、Manager にログインし、以下のコマンドを入力します。

    $ ovirt-aaa-jdbc-tool user unlock admin

第3章 OpenShift Virtualization のインストール

3.1. OpenShift Virtualization のクラスターの設定

OpenShift Virtualization をインストールする前に、OpenShift Container Platform クラスターが以下の要件を満たしていることを確認してください。

注記

インストーラーでプロビジョニングされるインフラストラクチャーを使用してインストールされ、MachineHealthCheck が適切に設定された OpenShift Virtualization クラスターで、ノードで MachineHealthCheck が失敗し、クラスターで利用できなくなると、そのノードは再利用されます。障害が発生したノードで実行された仮想マシンでは、一連の条件によって次に起こる動作が変わります。予想される結果や RunStrategies がそれらの結果に与える影響についての詳細は、「About RunStrategies for virtual machines」を参照してください。

  • ライブマイグレーションを有効にするには、共有ストレージが必要です。
  • コンピュートノードを、クラスター内でホストする仮想マシンの数およびサイズに応じて管理する必要があります。
  • OpenShift Virtualization を非接続環境でデプロイするには、Operator Lifecycle Manager をネットワークが制限された環境で設定する必要があります。
  • OpenShift Virtualization でプロキシーを使用するには、Operator Lifecycle Manager でプロキシーサポートを設定する必要があります。
  • クラスターで複数の CPU ベンダーのワーカーノードを使用する場合、ライブマイグレーションが失敗する可能性があります。たとえば、AMD CPU を持つ仮想マシンは、Intel CPU を持つノードにライブマイグレーションを試み、移行に失敗する可能性があります。これを回避するには、ノードに Vendor=Intel または Vendor=AMD などのベンダー固有のラベルを付け、仮想マシンでノードのアフィニティーを設定し、移行が正常に実行されるようにします。詳細は、ノードアフィニティーの required (必須) ルールの設定について参照してください。

OpenShift Virtualization はデフォルトで OpenShift Container Platform と連携しますが、以下のインストール設定が推奨されます。

注記

OpenShift Container Platform の評価版バージョンを取得するには、OpenShift Container Platform ホームページから評価版をダウンロードしてください。

3.2. Web コンソールを使用した OpenShift Virtualization のインストール

OpenShift Virtualization をインストールし、仮想化機能を OpenShift Container Platform クラスターに追加します。

OpenShift Container Platform 4.6 Web コンソールを使用して、OpenShift Virtualization Operator にサブスクライブし、これをデプロイすることができます。

3.2.1. 前提条件

  • OpenShift Container Platform 4.6 をクラスターにインストールします。
  • cluster-admin パーミッションを持つユーザーとしてログインします。

3.2.2. OpenShift Virtualization カタログのサブスクライブ

OpenShift Virtualization をインストールする前に、OpenShift Container Platform Web コンソールから OpenShift Virtualization カタログにサブスクライブします。サブスクライブにより、openshift-cnv namespace に OpenShift Virtualization Operator へのアクセスが付与されます。

手順

  1. ブラウザーウィンドウを開き、OpenShift Container Platform Web コンソールにログインします。
  2. OperatorsOperatorHub ページに移動します。
  3. OpenShift Virtualization を検索し、これを選択します。
  4. Operator についての情報を確認してから、Install をクリックします。
  5. Install Operator ページで以下を行います。

    1. インストールされた namespace の場合、Operator recommended namespace オプションが選択されていることを確認します。これにより、Operator が必須の openshift-cnv namespace にインストールされます。この namespace は存在しない場合は、自動的に作成されます。

      警告

      OpenShift Virtualization Operator を openshift-cnv 以外の namespace にインストールしようとすると、インストールが失敗します。

    2. 選択可能な Update Channel オプションの一覧から stable を選択します。これにより、OpenShift Container Platform バージョンと互換性がある OpenShift Virtualization のバージョンをインストールすることができます。
    3. Approval Strategy の場合、デフォルト値である Automatic が選択されていることを確認します。OpenShift Virtualization は、z-stream の新規リリースが利用可能になると自動的に更新されます。
  6. Install をクリックし、Operator を openshift-cnv namespace で利用可能にします。

    Installed Operators 画面では、OpenShift Virtualization がインストールを終了すると、StatusSucceeded が表示されます。

3.2.3. OpenShift Virtualization のデプロイ

OpenShift Virtualization カタログにサブスクライブした後に、OpenShift Virtualization Operator Deployment カスタムリソースを作成し、OpenShift Virtualization をデプロイします。

前提条件

  • openshift-cnv namespace の OpenShift Virtualization カタログへのサブスクリプション。

手順

  1. OperatorsInstalled Operators ページに移動します。
  2. OpenShift Virtualization をクリックします。
  3. OpenShift Virtualization Operator Deployment タブをクリックし、Create HyperConverged Cluster をクリックします。

    警告

    デプロイメントのエラーを回避するには、カスタムリソースの名前を変更しないでください。次のステップに進む前に、カスタムリソースの名前がデフォルトの kubevirt-hyperconverged であることを確認します。

  4. Create をクリックして OpenShift Virtualization を起動します。
  5. WorkloadsPods ページに移動して、OpenShift Virtualization Pod がすべて Running 状態になるまでこれらの Pod をモニターします。すべての Pod で Running 状態が表示された後に、OpenShift Virtualization にアクセスできます。

3.2.4. 次のステップ

以下のコンポーネントを追加で設定する必要がある場合があります。

  • KubeMacPool コンポーネントは、指定の namespace に仮想マシン NIC の MAC アドレスプールサービスを提供します。KubeMacPool ラベルを namespace に適用して、その namespace で MAC アドレスプールを有効にします
  • ホストパスプロビジョナーは、OpenShift Virtualization 用に設計されたローカルストレージプロビジョナーです。仮想マシンのローカルストレージを設定する必要がある場合、まずホストパスプロビジョナーを有効にする必要があります。

3.3. CLI を使用した OpenShift Virtualization のインストール

OpenShift Virtualization をインストールし、仮想化機能を OpenShift Container Platform クラスターに追加します。コマンドラインを使用してマニフェストをクラスターに適用し、OpenShift Virtualization Operator にサブスクライブし、デプロイできます。

3.3.1. 前提条件

  • OpenShift Container Platform 4.6 をクラスターにインストールします。
  • OpenShift CLI (oc) をインストールします。
  • cluster-admin 権限を持つユーザーとしてログインすること。

3.3.2. CLI を使用した OpenShift Virtualization カタログのサブスクライブ

OpenShift Virtualization をインストールする前に、OpenShift Virtualization カタログにサブスクライブする必要があります。サブスクライブにより、openshift-cnv namespace に OpenShift Virtualization Operator へのアクセスが付与されます。

単一マニフェストをクラスターに適用して NamespaceOperatorGroup、および Subscription オブジェクトをサブスクライブし、設定します。

手順

  1. 以下のマニフェストを含む YAML ファイルを作成します。

    apiVersion: v1
    kind: Namespace
    metadata:
      name: openshift-cnv
    ---
    apiVersion: operators.coreos.com/v1
    kind: OperatorGroup
    metadata:
      name: kubevirt-hyperconverged-group
      namespace: openshift-cnv
    spec:
      targetNamespaces:
        - openshift-cnv
    ---
    apiVersion: operators.coreos.com/v1alpha1
    kind: Subscription
    metadata:
      name: hco-operatorhub
      namespace: openshift-cnv
    spec:
      source: redhat-operators
      sourceNamespace: openshift-marketplace
      name: kubevirt-hyperconverged
      startingCSV: kubevirt-hyperconverged-operator.v2.5.6
      channel: "stable" 1
    1
    stable チャネルを使用することで、OpenShift Container Platform バージョンと互換性のある OpenShift Virtualization のバージョンをインストールすることができます。
  2. 以下のコマンドを実行して、OpenShift Virtualization に必要な NamespaceOperatorGroup、および Subscription オブジェクトを作成します。

    $ oc apply -f <file name>.yaml

3.3.3. CLI を使用した OpenShift Virtualization Operator のデプロイ

oc CLI を使用して OpenShift Virtualization Operator をデプロイすることができます。

前提条件

  • openshift-cnv namespace の OpenShift Virtualization カタログへのアクティブなサブスクリプション。

手順

  1. 以下のマニフェストを含む YAML ファイルを作成します。

    apiVersion: hco.kubevirt.io/v1beta1
    kind: HyperConverged
    metadata:
      name: kubevirt-hyperconverged
      namespace: openshift-cnv
    spec:
      BareMetalPlatform: true
  2. 以下のコマンドを実行して OpenShift Virtualization Operator をデプロイします。

    $ oc apply -f <file name>.yaml

検証

  • openshift-cnv namespace の Cluster Service Version (CSV)の PHASE を監視して、OpenShift Virtualization が正常にデプロイされたことを確認します。以下のコマンドを実行します。

    $ watch oc get csv -n openshift-cnv

    以下の出力は、デプロイメントに成功したかどうかを表示します。

    出力例

    NAME                                      DISPLAY                    VERSION   REPLACES   PHASE
    kubevirt-hyperconverged-operator.v2.5.6   OpenShift Virtualization   2.5.6                Succeeded

3.3.4. 次のステップ

以下のコンポーネントを追加で設定する必要がある場合があります。

  • KubeMacPool コンポーネントは、指定の namespace に仮想マシン NIC の MAC アドレスプールサービスを提供します。KubeMacPool ラベルを namespace に適用して、その namespace で MAC アドレスプールを有効にします
  • ホストパスプロビジョナーは、OpenShift Virtualization 用に設計されたローカルストレージプロビジョナーです。仮想マシンのローカルストレージを設定する必要がある場合、まずホストパスプロビジョナーを有効にする必要があります。

3.4. virtctl クライアントのインストール

virtctl クライアントは、OpenShift Virtualization リソースを管理するためのコマンドラインユーティリティーです。これは、Linux、macOS、および Windows ディストリビューションで利用できます。

virtctl クライアントのインストールは、 OpenShift Virtualization Web コンソールからか、または OpenShift Virtualization リポジトリーを有効にし、 kubevirt-virtctl パッケージをインストールして実行できます。

3.4.1. Web コンソールからの virtctl クライアントのインストール

Red Hat カスタマーポータルから virtctl クライアントをダウンロードできます。これは、「Command Line Tools」ページの OpenShift Virtualization Web コンソールでリンクされています。

前提条件

  • カスタマーポータルのダウンロードページにアクセスするには、有効な OpenShift Container Platform サブスクリプションが必要である。

手順

  1. Web コンソールの右上隅にある question circle アイコンをクリックして、カスタマーポータルにアクセスし、Command Line Tools を選択します。
  2. Version: 一覧からクラスターの適切なバージョンが選択されていることを確認します。
  3. 使用するディストリビューション用に virtctl クライアントをダウンロードします。すべてのダウンロードの形式は tar.gz です。
  4. tarball を展開します。以下の CLI コマンドは、これを tarball と同じディレクトリーに展開します。これはすべてのディストリビューションに適用できます。

    $ tar -xvf <virtctl-version-distribution.arch>.tar.gz
  5. Linux および macOS の場合:

    1. 展開したフォルダー階層に移動し、virtctl バイナリーを実行可能にします。

      $ chmod +x <virtctl-file-name>
    2. virtctl バイナリーをパスにあるディレクトリーに移動します。

      1. PATH を確認するには、以下を実行します。

        $ echo $PATH
  6. Windows ユーザーの場合:

    1. 展開したフォルダー階層に移動し、virtctl 実行可能ファイルをダブルクリックしてクライアントをインストールします。

3.4.2. OpenShift Virtualization リポジトリーの有効化

Red Hat は、Red Hat Enterprise Linux 8 および Red Hat Enterprise Linux 7 向けの OpenShift Virtualization リポジトリーを提供します。

  • Red Hat Enterprise Linux 8 リポジトリー: cnv-2.5-for-rhel-8-x86_64-rpms
  • Red Hat Enterprise Linux 7 リポジトリー: rhel-7-server-cnv-2.5-rpms

subscription-manager でリポジトリーを有効にするプロセスはどちらのプラットフォームでも同様です。

手順

  • 以下のコマンドを実行して、お使いのシステムに適した OpenShift Virtualization リポジトリーを有効にします。

    # subscription-manager repos --enable <repository>

3.4.3. virtctl クライアントのインストール

kubevirt-virtctl パッケージから virtctl クライアントをインストールします。

手順

  • kubevirt-virtctl パッケージをインストールします。

    # yum install kubevirt-virtctl

3.4.4. 追加リソース

OpenShift Virtualization の「Using the CLI tools

3.5. Web コンソールを使用した OpenShift Virtualization のアンインストール

OpenShift Container Platform Web コンソールを使用して OpenShift Virtualization をアンインストールできます。

3.5.1. 前提条件

3.5.2. OpenShift Virtualization Operator Deployment カスタムリソースの削除

OpenShift Virtualization をアンインストールするには、まず OpenShift Virtualization Operator Deployment カスタムリソースを削除する必要がある。

前提条件

  • OpenShift Virtualization Operator Deployment カスタムリソースを作成すること。

手順

  1. OpenShift Container Platform Web コンソールから、Projects 一覧より openshift-cnv を選択します。
  2. OperatorsInstalled Operators ページに移動します。
  3. OpenShift Virtualization をクリックします。
  4. OpenShift Virtualization Operator Deployment タブをクリックします。
  5. Options メニュー kebabkubevirt-hyperconverged カスタムリソースを含む行でクリックします。拡張されたメニューで、Delete HyperConverged Cluster をクリックします。
  6. 確認ウィンドウで Delete をクリックします。
  7. WorkloadsPods ページに移動し、Operator Pod のみが実行中であることを確認します。
  8. ターミナルウィンドウを開き、以下のコマンドを実行して残りのリソースをクリーンアップします。

    $ oc delete apiservices v1alpha3.subresources.kubevirt.io -n openshift-cnv

3.5.3. OpenShift Virtualization カタログサブスクリプションの削除

OpenShift Virtualization のアンインストールを終了するには、OpenShift Virtualization カタログサブスクリプションを削除します。

前提条件

  • OpenShift Virtualization カタログの有効なサブスクリプション。

手順

  1. OperatorsOperatorHub ページに移動します。
  2. OpenShift Virtualization を検索し、これを選択します。
  3. Uninstall をクリックします。
注記

openshift-cnv namespace を削除できるようになりました。

3.5.4. Web コンソールを使用した namespace の削除

OpenShift Container Platform Web コンソールを使用して namespace を削除できます。

注記

namespace を削除するパーミッションがない場合、Delete Namespace オプションは選択できなくなります。

手順

  1. AdministrationNamespaces に移動します。
  2. namespace の一覧で削除する必要のある namespace を見つけます。
  3. namespace の一覧の右端で、Options メニュー kebab から Delete Namespace を選択します。
  4. Delete Namespace ペインが表示されたら、フィールドから削除する namespace の名前を入力します。
  5. Delete をクリックします。

3.6. CLI を使用した OpenShift Virtualization のアンインストール

OpenShift Container Platform CLI を使用して OpenShift Virtualization をアンインストールできます。

3.6.1. 前提条件

3.6.2. OpenShift Virtualization の削除

CLI を使用して OpenShift Virtualization を削除できます。

前提条件

  • OpenShift CLI (oc) をインストールすること。
  • cluster-admin パーミッションを持つアカウントを使用して OpenShift Virtualization クラスターにアクセスできること。
注記

CLI を使用して OLM で OpenShift Virtualization Operator のサブスクリプションを削除すると、ClusterServiceVersion (CSV) オブジェクトはクラスターから削除されません。OpenShift Virtualization を完全にアンインストールするには、CSV を明示的に削除する必要があります。

手順

  1. HyperConverged カスタムリソースを削除します。

    $ oc delete HyperConverged kubevirt-hyperconverged -n openshift-cnv
  2. Operator Lifecycle Manager (OLM) で OpenShift Virtualization Operator のサブスクリプションを削除します。

    $ oc delete subscription kubevirt-hyperconverged -n openshift-cnv
  3. OpenShift Virtualization の Cluster Service Version (CSV) 名を環境変数として設定します。

    $ CSV_NAME=$(oc get csv -n openshift-cnv -o=custom-columns=:metadata.name)
  4. 直前の手順で CSV 名を指定して、OpenShift Virtualization クラスターから CSV を削除します。

    $ oc delete csv ${CSV_NAME} -n openshift-cnv

    OpenShift Virtualization は、CSV が正常に削除されたことを示す確認メッセージが表示される際にアンインストールされます。

    出力例

    clusterserviceversion.operators.coreos.com "kubevirt-hyperconverged-operator.v2.5.6" deleted

第4章 OpenShift Virtualization のアップグレード

次のマイナーバージョンの OpenShift Virtualization に手動でアップグレードし、Web コンソールを使用して更新のステータスをモニターできます。

4.1. OpenShift Virtualization のアップグレードについて

4.1.1. OpenShift Virtualization のアップグレードの仕組み

  • OpenShift Container Platform Web コンソールを使用して Operator サブスクリプションのチャネルを変更することで、OpenShift Virtualization の次のマイナーバージョンにアップグレードできます。
  • OpenShift Virtualization のインストール時に z-stream の自動更新を有効にできます。
  • 更新は、OpenShift Container Platform のインストール時にデプロイされる Marketplace Operator 経由で送信されます。Marketplace Operator は外部 Operator をクラスターに対して利用可能にします。
  • 更新の完了までにかかる時間は、ネットワーク接続によって異なります。ほとんどの自動更新は 15 分以内に完了します。

4.1.2. OpenShift Virtualization アップグレードのクラスターへの影響

  • アップグレードを実行しても仮想マシンのワークロードは中断しません。

    • 仮想マシン Pod は、アップグレード時に再起動したり、移行したりしません。virt-launcher Pod を更新する必要がある場合は、仮想マシンの再起動またはライブマイグレーションが必要になります。

      注記

      各仮想マシンには、仮想マシンインスタンスを実行する virt-launcher Pod があります。virt-launcher Pod は、仮想マシンのプロセスを管理するために使用される libvirt のインスタンスを実行します。

  • アップグレードによってネットワーク接続が中断されることはありません。
  • データボリュームおよびその関連付けられた永続ボリューム要求 (PVC) はアップグレード時に保持されます。

    重要

    ライブマイグレーションを実行できない仮想マシンを実行すると、OpenShift Container Platform クラスターのアップグレードがブロックされる可能性があります。これには、hostpath-provisioner ストレージまたは SR-IOV ネットワークインターフェースを使用する仮想マシンが含まれます。

    回避策として、仮想マシンを再設定し、クラスターのアップグレード時にそれらの電源を自動的にオフになるようにできます。evictionStrategy: LiveMigrate フィールドを削除し、runStrategy フィールドを Always に設定します。

4.2. マイナーリリースのアップグレードパス

アップグレードパスは、インストールしている OpenShift Virtualization の 2.4.z バージョンによって異なります。

重要

OpenShift Virtualization のマイナーリリースをアップグレードする前に、OpenShift Container Platform を 4.6 にアップグレードする必要があります。

4.2.1. 2.4.3 から 2.5.6 へのアップグレード

z-stream をアップグレードするには、まず 2.5.0 にアップグレードする必要があります。次に、2.5.0 から 2.5.1 へ、次に 2.5.2 などにアップグレードできます。

Approval Strategy がデフォルトの Automatic の場合、OpenShift Virtualization は 2.5.0 にアップグレードした後に z-stream を自動的にアップグレードします。

4.2.2. 2.4.4 または 2.4.5 から 2.5.6 へのアップグレード

2.4.4 または 2.4.5 から 2.5.2 に直接アップグレードできます。次に、2.5.2 から 2.5.3 などにアップグレードできます。

Approval Strategy がデフォルトの Automatic の場合、OpenShift Virtualization は 2.5.2 にアップグレードした後に z-stream を自動的にアップグレードします。

4.3. OpenShift Virtualization の次のマイナーバージョンへのアップグレード

OpenShift Container Platform Web コンソールを使用して Operator サブスクリプションのチャネルを変更することで、OpenShift Virtualization を次のマイナーバージョンに手動でアップグレードできます。

前提条件

  • cluster-admin ロールを持つユーザーとしてクラスターにログインすること。

手順

  1. OpenShift Container Platform Web コンソールにアクセスし、OperatorsInstalled Operators に移動します。
  2. OpenShift Virtualization をクリックし、Operator Details ページを開きます。
  3. Subscription タブをクリックし、Subscription Overview ページを開きます。
  4. Channel ペインで、バージョン番号の右側にある鉛筆アイコンをクリックし、Change Subscription Update Channel ウィンドウを開きます。
  5. stable を選択します。これにより、OpenShift Container Platform バージョンと互換性がある OpenShift Virtualization のバージョンをインストールすることができます。
  6. Save をクリックします。
  7. OperatorsInstalled Operators に移動してアップグレードのステータスを確認します。以下の oc コマンドを実行してステータスを確認することもできます。

    $ oc get csv -n openshift-cnv

4.4. アップグレードステータスの監視

OpenShift Virtualization アップグレードステータスをモニターする最適な方法として、Cluster Service Version (CSV) PHASE を監視できます。Web コンソールを使用するか、ここに提供されているコマンドを実行して CSV の状態をモニターすることもできます。

注記

PHASE および状態の値は利用可能な情報に基づく近似値になります。

前提条件

  • cluster-admin ロールを持つユーザーとしてクラスターにログインすること。
  • OpenShift CLI (oc) をインストールすること。

手順

  1. 以下のコマンドを実行します。

    $ oc get csv
  2. 出力を確認し、PHASE フィールドをチェックします。以下は例になります。

    出力例

    VERSION  REPLACES                                        PHASE
    2.5.0    kubevirt-hyperconverged-operator.v2.4.3         Installing
    2.4.3                                                    Replacing

  3. オプション: 以下のコマンドを実行して、すべての OpenShift Virtualization コンポーネントの状態の集約されたステータスをモニターします。

    $ oc get hco -n openshift-cnv kubevirt-hyperconverged \
    -o=jsonpath='{range .status.conditions[*]}{.type}{"\t"}{.status}{"\t"}{.message}{"\n"}{end}'

    アップグレードが成功すると、以下の出力が得られます。

    出力例

    ReconcileComplete  True  Reconcile completed successfully
    Available          True  Reconcile completed successfully
    Progressing        False Reconcile completed successfully
    Degraded           False Reconcile completed successfully
    Upgradeable        True  Reconcile completed successfully

4.5. 追加リソース

第5章 kubevirt-controller および virt-launcher に付与される追加のセキュリティー権限

kubevirt-controller および virt-launcher Pod には、通常の Pod 所有者の権限に加えて一部の SELinux ポリシーおよび SCC (Security Context Constraints) 権限が付与されます。これらの権限により、仮想マシンは OpenShift Virtualization 機能を使用できます。

5.1. virt-launcher Pod の拡張 SELinux ポリシー

virt-launcher Pod の container_t SELinux ポリシーは以下のルールで拡張されます。

  • allow process self (tun_socket (relabelfrom relabelto attach_queue))
  • allow process sysfs_t (file (write))
  • allow process hugetlbfs_t (dir (add_name create write remove_name rmdir setattr))
  • allow process hugetlbfs_t (file (create unlink))

これらのルールは、以下の仮想化機能を有効にします。

  • キューを独自の TUN ソケットに再度ラベル付けし、これに割り当てます。これは、ネットワークのマルチキューをサポートするために必要です。マルチキューは、利用可能な vCPU の数が増える際にネットワークのパフォーマンスをスケーリングできます。
  • virt-launcher Pod が情報を sysfs (/sys) ファイルに書き込むことを許可します。これは SR-IOV (Single Root I/O Virtualization) を有効にするために必要です。
  • hugetlbfs エントリーの読み取り/書き込みを実行します。これは、Huge Page をサポートするために必要です。Huge Page は、メモリーページサイズを増やすことで大量のメモリーを管理する方法です。

5.2. kubevirt-controller サービスアカウントの追加の OpenShift Container Platform SCC (Security Context Constraints) および Linux 機能

SCC (Security Context Constraints) は Pod のパーミッションを制御します。これらのパーミッションには、コンテナーのコレクションである Pod が実行できるアクションおよびそれがアクセスできるリソース情報が含まれます。SCC を使用して、Pod がシステムに受け入れられるために必要な Pod の実行についての条件の一覧を定義することができます。

kubevirt-controller は、クラスター内の仮想マシンの virt-launcher Pod を作成するクラスターコントローラーです。これらの virt-launcher Pod には、kubevirt-controller サービスアカウントによってパーミッションが付与されます。

5.2.1. kubevirt-controller サービスアカウントに付与される追加の SCC

kubevirt-controller サービスアカウントには追加の SCC および Linux 機能が付与され、これにより適切なパーミッションを持つ virt-launcher Pod を作成できます。これらの拡張パーミッションにより、仮想マシンは通常の Pod の範囲外の OpenShift Virtualization 機能を利用できます。

kubevirt-controller サービスアカウントには以下の SCC が付与されます。

  • scc.AllowHostDirVolumePlugin = true
    これは、仮想マシンが hostpath ボリュームプラグインを使用することを可能にします。
  • scc.AllowPrivilegedContainer = false
    これは、virt-launcher Pod が権限付きコンテナーとして実行されないようにします。
  • scc.AllowedCapabilities = []corev1.Capability{"NET_ADMIN", "NET_RAW", "SYS_NICE"}
    This provides the following additional Linux capabilities NET_ADMIN, NET_RAW, and SYS_NICE.

5.2.2. kubevirt-controller の SCC および RBAC 定義の表示

oc ツールを使用して kubevirt-controllerSecurityContextConstraints 定義を表示できます。

$ oc get scc kubevirt-controller -o yaml

oc ツールを使用して kubevirt-controller クラスターロールの RBAC 定義を表示できます。

$ oc get clusterrole kubevirt-controller -o yaml

5.3. 追加リソース

  • 『Red Hat Enterprise Linux 仮想化のチューニングと最適化ガイド』には、ネットワークマルチキューHuge Page についての詳細情報が記載されています。
  • capabilities man ページには、Linux 機能についての詳細情報が記載されています。
  • sysfs(5) man ページには、sysfs についての詳細情報が記載されています。
  • 『OpenShift Container Platform 認証』ガイドには、SCC (Security Context Constraints) についての詳細が記載されています。

第6章 CLI ツールの使用

クラスターでリソースを管理するために使用される 2 つの主な CLI ツールは以下の通りです。

  • OpenShift virtualization virtctl クライアント
  • OpenShift Container Platform oc クライアント

6.1. 前提条件

6.2. Virtctl クライアントコマンド

virtctl クライアントは、OpenShift Virtualization リソースを管理するためのコマンドラインユーティリティーです。以下の表には、OpenShift Virtualization のドキュメント全体で使用されている virtctl コマンドが記載されています。

コマンドで使用できるオプションの一覧を表示するには、これを -h または --help フラグを指定して実行します。以下は例になります。

$ virtctl image-upload -h

表6.1 virtctl クライアントコマンド

Command説明

virtctl start <vm_name>

仮想マシンを起動します。

virtctl stop <vm_name>

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

virtctl pause vm|vmi <object_name>

仮想マシンまたは仮想マシンインスタンスを一時停止します。マシンの状態がメモリーに保持されます。

virtctl unpause vm|vmi <object_name>

仮想マシンまたは仮想マシンインスタンスの一時停止を解除します。

virtctl migrate <vm_name>

仮想マシンを移行します。

virtctl restart <vm_name>

仮想マシンを再起動します。

virtctl expose <vm_name>

仮想マシンまたは仮想マシンインスタンスの指定されたポートを転送するサービスを作成し、このサービスをノードの指定されたポートで公開します。

virtctl console <vmi_name>

仮想マシンインスタンスのシリアルコンソールに接続します。

virtctl vnc <vmi_name>

仮想マシンインスタンスへの VNC 接続を開きます。

virtctl image-upload dv <datavolume_name> --image-path=</path/to/image> --no-create

仮想マシンイメージをすでに存在するデータボリュームにアップロードします。

virtctl image-upload dv <datavolume_name> --size=<datavolume_size> --image-path=</path/to/image>

仮想マシンイメージを新規データボリューム にアップロードします。

virtctl version

クライアントおよびサーバーのバージョン情報を表示します。

virtctl help

virtctl コマンドの説明的な一覧を表示します。

virtctl fslist <vmi_name>

ゲストマシンで利用可能なファイルシステムの詳細な一覧を返します。

virtctl guestosinfo <vmi_name>

オペレーティングシステムに関するゲストエージェント情報を返します。

virtctl userlist <vmi_name>

ゲストマシンでログインしているユーザーの詳細な一覧を返します。

6.3. OpenShift Container Platform クライアントコマンド

OpenShift Container Platform oc クライアントは、VirtualMachine (vm) および VirtualMachineInstance (vmi) オブジェクトタイプを含む、OpenShift Container Platform リソースを管理するためのコマンドラインユーティリティーです。

注記

-n <namespace> フラグを使用して、別のプロジェクトを指定できます。

表6.2 oc コマンド

Command説明

oc login -u <user_name>

OpenShift Container Platform クラスターに <user_name> としてログインします。

oc get <object_type>

現在のプロジェクトの指定されたオブジェクトタイプのオブジェクトの一覧を表示します。

oc describe <object_type> <resource_name>

現在のプロジェクトで特定のリソースの詳細を表示します。

oc create -f <object_config>

現在のプロジェクトで、ファイル名または標準入力 (stdin) からリソースを作成します。

oc edit <object_type> <resource_name>

現在のプロジェクトのリソースを編集します。

oc delete <object_type> <resource_name>

現在のプロジェクトのリソースを削除します。

oc client コマンドについてのより総合的な情報については、OpenShift Container Platform CLI ツールのドキュメントを参照してください。

第7章 仮想マシン

7.1. 仮想マシンの作成

以下のいずれかの手順を使用して、仮想マシンを作成します。

警告

openshift-* namespace に仮想マシンを作成しないでください。代わりに、openshift プレフィックスなしの新規 namespace を作成するか、または既存 namespace を使用します。

7.1.1. 仮想マシンウィザードの実行による仮想マシンの作成

Web コンソールは、GeneralNetworkingStorageAdvanced、および Review ステップに移動し、仮想マシンの作成プロセスを単純化するインタラクティブなウィザードを特長としています。すべての必須フィールドには * のマークが付けられます。必要なフィールドが完了したら、仮想マシンを確認し、これを作成することができます。

Network Interface Card (NIC) およびストレージディスクを作成し、それらの作成後に仮想マシンに割り当てることができます。

起動可能なディスク

URL または Container のいずれかが General ステップで Source として選択される場合、rootdisk ディスクが作成され、Bootable Disk として仮想マシンに割り当てられます。rootdisk を変更できますが、これを削除することはできません。

Bootable Disk は、仮想マシンにディスクが割り当てられていない場合、PXE ソースからプロビジョニングされる仮想マシンには不要です。1 つ以上のディスクが仮想マシンに割り当てられている場合、Bootable Disk を 1 つを選択する必要があります。

前提条件

  • ウィザードを使用して仮想マシンを作成する場合、仮想マシンのストレージメディアは Read-Write-Many(RWX)PVC をサポートする必要があります。

手順

  1. サイドメニューから WorkloadsVirtualization をクリックします。
  2. Virtual Machines タブをクリックします。
  3. Create Virtual Machine をクリックし、New with Wizard を選択します。
  4. General ステップで必要なすべてのフィールドに入力します。Template を選択すると、これらのフィールドへの入力が自動的に行われます。
  5. Next をクリックして Networking ステップに進みます。デフォルトで nic0 NIC が割り当てられます。

    1. オプション: Add Network Interface をクリックし、追加の NIC を作成します。
    2. オプション: すべての NIC の削除は、Options メニュー kebab をクリックし、Delete を選択して実行できます。仮想マシンの作成において、NIC が割り当てられている必要はありません。NIC は仮想マシンの作成後に作成することができます。
  6. Next をクリックして Storage 画面に進みます。

    1. オプション: Add Disk をクリックして追加のディスクを作成します。これらのディスクの削除は、Options メニュー kebab をクリックし、Delete を選択して実行できます。
    2. オプション: Options メニュー kebab をクリックし、ディスクを編集して変更内容を保存します。
  7. Review and Create をクリックします。Results 画面には、仮想マシンの JSON 設定ファイルが表示されます。

仮想マシンは Virtual Machines タブに一覧表示されます。

Web コンソールウィザードを実行する際は、仮想マシンウィザードのフィールドを参照します。

7.1.1.1. 仮想マシンウィザードのフィールド

名前パラメーター説明

Template

 

仮想マシンの作成に使用するテンプレート。テンプレートを選択すると、他のフィールドが自動的に入力されます。

ソース

PXE

PXE メニューから仮想マシンをプロビジョニングします。クラスターに PXE 対応の NIC が必要になります。

URL

HTTP または S3 エンドポイントで利用できるイメージから仮想マシンをプロビジョニングします。

コンテナー

クラスターからアクセスできるレジストリーの起動可能なオペレーティングシステムコンテナーから仮想マシンをプロビジョニングします。例: kubevirt/cirros-registry-disk-demo

Disk

ディスクから仮想マシンをプロビジョニングします。

Operating System

 

仮想マシン用に選択される主なオペレーティングシステム。

Flavor

small、medium、large、tiny、Custom

仮想マシンに割り当てられる CPU およびメモリーの量を決定するプリセット。Flavor に設定される Preset はオペレーティングシステムによって決まります。

Memory

 

仮想マシンに割り当てられるメモリーのサイズ (GiB 単位)。

CPU

 

仮想マシンに割り当てられる CPU の量。

Workload Profile

High Performance

高パフォーマンスのワークロードに対して最適化された仮想マシン設定。

Server

サーバーワークロードの実行に最適化されたプロファイル。

Desktop

デスクトップで使用するための仮想マシン設定。

名前

 

この名前には、小文字 (a-z)、数字 (0-9)、およびハイフン (-) を含めることができ、最大 253 文字を使用できます。最初と最後の文字は英数字にする必要があります。この名前には、大文字、スペース、ピリオド (.)、または特殊文字を使用できません。

説明

 

オプションの説明フィールド。

Start virtual machine on creation

 

これを選択すると、作成時に仮想マシンが自動的に起動します。

7.1.1.2. Cloud-init フィールド

名前説明

Hostname

仮想マシンの特定のホスト名を設定します。

Authenticated SSH Keys

仮想マシンの ~/.ssh/authorized_keys にコピーされるユーザーの公開鍵。

カスタムスクリプト

他のオプションを、カスタム cloud-init スクリプトを貼り付けるフィールドに置き換えます。

7.1.1.3. CD-ROM フィールド

ソース説明

Container

コンテナーのパスを指定します。例: kubevirt/fedora-registry-disk: latest

URL

URL パスおよびサイズ (GiB 単位) を指定します。次に、ドロップダウンリストからこの URL のストレージクラスを選択します。

Attach Disk

割り当てる仮想マシンディスクを選択します。

7.1.1.4. ネットワークフィールド

名前説明

名前

ネットワークインターフェースの名前。

Model

ネットワークインターフェースカードのモデルを示します。サポートされる値は e1000e および virtio です。

Network

利用可能なネットワーク接続定義の一覧。

Type

利用可能なバインディングメソッドの一覧。デフォルトの Pod ネットワークについては、masquerade が唯一の推奨されるバインディングメソッドになります。セカンダリーネットワークの場合は、 bridge バインディングメソッドを使用します。masquerade メソッドは、デフォルト以外のネットワークではサポートされません。

MAC Address

ネットワークインターフェースの MAC アドレス。MAC アドレスが指定されていない場合、セッションの一時アドレスが生成されます。

7.1.1.5. ストレージフィールド

名前説明

ソース

仮想マシンの空のディスクを選択するか、または URLContainerAttach Cloned Disk、または Attach Disk などの選択可能なオプションから選択します。既存ディスクを選択し、これを仮想マシンに割り当てるには、利用可能な Persistent Volume Claim (永続ボリューム要求、PVC) の一覧から Attach Cloned Disk または Attach Disk を選択します。

名前

ディスクの名前。この名前には、小文字 (a-z)、数字 (0-9)、ハイフン (-) およびピリオド (.) を含めることができ、最大 253 文字を使用できます。最初と最後の文字は英数字にする必要があります。この名前には、大文字、スペース、または特殊文字を使用できません。

Size (GiB)

ディスクのサイズ (GiB)。

Interface

ディスクデバイスのタイプ。サポートされるインターフェースは、virtIOSATA、および SCSI です。

Storage Class

ディスクの作成に使用されるストレージクラス。

Advanced → Volume Mode

永続ボリュームがフォーマットされたファイルシステムまたは raw ブロック状態を使用するかどうかを定義します。デフォルトは Filesystem です。

Advanced → Access Mode

永続ボリュームのアクセスモード。サポートされるアクセスモードは ReadWriteOnceReadOnlyMany、および ReadWriteMany です。

ストレージの詳細設定

以下のストレージの詳細設定は、BlankImport via URLURL、および Clone existing PVC ディスクで利用できます。これらのパラメーターはオプションです。これらのパラメーターを指定しない場合、システムは kubevirt-storage-class-defaults 設定マップのデフォルト値を使用します。

名前パラメーター説明

ボリュームモード

Filesystem

ファイルシステムベースのボリュームで仮想ディスクを保存します。

Block

ブロックボリュームで仮想ディスクを直接保存します。基礎となるストレージがサポートしている場合は、 Block を使用します。

アクセスモード

Single User (RWO)

ディスクは単一ノードで読み取り/書き込みとしてマウントできます。

Shared Access (RWX)

ディスクは数多くのノードで読み取り/書き込みとしてマウントできます。

注記

これは、ノード間の仮想マシンのライブマイグレーションなどの、一部の機能で必要になります。

Read Only (ROX)

ディスクは数多くのノードで読み取り専用としてマウントできます。

kubevirt-storage-class-defaults 設定マップについての詳細は、データボリュームのストレージのデフォルトについて参照してください。

7.1.2. 仮想マシンウィザードの作成用の事前に設定された YAML ファイルの貼り付け

YAML 設定ファイルを作成し、解析して仮想マシンを作成します。YAML 編集画面を開くと、常に有効な example 仮想マシン設定がデフォルトで提供されます。

Create をクリックする際に YAML 設定が無効な場合、エラーメッセージでエラーが発生したパラメーターが示唆されます。エラーは一度に 1 つのみ表示されます。

注記

編集中に YAML 画面から離れると、設定に対して加えた変更が取り消されます。

手順

  1. サイドメニューから WorkloadsVirtualization をクリックします。
  2. Virtual Machines タブをクリックします。
  3. Create Virtual Machine をクリックし、New from YAML を選択します。
  4. 編集可能なウィンドウで仮想マシンの設定を作成するか、またはこれを貼り付けます。

    1. または、YAML 画面にデフォルトで提供される example 仮想マシンを使用します。
  5. オプション: Download をクリックして YAML 設定ファイルをその現在の状態でダウンロードします。
  6. Create をクリックして仮想マシンを作成します。

仮想マシンは Virtual Machines タブに一覧表示されます。

7.1.3. CLI の使用による仮想マシンの作成

手順

仮想マシン設定ファイルの spec オブジェクトは、コア数やメモリーの量、ディスクタイプおよび使用するボリュームなどの仮想マシン設定を参照します。

  1. 関連する PVC claimName をボリュームとして参照し、仮想マシンディスクを仮想マシンに割り当てます。
  2. OpenShift Container Platform クライアントで仮想マシンを作成するには、以下のコマンドを実行します。

    $ oc create -f <vm.yaml>
  3. 仮想マシンは Stopped 状態で作成されるため、これを起動して仮想マシンインスタンスを実行します。
注記

ReplicaSetは、一定数の同一 Pod の可用性を保証することを目的としています。現時点で、ReplicaSet は OpenShift Virtualization ではサポートされていません。

表7.1 ドメイン設定

設定説明

Cores

仮想マシン内のコア数。1 以上の値である必要があります。

Memory

ノードによって仮想マシンに割り当てられる RAM の量。M (メガバイト) または Gi (ギガバイト) で値を指定します。

ディスク

参照されるボリュームの名前。ボリュームの名前に一致する必要があります。

表7.2 ボリューム設定

設定説明

名前

ボリュームの名前。 DNS ラベルであり、仮想マシン内で一意である必要があります。

PersistentVolumeClaim

仮想マシンに割り当てる PVC。PVC の claimName は仮想マシンと同じプロジェクトになければなりません。

7.1.4. 仮想マシンのストレージボリュームタイプ

ストレージボリュームタイプ説明

ephemeral

ネットワークボリュームを読み取り専用のバッキングストアとして使用するローカルの copy-on-write (COW) イメージ。バッキングボリュームは PersistentVolumeClaim である必要があります。一時イメージは仮想マシンの起動時に作成され、すべての書き込みをローカルに保存します。一時イメージは、仮想マシンの停止、再起動または削除時に破棄されます。バッキングボリューム (PVC) はいずれの方法でも変更されません。

persistentVolumeClaim

利用可能な PV を仮想マシンに割り当てます。PV の割り当てにより、仮想マシンデータのセッション間での永続化が可能になります。

CDI を使用して既存の仮想マシンディスクを PVC にインポートし、PVC を仮想マシンインスタンスに割り当てる方法は、既存の仮想マシンを OpenShift Container Platform にインポートするための推奨される方法です。ディスクを PVC 内で使用できるようにするためのいくつかの要件があります。

dataVolume

データボリュームは、インポート、クローンまたはアップロード操作で仮想マシンディスクの準備プロセスを管理することによって persistentVolumeClaim ディスクタイプにビルドされます。このボリュームタイプを使用する仮想マシンは、ボリュームが準備できるまで起動しないことが保証されます。

type: dataVolume または type: "" を指定します。persistentVolumeClaim などの type に他の値を指定すると、警告が表示され、仮想マシンは起動しません。

cloudInitNoCloud

参照される cloud-init NoCloud データソースが含まれるディスクを割り当て、ユーザーデータおよびメタデータを仮想マシンに提供します。cloud-init インストールは仮想マシンディスク内で必要になります。

containerDisk

コンテナーイメージレジストリーに保存される、仮想マシンディスクなどのイメージを参照します。イメージはレジストリーからプルされ、仮想マシンの起動時にディスクとして仮想マシンに割り当てられます。

containerDisk ボリュームは、単一の仮想マシンに制限されず、永続ストレージを必要としない多数の仮想マシンのクローンを作成するのに役立ちます。

RAW および QCOW2 形式のみがコンテナーイメージレジストリーのサポートされるディスクタイプです。QCOW2 は、縮小されたイメージサイズの場合に推奨されます。

注記

containerDisk ボリュームは一時的なボリュームです。これは、仮想マシンが停止されるか、再起動するか、または削除される際に破棄されます。containerDisk ボリュームは、CD-ROM などの読み取り専用ファイルシステムや破棄可能な仮想マシンに役立ちます。

emptyDisk

仮想マシンインターフェースのライフサイクルに関連付けられるスパースの QCOW2 ディスクを追加で作成します。データは仮想マシンのゲストによって実行される再起動後も存続しますが、仮想マシンが Web コンソールから停止または再起動する場合には破棄されます。空のディスクは、アプリケーションの依存関係および一時ディスクの一時ファイルシステムの制限を上回るデータを保存するために使用されます。

ディスク 容量 サイズも指定する必要があります。

7.1.5. 仮想マシンの RunStrategy について

仮想マシンの RunStrategy は、一連の条件に応じて仮想マシンインスタンス (VMI) の動作を判別します。spec.runStrategy 設定は、spec.running 設定の代わりに仮想マシン設定プロセスに存在します。spec.runStrategy 設定を使用すると、true または false の応答のみを伴う spec.running 設定とは対照的に、VMI の作成および管理をより柔軟に行えます。ただし、2 つの設定は相互排他的です。spec.running または spec.runStrategy のいずれかを使用できます。両方を使用する場合は、エラーが発生します。

4 つ RunStrategy が定義されています。

Always
VMI は仮想マシンの作成時に常に表示されます。元の VMI が何らかの理由で停止する場合に、新規の VMI が作成されます。これは spec.running: true と同じ動作です。
RerunOnFailure
前のインスタンスがエラーが原因で失敗する場合は、VMI が再作成されます。インスタンスは、仮想マシンが正常に停止する場合 (シャットダウン時など) には再作成されません。
Manual (手動)
startstop、および restart virtctl クライアントコマンドは、 VMI の状態および存在を制御するために使用できます。
Halted
仮想マシンが作成される際に VMI は存在しません。これは spec.running: false と同じ動作です。

startstop、および restart の virtctl コマンドの各種の組み合わせは、どの RunStrategy が使用されるかに影響を与えます。

以下の表は、仮想マシンの各種の状態からの移行について示しています。最初の列には、仮想マシンの初期の RunStrategy が表示されます。それぞれの追加の列には、virtctl コマンドと、このコマンド実行後の新規 RunStrategy が表示されます。

初期 RunStrategystartstoprestart

Always

-

Halted

Always

RerunOnFailure

-

Halted

RerunOnFailure

Manual

Manual

Manual

Manual

Halted

Always

-

-

注記

インストーラーでプロビジョニングされるインフラストラクチャーを使用してインストールされた OpenShift Virtualization クラスターでは、ノードで MachineHealthCheck に失敗し、クラスターで利用できなくなると、RunStrategy が Always または RerunOnFailure の仮想マシンが新規ノードで再スケジュールされます。

apiVersion: kubevirt.io/v1alpha3
kind: VirtualMachine
spec:
  RunStrategy: Always 1
  template:
...
1
VMI の現在の RunStrategy 設定。

7.1.6. 追加リソース

  • KubeVirt v0.34.1 API リファレンスVirtualMachineSpec 定義は、仮想マシン仕様のパラメーターおよび階層のより範囲の広いコンテキストを提供します。

    注記

    KubeVirt API リファレンスはアップストリームのプロジェクトリファレンスであり、OpenShift Virtualization でサポートされていないパラメーターが含まれる場合があります。

  • コンテナーディスクを準備してから、これを containerDisk ボリュームとして仮想マシンに追加します。
  • マシンヘルスチェックのデプロイおよび有効化についての詳細は、「Deploying machine health checks」を参照してください。
  • インストーラーでプロビジョニングされるインフラストラクチャーについての詳細は、「Installer-provisioned infrastructure overview」を参照してください。

7.2. 仮想マシンの編集

Web コンソールの YAML エディターまたはコマンドラインの OpenShift クライアントのいずれかを使用して、仮想マシン設定を更新できます。Web コンソールの Virtual Machine Overview でパラメーターのサブセットを更新することもできます。

7.2.1. Web コンソールでの仮想マシンの編集

関連するフィールドの横にある鉛筆アイコンをクリックして、Web コンソールの Virtual Machine Overview 画面で仮想マシンの選択する値 (select values) を編集します。他の値は、CLI を使用して編集できます。

手順

  1. サイドメニューから WorkloadsVirtualization をクリックします。
  2. Virtual Machines タブをクリックします。
  3. 仮想マシンを選択して、Virtual Machine Overview 画面を開きます。
  4. Details タブをクリックします。
  5. 鉛筆アイコンをクリックして、フィールドを編集可能にします。
  6. 関連する変更を加え、Save をクリックします。
注記

仮想マシンが実行されている場合、Boot Order または Flavor への変更は仮想マシンを再起動するまで反映されません。

関連するフィールドの右側にある View Pending Changes をクリックして、保留中の変更を表示できます。ページ上部の Pending Changes バナーには、仮想マシンの再起動時に適用されるすべての変更の一覧が表示されます。

7.2.2. Web コンソールを使用した仮想マシンの YAML 設定の編集

Web コンソールを使用して、仮想マシンの YAML 設定を編集します。

すべてのパラメーターを更新できる訳ではありません。変更不可の値を編集し、Save をクリックすると、更新できなかったパラメーターを示すエラーメッセージが出されます。

YAML 設定は、仮想マシンが Running の場合に編集できますが、変更は仮想マシンが停止され、再度起動された後にのみ有効になります。

注記

編集中に YAML 画面から離れると、設定に対して加えた変更が取り消されます。

手順

  1. サイドメニューから WorkloadsVirtualization をクリックします。
  2. Virtual Machines タブをクリックします。
  3. 仮想マシンを選択して、Virtual Machine Overview 画面を開きます。
  4. YAML タブをクリックして編集可能な設定を表示します。
  5. オプション: Download をクリックして YAML ファイルをその現在の状態でローカルにダウンロードできます。
  6. ファイルを編集し、Save をクリックします。

オブジェクトの更新されたバージョン番号を含む、変更が正常に行われたことを示す確認メッセージが表示されます。

7.2.3. CLI を使用した仮想マシン YAML 設定の編集

以下の手順を使用し、CLI を使用して仮想マシン YAML 設定を編集します。

前提条件

  • YAML オブジェクト設定ファイルを使って仮想マシンを設定していること。
  • oc CLI をインストールしていること。

手順

  1. 以下のコマンドを実行して、仮想マシン設定を更新します。

    $ oc edit <object_type> <object_ID>
  2. オブジェクト設定を開きます。
  3. YAML を編集します。
  4. 実行中の仮想マシンを編集する場合は、以下のいずれかを実行する必要があります。

    • 仮想マシンを再起動します。
    • 新規の設定を有効にするために、以下のコマンドを実行します。

      $ oc apply <object_type> <object_ID>

7.2.4. 仮想マシンへの仮想ディスクの追加

以下の手順を使用して仮想ディスクを仮想マシンに追加します。

手順

  1. サイドメニューから WorkloadsVirtualization をクリックします。
  2. Virtual Machines タブをクリックします。
  3. 仮想マシンを選択して、Virtual Machine Overview 画面を開きます。
  4. Disks タブをクリックします。
  5. Add Disks をクリックして、 Add Disk ウィンドウを開きます。
  6. Add Disk ウィンドウで、SourceNameSizeInterfaceType、および Storage Class を指定します。

    1. オプション: Advanced 一覧で、仮想ディスクの Volume Mode および Access Mode を指定します。これらのパラメーターを指定しない場合、システムは kubevirt-storage-class-defaults 設定マップのデフォルト値を使用します。
  7. Add をクリックします。
注記

仮想マシンが実行中の場合、新規ディスクは pending restart 状態にあり、仮想マシンを再起動するまで割り当てられません。

ページ上部の Pending Changes バナーには、仮想マシンの再起動時に適用されるすべての変更の一覧が表示されます。

kubevirt-storage-class-defaults 設定マップについての詳細は、データボリュームのストレージのデフォルトについて参照してください。

7.2.4.1. ストレージフィールド

名前説明

ソース

仮想マシンの空のディスクを選択するか、または URLContainerAttach Cloned Disk、または Attach Disk などの選択可能なオプションから選択します。既存ディスクを選択し、これを仮想マシンに割り当てるには、利用可能な Persistent Volume Claim (永続ボリューム要求、PVC) の一覧から Attach Cloned Disk または Attach Disk を選択します。

名前

ディスクの名前。この名前には、小文字 (a-z)、数字 (0-9)、ハイフン (-) およびピリオド (.) を含めることができ、最大 253 文字を使用できます。最初と最後の文字は英数字にする必要があります。この名前には、大文字、スペース、または特殊文字を使用できません。

Size (GiB)

ディスクのサイズ (GiB)。

Interface

ディスクデバイスのタイプ。サポートされるインターフェースは、virtIOSATA、および SCSI です。

Storage Class

ディスクの作成に使用されるストレージクラス。

Advanced → Volume Mode

永続ボリュームがフォーマットされたファイルシステムまたは raw ブロック状態を使用するかどうかを定義します。デフォルトは Filesystem です。

Advanced → Access Mode

永続ボリュームのアクセスモード。サポートされるアクセスモードは ReadWriteOnceReadOnlyMany、および ReadWriteMany です。

ストレージの詳細設定

以下のストレージの詳細設定は、BlankImport via URLURL、および Clone existing PVC ディスクで利用できます。これらのパラメーターはオプションです。これらのパラメーターを指定しない場合、システムは kubevirt-storage-class-defaults 設定マップのデフォルト値を使用します。

名前パラメーター説明

ボリュームモード

Filesystem

ファイルシステムベースのボリュームで仮想ディスクを保存します。

Block

ブロックボリュームで仮想ディスクを直接保存します。基礎となるストレージがサポートしている場合は、 Block を使用します。

アクセスモード

Single User (RWO)

ディスクは単一ノードで読み取り/書き込みとしてマウントできます。

Shared Access (RWX)

ディスクは数多くのノードで読み取り/書き込みとしてマウントできます。

注記

これは、ノード間の仮想マシンのライブマイグレーションなどの、一部の機能で必要になります。

Read Only (ROX)

ディスクは数多くのノードで読み取り専用としてマウントできます。

7.2.5. 仮想マシンへのネットワークインターフェースの追加

以下の手順を使用してネットワークインターフェースを仮想マシンに追加します。

手順

  1. サイドメニューから WorkloadsVirtualization をクリックします。
  2. Virtual Machines タブをクリックします。
  3. 仮想マシンを選択して、Virtual Machine Overview 画面を開きます。
  4. Network Interfaces タブをクリックします。
  5. Add Network Interface をクリックします。
  6. Add Network Interface ウィンドウで、ネットワークインターフェースの NameModelNetworkType、および MAC Address を指定します。
  7. Add をクリックします。
注記

仮想マシンが実行中の場合、新規ネットワークインターフェースは pending restart 状態にあり、仮想マシンを再起動するまで変更は反映されません。

ページ上部の Pending Changes バナーには、仮想マシンの再起動時に適用されるすべての変更の一覧が表示されます。

7.2.5.1. ネットワークフィールド

名前説明

名前

ネットワークインターフェースの名前。

Model

ネットワークインターフェースカードのモデルを示します。サポートされる値は e1000e および virtio です。

Network

利用可能なネットワーク接続定義の一覧。

Type

利用可能なバインディングメソッドの一覧。デフォルトの Pod ネットワークについては、masquerade が唯一の推奨されるバインディングメソッドになります。セカンダリーネットワークの場合は、 bridge バインディングメソッドを使用します。masquerade メソッドは、デフォルト以外のネットワークではサポートされません。

MAC Address

ネットワークインターフェースの MAC アドレス。MAC アドレスが指定されていない場合、セッションの一時アドレスが生成されます。

7.2.6. 仮想マシンの CD-ROM の編集

以下の手順を使用して、仮想マシンの CD-ROM を設定します。

手順

  1. Virtual Machines タブで、仮想マシンを選択します。
  2. Overview タブを選択します。
  3. CD-ROM 設定を追加または編集するには、CD-ROMs ラベルの右側にある鉛筆アイコンをクリックします。Edit CD-ROM ウィンドウが開きます。

    • CD-ROM が編集できない場合、以下のメッセージが表示されます: The virtual machine doesn’t have any CD-ROMs attached.
    • 利用可能な CD-ROM がある場合は、- をクリックして CD-ROM を削除できます。
  4. Edit CD-ROM ウィンドウで、以下を実行します。

    1. Media Type のドロップダウンリストから CD-ROM 設定のタイプを選択します。CD-ROM 設定タイプは ContainerURL、および Persistent Volume Claim です。
    2. それぞれの Type に必要な情報を入力します。
    3. すべての CD-ROM が追加されたら、Save をクリックします。

7.3. ブート順序の編集

Web コンソールまたは CLI を使用して、ブート順序リストの値を更新できます。

Virtual Machine Overview ページの Boot Order で、以下を実行できます。

  • ディスクまたはネットワークインターフェースカード (NIC) を選択し、これをブート順序の一覧に追加します。
  • ブート順序の一覧でディスクまたは NIC の順序を編集します。
  • ブート順序の一覧からディスクまたは NIC を削除して、起動可能なソースのインベントリーに戻します。

7.3.1. Web コンソールでのブート順序一覧への項目の追加

Web コンソールを使用して、ブート順序一覧に項目を追加します。

手順

  1. サイドメニューから WorkloadsVirtualization をクリックします。
  2. Virtual Machines タブをクリックします。
  3. 仮想マシンを選択して、Virtual Machine Overview 画面を開きます。
  4. Details タブをクリックします。
  5. Boot Order の右側にある鉛筆アイコンをクリックします。YAML 設定が存在しない場合や、これがブート順序一覧の初回作成時の場合、以下のメッセージが表示されます。No resource selected.仮想マシンは、YAML ファイルでの出現順にディスクからの起動を試行します。
  6. Add Source をクリックして、仮想マシンのブート可能なディスクまたはネットワークインターフェースカード (NIC) を選択します。
  7. 追加のディスクまたは NIC をブート順序一覧に追加します。
  8. Save をクリックします。
注記

仮想マシンが実行されている場合、Boot Order への変更は仮想マシンを再起動するまで反映されません。

Boot Order フィールドの右側にある View Pending Changes をクリックして、保留中の変更を表示できます。ページ上部の Pending Changes バナーには、仮想マシンの再起動時に適用されるすべての変更の一覧が表示されます。

7.3.2. Web コンソールでのブート順序一覧の編集

Web コンソールで起動順序一覧を編集します。

手順

  1. サイドメニューから WorkloadsVirtualization をクリックします。
  2. Virtual Machines タブをクリックします。
  3. 仮想マシンを選択して、Virtual Machine Overview 画面を開きます。
  4. Details タブをクリックします。
  5. Boot Order の右側にある鉛筆アイコンをクリックします。
  6. ブート順序一覧で項目を移動するのに適した方法を選択します。

    • スクリーンリーダーを使用しない場合、移動する項目の横にある矢印アイコンにカーソルを合わせ、項目を上下にドラッグし、選択した場所にドロップします。
    • スクリーンリーダーを使用する場合は、上矢印キーまたは下矢印を押して、ブート順序一覧で項目を移動します。次に Tab キーを押して、選択した場所に項目をドロップします。
  7. Save をクリックします。
注記

仮想マシンが実行されている場合、ブート順序の変更は仮想マシンが再起動されるまで反映されません。

Boot Order フィールドの右側にある View Pending Changes をクリックして、保留中の変更を表示できます。ページ上部の Pending Changes バナーには、仮想マシンの再起動時に適用されるすべての変更の一覧が表示されます。

7.3.3. YAML 設定ファイルでのブート順序一覧の編集

CLI を使用して、YAML 設定ファイルのブート順序の一覧を編集します。

手順

  1. 以下のコマンドを実行して、仮想マシンの YAML 設定ファイルを開きます。

    $ oc edit vm example
  2. YAML ファイルを編集し、ディスクまたはネットワークインターフェースカード (NIC) に関連付けられたブート順序の値を変更します。以下は例になります。

    disks:
      - bootOrder: 1 1
        disk:
          bus: virtio
        name: containerdisk
      - disk:
          bus: virtio
        name: cloudinitdisk
      - cdrom:
          bus: virtio
        name: cd-drive-1
    interfaces:
      - boot Order: 2 2
        macAddress: '02:96:c4:00:00'
        masquerade: {}
        name: default
    1
    ディスクに指定されたブート順序の値。
    2
    ネットワークインターフェースカードに指定されたブート順序の値。
  3. YAML ファイルを保存します。
  4. reload the content をクリックして、Web コンソールで YAML ファイルの更新されたブート順序の値をブート順序一覧に適用します。

7.3.4. Web コンソールでのブート順序一覧からの項目の削除

Web コンソールを使用して、ブート順序の一覧から項目を削除します。

手順

  1. サイドメニューから WorkloadsVirtualization をクリックします。
  2. Virtual Machines タブをクリックします。
  3. 仮想マシンを選択して、Virtual Machine Overview 画面を開きます。
  4. Details タブをクリックします。
  5. Boot Order の右側にある鉛筆アイコンをクリックします。
  6. 項目の横にある Remove アイコン delete をクリックします。この項目はブート順序の一覧から削除され、利用可能なブートソースの一覧に保存されます。ブート順序一覧からすべての項目を削除する場合、以下のメッセージが表示されます。No resource selected.仮想マシンは、YAML ファイルでの出現順にディスクからの起動を試行します。
注記

仮想マシンが実行されている場合、Boot Order への変更は仮想マシンを再起動するまで反映されません。

Boot Order フィールドの右側にある View Pending Changes をクリックして、保留中の変更を表示できます。ページ上部の Pending Changes バナーには、仮想マシンの再起動時に適用されるすべての変更の一覧が表示されます。

7.4. 仮想マシンの削除

Web コンソールまたは oc コマンドラインインターフェースを使用して、仮想マシンを削除できます。

7.4.1. Web コンソールの使用による仮想マシンの削除

仮想マシンを削除すると、仮想マシンはクラスターから永続的に削除されます。

注記

仮想マシンを削除する際に、これが使用するデータボリュームは自動的に削除されます。

手順

  1. OpenShift Virtualization コンソールのサイドメニューから WorkloadsVirtualization をクリックします。
  2. Virtual Machines タブをクリックします。
  3. 削除する仮想マシンの ⋮ ボタンをクリックして Delete Virtual Machine を選択します。

    • または、仮想マシン名をクリックして Virtual Machine Overview 画面を開き、ActionsDelete Virtual Machine をクリックします。
  4. 確認のポップアップウィンドウで、Delete をクリックし、仮想マシンを永続的に削除します。

7.4.2. CLI の使用による仮想マシンの削除

oc コマンドラインインターフェース (CLI) を使用して仮想マシンを削除できます。oc クライアントを使用すると、複数の仮想マシンで各種のアクションを実行できます。

注記

仮想マシンを削除する際に、これが使用するデータボリュームは自動的に削除されます。

前提条件

  • 削除する仮想マシンの名前を特定すること。

手順

  • 以下のコマンドを実行し、仮想マシンを削除します。

    $ oc delete vm <vm_name>
    注記

    このコマンドは、現在のプロジェクトに存在するオブジェクトのみを削除します。削除する必要のあるオブジェクトが別のプロジェクトまたは namespace にある場合、-n <project_name> オプションを指定します。

7.5. 仮想マシンインスタンスの管理

OpenShift Virtualization 環境外に独立して作成されたスタンドアロンの仮想マシンインスタンス(VMI) がある場合、Web コンソールまたはコマンドラインインターフェース (CLI) を使用してこれらを管理できます。

7.5.1. 仮想マシンインスタンスについて

仮想マシンインスタンス (VMI) は、実行中の仮想マシンを表します。VMI が仮想マシンまたは別のオブジェクトによって所有されている場合、Web コンソールで、または oc コマンドラインインターフェース(CLI) を使用し、所有者を通してこれを管理します。

スタンドアロンの VMI は、自動化または CLI で他の方法により、スクリプトを使用して独立して作成され、起動します。お使いの環境では、OpenShift Virtualization 環境外で開発され、起動されたスタンドアロンの VMI が存在する可能性があります。CLI を使用すると、引き続きそれらのスタンドアロン VMI を管理できます。スタンドアロン VMI に関連付けられた特定のタスクに Web コンソールを使用することもできます。

  • スタンドアロン VMI とそれらの詳細を一覧表示します。
  • スタンドアロン VMI のラベルとアノテーションを編集します。
  • スタンドアロン VMI を削除します。

仮想マシンを削除する際に、関連付けられた VMI は自動的に削除されます。仮想マシンまたは他のオブジェクトによって所有されていないため、スタンドアロン VMI を直接削除します。

注記

OpenShift Virtualization をアンインストールする前に、CLI または Web コンソールを使用してスタンドアロンの VMI の一覧を表示します。次に、未処理の VMI を削除します。

7.5.2. CLI を使用した仮想マシンインスタンスの一覧表示

oc コマンドラインインターフェース (CLI) を使用して、スタンドアロンおよび仮想マシンによって所有されている VMI を含むすべての仮想マシンの一覧を表示できます。

手順

  • 以下のコマンドを実行して、すべての VMI の一覧を表示します。

    $ oc get vmis

7.5.3. Web コンソールを使用したスタンドアロン仮想マシンインスタンスの一覧表示

Web コンソールを使用して、仮想マシンによって所有されていないクラスター内のスタンドアロンの仮想マシンインスタンス (VMI) の一覧を表示できます。

注記

仮想マシンまたは他のオブジェクトが所有する VMI は、Web コンソールには表示されません。Web コンソールは、スタンドアロンの VMI のみを表示します。クラスター内のすべての VMI を一覧表示するには、CLI を使用する必要があります。

手順

  • サイドメニューから Workloads → Virtualization をクリックします。仮想マシンおよびスタンドアロン VMI の一覧が表示されます。スタンドアロン VMI は、仮想マシンインスタンス名の横に表示される暗い配色のバッジで特定できます。

7.5.4. Web コンソールを使用したスタンドアロン仮想マシンインスタンスの編集

Web コンソールを使用して、スタンドアロン仮想マシンインスタンスのアノテーションおよびラベルを編集できます。スタンドアロン VMI の Details ページに表示される他の項目は編集できません。

手順

  1. サイドメニューから WorkloadsVirtualization をクリックします。仮想マシン (VM) およびスタンドアロン VMI の一覧が表示されます。
  2. スタンドアロン VMI の名前をクリックして、 Virtual Machine Instance Overview 画面を開きます。
  3. Details タブをクリックします。
  4. Annotations の右側にある鉛筆アイコンをクリックします。
  5. 関連する変更を加え、Save をクリックします。
注記

スタンドアロン VMI のラベルを編集するには、Actions をクリックして、Edit Labels を選択します。関連する変更を加え、Save をクリックします。

7.5.5. CLI を使用したスタンドアロン仮想マシンインスタンスの削除

oc コマンドラインインターフェース (CLI) を使用してスタンドアロン仮想マシンインスタンス (VMI) を削除できます。

前提条件

  • 削除する必要のある VMI の名前を特定すること。

手順

  • 以下のコマンドを実行して VMI を削除します。

    $ oc delete vmi <vmi_name>

7.5.6. Web コンソールを使用したスタンドアロン仮想マシンインスタンスの削除

Web コンソールからスタンドアロン仮想マシンインスタンス (VMI) を削除します。

手順

  1. OpenShift Container Platform Web コンソールで、サイドメニューから WorkloadsVirtualization をクリックします。
  2. 削除する必要のあるスタンドアロン仮想マシンインスタンス (VMI) の ⋮ ボタンをクリックし、 Delete Virtual Machine Instance を選択します。

    • または、スタンドアロン VMI の名前をクリックします。Virtual Machine Instance Overview ページが表示されます。
  3. ActionsDelete Virtual Machine Instance を選択します。
  4. 確認のポップアップウィンドウで、Delete をクリックし、スタンドアロン VMI を永続的に削除します。

7.6. 仮想マシンの状態の制御

Web コンソールから仮想マシンを停止し、起動し、再起動し、一時停止を解除することができます。

注記

コマンドラインインターフェース (CLI) から仮想マシンを制御するには、virtctl クライアントを使用します。

7.6.1. 仮想マシンの起動

Web コンソールから仮想マシンを起動できます。

手順

  1. サイドメニューから WorkloadsVirtualization をクリックします。
  2. Virtual Machines タブをクリックします。
  3. 起動する仮想マシンが含まれる行を見つけます。
  4. ユースケースに適したメニューに移動します。

    • 複数の仮想マシンでのアクションの実行が可能なこのページに留まるには、以下を実行します。

      1. 行の右端にある Options メニュー kebab をクリックします。
    • 選択した仮想マシンを起動する前に、その仮想マシンの総合的な情報を表示するには、以下を実行します。

      1. 仮想マシンの名前をクリックして、Virtual Machine Overview ページにアクセスします。
      2. Actions をクリックします。
  5. Start Virtual Machine を選択します。
  6. 確認ウィンドウで Start をクリックし、仮想マシンを起動します。
注記

URL ソースからプロビジョニングされる仮想マシンの初回起動時に、OpenShift Virtualization が URL エンドポイントからコンテナーをインポートする間、仮想マシンの状態は Importing になります。このプロセスは、イメージのサイズによって数分の時間がかかる可能性があります。

7.6.2. 仮想マシンの再起動

Web コンソールから実行中の仮想マシンを再起動できます。

重要

エラーを回避するには、ステータスが Importing の仮想マシンは再起動しないでください。

手順

  1. サイドメニューから WorkloadsVirtualization をクリックします。
  2. Virtual Machines タブをクリックします。
  3. 再起動する仮想マシンが含まれる行を見つけます。
  4. ユースケースに適したメニューに移動します。

    • 複数の仮想マシンでのアクションの実行が可能なこのページに留まるには、以下を実行します。

      1. 行の右端にある Options メニュー kebab をクリックします。
    • 選択した仮想マシンを再起動する前に、その仮想マシンの総合的な情報を表示するには、以下を実行します。

      1. 仮想マシンの名前をクリックして、Virtual Machine Overview ページにアクセスします。
      2. Actions をクリックします。
  5. Restart Virtual Machine を選択します。
  6. 確認ウィンドウで Restart をクリックし、仮想マシンを再起動します。

7.6.3. 仮想マシンの停止

Web コンソールから仮想マシンを停止できます。

手順

  1. サイドメニューから WorkloadsVirtualization をクリックします。
  2. Virtual Machines タブをクリックします。
  3. 停止する仮想マシンが含まれる行を見つけます。
  4. ユースケースに適したメニューに移動します。

    • 複数の仮想マシンでのアクションの実行が可能なこのページに留まるには、以下を実行します。

      1. 行の右端にある Options メニュー kebab をクリックします。
    • 選択した仮想マシンを停止する前に、その仮想マシンの総合的な情報を表示するには、以下を実行します。

      1. 仮想マシンの名前をクリックして、Virtual Machine Overview ページにアクセスします。
      2. Actions をクリックします。
  5. Stop Virtual Machine を選択します。
  6. 確認ウィンドウで Stop をクリックし、仮想マシンを停止します。

7.6.4. 仮想マシンの一時停止の解除

Web コンソールから仮想マシンの一時停止を解除できます。

前提条件

  • 1 つ以上の仮想マシンのステータスが Paused である必要がある。

    注記

    virtctl クライアントを使用して仮想マシンを一時停止することができます。

手順

  1. サイドメニューから WorkloadsVirtualization をクリックします。
  2. Virtual Machines タブをクリックします。
  3. 一時停止を解除する仮想マシンが含まれる行を見つけます。
  4. ユースケースに適したメニューに移動します。

    • 複数の仮想マシンでのアクションの実行が可能なこのページに留まるには、以下を実行します。

      1. Status 列で、Paused をクリックします。
    • 選択した仮想マシンの一時停止を解除する前に、その仮想マシンの総合的な情報を表示するには、以下を実行します。

      1. 仮想マシンの名前をクリックして、Virtual Machine Overview ページにアクセスします。
      2. Status の右側にある鉛筆アイコンをクリックします。
  5. 確認ウィンドウで Stop をクリックし、仮想マシンの一時停止を解除します。

7.7. 仮想マシンコンソールへのアクセス

OpenShift Virtualization は、異なる製品タスクを実現するために使用できる異なる仮想マシンコンソールを提供します。Web コンソールおよび CLI コマンドを使用してこれらのコンソールにアクセスできます。

7.7.1. 仮想マシンコンソールのセッション

Web コンソールの Virtual Machine Details ページの Console タブから、実行中の仮想マシンの VNC およびシリアルコンソールに接続することができます。

VNC コンソール は、Consoles タブに移動する際には常にデフォルトで開きます。VNC Console ドロップダウンリストをクリックし、Serial Console を選択して、シリアルコンソールへの接続を開くことができます。

コンソールのセッションは切断しない限り、バックグラウンドでアクティブな状態のままになります。コンソールセッションが一度に 1 つだけ開かれていることを確認するには、コンソールを切り換える前に、 Disconnect before switching チェックボックスをクリックします。

Open Console in New Window ボタンをクリックするか、または ActionsOpen Console をクリックして、切り離されたウィンドウのアクティブなコンソールセッションを開くことができます。

VNC コンソール のオプション

  • Send Key をクリックして、キーの組み合わせを仮想マシンに送信します。

シリアルコンソール のオプション

  • Disconnect をクリックして、仮想マシンから Serial Console セッションを手動で切断します。
  • Reconnect ボタンを使用して Serial Console セッションを仮想マシンに対して手動で開きます。

7.7.2. Web コンソールの使用による仮想マシンへの接続

7.7.2.1. ターミナルへの接続

Web コンソールを使用して仮想マシンに接続することができます。

手順

  1. 正しいプロジェクトを指定していることを確認します。そうでない場合は、Project 一覧をクリックして適切なプロジェクトを選択します。
  2. サイドメニューから WorkloadsVirtualization をクリックします。
  3. Virtual Machines タブをクリックします。
  4. 仮想マシンを選択して、Virtual Machine Overview 画面を開きます。
  5. Details タブで、virt-launcher-<vm-name> Pod をクリックします。
  6. Terminal タブをクリックします。ターミナルが空白の場合、ターミナルをクリックし、任意のキーを押して接続を開始します。

7.7.2.2. シリアルコンソールへの接続

Web コンソールの Virtual Machine Overview 画面の Consoles タブから、実行中の仮想マシンの Serial Console に接続します。

手順

  1. OpenShift Virtualization コンソールのサイドメニューから WorkloadsVirtualization をクリックします。
  2. Virtual Machines タブをクリックします。
  3. 仮想マシンを選択して、Virtual Machine Overview ページを開きます。
  4. Consoles をクリックします。VNC コンソールがデフォルトで開きます。
  5. VNC Console ドロップダウンリストをクリックし、Serial Console を選択します。
  6. オプション: Open Console in New Window をクリックして、別のウィンドウでシリアルコンソールを開きます。

7.7.2.3. VNC コンソールへの接続

Web コンソールの Virtual Machine Overview 画面の Console タブから実行中の仮想マシンの VNC コンソールに接続します。

手順

  1. OpenShift Virtualization コンソールのサイドメニューから WorkloadsVirtualization をクリックします。
  2. Virtual Machines タブをクリックします。
  3. 仮想マシンを選択して、Virtual Machine Overview ページを開きます。
  4. Console タブをクリックします。VNC コンソールがデフォルトで開きます。
  5. オプション: Open Console in New Window をクリックして、別のウィンドウで VNC コンソールを開きます。

7.7.2.4. RDP コンソールへの接続

Remote Desktop Protocol (RDP) を使用するデスクトップビューアーコンソールは、Windows 仮想マシンに接続するためのより使いやすいコンソールを提供します。

RDP を使用して Windows 仮想マシンに接続するには、Web コンソールの Virtual Machine Details 画面の Consoles タブから仮想マシンの console.rdp ファイルをダウンロードし、これを優先する RDP クライアントに指定します。

前提条件

  • QEMU ゲストエージェントがインストールされた実行中の Windows 仮想マシン。qemu-guest-agent は VirtIO ドライバーに含まれています。
  • 仮想マシンに接続された layer-2 NIC。
  • Windows 仮想マシンと同じネットワーク上のマシンにインストールされた RDP クライアント。

手順

  1. OpenShift Virtualization コンソールのサイドメニューから WorkloadsVirtualization をクリックします。
  2. Virtual Machines タブをクリックします。
  3. Windows 仮想マシンを選択して、Virtual Machine Overview 画面を開きます。
  4. Console タブをクリックします。
  5. Console 一覧で、Desktop Viewer を選択します。
  6. Network Interface 一覧で、 layer-2 NIC を選択します。
  7. Launch Remote Desktop をクリックし、 console.rdp ファイルをダウンロードします。
  8. RDP クライアントを開き、console.rdp ファイルを参照します。たとえば、remmina を使用します。

    $ remmina --connect /path/to/console.rdp
  9. Administrator ユーザー名およびパスワードを入力して、Windows 仮想マシンに接続します。

7.7.3. CLI コマンドの使用による仮想マシンコンソールへのアクセス

7.7.3.1. SSH 経由での仮想マシンインスタンスへのアクセス

仮想マシン (仮想マシン) にポート 22 を公開した後に、SSH を使用して仮想マシンにアクセスできます。

virtctl expose コマンドは、仮想マシンインスタンス (VMI) のポートをノードポートに転送し、有効にされたアクセスのサービスを作成します。以下の例では、fedora-vm-ssh サービスを作成します。このサービスは、クラスターノードの特定のポートから <fedora-vm> 仮想マシンのポート 22 にトラフィックを転送します。

前提条件

  • VMI と同じプロジェクトを使用する。
  • アクセスする VMI は、masquerade バインディング方法を使用してデフォルトの Pod ネットワークに接続されている。
  • アクセスする VMI が実行中であること。
  • OpenShift CLI (oc) をインストールすること。

手順

  1. 以下のコマンドを実行して fedora-vm-ssh サービスを作成します。

    $ virtctl expose vm <fedora-vm> --port=22 --name=fedora-vm-ssh --type=NodePort 1
    1
    <fedora-vm> は、fedora-vm-ssh サービスを実行する仮想マシンの名前です。
  2. サービスをチェックし、サービスが取得したポートを見つけます。

    $ oc get svc

出力例

NAME            TYPE       CLUSTER-IP     EXTERNAL-IP   PORT(S)           AGE
fedora-vm-ssh   NodePort   127.0.0.1      <none>        22:32551/TCP   6s

+ この例では、サービスは 32551 ポートを取得しています。

  1. SSH 経由で VMI にログインします。クラスターノードの ipAddress および直前の手順で確認したポートを使用します。

    $ ssh username@<node_IP_address> -p 32551

7.7.3.2. 仮想マシンインスタンスのシリアルコンソールへのアクセス

virtctl console コマンドは、指定された仮想マシンインスタンスへのシリアルコンソールを開きます。

前提条件

  • virt-viewer パッケージがインストールされていること。
  • アクセスする仮想マシンインスタンスが実行中であること。

手順

  • virtctl でシリアルコンソールに接続します。

    $ virtctl console <VMI>

7.7.3.3. VNC を使用した仮想マシンインスタンスのグラフィカルコンソールへのアクセス

virtctl クライアントユーティリティーは remote-viewer 機能を使用し、実行中の仮想マシンインスタンスに対してグラフィカルコンソールを開くことができます。この機能は virt-viewer パッケージに組み込まれています。

前提条件

  • virt-viewer パッケージがインストールされていること。
  • アクセスする仮想マシンインスタンスが実行中であること。
注記

リモートマシンで SSH 経由で virtctl を使用する場合、X セッションをマシンに転送する必要があります。

手順

  1. virtctl ユーティリティーを使用してグラフィカルインターフェースに接続します。

    $ virtctl vnc <VMI>
  2. コマンドが失敗した場合には、トラブルシューティング情報を収集するために -v フラグの使用を試行します。

    $ virtctl vnc <VMI> -v 4

7.7.3.4. RDP コンソールの使用による Windows 仮想マシンへの接続

Remote Desktop Protocol (RDP) は、Windows 仮想マシンに接続するためのより使いやすいコンソールを提供します。

RDP を使用して Windows 仮想マシンに接続するには、割り当てられた L2 NIC の IP アドレスを RDP クライアントに対して指定します。

前提条件

  • QEMU ゲストエージェントがインストールされた実行中の Windows 仮想マシン。qemu-guest-agent は VirtIO ドライバーに含まれています。
  • 仮想マシンに接続された layer-2 NIC。
  • Windows 仮想マシンと同じネットワーク上のマシンにインストールされた RDP クライアント。

手順

  1. アクセストークンを持つユーザーとして、oc CLI ツールを使って OpenShift Virtualization クラスターにログインします。

    $ oc login -u <user> https://<cluster.example.com>:8443
  2. oc describe vmi を使用して、実行中の Windows 仮想マシンの設定を表示します。

    $ oc describe vmi <windows-vmi-name>

    出力例

    ...
    spec:
      networks:
      - name: default
        pod: {}
      - multus:
          networkName: cnv-bridge
        name: bridge-net
    ...
    status:
      interfaces:
      - interfaceName: eth0
        ipAddress: 198.51.100.0/24
        ipAddresses:
          198.51.100.0/24
        mac: a0:36:9f:0f:b1:70
        name: default
      - interfaceName: eth1
        ipAddress: 192.0.2.0/24
        ipAddresses:
          192.0.2.0/24
          2001:db8::/32
        mac: 00:17:a4:77:77:25
        name: bridge-net
    ...

  3. レイヤー 2 ネットワークインターフェースの IP アドレスを特定し、これをコピーします。これは直前の例では 192.0.2.0 であり、IPv6 を選択する場合は 2001:db8:: になります。
  4. RDP クライアントを開き、接続用に直前の手順でコピーした IP アドレスを使用します。
  5. Administrator ユーザー名およびパスワードを入力して、Windows 仮想マシンに接続します。

7.8. 障害が発生したノードの解決による仮想マシンのフェイルオーバーのトリガー

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

注記

インストーラーでプロビジョニングされるインフラストラクチャー を使用してクラスターをインストールし、マシンヘルスチェックを適切に設定している場合は、以下のようになります。

  • 障害が発生したノードは自動的に再利用されます。
  • RunStrategyAlways または RerunOnFailure に設定された仮想マシンは正常なノードで自動的にスケジュールされます。

7.8.1. 前提条件

  • 仮想マシンが実行されているノードには NotReady 状態が設定されている。
  • 障害のあるノードで実行されていた仮想マシンでは、 RunStrategyAlways に設定されている。
  • OpenShift CLI (oc) がインストールされていること。

7.8.2. ベアメタルクラスターからのノードの削除

CLI を使用してノードを削除する場合、ノードオブジェクトは Kubernetes で削除されますが、ノード自体にある Pod は削除されません。レプリケーションコントローラーで管理されないベア Pod は、OpenShift Container Platform からはアクセスできなくなります。レプリケーションコントローラーで管理されるベア Pod は、他の利用可能なノードに再スケジュールされます。ローカルのマニフェスト Pod は削除する必要があります。

手順

以下の手順を実行して、ベアメタルで実行されている OpenShift Container Platform クラスターからノードを削除します。

  1. ノードにスケジュール対象外 (unschedulable) のマークを付けます。

    $ oc adm cordon <node_name>
  2. ノード上のすべての Pod をドレイン (解放) します。

    $ oc adm drain <node_name> --force=true

    このステップは、ノードがオフラインまたは応答しない場合に失敗する可能性があります。ノードが応答しない場合でも、共有ストレージに書き込むワークロードを実行している可能性があります。データの破損を防ぐには、続行する前に物理ハードウェアの電源を切ります。

  3. クラスターからノードを削除します。

    $ oc delete node <node_name>

    ノードオブジェクトはクラスターから削除されていますが、これは再起動後や kubelet サービスが再起動される場合にクラスターに再び参加することができます。ノードとそのすべてのデータを永続的に削除するには、ノードの使用を停止する必要があります。

  4. 物理ハードウェアを電源を切っている場合は、ノードがクラスターに再度加わるように、そのハードウェアを再びオンに切り替えます。

7.8.3. 仮想マシンのフェイルオーバーの確認

すべてのリソースが正常でないノードで終了すると、移行した仮想マシンのそれぞれについて、新しい仮想マシンインスタンス (VMI) が正常なノードに自動的に作成されます。VMI が作成されていることを確認するには、oc CLI を使用してすべての VMI を表示します。

7.8.3.1. CLI を使用した仮想マシンインスタンスの一覧表示

oc コマンドラインインターフェース (CLI) を使用して、スタンドアロンおよび仮想マシンによって所有されている VMI を含むすべての仮想マシンの一覧を表示できます。

手順

  • 以下のコマンドを実行して、すべての VMI の一覧を表示します。

    $ oc get vmis

7.9. QEMU ゲストエージェントの仮想マシンへのインストール

QEMU ゲストエージェントは、仮想マシンで実行され、仮想マシン、ユーザー、ファイルシステム、およびセカンダリーネットワークに関する情報をホストに渡すデーモンです。

7.9.1. QEMU ゲストエージェントの Linux 仮想マシンへのインストール

qemu-guest-agent は広く利用されており、Red Hat 仮想マシンでデフォルトで利用できます。このエージェントをインストールし、サービスを起動します。

手順

  1. コンソールのいずれか、または SSH を使用して仮想マシンのコマンドラインにアクセスします。
  2. QEMU ゲストエージェントを仮想マシンにインストールすること。

    $ yum install -y qemu-guest-agent
  3. サービスに永続性があることを確認し、これを起動します。

    $ systemctl enable --now qemu-guest-agent

Web コンソールで仮想マシンまたは仮想マシンテンプレートのいずれかを作成する際に、ウィザードの cloud-init セクションの custom script フィールドを使用して QEMU ゲストエージェントをインストールし、起動することもできます。

7.9.2. QEMU ゲストエージェントの Windows 仮想マシンへのインストール

Windows 仮想マシンの場合、QEMU ゲストエージェントは、以下の手順のいずれかを使用してインストールできる VirtIO ドライバーに含まれています。

7.9.2.1. VirtIO ドライバーの既存 Windows 仮想マシンへのインストール

VirtIO ドライバーを、割り当てられた SATA CD ドライブから既存の Windows 仮想マシンにインストールします。

注記

この手順では、ドライバーを Windows に追加するための汎用的なアプローチを使用しています。このプロセスは Windows のバージョンごとに若干異なる可能性があります。特定のインストール手順については、お使いの Windows バージョンについてのインストールドキュメントを参照してください。

手順

  1. 仮想マシンを起動し、グラフィカルコンソールに接続します。
  2. Windows ユーザーセッションにログインします。
  3. Device Manager を開き、Other devices を拡張して、Unknown device を一覧表示します。

    1. Device Properties を開いて、不明なデバイスを特定します。デバイスを右クリックし、Properties を選択します。
    2. Details タブをクリックし、Property リストで Hardware Ids を選択します。
    3. Hardware IdsValue をサポートされる VirtIO ドライバーと比較します。
  4. デバイスを右クリックし、Update Driver Software を選択します。
  5. Browse my computer for driver software をクリックし、VirtIO ドライバーが置かれている割り当て済みの SATA CD ドライブの場所に移動します。ドライバーは、ドライバーのタイプ、オペレーティングシステム、および CPU アーキテクチャー別に階層的に編成されます。
  6. Next をクリックしてドライバーをインストールします。
  7. 必要なすべての VirtIO ドライバーに対してこのプロセスを繰り返します。
  8. ドライバーのインストール後に、Close をクリックしてウィンドウを閉じます。
  9. 仮想マシンを再起動してドライバーのインストールを完了します。

7.9.2.2. Windows インストール時の VirtIO ドライバーのインストール

Windows のインストール時に割り当てられた SATA CD ドライバーから VirtIO ドライバーをインストールします。

注記

この手順では、Windows インストールの汎用的なアプローチを使用しますが、インストール方法は Windows のバージョンごとに異なる可能性があります。インストールする Windows のバージョンについてのドキュメントを参照してください。

手順

  1. 仮想マシンを起動し、グラフィカルコンソールに接続します。
  2. Windows インストールプロセスを開始します。
  3. Advanced インストールを選択します。
  4. ストレージの宛先は、ドライバーがロードされるまで認識されません。Load driver をクリックします。
  5. ドライバーは SATA CD ドライブとして割り当てられます。OK をクリックし、CD ドライバーでロードするストレージドライバーを参照します。ドライバーは、ドライバーのタイプ、オペレーティングシステム、および CPU アーキテクチャー別に階層的に編成されます。
  6. 必要なすべてのドライバーについて直前の 2 つの手順を繰り返します。
  7. Windows インストールを完了します。

7.10. 仮想マシンの QEMU ゲストエージェント情報の表示

QEMU ゲストエージェントが仮想マシンで実行されている場合は、Web コンソールを使用して、仮想マシン、ユーザー、ファイルシステム、およびセカンダリーネットワークに関する情報を表示できます。

7.10.1. 前提条件

7.10.2. Web コンソールでの QEMU ゲストエージェント情報について

QEMU ゲストエージェントがインストールされると、Virtual Machine Overview タブの Details ペインと、Details タブにホスト名、オペレーティングシステム、タイムゾーン、およびログインユーザーに関する情報が表示されます。

Virtual Machine Overview には、仮想マシンにインストールされたゲストオペレーティングシステムについての情報が表示されます。Details タブには、ログインユーザーの情報が含まれる表が表示されます。Disks タブには、ファイルシステムの情報が含まれる表が表示されます。

注記

QEMU ゲストエージェントがインストールされていない場合、Virtual Machine Overview タブおよび Details タブには、仮想マシンの作成時に指定したオペレーティングシステムについての情報が表示されます。

7.10.3. Web コンソールでの QEMU ゲストエージェント情報の表示

Web コンソールを使用して、QEMU ゲストエージェントによってホストに渡される仮想マシンの情報を表示できます。

手順

  1. サイドメニューから WorkloadsVirtual Machines をクリックします。
  2. Virtual Machines タブをクリックします。
  3. 仮想マシン名を選択して Virtual Machine Overview 画面を開き、Details ペインを表示します。
  4. Logged in users をクリックして、ユーザーについての情報を表示する Details タブを表示します。
  5. Disks タブをクリックして、ファイルシステムについての情報を表示します。

7.11. 仮想マシンでの設定マップ、シークレット、およびサービスアカウントの管理

シークレット、設定マップ、およびサービスアカウントを使用して設定データを仮想マシンに渡すことができます。たとえば、以下を実行できます。

  • シークレットを仮想マシンに追加して認証情報を必要とするサービスに仮想マシンのアクセスを付与します。
  • Pod または別のオブジェクトがデータを使用できるように、機密データではない設定データを設定マップに保存します。
  • サービスアカウントをそのコンポーネントに関連付けることにより、コンポーネントが API サーバーにアクセスできるようにします。
注記

OpenShift Virtualization はシークレット、設定マップ、およびサービスアカウントを仮想マシンディスクとして公開し、追加のオーバーヘッドなしにプラットフォーム全体でそれらを使用できるようにします。

7.11.1. シークレット、設定マップ、またはサービスアカウントの仮想マシンへの追加

OpenShift Container Platform Web コンソールを使用して、シークレット、設定マップ、またはサービスアカウントを仮想マシンに追加します。

前提条件

  • 追加するシークレット、設定マップ、またはサービスアカウントは、ターゲット仮想マシンと同じ namespace に存在する必要がある。

手順

  1. サイドメニューから WorkloadsVirtualization をクリックします。
  2. Virtual Machines タブをクリックします。
  3. 仮想マシンを選択して、Virtual Machine Overview 画面を開きます。
  4. Environment タブをクリックします。
  5. Select a resource をクリックし、一覧からシークレット、設定マップ、またはサービスアカウントを選択します。6 文字のシリアル番号が、選択したリソースについて自動的に生成されます。
  6. Save をクリックします。
  7. オプション。Add Config Map, Secret or Service Account をクリックして別のオブジェクトを追加します。
注記
  1. Reload をクリックし、最後に保存された状態にフォームをリセットできます。
  2. Environment リソースが仮想マシンにディスクとして追加されます。他のディスクをマウントするように、シークレット、設定マップ、またはサービスアカウントをマウントできます。
  3. 仮想マシンが実行中の場合、変更内容は仮想マシンが再起動されるまで反映されません。新規に追加されたリソースは、ページ上部の Pending Changes バナーの Environment および Disks タブの両方に保留中のリソースとしてマークされます。

検証

  1. Virtual Machine Overview ページから、Disks タブをクリックします。
  2. シークレット、設定マップ、またはサービスアカウントがディスクの一覧に含まれていることを確認します。
  3. オプション。変更を適用する適切な方法を選択します。

    1. 仮想マシンが実行されている場合、ActionsRestart Virtual Machine をクリックして仮想マシンを再起動します。
    2. 仮想マシンが停止している場合は、ActionsStart Virtual Machine をクリックして仮想マシンを起動します。

他のディスクをマウントするように、シークレット、設定マップ、またはサービスアカウントをマウントできるようになりました。

7.11.2. 仮想マシンからのシークレット、設定マップ、またはサービスアカウントの削除

OpenShift Container Platform Web コンソールを使用して、シークレット、設定マップ、またはサービスアカウントを仮想マシンから削除します。

前提条件

  • 仮想マシンに割り当てられるシークレット、設定マップ、またはサービスアカウントが少なくとも 1 つ必要である。

手順

  1. サイドメニューから WorkloadsVirtualization をクリックします。
  2. Virtual Machines タブをクリックします。
  3. 仮想マシンを選択して、Virtual Machine Overview 画面を開きます。
  4. Environment タブをクリックします。
  5. 一覧で削除する項目を見つけ、項目の右上にある Remove ボタン delete をクリックします。
  6. Save をクリックします。
注記

Reload をクリックし、最後に保存された状態にフォームをリセットできます。

検証

  1. Virtual Machine Overview ページから、Disks タブをクリックします。
  2. 削除したシークレット、設定マップ、またはサービスアカウントがディスクの一覧に含まれていないことを確認します。

7.11.3. 追加リソース

7.12. VirtIO ドライバーの既存の Windows 仮想マシンへのインストール

7.12.1. VirtIO ドライバーについて

VirtIO ドライバーは、Microsoft Windows 仮想マシンが OpenShift Virtualization で実行されるために必要な準仮想化デバイスドライバーです。サポートされるドライバーは、Red Hat Ecosystem Catalogcontainer-native-virtualization/virtio-win コンテナーディスクで利用できます。

container-native-virtualization/virtio-win コンテナーディスクは、ドライバーのインストールを有効にするために SATA CD ドライブとして仮想マシンに割り当てられる必要があります。仮想マシン上での Windows のインストール時に VirtIO ドライバーをインストールすることも、既存の Windows インストールに追加することもできます。

ドライバーのインストール後に、container-native-virtualization/virtio-win コンテナーディスクは仮想マシンから削除できます。

Installing Virtio drivers on a new Windows virtual machine」も参照してください。

7.12.2. Microsoft Windows 仮想マシンのサポートされる VirtIO ドライバー

表7.3 サポートされるドライバー

ドライバー名ハードウェア ID説明

viostor

VEN_1AF4&DEV_1001
VEN_1AF4&DEV_1042

ブロックドライバー。Other devices グループの SCSI Controller として表示される場合があります。

viorng

VEN_1AF4&DEV_1005
VEN_1AF4&DEV_1044

エントロピーソースドライバー。Other devices グループの PCI Device として表示される場合があります。

NetKVM

VEN_1AF4&DEV_1000
VEN_1AF4&DEV_1041

ネットワークドライバー。Other devices グループの Ethernet Controller として表示される場合があります。VirtIO NIC が設定されている場合にのみ利用できます。

7.12.3. VirtIO ドライバーコンテナーディスクの仮想マシンへの追加

OpenShift Virtualization は、Red Hat Ecosystem Catalog で利用できる Microsoft Windows の VirtIO ドライバーをコンテナーディスクとして配布します。これらのドライバーを Windows 仮想マシンにインストールするには、仮想マシン設定ファイルで container-native-virtualization/virtio-win コンテナーディスクを SATA CD ドライブとして仮想マシンに割り当てます。

前提条件

  • container-native-virtualization/virtio-win コンテナーディスクを Red Hat Ecosystem Catalog からダウンロードすること。コンテナーディスクがクラスターにない場合は Red Hat レジストリーからダウンロードされるため、これは必須ではありません。

手順

  1. container-native-virtualization/virtio-win コンテナーディスクを cdrom ディスクとして Windows 仮想マシン設定ファイルに追加します。コンテナーディスクは、クラスターにない場合はレジストリーからダウンロードされます。

    spec:
      domain:
        devices:
          disks:
            - name: virtiocontainerdisk
              bootOrder: 2 1
              cdrom:
                bus: sata
    volumes:
      - containerDisk:
          image: container-native-virtualization/virtio-win
        name: virtiocontainerdisk
    1
    OpenShift Virtualization は、VirtualMachine 設定ファイルに定義される順序で仮想マシンディスクを起動します。container-native-virtualization/virtio-win コンテナーディスクの前に仮想マシンの他のディスクを定義するか、またはオプションの bootOrder パラメーターを使用して仮想マシンが正しいディスクから起動するようにできます。ディスクに bootOrder を指定する場合、これは設定のすべてのディスクに指定される必要があります。
  2. ディスクは、仮想マシンが起動すると利用可能になります。

    • コンテナーディスクを実行中の仮想マシンに追加する場合、変更を有効にするために CLI で oc apply -f <vm.yaml> を使用するか、または仮想マシンを再起動します。
    • 仮想マシンが実行されていない場合、virtctl start <vm> を使用します。

仮想マシンが起動したら、VirtIO ドライバーを割り当てられた SATA CD ドライブからインストールできます。

7.12.4. VirtIO ドライバーの既存 Windows 仮想マシンへのインストール

VirtIO ドライバーを、割り当てられた SATA CD ドライブから既存の Windows 仮想マシンにインストールします。

注記

この手順では、ドライバーを Windows に追加するための汎用的なアプローチを使用しています。このプロセスは Windows のバージョンごとに若干異なる可能性があります。特定のインストール手順については、お使いの Windows バージョンについてのインストールドキュメントを参照してください。

手順

  1. 仮想マシンを起動し、グラフィカルコンソールに接続します。
  2. Windows ユーザーセッションにログインします。
  3. Device Manager を開き、Other devices を拡張して、Unknown device を一覧表示します。

    1. Device Properties を開いて、不明なデバイスを特定します。デバイスを右クリックし、Properties を選択します。
    2. Details タブをクリックし、Property リストで Hardware Ids を選択します。
    3. Hardware IdsValue をサポートされる VirtIO ドライバーと比較します。
  4. デバイスを右クリックし、Update Driver Software を選択します。
  5. Browse my computer for driver software をクリックし、VirtIO ドライバーが置かれている割り当て済みの SATA CD ドライブの場所に移動します。ドライバーは、ドライバーのタイプ、オペレーティングシステム、および CPU アーキテクチャー別に階層的に編成されます。
  6. Next をクリックしてドライバーをインストールします。
  7. 必要なすべての VirtIO ドライバーに対してこのプロセスを繰り返します。
  8. ドライバーのインストール後に、Close をクリックしてウィンドウを閉じます。
  9. 仮想マシンを再起動してドライバーのインストールを完了します。

7.12.5. 仮想マシンからの VirtIO コンテナーディスクの削除

必要なすべての VirtIO ドライバーを仮想マシンにインストールした後は、container-native-virtualization/virtio-win コンテナーディスクを仮想マシンに割り当てる必要はなくなります。container-native-virtualization/virtio-win コンテナーディスクを仮想マシン設定ファイルから削除します。

手順

  1. 設定ファイルを編集し、disk および volume を削除します。

    $ oc edit vm <vm-name>
    spec:
      domain:
        devices:
          disks:
            - name: virtiocontainerdisk
              bootOrder: 2
              cdrom:
                bus: sata
    volumes:
      - containerDisk:
          image: container-native-virtualization/virtio-win
        name: virtiocontainerdisk
  2. 変更を有効にするために仮想マシンを再起動します。

7.13. VirtIO ドライバーの新規 Windows 仮想マシンへのインストール

7.13.1. 前提条件

7.13.2. VirtIO ドライバーについて

VirtIO ドライバーは、Microsoft Windows 仮想マシンが OpenShift Virtualization で実行されるために必要な準仮想化デバイスドライバーです。サポートされるドライバーは、Red Hat Ecosystem Catalogcontainer-native-virtualization/virtio-win コンテナーディスクで利用できます。

container-native-virtualization/virtio-win コンテナーディスクは、ドライバーのインストールを有効にするために SATA CD ドライブとして仮想マシンに割り当てられる必要があります。仮想マシン上での Windows のインストール時に VirtIO ドライバーをインストールすることも、既存の Windows インストールに追加することもできます。

ドライバーのインストール後に、container-native-virtualization/virtio-win コンテナーディスクは仮想マシンから削除できます。

VirtIO ドライバーの既存の Windows 仮想マシンへのインストール」も参照してください。

7.13.3. Microsoft Windows 仮想マシンのサポートされる VirtIO ドライバー

表7.4 サポートされるドライバー

ドライバー名ハードウェア ID説明

viostor

VEN_1AF4&DEV_1001
VEN_1AF4&DEV_1042

ブロックドライバー。Other devices グループの SCSI Controller として表示される場合があります。

viorng

VEN_1AF4&DEV_1005
VEN_1AF4&DEV_1044

エントロピーソースドライバー。Other devices グループの PCI Device として表示される場合があります。

NetKVM

VEN_1AF4&DEV_1000
VEN_1AF4&DEV_1041

ネットワークドライバー。Other devices グループの Ethernet Controller として表示される場合があります。VirtIO NIC が設定されている場合にのみ利用できます。

7.13.4. VirtIO ドライバーコンテナーディスクの仮想マシンへの追加

OpenShift Virtualization は、Red Hat Ecosystem Catalog で利用できる Microsoft Windows の VirtIO ドライバーをコンテナーディスクとして配布します。これらのドライバーを Windows 仮想マシンにインストールするには、仮想マシン設定ファイルで container-native-virtualization/virtio-win コンテナーディスクを SATA CD ドライブとして仮想マシンに割り当てます。

前提条件

  • container-native-virtualization/virtio-win コンテナーディスクを Red Hat Ecosystem Catalog からダウンロードすること。コンテナーディスクがクラスターにない場合は Red Hat レジストリーからダウンロードされるため、これは必須ではありません。

手順

  1. container-native-virtualization/virtio-win コンテナーディスクを cdrom ディスクとして Windows 仮想マシン設定ファイルに追加します。コンテナーディスクは、クラスターにない場合はレジストリーからダウンロードされます。

    spec:
      domain:
        devices:
          disks:
            - name: virtiocontainerdisk
              bootOrder: 2 1
              cdrom:
                bus: sata
    volumes:
      - containerDisk:
          image: container-native-virtualization/virtio-win
        name: virtiocontainerdisk
    1
    OpenShift Virtualization は、VirtualMachine 設定ファイルに定義される順序で仮想マシンディスクを起動します。container-native-virtualization/virtio-win コンテナーディスクの前に仮想マシンの他のディスクを定義するか、またはオプションの bootOrder パラメーターを使用して仮想マシンが正しいディスクから起動するようにできます。ディスクに bootOrder を指定する場合、これは設定のすべてのディスクに指定される必要があります。
  2. ディスクは、仮想マシンが起動すると利用可能になります。

    • コンテナーディスクを実行中の仮想マシンに追加する場合、変更を有効にするために CLI で oc apply -f <vm.yaml> を使用するか、または仮想マシンを再起動します。
    • 仮想マシンが実行されていない場合、virtctl start <vm> を使用します。

仮想マシンが起動したら、VirtIO ドライバーを割り当てられた SATA CD ドライブからインストールできます。

7.13.5. Windows インストール時の VirtIO ドライバーのインストール

Windows のインストール時に割り当てられた SATA CD ドライバーから VirtIO ドライバーをインストールします。

注記

この手順では、Windows インストールの汎用的なアプローチを使用しますが、インストール方法は Windows のバージョンごとに異なる可能性があります。インストールする Windows のバージョンについてのドキュメントを参照してください。

手順

  1. 仮想マシンを起動し、グラフィカルコンソールに接続します。
  2. Windows インストールプロセスを開始します。
  3. Advanced インストールを選択します。
  4. ストレージの宛先は、ドライバーがロードされるまで認識されません。Load driver をクリックします。
  5. ドライバーは SATA CD ドライブとして割り当てられます。OK をクリックし、CD ドライバーでロードするストレージドライバーを参照します。ドライバーは、ドライバーのタイプ、オペレーティングシステム、および CPU アーキテクチャー別に階層的に編成されます。
  6. 必要なすべてのドライバーについて直前の 2 つの手順を繰り返します。
  7. Windows インストールを完了します。

7.13.6. 仮想マシンからの VirtIO コンテナーディスクの削除

必要なすべての VirtIO ドライバーを仮想マシンにインストールした後は、container-native-virtualization/virtio-win コンテナーディスクを仮想マシンに割り当てる必要はなくなります。container-native-virtualization/virtio-win コンテナーディスクを仮想マシン設定ファイルから削除します。

手順

  1. 設定ファイルを編集し、disk および volume を削除します。

    $ oc edit vm <vm-name>
    spec:
      domain:
        devices:
          disks:
            - name: virtiocontainerdisk
              bootOrder: 2
              cdrom:
                bus: sata
    volumes:
      - containerDisk:
          image: container-native-virtualization/virtio-win
        name: virtiocontainerdisk
  2. 変更を有効にするために仮想マシンを再起動します。

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. 仮想マシンの PXE ブートの設定

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

7.14.2.1. 前提条件

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

7.14.2.2. 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.2.3. 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.2.4. テンプレート: 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. ゲストメモリーの管理

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

警告

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

7.14.3.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.3.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.4. 仮想マシンでの Huge Page の使用

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

7.14.4.1. 前提条件

7.14.4.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.4.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.5. 仮想マシン用の専用リソースの有効化

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

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

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

7.14.5.2. 前提条件

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

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

Web コンソールの Virtual Machine Overview ページで仮想マシンの専用リソースを有効にすることができます。

手順

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

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

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

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

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

ポリシー属性説明

force

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

require

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

optional

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

disable

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

forbid

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

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

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

手順

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

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

7.14.6.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.6.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)。

7.15. 仮想マシンのインポート

7.15.1. データボリュームインポートの TLS 証明書

7.15.1.1. データボリュームインポートの認証に使用する TLS 証明書の追加

ソースからデータをインポートするには、レジストリーまたは HTTPS エンドポイントの TLS 証明書を設定マップに追加する必要があります。この設定マップは、宛先データボリュームの namespace に存在する必要があります。

TLS 証明書の相対パスを参照して設定マップ を作成します。

手順

  1. 正しい namespace にあることを確認します。設定マップは、同じ namespace にある場合にデータボリュームによってのみ参照されます。

    $ oc get ns
  2. 設定マップを作成します。

    $ oc create configmap <configmap-name> --from-file=</path/to/file/ca.pem>

7.15.1.2. 例: TLS 証明書から作成される設定マップ

以下は、ca.pem TLS 証明書で作成される設定マップの例です。

apiVersion: v1
kind: ConfigMap
metadata:
  name: tls-certs
data:
  ca.pem: |
    -----BEGIN CERTIFICATE-----
    ... <base64 encoded cert> ...
    -----END CERTIFICATE-----

7.15.2. データボリュームの使用による仮想マシンイメージのインポート

Containerized Data Importer (CDI) を使用し、データボリュームを使用して仮想マシンイメージを永続ボリューム要求 (PVC) にインポートします。次に、データボリュームを永続ストレージの仮想マシンに割り当てることができます。

仮想マシンイメージは、HTTP または HTTPS エンドポイントでホストするか、またはコンテナーディスクに組み込み、コンテナーレジストリーで保存できます。

重要

ディスクイメージを PVC にインポートする際に、ディスクイメージは PVC で要求されるストレージの全容量を使用するように拡張されます。この領域を使用するには、仮想マシンのディスクパーティションおよびファイルシステムの拡張が必要になる場合があります。

サイズ変更の手順は、仮想マシンにインストールされるオペレーティングシステムによって異なります。詳細は、該当するオペレーティングシステムのドキュメントを参照してください。

7.15.2.1. 前提条件

7.15.2.2. CDI がサポートする操作マトリックス

このマトリックスにはエンドポイントに対してコンテンツタイプのサポートされる CDI 操作が表示されます。これらの操作にはスクラッチ領域が必要です。

コンテンツタイプHTTPHTTPSHTTP Basic 認証レジストリーアップロード

kubevirt (QCOW2)

✓ QCOW2
✓ GZ*
✓ XZ*

✓ QCOW2**
✓ GZ*
✓ XZ*

✓ QCOW2
✓ GZ*
✓ XZ*

✓ QCOW2*
□ GZ
□ XZ

✓ QCOW2*
✓ GZ*
✓ XZ*

KubeVirt (RAW)

✓ RAW
✓ GZ
✓ XZ

✓ RAW
✓ GZ
✓ XZ

✓ RAW
✓ GZ
✓ XZ

✓ RAW*
□ GZ
□ XZ

✓ RAW*
✓ GZ*
✓ XZ*

✓ サポートされる操作

□ サポートされない操作

* スクラッチ領域が必要

**カスタム認証局が必要な場合にスクラッチ領域が必要

7.15.2.3. データボリュームについて

DataVolume オブジェクトは、Containerized Data Importer (CDI) プロジェクトで提供されるカスタムリソースです。データボリュームは、基礎となる永続ボリューム要求 (PVC) に関連付けられるインポート、クローン作成、およびアップロード操作のオーケストレーションを行います。データボリュームは OpenShift Virtualization に統合され、仮想マシンが PVC の作成前に起動することを防ぎます。

7.15.2.4. データボリュームの使用による永続ボリューム要求 (PVC) への仮想マシンイメージのインポート

データボリュームを使用して、仮想マシンイメージを永続ボリューム要求 (PVC) にインポートすることができます。

仮想マシンイメージは、HTTP または HTTPS エンドポイントでホストするか、またはイメージをコンテナーディスクに組み込み、コンテナーレジストリーで保存できます。

インポートされたイメージから仮想マシンを作成するには、仮想マシンを作成する前にイメージまたはコンテナーディスクのエンドポイントを VirtualMachine 設定ファイルに指定します。

前提条件

  • OpenShift CLI (oc) がインストールされていること。
  • クラスターには、少なくとも 1 つの利用可能な永続ボリュームがあること。
  • 仮想マシンイメージをインポートするには、以下が必要である。

    • RAW、ISO、または QCOW2 形式の仮想マシンディスクイメージ (オプションで xz または gz を使用して圧縮される)。
    • イメージがデータソースにアクセスするために必要な認証情報と共にホストされる HTTP エンドポイント。例: http://www.example.com/path/to/data
  • コンテナーディスクをインポートするには、以下が必要である。

    • データソースにアクセスするために必要な認証情報と共に、コンテナーイメージレジストリーに保存されている仮想マシンイメージからビルドされたコンテナーディスク。例: docker://registry.example.com/container-image

手順

  1. オプション: データソースに認証情報が必要な場合、endpoint-secret.yaml ファイルを編集し、更新された設定をクラスターに適用します。

    apiVersion: v1
    kind: Secret
    metadata:
      name: <endpoint-secret>
      labels:
        app: containerized-data-importer
    type: Opaque
    data:
      accessKeyId: "" 1
      secretKey:   "" 2
    1
    オプション: キーまたはユーザー名 (base64 エンコード)
    2
    オプション: シークレットまたはパスワード、base64 エンコード
    $ oc apply -f endpoint-secret.yaml
  2. 仮想マシン設定ファイルを編集し、インポートする必要のある仮想マシンイメージのデータソースを指定します。この例では、http ソースから Fedora イメージがインポートされます。

    apiVersion: kubevirt.io/v1alpha3
    kind: VirtualMachine
    metadata:
      creationTimestamp: null
      labels:
        kubevirt.io/vm: vm-fedora-datavolume
      name: vm-fedora-datavolume
    spec:
      dataVolumeTemplates:
      - metadata:
          creationTimestamp: null
          name: fedora-dv
        spec:
          pvc:
            accessModes:
            - ReadWriteOnce
            resources:
              requests:
                storage: 10Gi
            storageClassName: local
          source:
            http: 1
              url: "https://download.fedoraproject.org/pub/fedora/linux/releases/33/Cloud/x86_64/images/Fedora-Cloud-Base-33-1.2.x86_64.qcow2" 2
              secretRef: "" 3
              certConfigMap: "" 4
        status: {}
      running: true
      template:
        metadata:
          creationTimestamp: null
          labels:
            kubevirt.io/vm: vm-fedora-datavolume
        spec:
          domain:
            devices:
              disks:
              - disk:
                  bus: virtio
                name: datavolumedisk1
            machine:
              type: "" 5
            resources:
              requests:
                memory: 1.5Gi
          terminationGracePeriodSeconds: 60
          volumes:
          - dataVolume:
              name: fedora-dv
            name: datavolumedisk1
    status: {}
    1
    イメージのインポート元となるソースタイプ。この例では、HTTP エンドポイントを使用します。レジストリーからコンテナーディスクをインポートするには、httpregistry に置き換えます。
    2
    インポートする必要のある仮想マシンイメージのソース。この例では、HTTP エンドポイントで仮想マシンイメージを参照します。コンテナーレジストリーエンドポイントのサンプルは url: "docker://kubevirt/fedora-cloud-container-disk-demo:latest" です。
    3
    secretRef パラメーターはオプションです。
    4
    certConfigMap は、自己署名証明書またはシステム CA バンドルで署名されていない証明書を使用するサーバーと通信するために必要です。参照される設定マップはデータボリュームと同じ namespace にある必要があります。
    5
    type: dataVolume または type: "" を指定します。persistentVolumeClaim などの type に他の値を指定すると、警告が表示され、仮想マシンは起動しません。
  3. 仮想マシンを作成します。

    $ oc create -f vm-<name>-datavolume.yaml
    注記

    oc create コマンドは、データボリュームおよび仮想マシンを作成します。CDI コントローラーは適切なアノテーションを使って基礎となる PVC を作成し、インポートプロセスが開始されます。インポートが完了すると、データボリュームのステータスは Succeeded に変更され、仮想マシンの起動が可能になります。

    データボリュームのプロビジョニングはバックグランドで実行されるため、これをモニターする必要はありません。仮想マシンは起動できますが、これはインポートが完了するまで実行されません。

検証

  1. インポーター Pod は指定された URL から仮想マシンイメージまたはコンテナーディスクをダウンロードし、これをプロビジョニングされた PV に保存します。以下のコマンドを実行してインポーター Pod のステータスを確認します。

    $ oc get pods
  2. 以下のコマンドを実行し、Succeeded が表示されるまでデータボリュームのステータスをモニターします。

    $ oc describe dv <datavolume-name> 1
    1
    仮想マシン設定ファイルの dataVolumeTemplates.metadata.name で指定されるデータボリュームの名前。上記の設定例では、これは fedora-dv です。
  3. プロビジョニングが完了し、VMI が起動したことを検証するには、以下のコマンドを実行してそのシリアルコンソールへのアクセスを試行します。

    $ virtctl console <vm-fedora-datavolume>

7.15.3. データボリュームの使用による仮想マシンイメージのブロックストレージへのインポート

既存の仮想マシンイメージは OpenShift Container Platform クラスターにインポートできます。OpenShift Virtualization はデータボリュームを使用してデータのインポートおよび基礎となる永続ボリューム要求 (PVC) の作成を自動化します。

重要

ディスクイメージを PVC にインポートする際に、ディスクイメージは PVC で要求されるストレージの全容量を使用するように拡張されます。この領域を使用するには、仮想マシンのディスクパーティションおよびファイルシステムの拡張が必要になる場合があります。

サイズ変更の手順は、仮想マシンにインストールされるオペレーティングシステムによって異なります。詳細は、該当するオペレーティングシステムのドキュメントを参照してください。

7.15.3.1. 前提条件

7.15.3.2. データボリュームについて

DataVolume オブジェクトは、Containerized Data Importer (CDI) プロジェクトで提供されるカスタムリソースです。データボリュームは、基礎となる永続ボリューム要求 (PVC) に関連付けられるインポート、クローン作成、およびアップロード操作のオーケストレーションを行います。データボリュームは OpenShift Virtualization に統合され、仮想マシンが PVC の作成前に起動することを防ぎます。

7.15.3.3. ブロック永続ボリュームについて

ブロック永続ボリューム (PV) は、raw ブロックデバイスによってサポートされる PV です。これらのボリュームにはファイルシステムがなく、オーバーヘッドを削減することで、仮想マシンのパフォーマンス上の利点をもたらすことができます。

raw ブロックボリュームは、PV および永続ボリューム要求 (PVC) 仕様で volumeMode: Block を指定してプロビジョニングされます。

7.15.3.4. ローカルブロック永続ボリュームの作成

ファイルにデータを設定し、これをループデバイスとしてマウントすることにより、ノードでローカルブロック永続ボリューム (PV) を作成します。次に、このループデバイスを PV マニフェストで Block ボリュームとして参照し、これを仮想マシンイメージのブロックデバイスとして使用できます。

手順

  1. ローカル PV を作成するノードに root としてログインします。この手順では、node01 を例に使用します。
  2. ファイルを作成して、これを null 文字で設定し、ブロックデバイスとして使用できるようにします。以下の例では、2Gb (20 100Mb ブロック) のサイズのファイル loop10 を作成します。

    $ dd if=/dev/zero of=<loop10> bs=100M count=20
  3. loop10 ファイルをループデバイスとしてマウントします。

    $ losetup </dev/loop10>d3 <loop10> 1 2
    1
    ループデバイスがマウントされているファイルパスです。
    2
    前の手順で作成したファイルはループデバイスとしてマウントされます。
  4. マウントされたループデバイスを参照する PersistentVolume マニフェストを作成します。

    kind: PersistentVolume
    apiVersion: v1
    metadata:
      name: <local-block-pv10>
      annotations:
    spec:
      local:
        path: </dev/loop10> 1
      capacity:
        storage: <2Gi>
      volumeMode: Block 2
      storageClassName: local 3
      accessModes:
        - ReadWriteOnce
      persistentVolumeReclaimPolicy: Delete
      nodeAffinity:
        required:
          nodeSelectorTerms:
          - matchExpressions:
            - key: kubernetes.io/hostname
              operator: In
              values:
              - <node01> 4
    1
    ノード上のループデバイスのパス。
    2
    ブロック PV であることを指定します。
    3
    オプション: PV にストレージクラスを設定します。これを省略する場合、クラスターのデフォルトが使用されます。
    4
    ブロックデバイスがマウントされたノード。
  5. ブロック PV を作成します。

    # oc create -f <local-block-pv10.yaml>1
    1
    直前の手順で作成された永続ボリュームのファイル名。

7.15.3.5. データボリュームを使用した仮想マシンイメージのブロック永続ボリュームへのインポート

既存の仮想マシンイメージは OpenShift Container Platform クラスターにインポートできます。OpenShift Virtualization は DataVolume を使用してデータのインポートおよび基礎となる永続ボリューム要求 (PVC) の作成を自動化します。その後、仮想マシンマニフェストでデータボリュームを参照できます。

前提条件

  • RAW、ISO、または QCOW2 形式の仮想マシンディスクイメージ (オプションで xz または gz を使用して圧縮される)
  • データソースにアクセスするために必要な認証情報と共にイメージがホストされる HTTP または s3 エンドポイント
  • 少なくとも 1 つ以上の利用可能なブロック PV。

手順

  1. データソースに認証情報が必要な場合、endpoint-secret.yaml ファイルを編集し、更新された設定をクラスターに適用します。

    1. 選択するテキストエディターで endpoint-secret.yaml ファイルを編集します。

      apiVersion: v1
      kind: Secret
      metadata:
        name: <endpoint-secret>
        labels:
          app: containerized-data-importer
      type: Opaque
      data:
        accessKeyId: "" 1
        secretKey:   "" 2
      1
      オプション: キーまたはユーザー名 (base64 エンコード)
      2
      オプション: シークレットまたはパスワード、base64 エンコード
    2. 以下のコマンドを実行してシークレットを更新します。

      $ oc apply -f endpoint-secret.yaml
  2. インポートするイメージのデータソースを指定する DataVolume マニフェストおよび volumeMode: Block を作成して、利用可能なブロック PV が使用されるようにします。

    apiVersion: cdi.kubevirt.io/v1beta1
    kind: DataVolume
    metadata:
      name: <import-pv-datavolume> 1
    spec:
      storageClassName: local 2
      source:
          http:
             url: <http://download.fedoraproject.org/pub/fedora/linux/releases/28/Cloud/x86_64/images/Fedora-Cloud-Base-28-1.1.x86_64.qcow2> 3
             secretRef: <endpoint-secret> 4
      pvc:
        volumeMode: Block 5
        accessModes:
          - ReadWriteOnce
        resources:
          requests:
            storage: <2Gi>
    1
    データボリュームの名前。
    2
    オプション: ストレージクラスを設定するか、またはこれを省略してクラスターのデフォルトを受け入れます。
    3
    インポートするイメージの HTTP ソース。
    4
    データソースに認証が必要である場合にのみ必要です。
    5
    ブロック PV にインポートするために必要です。
  3. 以下のコマンドを実行して、仮想マシンイメージをインポートするためにデータボリュームを作成します。

    $ oc create -f <import-pv-datavolume.yaml>1
    1
    直前の手順で作成されたデータボリュームのファイル名です。

7.15.3.6. CDI がサポートする操作マトリックス

このマトリックスにはエンドポイントに対してコンテンツタイプのサポートされる CDI 操作が表示されます。これらの操作にはスクラッチ領域が必要です。

コンテンツタイプHTTPHTTPSHTTP Basic 認証レジストリーアップロード

kubevirt (QCOW2)

✓ QCOW2
✓ GZ*
✓ XZ*

✓ QCOW2**
✓ GZ*
✓ XZ*

✓ QCOW2
✓ GZ*
✓ XZ*

✓ QCOW2*
□ GZ
□ XZ

✓ QCOW2*
✓ GZ*
✓ XZ*

KubeVirt (RAW)

✓ RAW
✓ GZ
✓ XZ

✓ RAW
✓ GZ
✓ XZ

✓ RAW
✓ GZ
✓ XZ

✓ RAW*
□ GZ
□ XZ

✓ RAW*
✓ GZ*
✓ XZ*

✓ サポートされる操作

□ サポートされない操作

* スクラッチ領域が必要

**カスタム認証局が必要な場合にスクラッチ領域が必要

7.15.4. 単一の Red Hat Virtualization 仮想マシンのインポート

VM Import ウィザードまたは CLI を使用して、単一の Red Hat Virtualization (RHV) 仮想マシンを OpenShift Virtualization にインポートできます。

7.15.4.1. OpenShift Virtualization ストレージ機能マトリクス

以下の表は、仮想マシンのインポートをサポートする OpenShift Virtualization ストレージタイプについて説明しています。

表7.5 OpenShift Virtualization ストレージ機能マトリクス

 RHV 仮想マシンのインポート

OpenShift Container Storage: RBD ブロックモードボリューム

Yes

OpenShift Virtualization ホストパスプロビジョナー

No

他の複数ノードの書き込み可能なストレージ

はい [1]

他の単一ノードの書き込み可能なストレージ

[2]

  1. PVC は ReadWriteMany アクセスモードを要求する必要があります。
  2. PVC は ReadWriteOnce アクセスモードを要求する必要があります。

7.15.4.2. 仮想マシンをインポートするための前提条件

仮想マシンを Red Hat Virtualization (RHV) から OpenShift Virtualization にインポートするには、以下の前提条件を満たす必要があります。

  • 管理者ユーザー権限があること。
  • ストレージ:

    • OpenShift Virtualization のローカルおよび共有永続ストレージクラスは、仮想マシンのインポートをサポートする必要があります。
    • Ceph RBD ブロックモードのボリュームを使用している場合、ストレージは仮想ディスクに対応するのに十分な大きさである必要があります。ディスクが利用可能なストレージに対して大きすぎると、インポートプロセスが失敗し、仮想ディスクのコピーに使用される PV は解放されません。
  • ネットワーク:

    • RHV および OpenShift Virtualization ネットワークは同じ名前を持つか、または相互にマップされる必要があります。
    • RHV 仮想マシンネットワークインターフェースは e1000rtl8139、または virtio である必要があります。
  • 仮想マシンディスク:

    • ディスクインターフェースは satavirtio_scsi、または virtio である必要があります。
    • ディスクは直接の LUN として設定することはできません。
    • ディスクのステータスは illegal または locked にすることができません。
    • ストレージタイプは image である必要があります。
    • SCSI 予約を無効にする必要があります。
    • ScsiGenericIO を無効にする必要があります。
  • 仮想マシンの設定:

    • 仮想マシンが GPU リソースを使用する場合は、GPU を提供するノードを設定する必要があります。
    • 仮想マシンを vGPU リソース用に設定することはできません。
    • 仮想マシンには、illegal 状態のスナップショットを含めることはできません。
    • 仮想マシンは OpenShift Container Platform で作成されから、その後に RHV に追加することはできません。
    • 仮想マシンを USB デバイス用に設定することはできません。
    • watchdog モデルは diag288 にすることができません。

7.15.4.3. VM Import ウィザードを使用した仮想マシンのインポート

VM Import ウィザードを使用して、単一の仮想マシンをインポートできます。

手順

  1. Web コンソールで、WorkloadsVirtual Machines をクリックします。
  2. Create Virtual Machine をクリックし、Import with Wizard を選択します。
  3. Provider 一覧で Red Hat Virtualization (RHV) を選択します。
  4. Connect to New Instance または保存された RHV インスタンスを選択します。

    • Connect to New Instance を選択する場合は、以下のフィールドに入力します。

      • API URL: https://<RHV_Manager_FQDN>/ovirt-engine/api など。
      • CA certificate: Browse をクリックして RHV Manager CA 証明書をアップロードするか、またはフィールドに CA 証明書を貼り付けます。

        以下のコマンドを実行して CA 証明書を表示します。

        $ openssl s_client -connect <RHV_Manager_FQDN>:443 -showcerts < /dev/null

        CA 証明書は、出力内の 2 番目の証明書です。

      • Username: RHV Manager ユーザー名 (例: ocpadmin@internal)
      • Password: RHV Manager パスワード
    • 保存された RHV インスタンスを選択する場合、ウィザードは保存された認証情報を使用して RHV インスタンスに接続します。
  5. Check and Save をクリックし、接続が完了するまで待ちます。

    注記

    接続の詳細はシークレットに保存されます。正しくない URL、ユーザー名またはパスワードを使用してプロバイダーを追加する場合、WorkloadsSecrets をクリックし、プロバイダーのシークレットを削除します。

  6. クラスターおよび仮想マシンを選択します。
  7. Next をクリックします。
  8. Review 画面で、設定を確認します。
  9. オプション:Start virtual machine on creation を選択します。
  10. Edit をクリックして、以下の設定を更新します。

    • GeneralName: 仮想マシン名は 63 文字に制限されます。
    • GeneralDescription: 仮想マシンの説明 (オプション)。

      • Storage Class: NFS または ocs-storagecluster-ceph-rbd を選択します。

        ocs-storagecluster-ceph-rbd を選択する場合、ディスクの Volume ModeBlock に設定する必要があります。

      • AdvancedVolume Mode: Block を選択します。
    • AdvancedVolume Mode: Block を選択します。
    • NetworkingNetwork: 利用可能なネットワーク割り当て定義オブジェクトの一覧からネットワークを選択できます。
  11. インポート設定を編集した場合は、Import または Review and Import をクリックします。

    Successfully created virtual machine というメッセージが表示され、仮想マシンに作成されたリソースの一覧が表示されます。仮想マシンが WorkloadsVirtual Machines に表示されます。

仮想マシンウィザードのフィールド
名前パラメーター説明

Template

 

仮想マシンの作成に使用するテンプレート。テンプレートを選択すると、他のフィールドが自動的に入力されます。

ソース

PXE

PXE メニューから仮想マシンをプロビジョニングします。クラスターに PXE 対応の NIC が必要になります。

URL

HTTP または S3 エンドポイントで利用できるイメージから仮想マシンをプロビジョニングします。

コンテナー

クラスターからアクセスできるレジストリーの起動可能なオペレーティングシステムコンテナーから仮想マシンをプロビジョニングします。例: kubevirt/cirros-registry-disk-demo

Disk

ディスクから仮想マシンをプロビジョニングします。

Operating System

 

仮想マシン用に選択される主なオペレーティングシステム。

Flavor

small、medium、large、tiny、Custom

仮想マシンに割り当てられる CPU およびメモリーの量を決定するプリセット。Flavor に設定される Preset はオペレーティングシステムによって決まります。

Memory

 

仮想マシンに割り当てられるメモリーのサイズ (GiB 単位)。

CPU

 

仮想マシンに割り当てられる CPU の量。

Workload Profile

High Performance

高パフォーマンスのワークロードに対して最適化された仮想マシン設定。

Server

サーバーワークロードの実行に最適化されたプロファイル。

Desktop

デスクトップで使用するための仮想マシン設定。

名前

 

この名前には、小文字 (a-z)、数字 (0-9)、およびハイフン (-) を含めることができ、最大 253 文字を使用できます。最初と最後の文字は英数字にする必要があります。この名前には、大文字、スペース、ピリオド (.)、または特殊文字を使用できません。

説明

 

オプションの説明フィールド。

Start virtual machine on creation

 

これを選択すると、作成時に仮想マシンが自動的に起動します。

ネットワークフィールド
名前説明

名前

ネットワークインターフェースの名前。

Model

ネットワークインターフェースカードのモデルを示します。サポートされる値は e1000e および virtio です。

Network

利用可能なネットワーク接続定義の一覧。

Type

利用可能なバインディングメソッドの一覧。デフォルトの Pod ネットワークについては、masquerade が唯一の推奨されるバインディングメソッドになります。セカンダリーネットワークの場合は、 bridge バインディングメソッドを使用します。masquerade メソッドは、デフォルト以外のネットワークではサポートされません。

MAC Address

ネットワークインターフェースの MAC アドレス。MAC アドレスが指定されていない場合、セッションの一時アドレスが生成されます。

ストレージフィールド
名前説明

ソース

仮想マシンの空のディスクを選択するか、または URLContainerAttach Cloned Disk、または Attach Disk などの選択可能なオプションから選択します。既存ディスクを選択し、これを仮想マシンに割り当てるには、利用可能な Persistent Volume Claim (永続ボリューム要求、PVC) の一覧から Attach Cloned Disk または Attach Disk を選択します。

名前

ディスクの名前。この名前には、小文字 (a-z)、数字 (0-9)、ハイフン (-) およびピリオド (.) を含めることができ、最大 253 文字を使用できます。最初と最後の文字は英数字にする必要があります。この名前には、大文字、スペース、または特殊文字を使用できません。

Size (GiB)

ディスクのサイズ (GiB)。

Interface

ディスクデバイスのタイプ。サポートされるインターフェースは、virtIOSATA、および SCSI です。

Storage Class

ディスクの作成に使用されるストレージクラス。

Advanced → Volume Mode

永続ボリュームがフォーマットされたファイルシステムまたは raw ブロック状態を使用するかどうかを定義します。デフォルトは Filesystem です。

ストレージの詳細設定
名前パラメーター説明

ボリュームモード

Filesystem

ファイルシステムベースのボリュームで仮想ディスクを保存します。

Block

ブロックボリュームで仮想ディスクを直接保存します。基礎となるストレージがサポートしている場合は、 Block を使用します。

アクセスモード [1]

Single User (RWO)

ディスクは単一ノードで読み取り/書き込みとしてマウントできます。

Shared Access (RWX)

ディスクは数多くのノードで読み取り/書き込みとしてマウントできます。

Read Only (ROX)

ディスクは数多くのノードで読み取り専用としてマウントできます。

  1. コマンドラインインターフェースを使用してアクセスモードを変更できます。

7.15.4.4. CLI を使用した仮想マシンのインポート

Secret および VirtualMachineImport カスタムリソース (CR) を作成して、CLI で仮想マシンをインポートできます。Secret CR は RHV Manager の認証情報および CA 証明書を保存します。VirtualMachineImport CR は仮想マシンのインポートプロセスのパラメーターを定義します。

オプション: VirtualMachineImport CR とは別に ResourceMapping CR を作成できます。ResourceMapping CR は、追加の RHV 仮想マシンをインポートする場合などに柔軟性を提供します。

重要

デフォルトのターゲットストレージクラスは NFS である必要があります。Cinder は RHV 仮想マシンのインポートをサポートしません。

手順

  1. 以下のコマンドを実行して Secret CR を作成します。

    $ cat <<EOF | oc create -f -
    apiVersion: v1
    kind: Secret
    metadata:
      name: rhv-credentials
      namespace: default 1
    type: Opaque
    stringData:
      ovirt: |
        apiUrl: <api_endpoint> 2
        username: ocpadmin@internal
        password: 3
        caCert: |
          -----BEGIN CERTIFICATE-----
          4
          -----END CERTIFICATE-----
    EOF
    1
    オプション。すべての CR に異なる namespace を指定できます。
    2
    RHV Manager の API エンドポイントを指定します(例: \"https://www.example.com:8443/ovirt-engine/api")。
    3
    ocpadmin@internal のパスワードを指定します。
    4
    RHV Manager CA 証明書を指定します。以下のコマンドを実行して CA 証明書を取得できます。
    $ openssl s_client -connect :443 -showcerts < /dev/null
  2. オプション: 以下のコマンドを実行して、リソースマッピングを VirtualMachineImport CR から分離する必要がある場合に ResourceMapping を作成します。

    $ cat <<EOF | kubectl create -f -
    apiVersion: v2v.kubevirt.io/v1alpha1
    kind: ResourceMapping
    metadata:
      name: resourcemapping_example
      namespace: default
    spec:
      ovirt:
        networkMappings:
          - source:
              name: <rhv_logical_network>/<vnic_profile> 1
            target:
              name: <target_network> 2
            type: pod
        storageMappings: 3
          - source:
              name: <rhv_storage_domain> 4
            target:
              name: <target_storage_class> 5
            volumeMode: <volume_mode> 6
    EOF
    1
    RHV の論理ネットワークおよび vNIC プロファイルを指定します。
    2
    OpenShift Virtualization ネットワークを指定します。
    3
    ストレージマッピングが ResourceMapping および VirtualMachineImport CR の両方に指定される場合、VirtualMachineImport CR が優先されます。
    4
    RHV ストレージドメインを指定します。
    5
    nfs または ocs-storagecluster-ceph-rbd を指定します。
    6
    ocs-storagecluster-ceph-rbd ストレージクラスを指定した場合、Block をボリュームモードとして指定する必要があります。
  3. 以下のコマンドを実行して VirtualMachineImport CR を作成します。

    $ cat <<EOF | oc create -f -
    apiVersion: v2v.kubevirt.io/v1beta1
    kind: VirtualMachineImport
    metadata:
      name: vm-import
      namespace: default
    spec:
      providerCredentialsSecret:
        name: rhv-credentials
        namespace: default
    # resourceMapping: 1
    #   name: resourcemapping-example
    #   namespace: default
      targetVmName: vm_example 2
      startVm: true
      source:
        ovirt:
          vm:
            id: <source_vm_id> 3
            name: <source_vm_name> 4
          cluster:
            name: <source_cluster_name> 5
          mappings: 6
            networkMappings:
              - source:
                  name: <source_logical_network>/<vnic_profile> 7
                target:
                  name: <target_network> 8
                type: pod
            storageMappings: 9
              - source:
                  name: <source_storage_domain> 10
                target:
                  name: <target_storage_class> 11
                accessMode: <volume_access_mode> 12
            diskMappings:
              - source:
                  id: <source_vm_disk_id> 13
                target:
                  name: <target_storage_class> 14
    EOF
    1
    ResourceMapping CR を作成する場合、resourceMapping セクションのコメントを解除します。
    2
    ターゲットの仮想マシン名を指定します。
    3
    ソース仮想マシン ID を指定します (例: 80554327-0569-496b-bdeb-fcbbf52b827b)。Manager マシンの Web ブラウザーで https://www.example.com/ovirt-engine/api/vms/ を入力して仮想マシン ID を取得し、すべての仮想マシンを一覧表示できます。インポートする仮想マシンとその対応する仮想マシン ID を見つけます。仮想マシン名またはクラスター名を指定する必要はありません。
    4
    ソース仮想マシン名を指定する場合、ソースクラスターも指定する必要があります。ソース仮想マシン ID は指定しないでください。
    5
    ソースクラスターを指定する場合、ソース仮想マシン名も指定する必要があります。ソース仮想マシン ID は指定しないでください。
    6
    ResourceMapping CR を作成する場合、mappings セクションをコメントアウトします。
    7
    ソース仮想マシンの論理ネットワークおよび vNIC プロファイルを指定します。
    8
    OpenShift Virtualization ネットワークを指定します。
    9
    ストレージマッピングが ResourceMapping および VirtualMachineImport CR の両方に指定される場合、VirtualMachineImport CR が優先されます。
    10
    ソースストレージドメインを指定します。
    11
    ターゲットストレージクラスを指定します。
    12
    ReadWriteOnceReadWriteMany、または ReadOnlyMany を指定します。アクセスモードが指定されていない場合、{virt} は RHV 仮想マシンまたは仮想ディスクアクセスモード上の HostMigration mode 設定に基づいて正しいボリュームアクセスモードを判別します。
    • RHV 仮想マシン移行モードが Allow manual and automatic migration の場合、デフォルトのアクセスモードは ReadWriteMany になります。
    • RHV 仮想ディスクのアクセスモードが ReadOnly の場合、デフォルトのアクセスモードは ReadOnlyMany になります。
    • その他のすべての設定では、デフォルトのアクセスモードは ReadWriteOnce です。
    13
    ソース仮想マシンディスク ID を指定します (例: 8181ecc1-5db8-4193-9c92-3ddab3be7b05)。Manager マシンの Web ブラウザーで https://www.example.com/ovirt-engine/api/vms/vm23 を入力して仮想マシンの詳細を確認し、ディスク ID 取得できます。
    14
    ターゲットストレージクラスを指定します。
  4. 仮想マシンインポートの進捗に従い、インポートが正常に完了したことを確認します。

    $ oc get vmimports vm-import -n default

    インポートが成功したことを示す出力は、以下のようになります。

    出力例

    ...
    status:
      conditions:
      - lastHeartbeatTime: "2020-07-22T08:58:52Z"
        lastTransitionTime: "2020-07-22T08:58:52Z"
        message: Validation completed successfully
        reason: ValidationCompleted
        status: "True"
        type: Valid
      - lastHeartbeatTime: "2020-07-22T08:58:52Z"
        lastTransitionTime: "2020-07-22T08:58:52Z"
        message: 'VM specifies IO Threads: 1, VM has NUMA tune mode specified: interleave'
        reason: MappingRulesVerificationReportedWarnings
        status: "True"
        type: MappingRulesVerified
      - lastHeartbeatTime: "2020-07-22T08:58:56Z"
        lastTransitionTime: "2020-07-22T08:58:52Z"
        message: Copying virtual machine disks
        reason: CopyingDisks
        status: "True"
        type: Processing
      dataVolumes:
      - name: fedora32-b870c429-11e0-4630-b3df-21da551a48c0
      targetVmName: fedora32

7.15.4.4.1. 仮想マシンをインポートするための設定マップの作成

デフォルトの vm-import-controller マッピングを上書きする場合や、追加のマッピングを追加する場合は、Red Hat Virtualization (RHV) 仮想マシンオペレーティングシステムを OpenShift Virtualization テンプレートにマップする設定マップを作成できます。

デフォルトの vm-import-controller 設定マップには、以下の RHV オペレーティングシステムおよびそれらの対応する共通の OpenShift Virtualization テンプレートが含まれます。

表7.6 オペレーティングシステムおよびテンプレートのマッピング

RHV 仮想マシンオペレーティングシステムOpenShift Virtualization テンプレート

rhel_6_9_plus_ppc64

rhel6.9

rhel_6_ppc64

rhel6.9

rhel_6

rhel6.9

rhel_6x64

rhel6.9

rhel_7_ppc64

rhel7.7

rhel_7_s390x

rhel7.7

rhel_7x64

rhel7.7

rhel_8x64

rhel8.1

sles_11_ppc64

opensuse15.0

sles_11

opensuse15.0

sles_12_s390x

opensuse15.0

ubuntu_12_04

ubuntu18.04

ubuntu_12_10

ubuntu18.04

ubuntu_13_04

ubuntu18.04

ubuntu_13_10

ubuntu18.04

ubuntu_14_04_ppc64

ubuntu18.04

ubuntu_14_04

ubuntu18.04

ubuntu_16_04_s390x

ubuntu18.04

windows_10

win10

windows_10x64

win10

windows_2003

win10

windows_2003x64

win10

windows_2008R2x64

win2k8

windows_2008

win2k8

windows_2008x64

win2k8

windows_2012R2x64

win2k12r2

windows_2012x64

win2k12r2

windows_2016x64

win2k16

windows_2019x64

win2k19

windows_7

win10

windows_7x64

win10

windows_8

win10

windows_8x64

win10

windows_xp

win10

手順

  1. Web ブラウザーで、http://<RHV_Manager_FQDN>/ovirt-engine/api/vms/<VM_ID> に移動して RHV 仮想マシンオペレーティングシステムの REST API 名を特定します。以下の例のように、オペレーティングシステム名が XML 出力の <os> セクションに表示されます。

    ...
    <os>
    ...
    <type>rhel_8x64</type>
    </os>
  2. 利用可能な OpenShift Virtualization テンプレートの一覧を表示します。

    $ oc get templates -n openshift --show-labels | tr ',' '\n' | grep os.template.kubevirt.io | sed -r 's#os.template.kubevirt.io/(.*)=.*#\1#g' | sort -u

    出力例

    fedora31
    fedora32
    ...
    rhel8.1
    rhel8.2
    ...

  3. RHV 仮想マシンオペレーティングシステムに一致する OpenShift Virtualization テンプレートが利用可能なテンプレートの一覧に表示されない場合は、OpenShift Virtualization Web コンソールでテンプレートを作成します。
  4. RHV 仮想マシンオペレーティングシステムを OpenShift Virtualization テンプレートにマップするために設定マップを作成します。

    $ cat <<EOF | oc create -f -
    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: os-configmap
      namespace: default 1
    data:
      guestos2common: |
        "Red Hat Enterprise Linux Server": "rhel"
        "CentOS Linux": "centos"
        "Fedora": "fedora"
        "Ubuntu": "ubuntu"
        "openSUSE": "opensuse"
      osinfo2common: |
        "<rhv-operating-system>": "<vm-template>" 2
    EOF
    1
    オプション: namespace パラメーターの値を変更できます。
    2
    以下の例のように、RHV オペレーティングシステムおよび対応する仮想マシンテンプレートの REST API 名を指定します。

    設定マップの例

    $ cat <<EOF | oc apply -f -
    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: os-configmap
      namespace: default
    data:
      osinfo2common: |
        "other_linux": "fedora31"
    EOF

  5. カスタム設定マップが作成されていることを確認します。

    $ oc get cm -n default os-configmap -o yaml
  6. vm-import-controller-config 設定マップにパッチを適用し、新規設定マップを適用します。

    $ oc patch configmap vm-import-controller-config -n openshift-cnv --patch '{
        "data": {
            "osConfigMap.name": "os-configmap",
            "osConfigMap.namespace": "default" 1
        }
    }'
    1
    設定マップで namespace を変更した場合は、namespace を更新します。
  7. テンプレートが OpenShift Virtualization Web コンソールに表示されることを確認します。

    1. サイドメニューから WorkloadsVirtualization をクリックします。
    2. Virtual Machine Templates タブをクリックして、一覧でテンプレートを見つけます。

7.15.4.5. 仮想マシンのインポートのトラブルシューティング

7.15.4.5.1. ログ

VM Import Controller Pod ログでエラーの有無を確認できます。

手順

  1. 以下のコマンドを実行して、VM Import Controller Pod 名を表示します。

    $ oc get pods -n <namespace> | grep import 1
    1
    インポートされた仮想マシンの namespace を指定します。

    出力例

    vm-import-controller-f66f7d-zqkz7            1/1     Running     0          4h49m

  2. 以下のコマンドを実行して、VM Import Controller Pod ログを表示します。

    $ oc logs <vm-import-controller-f66f7d-zqkz7> -f -n <namespace> 1
    1
    VM Import Controller Pod 名および namespace を指定します。
7.15.4.5.2. エラーメッセージ

以下のエラーメッセージが表示される場合があります。

  • 以下のエラーメッセージが VM Import Controller Pod ログに表示され、OpenShift Virtualization ストレージ PV が適切でない場合は進捗バーは 10% で停止します。

    Failed to bind volumes: provisioning failed for PVC

    互換性のあるストレージクラスを使用する必要があります。Cinder ストレージクラスはサポートされません。

7.15.4.5.3. 既知の問題
  • Ceph RBD ブロックモードのボリュームを使用していて、仮想ディスクに利用可能なストレージ領域が小さすぎると、インポートプロセスバーは 75% で 20 分以上停止し、移行は成功しません。Web コンソールにエラーメッセージは表示されません。BZ#1910019

7.15.5. 単一 VMware 仮想マシンまたはテンプレートのインポート

VM Import ウィザードを使用して、VMware vSphere 6.5、6.7、または 7.0 の仮想マシンまたは仮想マシンテンプレートを OpenShift Virtualization にインポートできます。

VM テンプレートをインポートする場合、OpenShift Virtualization はテンプレートに基づいて仮想マシンを作成します。

7.15.5.1. OpenShift Virtualization ストレージ機能マトリクス

以下の表は、仮想マシンのインポートをサポートする OpenShift Virtualization ストレージタイプについて説明しています。

表7.7 OpenShift Virtualization ストレージ機能マトリクス

 VMware VM のインポート

OpenShift Container Storage: RBD ブロックモードボリューム

Yes

OpenShift Virtualization ホストパスプロビジョナー

Yes

他の複数ノードの書き込み可能なストレージ

はい [1]

他の単一ノードの書き込み可能なストレージ

[2]

  1. PVC は ReadWriteMany アクセスモードを要求する必要があります。
  2. PVC は ReadWriteOnce アクセスモードを要求する必要があります。

7.15.5.2. VDDK イメージの作成

インポートプロセスでは、VMware Virtual Disk Development Kit (VDDK) を使用して VMware 仮想ディスクをコピーします。

VDDK SDK をダウンロードし、VDDK イメージを作成し、イメージレジストリーにイメージをアップロードしてからこれを v2v-vmware 設定マップに追加できます。

内部 OpenShift Container Platform イメージレジストリーまたは VDDK イメージのセキュアな外部イメージレジストリーのいずれかを設定できます。レジストリーは OpenShift Virtualization 環境からアクセスできる必要があります。

注記

VDDK イメージをパブリックリポジトリーに保存すると、VMware ライセンスの条件に違反する可能性があります。

7.15.5.2.1. 内部イメージレジストリーの設定

イメージレジストリー Operator 設定を更新して、ベアメタルに内部 OpenShift Container Platform イメージレジストリーを設定できます。

レジストリーをルートで公開して、OpenShift Container Platform クラスターから、または外部からレジストリーに直接アクセスできます。

イメージレジストリーの管理状態の変更

イメージレジストリーを起動するには、イメージレジストリー Operator 設定の managementStateRemoved から Managed に変更する必要があります。

手順

  • ManagementState イメージレジストリー Operator 設定を Removed から Managed に変更します。以下は例になります。

    $ oc patch configs.imageregistry.operator.openshift.io cluster --type merge --patch '{"spec":{"managementState":"Managed"}}'
ベアメタルおよび他の手動インストールの場合のレジストリーストレージの設定

クラスター管理者は、インストール後にレジストリーをストレージを使用できるように設定する必要があります。

前提条件

  • クラスター管理者のパーミッション。
  • ベアメタルなどの、手動でプロビジョニングされた Red Hat Enterprise Linux CoreOS (RHCOS) ノードを使用するクラスター。
  • Red Hat OpenShift Container Storage などのクラスターのプロビジョニングされた永続ストレージ。

    重要

    OpenShift Container Platform は、1 つのレプリカのみが存在する場合にイメージレジストリーストレージの ReadWriteOnce アクセスをサポートします。2 つ以上のレプリカで高可用性をサポートするイメージレジストリーをデプロイするには、ReadWriteMany アクセスが必要です。

  • 100Gi の容量が必要です。

手順

  1. レジストリーをストレージを使用できるように設定するには、configs.imageregistry/cluster リソースの spec.storage.pvc を変更します。

    注記

    共有ストレージを使用する場合は、外部からアクセスを防ぐためにセキュリティー設定を確認します。

  2. レジストリー Pod がないことを確認します。

    $ oc get pod -n openshift-image-registry
    注記

    ストレージタイプが emptyDIR の場合、レプリカ数が 1 を超えることはありません。

  3. レジストリー設定を確認します。

    $ oc edit configs.imageregistry.operator.openshift.io

    出力例

    storage:
      pvc:
        claim:

    claim フィールドを空のままにし、image-registry-storage PVC の自動作成を可能にします。

  4. clusteroperator ステータスを確認します。

    $ oc get clusteroperator image-registry
  5. イメージのビルドおよびプッシュを有効にするためにレジストリーが managed に設定されていることを確認します。

    • 以下を実行します。

      $ oc edit configs.imageregistry/cluster

      次に、行を変更します。

      managementState: Removed

      次のように変更してください。

      managementState: Managed
クラスターからレジストリーへの直接アクセス

クラスター内からレジストリーにアクセスすることができます。

手順

内部ルートを使用して、クラスターからレジストリーにアクセスします。

  1. ノードのアドレスを取得することにより、ノードにアクセスします。

    $ oc get nodes
    $ oc debug nodes/<node_address>
  2. ノード上で ocpodman などのツールへのアクセスを有効にするには、以下のコマンドを実行します。

    sh-4.2# chroot /host
  3. アクセストークンを使用してコンテナーイメージレジストリーにログインします。

    sh-4.2# oc login -u kubeadmin -p <password_from_install_log> https://api-int.<cluster_name>.<base_domain>:6443
    sh-4.2# podman login -u kubeadmin -p $(oc whoami -t) image-registry.openshift-image-registry.svc:5000

    以下のようなログインを確認するメッセージが表示されるはずです。

    Login Succeeded!
    注記

    ユーザー名には任意の値を指定でき、トークンには必要な情報がすべて含まれます。コロンが含まれるユーザー名を指定すると、ログインに失敗します。

    イメージレジストリー Operator はルートを作成するため、 default-route-openshift-image-registry.<cluster_name> のようになります。

  4. レジストリーに対して podman pull および podman push 操作を実行します。

    重要

    任意のイメージをプルできますが、system:registry ロールを追加している場合は、各自のプロジェクトにあるレジストリーにのみイメージをプッシュすることができます。

    次の例では、以下を使用します。

    コンポーネント

    <registry_ip>

    172.30.124.220

    <port>

    5000

    <project>

    openshift

    <image>

    image

    <tag>

    省略 (デフォルトは latest)

    1. 任意のイメージをプルします。

      $ podman pull name.io/image
    2. 新規イメージに <registry_ip>:<port>/<project>/<image> 形式でタグ付けします。プロジェクト名は、イメージを正しくレジストリーに配置し、これに後でアクセスできるようにするために OpenShift Container Platform のプル仕様に表示される必要があります。

      $ podman tag name.io/image image-registry.openshift-image-registry.svc:5000/openshift/image
      注記

      指定されたプロジェクトについて system:image-builder ロールを持っている必要があります。このロールにより、ユーザーはイメージの書き出しやプッシュを実行できます。そうでない場合は、次の手順の podman push は失敗します。これをテストするには、新規プロジェクトを作成し、イメージをプッシュできます。

    3. 新しくタグ付けされたイメージをレジストリーにプッシュします。

      $ podman push image-registry.openshift-image-registry.svc:5000/openshift/image
セキュアなレジストリーの手動による公開

クラスター内から OpenShift Container Platform レジストリーにログインするのではなく、外部からレジストリーにアクセスできるように、このレジストリーをルートに公開します。これにより、ルートアドレスを使用してクラスターの外部からレジストリーにログインし、ルートホストを使用してイメージにタグを付けて既存のプロジェクトにプッシュすることができます。

前提条件:

  • 以下の前提条件は自動的に実行されます。

    • レジストリー Operator のデプロイ。
    • Ingress Operator のデプロイ。

手順

configs.imageregistry.operator.openshift.io リソースで DefaultRoute パラメーターを使用するか、またはカスタムルートを使用してルートを公開することができます。

DefaultRoute を使用してレジストリーを公開するには、以下を実行します。

  1. DefaultRouteTrue に設定します。

    $ oc patch configs.imageregistry.operator.openshift.io/cluster --patch '{"spec":{"defaultRoute":true}}' --type=merge
  2. podman でログインします。

    $ HOST=$(oc get route default-route -n openshift-image-registry --template='{{ .spec.host }}')
    $ podman login -u kubeadmin -p $(oc whoami -t) --tls-verify=false $HOST 1
    1
    --tls-verify=false は、ルートのクラスターのデフォルト証明書が信頼されない場合に必要になります。Ingress Operator で、信頼されるカスタム証明書をデフォルト証明書として設定できます。

カスタムルートを使用してレジストリーを公開するには、以下を実行します。

  1. ルートの TLS キーでシークレットを作成します。

    $ oc create secret tls public-route-tls \
        -n openshift-image-registry \
        --cert=</path/to/tls.crt> \
        --key=</path/to/tls.key>

    この手順はオプションです。シークレットを作成しない場合、ルートは Ingress Operator からデフォルトの TLS 設定を使用します。

  2. レジストリー Operator では、以下のようになります。

    spec:
      routes:
        - name: public-routes
          hostname: myregistry.mycorp.organization
          secretName: public-route-tls
    ...
    注記

    レジストリーのルートのカスタム TLS 設定を指定している場合は secretName のみを設定します。

7.15.5.2.2. 外部イメージレジストリーの設定

VDDK イメージの外部イメージレジストリーを使用する場合、外部イメージレジストリーの認証局を OpenShift Container Platform クラスターに追加できます。

オプションで、Docker 認証情報からプルシークレットを作成し、これをサービスアカウントに追加できます。

クラスターへの認証局の追加

以下の手順でイメージのプッシュおよびプル時に使用する認証局 (CA) をクラスターに追加することができます。

前提条件

  • クラスター管理者の権限があること。
  • レジストリーの公開証明書 (通常は、/etc/docker/certs.d/ ディレクトリーにある hostname/ca.crt ファイル)。

手順

  1. 自己署名証明書を使用するレジストリーの信頼される証明書が含まれる ConfigMapopenshift-config namespace に作成します。それぞれの CA ファイルについて、ConfigMap のキーが hostname[..port] 形式のレジストリーのホスト名であることを確認します。

    $ oc create configmap registry-cas -n openshift-config \
    --from-file=myregistry.corp.com..5000=/etc/docker/certs.d/myregistry.corp.com:5000/ca.crt \
    --from-file=otherregistry.com=/etc/docker/certs.d/otherregistry.com/ca.crt
  2. クラスターイメージの設定を更新します。

    $ oc patch image.config.openshift.io/cluster --patch '{"spec":{"additionalTrustedCA":{"name":"registry-cas"}}}' --type=merge
Pod が他のセキュリティー保護されたレジストリーからイメージを参照できるようにする設定

Docker クライアントの .dockercfg $HOME/.docker/config.json ファイルは、セキュア/非セキュアなレジストリーに事前にログインしている場合に認証情報を保存する Docker 認証情報ファイルです。

OpenShift Container Platform の内部レジストリーにないセキュリティー保護されたコンテナーイメージをプルするには、Docker 認証情報でプルシークレットを作成し、これをサービスアカウントに追加する必要があります。

手順

  • セキュリティー保護されたレジストリーの .dockercfg ファイルがすでにある場合は、以下を実行してそのファイルからシークレットを作成できます。

    $ oc create secret generic <pull_secret_name> \
        --from-file=.dockercfg=<path/to/.dockercfg> \
        --type=kubernetes.io/dockercfg
  • または、$HOME/.docker/config.json ファイルがある場合は以下を実行します。

    $ oc create secret generic <pull_secret_name> \
        --from-file=.dockerconfigjson=<path/to/.docker/config.json> \
        --type=kubernetes.io/dockerconfigjson
  • セキュリティー保護されたレジストリーの Docker 認証情報がない場合は、以下を実行してシークレットを作成できます。

    $ oc create secret docker-registry <pull_secret_name> \
        --docker-server=<registry_server> \
        --docker-username=<user_name> \
        --docker-password=<password> \
        --docker-email=<email>
  • Pod のイメージをプルするためのシークレットを使用するには、そのシークレットをサービスアカウントに追加する必要があります。この例では、サービスアカウントの名前は、Pod が使用するサービスアカウントの名前に一致している必要があります。デフォルトのサービスアカウントは default です。

    $ oc secrets link default <pull_secret_name> --for=pull
7.15.5.2.3. VDDK イメージの作成および使用

VMware Virtual Disk Development Kit (VDDK) をダウンロードして、VDDK イメージをビルドし、VDDK イメージをイメージレジストリーにプッシュできます。VDDK イメージを v2v-vmware 設定マップに追加します。

前提条件

  • OpenShift Container Platform 内部イメージレジストリーまたはセキュアな外部レジストリーにアクセスできる必要がある。

手順

  1. 一時ディレクトリーを作成し、これに移動します。

    $ mkdir /tmp/<dir_name> && cd /tmp/<dir_name>
  2. ブラウザーで VMware code に移動し、SDKs をクリックします。
  3. Compute VirtualizationVirtual Disk Development Kit(VDDK) をクリックします。
  4. VMware vSphere のバージョンに対応する VDDK バージョンを選択します。たとえば、vSphere 7.0 の場合は VDDK 7.0 を選択し、Download をクリックしてから、VDDK アーカイブを一時ディレクトリーに保存します。
  5. VDDK アーカイブを展開します。

    $ tar -xzf VMware-vix-disklib-<version>.x86_64.tar.gz
  6. Dockerfile を作成します。

    $ cat > Dockerfile <<EOF
    FROM busybox:latest
    COPY vmware-vix-disklib-distrib /vmware-vix-disklib-distrib
    RUN mkdir -p /opt
    ENTRYPOINT ["cp", "-r", "/vmware-vix-disklib-distrib", "/opt"]
    EOF
  7. イメージをビルドします。

    $ podman build . -t <registry_route_or_server_path>/vddk:<tag> 1
    1
    イメージレジストリーを指定します。
    • 内部 OpenShift Container Platform レジストリーの場合は、内部レジストリールート (例: image-registry.openshift-image-registry.svc:5000/openshift/vddk:<tag>) を使用します。
    • 外部レジストリーの場合は、サーバー名、パスおよびタグを指定します (例: server.example.com:5000/vddk:<tag>)。
  8. イメージをレジストリーにプッシュします。

    $ podman push <registry_route_or_server_path>/vddk:<tag>
  9. イメージが OpenShift virtualization 環境からアクセスできることを確認します。
  10. openshift-cnv プロジェクトで v2v-vmware 設定マップを編集します。

    $ oc edit configmap v2v-vmware -n openshift-cnv
  11. vddk-init-image パラメーターを data スタンザに追加します。

    ...
    data:
      vddk-init-image: <registry_route_or_server_path>/vddk:<tag>

7.15.5.3. VM Import ウィザードを使用した仮想マシンのインポート

VM Import ウィザードを使用して、単一の仮想マシンをインポートできます。

仮想マシンテンプレートをインポートすることもできます。VM テンプレートをインポートする場合、OpenShift Virtualization はテンプレートに基づいて仮想マシンを作成します。

前提条件

  • 管理者ユーザー権限があること。
  • VMware Virtual Disk Development Kit (VDDK) イメージは、OpenShift Virtualization 環境からアクセスできるイメージレジストリーにある。
  • VDDK イメージは v2v-vmware 設定マップに追加されている。
  • 仮想マシンの電源がオフになっている。
  • 仮想ディスクが IDE または SCSI コントローラーに接続されている。仮想ディスクが SATA コントローラーに接続されている場合は、それらを IDE コントローラーに変更してから、仮想マシンを移行できます。
  • OpenShift Virtualization のローカルおよび共有永続ストレージクラスは、仮想マシンのインポートをサポートする必要があります。
  • OpenShift Virtualization ストレージは、仮想ディスクに対応するのに十分な大きさである。

    警告

    Ceph RBD ブロックモードのボリュームを使用している場合、ストレージは仮想ディスクに対応するのに十分な大きさである必要があります。ディスクが利用可能なストレージに対して大きすぎると、インポートプロセスが失敗し、仮想ディスクのコピーに使用される PV は解放されません。オブジェクトの削除をサポートするためのリソースが十分にないため、別の仮想マシンをインポートしたり、ストレージをクリーンアップしたりすることはできません。この状況を解決するには、ストレージバックエンドにオブジェクトストレージデバイスをさらに追加する必要があります。

  • OpenShift Virtualization egress ネットワークポリシーは以下のトラフィックを許可する必要がある。

    宛先プロトコルポート

    VMware ESXi ホスト

    TCP

    443

    VMware ESXi ホスト

    TCP

    902

    VMware vCenter

    TCP

    5840

手順

  1. Web コンソールで、WorkloadsVirtual Machines をクリックします。
  2. Create Virtual Machine をクリックし、Import with Wizard を選択します。
  3. Provider 一覧から、VMware を選択します。
  4. Connect to New Instance または保存された vCenter インスタンスを選択します。

    • Connect to New Instance を選択する場合、vCenter hostnameUsernamePassword を入力します。
    • 保存された vCenter インスタンスを選択する場合、ウィザードは保存された認証情報を使用して vCenter に接続します。
  5. Check and Save をクリックし、接続が完了するまで待ちます。

    注記

    接続の詳細はシークレットに保存されます。ホスト名、ユーザー名、またはパスワードが正しくないプロバイダーを追加した場合は、WorkloadsSecrets をクリックし、プロバイダーのシークレットを削除します。

  6. 仮想マシンまたはテンプレートを選択します。
  7. Next をクリックします。
  8. Review 画面で、設定を確認します。
  9. Edit をクリックして、以下の設定を更新します。

    • General:

      • 説明
      • オペレーティングシステム
      • Flavor
      • Memory
      • CPU
      • Workload Profile
    • Networking:

      • 名前
      • Model
      • Network
      • Type
      • MAC Address
    • ストレージ: 仮想マシンディスクの Options メニュー kebab をクリックし、Edit を選択して以下のフィールドを更新します。

      • 名前
      • Source: Import Disk など。
      • Size
      • Interface
      • Storage Class: NFS または ocs-storagecluster-ceph-rbd (ceph-rbd) を選択します。

        ocs-storagecluster-ceph-rbd を選択する場合、ディスクの Volume ModeBlock に設定する必要があります。

        他のストレージクラスは機能する可能性がありますが、正式にサポートされていません。

      • AdvancedVolume Mode: Block を選択します。
      • AdvancedAccess Mode
    • AdvancedCloud-init:

      • Form: Hostname および Authenticated SSH Keys を入力します。
      • Custom script: テキストフィールドに cloud-init スクリプトを入力します。
    • AdvancedVirtual Hardware: 仮想 CD-ROM をインポートされた仮想マシンに割り当てることができます。
  10. インポート設定を編集した場合は、Import または Review and Import をクリックします。

    Successfully created virtual machine というメッセージが表示され、仮想マシンに作成されたリソースの一覧が表示されます。仮想マシンが WorkloadsVirtual Machines に表示されます。

仮想マシンウィザードのフィールド
名前パラメーター説明

Template

 

仮想マシンの作成に使用するテンプレート。テンプレートを選択すると、他のフィールドが自動的に入力されます。

ソース

PXE

PXE メニューから仮想マシンをプロビジョニングします。クラスターに PXE 対応の NIC が必要になります。

URL

HTTP または S3 エンドポイントで利用できるイメージから仮想マシンをプロビジョニングします。

コンテナー

クラスターからアクセスできるレジストリーの起動可能なオペレーティングシステムコンテナーから仮想マシンをプロビジョニングします。例: kubevirt/cirros-registry-disk-demo

Disk

ディスクから仮想マシンをプロビジョニングします。

Operating System

 

仮想マシン用に選択される主なオペレーティングシステム。

Flavor

small、medium、large、tiny、Custom

仮想マシンに割り当てられる CPU およびメモリーの量を決定するプリセット。Flavor に設定される Preset はオペレーティングシステムによって決まります。

Memory

 

仮想マシンに割り当てられるメモリーのサイズ (GiB 単位)。

CPU

 

仮想マシンに割り当てられる CPU の量。

Workload Profile

High Performance

高パフォーマンスのワークロードに対して最適化された仮想マシン設定。

Server

サーバーワークロードの実行に最適化されたプロファイル。

Desktop

デスクトップで使用するための仮想マシン設定。

名前

 

この名前には、小文字 (a-z)、数字 (0-9)、およびハイフン (-) を含めることができ、最大 253 文字を使用できます。最初と最後の文字は英数字にする必要があります。この名前には、大文字、スペース、ピリオド (.)、または特殊文字を使用できません。

説明

 

オプションの説明フィールド。

Start virtual machine on creation

 

これを選択すると、作成時に仮想マシンが自動的に起動します。

Cloud-init フィールド
名前説明

Hostname

仮想マシンの特定のホスト名を設定します。

Authenticated SSH Keys

仮想マシンの ~/.ssh/authorized_keys にコピーされるユーザーの公開鍵。

カスタムスクリプト

他のオプションを、カスタム cloud-init スクリプトを貼り付けるフィールドに置き換えます。

ネットワークフィールド
名前説明

名前

ネットワークインターフェースの名前。

Model

ネットワークインターフェースカードのモデルを示します。サポートされる値は e1000e および virtio です。

Network

利用可能なネットワーク接続定義の一覧。

Type

利用可能なバインディングメソッドの一覧。デフォルトの Pod ネットワークについては、masquerade が唯一の推奨されるバインディングメソッドになります。セカンダリーネットワークの場合は、 bridge バインディングメソッドを使用します。masquerade メソッドは、デフォルト以外のネットワークではサポートされません。

MAC Address

ネットワークインターフェースの MAC アドレス。MAC アドレスが指定されていない場合、セッションの一時アドレスが生成されます。

ストレージフィールド
名前説明

ソース

仮想マシンの空のディスクを選択するか、または URLContainerAttach Cloned Disk、または Attach Disk などの選択可能なオプションから選択します。既存ディスクを選択し、これを仮想マシンに割り当てるには、利用可能な Persistent Volume Claim (永続ボリューム要求、PVC) の一覧から Attach Cloned Disk または Attach Disk を選択します。

名前

ディスクの名前。この名前には、小文字 (a-z)、数字 (0-9)、ハイフン (-) およびピリオド (.) を含めることができ、最大 253 文字を使用できます。最初と最後の文字は英数字にする必要があります。この名前には、大文字、スペース、または特殊文字を使用できません。

Size (GiB)

ディスクのサイズ (GiB)。

Interface

ディスクデバイスのタイプ。サポートされるインターフェースは、virtIOSATA、および SCSI です。

Storage Class

ディスクの作成に使用されるストレージクラス。

Advanced → Volume Mode

永続ボリュームがフォーマットされたファイルシステムまたは raw ブロック状態を使用するかどうかを定義します。デフォルトは Filesystem です。

Advanced → Access Mode

永続ボリュームのアクセスモード。サポートされるアクセスモードは ReadWriteOnceReadOnlyMany、および ReadWriteMany です。

ストレージの詳細設定

以下のストレージの詳細設定は、BlankImport via URLURL、および Clone existing PVC ディスクで利用できます。これらのパラメーターはオプションです。これらのパラメーターを指定しない場合、システムは kubevirt-storage-class-defaults 設定マップのデフォルト値を使用します。

名前パラメーター説明

ボリュームモード

Filesystem

ファイルシステムベースのボリュームで仮想ディスクを保存します。

Block

ブロックボリュームで仮想ディスクを直接保存します。基礎となるストレージがサポートしている場合は、 Block を使用します。

アクセスモード

Single User (RWO)

ディスクは単一ノードで読み取り/書き込みとしてマウントできます。

Shared Access (RWX)

ディスクは数多くのノードで読み取り/書き込みとしてマウントできます。

注記

これは、ノード間の仮想マシンのライブマイグレーションなどの、一部の機能で必要になります。

Read Only (ROX)

ディスクは数多くのノードで読み取り専用としてマウントできます。

7.15.5.3.1. インポートされた仮想マシンの NIC 名の更新

VMware からインポートされた仮想マシンの NIC 名を、 OpenShift Virtualization の命名規則に適合するように更新する必要があります。

手順

  1. 仮想マシンにログインします。
  2. /etc/sysconfig/network-scripts ディレクトリーに移動します。
  3. ネットワーク設定ファイルの名前を変更します。

    $ mv vmnic0 ifcfg-eth0 1
    1
    ネットワーク設定ファイルの名前を ifcfg-eth0 に変更します。追加のネットワーク設定ファイルには、ifcfg-eth1ifcfg-eth2 などの番号が順番に付けられます。
  4. ネットワーク設定ファイルで NAME および DEVICE パラメーターを更新します。

    NAME=eth0
    DEVICE=eth0
  5. ネットワークを再起動します。

    $ systemctl restart network

7.15.5.4. 仮想マシンのインポートのトラブルシューティング

7.15.5.4.1. ログ

V2V Conversion Pod ログでエラーの有無を確認できます。

手順

  1. 以下のコマンドを実行して、V2V Conversion Pod 名を表示します。

    $ oc get pods -n <namespace> | grep v2v 1
    1
    インポートされた仮想マシンの namespace を指定します。

    出力例

    kubevirt-v2v-conversion-f66f7d-zqkz7            1/1     Running     0          4h49m

  2. 以下のコマンドを実行して V2V Conversion Pod ログを表示します。

    $ oc logs <kubevirt-v2v-conversion-f66f7d-zqkz7> -f -n <namespace> 1
    1
    VM Conversion Pod 名および namespace を指定します。
7.15.5.4.2. エラーメッセージ

以下のエラーメッセージが表示される場合があります。

  • インポート前に VMware 仮想マシンがシャットダウンされない場合、OpenShift Container Platform コンソールのインポートされた仮想マシンにはエラーメッセージ Readiness probe failed が表示され、V2V Conversion Pod ログには以下のエラーメッセージが表示されます。

    INFO - have error: ('virt-v2v error: internal error: invalid argument: libvirt domain ‘v2v_migration_vm_1’ is running or paused. It must be shut down in order to perform virt-v2v conversion',)"
  • 管理者以外のユーザーが仮想マシンのインポートを試みると、以下のエラーメッセージが OpenShift Container Platform コンソールに表示されます。

    Could not load config map vmware-to-kubevirt-os in kube-public namespace
    Restricted Access: configmaps "vmware-to-kubevirt-os" is forbidden: User cannot get resource "configmaps" in API group "" in the namespace "kube-public"

    仮想マシンをインポートできるのは、管理者ユーザーのみです。

7.16. 仮想マシンのクローン作成

7.16.1. 複数の namespace 間でデータボリュームをクローン作成するためのユーザーパーミッションの有効化

namespace には相互に分離する性質があるため、ユーザーはデフォルトでは namespace をまたがってリソースのクローンを作成することができません。

ユーザーが仮想マシンのクローンを別の namespace に作成できるようにするには、cluster-admin ロールを持つユーザーが新規のクラスターロールを作成する必要があります。このクラスターロールをユーザーにバインドし、それらのユーザーが仮想マシンのクローンを宛先 namespace に対して作成できるようにします。

7.16.1.1. 前提条件

  • cluster-admin ロールを持つユーザーのみがクラスターロールを作成できます。

7.16.1.2. データボリュームについて

DataVolume オブジェクトは、Containerized Data Importer (CDI) プロジェクトで提供されるカスタムリソースです。データボリュームは、基礎となる永続ボリューム要求 (PVC) に関連付けられるインポート、クローン作成、およびアップロード操作のオーケストレーションを行います。データボリュームは OpenShift Virtualization に統合され、仮想マシンが PVC の作成前に起動することを防ぎます。

7.16.1.3. データボリュームのクローン作成のための RBAC リソースの作成

datavolumes リソースのすべてのアクションのパーミッションを有効にする新規のくスターロールを作成します。

手順

  1. ClusterRole マニフェストを作成します。

    apiVersion: rbac.authorization.k8s.io/v1
    kind: ClusterRole
    metadata:
      name: <datavolume-cloner> 1
    rules:
    - apiGroups: ["cdi.kubevirt.io"]
      resources: ["datavolumes/source"]
      verbs: ["*"]
    1
    クラスターロールの一意の名前。
  2. クラスターにクラスターロールを作成します。

    $ oc create -f <datavolume-cloner.yaml> 1
    1
    直前の手順で作成された ClusterRole マニフェストのファイル名です。
  3. 移行元および宛先 namespace の両方に適用される RoleBinding マニフェストを作成し、直前の手順で作成したクラスターロールを参照します。

    apiVersion: rbac.authorization.k8s.io/v1
    kind: RoleBinding
    metadata:
      name: <allow-clone-to-user> 1
      namespace: <Source namespace> 2
    subjects:
    - kind: ServiceAccount
      name: default
      namespace: <Destination namespace> 3
    roleRef:
      kind: ClusterRole
      name: datavolume-cloner 4
      apiGroup: rbac.authorization.k8s.io
    1
    ロールバインディングの一意の名前。
    2
    ソースデータボリュームの namespace。
    3
    データボリュームのクローンが作成される namespace。
    4
    直前の手順で作成したクラスターロールの名前。
  4. クラスターにロールバインディングを作成します。

    $ oc create -f <datavolume-cloner.yaml> 1
    1
    直前の手順で作成された RoleBinding マニフェストのファイル名です。

7.16.2. 新規データボリュームへの仮想マシンディスクのクローン作成

データボリューム設定ファイルでソース PVC を参照し、新規データボリュームに仮想マシンディスクの永続ボリューム要求 (PVC) のクローンを作成できます。

警告

異なるボリュームモード間でのクローン作成操作はサポートされていません。volumeMode の値は、ソースとターゲットの両方の仕様で一致している必要があります。

たとえば、volumeMode: Block の永続ボリューム (PV) から volumeMode: Filesystem の PV へのクローン作成を試行する場合、操作はエラーメッセージを出して失敗します。

7.16.2.1. 前提条件

  • ユーザーは、仮想マシンディスクの PVC のクローンを別の namespace に作成するために 追加のパーミッションが必要です。

7.16.2.2. データボリュームについて

DataVolume オブジェクトは、Containerized Data Importer (CDI) プロジェクトで提供されるカスタムリソースです。データボリュームは、基礎となる永続ボリューム要求 (PVC) に関連付けられるインポート、クローン作成、およびアップロード操作のオーケストレーションを行います。データボリュームは OpenShift Virtualization に統合され、仮想マシンが PVC の作成前に起動することを防ぎます。

7.16.2.3. 新規データボリュームへの仮想マシンディスクの永続ボリューム要求 (PVC) のクローン作成

既存の仮想マシンディスクの永続ボリューム要求 (PVC) のクローンを新規データボリュームに作成できます。その後、新規データボリュームは新規の仮想マシンに使用できます。

注記

データボリュームが仮想マシンとは別に作成される場合、データボリュームのライフサイクルは仮想マシンから切り離されます。仮想マシンが削除されても、データボリュームもその関連付けられた PVC も削除されません。

前提条件

  • 使用する既存の仮想マシンディスクの PVC を判別すること。クローン作成の前に、PVC に関連付けられた仮想マシンの電源を切る必要があります。
  • OpenShift CLI (oc) をインストールすること。

手順

  1. 関連付けられた PVC の名前および namespace を特定するために、クローン作成に必要な仮想マシンディスクを確認します。
  2. 新規データボリュームの名前、ソース PVC の名前および namespace、および新規データボリュームのサイズを指定するデータボリュームの YAML ファイルを作成します。

    以下は例になります。

    apiVersion: cdi.kubevirt.io/v1beta1
    kind: DataVolume
    metadata:
      name: <cloner-datavolume> 1
    spec:
      source:
        pvc:
          namespace: "<source-namespace>" 2
          name: "<my-favorite-vm-disk>" 3
      pvc:
        accessModes:
          - ReadWriteOnce
        resources:
          requests:
            storage: <2Gi> 4
    1
    新規データボリュームの名前。
    2
    ソース PVC が存在する namespace。
    3
    ソース PVC の名前。
    4
    新規データボリュームのサイズ。十分な領域を割り当てる必要があります。そうでない場合には、クローン操作は失敗します。サイズはソース PVC と同じか、またはそれよりも大きくなければなりません。
  3. データボリュームを作成して PVC のクローン作成を開始します。

    $ oc create -f <cloner-datavolume>.yaml
    注記

    データボリュームは仮想マシンが PVC の作成前に起動することを防ぐため、PVC のクローン作成中に新規データボリュームを参照する仮想マシンを作成できます。

7.16.2.4. テンプレート: データボリュームクローン設定ファイル

example-clone-dv.yaml

apiVersion: cdi.kubevirt.io/v1beta1
kind: DataVolume
metadata:
  name: "example-clone-dv"
spec:
  source:
      pvc:
        name: source-pvc
        namespace: example-ns
  pvc:
    accessModes:
      - ReadWriteOnce
    resources:
      requests:
        storage: "1G"

7.16.2.5. CDI がサポートする操作マトリックス

このマトリックスにはエンドポイントに対してコンテンツタイプのサポートされる CDI 操作が表示されます。これらの操作にはスクラッチ領域が必要です。

コンテンツタイプHTTPHTTPSHTTP Basic 認証レジストリーアップロード

kubevirt (QCOW2)

✓ QCOW2
✓ GZ*
✓ XZ*

✓ QCOW2**
✓ GZ*
✓ XZ*

✓ QCOW2
✓ GZ*
✓ XZ*

✓ QCOW2*
□ GZ
□ XZ

✓ QCOW2*
✓ GZ*
✓ XZ*

KubeVirt (RAW)

✓ RAW
✓ GZ
✓ XZ

✓ RAW
✓ GZ
✓ XZ

✓ RAW
✓ GZ
✓ XZ

✓ RAW*
□ GZ
□ XZ

✓ RAW*
✓ GZ*
✓ XZ*

✓ サポートされる操作

□ サポートされない操作

* スクラッチ領域が必要

**カスタム認証局が必要な場合にスクラッチ領域が必要

7.16.3. データボリュームテンプレートの使用による仮想マシンのクローン作成

既存の仮想マシンの永続ボリューム要求 (PVC) のクローン作成により、新規の仮想マシンを作成できます。dataVolumeTemplate を仮想マシン設定ファイルに含めることにより、元の PVC から新規のデータボリュームを作成します。

警告

異なるボリュームモード間でのクローン作成操作はサポートされていません。volumeMode の値は、ソースとターゲットの両方の仕様で一致している必要があります。

たとえば、volumeMode: Block の永続ボリューム (PV) から volumeMode: Filesystem の PV へのクローン作成を試行する場合、操作はエラーメッセージを出して失敗します。

7.16.3.1. 前提条件

  • ユーザーは、仮想マシンディスクの PVC のクローンを別の namespace に作成するために 追加のパーミッションが必要です。

7.16.3.2. データボリュームについて

DataVolume オブジェクトは、Containerized Data Importer (CDI) プロジェクトで提供されるカスタムリソースです。データボリュームは、基礎となる永続ボリューム要求 (PVC) に関連付けられるインポート、クローン作成、およびアップロード操作のオーケストレーションを行います。データボリュームは OpenShift Virtualization に統合され、仮想マシンが PVC の作成前に起動することを防ぎます。

7.16.3.3. データボリュームテンプレートの使用による、クローン作成された永続ボリューム要求 (PVC) からの仮想マシンの新規作成

既存の仮想マシンの永続ボリューム要求 (PVC) のクローンをデータボリュームに作成する仮想マシンを作成できます。仮想マシンマニフェストの dataVolumeTemplate を参照することにより、source PVC のクローンがデータボリュームに作成され、これは次に仮想マシンを作成するために自動的に使用されます。

注記

データボリュームが仮想マシンのデータボリュームテンプレートの一部として作成されると、データボリュームのライフサイクルは仮想マシンに依存します。つまり、仮想マシンが削除されると、データボリュームおよび関連付けられた PVC も削除されます。

前提条件

  • 使用する既存の仮想マシンディスクの PVC を判別すること。クローン作成の前に、PVC に関連付けられた仮想マシンの電源を切る必要があります。
  • OpenShift CLI (oc) をインストールすること。

手順

  1. 関連付けられた PVC の名前および namespace を特定するために、クローン作成に必要な仮想マシンを確認します。
  2. VirtualMachine オブジェクトの YAML ファイルを作成します。以下の仮想マシンのサンプルでは、source-namespace namespace にある my-favorite-vm-disk のクローンを作成します。favorite-clone という 2Gi データは my-favorite-vm-disk から作成されます。

    以下は例になります。

    apiVersion: kubevirt.io/v1alpha3
    kind: VirtualMachine
    metadata:
      labels:
        kubevirt.io/vm: vm-dv-clone
      name: vm-dv-clone 1
    spec:
      running: false
      template:
        metadata:
          labels:
            kubevirt.io/vm: vm-dv-clone
        spec:
          domain:
            devices:
              disks:
              - disk:
                  bus: virtio
                name: root-disk
            resources:
              requests:
                memory: 64M
          volumes:
          - dataVolume:
              name: favorite-clone
            name: root-disk
      dataVolumeTemplates:
      - metadata:
          name: favorite-clone
        spec:
          pvc:
            accessModes:
            - ReadWriteOnce
            resources:
              requests:
                storage: 2Gi
          source:
            pvc:
              namespace: "source-namespace"
              name: "my-favorite-vm-disk"
    1
    作成する仮想マシン。
  3. PVC のクローンが作成されたデータボリュームで仮想マシンを作成します。

    $ oc create -f <vm-clone-datavolumetemplate>.yaml

7.16.3.4. テンプレート: データボリューム仮想マシン設定ファイル

example-dv-vm.yaml

apiVersion: kubevirt.io/v1alpha3
kind: VirtualMachine
metadata:
  labels:
    kubevirt.io/vm: example-vm
  name: example-vm
spec:
  dataVolumeTemplates:
  - metadata:
      name: example-dv
    spec:
      pvc:
        accessModes:
        - ReadWriteOnce
        resources:
          requests:
            storage: 1G
      source:
          http:
             url: "" 1
  running: false
  template:
    metadata:
      labels:
        kubevirt.io/vm: example-vm
    spec:
      domain:
        cpu:
          cores: 1
        devices:
          disks:
          - disk:
              bus: virtio
            name: example-dv-disk
        machine:
          type: q35
        resources:
          requests:
            memory: 1G
      terminationGracePeriodSeconds: 0
      volumes:
      - dataVolume:
          name: example-dv
        name: example-dv-disk
1
インポートする必要のあるイメージの HTTP ソース (該当する場合)。

7.16.3.5. CDI がサポートする操作マトリックス

このマトリックスにはエンドポイントに対してコンテンツタイプのサポートされる CDI 操作が表示されます。これらの操作にはスクラッチ領域が必要です。

コンテンツタイプHTTPHTTPSHTTP Basic 認証レジストリーアップロード

kubevirt (QCOW2)

✓ QCOW2
✓ GZ*
✓ XZ*

✓ QCOW2**
✓ GZ*
✓ XZ*

✓ QCOW2
✓ GZ*
✓ XZ*

✓ QCOW2*
□ GZ
□ XZ

✓ QCOW2*
✓ GZ*
✓ XZ*

KubeVirt (RAW)

✓ RAW
✓ GZ
✓ XZ

✓ RAW
✓ GZ
✓ XZ

✓ RAW
✓ GZ
✓ XZ

✓ RAW*
□ GZ
□ XZ

✓ RAW*
✓ GZ*
✓ XZ*

✓ サポートされる操作

□ サポートされない操作

* スクラッチ領域が必要

**カスタム認証局が必要な場合にスクラッチ領域が必要

7.16.4. 新規ブロックストレージデータボリュームへの仮想マシンディスクのクローン作成

データボリューム設定ファイルでソース PVC を参照し、新規ブロックデータボリュームに仮想マシンディスクの永続ボリューム要求 (PVC) のクローンを作成できます。

警告

異なるボリュームモード間でのクローン作成操作はサポートされていません。volumeMode の値は、ソースとターゲットの両方の仕様で一致している必要があります。

たとえば、volumeMode: Block の永続ボリューム (PV) から volumeMode: Filesystem の PV へのクローン作成を試行する場合、操作はエラーメッセージを出して失敗します。

7.16.4.1. 前提条件

  • ユーザーは、仮想マシンディスクの PVC のクローンを別の namespace に作成するために 追加のパーミッションが必要です。

7.16.4.2. データボリュームについて

DataVolume オブジェクトは、Containerized Data Importer (CDI) プロジェクトで提供されるカスタムリソースです。データボリュームは、基礎となる永続ボリューム要求 (PVC) に関連付けられるインポート、クローン作成、およびアップロード操作のオーケストレーションを行います。データボリュームは OpenShift Virtualization に統合され、仮想マシンが PVC の作成前に起動することを防ぎます。

7.16.4.3. ブロック永続ボリュームについて

ブロック永続ボリューム (PV) は、raw ブロックデバイスによってサポートされる PV です。これらのボリュームにはファイルシステムがなく、オーバーヘッドを削減することで、仮想マシンのパフォーマンス上の利点をもたらすことができます。

raw ブロックボリュームは、PV および永続ボリューム要求 (PVC) 仕様で volumeMode: Block を指定してプロビジョニングされます。

7.16.4.4. ローカルブロック永続ボリュームの作成

ファイルにデータを設定し、これをループデバイスとしてマウントすることにより、ノードでローカルブロック永続ボリューム (PV) を作成します。次に、このループデバイスを PV マニフェストで Block ボリュームとして参照し、これを仮想マシンイメージのブロックデバイスとして使用できます。

手順

  1. ローカル PV を作成するノードに root としてログインします。この手順では、node01 を例に使用します。
  2. ファイルを作成して、これを null 文字で設定し、ブロックデバイスとして使用できるようにします。以下の例では、2Gb (20 100Mb ブロック) のサイズのファイル loop10 を作成します。

    $ dd if=/dev/zero of=<loop10> bs=100M count=20
  3. loop10 ファイルをループデバイスとしてマウントします。

    $ losetup </dev/loop10>d3 <loop10> 1 2
    1
    ループデバイスがマウントされているファイルパスです。
    2
    前の手順で作成したファイルはループデバイスとしてマウントされます。
  4. マウントされたループデバイスを参照する PersistentVolume マニフェストを作成します。

    kind: PersistentVolume
    apiVersion: v1
    metadata:
      name: <local-block-pv10>
      annotations:
    spec:
      local:
        path: </dev/loop10> 1
      capacity:
        storage: <2Gi>
      volumeMode: Block 2
      storageClassName: local 3
      accessModes:
        - ReadWriteOnce
      persistentVolumeReclaimPolicy: Delete
      nodeAffinity:
        required:
          nodeSelectorTerms:
          - matchExpressions:
            - key: kubernetes.io/hostname
              operator: In
              values:
              - <node01> 4
    1
    ノード上のループデバイスのパス。
    2
    ブロック PV であることを指定します。
    3
    オプション: PV にストレージクラスを設定します。これを省略する場合、クラスターのデフォルトが使用されます。
    4
    ブロックデバイスがマウントされたノード。
  5. ブロック PV を作成します。

    # oc create -f <local-block-pv10.yaml>1
    1
    直前の手順で作成された永続ボリュームのファイル名。

7.16.4.5. 新規データボリュームへの仮想マシンディスクの永続ボリューム要求 (PVC) のクローン作成

既存の仮想マシンディスクの永続ボリューム要求 (PVC) のクローンを新規データボリュームに作成できます。その後、新規データボリュームは新規の仮想マシンに使用できます。

注記

データボリュームが仮想マシンとは別に作成される場合、データボリュームのライフサイクルは仮想マシンから切り離されます。仮想マシンが削除されても、データボリュームもその関連付けられた PVC も削除されません。

前提条件

  • 使用する既存の仮想マシンディスクの PVC を判別すること。クローン作成の前に、PVC に関連付けられた仮想マシンの電源を切る必要があります。
  • OpenShift CLI (oc) をインストールすること。
  • ソース PVC と同じか、またはこれよりも大きい 1 つ以上の利用可能なブロック永続ボリューム (PV)。

手順

  1. 関連付けられた PVC の名前および namespace を特定するために、クローン作成に必要な仮想マシンディスクを確認します。
  2. 新規データボリュームの名前、ソース PVC の名前および namespace、利用可能なブロック PV を使用できるようにするために volumeMode: Block、および新規データボリュームのサイズを指定するデータボリュームの YAML ファイルを作成します。

    以下は例になります。

    apiVersion: cdi.kubevirt.io/v1beta1
    kind: DataVolume
    metadata:
      name: <cloner-datavolume> 1
    spec:
      source:
        pvc:
          namespace: "<source-namespace>" 2
          name: "<my-favorite-vm-disk>" 3
      pvc:
        accessModes:
          - ReadWriteOnce
        resources:
          requests:
            storage: <2Gi> 4
        volumeMode: Block 5
    1
    新規データボリュームの名前。
    2
    ソース PVC が存在する namespace。
    3
    ソース PVC の名前。
    4
    新規データボリュームのサイズ。十分な領域を割り当てる必要があります。そうでない場合には、クローン操作は失敗します。サイズはソース PVC と同じか、またはそれよりも大きくなければなりません。
    5
    宛先がブロック PV であることを指定します。
  3. データボリュームを作成して PVC のクローン作成を開始します。

    $ oc create -f <cloner-datavolume>.yaml
    注記

    データボリュームは仮想マシンが PVC の作成前に起動することを防ぐため、PVC のクローン作成中に新規データボリュームを参照する仮想マシンを作成できます。

7.16.4.6. CDI がサポートする操作マトリックス

このマトリックスにはエンドポイントに対してコンテンツタイプのサポートされる CDI 操作が表示されます。これらの操作にはスクラッチ領域が必要です。

コンテンツタイプHTTPHTTPSHTTP Basic 認証レジストリーアップロード

kubevirt (QCOW2)

✓ QCOW2
✓ GZ*
✓ XZ*

✓ QCOW2**
✓ GZ*
✓ XZ*

✓ QCOW2
✓ GZ*
✓ XZ*

✓ QCOW2*
□ GZ
□ XZ

✓ QCOW2*
✓ GZ*
✓ XZ*

KubeVirt (RAW)

✓ RAW
✓ GZ
✓ XZ

✓ RAW
✓ GZ
✓ XZ

✓ RAW
✓ GZ
✓ XZ

✓ RAW*
□ GZ
□ XZ

✓ RAW*
✓ GZ*
✓ XZ*

✓ サポートされる操作

□ サポートされない操作

* スクラッチ領域が必要

**カスタム認証局が必要な場合にスクラッチ領域が必要

7.17. 仮想マシンのネットワーク

7.17.1. 仮想マシンのデフォルト Pod ネットワークの使用

OpenShift Virtualization でデフォルトの Pod ネットワークを使用できます。これを実行するには、masquerade バインディングメソッドを使用する必要があります。これは、デフォルトの Pod ネットワークを使用する場合にのみ推奨されるバインディングメソッドです。デフォルト以外のネットワークには、masquerade モードを使用しないでください。

セカンダリーネットワークの場合は、bridge バインディングメソッドを使用します。

注記

KubeMacPool コンポーネントは、指定の namespace に仮想マシン NIC の MAC アドレスプールサービスを提供します。これはデフォルトで有効にされません。KubeMacPool ラベルを namespace に適用して、その namespace で MAC アドレスプールを有効にします

7.17.1.1. コマンドラインでのマスカレードモードの設定

マスカレードモードを使用し、仮想マシンの送信トラフィックを Pod IP アドレスの背後で非表示にすることができます。マスカレードモードは、ネットワークアドレス変換 (NAT) を使用して仮想マシンを Linux ブリッジ経由で Pod ネットワークバックエンドに接続します。

仮想マシンの設定ファイルを編集して、マスカレードモードを有効にし、トラフィックが仮想マシンに到達できるようにします。

前提条件

  • 仮想マシンは、IPv4 アドレスを取得するために DHCP を使用できるように設定される必要がある。以下の例では、DHCP を使用するように設定されます。

手順

  1. 仮想マシン設定ファイルの interfaces 仕様を編集します。

    kind: VirtualMachine
    spec:
      domain:
        devices:
          interfaces:
            - name: red
              masquerade: {} 1
              ports:
                - port: 80 2
      networks:
      - name: red
        pod: {}
    1
    マスカレードモードを使用した接続
    2
    ポート 80 での受信トラフィックの許可
  2. 仮想マシンを作成します。

    $ oc create -f <vm-name>.yaml

7.17.1.2. バインディング方法の選択

OpenShift Virtualization Web コンソールウィザードから仮想マシンを作成する場合、Networking 画面で必要なバインディングメソッドを選択します。

7.17.1.2.1. ネットワークフィールド
名前説明

名前

ネットワークインターフェースの名前。

Model

ネットワークインターフェースカードのモデルを示します。サポートされる値は e1000e および virtio です。

Network

利用可能なネットワーク接続定義の一覧。

Type

利用可能なバインディングメソッドの一覧。デフォルトの Pod ネットワークについては、masquerade が唯一の推奨されるバインディングメソッドになります。セカンダリーネットワークの場合は、 bridge バインディングメソッドを使用します。masquerade メソッドは、デフォルト以外のネットワークではサポートされません。

MAC Address

ネットワークインターフェースの MAC アドレス。MAC アドレスが指定されていない場合、セッションの一時アドレスが生成されます。

7.17.1.3. デフォルトネットワーク用の仮想マシン設定の例

7.17.1.3.1. テンプレート: 仮想マシンの設定ファイル
apiVersion: kubevirt.io/v1alpha3
kind: VirtualMachine
metadata:
  name: example-vm
  namespace: default
spec:
  running: false
  template:
    spec:
      domain:
        devices:
          disks:
            - name: containerdisk
              disk:
                bus: virtio
            - name: cloudinitdisk
              disk:
                bus: virtio
          interfaces:
          - masquerade: {}
            name: default
        resources:
          requests:
            memory: 1024M
      networks:
        - name: default
          pod: {}
      volumes:
        - name: containerdisk
          containerDisk:
            image: kubevirt/fedora-cloud-container-disk-demo
        - name: cloudinitdisk
          cloudInitNoCloud:
            userData: |
              #!/bin/bash
              echo "fedora" | passwd fedora --stdin
7.17.1.3.2. テンプレート: Windows 仮想マシンインスタンスの設定ファイル
apiVersion: kubevirt.io/v1alpha3
kind: VirtualMachineInstance
metadata:
  labels:
    special: vmi-windows
  name: vmi-windows
spec:
  domain:
    clock:
      timer:
        hpet:
          present: false
        hyperv: {}
        pit:
          tickPolicy: delay
        rtc:
          tickPolicy: catchup
      utc: {}
    cpu:
      cores: 2
    devices:
      disks:
      - disk:
          bus: sata
        name: pvcdisk
      interfaces:
      - masquerade: {}
        model: e1000
        name: default
    features:
      acpi: {}
      apic: {}
      hyperv:
        relaxed: {}
        spinlocks:
          spinlocks: 8191
        vapic: {}
    firmware:
      uuid: 5d307ca9-b3ef-428c-8861-06e72d69f223
    machine:
      type: q35
    resources:
      requests:
        memory: 2Gi
  networks:
  - name: default
    pod: {}
  terminationGracePeriodSeconds: 0
  volumes:
  - name: pvcdisk
    persistentVolumeClaim:
      claimName: disk-windows

7.17.1.4. 仮想マシンからのサービスの作成

仮想マシンを公開するために Service オブジェクトを最初に作成し、実行中の仮想マシンからサービスを作成します。

ClusterIP サービスタイプは、クラスター内で仮想マシンを内部に公開します。NodePort または LoadBalancer サービスタイプは、クラスター外から仮想マシンを外部に公開します。

この手順では、type: ClusterIPService オブジェクトを仮想マシンバックエンドサービスとして作成し、これに接続し、公開する方法についての例を示します。

注記

ClusterIP は、サービスの type が指定されていない場合のデフォルトサービスの type です。

手順

  1. 以下のように仮想マシンの YAML を編集します。

    apiVersion: kubevirt.io/v1alpha3
    kind: VirtualMachine
    metadata:
      name: vm-ephemeral
      namespace: example-namespace
    spec:
      running: false
      template:
        metadata:
          labels:
            special: key 1
        spec:
          domain:
            devices:
              disks:
                - name: containerdisk
                  disk:
                    bus: virtio
                - name: cloudinitdisk
                  disk:
                    bus: virtio
              interfaces:
              - masquerade: {}
                name: default
            resources:
              requests:
                memory: 1024M
          networks:
            - name: default
              pod: {}
          volumes:
            - name: containerdisk
              containerDisk:
                image: kubevirt/fedora-cloud-container-disk-demo
            - name: cloudinitdisk
              cloudInitNoCloud:
                userData: |
                  #!/bin/bash
                  echo "fedora" | passwd fedora --stdin
    1
    ラベル special: keyspec.template.metadata.labels セクションに追加します。
    注記

    仮想マシンのラベルは Pod に渡されます。VirtualMachine 設定のラベル (例: special: key) は、この手順の後で作成する Service YAML selector 属性のラベルに一致する必要があります。

  2. 仮想マシン YAML を保存して変更を適用します。
  3. Service YAML を編集し、Service オブジェクトを作成し、公開するために必要な設定を行います。

    apiVersion: v1
    kind: Service
    metadata:
      name: vmservice 1
      namespace: example-namespace 2
    spec:
      ports:
      - port: 27017
        protocol: TCP
        targetPort: 22 3
      selector:
        special: key 4
      type: ClusterIP 5
    1
    作成および公開するサービスの name を指定します。
    2
    仮想マシン YAML に指定する namespace に対応する Service YAML の metadata セクションの namespace を指定します。
    3
    targetPort: 22 を追加し、SSH ポート 22 にサービスを公開します。
    4
    Service YAML の spec セクションで、special: keyselector 属性に追加します。これは、仮想マシン YAML 設定ファイルに追加した labels に対応します。
    5
    Service YAML の spec セクションで、ClusterIP サービスの type: ClusterIP を追加します。NodePortLoadBalancer などのクラスター外にある他のタイプのサービスを作成し、公開するには、type: ClusterIPtype: NodePort または type: LoadBalancer に随時置き換えます。
  4. Service YAML を保存し、サービス設定を保管します。
  5. ClusterIP サービスを作成します。

    $ oc create -f <service_name>.yaml
  6. 仮想マシンを起動します。仮想マシンがすでに実行中の場合は、これを再起動します。
  7. Service オブジェクトをクエリーし、これが利用可能であり、ClusterIP タイプで設定されていることを確認します。

    検証

    • oc get service コマンドを実行し、仮想マシンで参照する namespace および Service YAML ファイルを指定します。

      $ oc get service -n example-namespace

      出力例

      NAME        TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)     AGE
      vmservice   ClusterIP   172.30.3.149   <none>        27017/TCP   2m

      • 出力で示されているように、vmservice が実行されています。
      • TYPE は、Service YAML で指定したように ClusterIP として表示されます。
  8. サービスをサポートするために使用する仮想マシンへの接続を確立します。別の仮想マシンなど、クラスター内のオブジェクトから接続します。

    1. 以下のように仮想マシンの YAML を編集します。

      apiVersion: kubevirt.io/v1alpha3
      kind: VirtualMachine
      metadata:
        name: vm-connect
        namespace: example-namespace
      spec:
        running: false
        template:
          spec:
            domain:
              devices:
                disks:
                  - name: containerdisk
                    disk:
                      bus: virtio
                  - name: cloudinitdisk
                    disk:
                      bus: virtio
                interfaces:
                - masquerade: {}
                  name: default
              resources:
                requests:
                  memory: 1024M
            networks:
              - name: default
                pod: {}
            volumes:
              - name: containerdisk
                containerDisk:
                  image: kubevirt/fedora-cloud-container-disk-demo
              - name: cloudinitdisk
                cloudInitNoCloud:
                  userData: |
                    #!/bin/bash
                    echo "fedora" | passwd fedora --stdin
    2. oc create コマンドを実行して 2 番目の仮想マシンを作成します。ここで、file.yaml は仮想マシン YAML の名前になります。

      $ oc create -f <file.yaml>
    3. 仮想マシンを起動します。
    4. 以下の virtctl コマンドを実行して仮想マシンに接続します。

      $ virtctl -n example-namespace console <new-vm-name>
      注記

      サービスタイプ LoadBalancer の場合、vinagre クライアントを使用し、パブリック IP およびポートを使用して仮想マシンに接続します。外部ポートは、サービスタイプ LoadBalancer を使用する場合に動的に割り当てられます。

    5. ssh コマンドを実行して接続を認証します。ここで、172.30.3.149 はサービスの ClusterIP であり、fedora は仮想マシンのユーザー名です。

      $ ssh fedora@172.30.3.149 -p 27017

      検証

      • 公開するサービスをサポートする仮想マシンのコマンドプロンプトが表示されます。実行中の仮想マシンがサポートするサービスの準備ができました。

追加リソース

7.17.2. 仮想マシンの複数ネットワークへの割り当て

Linux ブリッジを使用して、仮想マシンを複数のネットワークに割り当てることができます。また、複数インターフェースへのアクセスに依存する異なる既存のワークロードを持つ仮想マシンをインポートできます。

仮想マシンを追加のネットワークに割り当てるには、以下を実行します。

  1. Web コンソールまたは CLI で namespace のブリッジネットワーク接続定義を設定します。
  2. Web コンソールまたは CLI のいずれかを使用して、仮想マシンをネットワーク接続定義に割り当てます。

    • Web コンソールで、新規または既存の仮想マシンの NIC を作成します。
    • CLI で、仮想マシン設定にネットワーク情報を追加します。
注記

KubeMacPool コンポーネントは、指定の namespace に仮想マシン NIC の MAC アドレスプールサービスを提供します。これはデフォルトで有効にされません。KubeMacPool ラベルを namespace に適用して、その namespace で MAC アドレスプールを有効にします

7.17.2.1. 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.17.2.2. ネットワーク接続定義の作成

7.17.2.2.1. 前提条件
  • Linux ブリッジは、すべてのノードに設定して割り当てる必要がある。詳細は、「ノードのネットワーク」セクションを参照してください。
警告

仮想マシンのネットワーク接続定義での IPAM の設定はサポートされていません。

7.17.2.2.2. Web コンソールでの Linux ブリッジネットワーク接続定義の作成

ネットワーク接続定義は、layer-2 デバイスを OpenShift Virtualization クラスターの特定の namespace に公開するカスタムリソースです。

ネットワーク管理者は、ネットワーク接続定義を作成して既存の layer-2 ネットワークを Pod および仮想マシンに提供できます。

手順

  1. Web コンソールで、NetworkingNetwork Attachment Definitions をクリックします。
  2. Create Network Attachment Definition をクリックします。
  3. 一意の Name およびオプションの Description を入力します。
  4. Network Type 一覧をクリックし、CNV Linux bridge を選択します。
  5. Bridge Name フィールドにブリッジの名前を入力します。
  6. オプション: リソースに VLAN ID が設定されている場合、 VLAN Tag Number フィールドに ID 番号を入力します。
  7. Create をクリックします。
7.17.2.2.3. CLI での Linux ブリッジネットワーク接続定義の作成

ネットワーク管理者は、タイプ cnv-bridge のネットワーク接続定義を、レイヤー 2 ネットワークを Pod および仮想マシンに提供するように設定できます。

注記

ネットワーク接続定義は Pod または仮想マシンと同じ namespace にある必要があります。

手順

  1. ネットワーク接続定義マニフェストを作成します。マニフェストには、お使いの設定に合わせて変更された以下の内容が含まれる必要があります。

    apiVersion: "k8s.cni.cncf.io/v1"
    kind: NetworkAttachmentDefinition
    metadata:
      name: <a-bridge-network> 1
      annotations:
        k8s.v1.cni.cncf.io/resourceName: bridge.network.kubevirt.io/<bridge-interface> 2
    spec:
      config: '{
        "cniVersion": "0.3.1",
        "name": "<a-bridge-network>", 3
        "plugins": [
          {
            "type": "cnv-bridge", 4
            "bridge": "<bridge-interface>", 5
            "vlan": 1 6
          },
          {
            "type": "cnv-tuning" 7
          }
        ]
      }'
    1
    NetworkAttachmentDefinition オブジェクトの名前。
    2
    オプション: ノード選択のアノテーションのキーと値のペア。bridge-interface は一部のノードに設定されるブリッジの名前です。このアノテーションをネットワーク接続定義に追加する場合、仮想マシンインスタンスは bridge-interface ブリッジが接続されているノードでのみ実行されます。
    3
    設定の名前。設定名をネットワーク接続定義の name 値に一致させることが推奨されます。
    4
    このネットワーク接続定義のネットワークを提供する Container Network Interface (CNI) プラグインの実際の名前。異なる CNI を使用するのでない限り、このフィールドは変更しないでください。
    5
    ノードに設定される Linux ブリッジの名前。
    6
    オプション: VLAN タグ。
    7
    MAC プールマネージャーが固有の MAC アドレスを接続に割り当ることを許可する CNI プラグイン。
  2. ネットワーク接続定義を作成します。

    $ oc create -f <network-attachment-definition.yaml> 1
    1
    ここで、<network-attachment-definition.yaml> はネットワーク接続定義マニフェストのファイル名です。

検証

  • ネットワーク接続定義が oc get network-attachment-definition <name> または oc get net-attach-def <name> のいずれかを実行して作成されていることを確認します。以下は例になります。

    $ oc get network-attachment-definition <a-bridge-network> 1
    1
    ここで、<a-bridge-network> はネットワーク接続定義の設定に指定される名前です。

7.17.2.3. 仮想マシンの追加のネットワークへの割り当て

7.17.2.3.1. Web コンソールでの仮想マシンの NIC の作成

Web コンソールから追加の NIC を作成し、これを仮想マシンに割り当てます。

手順

  1. OpenShift Virtualization コンソールの適切なプロジェクトで、サイドメニューから WorkloadsVirtualization をクリックします。
  2. Virtual Machines タブをクリックします。
  3. 仮想マシンを選択して、Virtual Machine Overview 画面を開きます。
  4. Network Interfaces をクリックし、仮想マシンにすでに割り当てられている NIC を表示します。
  5. Add Network Interface をクリックし、一覧に新規スロットを作成します。
  6. Network ドロップダウンリストを使用して、追加ネットワークのネットワーク接続定義を選択します。
  7. 新規 NIC の NameModelType、および MAC Address に入力します。
  8. Add ボタンをクリックして NIC を保存し、これを仮想マシンに割り当てます。
7.17.2.3.2. ネットワークフィールド
名前説明

名前

ネットワークインターフェースの名前。

Model

ネットワークインターフェースカードのモデルを示します。サポートされる値は e1000e および virtio です。

Network

利用可能なネットワーク接続定義の一覧。

Type

利用可能なバインディングメソッドの一覧。デフォルトの Pod ネットワークについては、masquerade が唯一の推奨されるバインディングメソッドになります。セカンダリーネットワークの場合は、 bridge バインディングメソッドを使用します。masquerade メソッドは、デフォルト以外のネットワークではサポートされません。

MAC Address

ネットワークインターフェースの MAC アドレス。MAC アドレスが指定されていない場合、セッションの一時アドレスが生成されます。

7.17.2.3.3. CLI での仮想マシンのセカンダリーネットワークへの割り当て

ブリッジインターフェースを追加し、仮想マシン設定でネットワーク接続定義を指定して、仮想マシンをセカンダリーネットワークに割り当てます。

以下の手順では、YAML ファイルを使用して設定を編集し、更新されたファイルをクラスターに適用します。oc edit <object> <name> コマンドを使用して、既存の仮想マシンを編集することもできます。

前提条件

  • 設定を編集する前に仮想マシンをシャットダウンします。実行中の仮想マシンを編集する場合は、変更を有効にするために仮想マシンを再起動する必要があります。

手順

  1. ブリッジネットワークに接続する必要のある仮想マシン設定を作成または編集します。ブリッジインターフェースを spec.template.spec.domain.devices.interfaces 一覧に追加し、ネットワーク接続定義を spec.template.spec.networks 一覧に追加します。interfaces エントリーの名前は networks エントリーと同じである必要があります。以下の例では、a-bridge-network ネットワーク接続定義に接続される bridge-net というブリッジインターフェースを追加します。

    apiVersion: v1
    kind: VirtualMachine
    metadata:
        name: example-vm
    spec:
      template:
        spec:
          domain:
            devices:
              interfaces:
                - masquerade: {}
                  name: default
                - bridge: {}
                  name: bridge-net 1
    ...
          networks:
            - name: default
              pod: {}
            - name: bridge-net 2
              multus:
                networkName: <a-bridge-network> 3
    ...
    1 2
    ブリッジインターフェースの名前。この値は、対応する spec.template.spec.networks エントリーの name 値と一致する必要があります。
    3
    SR-IOV ネットワーク接続定義の名前。
    注記

    サンプルの仮想マシンは、default Pod ネットワーク、および a-bridge-network という名前のネットワーク接続定義によって定義される bridge-net の両方に接続されます。

  2. 設定を適用します。

    $ oc apply -f <example-vm.yaml>
  3. オプション: 実行中の仮想マシンを編集している場合は、変更を有効にするためにこれを再起動する必要があります。

7.17.2.4. 追加リソース

7.17.3. 仮想マシンの IP アドレスの設定

動的または静的のいずれかでプロビジョニングされた仮想マシンの IP アドレスを設定できます。

前提条件

  • 仮想マシンが セカンダリーネットワーク に接続できること。
  • 仮想マシンの動的 IP を設定するには、セカンダリーネットワーク上で DHCP サーバーを利用できる必要がある。

7.17.3.1. cloud-init を使用した新規仮想マシンの IP アドレスの設定

仮想マシンの作成時に cloud-init を使用して IP アドレスを設定できます。IP アドレスは、動的または静的にプロビジョニングできます。

手順

  • 仮想マシン設定を作成し、仮想マシン設定の spec.volumes.cloudInitNoCloud.networkData フィールドに cloud-init ネットワークの詳細を追加します。

    1. 動的 IP を設定するには、インターフェース名と dhcp4 ブール値を指定します。

      kind: VirtualMachine
      spec:
      ...
        volumes:
        - cloudInitNoCloud:
            networkData: |
              version: 2
              ethernets:
                eth1: 1
                  dhcp4: true 2
      1
      インターフェースの名前。
      2
      DHCP を使用して IPv4 アドレスをプロビジョニングします。
    2. 静的 IP を設定するには、インターフェース名と IP アドレスを指定します。

      kind: VirtualMachine
      spec:
      ...
        volumes:
        - cloudInitNoCloud:
            networkData: |
              version: 2
              ethernets:
                eth1: 1
                  addresses:
                  - 10.10.10.14/24 2
      1
      インターフェースの名前。
      2
      仮想マシンの静的 IP アドレス。

7.17.4. 仮想マシンの SR-IOV ネットワークデバイスの設定

クラスターで Single Root I/O Virtualization (SR-IOV) デバイスを設定できます。このプロセスは、OpenShift Container Platform の SR-IOV デバイスの設定と似ていますが、同じではありません。

注記

ライブマイグレーションは SR-IOV ネットワークインターフェースに接続されている仮想マシンにはサポートされません。

7.17.4.1. 前提条件

7.17.4.2. SR-IOV ネットワークデバイスの自動検出

SR-IOV Network Operator は、クラスターでワーカーノード上の SR-IOV 対応ネットワークデバイスを検索します。Operator は、互換性のある SR-IOV ネットワークデバイスを提供する各ワーカーノードの SriovNetworkNodeState カスタムリソース (CR) を作成し、更新します。

CR にはワーカーノードと同じ名前が割り当てられます。status.interfaces 一覧は、ノード上のネットワークデバイスについての情報を提供します。

重要

SriovNetworkNodeState オブジェクトは変更しないでください。Operator はこれらのリソースを自動的に作成し、管理します。

7.17.4.2.1. SriovNetworkNodeState オブジェクトの例

以下の YAML は、SR-IOV Network Operator によって作成される SriovNetworkNodeState オブジェクトの例です。

SriovNetworkNodeState オブジェクト

apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetworkNodeState
metadata:
  name: node-25 1
  namespace: openshift-sriov-network-operator
  ownerReferences:
  - apiVersion: sriovnetwork.openshift.io/v1
    blockOwnerDeletion: true
    controller: true
    kind: SriovNetworkNodePolicy
    name: default
spec:
  dpConfigVersion: "39824"
status:
  interfaces: 2
  - deviceID: "1017"
    driver: mlx5_core
    mtu: 1500
    name: ens785f0
    pciAddress: "0000:18:00.0"
    totalvfs: 8
    vendor: 15b3
  - deviceID: "1017"
    driver: mlx5_core
    mtu: 1500
    name: ens785f1
    pciAddress: "0000:18:00.1"
    totalvfs: 8
    vendor: 15b3
  - deviceID: 158b
    driver: i40e
    mtu: 1500
    name: ens817f0
    pciAddress: 0000:81:00.0
    totalvfs: 64
    vendor: "8086"
  - deviceID: 158b
    driver: i40e
    mtu: 1500
    name: ens817f1
    pciAddress: 0000:81:00.1
    totalvfs: 64
    vendor: "8086"
  - deviceID: 158b
    driver: i40e
    mtu: 1500
    name: ens803f0
    pciAddress: 0000:86:00.0
    totalvfs: 64
    vendor: "8086"
  syncStatus: Succeeded

1
name フィールドの値はワーカーノードの名前と同じです。
2
interfaces スタンザには、ワーカーノード上の Operator によって検出されるすべての SR-IOV デバイスの一覧が含まれます。

7.17.4.3. SR-IOV ネットワークデバイスの設定

SR-IOV Network Operator は SriovNetworkNodePolicy.sriovnetwork.openshift.io CustomResourceDefinition を OpenShift Container Platform に追加します。SR-IOV ネットワークデバイスは、SriovNetworkNodePolicy カスタムリソース (CR) を作成して設定できます。

注記

SriovNetworkNodePolicy オブジェクトで指定された設定を適用する際に、SR-IOV Operator はノードをドレイン (解放) する可能性があり、場合によってはノードの再起動を行う場合があります。

設定の変更が適用されるまでに数分かかる場合があります。

前提条件

  • OpenShift CLI (oc) がインストールされていること。
  • cluster-admin ロールを持つユーザーとしてクラスターにアクセスできる。
  • SR-IOV Network Operator がインストールされていること。
  • ドレイン (解放) されたノードからエビクトされたワークロードを処理するために、クラスター内に利用可能な十分なノードがあること。
  • SR-IOV ネットワークデバイス設定についてコントロールプレーンノードを選択していないこと。

手順

  1. SriovNetworkNodePolicy オブジェクトを作成してから、YAML を <name>-sriov-node-network.yaml ファイルに保存します。<name> をこの設定の名前に置き換えます。
apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetworkNodePolicy
metadata:
  name: <name> 1
  namespace: openshift-sriov-network-operator 2
spec:
  resourceName: <sriov_resource_name> 3
  nodeSelector:
    feature.node.kubernetes.io/network-sriov.capable: "true" 4
  priority: <priority> 5
  mtu: <mtu> 6
  numVfs: <num> 7
  nicSelector: 8
    vendor: "<vendor_code>" 9
    deviceID: "<device_id>" 10
    pfNames: ["<pf_name>", ...] 11
    rootDevices: ["<pci_bus_id>", "..."] 12
  deviceType: vfio-pci 13
  isRdma: false 14
1
CR オブジェクトの名前を指定します。
2
SR-IOV Operator がインストールされている namespace を指定します。
3
SR-IOV デバイスプラグインのリソース名を指定します。1 つのリソース名に複数の SriovNetworkNodePolicy オブジェクトを作成できます。
4
設定するノードを選択するノードセレクターを指定します。選択したノード上の SR-IOV ネットワークデバイスのみが設定されます。SR-IOV Container Network Interface (CNI) プラグインおよびデバイスプラグインは、選択したノードにのみデプロイされます。
5
オプション: 0 から 99 までの整数値を指定します。数値が小さいほど優先度が高くなります。したがって、1099 よりも優先度が高くなります。デフォルト値は 99 です。
6
オプション: 仮想機能 (VF) の最大転送単位 (MTU) の値を指定します。MTU の最大値は NIC モデルによって異なります。
7
SR-IOV 物理ネットワークデバイス用に作成する仮想機能 (VF) の数を指定します。Intel Network Interface Card (NIC) の場合、VF の数はデバイスがサポートする VF の合計よりも大きくすることはできません。Mellanox NIC の場合、VF の数は 128 よりも大きくすることはできません。
8
nicSelector マッピングは、Operator が設定するイーサネットデバイスを選択します。すべてのパラメーターの値を指定する必要はありません。意図せずにイーサネットデバイスを選択する可能性を最低限に抑えるために、イーサネットアダプターを正確に特定できるようにすることが推奨されます。rootDevices を指定する場合、vendordeviceID、または pfName の値も指定する必要があります。pfNamesrootDevices の両方を同時に指定する場合、それらが同一のデバイスをポイントすることを確認します。
9
オプション: SR-IOV ネットワークデバイスのベンダー 16 進コードを指定します。許可される値は 8086 または 15b3 のいずれかのみになります。
10
オプション: SR-IOV ネットワークデバイスのデバイス 16 進コードを指定します。許可される値は 158b10151017 のみになります。
11
オプション: このパラメーターは、1 つ以上のイーサネットデバイスの物理機能 (PF) 名の配列を受け入れます。
12
このパラメーターは、イーサネットデバイスの物理機能についての 1 つ以上の PCI バスアドレスの配列を受け入れます。以下の形式でアドレスを指定します: 0000:02:00.1
13
OpenShift Virtualization の仮想機能には、vfio-pci ドライバータイプが必要です。
14
オプション: Remote Direct Memory Access (RDMA) モードを有効にするかどうかを指定します。Mellanox カードの場合、isRdmafalse に設定します。デフォルト値は false です。
注記

isRDMA フラグが true に設定される場合、引き続き RDMA 対応の VF を通常のネットワークデバイスとして使用できます。デバイスはどちらのモードでも使用できます。

  1. SriovNetworkNodePolicy オブジェクトを作成します。

    $ oc create -f <name>-sriov-node-network.yaml

    ここで、<name> はこの設定の名前を指定します。

    設定の更新が適用された後に、sriov-network-operator namespace のすべての Pod が Running ステータスに移行します。

  2. SR-IOV ネットワークデバイスが設定されていることを確認するには、以下のコマンドを実行します。<node_name> を、設定したばかりの SR-IOV ネットワークデバイスを持つノードの名前に置き換えます。

    $ oc get sriovnetworknodestates -n openshift-sriov-network-operator <node_name> -o jsonpath='{.status.syncStatus}'

7.17.4.4. 次のステップ

7.17.5. SR-IOV ネットワークの定義

仮想マシンの Single Root I/O Virtualization (SR-IOV) デバイスのネットワーク割り当てを作成できます。

ネットワークが定義された後に、仮想マシンを SR-IOV ネットワークに割り当てることができます。

7.17.5.1. 前提条件

7.17.5.2. SR-IOV の追加ネットワークの設定

SriovNetwork オブジェクト を作成して、SR-IOV ハードウェアを使用する追加のネットワークを設定できます。SriovNetwork オブジェクトの作成時に、SR-IOV Operator は NetworkAttachmentDefinition オブジェクトを自動的に作成します。

次に、ユーザーはネットワークを仮想マシン設定で指定することで、仮想マシンを SR-IOV ネットワークに割り当てることができます。

注記

SriovNetwork オブジェクトが running 状態の Pod または仮想マシンに割り当てられている場合、これを変更したり、削除したりしないでください。

前提条件

  • OpenShift CLI (oc) をインストールすること。
  • cluster-admin 権限を持つユーザーとしてログインすること。

手順

  1. 以下の SriovNetwork オブジェクトを作成してから、YAML を <name>-sriov-network.yaml ファイルに保存します。<name> を、この追加ネットワークの名前に置き換えます。
apiVersion: sriovnetwork.openshift.io/v1
kind: SriovNetwork
metadata:
  name: <name> 1
  namespace: openshift-sriov-network-operator 2
spec:
  resourceName: <sriov_resource_name> 3
  networkNamespace: <target_namespace> 4
  vlan: <vlan> 5
  spoofChk: "<spoof_check>" 6
  linkState: <link_state> 7
  maxTxRate: <max_tx_rate> 8
  minTxRate: <min_rx_rate> 9
  vlanQoS: <vlan_qos> 10
  trust: "<trust_vf>" 11
  capabilities: <capabilities> 12
1
<name> をオブジェクトの名前に置き換えます。SR-IOV Network Operator は、同じ名前を持つ NetworkAttachmentDefinition オブジェクトを作成します。
2
SR-IOV ネットワーク Operator がインストールされている namespace を指定します。
3
<sriov_resource_name> を、この追加ネットワークの SR-IOV ハードウェアを定義する SriovNetworkNodePolicy オブジェクトの .spec.resourceName パラメーターの値に置き換えます。
4
<target_namespace> を SriovNetwork のターゲット namespace に置き換えます。ターゲット namespace の Pod または仮想マシンのみを SriovNetwork に割り当てることができます。
5
オプション: <vlan> を、追加ネットワークの仮想 LAN (VLAN) ID に置き換えます。整数値は 0 から 4095である必要があります。デフォルト値は 0 です。
6
オプション: <spoof_check> を VF の spoof check モードに置き換えます。許可される値は、文字列の "on" および "off" です。
重要

指定する値を引用符で囲む必要があります。そうしないと、CR は SR-IOV ネットワーク Operator によって拒否されます。

7
オプション: <link_state> を仮想機能 (VF) のリンクの状態に置き換えます。許可される値は、enabledisable、および auto です。
8
オプション: <max_tx_rate> を VF の最大伝送レート (Mbps) に置き換えます。
9
オプション: <min_tx_rate> を VF の最小伝送レート (Mbps) に置き換えます。この値は、常に最大伝送レート以下である必要があります。
注記

Intel NIC は minTxRate パラメーターをサポートしません。詳細は、BZ#1772847 を参照してください。

10
オプション: <vlan_qos> を VF の IEEE 802.1p 優先レベルに置き換えます。デフォルト値は 0 です。
11
オプション: <trust_vf> を VF の信頼モードに置き換えます。許可される値は、文字列の "on" および "off" です。
重要

指定する値を引用符で囲む必要があります。そうしないと、CR は SR-IOV ネットワーク Operator によって拒否されます。

12
オプション: <capabilities> を、このネットワークに設定する機能に置き換えます。
  1. オブジェクトを作成するには、以下のコマンドを入力します。<name> を、この追加ネットワークの名前に置き換えます。

    $ oc create -f <name>-sriov-network.yaml
  2. オプション: 以下のコマンドを実行して、直前の手順で作成した SriovNetwork オブジェクトに関連付けられた NetworkAttachmentDefinition オブジェクトが存在することを確認するには、以下のコマンドを入力します。<namespace> を、SriovNetwork オブジェクト で指定した namespace に置き換えます。

    $ oc get net-attach-def -n <namespace>

7.17.5.3. 次のステップ

7.17.6. 仮想マシンの SR-IOV ネットワークへの割り当て

SR-IOV (Single Root I/O Virtualization) ネットワークをセカンダリーネットワークとして使用するために仮想マシンを割り当てることができます。

7.17.6.1. 前提条件

7.17.6.2. 仮想マシンの SR-IOV ネットワークへの割り当て

仮想マシンの設定にネットワークの詳細を含めることで、仮想マシンを SR-IOV ネットワークに割り当てることができます。

手順

  1. SR-IOV ネットワークの詳細を仮想マシン設定の spec.domain.devices.interfaces および spec.networks に追加します。

    kind: VirtualMachine
    ...
    spec:
      domain:
        devices:
          interfaces:
          - name: <default> 1
            masquerade: {} 2
          - name: <nic1> 3
            sriov: {}
      networks:
      - name: <default> 4
        pod: {}
      - name: <nic1> 5
        multus:
            networkName: <sriov-network> 6
    ...
    1
    Pod ネットワークに接続されているインターフェースの一意の名前。
    2
    デフォルト Pod ネットワークへの masquerade バインディング。
    3
    SR-IOV インターフェースの一意の名前。
    4
    Pod ネットワークインターフェースの名前。これは、前のステップで定義した interfaces.name と同じである必要があります。
    5
    SR-IOV ネットワークの名前。これは、前のステップで定義した interfaces.name と同じである必要があります。
    6
    SR-IOV ネットワーク割り当て定義の名前。
  2. 仮想マシン設定を適用します。

    $ oc apply -f <vm-sriov.yaml> 1
    1
    仮想マシン YAML ファイルの名前。

7.17.7. NIC の IP アドレスの仮想マシンへの表示

Web コンソールまたは oc クライアントを使用して、ネットワークインターフェースカード (NIC) の IP アドレスを表示できます。QEMU ゲストエージェントは、仮想マシンのセカンダリーネットワークに関する追加情報を表示します。

7.17.7.1. CLI での仮想マシンインターフェースの IP アドレスの表示

ネットワークインターフェース設定は oc describe vmi <vmi_name> コマンドに含まれます。

IP アドレス情報は、仮想マシン上で ip addr を実行するか、または oc get vmi <vmi_name> -o yaml を実行して表示することもできます。

手順

  • oc describe コマンドを使用して、仮想マシンインターフェース設定を表示します。

    $ oc describe vmi <vmi_name>

    出力例

    ...
    Interfaces:
       Interface Name:  eth0
       Ip Address:      10.244.0.37/24
       Ip Addresses:
         10.244.0.37/24
         fe80::858:aff:fef4:25/64
       Mac:             0a:58:0a:f4:00:25
       Name:            default
       Interface Name:  v2
       Ip Address:      1.1.1.7/24
       Ip Addresses:
         1.1.1.7/24
         fe80::f4d9:70ff:fe13:9089/64
       Mac:             f6:d9:70:13:90:89
       Interface Name:  v1
       Ip Address:      1.1.1.1/24
       Ip Addresses:
         1.1.1.1/24
         1.1.1.2/24
         1.1.1.4/24
         2001:de7:0:f101::1/64
         2001:db8:0:f101::1/64
         fe80::1420:84ff:fe10:17aa/64
       Mac:             16:20:84:10:17:aa

7.17.7.2. Web コンソールでの仮想マシンインターフェースの IP アドレスの表示

IP 情報は、仮想マシンの Virtual Machine Overview 画面に表示されます。

手順

  1. OpenShift Virtualization コンソールのサイドメニューから WorkloadsVirtualization をクリックします。
  2. Virtual Machines タブをクリックします。
  3. 仮想マシン名を選択して、Virtual Machine Overview 画面を開きます。

それぞれの割り当てられた NIC の情報は IP Address の下に表示されます。

7.17.8. 仮想マシンの MAC アドレスプールの使用

KubeMacPool コンポーネントは、指定の namespace に仮想マシン NIC の MAC アドレスプールサービスを提供します。KubeMacPool ラベルをその namespace に適用して、namespace の MAC アドレスプールを有効にします。

7.17.8.1. KubeMacPool について

namespace の KubeMacPool コンポーネントを有効にする場合、その namespace の仮想マシン NIC には MAC アドレスプールから MAC アドレスが割り当てられます。これにより、NIC には別の仮想マシンの MAC アドレスと競合しない一意の MAC アドレスが割り当てられます。

仮想マシンから作成される仮想マシンインスタンスは、再起動時に割り当てられる MAC アドレスを保持します。

注記

KubeMacPool は、仮想マシンから独立して作成される仮想マシンインスタンスを処理しません。

KubeMacPool はデフォルトで無効にされます。KubeMacPool ラベルを namespace に適用して、namespace の MAC アドレスプールを有効にします。

7.17.8.2. CLI での namespace の MAC アドレスプールの有効化

mutatevirtualmachines.kubemacpool.io=allocate ラベルを namespace に適用して namespace の仮想マシンの MAC アドレスプールを有効にします。

手順

  • KubeMacPool ラベルを namespace に追加します。以下の例では、KubeMacPool ラベルを 2 つの namespace (<namespace1> および <namespace2>) に追加します。

    $ oc label namespace <namespace1> <namespace2> mutatevirtualmachines.kubemacpool.io=allocate

7.17.8.3. CLI での namespace の MAC アドレスプールの無効化

mutatevirtualmachines.kubemacpool.io ラベルを削除して、namespace の仮想マシンの MAC アドレスプールを無効にします。

手順

  • KubeMacPool ラベルを namespace から削除します。以下の例では、KubeMacPool ラベルを 2 つの namespace (<namespace1> および <namespace2>) から削除します。

    $ oc label namespace <namespace1> <namespace2> mutatevirtualmachines.kubemacpool.io-

7.18. 仮想マシンディスク

7.18.1. ストレージ機能

以下の表を使用して、OpenShift Virtualization のローカルおよび共有の永続ストレージ機能の可用性を確認できます。

7.18.1.1. OpenShift Virtualization ストレージ機能マトリクス

表7.8 OpenShift Virtualization ストレージ機能マトリクス

 仮想マシンのライブマイグレーションホスト支援型仮想マシンディスクのクローン作成ストレージ支援型仮想マシンディスクのクローン作成仮想マシンのスナップショット

OpenShift Container Storage: RBD ブロックモードボリューム

Yes

Yes

Yes

Yes

OpenShift Virtualization ホストパスプロビジョナー

No

No

No

他の複数ノードの書き込み可能なストレージ

はい [1]

[2]

[2]

他の単一ノードの書き込み可能なストレージ

No

[2]

[2]

  1. PVC は ReadWriteMany アクセスモードを要求する必要があります。
  2. ストレージプロバイダーが Kubernetes および CSI スナップショット API の両方をサポートする必要があります。
注記

以下を使用する仮想マシンのライブマイグレーションを行うことはできません。

  • ReadWriteOnce (RWO) アクセスモードのストレージクラス
  • SR-IOV や GPU などのパススルー機能

それらの仮想マシンの evictionStrategy フィールドを LiveMigrate に設定しないでください。

7.18.2. 仮想マシンのローカルストレージの設定

ホストパスプロビジョナー機能を使用して、仮想マシンのローカルストレージを設定できます。

7.18.2.1. ホストパスプロビジョナーについて

ホストパスプロビジョナーは、OpenShift Virtualization 用に設計されたローカルストレージプロビジョナーです。仮想マシンのローカルストレージを設定する必要がある場合、まずホストパスプロビジョナーを有効にする必要があります。

OpenShift Virtualization Operator のインストール時に、ホストパスプロビジョナー Operator は自動的にインストールされます。これを使用するには、以下を実行する必要があります。

  • SELinux を設定します。

    • Red Hat Enterprise Linux CoreOS 8 ワーカーを使用する場合は、各ノードに MachineConfig オブジェクトを作成する必要があります。
    • それ以外の場合には、SELinux ラベル container_file_t を各ノードの永続ボリューム (PV) バッキングディレクトリーに適用します。
  • HostPathProvisioner カスタムリソースを作成します。
  • ホストパスプロビジョナーの StorageClass オブジェクトを作成します。

ホストパスプロビジョナー Operator は、カスタムリソースの作成時にプロビジョナーを各ノードに DaemonSet としてデプロイします。カスタムリソースファイルでは、ホストパスプロビジョナーが作成する永続ボリュームのバッキングディレクトリーを指定します。

7.18.2.2. Red Hat Enterprise Linux CoreOS 8 でのホストパスプロビジョナー用の SELinux の設定

HostPathProvisioner カスタムリソースを作成する前に、SELinux を設定する必要があります。Red Hat Enterprise Linux CoreOS 8 ワーカーで SELinux を設定するには、各ノードに MachineConfig オブジェクトを作成する必要があります。

前提条件

  • ホストパスプロビジョナーが作成する永続ボリューム (PV) 用に、各ノードにバッキングディレクトリーを作成すること。

手順

  1. MachineConfig ファイルを作成します。以下は例になります。

    $ touch machineconfig.yaml
  2. ファイルを編集し、ホストパスプロビジョナーが PV を作成するディレクトリーを組み込みます。以下は例になります。

    apiVersion: machineconfiguration.openshift.io/v1
    kind: MachineConfig
    metadata:
      name: 50-set-selinux-for-hostpath-provisioner
      labels:
        machineconfiguration.openshift.io/role: worker
    spec:
      config:
        ignition:
          version: 3.1.0
        systemd:
          units:
            - contents: |
                [Unit]
                Description=Set SELinux chcon for hostpath provisioner
                Before=kubelet.service
    
                [Service]
                ExecStart=/usr/bin/chcon -Rt container_file_t <path/to/backing/directory> 1
    
                [Install]
                WantedBy=multi-user.target
              enabled: true
              name: hostpath-provisioner.service
    1
    プロビジョナーが PV を作成するバッキングディレクトリーを指定します。
  3. MachineConfig オブジェクトを作成します。

    $ oc create -f machineconfig.yaml -n <namespace>

7.18.2.3. ホストパスプロビジョナーを使用したローカルストレージの有効化

ホストパスプロビジョナーをデプロイし、仮想マシンがローカルストレージを使用できるようにするには、最初に HostPathProvisioner カスタムリソースを作成します。

前提条件

  • ホストパスプロビジョナーが作成する永続ボリューム (PV) 用に、各ノードにバッキングディレクトリーを作成すること。
  • SELinux コンテキスト container_file_t を各ノードの PV バッキングディレクトリーに適用すること。以下は例になります。

    $ sudo chcon -t container_file_t -R </path/to/backing/directory>
    注記

    Red Hat Enterprise Linux CoreOS 8 ワーカーを使用する場合は、代わりに MachineConfig マニフェストを使用して SELinux を設定する必要があります。

手順

  1. HostPathProvisioner カスタムリソースファイルを作成します。以下は例になります。

    $ touch hostpathprovisioner_cr.yaml
  2. ファイルを編集し、spec.pathConfig.path の値がホストパスプロビジョナーが PV を作成するディレクトリーであることを確認します。以下は例になります。

    apiVersion: hostpathprovisioner.kubevirt.io/v1beta1
    kind: HostPathProvisioner
    metadata:
      name: hostpath-provisioner
    spec:
      imagePullPolicy: IfNotPresent
      pathConfig:
        path: "</path/to/backing/directory>" 1
        useNamingPrefix: false 2
    1
    プロビジョナーが PV を作成するバッキングディレクトリーを指定します。
    2
    作成された PV にバインドされる Persistent Volume Claim (永続ボリューム要求、PVC) の名前をディレクトリー名のプレフィックスとして使用する場合には、この値を true に変更します。
    注記

    バッキングディレクトリーを作成していない場合、プロビジョナーはこの作成を試行します。container_file_t SELinux コンテキストを適用していない場合、これにより Permission denied エラーが生じる可能性があります。

  3. openshift-cnv namespace にカスタムリソースを作成します。

    $ oc create -f hostpathprovisioner_cr.yaml -n openshift-cnv

7.18.2.4. ストレージクラスの作成

ストレージクラスの作成時に、ストレージクラスに属する永続ボリューム (PV) の動的プロビジョニングに影響するパラメーターを設定します。

注記

StorageClass オブジェクトの作成後には、このオブジェクトのパラメーターを更新できません。

手順

  1. ストレージクラスを定義する YAML ファイルを作成します。以下は例になります。

    $ touch storageclass.yaml
  2. ファイルを編集します。以下は例になります。

    apiVersion: storage.k8s.io/v1
    kind: StorageClass
    metadata:
      name: hostpath-provisioner 1
    provisioner: kubevirt.io/hostpath-provisioner
    reclaimPolicy: Delete 2
    volumeBindingMode: WaitForFirstConsumer 3
    1
    この値を変更することで、オプションでストレージクラスの名前を変更できます。
    2
    reclaimPolicy には、Delete および Retain の 2 つの値があります。値を指定しない場合、ストレージクラスはデフォルトで Delete に設定されます。
    3
    volumeBindingMode 値は、動的プロビジョニングおよびボリュームバインディングが実行されるタイミングを決定します。WaitForFirstConsumer を指定して、永続ボリューム要求 (PVC) を使用する Pod が作成されるまで PV のバインディングおよびプロビジョニングを遅延させます。これにより、PV が Pod のスケジュール要件を満たすようになります。
注記

仮想マシンは、ローカル PV に基づくデータボリュームを使用します。ローカル PV は特定のノードにバインドされます。ディスクイメージは仮想マシンで使用するために準備されますが、ローカルストレージ PV がすでに固定されたノードに仮想マシンをスケジュールすることができない可能性があります。

この問題を解決するには、Kubernetes Pod スケジューラーを使用して PVC を正しいノード上の PV にバインドします。volumeBindingModeWaitForFirstConsumer に設定された StorageClass を使用すると、PV のバインディングおよびプロビジョニングは、Pod が PVC を使用して作成されるまで遅延します。

  1. StorageClass オブジェクトを作成します。

    $ oc create -f storageclass.yaml

7.18.3. コンピュートリソースクォータを持つ namespace で機能する CDI の設定

Containerized Data Importer (CDI) を使用して、CPU およびメモリーリソースの制限が適用される namespace に仮想マシンディスクをインポートし、アップロードし、そのクローンを作成できるようになりました。

7.18.3.1. namespace の CPU およびメモリークォータについて

ResourceQuota オブジェクトで定義される リソースクォータ は、その namespace 内のリソースが消費できるコンピュートリソースの全体量を制限する制限を namespace に課します。

CDIConfig オブジェクトは Containerized Data Importer (CDI) のユーザー設定を定義します。CDIConfig オブジェクトの CPU およびメモリーの要求および制限の値はデフォルト値の 0 に設定されます。これにより、コンピュートリソース要件を作成する CDI によって作成される Pod にデフォルト値が付与され、クォータで制限される namespace での実行が許可されます。

7.18.3.2. CPU およびメモリーのデフォルトを上書きするための CDIConfig オブジェクトの編集

CDIConfig オブジェクトの spec 属性を編集して、ユースケースに応じて CPU およびメモリーの要求および制限のデフォルト設定を変更します。

前提条件

  • OpenShift CLI (oc) をインストールすること。

手順

  1. 以下のコマンドを実行して cdiconfig/config を編集します。

    $ oc edit cdiconfig/config
  2. CDIConfig オブジェクトの spec: podResourceRequirements プロパティーを編集して、デフォルトの CPU およびメモリーの要求および制限を変更します。

    apiVersion: cdi.kubevirt.io/v1beta1
    kind: CDIConfig
    metadata:
      labels:
        app: containerized-data-importer
        cdi.kubevirt.io: ""
      name: config
    spec:
        podResourceRequirements:
        limits:
          cpu: "4"
          memory: "1Gi"
        requests:
          cpu: "1"
          memory: "250Mi"
    ...
  3. エディターを保存し、終了して CDIConfig オブジェクトを更新します。

検証

  • 以下のコマンドを実行して CDIConfig ステータスを表示し、変更を確認します。

    $ oc get cdiconfig config -o yaml

7.18.3.3. 追加リソース

7.18.4. Web コンソールの使用によるローカルディスクイメージのアップロード

Web コンソールを使用して、ローカルに保存されたディスクイメージファイルをアップロードできます。

7.18.4.1. 前提条件

7.18.4.2. CDI がサポートする操作マトリックス

このマトリックスにはエンドポイントに対してコンテンツタイプのサポートされる CDI 操作が表示されます。これらの操作にはスクラッチ領域が必要です。

コンテンツタイプHTTPHTTPSHTTP Basic 認証レジストリーアップロード

kubevirt (QCOW2)

✓ QCOW2
✓ GZ*
✓ XZ*

✓ QCOW2**
✓ GZ*
✓ XZ*

✓ QCOW2
✓ GZ*
✓ XZ*

✓ QCOW2*
□ GZ
□ XZ

✓ QCOW2*
✓ GZ*
✓ XZ*

KubeVirt (RAW)

✓ RAW
✓ GZ
✓ XZ

✓ RAW
✓ GZ
✓ XZ

✓ RAW
✓ GZ
✓ XZ

✓ RAW*
□ GZ
□ XZ

✓ RAW*
✓ GZ*
✓ XZ*

✓ サポートされる操作

□ サポートされない操作

* スクラッチ領域が必要

**カスタム認証局が必要な場合にスクラッチ領域が必要

7.18.4.3. Web コンソールを使用したイメージファイルのアップロード

Web コンソールを使用して、イメージファイルを新規の永続ボリューム要求 (PVC) にアップロードします。この PVC を後で使用して、イメージを新規の仮想マシンに割り当てることができます。

前提条件

  • 以下のいずれかが必要である。

    • ISO または IMG 形式のいずれかの raw 仮想マシンイメージファイル。
    • QCOW2 形式の仮想マシンのイメージファイル。
  • 最善の結果を得るには、アップロードする前にイメージファイルを以下のガイドラインに従って圧縮すること。

    • xz または gzip を使用して raw イメージファイルを圧縮します。

      注記

      圧縮された raw イメージファイルを使用すると、最も効率的にアップロードできます。

    • クライアントについて推奨される方法を使用して、QCOW2 イメージファイルを圧縮します。

      • Linux クライアントを使用する場合は、virt-sparsify ツールを使用して、QCOW2 ファイルをスパース化 (sparsify) します。
      • Windows クライアントを使用する場合は、xz または gzip を使用して QCOW2 ファイルを圧縮します。

手順

  1. Web コンソールのサイドメニューから、StoragePersistent Volume Claims をクリックします。
  2. Create Persistent Volume Claim ドロップダウンリストをクリックし、これを拡張します。
  3. With Data Upload Form をクリックし、Upload Data to Persistent Volume Claim ページを開きます。
  4. Browse をクリックし、ファイルマネージャーを開き、アップロードするイメージを選択するか、ファイルを Drag a file here or browse to upload フィールドにドラッグします。
  5. オプション: 特定のオペレーティングシステムのデフォルトイメージとしてこのイメージを設定します。

    1. Attach this data to a virtual machine operating system チェックボックスを選択します。
    2. 一覧からオペレーティングシステムを選択します。
  6. Persistent Volume Claim Name フィールドには、一意の名前が自動的に入力され、これを編集することはできません。PVC に割り当てられた名前をメモし、必要に応じてこれを後で特定できるようにします。
  7. Storage Class 一覧からストレージクラスを選択します。
  8. Size フィールドに PVC のサイズ値を入力します。ドロップダウンリストから、対応する測定単位を選択します。

    警告

    PVC サイズは圧縮解除された仮想ディスクのサイズよりも大きくなければなりません。

  9. 選択したストレージクラスに一致する Access Mode を選択します。
  10. Upload をクリックします。

7.18.5. virtctl ツールの使用によるローカルディスクイメージのアップロード

virtctl コマンドラインユーティリティーを使用して、ローカルに保存されたディスクイメージを新規または既存のデータボリュームにアップロードできます。

7.18.5.1. 前提条件

7.18.5.2. データボリュームについて

DataVolume オブジェクトは、Containerized Data Importer (CDI) プロジェクトで提供されるカスタムリソースです。データボリュームは、基礎となる永続ボリューム要求 (PVC) に関連付けられるインポート、クローン作成、およびアップロード操作のオーケストレーションを行います。データボリュームは OpenShift Virtualization に統合され、仮想マシンが PVC の作成前に起動することを防ぎます。

7.18.5.3. アップロードデータボリュームの作成

ローカルディスクイメージのアップロードに使用する upload データソースでデータボリュームを手動で作成できます。

手順

  1. spec: source: upload{} を指定するデータボリューム設定を作成します。

    apiVersion: cdi.kubevirt.io/v1beta1
    kind: DataVolume
    metadata:
      name: <upload-datavolume> 1
    spec:
      source:
          upload: {}
      pvc:
        accessModes:
          - ReadWriteOnce
        resources:
          requests:
            storage: <2Gi> 2
    1
    データボリュームの名前。
    2
    データボリュームのサイズ。この値がアップロードするディスクのサイズ以上であることを確認します。
  2. 以下のコマンドを実行してデータボリュームを作成します。

    $ oc create -f <upload-datavolume>.yaml

7.18.5.4. ローカルディスクイメージのデータボリュームへのアップロード

virtctl CLI ユーティリティーを使用して、ローカルディスクイメージをクライアントマシンからクラスター内のデータボリューム (DV) にアップロードできます。この手順の実行時に、すでにクラスターに存在する DV を使用するか、または新規の DV を作成することができます。

注記

ローカルディスクイメージのアップロード後に、これを仮想マシンに追加できます。

前提条件

  • 以下のいずれかが必要である。

    • ISO または IMG 形式のいずれかの raw 仮想マシンイメージファイル。
    • QCOW2 形式の仮想マシンのイメージファイル。
  • 最善の結果を得るには、アップロードする前にイメージファイルを以下のガイドラインに従って圧縮すること。

    • xz または gzip を使用して raw イメージファイルを圧縮します。

      注記

      圧縮された raw イメージファイルを使用すると、最も効率的にアップロードできます。

    • クライアントについて推奨される方法を使用して、QCOW2 イメージファイルを圧縮します。

      • Linux クライアントを使用する場合は、virt-sparsify ツールを使用して、QCOW2 ファイルをスパース化 (sparsify) します。
      • Windows クライアントを使用する場合は、xz または gzip を使用して QCOW2 ファイルを圧縮します。
  • kubevirt-virtctl パッケージがクライアントマシンにインストールされていること。
  • クライアントマシンが OpenShift Container Platform ルーターの証明書を信頼するように設定されていること。

手順

  1. 以下を特定します。

    • 使用するアップロードデータボリュームの名前。このデータボリュームが存在しない場合、これは自動的に作成されます。
    • データボリュームのサイズ (アップロード手順の実行時に作成する必要がある場合)。サイズはディスクイメージのサイズ以上である必要があります。
    • アップロードする必要のある仮想マシンディスクイメージのファイルの場所。
  2. virtctl image-upload コマンドを実行してディスクイメージをアップロードします。直前の手順で特定したパラメーターを指定します。以下は例になります。

    $ virtctl image-upload dv <datavolume_name> \ 1
    --size=<datavolume_size> \ 2
    --image-path=</path/to/image> \ 3
    1
    データボリュームの名前。
    2
    データボリュームのサイズ。例: --size=500Mi--size=1G
    3
    仮想マシンディスクイメージのファイルパス。
    注記
    • 新規データボリュームを作成する必要がない場合は、--size パラメーターを省略し、--no-create フラグを含めます。
    • ディスクイメージを PVC にアップロードする場合、PVC サイズは圧縮されていない仮想ディスクのサイズよりも大きくなければなりません。
    • HTTPS を使用したセキュアでないサーバー接続を許可するには、--insecure パラメーターを使用します。--insecure フラグを使用する際に、アップロードエンドポイントの信頼性は検証 されない 点に注意してください。
  3. オプション。データボリュームが作成されたことを確認するには、以下のコマンドを実行してすべてのデータボリュームを表示します。

    $ oc get dvs

7.18.5.5. CDI がサポートする操作マトリックス

このマトリックスにはエンドポイントに対してコンテンツタイプのサポートされる CDI 操作が表示されます。これらの操作にはスクラッチ領域が必要です。

コンテンツタイプHTTPHTTPSHTTP Basic 認証レジストリーアップロード

kubevirt (QCOW2)

✓ QCOW2
✓ GZ*
✓ XZ*

✓ QCOW2**
✓ GZ*
✓ XZ*

✓ QCOW2
✓ GZ*
✓ XZ*

✓ QCOW2*
□ GZ
□ XZ

✓ QCOW2*
✓ GZ*
✓ XZ*

KubeVirt (RAW)

✓ RAW
✓ GZ
✓ XZ

✓ RAW
✓ GZ
✓ XZ

✓ RAW
✓ GZ
✓ XZ

✓ RAW*
□ GZ
□ XZ

✓ RAW*
✓ GZ*
✓ XZ*

✓ サポートされる操作

□ サポートされない操作

* スクラッチ領域が必要

**カスタム認証局が必要な場合にスクラッチ領域が必要

7.18.6. ブロックストレージデータボリュームへのローカルディスクイメージのアップロード

virtctl コマンドラインユーティリティーを使用して、ローカルのディスクイメージをブロックデータボリュームにアップロードできます。

このワークフローでは、ローカルブロックデバイスを使用して永続ボリュームを使用し、このブロックボリュームを upload データボリュームに関連付け、 virtctl を使用してローカルディスクイメージをデータボリュームにアップロードできます。

7.18.6.1. 前提条件

7.18.6.2. データボリュームについて

DataVolume オブジェクトは、Containerized Data Importer (CDI) プロジェクトで提供されるカスタムリソースです。データボリュームは、基礎となる永続ボリューム要求 (PVC) に関連付けられるインポート、クローン作成、およびアップロード操作のオーケストレーションを行います。データボリュームは OpenShift Virtualization に統合され、仮想マシンが PVC の作成前に起動することを防ぎます。

7.18.6.3. ブロック永続ボリュームについて

ブロック永続ボリューム (PV) は、raw ブロックデバイスによってサポートされる PV です。これらのボリュームにはファイルシステムがなく、オーバーヘッドを削減することで、仮想マシンのパフォーマンス上の利点をもたらすことができます。

raw ブロックボリュームは、PV および永続ボリューム要求 (PVC) 仕様で volumeMode: Block を指定してプロビジョニングされます。

7.18.6.4. ローカルブロック永続ボリュームの作成

ファイルにデータを設定し、これをループデバイスとしてマウントすることにより、ノードでローカルブロック永続ボリューム (PV) を作成します。次に、このループデバイスを PV マニフェストで Block ボリュームとして参照し、これを仮想マシンイメージのブロックデバイスとして使用できます。

手順

  1. ローカル PV を作成するノードに root としてログインします。この手順では、node01 を例に使用します。
  2. ファイルを作成して、これを null 文字で設定し、ブロックデバイスとして使用できるようにします。以下の例では、2Gb (20 100Mb ブロック) のサイズのファイル loop10 を作成します。

    $ dd if=/dev/zero of=<loop10> bs=100M count=20
  3. loop10 ファイルをループデバイスとしてマウントします。

    $ losetup </dev/loop10>d3 <loop10> 1 2
    1
    ループデバイスがマウントされているファイルパスです。
    2
    前の手順で作成したファイルはループデバイスとしてマウントされます。
  4. マウントされたループデバイスを参照する PersistentVolume マニフェストを作成します。

    kind: PersistentVolume
    apiVersion: v1
    metadata:
      name: <local-block-pv10>
      annotations:
    spec:
      local:
        path: </dev/loop10> 1
      capacity:
        storage: <2Gi>
      volumeMode: Block 2
      storageClassName: local 3
      accessModes:
        - ReadWriteOnce
      persistentVolumeReclaimPolicy: Delete
      nodeAffinity:
        required:
          nodeSelectorTerms:
          - matchExpressions:
            - key: kubernetes.io/hostname
              operator: In
              values:
              - <node01> 4
    1
    ノード上のループデバイスのパス。
    2
    ブロック PV であることを指定します。
    3
    オプション: PV にストレージクラスを設定します。これを省略する場合、クラスターのデフォルトが使用されます。
    4
    ブロックデバイスがマウントされたノード。
  5. ブロック PV を作成します。

    # oc create -f <local-block-pv10.yaml>1
    1
    直前の手順で作成された永続ボリュームのファイル名。

7.18.6.5. アップロードデータボリュームの作成

ローカルディスクイメージのアップロードに使用する upload データソースでデータボリュームを手動で作成できます。

手順

  1. spec: source: upload{} を指定するデータボリューム設定を作成します。

    apiVersion: cdi.kubevirt.io/v1beta1
    kind: DataVolume
    metadata:
      name: <upload-datavolume> 1
    spec:
      source:
          upload: {}
      pvc:
        accessModes:
          - ReadWriteOnce
        resources:
          requests:
            storage: <2Gi> 2
    1
    データボリュームの名前。
    2
    データボリュームのサイズ。この値がアップロードするディスクのサイズ以上であることを確認します。
  2. 以下のコマンドを実行してデータボリュームを作成します。

    $ oc create -f <upload-datavolume>.yaml

7.18.6.6. ローカルディスクイメージのデータボリュームへのアップロード

virtctl CLI ユーティリティーを使用して、ローカルディスクイメージをクライアントマシンからクラスター内のデータボリューム (DV) にアップロードできます。この手順の実行時に、すでにクラスターに存在する DV を使用するか、または新規の DV を作成することができます。

注記

ローカルディスクイメージのアップロード後に、これを仮想マシンに追加できます。

前提条件

  • 以下のいずれかが必要である。

    • ISO または IMG 形式のいずれかの raw 仮想マシンイメージファイル。
    • QCOW2 形式の仮想マシンのイメージファイル。
  • 最善の結果を得るには、アップロードする前にイメージファイルを以下のガイドラインに従って圧縮すること。

    • xz または gzip を使用して raw イメージファイルを圧縮します。

      注記

      圧縮された raw イメージファイルを使用すると、最も効率的にアップロードできます。

    • クライアントについて推奨される方法を使用して、QCOW2 イメージファイルを圧縮します。

      • Linux クライアントを使用する場合は、virt-sparsify ツールを使用して、QCOW2 ファイルをスパース化 (sparsify) します。
      • Windows クライアントを使用する場合は、xz または gzip を使用して QCOW2 ファイルを圧縮します。
  • kubevirt-virtctl パッケージがクライアントマシンにインストールされていること。
  • クライアントマシンが OpenShift Container Platform ルーターの証明書を信頼するように設定されていること。

手順

  1. 以下を特定します。

    • 使用するアップロードデータボリュームの名前。このデータボリュームが存在しない場合、これは自動的に作成されます。
    • データボリュームのサイズ (アップロード手順の実行時に作成する必要がある場合)。サイズはディスクイメージのサイズ以上である必要があります。
    • アップロードする必要のある仮想マシンディスクイメージのファイルの場所。
  2. virtctl image-upload コマンドを実行してディスクイメージをアップロードします。直前の手順で特定したパラメーターを指定します。以下は例になります。

    $ virtctl image-upload dv <datavolume_name> \ 1
    --size=<datavolume_size> \ 2
    --image-path=</path/to/image> \ 3
    1
    データボリュームの名前。
    2
    データボリュームのサイズ。例: --size=500Mi--size=1G
    3
    仮想マシンディスクイメージのファイルパス。
    注記
    • 新規データボリュームを作成する必要がない場合は、--size パラメーターを省略し、--no-create フラグを含めます。
    • ディスクイメージを PVC にアップロードする場合、PVC サイズは圧縮されていない仮想ディスクのサイズよりも大きくなければなりません。
    • HTTPS を使用したセキュアでないサーバー接続を許可するには、--insecure パラメーターを使用します。--insecure フラグを使用する際に、アップロードエンドポイントの信頼性は検証 されない 点に注意してください。
  3. オプション。データボリュームが作成されたことを確認するには、以下のコマンドを実行してすべてのデータボリュームを表示します。

    $ oc get dvs

7.18.6.7. CDI がサポートする操作マトリックス

このマトリックスにはエンドポイントに対してコンテンツタイプのサポートされる CDI 操作が表示されます。これらの操作にはスクラッチ領域が必要です。

コンテンツタイプHTTPHTTPSHTTP Basic 認証レジストリーアップロード

kubevirt (QCOW2)

✓ QCOW2
✓ GZ*
✓ XZ*

✓ QCOW2**
✓ GZ*
✓ XZ*

✓ QCOW2
✓ GZ*
✓ XZ*

✓ QCOW2*
□ GZ
□ XZ

✓ QCOW2*
✓ GZ*
✓ XZ*

KubeVirt (RAW)

✓ RAW
✓ GZ
✓ XZ

✓ RAW
✓ GZ
✓ XZ

✓ RAW
✓ GZ
✓ XZ

✓ RAW*
□ GZ
□ XZ

✓ RAW*
✓ GZ*
✓ XZ*

✓ サポートされる操作

□ サポートされない操作

* スクラッチ領域が必要

**カスタム認証局が必要な場合にスクラッチ領域が必要

7.18.7. オフラインの仮想マシンスナップショットの管理

オフ (オフライン) になっている仮想マシンの仮想マシン (VM) スナップショットを作成し、復元し、削除できます。OpenShift Virtualization は、以下でオフラインの仮想マシンスナップショットをサポートします。

  • Red Hat OpenShift Container Storage
  • Kubernetes Volume Snapshot API をサポートする Container Storage Interface (CSI) ドライバーを使用するその他のストレージプロバイダー

7.18.7.1. 仮想マシンスナップショットについて

スナップショット は、特定の時点における仮想マシン (VM) の状態およびデータを表します。スナップショットを使用して、バックアップおよび障害復旧のために既存の仮想マシンを (スナップショットで表される) 以前の状態に復元したり、以前の開発バージョンに迅速にロールバックしたりできます。

オフラインの仮想マシンのスナップショットは、電源がオフになった (停止状態の) 仮想マシンから作成されます。スナップショットは、仮想マシンに割り当てられた各 Container Storage Interface (CSI) ボリュームのコピーと、仮想マシンの仕様およびメタデータのコピーを保存します。スナップショットは作成後に変更できません。

オフラインの仮想マシンスナップショット機能を使用すると、クラスター管理者、およびアプリケーション開発者は以下を実行できます。

  • 新規 SCC の作成
  • 特定の仮想マシンに割り当てられているすべてのスナップショットの一覧表示
  • スナップショットからの仮想マシンの復元
  • 既存の仮想マシンスナップショットの削除
7.18.7.1.1. 仮想マシンスナップショットコントローラーおよびカスタムリソース定義 (CRD)

仮想マシンスナップショット機能では、スナップショットを管理するための CRD として定義された 3 つの新規 API オブジェクトが導入されました。

  • VirtualMachineSnapshot: スナップショットを作成するユーザー要求を表します。これには、仮想マシンの現在の状態に関する情報が含まれます。
  • VirtualMachineSnapshotContent: クラスター上のプロビジョニングされたリソース (スナップショット) を表します。これは、仮想マシンのスナップショットコントローラーによって作成され、仮想マシンの復元に必要なすべてのリソースへの参照が含まれます。
  • VirtualMachineRestore: スナップショットから仮想マシンを復元するユーザー要求を表します。

仮想マシンスナップショットコントローラーは、1 対 1 のマッピングで、VirtualMachineSnapshotContent オブジェクトを、この作成に使用した VirtualMachineSnapshot オブジェクトにバインドします。

7.18.7.2. CLI でのオフライン仮想マシンスナップショットの作成

VirtualMachineSnapshot オブジェクトを作成し、オフライン仮想マシンの仮想マシン (VM) スナップショットを作成できます。

前提条件

  • 永続ボリューム要求 (PVC) が Container Storage Interface (CSI) ボリュームスナップショットをサポートするストレージクラスにあることを確認する。
  • OpenShift CLI (oc) をインストールすること。
  • スナップショットを作成する仮想マシンの電源を切ること。

手順

  1. YAML ファイルを作成し、新規の VirtualMachineSnapshot の名前およびソース仮想マシンの名前を指定する VirtualMachineSnapshot オブジェトを定義します。

    以下は例になります。

    apiVersion: snapshot.kubevirt.io/v1alpha1
    kind: VirtualMachineSnapshot
    metadata:
      name: my-vmsnapshot 1
    spec:
      source:
        apiGroup: kubevirt.io
        kind: VirtualMachine
        name: my-vm 2
    1
    新規 VirtualMachineSnapshot オブジェクトの名前。
    2
    ソース仮想マシンの名前。
  2. VirtualMachineSnapshot リソースを作成します。スナップコントローラーは VirtualMachineSnapshotContent オブジェクトを作成し、これを VirtualMachineSnapshot にバインドし、 VirtualMachineSnapshot オブジェクトの status および readyToUse フィールドを更新します。

    $ oc create -f <my-vmsnapshot>.yaml

検証

  1. VirtualMachineSnapshot オブジェクトが作成されており、VirtualMachineSnapshotContent にバインドされていることを確認します。readyToUse フラグを true に設定する必要があります。

    $ oc describe vmsnapshot <my-vmsnapshot>

    出力例

    apiVersion: snapshot.kubevirt.io/v1alpha1
    kind: VirtualMachineSnapshot
    metadata:
    creationTimestamp: "2020-09-30T14:41:51Z"
    finalizers:
    - snapshot.kubevirt.io/vmsnapshot-protection
    generation: 5
    name: mysnap
    namespace: default
    resourceVersion: "3897"
    selfLink: /apis/snapshot.kubevirt.io/v1alpha1/namespaces/default/virtualmachinesnapshots/my-vmsnapshot
    uid: 28eedf08-5d6a-42c1-969c-2eda58e2a78d
    spec:
    source:
    apiGroup: kubevirt.io
    kind: VirtualMachine
    name: my-vm
    status:
    conditions:
      - lastProbeTime: null
      lastTransitionTime: "2020-09-30T14:42:03Z"
      reason: Operation complete
      status: "False" 1
      type: Progressing
      - lastProbeTime: null
      lastTransitionTime: "2020-09-30T14:42:03Z"
      reason: Operation complete
      status: "True" 2
      type: Ready
    creationTime: "2020-09-30T14:42:03Z"
    readyToUse: true 3
    sourceUID: 355897f3-73a0-4ec4-83d3-3c2df9486f4f
    virtualMachineSnapshotContentName: vmsnapshot-content-28eedf08-5d6a-42c1-969c-2eda58e2a78d 4

    1
    Progressing 状態の status フィールドは、スナップショットが作成中であるかどうかを指定します。
    2
    Ready 状態の status フィールドは、スナップショットの作成プロセスが完了しているかどうかを指定します。
    3
    スナップショットを使用する準備ができているかどうかを指定します。
    4
    スナップショットが、スナップショットコントローラーで作成される VirtualMachineSnapshotContent オブジェクトにバインドされるように指定します。
  2. VirtualMachineSnapshotContent リソースの spec:volumeBackups プロパティーをチェックし、予想される PVC がスナップショットに含まれることを確認します。

7.18.7.3. CLI でのスナップショットからの仮想マシンの復元

仮想マシンスナップショットを使用して、既存の仮想マシン (VM) を以前の設定に復元できます。

前提条件

  • OpenShift CLI (oc) をインストールすること。
  • 以前の状態に復元する仮想マシンの電源を切ること。

手順

  1. 復元する仮想マシンの名前およびソースとして使用されるスナップショットの名前を指定する VirtualMachineRestore オブジェクトを定義するために YAML ファイルを作成します。

    以下は例になります。

    apiVersion: snapshot.kubevirt.io/v1alpha1
    kind: VirtualMachineRestore
    metadata:
      name: my-vmrestore 1
    spec:
      target:
        apiGroup: kubevirt.io
        kind: VirtualMachine
        name: my-vm 2
      virtualMachineSnapshotName: my-vmsnapshot 3
    1
    新規 VirtualMachineRestore オブジェクトの名前。
    2
    復元するターゲット仮想マシンの名前。
    3
    ソースとして使用する VirtualMachineSnapshot オブジェクトの名前。
  2. VirtualMachineRestore リソースを作成します。スナップショットコントローラーは、VirtualMachineRestore オブジェクトのステータスフィールドを更新し、既存の仮想マシン設定をスナップショットのコンテンツに置き換えます。

    $ oc create -f <my-vmrestore>.yaml

検証

  • 仮想マシンがスナップショットで表される以前の状態に復元されていることを確認します。complete フラグは true に設定される必要があります。

    $ oc get vmrestore <my-vmrestore>

    出力例

    apiVersion: snapshot.kubevirt.io/v1alpha1
    kind: VirtualMachineRestore
    metadata:
    creationTimestamp: "2020-09-30T14:46:27Z"
    generation: 5
    name: my-vmrestore
    namespace: default
    ownerReferences:
    - apiVersion: kubevirt.io/v1alpha3
    blockOwnerDeletion: true
    controller: true
    kind: VirtualMachine
    name: my-vm
    uid: 355897f3-73a0-4ec4-83d3-3c2df9486f4f
    resourceVersion: "5512"
    selfLink: /apis/snapshot.kubevirt.io/v1alpha1/namespaces/default/virtualmachinerestores/my-vmrestore
    uid: 71c679a8-136e-46b0-b9b5-f57175a6a041
    spec:
    target:
    apiGroup: kubevirt.io
    kind: VirtualMachine
    name: my-vm
    virtualMachineSnapshotName: my-vmsnapshot
    status:
    complete: true 1
    conditions:
    - lastProbeTime: null
    lastTransitionTime: "2020-09-30T14:46:28Z"
    reason: Operation complete
    status: "False" 2
    type: Progressing
    - lastProbeTime: null
    lastTransitionTime: "2020-09-30T14:46:28Z"
    reason: Operation complete
    status: "True" 3
    type: Ready
    deletedDataVolumes:
    - test-dv1
    restoreTime: "2020-09-30T14:46:28Z"
    restores:
    - dataVolumeName: restore-71c679a8-136e-46b0-b9b5-f57175a6a041-datavolumedisk1
    persistentVolumeClaim: restore-71c679a8-136e-46b0-b9b5-f57175a6a041-datavolumedisk1
    volumeName: datavolumedisk1
    volumeSnapshotName: vmsnapshot-28eedf08-5d6a-42c1-969c-2eda58e2a78d-volume-datavolumedisk1

    1
    仮想マシンをスナップショットで表される状態に復元するプロセスが完了しているかどうかを指定します。
    2
    Progressing 状態の status フィールドは、仮想マシンが復元されているかどうかを指定します。
    3
    Ready 状態の status フィールドは、仮想マシンの復元プロセスが完了しているかどうかを指定します。

7.18.7.4. CLI での仮想マシンのスナップショットの削除

適切な VirtualMachineSnapshot オブジェクトを削除して、既存の仮想マシン (VM) スナップショットを削除できます。

前提条件

  • OpenShift CLI (oc) をインストールすること。

手順

  • VirtualMachineSnapshot オブジェクトを削除します。スナップショットコントローラーは、VirtualMachineSnapshot を、関連付けられた VirtualMachineSnapshotContent オブジェクトと共に削除します。

    $ oc delete vmsnapshot <my-vmsnapshot>

検証

  • スナップショットが削除され、この仮想マシンに割り当てられていないことを確認します。

    $ oc get vmsnapshot

7.18.7.5. 追加リソース

7.18.8. ローカル仮想マシンディスクの別のノードへの移動

ローカルボリュームストレージを使用する仮想マシンは、特定のノードで実行されるように移動することができます。

以下の理由により、仮想マシンを特定のノードに移動する場合があります。

  • 現在のノードにローカルストレージ設定に関する制限がある。
  • 新規ノードがその仮想マシンのワークロードに対して最適化されている。

ローカルストレージを使用する仮想マシンを移行するには、データボリュームを使用して基礎となるボリュームのクローンを作成する必要があります。クローン操作が完了したら、新規データボリュームを使用できるように仮想マシン設定を編集するか、または新規データボリュームを別の仮想マシンに追加できます。

注記

cluster-admin ロールのないユーザーには、複数の namespace 間でボリュームのクローンを作成できるように追加のユーザーパーミッションが必要になります。

7.18.8.1. ローカルボリュームの別のノードへのクローン作成

基礎となる永続ボリューム要求 (PVC) のクローンを作成して、仮想マシンディスクを特定のノードで実行するように移行することができます。

仮想マシンディスクのノードが適切なノードに作成されることを確認するには、新規の永続ボリューム (PV) を作成するか、または該当するノードでそれを特定します。一意のラベルを PV に適用し、これがデータボリュームで参照できるようにします。

注記

宛先 PV のサイズはソース PVC と同じか、またはそれよりも大きくなければなりません。宛先 PV がソース PVC よりも小さい場合、クローン作成操作は失敗します。

前提条件

  • 仮想マシンが実行されていないこと。仮想マシンディスクのクローンを作成する前に、仮想マシンの電源を切ります。

手順

  1. ノードに新規のローカル PV を作成するか、またはノードにすでに存在しているローカル PV を特定します。

    • nodeAffinity.nodeSelectorTerms パラメーターを含むローカル PV を作成します。以下のマニフェストは、node0110Gi のローカル PV を作成します。

      kind: PersistentVolume
      apiVersion: v1
      metadata:
        name: <destination-pv> 1
        annotations:
      spec:
        accessModes:
        - ReadWriteOnce
        capacity:
          storage: 10Gi 2
        local:
          path: /mnt/local-storage/local/disk1 3
        nodeAffinity:
          required:
            nodeSelectorTerms:
            - matchExpressions:
              - key: kubernetes.io/hostname
                operator: In
                values:
                - node01 4
        persistentVolumeReclaimPolicy: Delete
        storageClassName: local
        volumeMode: Filesystem
      1
      PV の名前。
      2
      PV のサイズ。十分な領域を割り当てる必要があります。そうでない場合には、クローン操作は失敗します。サイズはソース PVC と同じか、またはそれよりも大きくなければなりません。
      3
      ノードのマウントパス。
      4
      PV を作成するノードの名前。
    • ターゲットノードに存在する PV を特定します。設定の nodeAffinity フィールドを確認して、PV がプロビジョニングされるノードを特定することができます。

      $ oc get pv <destination-pv> -o yaml

      以下のスニペットは、PV が node01 にあることを示しています。

      出力例

      ...
      spec:
        nodeAffinity:
          required:
            nodeSelectorTerms:
            - matchExpressions:
              - key: kubernetes.io/hostname 1
                operator: In
                values:
                - node01 2
      ...

      1
      kubernetes.io/hostname キーでは、ノードを選択するためにノードホスト名を使用します。
      2
      ノードのホスト名です。
  2. PV に一意のラベルを追加します。

    $ oc label pv <destination-pv> node=node01
  3. 以下を参照するデータボリュームマニフェストを作成します。

    • 仮想マシンの PVC 名と namespace。
    • 直前の手順で PV に適用されたラベル。
    • 宛先 PV のサイズ。

      apiVersion: cdi.kubevirt.io/v1beta1
      kind: DataVolume
      metadata:
        name: <clone-datavolume> 1
      spec:
        source:
          pvc:
            name: "<source-vm-disk>" 2
            namespace: "<source-namespace>" 3
        pvc:
          accessModes:
            - ReadWriteOnce
          selector:
            matchLabels:
              node: node01 4
          resources:
            requests:
              storage: <10Gi> 5
      1
      新規データボリュームの名前。
      2
      ソース PVC の名前。PVC 名が分からない場合は、仮想マシン設定 spec.volumes.persistentVolumeClaim.claimName で確認できます。
      3
      ソース PVC が存在する namespace。
      4
      直前の手順で PV に追加したラベル。
      5
      宛先 PV のサイズ。
  4. データボリュームマニフェストをクラスターに適用してクローン作成の操作を開始します。

    $ oc apply -f <clone-datavolume.yaml>

データボリュームは、仮想マシンの PVC のクローンを特定のノード上の PV に作成します。

7.18.9. 空のディスクイメージを追加して仮想ストレージを拡張する

空のディスクイメージを OpenShift Virtualization に追加することによって、ストレージ容量を拡張したり、新規のデータパーティションを作成したりできます。

7.18.9.1. データボリュームについて

DataVolume オブジェクトは、Containerized Data Importer (CDI) プロジェクトで提供されるカスタムリソースです。データボリュームは、基礎となる永続ボリューム要求 (PVC) に関連付けられるインポート、クローン作成、およびアップロード操作のオーケストレーションを行います。データボリュームは OpenShift Virtualization に統合され、仮想マシンが PVC の作成前に起動することを防ぎます。

7.18.9.2. データボリュームを使用した空のディスクイメージの作成

データボリューム設定ファイルをカスタマイズし、デプロイすることにより、新規の空のディスクイメージを永続ボリューム要求 (PVC) に作成することができます。

前提条件

  • 1 つ以上の利用可能な永続ボリュームがあること。
  • OpenShift CLI (oc) をインストールすること。

手順

  1. データボリューム設定ファイルを編集します。

    apiVersion: cdi.kubevirt.io/v1beta1
    kind: DataVolume
    metadata:
      name: blank-image-datavolume
    spec:
      source:
          blank: {}
      pvc:
        # Optional: Set the storage class or omit to accept the default
        # storageClassName: "hostpath"
        accessModes:
          - ReadWriteOnce
        resources:
          requests:
            storage: 500Mi
  2. 以下のコマンドを実行して、空のディスクイメージを作成します。

    $ oc create -f <blank-image-datavolume>.yaml

7.18.9.3. テンプレート: 空のディスクイメージのデータボリューム設定ファイル

blank-image-datavolume.yaml

apiVersion: cdi.kubevirt.io/v1beta1
kind: DataVolume
metadata:
  name: blank-image-datavolume
spec:
  source:
      blank: {}
  pvc:
    # Optional: Set the storage class or omit to accept the default
    # storageClassName: "hostpath"
    accessModes:
      - ReadWriteOnce
    resources:
      requests:
        storage: 500Mi

7.18.10. smart-cloning を使用したデータボリュームのクローン作成

smart-cloning は OpenShift Container Platform Storage (OCS) のビルトイン機能であり、クローン作成プロセスのパフォーマンスを強化するように設計されています。smart-cloning で作成したクローンは、ホスト支援型のクローン作成よりも速く、効率的です。

smart-cloning を有効にするためにアクションを実行する必要はありませんが、この機能を使用するには、ストレージ環境が smart-cloning と互換性があることを確認する必要があります。

永続ボリューム要求 (PVC) ソースでデータボリュームを作成すると、クローン作成プロセスが自動的に開始します。お使いの環境で smart-cloning をサポートするかどうかにかかわらず、データボリュームのクローンは常に受信できます。ただし、ストレージプロバイダーが smart-cloning に対応している場合、smart-cloning によるパフォーマンス上のメリットが得られます。

7.18.10.1. smart-cloning について

データボリュームに smart-cloning が実行された場合、以下が発生します。

  1. ソースの永続ボリューム要求 (PVC) のスナップショットが作成されます。
  2. PVC はスナップショットから作成されます。
  3. スナップショットは削除されます。

7.18.10.2. データボリュームのクローン作成

前提条件

smart-cloning が実行されるには、以下の条件が必要です。

  • ストレージプロバイダーはスナップショットをサポートする必要がある。
  • ソースおよびターゲット PVC は、同じ namespace に定義される必要がある。
  • ソースおよびターゲット PVC は、同じストレージクラスに定義される必要がある。
  • VolumeSnapshotClass オブジェクトは、ソースおよびターゲット PVC の両方に定義されるストレージクラスを参照する必要がある。

これらの前提条件のいずれかが満たされない場合、PVC ソースでデータボリュームを作成すると、ホスト支援型クローンが自動的に実行されます。

手順

データボリュームのクローン作成を開始するには、以下を実行します。

  1. 新規データボリュームの名前、ソース PVC の名前および namespace、および新規データボリュームのサイズを指定する DataVolume オブジェクトの YAML ファイルを作成します。この例では、ソース PVC のクローンをブロックモードで作成し、volumeMode: Block が使用されます。

    apiVersion: cdi.kubevirt.io/v1beta1
    kind: DataVolume
    metadata:
      name: <cloner-datavolume> 1
    spec:
      source:
        pvc:
          namespace: "<source-namespace>" 2
          name: "<my-favorite-vm-disk>" 3
      pvc:
        accessModes:
          - ReadWriteMany
        resources:
          requests:
            storage: <2Gi> 4
        volumeMode: Block 5
    1
    新規データボリュームの名前。
    2
    ソース PVC が存在する namespace。
    3
    ソース PVC の名前。
    4
    新規データボリュームのサイズ。十分な領域を割り当てる必要があります。そうでない場合には、クローン操作は失敗します。サイズはソース PVC と同じか、またはそれよりも大きくなければなりません。
    5
    宛先がブロック PV であることを指定します。
  2. データボリュームを作成して PVC のクローン作成を開始します。

    $ oc create -f <cloner-datavolume>.yaml
    注記

    データボリュームは仮想マシンが PVC の作成前に起動することを防ぐため、PVC のクローン作成中に新規データボリュームを参照する仮想マシンを作成できます。

7.18.10.3. 追加リソース

7.18.11. データボリュームのストレージのデフォルト

kubevirt-storage-class-defaults 設定マップはデータボリュームの アクセスモード および ボリュームモード のデフォルト設定を提供します。Web コンソールで、基礎となるストレージにより適したデータボリュームを作成するために、設定マップに対してストレージクラスのデフォルトを編集したり、追加したりできます。

7.18.11.1. データボリュームのストレージ設定について

データボリュームでは、定義された アクセスモードボリュームモード を Web コンソールで作成する必要があります。これらのストレージ設定は、デフォルトで ReadWriteOnce アクセスモードおよび Filesystem ボリュームモードで設定されます。

これらの設定は、openshift-cnv namespace で kubevirt-storage-class-defaults 設定マップを編集して変更できます。また、異なるストレージタイプについて Web コンソールでデータボリュームを作成するために、他のストレージクラスの設定を追加することもできます。

注記

基礎となるストレージでサポートされるストレージ設定を設定する必要があります。

Web コンソールで作成するすべてのデータボリュームは、設定マップにも定義されるストレージクラスを指定しない限り、デフォルトのストレージ設定を使用します。

7.18.11.1.1. アクセスモード

データボリュームは以下のアクセスモードをサポートします。

  • ReadWriteOnce: ボリュームは単一ノードで、read-write としてマウントできます。ReadWriteOnce にはより多様性があり、これはデフォルトの設定です。
  • ReadWriteMany: ボリュームは数多くのノードで、read-write としてマウントできます。ReadWriteMany は、ノード間の仮想マシンのライブマイグレーションなどの、一部の機能で必要になります。

ReadWriteMany は、基礎となるストレージがこれをサポートしている場合に推奨されます。

7.18.11.1.2. ボリュームモード

ボリュームモードは、ボリュームをフォーマットされたファイルシステムで使用するか、または raw ブロック状態のままにするかを定義します。データボリュームは以下のボリュームモードをサポートします。

  • Filesystem: データボリュームにファイルシステムを作成します。これはデフォルトの設定です。
  • Block: ブロックデータボリュームを作成します。基礎となるストレージがサポートしている場合は、 Block を使用します。

7.18.11.2. Web コンソールでの kubevirt-storage-class-defaults 設定マップの編集

データボリュームのストレージ設定を、openshift-cnv namespace の kubevirt-storage-class-defaults 設定マップを編集して変更します。また、異なるストレージタイプについて Web コンソールでデータボリュームを作成するために、他のストレージクラスの設定を追加することもできます。

注記

基礎となるストレージでサポートされるストレージ設定を設定する必要があります。

手順

  1. サイドメニューから、WorkloadsConfig Maps をクリックします。
  2. Project 一覧で、openshift-cnv を選択します。
  3. kubevirt-storage-class-defaults をクリックして Config Map Overview を開きます。
  4. YAML タブをクリックして編集可能な設定を表示します。
  5. 基礎となるストレージに適したストレージ設定で data の値を更新します。

    ...
    data:
      accessMode: ReadWriteOnce 1
      volumeMode: Filesystem 2
      <new>.accessMode: ReadWriteMany 3
      <new>.volumeMode: Block 4
    1
    デフォルトの accessMode は ReadWriteOnce です。
    2
    デフォルトの volumeMode は Filesystem です。
    3
    ストレージクラスのアクセスモードを追加する場合は、パラメーターの <new> 部分をストレージクラス名に置き換えます。
    4
    ストレージクラスのボリュームモードを追加する場合は、パラメーターの <new> 部分をストレージクラス名に置き換えます。
  6. Save をクリックして設定マップを更新します。

7.18.11.3. CLI での kubevirt-storage-class-defaults 設定マップの編集

データボリュームのストレージ設定を、openshift-cnv namespace の kubevirt-storage-class-defaults 設定マップを編集して変更します。また、異なるストレージタイプについて Web コンソールでデータボリュームを作成するために、他のストレージクラスの設定を追加することもできます。

注記

基礎となるストレージでサポートされるストレージ設定を設定する必要があります。

手順

  1. 以下のコマンドを実行して設定マップを編集します。

    $ oc edit configmap kubevirt-storage-class-defaults -n openshift-cnv
  2. 設定マップの data 値を更新します。

    ...
    data:
      accessMode: ReadWriteOnce 1
      volumeMode: Filesystem 2
      <new>.accessMode: ReadWriteMany 3
      <new>.volumeMode: Block 4
    1
    デフォルトの accessMode は ReadWriteOnce です。
    2
    デフォルトの volumeMode は Filesystem です。
    3
    ストレージクラスのアクセスモードを追加する場合は、パラメーターの <new> 部分をストレージクラス名に置き換えます。
    4
    ストレージクラスのボリュームモードを追加する場合は、パラメーターの <new> 部分をストレージクラス名に置き換えます。
  3. エディターを保存し、終了して設定マップを更新します。

7.18.11.4. 複数のストレージクラスのデフォルト例

以下の YAML ファイルは、kubevirt-storage-class-defaults 設定マップの例です。これには、migration および block の 2 つのストレージクラスについてストレージが設定されます。

設定マップを更新する前に、すべての設定が基礎となるストレージでサポートされていることを確認してください。

kind: ConfigMap
apiVersion: v1
metadata:
  name: kubevirt-storage-class-defaults
  namespace: openshift-cnv
...
data:
  accessMode: ReadWriteOnce
  volumeMode: Filesystem
  nfs-sc.accessMode: ReadWriteMany
  nfs-sc.volumeMode: Filesystem
  block-sc.accessMode: ReadWriteMany
  block-sc.volumeMode: Block

7.18.12. デフォルトの OS イメージの作成および使用

デフォルトのオペレーティングシステム (OS) イメージ は、OS とドライバーなどの OS のすべての設定を含む起動可能なディスクです。デフォルトの OS イメージを使用して、特定の設定で起動可能な仮想マシンを作成します。

デフォルトの OS イメージを使用するには、最新バージョンの OpenShift Virtualization をインストールする必要があります。次に、OpenShift Container Platform Web コンソールを使用してデフォルトの OS イメージを PVC にアップロードし、 永続ボリューム要求 (PVC)を作成します。アップロード後に、Web コンソールでウィザードを使用してアップロードしたイメージから仮想マシンまたは仮想マシンテンプレートを作成します。

7.18.12.1. デフォルトの OS イメージを保存する永続ボリューム要求 (PVC)の作成

以下の手順に従って、デフォルトのオペレーティングシステム (OS) イメージをアップロードし、保存するのに使用する Persistent Volume Claim(永続ボリューム要求、PVC)を作成します。

前提条件

  • os-images.kubevirt.io:edit RBAC ロールを持つユーザー、または管理者としてログインしている。

手順

  1. デフォルトの OS イメージとしてアップロードして保存する起動可能なディスクのローカルイメージを選択します。
  2. OpenShift Container Platform Web コンソールで、サイドバーメニューから Storage > Persistent Volume Claims をクリックします。Persistent Volume Claim ページが表示されます。
  3. Create Persistent Volume Claim ボタンをクリックし、With Data upload form オプションを選択します。
  4. デフォルト OS イメージをアップロードし、保存するために使用される PVC を作成するために、Upload Data to Persistent Volume Claim フォームを完了します。

    1. Browse をクリックして、起動可能なイメージを特定して、デフォルトの OS イメージとしてアップロードし、保存します。
    2. Attach this data to a Virtual Machine operating system チェックボックスを選択します。
    3. Operating System 一覧からアップロードする必要のある起動可能なディスクの OS を選択します。
    4. Storage Class 一覧で使用するストレージクラスを選択します。
    5. Size フィールドに作成する PVC のサイズを入力します。
    6. Access Mode を選択します。
    7. Create をクリックして PVC を作成します。

    Persistent Volume Claim Details 画面には、作成した PVC についての情報が表示されます。

7.18.12.2. デフォルト OS イメージからの仮想マシンの作成

デフォルトのオペレーティングシステム (OS) イメージの永続ボリューム要求 (PVC)を作成した後に、PVC にアップロードしたデフォルトの OS イメージから新規の仮想マシンまたは仮想マシンテンプレートを作成します。

注記

管理者以外のユーザー権限で、デフォルトの OS イメージから仮想マシンおよび仮想マシンテンプレートを作成できます。デフォルトの OS イメージを PVC にアップロードし、保存するには、管理者権限が必要です。

前提条件

  • PVC の作成時に、Attach this data to a Virtual Machine operating system チェックボックスを選択している。

手順

  1. OpenShift Container Platform Web コンソールで、サイドメニューから Workloads > Virtualization をクリックします。Virtualization ページが表示されます。Web コンソールのヘルプまたは既存のドキュメントを使用して仮想マシンテンプレートを作成します。
  2. アップロードしたデフォルト OS イメージから仮想マシンまたは仮想マシンテンプレートを作成します。

    1. Create Virtual Machine > New with Wizard を選択します。Create Virtual Machine ウィザードが表示されます。
    2. General ウィザードページで、OS およびバージョン名の横にある (Source available) ラベルを表示する Operating System から OS を選択します。(Source available) ラベルは、デフォルトの OS イメージがこの OS で利用可能であることを示します。
    3. Clone available operating system source チェックボックスが選択されていることを確認します。
    4. Review and Confirm ボタンをクリックします。
    5. Review and confirm your settings ウィザードページで、仮想マシンについての情報を確認し、必要な場合はこれを変更します。
    6. Create Virtual Machine をクリックし、仮想マシンを作成します。「Successfully created virtual machine」ページが See virtual machine details または Go to list へのリンクと共に表示され、仮想マシンおよび仮想マシンテンプレートの一覧が表示されます。

7.18.12.3. 追加リソース

7.18.13. 仮想マシンでのコンテナーディスクの使用

仮想マシンイメージをコンテナーディスクにビルドし、これをコンテナーレジストリーに保存することができます。次に、コンテナーディスクを仮想マシンの永続ストレージにインポートしたり、一時ストレージの仮想マシンに直接割り当てたりすることができます。

7.18.13.1. コンテナーディスクについて

コンテナーディスクは、コンテナーイメージレジストリーにコンテナーイメージとして保存される仮想マシンのイメージです。コンテナーディスクを使用して、同じディスクイメージを複数の仮想マシンに配信し、多数の仮想マシンのクローンを作成することができます。

コンテナーディスクは、仮想マシンに割り当てられるデータボリュームを使用して永続ボリューム要求 (PVC) にインポートするか、または一時 containerDisk ボリュームとして仮想マシンに直接割り当てることができます。

7.18.13.1.1. データボリュームの使用によるコンテナーディスクの PVC へのインポート

Containerized Data Importer (CDI) を使用し、データボリュームを使用してコンテナーディスクを PVC にインポートします。次に、データボリュームを永続ストレージの仮想マシンに割り当てることができます。

7.18.13.1.2. コンテナーディスクの containerDisk ボリュームとしての仮想マシンへの割り当て

containerDisk ボリュームは一時的なボリュームです。これは、仮想マシンが停止されるか、再起動するか、または削除される際に破棄されます。containerDisk ボリュームを持つ仮想マシンが起動すると、コンテナーイメージはレジストリーからプルされ、仮想マシンをホストするノードでホストされます。

containerDisk ボリュームは、CD-ROM などの読み取り専用ファイルシステム用に、または破棄可能な仮想マシン用に使用します。

重要

データはホストノードのローカルストレージに一時的に書き込まれるため、読み取り/書き込みファイルシステムに containerDisk ボリュームを使用することは推奨されません。これにより、データを移行先ノードに移行する必要があるため、ノードのメンテナンス時など、仮想マシンのライブマイグレーションが遅くなります。さらに、ノードの電源が切れた場合や、予期せずにシャットダウンする場合にすべてのデータが失われます。

7.18.13.2. 仮想マシン用のコンテナーディスクの準備

仮想マシンイメージでコンテナーディスクをビルドし、これを仮想マシンで使用する前にこれをコンテナーレジストリーにプッシュする必要があります。次に、データボリュームを使用してコンテナーディスクを PVC にインポートし、これを仮想マシンに割り当てるか、またはコンテナーディスクを一時的な containerDisk ボリュームとして仮想マシンに直接割り当てることができます。

前提条件

  • podman がインストールされていない場合はインストールすること。
  • 仮想マシンイメージは QCOW2 または RAW 形式のいずれかであること。

手順

  1. Dockerfile を作成して、仮想マシンイメージをコンテナーイメージにビルドします。仮想マシンイメージは、UID が 107 の QEMU で所有され、コンテナー内の /disk/ ディレクトリーに置かれる必要があります。次に、/disk/ ディレクトリーのパーミッションは 0440 に設定する必要があります。

    以下の例では、Red Hat Universal Base Image (UBI) を使用して最初の段階でこれらの設定変更を処理し、2 番目の段階で最小の scratch イメージを使用して結果を保存します。

    $ cat > Dockerfile << EOF
    FROM registry.access.redhat.com/ubi8/ubi:latest AS builder
    ADD --chown=107:107 <vm_image>.qcow2 /disk/ 1
    RUN chmod 0440 /disk/*
    
    FROM scratch
    COPY --from=builder /disk/* /disk/
    EOF
    1
    ここで、<vm_image> は QCOW2 または RAW 形式の仮想マシンイメージです。
    リモートの仮想マシンイメージを使用するには、<vm_image>.qcow2 をリモートイメージの完全な URL に置き換えます。
  2. コンテナーをビルドし、これにタグ付けします。

    $ podman build -t <registry>/<container_disk_name>:latest .
  3. コンテナーイメージをレジストリーにプッシュします。

    $ podman push <registry>/<container_disk_name>:latest

コンテナーレジストリーに TLS がない場合は、コンテナーディスクを永続ストレージにインポートする前に非セキュアなレジストリーとしてこれを追加する必要があります。

7.18.13.3. 非セキュアなレジストリーとして使用するコンテナーレジストリーの TLS の無効化

レジストリーを cdi-insecure-registries 設定マップに追加することで、コンテナーレジストリーの TLS (トランスポート層セキュリティー) を無効にできます。

前提条件

  • cluster-admin ロールを持つユーザーとしてクラスターにログインすること。

手順

  • レジストリーを cdi namespace の cdi-insecure-registries 設定マップに追加します。

    $ oc patch configmap cdi-insecure-registries -n cdi \
      --type merge -p '{"data":{"mykey": "<insecure-registry-host>:5000"}}' 1
    1
    <insecure-registry-host> をレジストリーのホスト名に置き換えます。

7.18.13.4. 次のステップ

7.18.14. CDI のスクラッチ領域の用意

7.18.14.1. データボリュームについて

DataVolume オブジェクトは、Containerized Data Importer (CDI) プロジェクトで提供されるカスタムリソースです。データボリュームは、基礎となる永続ボリューム要求 (PVC) に関連付けられるインポート、クローン作成、およびアップロード操作のオーケストレーションを行います。データボリュームは OpenShift Virtualization に統合され、仮想マシンが PVC の作成前に起動することを防ぎます。

7.18.14.2. スクラッチ領域について

Containerized Data Importer (CDI) では、仮想マシンイメージのインポートやアップロードなどの、一部の操作を実行するためにスクラッチ領域 (一時ストレージ) が必要になります。このプロセスで、CDI は、宛先データボリューム (DV) をサポートする PVC のサイズと同じサイズのスクラッチ領域 PVC をプロビジョニングします。スクラッチ領域 PVC は操作の完了または中止後に削除されます。

CDIConfig オブジェクトにより、scratchSpaceStorageClassCDIConfig オブジェクトの spec: セクションに設定して、スクラッチ領域 PVC をバインドするために使用するストレージクラスを定義することができます。

定義されたストレージクラスがクラスターのストレージクラスに一致しない場合、クラスターに定義されたデフォルトのストレージクラス が使用されます。クラスターで定義されたデフォルトのストレージクラスがない場合、元の DV または PVC のプロビジョニングに使用されるストレージクラスが使用されます。

注記

CDI では、元のデータボリュームをサポートする PVC の種類を問わず、file ボリュームモードが設定されているスクラッチ領域が必要です。元の PVC が block ボリュームモードでサポートされる場合、 file ボリュームモード PVC をプロビジョニングできるストレージクラスを定義する必要があります。

手動プロビジョニング

ストレージクラスがない場合、CDI はイメージのサイズ要件に一致するプロジェクトの PVC を使用します。これらの要件に一致する PVC がない場合、CDI インポート Pod は適切な PVC が利用可能になるまで、またはタイムアウト機能が Pod を強制終了するまで Pending 状態になります。

7.18.14.3. スクラッチ領域を必要とする CDI 操作

Type理由

レジストリーのインポート

CDI はイメージをスクラッチ領域にダウンロードし、イメージファイルを見つけるためにレイヤーを抽出する必要があります。その後、raw ディスクに変換するためにイメージファイルが QEMU-img に渡されます。

イメージのアップロード

QEMU-IMG は STDIN の入力を受け入れません。代わりに、アップロードするイメージは、変換のために QEMU-IMG に渡される前にスクラッチ領域に保存されます。

アーカイブされたイメージの HTTP インポート

QEMU-IMG は、CDI がサポートするアーカイブ形式の処理方法を認識しません。イメージが QEMU-IMG に渡される前にアーカイブは解除され、スクラッチ領域に保存されます。

認証されたイメージの HTTP インポート

QEMU-IMG が認証を適切に処理しません。イメージが QEMU-IMG に渡される前にスクラッチ領域に保存され、認証されます。

カスタム証明書の HTTP インポート

QEMU-IMG は HTTPS エンドポイントのカスタム証明書を適切に処理しません。代わりに CDI は、ファイルを QEMU-IMG に渡す前にイメージをスクラッチ領域にダウンロードします。

7.18.14.4. CDI 設定でのストレージクラスの定義

CDI 設定でストレージクラスを定義し、CDI 操作のスクラッチ領域を動的にプロビジョニングします。

手順

  • oc クライアントを使用して cdiconfig/config を編集し、spec: scratchSpaceStorageClass を追加または編集してクラスターのストレージクラスに一致させます。

    $ oc edit cdiconfig/config
    API Version:  cdi.kubevirt.io/v1beta1
    kind: CDIConfig
    metadata:
      name: config
    ...
    spec:
      scratchSpaceStorageClass: "<storage_class>"
    ...

7.18.14.5. CDI がサポートする操作マトリックス

このマトリックスにはエンドポイントに対してコンテンツタイプのサポートされる CDI 操作が表示されます。これらの操作にはスクラッチ領域が必要です。

コンテンツタイプHTTPHTTPSHTTP Basic 認証レジストリーアップロード

kubevirt (QCOW2)

✓ QCOW2
✓ GZ*
✓ XZ*

✓ QCOW2**
✓ GZ*
✓ XZ*

✓ QCOW2
✓ GZ*
✓ XZ*

✓ QCOW2*
□ GZ
□ XZ

✓ QCOW2*
✓ GZ*
✓ XZ*

KubeVirt (RAW)

✓ RAW
✓ GZ
✓ XZ

✓ RAW
✓ GZ
✓ XZ

✓ RAW
✓ GZ
✓ XZ

✓ RAW*
□ GZ
□ XZ

✓ RAW*
✓ GZ*
✓ XZ*

✓ サポートされる操作

□ サポートされない操作

* スクラッチ領域が必要

**カスタム認証局が必要な場合にスクラッチ領域が必要

追加リソース

  • ストレージクラスおよびこれらがクラスターで定義される方法についての詳細は、「動的プロビジョニング」セクションを参照してください。

7.18.15. 永続ボリュームの再利用

静的にプロビジョニングされた永続ボリューム (PV) を再利用するには、まずボリュームを回収する必要があります。これには、ストレージ設定を再利用できるように PV を削除する必要があります。

7.18.15.1. 静的にプロビジョニングされた永続ボリュームの回収について

永続ボリューム (PV) を回収する場合、PV のバインドを永続ボリューム要求 (PVC) から解除し、PV を削除します。基礎となるストレージによっては、共有ストレージを手動で削除する必要がある場合があります。

次に、PV 設定を再利用し、異なる名前の PV を作成できます。

静的にプロビジョニングされる PV には、回収に Retain の回収 (reclaim) ポリシーが必要です。これがない場合、PV は PVC が PV からのバインド解除時に failed 状態になります。

重要

Recycle 回収ポリシーは OpenShift Container Platform 4 では非推奨となっています。

7.18.15.2. 静的にプロビジョニングされた永続ボリュームの回収

永続ボリューム要求 (PVC) のバインドを解除し、PV を削除して静的にプロビジョニングされた永続ボリューム (PV) を回収します。共有ストレージを手動で削除する必要がある場合もあります。

静的にプロビジョニングされる PV の回収方法は、基礎となるストレージによって異なります。この手順では、ストレージに応じてカスタマイズする必要がある可能性のある一般的な方法を示します。

手順

  1. PV の回収ポリシーが Retain に設定されていることを確認します。

    1. PV の回収ポリシーを確認します。

      $ oc get pv <pv_name> -o yaml | grep 'persistentVolumeReclaimPolicy'
    2. persistentVolumeReclaimPolicyRetain に設定されていない場合、以下のコマンドで回収ポリシーを編集します。

      $ oc patch pv <pv_name> -p '{"spec":{"persistentVolumeReclaimPolicy":"Retain"}}'
  2. PV を使用しているリソースがないことを確認します。

    $ oc describe pvc <pvc_name> | grep 'Mounted By:'

    PVC を使用するリソースをすべて削除してから継続します。

  3. PVC を削除して PV を解放します。

    $ oc delete pvc <pvc_name>
  4. オプション: PV 設定を YAML ファイルにエクスポートします。この手順の後半で共有ストレージを手動で削除する場合は、この設定を参照してください。このファイルで spec パラメーターをベースとして使用し、PV の回収後に同じストレージ設定で新規 PV を作成することもできます。

    $ oc get pv <pv_name> -o yaml > <file_name>.yaml
  5. PV を削除します。

    $ oc delete pv <pv_name>
  6. オプション: ストレージタイプによっては、共有ストレージフォルダーの内容を削除する必要がある場合があります。

    $ rm -rf <path_to_share_storage>
  7. オプション: 削除された PV と同じストレージ設定を使用する PV を作成します。回収された PV 設定をすでにエクスポートしている場合、そのファイルの spec パラメーターを新規 PV マニフェストのベースとして使用することができます。

    注記

    競合の可能性を回避するには、新規 PV オブジェクトに削除されたものとは異なる名前を割り当てることが推奨されます。

    $ oc create -f <new_pv_name>.yaml

追加リソース

7.18.16. データボリュームの削除

oc コマンドラインインターフェースを使用して、データボリュームを手動で削除できます。

注記

仮想マシンを削除する際に、これが使用するデータボリュームは自動的に削除されます。

7.18.16.1. データボリュームについて

DataVolume オブジェクトは、Containerized Data Importer (CDI) プロジェクトで提供されるカスタムリソースです。データボリュームは、基礎となる永続ボリューム要求 (PVC) に関連付けられるインポート、クローン作成、およびアップロード操作のオーケストレーションを行います。データボリュームは OpenShift Virtualization に統合され、仮想マシンが PVC の作成前に起動することを防ぎます。

7.18.16.2. すべてのデータボリュームの一覧表示

oc コマンドラインインターフェースを使用して、クラスターのデータボリュームを一覧表示できます。

手順

  • 以下のコマンドを実行して、データボリュームを一覧表示します。

    $ oc get dvs

7.18.16.3. データボリュームの削除

oc コマンドラインインターフェース (CLI) を使用してデータボリュームを削除できます。

前提条件

  • 削除する必要のあるデータボリュームの名前を特定すること。

手順

  • 以下のコマンドを実行し、データボリューム を削除します。

    $ oc delete dv <datavolume_name>
    注記

    このコマンドは、現在のプロジェクトに存在するオブジェクトのみを削除します。削除する必要のあるオブジェクトが別のプロジェクトまたは namespace にある場合、-n <project_name> オプションを指定します。

第8章 仮想マシンテンプレート

8.1. 仮想マシンテンプレートの作成

仮想マシンテンプレートを使用して、同様の設定を持つ複数の仮想マシンを作成することができます。テンプレートの作成後、仮想マシンの作成時にテンプレートを参照します。

8.1.1. Web コンソールでのインタラクティブなウィザードを使用した仮想マシンテンプレートの作成

Web コンソールは、GeneralNetworkingStorageAdvanced、および Review ステップに移動し、仮想マシンテンプレートの作成プロセスを単純化するインタラクティブなウィザードを特長としています。すべての必須フィールドには * のマークが付けられます。ウィザードは必須フィールドへの値の入力が完了するまで次のステップに移動することを防ぎます。

手順

  1. OpenShift Virtualization コンソールのサイドメニューから WorkloadsVirtualization をクリックします。
  2. Virtual Machine Templates タブをクリックします。
  3. Create Template をクリックし、New with Wizard を選択します。
  4. General ステップで必要なすべてのフィールドに入力します。
  5. Next をクリックして Networking 画面に進みます。デフォルトで nic0 という名前の NIC が割り当てられます。

    1. オプション: Add Network Interface をクリックし、追加の NIC を作成します。
    2. オプション: すべての NIC の削除は、Options メニュー kebab をクリックし、Delete を選択して実行できます。テンプレートから作成される仮想マシンには、割り当てられている NIC は不要です。NIC は仮想マシンの作成後に作成できます。
  6. Next をクリックして Storage 画面に進みます。

    1. オプション: Add Disk をクリックして追加のディスクを作成します。
    2. オプション: ディスクをクリックして選択可能なフィールドを変更します。✓ ボタンをクリックして変更を保存します。
    3. オプション: Disk をクリックし、Select Storage の一覧から利用可能なディスクを選択します。

      注記

      URL または Container のいずれかが General ステップで Source として選択される場合、rootdisk ディスクが作成され、Bootable Disk として仮想マシンに割り当てられます。rootdisk を変更できますが、これを削除することはできません。

      Bootable Disk は、仮想マシンにディスクが割り当てられていない場合、PXE ソースからプロビジョニングされる仮想マシンには不要です。1 つ以上のディスクが仮想マシンに割り当てられている場合、Bootable Disk を 1 つを選択する必要があります。

  7. Create Virtual Machine Template > をクリックします。Results 画面には、仮想マシンテンプレートの JSON 設定ファイルが表示されます。

    テンプレートは Virtual Machine Templates タブに一覧表示されます。

8.1.2. 仮想マシンテンプレートのインタラクティブなウィザードのフィールド

以下の表は、Create Virtual Machine Template のインタラクティブなウィザードの Basic SettingsNetworking、および Storage ペインのフィールドを説明しています。

8.1.2.1. 仮想マシンテンプレートウィザードのフィールド

名前パラメーター説明

ソース

PXE

PXE メニューから仮想マシンをプロビジョニングします。クラスターに PXE 対応の NIC が必要になります。

URL

HTTP または S3 エンドポイントで利用できるイメージから仮想マシンをプロビジョニングします。

コンテナー

クラスターからアクセスできるレジストリーの起動可能なオペレーティングシステムコンテナーから仮想マシンをプロビジョニングします。例: kubevirt/cirros-registry-disk-demo

Disk

ディスクから仮想マシンをプロビジョニングします。

Operating System

 

仮想マシン用に選択される主なオペレーティングシステム。

Flavor

small、medium、large、tiny、Custom

仮想マシンに割り当てられる CPU およびメモリーの量を決定するプリセット。Flavor に設定される Preset はオペレーティングシステムによって決まります。

Memory

 

仮想マシンに割り当てられるメモリーのサイズ (GiB 単位)。

CPU

 

仮想マシンに割り当てられる CPU の量。

Workload Profile

High Performance

高パフォーマンスのワークロードに対して最適化された仮想マシン設定。

Server

サーバーワークロードの実行に最適化されたプロファイル。

Desktop

デスクトップで使用するための仮想マシン設定。

名前

 

この名前には、小文字 (a-z)、数字 (0-9)、およびハイフン (-) を含めることができ、最大 253 文字を使用できます。最初と最後の文字は英数字にする必要があります。この名前には、大文字、スペース、ピリオド (.)、または特殊文字を使用できません。

説明

 

オプションの説明フィールド。

8.1.2.2. Cloud-init フィールド

名前説明

Hostname

仮想マシンの特定のホスト名を設定します。

Authenticated SSH Keys

仮想マシンの ~/.ssh/authorized_keys にコピーされるユーザーの公開鍵。

カスタムスクリプト

他のオプションを、カスタム cloud-init スクリプトを貼り付けるフィールドに置き換えます。

8.1.2.3. ネットワークフィールド

名前説明

名前

ネットワークインターフェースの名前。

Model

ネットワークインターフェースカードのモデルを示します。サポートされる値は e1000e および virtio です。

Network

利用可能なネットワーク接続定義の一覧。

Type

利用可能なバインディングメソッドの一覧。デフォルトの Pod ネットワークについては、masquerade が唯一の推奨されるバインディングメソッドになります。セカンダリーネットワークの場合は、 bridge バインディングメソッドを使用します。masquerade メソッドは、デフォルト以外のネットワークではサポートされません。

MAC Address

ネットワークインターフェースの MAC アドレス。MAC アドレスが指定されていない場合、セッションの一時アドレスが生成されます。

8.1.2.4. ストレージフィールド

名前説明

ソース

仮想マシンの空のディスクを選択するか、または URLContainerAttach Cloned Disk、または Attach Disk などの選択可能なオプションから選択します。既存ディスクを選択し、これを仮想マシンに割り当てるには、利用可能な Persistent Volume Claim (永続ボリューム要求、PVC) の一覧から Attach Cloned Disk または Attach Disk を選択します。

名前

ディスクの名前。この名前には、小文字 (a-z)、数字 (0-9)、ハイフン (-) およびピリオド (.) を含めることができ、最大 253 文字を使用できます。最初と最後の文字は英数字にする必要があります。この名前には、大文字、スペース、または特殊文字を使用できません。

Size (GiB)

ディスクのサイズ (GiB)。

Interface

ディスクデバイスのタイプ。サポートされるインターフェースは、virtIOSATA、および SCSI です。

Storage Class

ディスクの作成に使用されるストレージクラス。

Advanced → Volume Mode

永続ボリュームがフォーマットされたファイルシステムまたは raw ブロック状態を使用するかどうかを定義します。デフォルトは Filesystem です。

Advanced → Access Mode

永続ボリュームのアクセスモード。サポートされるアクセスモードは ReadWriteOnceReadOnlyMany、および ReadWriteMany です。

ストレージの詳細設定

以下のストレージの詳細設定は、BlankImport via URLURL、および Clone existing PVC ディスクで利用できます。これらのパラメーターはオプションです。これらのパラメーターを指定しない場合、システムは kubevirt-storage-class-defaults 設定マップのデフォルト値を使用します。

名前パラメーター説明

ボリュームモード

Filesystem

ファイルシステムベースのボリュームで仮想ディスクを保存します。

Block

ブロックボリュームで仮想ディスクを直接保存します。基礎となるストレージがサポートしている場合は、 Block を使用します。

アクセスモード

Single User (RWO)

ディスクは単一ノードで読み取り/書き込みとしてマウントできます。

Shared Access (RWX)

ディスクは数多くのノードで読み取り/書き込みとしてマウントできます。

注記

これは、ノード間の仮想マシンのライブマイグレーションなどの、一部の機能で必要になります。

Read Only (ROX)

ディスクは数多くのノードで読み取り専用としてマウントできます。

8.2. 仮想マシンテンプレートの編集

仮想マシンテンプレートは、Web コンソールで YAML エディターの詳細設定を編集するか、または Virtual Machine Template Overview 画面のパラメーターのサブセットを編集して更新することができます。

8.2.1. Web コンソールでの仮想マシンテンプレートの編集

Web コンソールの Virtual Machine Template Overview 画面の仮想マシンテンプレートの選択する値 (select values) は、関連するフィールドの横にある鉛筆アイコンをクリックして編集します。他の値は、CLI を使用して編集できます。

手順

  1. サイドメニューから WorkloadsVirtualization をクリックします。
  2. Virtual Machine Templates タブをクリックします。
  3. 仮想マシンテンプレートを選択して、Virtual Machine Template Overview 画面を開きます。
  4. Details タブをクリックします。
  5. 鉛筆アイコンをクリックして、フィールドを編集可能にします。
  6. 関連する変更を加え、Save をクリックします。

仮想マシンテンプレートの編集は、そのテンプレートですでに作成された仮想マシンには影響を与えません。

8.2.2. Web コンソールでの仮想マシンテンプレート YAML 設定の編集

Web コンソールで仮想マシンテンプレートの YAML 設定を編集できます。

すべてのパラメーターが変更可能である訳ではありません。無効な設定で Save をクリックすると、エラーメッセージで変更できないパラメーターが示唆されます。

注記

編集中に YAML 画面から離れると、設定に対して加えた変更が取り消されます。

手順

  1. OpenShift Virtualization コンソールのサイドメニューから WorkloadsVirtualization をクリックします。
  2. Virtual Machine Templates タブをクリックします。
  3. テンプレートを選択します。
  4. YAML タブをクリックして編集可能な設定を表示します。
  5. ファイルを編集し、Save をクリックします。

オブジェクトの更新されたバージョン番号を含む、変更が正常に行われたことを示す確認メッセージが表示されます。

8.2.3. 仮想マシンテンプレートへの仮想ディスクの追加

以下の手順を使用して、仮想ディスクを仮想マシンテンプレートに追加します。

手順

  1. サイドメニューから WorkloadsVirtualization をクリックします。
  2. Virtual Machine Templates タブをクリックします。
  3. 仮想マシンテンプレートを選択して、Virtual Machine Template Overview 画面を開きます。
  4. Disks タブをクリックします。
  5. Add Disks をクリックして、 Add Disk ウィンドウを開きます。
  6. Add Disk ウィンドウで、SourceNameSizeInterfaceType、および Storage Class を指定します。

    1. オプション: Advanced 一覧で、仮想ディスクの Volume Mode および Access Mode を指定します。これらのパラメーターを指定しない場合、システムは kubevirt-storage-class-defaults 設定マップのデフォルト値を使用します。
  7. Add をクリックします。

8.2.4. ネットワークインターフェースの仮想マシンテンプレートへの追加

以下の手順を使用して、ネットワークインターフェースを仮想マシンテンプレートに追加します。

手順

  1. サイドメニューから WorkloadsVirtualization をクリックします。
  2. Virtual Machine Templates タブをクリックします。
  3. 仮想マシンテンプレートを選択して、Virtual Machine Template Overview 画面を開きます。
  4. Network Interfaces タブをクリックします。
  5. Add Network Interface をクリックします。
  6. Add Network Interface ウィンドウで、ネットワークインターフェースの NameModelNetworkType、および MAC Address を指定します。
  7. Add をクリックします。

8.2.5. 仮想マシンテンプレートの CD-ROM の編集

以下の手順を使用して、仮想マシンの CD-ROM を設定します。

手順

  1. Virtual Machine Templates タブで、仮想マシンテンプレートを選択します。
  2. Overview タブを選択します。
  3. CD-ROM 設定を追加または編集するには、CD-ROMs ラベルの右側にある鉛筆アイコンをクリックします。Edit CD-ROM ウィンドウが開きます。

    • CD-ROM が編集できない場合、以下のメッセージが表示されます: The virtual machine doesn’t have any CD-ROMs attached.
    • 利用可能な CD-ROM がある場合は、- をクリックして CD-ROM を削除できます。
  4. Edit CD-ROM ウィンドウで、以下を実行します。

    1. Media Type のドロップダウンリストから CD-ROM 設定のタイプを選択します。CD-ROM 設定タイプは ContainerURL、および Persistent Volume Claim です。
    2. それぞれの Type に必要な情報を入力します。
    3. すべての CD-ROM が追加されたら、Save をクリックします。

8.3. 仮想マシンテンプレートの専用リソースの有効化

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

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

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

8.3.2. 前提条件

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

8.3.3. 仮想マシンテンプレートの専用リソースの有効化

Web コンソールの Virtual Machine Template Overview ページで仮想マシンテンプレートの専用リソースを有効にすることができます。

手順

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

8.4. 仮想マシンテンプレートの削除

Web コンソールで仮想マシンテンプレートを削除できます。

8.4.1. Web コンソールでの仮想マシンテンプレートの削除

仮想マシンテンプレートを削除すると、仮想マシンはクラスターから永続的に削除されます。

手順

  1. OpenShift Virtualization コンソールのサイドメニューから WorkloadsVirtualization をクリックします。
  2. Virtual Machine Templates タブをクリックします。
  3. このペインから仮想マシンテンプレートを削除できます。 これにより、1 つのペインで複数のマシンに対してアクションを実行することがより容易になります。 または、Virtual Machine Template Details ペインから仮想マシンテンプレートを削除することもできます。 この場合、選択されたテンプレートの総合的な詳細情報を確認できます。

    • 削除するテンプレートの Options メニュー kebab をクリックし、Delete Template を選択します。
    • テンプレート名をクリックして Virtual Machine Template Details ペインを開き、ActionsDelete Template をクリックします。
  4. 確認のポップアップウィンドウで、Delete をクリックし、テンプレートを永続的に削除します。

第9章 ライブマイグレーション

9.1. 仮想マシンのライブマイグレーション

9.1.1. ライブマイグレーションについて

ライブマイグレーションは、仮想ワークロードまたはアクセスに支障を与えることなく、実行中の仮想マシンインスタンス (VMI) をクラスター内の別のノードに移行するプロセスです。VMI が LiveMigrate エビクションストラテジーを使用する場合、VMI が実行されるノードがメンテナンスモードになると自動的に移行されます。移行する VMI を選択して、ライブマイグレーションを手動で開始することもできます。

仮想マシンでは、共有 ReadWriteMany (RWX) アクセスモードを持つ永続ボリューム要求 (PVC) のライブマイグレーションが必要です。

注記

ライブマイグレーションは SR-IOV ネットワークインターフェースに接続されている仮想マシンにはサポートされません。

9.1.2. ライブマイグレーションのアクセスモードの更新

ライブマイグレーションが適切に機能するには、ReadWriteMany (RWX) アクセスモードを使用する必要があります。必要に応じて、以下の手順でアクセスモードを更新します。

手順

  • RWX アクセスモードを設定するには、以下の oc patch コマンドを実行します。

    $ oc patch -n openshift-cnv \
        cm kubevirt-storage-class-defaults \
        -p '{"data":{"'$<STORAGE_CLASS>'.accessMode":"ReadWriteMany"}}'

9.2. ライブマイグレーションの制限およびタイムアウト

ライブマイグレーションの制限およびタイムアウトは、移行プロセスがクラスターに負担をかけないようにするために適用されます。kubevirt-config 設定ファイルを編集してこれらの設定を行います。

9.2.1. ライブマイグレーションの制限およびタイムアウトの設定

更新された key:value フィールドを openshift-cnv namespace にある kubevirt-config 設定ファイルに追加することによってライブマイグレーションの制限およびタイムアウトを設定します。

手順

  • kubevirt-config 設定ファイルを編集し、必要なライブマイグレーションパラメーターを追加します。以下の例は、デフォルト値を示しています。

    $ oc edit configmap kubevirt-config -n openshift-cnv

    設定ファイルのサンプル

    apiVersion: v1
    data:
      default-network-interface: masquerade
      feature-gates: DataVolumes,SRIOV,LiveMigration,CPUManager,CPUNodeDiscovery,Sidecar,Snapshot
      migrations: |-
        parallelMigrationsPerCluster: "5"
        parallelOutboundMigrationsPerNode: "2"
        bandwidthPerMigration: "64Mi"
        completionTimeoutPerGiB: "800"
        progressTimeout: "150"
      machine-type: pc-q35-rhel8.3.0
      selinuxLauncherType: virt_launcher.process
      smbios: |-
        Family: Red Hat
        Product: Container-native virtualization
        Manufacturer: Red Hat
        Sku: 2.6.0
        Version: 2.6.0
    kind: ConfigMap
    metadata:
      creationTimestamp: "2021-03-26T18:01:04Z"
      labels:
        app: kubevirt-hyperconverged
      name: kubevirt-config
      namespace: openshift-cnv
      resourceVersion: "15371295"
      selfLink: /api/v1/namespaces/openshift-cnv/configmaps/kubevirt-config
      uid: <uuid>

9.2.2. クラスター全体のライブマイグレーションの制限およびタイムアウト

表9.1 移行パラメーター

パラメーター説明Default

parallelMigrationsPerCluster

クラスターで並行して実行される移行の数。

5

parallelOutboundMigrationsPerNode

ノードごとのアウトバウンドの移行の最大数。

2

bandwidthPerMigration

それぞれの移行の帯域幅 (MiB/s)。

64Mi

completionTimeoutPerGiB

移行がこの時間内に終了しない場合 (単位はメモリーの GiB あたりの秒数)、移行は取り消されます。たとえば、6GiB メモリーを持つ仮想マシンインスタンスは、4800 秒内に移行を完了しない場合にタイムアウトします。Migration MethodBlockMigration の場合、移行するディスクのサイズは計算に含められます。

800

progressTimeout

メモリーのコピーの進捗がこの時間内 (秒単位) に見られない場合に、移行は取り消されます。

150

9.3. 仮想マシンインスタンスの別のノードへの移行

Web コンソールまたは CLI のいずれかで仮想マシンインスタンスのライブマイグレーションを手動で開始します。

9.3.1. Web コンソールでの仮想マシンインスタンスのライブマイグレーションの開始

実行中の仮想マシンインスタンスをクラスター内の別のノードに移行します。

注記

Migrate Virtual Machine アクションはすべてのユーザーに対して表示されますが、仮想マシンの移行を開始できるのは管理者ユーザーのみとなります。

手順

  1. OpenShift Virtualization コンソールのサイドメニューから WorkloadsVirtualization をクリックします。
  2. Virtual Machines タブをクリックします。
  3. この画面から移行を開始できます。 これにより、1 つの画面で複数のマシンに対してアクションを実行することがより容易になります。 または、Virtual Machine Overview 画面から仮想マシンを停止することもできます。 この場合、選択された仮想マシンの総合的な詳細情報を確認できます。

    • 仮想マシンの末尾の Options メニュー kebab をクリックし、Migrate Virtual Machine を選択します。
    • 仮想マシン名をクリックし、Virtual Machine Overview 画面を開き、ActionsMigrate Virtual Machine をクリックします。
  4. Migrate をクリックして、仮想マシンを別のノードに移行します。

9.3.2. CLI での仮想マシンインスタンスのライブマイグレーションの開始

クラスターに VirtualMachineInstanceMigration オブジェクトを作成し、仮想マシンインスタンスの名前を参照して、実行中の仮想マシンインスタンスのライブマイグレーションを開始します。

手順

  1. 移行する仮想マシンインスタンスの VirtualMachineInstanceMigration 設定ファイルを作成します。vmi-migrate.yaml はこの例になります。

    apiVersion: kubevirt.io/v1alpha3
    kind: VirtualMachineInstanceMigration
    metadata:
      name: migration-job
    spec:
      vmiName: vmi-fedora
  2. 以下のコマンドを実行して、クラスター内にオブジェクトを作成します。

    $ oc create -f vmi-migrate.yaml

VirtualMachineInstanceMigration オブジェクトは、仮想マシンインスタンスのライブマイグレーションをトリガーします。このオブジェクトは、手動で削除されない場合、仮想マシンインスタンスが実行中である限りクラスターに存在します。

9.4. 仮想マシンインスタンスのライブマイグレーションのモニター

Web コンソールまたは CLI のいずれかで仮想マシンインスタンスのライブマイグレーションの進捗をモニターできます。

9.4.1. Web コンソールでの仮想マシンインスタンスのライブマイグレーションのモニター

移行期間中、仮想マシンのステータスは Migrating になります。このステータスは Virtual Machines タブに表示されるか、または移行中の仮想マシンの Virtual Machine Overview 画面に表示されます。

手順

  1. OpenShift Virtualization コンソールのサイドメニューから WorkloadsVirtualization をクリックします。
  2. Virtual Machines タブをクリックします。
  3. 仮想マシンを選択して、Virtual Machine Overview 画面を開きます。