Virtual Machine Disk

A Virtual Machine Disk

storageClass and source are annotated as immutable in the chart schema — see docs/storage-immutability.md for the contract and which consumers enforce it. DataVolume.spec is immutable in CDI, so the chart also fails the release on an attempted storageClass/source edit of an existing disk rather than silently reusing the old spec; delete and recreate the disk to change either field.

Whether CDI has finished populating the disk shows up in the WorkloadsReady condition, not in Ready, which follows the Helm release and does not wait on the DataVolume: WorkloadsReady stays False while an import, clone or upload is in flight and when the DataVolume fails. Its message names the DataVolume and the phase it is in, followed by the error CDI reports for the pod populating the disk when there is one, such as a 404 or an unresolvable host on an HTTP source: CDI keeps retrying such an import, so its phase stays ImportInProgress, and the error is shown between retries rather than while a retry is running. kubectl get vmdisks shows the condition in the WORKLOADS column, and the console badge reads DataVolumeNotReady until it is True. A disk created before this behaviour was introduced keeps its old release settings, under which Ready may wait on the DataVolume, until its application is next updated. A source.upload disk reads False from the moment it is created until virtctl image-upload completes, because CDI reports waiting for the upload and receiving it as one phase. A disk counts as ready while it waits for its consumer with bindImmediately off on a WaitForFirstConsumer class, because that is a state such a disk is supposed to rest in.

bindImmediately is on by default, so a disk’s volume is provisioned when the disk is created rather than deferred to the first consumer. That default exists because a VMDisk is a standalone object with a lifecycle of its own: on a WaitForFirstConsumer StorageClass a disk that no VM has attached yet would otherwise never populate at all. It costs something on a node-pinned class such as local, where the CDI worker pod becomes the first consumer and the volume lands where that pod was scheduled rather than where the VM will run, so a VM whose placement is constrained (a nodeSelector, a resource request only one node satisfies, or the Windows affinity applied by _cluster.scheduling.dedicatedNodesForWindowsVMs) can stay unschedulable against a node-affinity conflict, and storageClass is immutable so the only exit is deleting and recreating the disk. Turn bindImmediately off for a disk a VMInstance will consume on such a class: KubeVirt then renders a temporary launcher pod carrying the VM’s own affinity and node selector, and the volume binds where the VM can actually run. The chart default replicated binds Immediate regardless, so neither setting changes anything there.

A disk created from source.image should use the StorageClass its golden image lives in, replicated in the default layout. When CDI clones with the csi-clone strategy, the platform default, into a different StorageClass of the same CSI driver with the same volume mode and room to expand, it does not fall back to a host-assisted copy and leaves the clone to the driver. The snapshot strategy does the same when it gets a VolumeSnapshotClass of that driver: the class both StorageProfiles name, or, when they do not name the same one, any class of the driver. LINSTOR creates that clone next to the source data, so on a target class that does not allow remote volume access from every node, such as a node-local class, the clone may never bind. The chart refuses such a new disk when the golden’s driver and the target class’s provisioner are both LINSTOR and the target’s allowRemoteVolumeAccess is not a value linstor-csi reads as true (1, t or true, in any of the cases Go’s strconv.ParseBool accepts); any other value is a list of rules, and the chart counts it as access from anywhere only when one rule names no fromSame label. Without that parameter it reads the target’s layer list the way linstor-csi does, which allows remote access when it has a DRBD or NVMe layer, and a class that sets no layer list has DRBD. Under snapshot, it also refuses a disk whose golden and target StorageProfiles name the same VolumeSnapshotClass when that class does not exist and the golden’s driver is the target class’s provisioner, whatever the driver: CDI then fails to plan the clone instead of falling back. Both refusals compare only what they can look up: without the golden image’s PVC, the cdi resource or the target’s StorageClass nothing is compared. The remote access refusal also needs the target’s StorageProfile with a claim property set and the golden’s driver, taken from its bound PV or else from its StorageClass; when any of them is missing, the disk renders. Neither applies to a disk whose DataVolume or PVC already exists. Use the golden image’s StorageClass instead, or ask the platform administrator to set cloneStrategyOverride: copy in the kubevirt-cdi package, which clones through a host-assisted copy in every case. The remote access refusal leaves alone a target class that allows remote volume access, a driver other than LINSTOR, a target class of another driver, a different volume mode, a class without volume expansion, snapshot that gets no VolumeSnapshotClass of the driver, and the copy strategy. An empty storageClass is compared as the class CDI would pick for it: the class annotated storageclass.kubevirt.io/is-default-virt-class, otherwise the class annotated storageclass.kubernetes.io/is-default-class; when several classes carry the annotation that decides, nothing is compared.

Parameters

Common parameters