Persistent Storage for Virtual Machines

Previous examples have used a small virtual machine running the CirrOS operating system. This virtual machine uses a containerdisk image, that is, the root disk of the VM is a container just like those in Pods. Like a Pod’s container image, the containerdisk does not persist any changes made to it by its VM.

For Pods and VMs alike, the solution to persistent storage is persistent volumes. The KubeVirt project includes a persistent storage add-on for Kubernetes called the Containerized Data Importer (CDI). CDI provides a declarative way to import virtual machine disk images into PersistentVolumeClaims (PVCs) for use by virtual machines.

Upload with virtctl

The virtctl utility has an image-upload command if you have a copy of the image you would like to use on local disk. See the virtctl image-upload documentation for more information.

Create a DataVolume

CDI includes a CustomResourceDefinition (CRD) that provides a resource called a DataVolume (DV). DVs are used to abstract the creation and population of disk data onto PVCs in a Kubernetes cluster. Once a DV is created, CDI takes over and copies a disk image from the provided source into a PVC. Available source types range from external targets like images served over http to internal sources like other PVCs or even container disks in a registry. Here is an example DataVolume that will import a CirrOS image to a PVC so the underlying VM can have a persistent disk across reboots.

apiVersion: cdi.kubevirt.io/v1beta1
kind: DataVolume
metadata:
  name: "example-import-dv"
spec:
  source:
      http:
         url: "https://download.cirros-cloud.net/0.4.0/cirros-0.4.0-x86_64-disk.img" # S3 or GCS
         secretRef: "" # Optional
         certConfigMap: "" # Optional
  pvc:
    accessModes:
      - ReadWriteOnce
    resources:
      requests:
        storage: "64Mi"

 

Monitoring and troubleshooting DataVolumes

The DV’s status field reflects the progress of copies, clones, or uploads using three conditions: Ready, Bound, and Running. If the DV’s Ready condition is true, then the PVC is ready to be used by a virtual machine.

Bound means that a PVC has successfully bound to a PV. In the case that Bound remains “false” for longer than it should take to create a PV, this may indicate a problem with the underlying storage system, lack of a default StorageClass, or a mismatch between PVC parameters in the DV and what can be offered by the default StorageClass.

The Running condition indicates the cloning operation is under way. There will be a Pod running in the same namespace as the DV with a name in the form, “importer-DVNAME”. Watching logs of that importer Pod will provide progress updates if the clone is progressing properly.