Uploading a local disk image to a block storage data volume
You can upload a local disk image into a block data volume by using the virtctl
command-line utility.
In this workflow, you create a local block device to use as a persistent volume, associate this block volume with an upload
data volume, and use virtctl
to upload the local disk image into the data volume.
Prerequisites
If you require scratch space according to the CDI supported operations matrix, you must first define a storage class or prepare CDI scratch space for this operation to complete successfully.
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). Data volumes are integrated with OKD Virtualization, and they prevent a virtual machine from being started before the PVC has been prepared.
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
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
to the node on which to create the local PV. This procedure usesnode01
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.$ losetup </dev/loop10>d3 <loop10> (1) (2)
1 File path where the loop device is mounted. 2 The file created in the previous step to be mounted as the loop device. 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.
Creating an upload data volume
You can manually create a data volume with an upload
data source to use for uploading local disk images.
Procedure
Create a data volume configuration that specifies
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 The name of the data volume. 2 The size of the data volume. Ensure that this value is greater than or equal to the size of the disk that you upload. Create the data volume by running the following command:
$ oc create -f <upload-datavolume>.yaml
Uploading a local disk image to a data volume
You can use the virtctl
CLI utility to upload a local disk image from a client machine to a data volume (DV) in your cluster. You can use a DV that already exists in your cluster or create a new DV during this procedure.
After you upload a local disk image, you can add it to a virtual machine. |
Prerequisites
You must have one of the following:
A raw virtual machine image file in either ISO or IMG format.
A virtual machine image file in QCOW2 format.
For best results, compress your image file according to the following guidelines before you upload it:
Compress a raw image file by using
xz
orgzip
.Using a compressed raw image file results in the most efficient upload.
Compress a QCOW2 image file by using the method that is recommended for your client:
If you use a Linux client, sparsify the QCOW2 file by using the virt-sparsify tool.
If you use a Windows client, compress the QCOW2 file by using
xz
orgzip
.
The
kubevirt-virtctl
package must be installed on the client machine.The client machine must be configured to trust the OKD router’s certificate.
Procedure
Identify the following items:
The name of the upload data volume that you want to use. If this data volume does not exist, it is created automatically.
The size of the data volume, if you want it to be created during the upload procedure. The size must be greater than or equal to the size of the disk image.
The file location of the virtual machine disk image that you want to upload.
Upload the disk image by running the
virtctl image-upload
command. Specify the parameters that you identified in the previous step. For example:$ virtctl image-upload dv <datavolume_name> \ (1)
--size=<datavolume_size> \ (2)
--image-path=</path/to/image> \ (3)
1 The name of the data volume. 2 The size of the data volume. For example: —size=500Mi
,—size=1G
3 The file path of the virtual machine disk image. If you do not want to create a new data volume, omit the
—size
parameter and include the—no-create
flag.When uploading a disk image to a PVC, the PVC size must be larger than the size of the uncompressed virtual disk.
To allow insecure server connections when using HTTPS, use the
—insecure
parameter. Be aware that when you use the—insecure
flag, the authenticity of the upload endpoint is not verified.
Optional. To verify that a data volume was created, view all data volumes by running the following command:
$ oc get dvs
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 | ✓ QCOW2* | ✓ QCOW2 | ✓ QCOW2 | ✓ QCOW2 |
KubeVirt (RAW) | ✓ RAW | ✓ RAW | ✓ RAW | ✓ RAW | ✓ RAW |
✓ Supported operation
□ Unsupported operation
* Requires scratch space
** Requires scratch space if a custom certificate authority is required
Additional resources
- Configure preallocation mode to improve write performance for data volume operations.