8.18. 가상 머신 디스크

1. PVC에서 ReadWriteMany 액세스 모드를 요청해야 합니다.
2. 스토리지 공급자는 Kubernetes 및 CSI Snapshot API를 모두 지원해야 합니다.

절차

1. MachineConfig 파일을 생성합니다. 예를 들면 다음과 같습니다.

   $ touch machineconfig.yaml

2. hostpath 프로비전 프로그램으로 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.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 <backing_directory_path> 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 값이 hostpath 프로비전 프로그램으로 PV를 생성할 디렉터리가 되도록 파일을 편집합니다. 예를 들면 다음과 같습니다.

   apiVersion: hostpathprovisioner.kubevirt.io/v1beta1
   kind: HostPathProvisioner
   metadata:
     name: hostpath-provisioner
   spec:
     imagePullPolicy: IfNotPresent
     pathConfig:
       path: "<backing_directory_path>" 1
       useNamingPrefix: false 2
     workload: 3

   1

   프로비전 프로그램으로 PV를 생성할 백업 디렉터리를 지정합니다. 이 디렉토리는 파일 시스템의 루트 디렉토리(/)에 있으면 안 됩니다.

   2

   생성된 PV에 바인딩된 PVC(영구 볼륨 클레임) 이름을 디렉터리 이름의 접두부로 사용하려면 이 값을 true로 변경하십시오.

   3

   선택 사항: spec.workload 필드를 사용하여 hostpath 프로비전 프로그램에 대한 노드 배치 규칙을 구성할 수 있습니다.

   참고

   백업 디렉터리를 만들지 않은 경우 프로비전 프로그램에서 백업 디렉터리를 만들려고 합니다. container_file_t SELinux 컨텍스트를 적용하지 않은 경우 Permission denied 오류가 발생할 수 있습니다.

3. openshift-cnv 네임스페이스에 사용자 정의 리소스를 만듭니다.

   $ 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 두 가지입니다. 값을 지정하지 않는 경우 스토리지 클래스는 기본값인 Delete로 설정됩니다.

   3

   volumeBindingMode 값은 동적 프로비저닝 및 볼륨 바인딩이 발생하는 시기를 결정합니다. PVC(영구 볼륨 클레임)를 사용하는 Pod를 생성한 후 PV의 바인딩 및 프로비저닝을 수행하려면 WaitForFirstConsumer를 지정합니다. 이렇게 하면 PV에서 Pod의 스케줄링 요구 사항을 충족할 수 있습니다.

   참고

   가상 머신은 로컬 PV를 기반으로 하는 데이터 볼륨을 사용합니다. 로컬 PV는 특정 노드에 바인딩됩니다. 디스크 이미지는 가상 머신에서 사용할 수 있는 반면 가상 머신은 이전에 로컬 스토리지 PV가 고정된 노드에 예약할 수 없습니다.

   이 문제를 해결하려면 Kubernetes Pod 스케줄러를 사용하여 올바른 노드의 PV에 PVC를 바인딩합니다. volumeBindingMode가 WaitForFirstConsumer로 설정된 StorageClass를 사용하면 PVC를 사용하여 Pod가 생성될 때까지 PV의 바인딩 및 프로비저닝이 지연됩니다.

3. StorageClass 오브젝트를 만듭니다.

   $ oc create -f storageclass.yaml

절차

1. 스토리지 프로파일을 편집합니다. 이 예에서 CDI는 제공자를 인식하지 못합니다.

   $ oc edit -n openshift-cnv storageprofile <storage_class>

   스토리지 프로필 예

   apiVersion: cdi.kubevirt.io/v1beta1
   kind: StorageProfile
   metadata:
     name: <some_unknown_provisioner_class>
   #   ...
   spec: {}
   status:
     provisioner: <some_unknown_provisioner>
     storageClass: <some_unknown_provisioner_class>

2. 스토리지 프로파일에 필요한 속성 값을 제공합니다.

   스토리지 프로필 예

   apiVersion: cdi.kubevirt.io/v1beta1
   kind: StorageProfile
   metadata:
     name: <some_unknown_provisioner_class>
   #   ...
   spec:
     claimPropertySets:
     - accessModes:
       - ReadWriteOnce 1
       volumeMode:
         Filesystem 2
   status:
     provisioner: <some_unknown_provisioner>
     storageClass: <some_unknown_provisioner_class>

   1

   선택한 accessModes입니다.

   2

   선택한 volumeMode입니다.

   변경 사항을 저장하면 선택한 값이 스토리지 프로필 status 요소에 표시됩니다.

절차

1. 다음 명령을 실행하여 편집할 CDI를 엽니다.

   $ oc edit cdi

2. spec.config.filesystemOverhead 필드를 편집하여 선택한 값으로 채웁니다.

   ...
   spec:
     config:
       filesystemOverhead:
         global: "<new_global_value>" 1
         storageClass:
           <storage_class_name>: "<new_value_for_this_storage_class>" 2

   1

   CDI가 클러스터에 사용하는 파일 시스템 오버헤드 백분율입니다. 예를 들면 global입니다. "0.07" 는 파일 시스템 오버헤드에 대해 PVC의 7%를 예약합니다.

   2

   지정된 스토리지 클래스의 파일 시스템 오버헤드 백분율입니다. 예를 들면 mystorageclass입니다. "0.04" 는 mystorageclass 스토리지 클래스의 PVC의 기본 오버헤드 값을 4%로 변경합니다.

3. 편집기를 저장하고 종료하여 CDI 오브젝트를 업데이트합니다.

절차

1. 다음 명령을 실행하여 HyperConverged CR을 편집합니다.

   $ oc edit hco -n openshift-cnv kubevirt-hyperconverged

2. spec.resourceRequirements.storageWorkloads 스탠자를 CR에 추가하여 사용 사례에 따라 값을 설정합니다. 예를 들면 다음과 같습니다.

   apiVersion: hco.kubevirt.io/v1beta1
   kind: HyperConverged
   metadata:
     name: kubevirt-hyperconverged
   spec:
     resourceRequirements:
       storageWorkloads:
         limits:
           cpu: "500m"
           memory: "2Gi"
         requests:
           cpu: "250m"
           memory: "1Gi"

3. 편집기를 저장하고 종료하여 HyperConverged CR을 업데이트합니다.

절차

1. 웹 콘솔의 사이드 메뉴에서 스토리지 영구 볼륨 클레임을 클릭합니다.
2. 영구 볼륨 클레임 생성 드롭다운 목록을 클릭하여 확장합니다.
3. 사용할 데이터 업로드 폼을 클릭하여 영구 볼륨 클레임에 데이터 업로드 페이지를 엽니다.
4. 찾아보기를 클릭하여 파일 관리자를 열고 업로드할 이미지를 선택하거나, 파일을 여기로 드래그하거나 업로드할 항목 찾아보기 필드로 파일을 드래그합니다.

5. 선택 사항: 이 이미지를 특정 운영 체제의 기본 이미지로 설정합니다.

   1. 이 데이터를 가상 머신 운영 체제에 연결 확인란을 선택합니다.
   2. 목록에서 운영 체제를 선택합니다.
6. 영구 볼륨 클레임 이름 필드는 고유한 이름으로 자동으로 채워지며 편집할 수 없습니다. 필요한 경우 나중에 확인할 수 있도록 PVC에 지정된 이름을 기록해 두십시오.
7. 스토리지 클래스 목록에서 스토리지 클래스를 선택합니다.

8. 크기 필드에 PVC 크기 값을 입력합니다. 드롭다운 목록에서 해당 측정 단위를 선택합니다.

   주의

   PVC 크기는 압축되지 않은 가상 디스크의 크기보다 커야 합니다.

9. 선택한 스토리지 클래스와 일치하는 액세스 모드를 선택합니다.
10. 업로드를 클릭합니다.

절차

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

절차

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

절차

1. 로컬 PV를 생성할 노드에 root로 로그인합니다. 이 절차에서는 예제로 node01을 사용합니다.

2. 블록 장치로 사용할 수 있도록 파일을 생성하고 null 문자로 채웁니다. 다음 예제에서는 크기가 2Gb(20X100Mb 블록)인 파일 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

   이전 단계에서 생성한 영구 볼륨의 파일 이름입니다.

절차

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

절차

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

프로세스

1. 사이드 메뉴에서 워크로드 가상화를 클릭합니다.
2. 가상 머신 탭을 클릭합니다.
3. 가상 머신을 선택하여 가상 머신 개요 화면을 엽니다.
4. 가상 머신이 실행 중인 경우 작업 가상 머신 중지를 클릭하여 전원을 끕니다.
5. 스냅샷 탭을 클릭한 후 스냅샷 찍기를 클릭합니다.
6. 스냅샷 이름 및 선택 사항으로 설명 필드를 작성합니다.
7. 이 스냅샷에 포함된 디스크를 확장하여 스냅샷에 스토리지 볼륨이 포함되어 있는지 확인합니다.
8. VM에 스냅샷에 포함할 수 없는 디스크가 있고 계속 진행하려면 이 경고에 대해 인식하고 있으며 계속 진행하겠습니다. 확인란을 선택합니다.
9. 저장을 클릭합니다.

프로세스

1. YAML 파일을 생성하여 새 VirtualMachineSnapshot의 이름과 소스 VM의 이름을 지정하는 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

   소스 VM의 이름입니다.

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

   status 필드의 Progressing 조건은 스냅샷이 아직 생성 중인지를 나타냅니다.

   2

   status 필드의 Ready 조건은 스냅샷 생성 프로세스가 완료되었는지를 나타냅니다.

   3

   스냅샷을 사용할 준비가 되었는지를 나타냅니다.

   4

   스냅샷이 스냅샷 컨트롤러에서 생성한 VirtualMachineSnapshotContent 오브젝트에 바인딩되도록 지정합니다.

2. VirtualMachineSnapshotContent 리소스의 spec:volumeBackups 속성을 확인하여 예상 PVC가 스냅샷에 포함되어 있는지 확인합니다.

절차

1. 사이드 메뉴에서 워크로드 가상화를 클릭합니다.
2. 가상 머신 탭을 클릭합니다.
3. 가상 머신을 선택하여 가상 머신 개요 화면을 엽니다.
4. 가상 머신이 실행 중인 경우 작업 가상 머신 중지를 클릭하여 전원을 끕니다.
5. 스냅샷 탭을 클릭합니다. 페이지에는 가상 머신과 연결된 스냅샷 목록이 표시됩니다.

6. VM 스냅샷을 복원하는 다음 방법 중 하나를 선택합니다.

   1. VM을 복원하기 위해 소스로 사용할 스냅샷에서 복원을 클릭합니다.
   2. 스냅샷을 선택하여 스냅샷 세부 정보 화면을 열고 작업 가상 머신 스냅샷 복원을 클릭합니다.
7. 확인 팝업 창에서 복원을 클릭하여 스냅샷에 표시된 VM을 이전 구성으로 복원합니다.

절차

1. YAML 파일을 생성하여 복원할 VM의 이름과 소스로 사용할 스냅샷 이름을 지정하는 VirtualMachineRestore 오브젝트를 정의합니다.

   예를 들면 다음과 같습니다.

   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

   복원할 대상 VM의 이름입니다.

   3

   소스로 사용할 VirtualMachineSnapshot 오브젝트의 이름입니다.

2. VirtualMachineRestore 리소스를 만듭니다. 스냅샷 컨트롤러는 VirtualMachineRestore 오브젝트의 상태 필드를 업데이트하고 기존 VM 구성을 스냅샷의 콘텐츠로 교체합니다.

   $ oc create -f <my-vmrestore>.yaml

절차

1. 사이드 메뉴에서 워크로드 가상화를 클릭합니다.
2. 가상 머신 탭을 클릭합니다.
3. 가상 머신을 선택하여 가상 머신 개요 화면을 엽니다.
4. 스냅샷 탭을 클릭합니다. 페이지에는 가상 머신과 연결된 스냅샷 목록이 표시됩니다.

5. 가상 머신 스냅샷을 삭제하는 다음 방법 중 하나를 선택합니다.

   1. 삭제할 가상 머신의 옵션 메뉴 를 클릭하고 가상 머신 스냅샷 삭제를 선택합니다.
   2. 스냅샷을 선택하여 스냅샷 세부 정보 화면을 열고 작업 가상 머신 스냅샷 삭제를 클릭합니다.
6. 확인 팝업 창에서 삭제를 클릭하여 스냅샷을 삭제합니다.

절차

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. 다음을 참조하는 데이터 볼륨 매니페스트를 생성합니다.

   • 가상 머신의 PVC 이름 및 네임스페이스
   • 이전 단계에서 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가 존재하는 네임스페이스입니다.

     4

     이전 단계에서 PV에 적용한 라벨입니다.

     5

     대상 PV의 크기

4. 클러스터에 데이터 볼륨 매니페스트를 적용하여 복제 작업을 시작합니다.

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

절차

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

1. 소스 PVC(영구 볼륨 클레임)의 스냅샷이 생성됩니다.
2. 스냅샷에서 PVC가 생성됩니다.
3. 스냅샷이 삭제됩니다.

1. DataVolume 오브젝트에 대해 새 데이터 볼륨의 이름, 소스 PVC의 이름과 네임스페이스를 지정하는 YAML 파일을 생성합니다. 이 예제에서는 스토리지 API를 지정하므로 accessModes 또는 volumeMode를 지정할 필요가 없습니다. 최적의 값을 자동으로 계산합니다.

   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
     storage: 4
       resources:
         requests:
           storage: <2Gi> 5

   1

   새 데이터 볼륨의 이름입니다.

   2

   소스 PVC가 존재하는 네임스페이스입니다.

   3

   소스 PVC의 이름입니다.

   4

   스토리지 API로 할당을 지정합니다.

   5

   새 데이터 볼륨의 크기입니다.

2. 데이터 볼륨을 생성하여 PVC 복제를 시작합니다.

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

   참고

   데이터 볼륨이 있으면 PVC가 준비될 때까지 가상 머신이 시작되지 않으므로 PVC가 복제되는 동안 새 데이터 볼륨을 참조하는 가상 머신을 생성할 수 있습니다.

절차

1. OpenShift Virtualization 콘솔의 사이드 메뉴에서 워크로드 가상화를 클릭합니다.
2. 템플릿 탭을 클릭합니다.
3. 부팅 소스를 구성할 RHEL 템플릿을 확인하고 소스 추가를 클릭합니다.
4. 템플릿에 부팅 소스 추가 창의 Boot 소스 유형 목록에서 URL을 통해 가져오기 (PVC 생성)을 선택합니다.
5. RHEL 다운로드 페이지를 클릭하여 Red Hat 고객 포털에 액세스합니다. 사용 가능한 설치 프로그램 및 이미지 목록이 Red Hat Enterprise Linux 다운로드 페이지에 표시됩니다.
6. 다운로드하려는 Red Hat Enterprise Linux KVM 게스트 이미지를 식별합니다. 지금 다운로드를 마우스 오른쪽 버튼으로 클릭하고 이미지의 URL을 복사합니다.
7. 템플릿에 부팅 소스 추가 창에서 게스트 이미지의 복사된 URL을 URL 가져오기 필드에 붙여넣고 저장 및 가져오기를 클릭합니다.

1. 템플릿 탭을 클릭합니다.
2. 이 템플릿의 타일에 녹색 확인 마크가 표시되는지 확인합니다.

절차

1. OpenShift Virtualization 콘솔의 사이드 메뉴에서 워크로드 가상화를 클릭합니다.
2. 템플릿 탭을 클릭합니다.
3. 부팅 소스를 구성할 가상 머신 템플릿을 확인하고 소스 추가를 클릭합니다.
4. 템플릿에 부팅 소스 추가 창에서 부팅 소스 선택을 클릭하고 PVC(영구 볼륨 클레임)를 생성하는 방법을 선택합니다. 로컬 파일 업로드,URL을 통해 가져오기,기존 PVC 복제 또는 레지스트리를 통해 가져오기.
5. 선택 사항: This is a CD-ROM boot source (CD-ROM 부팅 소스)를 클릭하여 CD-ROM을 마운트하고 이를 사용하여 운영 체제를 빈 디스크에 설치합니다. 추가 빈 디스크는 OpenShift Virtualization에 의해 자동으로 생성 및 마운트됩니다. 추가 디스크가 필요하지 않은 경우 가상 머신을 생성할 때 제거할 수 있습니다.

6. 영구 볼륨 클레임(PVC) 크기에 값을 입력하여 압축이 해제되지 않은 이미지에 적합한 PVC 크기를 지정하고 필요한 추가 공간을 지정합니다.

   1. 선택 사항: 소스 프로바이더 의 이름을 입력하여 이름을 이 템플릿과 연결합니다.

   2. 선택 사항: 고급 스토리지 설정: Storage(스토리지) 클래스를 클릭하고 디스크를 생성하는 데 사용되는 스토리지 클래스를 선택합니다. 일반적으로 이 스토리지 클래스는 모든 PVC에서 사용하도록 생성되는 기본 스토리지 클래스입니다.

      참고

      제공된 부팅 소스가 최신 버전의 운영 체제로 자동 업데이트됩니다. 자동 업데이트됨 부팅 소스의 경우 PVC(영구 볼륨 클레임)가 클러스터의 기본 스토리지 클래스를 사용하여 생성됩니다. 구성 후 다른 기본 스토리지 클래스를 선택하는 경우 이전 기본 스토리지 클래스로 구성된 클러스터 네임스페이스의 기존 데이터 볼륨을 삭제해야 합니다.

   3. 선택 사항: 고급 스토리지 설정: 액세스 모드를 클릭하고 영구 볼륨에 대한 액세스 모드를 선택합니다.

      • 단일 사용자(RWO) 는 볼륨을 단일 노드에서 읽기-쓰기로 마운트합니다.
      • 공유 액세스(RWX) 는 볼륨을 여러 노드에서 읽기-쓰기로 마운트합니다.
      • 읽기 전용(ROX) 은 볼륨을 여러 노드에서 읽기 전용으로 마운트합니다.
   4. 선택 사항: 고급 스토리지 설정: 기본값인 파일 시스템 대신 Block 을 선택하려면 볼륨 모드를 클릭합니다. OpenShift Virtualization은 원시 블록 볼륨을 정적으로 프로비저닝할 수 있습니다. 이러한 볼륨에는 파일 시스템이 없으며 디스크에 직접 쓰거나 자체 스토리지 서비스를 구현하는 애플리케이션에 성능 이점을 제공할 수 있습니다.

7. 다음과 같이 부팅 소스를 저장할 적절한 방법을 선택합니다.

   1. 로컬 파일을 업로드한 경우 저장 및 업로드를 클릭합니다.
   2. URL 또는 레지스트리에서 콘텐츠를 가져온 경우 저장 및 가져오기를 클릭합니다.
   3. 기존 PVC를 복제한 경우 저장 및 복제를 클릭합니다.

절차

1. OpenShift Container Platform 웹 콘솔의 사이드 메뉴에서 워크로드 > 가상화를 클릭합니다.
2. 가상 머신 탭 또는 템플릿 탭에서 생성을 클릭하고 마법사를 통한 가상 머신을 선택합니다.
3. 템플릿 선택 단계의 OS 및 버전 이름 옆에 (사용 가능한 소스) 레이블이 있는 운영 체제 목록에서 OS를 선택합니다. (사용 가능한 소스) 라벨은 이 OS에서 부팅 소스를 사용할 수 있음을 나타냅니다.
4. 검토 및 확인을 클릭합니다.
5. 필요한 경우 가상 머신 설정을 검토한 후 편집합니다.
6. 가상 머신 생성을 클릭하여 가상 머신을 생성합니다. 가상 머신 템플릿을 성공적으로 생성했습니다. 페이지가 표시됩니다.

절차

1. OpenShift Virtualization 콘솔의 사이드 메뉴에서 워크로드 > 가상화를 클릭합니다.
2. 템플릿 탭을 클릭합니다.
3. 사용자 지정할 템플릿의 Source 공급자 열에서 링크를 클릭합니다. 템플릿에 현재 정의된 소스가 있음을 나타내는 창이 표시됩니다.
4. 창에서 소스 사용자 지정 링크를 클릭합니다.
5. 부팅 소스 사용자 지정 프로세스에 대한 정보를 읽은 후에 사용자 지정 정보로 진행하려면 부팅 소스 사용자 지정 창에서 계속을 클릭합니다.

6. 부팅 소스 사용자 지정 준비 페이지의 새 템플릿 정의 섹션에서 다음을 수행합니다.

   1. 새 템플릿 네임스페이스 필드를 선택한 다음 프로젝트를 선택합니다.
   2. 새 템플릿 이름 필드에 사용자 지정 템플릿의 이름을 입력합니다.
   3. 새 템플릿 공급자 필드에 템플릿 프로바이더의 이름을 입력합니다.
   4. 새 템플릿 지원 필드를 선택한 다음, 생성한 사용자 지정 템플릿에 대한 지원 연락처를 나타내는 적절한 값을 선택합니다.
   5. 새 템플릿 플레이버 필드를 선택한 다음 생성한 사용자 지정 이미지의 적절한 CPU 및 메모리 값을 선택합니다.
7. 사용자 지정에 대한 부팅 소스 준비 섹션에서 필요한 경우 cloud-init YAML 스크립트를 사용자 지정하여 로그인 인증 정보를 정의합니다. 그렇지 않으면 스크립트가 기본 인증 정보를 생성합니다.
8. 사용자 지정 시작을 클릭합니다. 사용자 지정 프로세스가 시작되고 부팅 소스 사용자 지정 준비 페이지가 표시된 다음 부팅 소스 사용자 지정 페이지가 표시됩니다. 부팅 소스 사용자 지정 페이지에 실행 중인 스크립트의 출력이 표시됩니다. 스크립트가 완료되면 사용자 지정 이미지를 사용할 수 있습니다.
9. VNC 콘솔의 게스트 로그인 인증 정보 섹션에서 암호 표시를 클릭합니다. 로그인 인증 정보가 표시됩니다.
10. 이미지가 로그인할 준비가 되면 게스트 로그인 인증 정보 섹션에 표시된 사용자 이름과 암호를 제공하여 VNC 콘솔로 로그인합니다.
11. 사용자 지정 이미지가 예상대로 작동하는지 확인합니다. 부팅 가능한 경우 부팅 소스 사용 가능을 클릭합니다.
12. 사용자 지정 완료 및 템플릿 사용 가능 창에서 I have sealed the boot source so it can be used as a template를 선택한 다음 적용을 클릭합니다.
13. 부팅 소스 사용자 지정 완료 페이지에서 템플릿 생성 프로세스가 완료될 때까지 기다립니다. 템플릿 세부 정보 탐색또는 템플릿 목록으로 이동을 클릭하여 사용자 지정 부팅 소스에서 생성한 사용자 지정 템플릿을 확인합니다.

절차

1. Dockerfile을 생성하여 가상 머신 이미지를 컨테이너 이미지로 빌드합니다. 가상 머신 이미지는 UID가 107인 QEMU에 속하고 컨테이너 내부의 /disk/ 디렉터리에 있어야 합니다. 그런 다음 /disk/ 디렉터리에 대한 권한을 0440으로 설정해야 합니다.

   다음 예제에서는 Red Hat UBI(Universal Base Image)를 사용하여 첫 번째 단계에서 이러한 구성 변경을 처리하고, 두 번째 단계에서 최소 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

절차

1. 다음 명령을 실행하여 HyperConverged CR을 편집합니다.

   $ oc edit hco -n openshift-cnv kubevirt-hyperconverged

2. spec.scratchSpaceStorageClass 필드를 CR에 추가하여 해당 값을 클러스터에 존재하는 스토리지 클래스의 이름으로 설정합니다.

   apiVersion: hco.kubevirt.io/v1beta1
   kind: HyperConverged
   metadata:
     name: kubevirt-hyperconverged
   spec:
     scratchSpaceStorageClass: "<storage_class>" 1

   1

   스토리지 클래스를 지정하지 않으면 CDI는 채워지는 영구 볼륨 클레임의 스토리지 클래스를 사용합니다.

3. 기본 편집기를 저장하고 종료하여 HyperConverged CR을 업데이트합니다.

절차

1. PV의 회수 정책이 Retain으로 설정되어 있는지 확인합니다.

   1. PV의 회수 정책을 확인합니다.

      $ oc get pv <pv_name> -o yaml | grep 'persistentVolumeReclaimPolicy'

   2. persistentVolumeReclaimPolicy가 Retain으로 설정되지 않은 경우, 다음 명령을 사용하여 회수 정책을 편집합니다.

      $ 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 파일로 내보냅니다. 이 절차의 뒷부분에서 공유 스토리지를 수동으로 제거하는 경우 이 구성을 참조할 수 있습니다. PV를 회수한 후 새 PV를 동일한 스토리지 구성으로 생성하기 위해 이 파일의 spec 매개변수를 기반으로 사용할 수도 있습니다.

   $ 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