手順

1. 正しいプロジェクトを指定していることを確認します。そうでない場合は、Project 一覧をクリックして適切なプロジェクトを選択します。
2. Workloads → Virtual Machines をクリックして、プロジェクトに仮想マシンを表示します。
3. 仮想マシンを選択します。
4. Overview タブで、virt-launcher-<vm-name> Pod をクリックします。
5. Terminal タブをクリックします。ターミナルが空白の場合、ターミナルをクリックし、任意のキーを押して接続を開始します。

手順

1. Container-native Virtualization コンソールで Workloads → Virtual Machinesをクリックします。
2. 仮想マシンを選択します。
3. Consoles をクリックします。VNC コンソールがデフォルトで開きます。
4. VNC Console ドロップダウンリストをクリックし、Serial Console を選択します。

手順

1. Container-native Virtualization コンソールで Workloads → Virtual Machinesをクリックします。
2. 仮想マシンを選択します。
3. Consoles をクリックします。VNC コンソールがデフォルトで開きます。

手順

1. Container-native Virtualization コンソールで Workloads → Virtual Machinesをクリックします。
2. Windows 仮想マシンを選択します。
3. Consoles タブをクリックします。
4. Consoles 一覧をクリックし、Desktop Viewer を選択します。
5. Network Interface 一覧で、 layer-2 NIC を選択します。
6. Launch Remote Desktop をクリックし、 console.rdp ファイルをダウンロードします。

7. RDP クライアントを開き、console.rdp ファイルを参照します。たとえば、remmina を使用します。

   $ remmina --connect /path/to/console.rdp

8. Administrator ユーザー名およびパスワードを入力して、Windows 仮想マシンに接続します。

手順

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

   $ virtctl expose vm <fedora-vm> --port=20022 --target-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>        20022:32551/TCP   6s

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

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

   $ ssh username@<node_IP_address> -p 32551

手順

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

   $ virtctl vnc <VMI>

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

   $ virtctl vnc <VMI> -v 4

手順

1. アクセストークンを持つユーザーとして、oc CLI ツールを使って Container-native 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 仮想マシンに接続します。

手順

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

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

   注記

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

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

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

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

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

   1

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

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

   $ ansible-playbook create-vm.yaml

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

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

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

   $ ansible-playbook create-vm.yaml

手順

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

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

      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"
              },
              {
                "type": "cnv-tuning" 1
              }
            ]
          }'

      1

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

      注記

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

2. 直前の手順で作成したファイルを使用して NetworkAttachmentDefinition オブジェクトを作成します。

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

3. 仮想マシンインスタンス設定ファイルを、インターフェイスおよびネットワークの詳細を含めるように編集します。

   1. PXE サーバーで必要な場合には、ネットワークおよび MAC アドレスを指定します。MAC アドレスが指定されていない場合、値は自動的に割り当てられます。ただし、この時点で自動的に割り当てられる MAC アドレスは永続しないことに注意してください。

      bootOrder が 1 に設定されており、インターフェイスが最初に起動することを確認します。この例では、インターフェイスは <pxe-net> というネットワークに接続されています。

      interfaces:
      - masquerade: {}
        name: default
      - bridge: {}
        name: pxe-net
        macAddress: de:00:00:00:00:de
        bootOrder: 1

      注記

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

   2. オペレーティングシステムのプロビジョニング後に起動が適切に実行されるよう、ブートデバイス番号をディスクに割り当てます。

      ディスク bootOrder の値を 2 に設定します。

      devices:
        disks:
        - disk:
            bus: virtio
          name: containerdisk
          bootOrder: 2

   3. 直前に作成された NetworkAttachmentDefinition に接続されるネットワークを指定します。このシナリオでは、<pxe-net> は <pxe-net-conf> という NetworkAttachmentDefinition に接続されます。

      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

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

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

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

   $ virtctl vnc vmi-pxe-boot

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

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

   $ virtctl console vmi-pxe-boot

9. 仮想マシンのインターフェイスおよび 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

手順

1. 仮想マシンインスタンスに対し、クラスターから要求された以上のメモリーが利用可能であることを明示的に示すために、仮想マシン設定ファイルを編集し、spec.domain.memory.guest を spec.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

手順

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

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

   注記

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

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

   $ oc create -f <file name>.yaml

手順

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

手順

1. 正しい namespace にあることを確認します。ConfigMap は、同じ namespace にある場合に DataVolume によってのみ参照されます。

   $ oc get ns

2. ConfigMap を作成します。

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

手順

1. インポートする必要のある仮想ディスクイメージをホストする HTTP ファイルサーバーを特定します。正しい形式での完全な URL が必要になります。

   • http://www.example.com/path/to/data

2. データソースに認証情報が必要な場合、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

3. 仮想マシン設定ファイルを編集し、インポートする必要のあるイメージのデータソースを指定します。この例では、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: 2Gi
           storageClassName: local
         source:
           http:
             url: https://download.fedoraproject.org/pub/fedora/linux/releases/28/Cloud/x86_64/images/Fedora-Cloud-Base-28-1.1.x86_64.qcow2 1
             secretRef: "" 2
             certConfigMap: "" 3
       status: {}
     running: false
     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: 64M
         terminationGracePeriodSeconds: 0
         volumes:
         - dataVolume:
             name: fedora-dv
           name: datavolumedisk1
   status: {}

   1

   インポートする必要のあるイメージの HTTP ソース。

   2

   secretRef パラメーターはオプションです。

   3

   certConfigMap は、自己署名証明書またはシステム CA バンドルで署名されていない証明書を使用するサーバーと通信するために必要です。参照される ConfigMap は DataVolume と同じ namespace にある必要があります。

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

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

   注記

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

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

オプションの検証手順

1. oc get pods を実行し、インポーター Pod を見つけます。この Pod は指定された URL からイメージをダウンロードし、これをプロビジョニングされた PV に保存します。

2. Succeeded が表示されるまで DataVolume のステータスをモニターします。

   $ oc describe dv <data-label> 1

   1

   仮想マシン設定ファイルに指定された DataVolume のデータラベル。

3. プロビジョニングが完了し、VMI が起動したことを検証するには、そのシリアルコンソールへのアクセスを試行します。

   $ virtctl console <vm-fedora-datavolume>

手順

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 に StorageClass を設定します。これを省略する場合、クラスターのデフォルトが使用されます。

   4

   ブロックデバイスがマウントされたノード。

5. ブロック PV を作成します。

   # oc create -f <local-block-pv10.yaml>1

   1

   直前の手順で作成された PersistentVolume のファイル名。

手順

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/v1alpha1
   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

   DataVolume の名前。

   2

   オプション: ストレージクラスを設定するか、またはこれを省略してクラスターのデフォルトを受け入れます。

   3

   インポートするイメージの HTTP ソース。

   4

   データソースに認証が必要である場合にのみ必要です。

   5

   ブロック PV にインポートするために必要です。

3. 仮想マシンイメージをインポートするために DataVolume を作成します。

   $ oc create -f <import-pv-datavolume.yaml>1

   1

   直前の手順で作成されたファイル名 DataVolume。

手順

1. 一時ディレクトリーを作成し、これに移動します。

   $ mkdir /tmp/<dir_name> && cd /tmp/<dir_name>

2. ブラウザーで VMware code に移動し、SDKs をクリックします。
3. Compute Virtualization で Virtual Disk Development Kit(VDDK) をクリックします。
4. 最新の VDDK リリースを選択し、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 Container Platform 環境からアクセスできることを確認します。

10. openshift-cnv プロジェクトで v2v-vmware ConfigMap を編集します。

    $ oc edit configmap v2v-vmware -n openshift-cnv

11. vddk-init-image パラメーターを data スタンザに追加します。

    ...
    data:
      vddk-init-image: <registry_route_or_server_path>/vddk:<tag>

手順

1. Container-native Virtualization Web コンソールで Workloads → Virtual Machines をクリックします。
2. Create Virtual Machine をクリックし、Import with Wizard を選択します。

3. General 画面で、以下の手順を実行します。

   1. Provider 一覧から、VMware を選択します。

   2. vCenter instance 一覧から Connect to New Instance または保存された vCenter インスタンスを選択します。

      • Connect to New Instance を選択する場合、vCenter hostname、Username、Password を入力します。
      • 保存された vCenter インスタンスを選択する場合、ウィザードは保存された認証情報を使用して vCenter に接続します。
   3. VM or Template to Import 一覧からインポートする仮想マシンまたはテンプレートを選択します。
   4. オペレーティングシステムを選択します。

   5. Flavor 一覧から既存フレーバーまたは Custom を選択します。

      Custom を選択した場合は、Memory (GB) および CPUs を指定します。

   6. Workload Profile を選択します。
   7. 仮想マシン名が namespace の別の仮想マシンで使用されている場合、名前を更新します。
   8. Next をクリックします。

4. Networking 画面で以下の手順を実行します。

   1. ネットワークインターフェイスの Options メニュー をクリックし、Edit を選択します。

   2. 有効なネットワークインターフェイス名を入力します。

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

   3. ネットワークインターフェイスモデルを選択します。
   4. ネットワーク定義を選択します。
   5. ネットワークインターフェイスの種類を選択します。
   6. MAC アドレスを入力します。
   7. Save をクリックした後に、Next をクリックします。

5. Storage 画面で以下の手順を実行します。

   1. ディスクの Options メニュー をクリックし、Edit を選択します。

   2. 有効な名前を入力します。

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

   3. インターフェイスタイプを選択します。

   4. ストレージクラスを作成します。

      ストレージクラスを選択しない場合、Container-native Virtualization はデフォルトストレージクラスを使用して仮想マシンを作成します。

   5. Save をクリックした後に、Next をクリックします。
6. Advanced 画面で、cloud-init を使用している場合は Hostname および Authorized SSH Keys を入力します。
7. Next をクリックします。

8. 設定を確認し、Create Virtual Machine をクリックします。

   Successfully created virtual machine というメッセージが表示され、仮想マシンに作成されたリソースの一覧が表示されます。電源がオフになった仮想マシンが Workloads → Virtual Machines に表示されます。

9. See virtual machine details をクリックして、インポートされた仮想マシンのダッシュボードを表示します。

   エラーが発生した場合は、以下の手順を実行します。

   1. Workloads → Pods をクリックします。
   2. 変換 Pod (例: kubevirt-v2v-conversion-rhel7-mini-1-27b9h) をクリックします。
   3. Logs をクリックし、エラーメッセージの有無を確認します。

手順

1. 仮想マシンにログインします。
2. /etc/sysconfig/network-scripts ディレクトリーに移動します。

3. ネットワーク設定ファイル名を ifcfg-eth0 に変更します。

   $ mv vmnic0 ifcfg-eth0 1

   1

   追加のネットワーク設定ファイルには、ifcfg-eth1、ifcfg-eth2 などの番号が順番に付けられます。

4. ネットワーク設定ファイルで NAME および DEVICE パラメーターを更新します。

   NAME=eth0
   DEVICE=eth0

5. ネットワークを再起動します。

   $ systemctl restart network

1. Conversion Pod 名を取得します。

   $ oc get pods -n <project> | grep v2v 1
   kubevirt-v2v-conversion-f66f7d-zqkz7            1/1     Running     0          4h49m

   1

   インポートされた仮想マシンのプロジェクトを指定します。

2. Conversion Pod ログを取得します。

   $ oc logs kubevirt-v2v-conversion-f66f7d-zqkz7 -f -n <project>

手順

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

   ClusterRole の一意の名前。

2. クラスターに ClusterRole を作成します。

   $ oc create -f <datavolume-cloner.yaml> 1

   1

   直前の手順で作成された ClusterRole マニフェストのファイル名です。

3. 移行元および宛先 namespace の両方に適用される RoleBinding マニフェストを作成し、直前の手順で作成した ClusterRole を参照します。

   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

   RoleBinding の一意の名前。

   2

   ソース DataVolume の namespace。

   3

   DataVolume のクローンが作成される namespace。

   4

   直前の手順で作成した ClusterRole の名前。

4. クラスターに RoleBinding を作成します。

   $ oc create -f <datavolume-cloner.yaml> 1

   1

   直前の手順で作成された RoleBinding マニフェストのファイル名です。

手順

1. 関連付けられた PVC の名前および namespace を特定するために、クローン作成に必要な仮想マシンディスクを確認します。

2. 新規 DataVolume の名前、ソース PVC の名前および namespace、および新規 DataVolume のサイズを指定する DataVolume オブジェクトの YAML ファイルを作成します。

   以下は例になります。

   apiVersion: cdi.kubevirt.io/v1alpha1
   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

   新規 DataVolume の名前。

   2

   ソース PVC が存在する namespace。

   3

   ソース PVC の名前。

   4

   新規 DataVolume のサイズ。十分な領域を割り当てる必要があります。そうでない場合には、クローン操作は失敗します。サイズはソース PVC と同じか、またはそれよりも大きくなければなりません。

3. DataVolume を作成して PVC のクローン作成を開始します。

   $ oc create -f <cloner-datavolume>.yaml

   注記

   DataVolume は仮想マシンが PVC の作成前に起動することを防ぐため、PVC のクローン作成中に新規 DataVolume を参照する仮想マシンを作成できます。

手順

1. 関連付けられた PVC の名前および namespace を特定するために、クローン作成に必要な仮想マシンを確認します。

2. VirtualMachine オブジェクトの YAML ファイルを作成します。以下の仮想マシンのサンプルでは、source-namespace namespace にある my-favorite-vm-disk のクローンを作成します。favorite-clone という 2Gi DataVolume が 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 のクローンが作成された DataVolume で仮想マシンを作成します。

   $ oc create -f <vm-clone-datavolumetemplate>.yaml

手順

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 に StorageClass を設定します。これを省略する場合、クラスターのデフォルトが使用されます。

   4

   ブロックデバイスがマウントされたノード。

5. ブロック PV を作成します。

   # oc create -f <local-block-pv10.yaml>1

   1

   直前の手順で作成された PersistentVolume のファイル名。

手順

1. 関連付けられた PVC の名前および namespace を特定するために、クローン作成に必要な仮想マシンディスクを確認します。

2. 新規 DataVolume の名前、ソース PVC の名前および namespace、利用可能なブロック PV を使用できるようにするために volumeMode: Block、および新規 DataVolume のサイズを指定する DataVolume オブジェクトの YAML ファイルを作成します。

   以下は例になります。

   apiVersion: cdi.kubevirt.io/v1alpha1
   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

   新規 DataVolume の名前。

   2

   ソース PVC が存在する namespace。

   3

   ソース PVC の名前。

   4

   新規 DataVolume のサイズ。十分な領域を割り当てる必要があります。そうでない場合には、クローン操作は失敗します。サイズはソース PVC と同じか、またはそれよりも大きくなければなりません。

   5

   宛先がブロック PV であることを指定します。

3. DataVolume を作成して PVC のクローン作成を開始します。

   $ oc create -f <cloner-datavolume>.yaml

   注記

   DataVolume は仮想マシンが PVC の作成前に起動することを防ぐため、PVC のクローン作成中に新規 DataVolume を参照する仮想マシンを作成できます。

手順

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

手順

1. Container-native Virtualization コンソールの適切なプロジェクトで、Workloads → Virtual Machines をクリックします。
2. 仮想マシンを選択します。
3. Network Interfaces をクリックし、仮想マシンにすでに割り当てられている NIC を表示します。
4. Create Network Interface をクリックし、一覧に新規スロットを作成します。
5. 新規 NIC の Name、Model、Network、 Type、および MAC Address を入力します。
6. ✓ ボタンをクリックして NIC を保存し、これを仮想マシンに割り当てます。

手順

1. コンソールのいずれか、または SSH を使用して仮想マシンのコマンドラインにアクセスします。

2. QEMU ゲストエージェントを仮想マシンにインストールします。

   $ yum install -y qemu-guest-agent

3. QEMU ゲストエージェントサービスを起動します。

   $ systemctl start qemu-guest-agent

4. サービスに永続性があることを確認します。

   $ systemctl enable qemu-guest-agent

1. 以下のコマンドを実行して、ゲストエージェントがインストールされており、実行中であることを確認します。

   $ systemctl status qemu-guest-agent

2. ゲストエージェントがインストールされておらず、実行されていない場合は、仮想マシン上でゲストエージェントをインストールし、実行します。

手順

1. Container-native Virtualization コンソールで Workloads → Virtual Machinesをクリックします。
2. 仮想マシンの名前をクリックして、Virtual Machine Overview 画面を開きます。

手順

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

手順

1. HostPathProvisioner カスタムリソースファイルを作成します。以下は例になります。

   $ touch hostpathprovisioner_cr.yaml

2. ファイルを編集し、spec.pathConfig.path の値がホストパスプロビジョナーが PV を作成するディレクトリーであることを確認します。以下に例を示します。

   apiVersion: hostpathprovisioner.kubevirt.io/v1alpha1
   kind: HostPathProvisioner
   metadata:
     name: hostpath-provisioner
   spec:
     imagePullPolicy: IfNotPresent
     pathConfig:
       path: "</path/to/backing/directory>" 1
       useNamingPrefix: "false" 2

   1

   プロビジョナーが PV を作成するバッキングディレクトリーを指定します。

   2

   作成された PV にバインドされる PersistentVolumeClaim (PVC) の名前をディレクトリー名の接頭辞として使用する場合には、この値を true に変更します。

   注記

   バッキングディレクトリーを作成していない場合、プロビジョナーはこの作成を試行します。container_file_t SELinux コンテキストを適用していない場合、これにより Permission denied エラーが生じる可能性があります。

3. openshift-cnv namespace にカスタムリソースを作成します。

   $ oc create -f hostpathprovisioner_cr.yaml -n openshift-cnv

手順

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 を指定して、PersistentVolumeClaim (PVC) を使用する Pod が作成されるまで PV のバインディングおよびプロビジョニングを遅延させます。これにより、PV が Pod のスケジュール要件を満たすようになります。

3. StorageClass オブジェクトを作成します。

   $ oc create -f storageclass.yaml

手順

1. spec: source: upload{} を指定する DataVolume 設定を作成します。

   apiVersion: cdi.kubevirt.io/v1alpha1
   kind: DataVolume
   metadata:
     name: <upload-datavolume> 1
   spec:
     source:
         upload: {}
     pvc:
       accessModes:
         - ReadWriteOnce
       resources:
         requests:
           storage: <2Gi> 2

   1

   DataVolume の名前。

   2

   DataVolume のサイズ。この値がアップロードするディスクのサイズ以上であることを確認します。

2. 以下のコマンドを実行して DataVolume を作成します。

   $ oc create -f <upload-datavolume>.yaml

手順

1. 以下を特定します。

   • 使用するアップロード DataVolume の名前。この DataVolume が存在しない場合、これは自動的に作成されます。
   • DataVolume のサイズ (アップロード手順の実行時に作成する必要がある場合)。サイズはディスクイメージのサイズ以上である必要があります。
   • アップロードする必要のある仮想マシンディスクイメージのファイルの場所。

2. virtctl image-upload コマンドを実行してディスクイメージをアップロードします。直前の手順で特定したパラメーターを指定します。以下は例になります。

   $ virtctl image-upload dv <datavolume_name> \ 1
   --size=<datavolume_size> \ 2
   --image-path=</path/to/image> \ 3

   1

   DataVolume の名前。

   2

   DataVolume のサイズ。例: --size=500Mi、--size=1G

   3

   仮想マシンディスクイメージのファイルパス。

   注記

   • 新規 DataVolume を作成する必要がない場合は、--size パラメーターを省略し、--no-create フラグを含めます。
   • HTTPS を使用したセキュアでないサーバー接続を許可するには、--insecure パラメーターを使用します。--insecure フラグを使用する際に、アップロードエンドポイントの信頼性は検証 されない 点に注意してください。

3. オプション。DataVolume が作成されたことを確認するには、以下のコマンドを実行してすべての DataVolume オブジェクトを表示します。

   $ oc get dvs

手順

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 に StorageClass を設定します。これを省略する場合、クラスターのデフォルトが使用されます。

   4

   ブロックデバイスがマウントされたノード。

5. ブロック PV を作成します。

   # oc create -f <local-block-pv10.yaml>1

   1

   直前の手順で作成された PersistentVolume のファイル名。

手順

1. spec: source: upload{} を指定する DataVolume 設定を作成します。

   apiVersion: cdi.kubevirt.io/v1alpha1
   kind: DataVolume
   metadata:
     name: <upload-datavolume> 1
   spec:
     source:
         upload: {}
     pvc:
       accessModes:
         - ReadWriteOnce
       resources:
         requests:
           storage: <2Gi> 2

   1

   DataVolume の名前。

   2

   DataVolume のサイズ。この値がアップロードするディスクのサイズ以上であることを確認します。

2. 以下のコマンドを実行して DataVolume を作成します。

   $ oc create -f <upload-datavolume>.yaml

手順

1. 以下を特定します。

   • 使用するアップロード DataVolume の名前。この DataVolume が存在しない場合、これは自動的に作成されます。
   • DataVolume のサイズ (アップロード手順の実行時に作成する必要がある場合)。サイズはディスクイメージのサイズ以上である必要があります。
   • アップロードする必要のある仮想マシンディスクイメージのファイルの場所。

2. virtctl image-upload コマンドを実行してディスクイメージをアップロードします。直前の手順で特定したパラメーターを指定します。以下は例になります。

   $ virtctl image-upload dv <datavolume_name> \ 1
   --size=<datavolume_size> \ 2
   --image-path=</path/to/image> \ 3

   1

   DataVolume の名前。

   2

   DataVolume のサイズ。例: --size=500Mi、--size=1G

   3

   仮想マシンディスクイメージのファイルパス。

   注記

   • 新規 DataVolume を作成する必要がない場合は、--size パラメーターを省略し、--no-create フラグを含めます。
   • HTTPS を使用したセキュアでないサーバー接続を許可するには、--insecure パラメーターを使用します。--insecure フラグを使用する際に、アップロードエンドポイントの信頼性は検証 されない 点に注意してください。

3. オプション。DataVolume が作成されたことを確認するには、以下のコマンドを実行してすべての DataVolume オブジェクトを表示します。

   $ oc get dvs

手順

1. ノードに新規のローカル PV を作成するか、またはノードにすでに存在しているローカル PV を特定します。

   • nodeAffinity.nodeSelectorTerms パラメーターを含むローカル PV を作成します。以下のマニフェストは、node01 に 10Gi のローカル 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. 以下を参照する DataVolume マニフェストを作成します。

   • 仮想マシンの PVC 名と namespace。
   • 直前の手順で PV に適用されたラベル。

   • 宛先 PV のサイズ。

     apiVersion: cdi.kubevirt.io/v1alpha1
     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

     新規 DataVolume の名前。

     2

     ソース PVC の名前。PVC 名が分からない場合は、仮想マシン設定 spec.volumes.persistentVolumeClaim.claimName で確認できます。

     3

     ソース PVC が存在する namespace。

     4

     直前の手順で PV に追加したラベル。

     5

     宛先 PV のサイズ。

4. DataVolume マニフェストをクラスターに適用してクローン作成の操作を開始します。

   $ oc apply -f <clone-datavolume.yaml>

手順

1. DataVolume 設定ファイルを編集します。

   apiVersion: cdi.kubevirt.io/v1alpha1
   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

手順

1. サイドメニューから、Workloads → Config 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 をクリックして ConfigMap を更新します。

手順

1. oc edit を使用して ConfigMap を編集します。

   $ oc edit configmap kubevirt-storage-class-defaults -n openshift-cnv

2. ConfigMap の 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. エディターを保存し、終了して ConfigMap を更新します。