Cloning a virtual machine disk into a new block storage persistent volume claim - Virtual machines | Virtualization

Prerequisites
About data volumes
About block persistent volumes
Creating a local block persistent volume
Cloning the PVC of a VM disk into a new data volume
CDI supported operations matrix

You can clone the persistent volume claim (PVC) of a virtual machine disk into a new block PVC by referencing the source PVC in your clone target data volume configuration file.

Cloning operations between different volume modes are supported, such as cloning from a persistent volume (PV) with volumeMode: Block to a PV with volumeMode: Filesystem.

However, you can only clone between different volume modes if they are of the contentType: kubevirt.

When you enable preallocation globally, or for a single data volume, the Containerized Data Importer (CDI) preallocates disk space during cloning. Preallocation enhances write performance. For more information, see Using preallocation for data volumes.

Prerequisites

Users need additional permissions to clone the PVC of a virtual machine disk into another namespace.

About data volumes

DataVolume objects are custom resources that are provided by the Containerized Data Importer (CDI) project. Data volumes orchestrate import, clone, and upload operations that are associated with an underlying persistent volume claim (PVC). You can create a data volume as either a standalone resource or by using the dataVolumeTemplate field in the virtual machine (VM) specification.

VM disk PVCs that are prepared by using standalone data volumes maintain an independent lifecycle from the VM. If you use the dataVolumeTemplate field in the VM specification to prepare the PVC, the PVC shares the same lifecycle as the VM.

About block persistent volumes

A block persistent volume (PV) is a PV that is backed by a raw block device. These volumes do not have a file system and can provide performance benefits for virtual machines by reducing overhead.

Raw block volumes are provisioned by specifying volumeMode: Block in the PV and persistent volume claim (PVC) specification.

Creating a local block persistent volume

If you intend to import a virtual machine image into block storage with a data volume, you must have an available local block persistent volume.

Create a local block persistent volume (PV) on a node by populating a file and mounting it as a loop device. You can then reference this loop device in a PV manifest as a Block volume and use it as a block device for a virtual machine image.

Procedure

Log in as root user to the node on which to create the local PV. This procedure uses node01 for its examples.
Create a file and populate it with null characters so that it can be used as a block device. The following example creates a file loop10 with a size of 2Gb (20 100Mb blocks):
```
# dd if=/dev/zero of=loop10 bs=100M count=20
```
Mount the loop10 file as a loop device as in the following example:
```
# losetup /path/loop10 loop10 (1)
```
1 Specify the path of the loop device and the loop device file name.

Create a PersistentVolume manifest that references the mounted loop device.

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	The path of the loop device on the node.
2	Specifies it is a block PV.
3	Optional: Set a storage class for the PV. If you omit it, the cluster default is used.
4	The node on which the block device was mounted.

Create the block PV:
```
# oc create -f <local-block-pv10.yaml>(1)
```
1 The file name of the persistent volume created in the previous step.

Cloning the PVC of a VM disk into a new data volume

You can clone the persistent volume claim (PVC) of an existing (virtual machine) VM disk into a new data volume. The new data volume can then be used for a new virtual machine.

When a data volume is created independently of a VM, the lifecycle of the data volume is independent of the VM. If the VM is deleted, neither the data volume nor its associated PVC is deleted.

Prerequisites

The VM must be stopped.

Procedure

Create a YAML file for a data volume as shown in the following example:

apiVersion: cdi.kubevirt.io/v1beta1
kind: DataVolume
metadata:
  name: <datavolume> (1)
spec:
  source:
    pvc:
      namespace: "<source_namespace>" (2)
      name: "<my_vm_disk>" (3)
  storage: {}

1	Specify the name of the new data volume.
2	Specify the namespace of the source PVC.
3	Specify the name of the source PVC.

Create the data volume by running the following command:
```
$ oc create -f <datavolume>.yaml
```
Data volumes prevent a VM from starting before the PVC is prepared. You can create a VM that references the new data volume while the PVC is being cloned.

CDI supported operations matrix

This matrix shows the supported CDI operations for content types against endpoints, and which of these operations requires scratch space.

Content types	HTTP	HTTPS	HTTP basic auth	Registry	Upload
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*

Content types

HTTP

HTTPS

HTTP basic auth

Registry

Upload

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*

✓ Supported operation

□ Unsupported operation

* Requires scratch space

** Requires scratch space if a custom certificate authority is required