Overview
TheDataVolume class provides a declarative way to create and manage persistent volumes for virtual machines. It handles data import from various sources including HTTP, container registries, PVCs, and supports direct upload and blank disk creation.
Class Definition
Constructor
Source type for the DataVolume:
"upload", "http", "pvc", "registry", or "blank". Use source_dict instead.Dictionary defining the DataVolume source configuration. This is the recommended way to specify sources.
DataVolume size in Kubernetes resource format (e.g.,
"5Gi", "100Mi").Name of the StorageClass to use for the DataVolume.
URL for importing data when source is
"http" or "registry".Content type of the data:
"kubevirt" or "archive".Access mode for the volume:
"ReadWriteOnce" (RWO), "ReadOnlyMany" (ROX), or "ReadWriteMany" (RWX).Volume mode:
"Filesystem" or "Block".Name of ConfigMap containing TLS certificates for HTTPS sources.
Secret object containing authentication credentials for the source.
Node name to provision the DataVolume on (for hostPath storage).
Name of the source PVC when cloning from an existing PVC.
Namespace of the source PVC when cloning.
Indirect reference to a data source. Fields:
kind (e.g., "DataSource"), name, namespace.Network attachment definition name for Multus networking.
Request immediate binding even when StorageClass uses
WaitForFirstConsumer.Enable disk space preallocation for better performance.
API to use for DataVolume:
"pvc" or "storage". Default will change to "storage" in future releases.List of DataVolumeCheckpoints for incremental snapshot operations.
Indicates if the current checkpoint is the final one.
Priority class for the DataVolume import/clone pod.
Access Modes
TheDataVolume.AccessMode class defines volume access modes:
RWO: ReadWriteOnce - can be mounted read-write by a single nodeROX: ReadOnlyMany - can be mounted read-only by many nodesRWX: ReadWriteMany - can be mounted read-write by many nodes
Content Types
TheDataVolume.ContentType class defines data content types:
KUBEVIRT: KubeVirt-specific disk image formatARCHIVE: Archive file that needs to be extracted
Volume Modes
TheDataVolume.VolumeMode class defines volume modes:
BLOCK: Raw block deviceFILE: Filesystem volume
Status Values
TheDataVolume.Status class provides constants for DataVolume states:
BLANK: Blank disk createdPVC_BOUND: PVC is boundIMPORT_SCHEDULED: Import operation scheduledClONE_SCHEDULED: Clone operation scheduledUPLOAD_SCHEDULED: Upload operation scheduledIMPORT_IN_PROGRESS: Importing dataCLONE_IN_PROGRESS: Cloning from sourceUPLOAD_IN_PROGRESS: Upload in progressSNAPSHOT_FOR_SMART_CLONE_IN_PROGRESS: Creating snapshot for smart cloneSMART_CLONE_PVC_IN_PROGRESS: Smart clone in progressUPLOAD_READY: Ready to receive uploadUNKNOWN: Status unknownWAIT_FOR_FIRST_CONSUMER: Waiting for first consumer (WaitForFirstConsumer binding mode)PENDING_POPULATION: Waiting for population to start
Methods
wait_for_dv_success()
Waits for the DataVolume to successfully complete provisioning.Maximum time to wait for success (default: 600 seconds).
Time to wait for non-Pending status (default: 120 seconds).
Time to wait for PVC to reach Bound status (default: 60 seconds).
Garbage collection flag (deprecated, removed in v4.19).
Optional function to check for failure conditions. If returns
True, raises TimeoutExpiredError.wait_deleted()
Waits for both the DataVolume and its associated PVC to be deleted.Maximum time to wait for deletion (default: 240 seconds).
delete()
Deletes the DataVolume.Whether to wait for deletion to complete.
Maximum time to wait for deletion.
Optional deletion options body.
Properties
pvc
Returns the associated PersistentVolumeClaim object.scratch_pvc
Returns the scratch PVC used during import/clone operations.Usage Examples
Related Resources
VirtualMachine
Use DataVolumes as persistent disks for VMs
Virtual Machines Guide
Complete guide to working with virtual machines
Notes
The
api_name parameter currently defaults to "pvc" but will change to "storage" in a future release. Explicitly set api_name="pvc" to maintain current behavior.DataVolumes with
WaitForFirstConsumer binding mode will remain in WAIT_FOR_FIRST_CONSUMER status until a pod requests the volume. Use bind_immediate_annotation=True to bind immediately if needed.