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

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

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

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

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

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

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

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

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

重要

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

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

9.17.2.1. 前提条件

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

✓ サポートされる操作

□ サポートされない操作

* スクラッチ領域が必要

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

注記

CDI は OpenShift Container Platform の クラスター全体のプロキシー設定 を使用するようになりました。

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

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

9.17.2.4. データボリュームを使用して仮想マシンイメージをストレージにインポートする

データボリュームを使用して、仮想マシンイメージをストレージにインポートできます。

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

イメージのデータソースは、VirtualMachine 設定ファイルで指定します。仮想マシンが作成されると、仮想マシンイメージを含むデータボリュームがストレージにインポートされます。

前提条件

  • 仮想マシンイメージをインポートするには、以下が必要である。

    • RAW、ISO、または QCOW2 形式の仮想マシンディスクイメージ (オプションで xz または gz を使用して圧縮される)。
    • データソースにアクセスするために必要な認証情報と共にイメージがホストされる HTTP または HTTPS エンドポイント
  • コンテナーディスクをインポートするには、仮想マシンイメージをコンテナーディスクに組み込み、データソースにアクセスするために必要な認証クレデンシャルとともにコンテナーレジストリーに保存する必要があります。
  • 仮想マシンが自己署名証明書またはシステム CA バンドルによって署名されていない証明書を使用するサーバーと通信する必要がある場合は、データボリュームと同じ namespace に config map を作成する必要があります。

手順

  1. データソースに認証が必要な場合は、データソースのクレデンシャルを指定して Secret マニフェストを作成し、endpoint-secret.yaml として保存します。

    apiVersion: v1
    kind: Secret
    metadata:
      name: endpoint-secret 1
      labels:
        app: containerized-data-importer
    type: Opaque
    data:
      accessKeyId: "" 2
      secretKey:   "" 3
    1
    Secret の名前を指定します。
    2
    Base64 でエンコードされたキー ID またはユーザー名を指定します。
    3
    Base64 でエンコードされた秘密鍵またはパスワードを指定します。
  2. Secret マニフェストを適用します。

    $ oc apply -f endpoint-secret.yaml
  3. VirtualMachine マニフェストを編集し、インポートする仮想マシンイメージのデータソースを指定して、vm-fedora-datavolume.yaml として保存します。

    apiVersion: kubevirt.io/v1
    kind: VirtualMachine
    metadata:
      creationTimestamp: null
      labels:
        kubevirt.io/vm: vm-fedora-datavolume
      name: vm-fedora-datavolume 1
    spec:
      dataVolumeTemplates:
      - metadata:
          creationTimestamp: null
          name: fedora-dv 2
        spec:
          storage:
            resources:
              requests:
                storage: 10Gi
            storageClassName: local
          source:
            http: 3
              url: "https://mirror.arizona.edu/fedora/linux/releases/35/Cloud/x86_64/images/Fedora-Cloud-Base-35-1.2.x86_64.qcow2" 4
              secretRef: endpoint-secret 5
              certConfigMap: "" 6
        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: ""
            resources:
              requests:
                memory: 1.5Gi
          terminationGracePeriodSeconds: 180
          volumes:
          - dataVolume:
              name: fedora-dv
            name: datavolumedisk1
    status: {}
    1
    仮想マシンの名前を指定します。
    2
    データボリュームの名前を指定します。
    3
    HTTP または HTTPS エンドポイントに http を指定します。レジストリーからインポートされたコンテナーディスクイメージの registry を指定します。
    4
    インポートする仮想マシンイメージの URL またはレジストリーエンドポイントを指定します。この例では、HTTPS エンドポイントで仮想マシンイメージを参照します。コンテナーレジストリーエンドポイントのサンプルは url: "docker://kubevirt/fedora-cloud-container-disk-demo:latest" です。
    5
    データソースの Secret を作成した場合は、Secret 名を指定します。
    6
    オプション: CA 証明書 config map を指定します。
  4. 仮想マシンを作成します。

    $ oc create -f vm-fedora-datavolume.yaml
    注記

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

    データボリュームのプロビジョニングはバックグランドで実行されるため、これをプロセスをモニターする必要はありません。

検証

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

    $ oc get pods
  2. 次のコマンドを実行して、ステータスが Succeeded になるまでデータボリュームを監視します。

    $ oc describe dv fedora-dv 1
    1
    VirtualMachine マニフェストで定義したデータボリューム名を指定します。
  3. シリアルコンソールにアクセスして、プロビジョニングが完了し、仮想マシンが起動したことを確認します。

    $ virtctl console vm-fedora-datavolume

9.17.2.5. 関連情報

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

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

重要

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

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

9.17.3.1. 前提条件

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

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

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

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

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

9.17.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
    直前の手順で作成された永続ボリュームのファイル名。

9.17.3.5. データボリュームを使用して仮想マシンイメージをブロックストレージにインポートする

データボリュームを使用して、仮想マシンイメージをブロックストレージにインポートできます。仮想マシンを作成する前に、VirtualMachine マニフェストでデータボリュームを参照します。

前提条件

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

手順

  1. データソースに認証が必要な場合は、データソースのクレデンシャルを指定して Secret マニフェストを作成し、endpoint-secret.yaml として保存します。

    apiVersion: v1
    kind: Secret
    metadata:
      name: endpoint-secret 1
      labels:
        app: containerized-data-importer
    type: Opaque
    data:
      accessKeyId: "" 2
      secretKey:   "" 3
    1
    Secret の名前を指定します。
    2
    Base64 でエンコードされたキー ID またはユーザー名を指定します。
    3
    Base64 でエンコードされた秘密鍵またはパスワードを指定します。
  2. Secret マニフェストを適用します。

    $ oc apply -f endpoint-secret.yaml
  3. データ DataVolume マニフェストを作成し、仮想マシンイメージのデータソースと storage.volumeModeBlock を指定します。

    apiVersion: cdi.kubevirt.io/v1beta1
    kind: DataVolume
    metadata:
      name: import-pv-datavolume 1
    spec:
      storageClassName: local 2
        source:
          http:
            url: "https://mirror.arizona.edu/fedora/linux/releases/35/Cloud/x86_64/images/Fedora-Cloud-Base-35-1.2.x86_64.qcow2" 3
            secretRef: endpoint-secret 4
      storage:
        volumeMode: Block 5
        resources:
          requests:
            storage: 10Gi
    1
    データボリュームの名前を指定します。
    2
    オプション: ストレージクラスを設定するか、これを省略してクラスターのデフォルトを受け入れます。
    3
    インポートするイメージの HTTP または HTTPS URL を指定します。
    4
    データソースの Secret を作成した場合は、Secret 名を指定します。
    5
    ボリュームモードとアクセスモードは、既知のストレージプロビジョナーに対して自動的に検出されます。それ以外の場合は、Block を指定します。
  4. 仮想マシンイメージをインポートするために data volume を作成します。

    $ oc create -f import-pv-datavolume.yaml

仮想マシンを作成する前に、VirtualMachine マニフェストでこのデータボリュームを参照できます。

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

✓ サポートされる操作

□ サポートされない操作

* スクラッチ領域が必要

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

注記

CDI は OpenShift Container Platform の クラスター全体のプロキシー設定 を使用するようになりました。

9.17.3.7. 関連情報